rfc8679xml2.original.xml   rfc8679.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
<!-- [rfced] updated by Chris /08/19/19 --> nsus="true" docName="draft-ietf-mpls-egress-protection-framework-07" indexInclud
e="true" ipr="trust200902" number="8679" prepTime="2019-12-04T22:12:35" scripts=
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ "Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3"
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC tocInclude="true" xml:lang="en">
.2119.xml"> <link href="https://datatracker.ietf.org/doc/draft-ietf-mpls-egress-protection
<!ENTITY RFC4090 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC -framework-07" rel="prev"/>
.4090.xml"> <link href="https://dx.doi.org/10.17487/rfc8679" rel="alternate"/>
<!ENTITY RFC5286 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <link href="urn:issn:2070-1721" rel="alternate"/>
.5286.xml">
<!ENTITY RFC7490 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7490.xml">
<!ENTITY RFC7812 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7812.xml">
<!ENTITY RFC8104 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8104.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
<!ENTITY RFC8400 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8400.xml">
<!ENTITY RFC8402 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8402.xml">
]>
<!-- [rfced] The sortrefs PI was set to "no" in the original. Please review. --
>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc submissionType="IETF" category="std" consensus="yes" number="XXXX" ipr="tru
st200902">
<front> <front>
<title>MPLS Egress Protection Framework</title>
<title>MPLS Egress Protection Framework <seriesInfo name="RFC" value="8679" stream="IETF"/>
</title> <author fullname="Yimin Shen" surname="Shen" initials="Y">
<organization showOnFrontPage="true">Juniper Networks</organization>
<author fullname="Yimin Shen" surname="Yimin Shen">
<organization>Juniper Networks</organization>
<address> <address>
<postal> <postal>
<street>10 Technology Park Drive</street> <street>10 Technology Park Drive</street>
<city>Westford</city> <city>Westford</city>
<region>MA</region> <region>MA</region>
<code>01886</code> <code>01886</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<phone>+1 9785890722</phone> <phone>+1 978 589 0722</phone>
<email>yshen@juniper.net</email> <email>yshen@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Minto Jeyananth" surname="Jeyananth" initials="M">
<author fullname="Minto Jeyananth" surname="Minto Jeyananth"> <organization showOnFrontPage="true">Juniper Networks</organization>
<organization>Juniper Networks</organization>
<address> <address>
<postal> <postal>
<street>1133 Innovation Way</street> <street>1133 Innovation Way</street>
<city>Sunnyvale</city> <city>Sunnyvale</city>
<region>CA</region> <region>CA</region>
<code>94089</code> <code>94089</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<phone>+1 4089367563</phone> <phone>+1 408 936 7563</phone>
<email>minto@juniper.net</email> <email>minto@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Bruno Decraene" surname="Decraene" initials="B">
<author fullname="Bruno Decraene" surname="Bruno Decraene"> <organization showOnFrontPage="true">Orange</organization>
<organization>Orange</organization>
<address> <address>
<email>bruno.decraene@orange.com</email> <email>bruno.decraene@orange.com</email>
</address> </address>
</author> </author>
<author fullname="Hannes Gredler" surname="Gredler" initials="H">
<author fullname="Hannes Gredler" surname="Hannes Gredler"> <organization showOnFrontPage="true">RtBrick Inc.</organization>
<organization>RtBrick Inc</organization>
<address> <address>
<email>hannes@rtbrick.com</email> <email>hannes@rtbrick.com</email>
</address> </address>
</author> </author>
<author fullname="Carsten Michel" surname="Michel" initials="C">
<author fullname="Carsten Michel" surname="Carsten Michel"> <organization showOnFrontPage="true">Deutsche Telekom</organization>
<organization>Deutsche Telekom</organization>
<address> <address>
<email>c.michel@telekom.de</email> <email>c.michel@telekom.de</email>
</address> </address>
</author> </author>
<author fullname="Huaimo Chen" surname="Chen" initials="H">
<author fullname="Huaimo Chen" surname="Huaimo Chen"> <organization showOnFrontPage="true">Futurewei</organization>
<organization>Huawei Technologies Co., Ltd.</organization>
<address> <address>
<email>huaimo.chen@huawei.com</email> <postal>
<street/>
<city>Boston</city>
<region>MA</region>
<code/>
<country>United States of America</country>
</postal>
<email>Huaimo.chen@futurewei.com</email>
</address> </address>
</author> </author>
<date month="12" year="2019"/>
<date year="2019" month="September"/> <area>RTG</area>
<workgroup>Multiprotocol Label Switching</workgroup>
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>fast reroute</keyword> <keyword>fast reroute</keyword>
<keyword>egress protection</keyword> <keyword>egress protection</keyword>
<keyword>local repair</keyword> <keyword>local repair</keyword>
<abstract pn="section-abstract">
<abstract> <t pn="section-abstract-1">
<t> This document specifies a fast reroute framework for protecting IP/MPLS s
This document specifies a fast reroute framework for protecting IP/MPLS s ervices and MPLS transport tunnels against egress node and egress link failures.
ervices and MPLS transport tunnels against egress node and egress link failures. For each type of egress failure, it defines the roles of Point of Local Repair
For each type of egress failure, it defines the roles of point of local repair (PLR), protector, and backup egress router and the procedures of establishing a
(PLR), protector, and backup egress router, and the procedures of establishing a bypass tunnel from a PLR to a protector. It describes the behaviors of these rou
bypass tunnel from a PLR to a protector. It describes the behaviors of these ro ters in handling an egress failure, including local repair on the PLR and contex
uters in handling an egress failure, including local repair on the PLR, and cont t-based forwarding on the protector. The framework can be used to develop egress
ext-based forwarding on the protector. The framework can be used to develop egre protection mechanisms to reduce traffic loss before global repair reacts to an
ss protection mechanisms to reduce traffic loss before global repair reacts to a egress failure and control-plane protocols converge on the topology changes due
n egress failure and control plane protocols converge on the topology changes du to the egress failure.
e to the egress failure.
</t> </t>
</abstract> </abstract>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<t pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
</t>
<t pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc8679" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t pn="section-boilerplate.2-1">
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent
="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-introduction">Introductio
n</xref></t>
</li>
<li pn="section-toc.1-1.2">
<t keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent
="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-specification-of-requirem
en">Specification of Requirements</xref></t>
</li>
<li pn="section-toc.1-1.3">
<t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent
="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-terminology">Terminology<
/xref></t>
</li>
<li pn="section-toc.1-1.4">
<t keepWithNext="true" pn="section-toc.1-1.4.1"><xref derivedContent
="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-requirements">Requirement
s</xref></t>
</li>
<li pn="section-toc.1-1.5">
<t keepWithNext="true" pn="section-toc.1-1.5.1"><xref derivedContent
="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-egress-node-protection">E
gress Node Protection</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.5.2">
<li pn="section-toc.1-1.5.2.1">
<t keepWithNext="true" pn="section-toc.1-1.5.2.1.1"><xref derive
dContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-reference-top
ology">Reference Topology</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2">
<t keepWithNext="true" pn="section-toc.1-1.5.2.2.1"><xref derive
dContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-egress-node-f
ailure-and-det">Egress Node Failure and Detection</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3">
<t keepWithNext="true" pn="section-toc.1-1.5.2.3.1"><xref derive
dContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-protector-and
-plr">Protector and PLR</xref></t>
</li>
<li pn="section-toc.1-1.5.2.4">
<t keepWithNext="true" pn="section-toc.1-1.5.2.4.1"><xref derive
dContent="5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-protected-egr
ess">Protected Egress</xref></t>
</li>
<li pn="section-toc.1-1.5.2.5">
<t keepWithNext="true" pn="section-toc.1-1.5.2.5.1"><xref derive
dContent="5.5" format="counter" sectionFormat="of" target="section-5.5"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-egress-protec
ted-tunnel-and">Egress-Protected Tunnel and Service</xref></t>
</li>
<li pn="section-toc.1-1.5.2.6">
<t keepWithNext="true" pn="section-toc.1-1.5.2.6.1"><xref derive
dContent="5.6" format="counter" sectionFormat="of" target="section-5.6"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-egress-protec
tion-bypass-tu">Egress-Protection Bypass Tunnel</xref></t>
</li>
<li pn="section-toc.1-1.5.2.7">
<t keepWithNext="true" pn="section-toc.1-1.5.2.7.1"><xref derive
dContent="5.7" format="counter" sectionFormat="of" target="section-5.7"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-context-id-co
ntext-label-an">Context ID, Context Label, and Context-Based Forwarding</xref></
t>
</li>
<li pn="section-toc.1-1.5.2.8">
<t keepWithNext="true" pn="section-toc.1-1.5.2.8.1"><xref derive
dContent="5.8" format="counter" sectionFormat="of" target="section-5.8"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-advertisement
-and-path-reso">Advertisement and Path Resolution for Context ID</xref></t>
</li>
<li pn="section-toc.1-1.5.2.9">
<t keepWithNext="true" pn="section-toc.1-1.5.2.9.1"><xref derive
dContent="5.9" format="counter" sectionFormat="of" target="section-5.9"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-egress-protec
tion-bypass-tun">Egress-Protection Bypass Tunnel Establishment</xref></t>
</li>
<li pn="section-toc.1-1.5.2.10">
<t keepWithNext="true" pn="section-toc.1-1.5.2.10.1"><xref deriv
edContent="5.10" format="counter" sectionFormat="of" target="section-5.10"/>. <x
ref derivedContent="" format="title" sectionFormat="of" target="name-local-repai
r-on-plr">Local Repair on PLR</xref></t>
</li>
<li pn="section-toc.1-1.5.2.11">
<t keepWithNext="true" pn="section-toc.1-1.5.2.11.1"><xref deriv
edContent="5.11" format="counter" sectionFormat="of" target="section-5.11"/>. <x
ref derivedContent="" format="title" sectionFormat="of" target="name-service-lab
el-distribution-">Service Label Distribution from Egress Router to Protector</xr
ef></t>
</li>
<li pn="section-toc.1-1.5.2.12">
<t keepWithNext="true" pn="section-toc.1-1.5.2.12.1"><xref deriv
edContent="5.12" format="counter" sectionFormat="of" target="section-5.12"/>. <x
ref derivedContent="" format="title" sectionFormat="of" target="name-centralized
-protector-mode">Centralized Protector Mode</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6">
<t keepWithNext="true" pn="section-toc.1-1.6.1"><xref derivedContent
="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-egress-link-protection">E
gress Link Protection</xref></t>
</li>
<li pn="section-toc.1-1.7">
<t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent
="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-global-repair">Global Rep
air</xref></t>
</li>
<li pn="section-toc.1-1.8">
<t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent
="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-operational-consideration
s">Operational Considerations</xref></t>
</li>
<li pn="section-toc.1-1.9">
<t keepWithNext="true" pn="section-toc.1-1.9.1"><xref derivedContent
="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-general-context-based-for
wa">General Context-Based Forwarding</xref></t>
</li>
<li pn="section-toc.1-1.10">
<t keepWithNext="true" pn="section-toc.1-1.10.1"><xref derivedConten
t="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedC
ontent="" format="title" sectionFormat="of" target="name-example-layer-3-vpn-egr
ess-">Example: Layer 3 VPN Egress Protection</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.10.2">
<li pn="section-toc.1-1.10.2.1">
<t keepWithNext="true" pn="section-toc.1-1.10.2.1.1"><xref deriv
edContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-egress-nod
e-protection-2">Egress Node Protection</xref></t>
</li>
<li pn="section-toc.1-1.10.2.2">
<t keepWithNext="true" pn="section-toc.1-1.10.2.2.1"><xref deriv
edContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-egress-lin
k-protection-2">Egress Link Protection</xref></t>
</li>
<li pn="section-toc.1-1.10.2.3">
<t keepWithNext="true" pn="section-toc.1-1.10.2.3.1"><xref deriv
edContent="10.3" format="counter" sectionFormat="of" target="section-10.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-global-rep
air-2">Global Repair</xref></t>
</li>
<li pn="section-toc.1-1.10.2.4">
<t keepWithNext="true" pn="section-toc.1-1.10.2.4.1"><xref deriv
edContent="10.4" format="counter" sectionFormat="of" target="section-10.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-other-mode
s-of-vpn-label-al">Other Modes of VPN Label Allocation</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.11">
<t keepWithNext="true" pn="section-toc.1-1.11.1"><xref derivedConten
t="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedC
ontent="" format="title" sectionFormat="of" target="name-iana-considerations">IA
NA Considerations</xref></t>
</li>
<li pn="section-toc.1-1.12">
<t keepWithNext="true" pn="section-toc.1-1.12.1"><xref derivedConten
t="12" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedC
ontent="" format="title" sectionFormat="of" target="name-security-considerations
">Security Considerations</xref></t>
</li>
<li pn="section-toc.1-1.13">
<t keepWithNext="true" pn="section-toc.1-1.13.1"><xref derivedConten
t="13" format="counter" sectionFormat="of" target="section-13"/>. <xref derivedC
ontent="" format="title" sectionFormat="of" target="name-references">References<
/xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.13.2">
<li pn="section-toc.1-1.13.2.1">
<t keepWithNext="true" pn="section-toc.1-1.13.2.1.1"><xref deriv
edContent="13.1" format="counter" sectionFormat="of" target="section-13.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-normative-
references">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.13.2.2">
<t keepWithNext="true" pn="section-toc.1-1.13.2.2.1"><xref deriv
edContent="13.2" format="counter" sectionFormat="of" target="section-13.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-informativ
e-references">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.14">
<t keepWithNext="true" pn="section-toc.1-1.14.1"><xref derivedConten
t="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derived
Content="" format="title" sectionFormat="of" target="name-acknowledgements">Ackn
owledgements</xref></t>
</li>
<li pn="section-toc.1-1.15">
<t keepWithNext="true" pn="section-toc.1-1.15.1"><xref derivedConten
t="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derived
Content="" format="title" sectionFormat="of" target="name-authors-addresses">Aut
hors' Addresses</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle>
<middle> <section anchor="intro" numbered="true" toc="include" removeInRFC="false" pn
="section-1">
<section anchor="intro" title="Introduction"> <name slugifiedName="name-introduction">Introduction</name>
<t> <t pn="section-1-1">
In MPLS networks, label switched paths (LSPs) are widely used as transpor In MPLS networks, Label Switched Paths (LSPs) are widely used as transpor
t tunnels to carry IP and MPLS services across MPLS domains. Examples of MPLS se t tunnels to carry IP and MPLS services across MPLS domains. Examples of MPLS se
rvices are layer-2 VPNs, layer-3 VPNs, hierarchical LSPs, and others. In general rvices are Layer 2 VPNs, Layer 3 VPNs, hierarchical LSPs, and others. In general
, a tunnel may carry multiple services of one or multiple types, if the tunnel s , a tunnel may carry multiple services of one or multiple types, if the tunnel s
atisfies both individual and aggregate requirements (e.g., CoS, QoS) of these se atisfies both individual and aggregate requirements (e.g., Class of Service (CoS
rvices. The egress router of the tunnel hosts the service instances of the servi ) and QoS) of these services. The egress router of the tunnel hosts the service
ces. An MPLS service instance forwards service packets via an egress link to the instances of the services. An MPLS service instance forwards service packets via
service destination, based on a service label. An IP service instance does the an egress link to the service destination, based on a service label. An IP serv
same based on a service IP address. The egress link is often called a PE-CE (pro ice instance does the same, based on an IP service address. The egress link is o
vider edge - customer edge) link or attachment circuit (AC). ften called a Provider Edge - Customer Edge (PE-CE) link or Attachment Circuit (
</t> AC).
</t>
<t> <t pn="section-1-2">
Today, local-repair-based fast reroute mechanisms (<xref Today, local-repair-based fast reroute mechanisms (see <xref target="RFC4
target="RFC4090"/>, <xref target="RFC5286"/>, <xref target="RFC7490"/>, and 090" format="default" sectionFormat="of" derivedContent="RFC4090"/>, <xref targe
<xref target="RFC7812"/>) have been widely deployed to protect MPLS tunnels agai t="RFC5286" format="default" sectionFormat="of" derivedContent="RFC5286"/>, <xre
nst transit link/node failures, with traffic restoration time in the order of te f target="RFC7490" format="default" sectionFormat="of" derivedContent="RFC7490"/
ns of milliseconds. Local repair refers to the scenario where the router upstrea >, and
m to an anticipated failure, a.k.a. PLR (point of local repair), pre-establishes <xref target="RFC7812" format="default" sectionFormat="of" derivedContent="RFC78
a bypass tunnel to the router downstream of the failure, a.k.a. MP (merge point 12"/>) have been widely deployed to protect MPLS tunnels against transit link/no
), pre-installs the forwarding state of the bypass tunnel in the data plane, and de failures, with traffic restoration time in the order of tens of milliseconds.
uses a rapid mechanism (e.g., link layer OAM, BFD, and others) to locally detec Local repair refers to the scenario where the router upstream to an anticipated
t the failure in the data plane. When the failure occurs, the PLR reroutes traff failure, a.k.a., PLR, pre-establishes a bypass tunnel to the router downstream
ic through the bypass tunnel to the MP, allowing the traffic to continue to flow of the failure, a.k.a., Merge Point (MP), pre-installs the forwarding state of t
to the tunnel's egress router. he bypass tunnel in the data plane, and uses a rapid mechanism (e.g., link-layer
</t> Operations, Administration, and Maintenance (OAM), Bidirectional Forwarding Det
ection (BFD), and others) to locally detect the failure in the data plane. When
<t> the failure occurs, the PLR reroutes traffic through the bypass tunnel to the MP
This document specifies a fast reroute framework for egress node and egre , allowing the traffic to continue to flow to the tunnel's egress router.
ss link protection. Similar to transit link/node protection, this framework also </t>
relies on a PLR to perform local failure detection and local repair. In egress <t pn="section-1-3">
node protection, the PLR is the penultimate-hop router of a tunnel. In egress li This document specifies a fast reroute framework for egress node and egre
nk protection, the PLR is the egress router of the tunnel. The framework further ss link protection. Similar to transit link/node protection, this framework also
uses a so-called "protector" to serve as the tailend of a bypass tunnel. The pr relies on a PLR to perform local failure detection and local repair. In egress
otector is a router that hosts "protection service instances" and has its own co node protection, the PLR is the penultimate hop router of a tunnel. In egress li
nnectivity or paths to service destinations. When a PLR does local repair, the p nk protection, the PLR is the egress router of the tunnel. The framework further
rotector performs "context label switching" for rerouted MPLS service packets an uses a so-called "protector" to serve as the tail end of a bypass tunnel. The p
d "context IP forwarding" for rerouted IP service packets, to allow the service rotector is a router that hosts "protection service instances" and has its own c
packets to continue to reach the service destinations. onnectivity or paths to service destinations. When a PLR does local repair, the
</t> protector performs "context label switching" for rerouted MPLS service packets a
nd "context IP forwarding" for rerouted IP service packets, to allow the service
<t> packets to continue to reach the service destinations.
This framework considers an egress node failure as a failure of a tunnel, </t>
and a failure of all the services carried by the tunnel, as service packets can <t pn="section-1-4">
no longer reach the service instances on the egress router. Therefore, the fram This framework considers an egress node failure as a failure of a tunnel
ework addresses egress node protection at both tunnel level and service level si and a failure of all the services carried by the tunnel as service packets that
multaneously. Likewise, the framework considers an egress link failure as a fail can no longer reach the service instances on the egress router. Therefore, the f
ure of all the services traversing the link, and addresses egress link protectio ramework addresses egress node protection at both the tunnel level and service l
n at the service level. evel, simultaneously. Likewise, the framework considers an egress link failure a
</t> s a failure of all the services traversing the link and addresses egress link pr
otection at the service level.
<t> </t>
This framework requires that the destination (a CE or site) of a service <t pn="section-1-5">
MUST be dual-homed or have dual paths to an MPLS network, via two MPLS edge rout This framework requires that the destination (a CE or site) of a service
ers. One of the routers is the egress router of the service's transport tunnel, <bcp14>MUST</bcp14> be dual-homed or have dual paths to an MPLS network, via two
and the other is a backup egress router which hosts a "backup service instance". MPLS edge routers. One of the routers is the egress router of the service's tra
In the "co-located" protector mode in this document, the backup egress router s nsport tunnel, and the other is a backup egress router that hosts a "backup serv
erves as the protector, and hence the backup service instance acts as the protec ice instance". In the "co-located" protector mode in this document, the backup e
tion service instance. In the "centralized" protector mode (<xref target="centra gress router serves as the protector; hence, the backup service instance acts as
lized" />), the protector and the backup egress router are decoupled, and the pr the protection service instance. In the "centralized" protector mode (<xref tar
otection service instance and the backup service instance are hosted separately get="centralized" format="default" sectionFormat="of" derivedContent="Section 5.
by the two routers. 12"/>), the protector and the backup egress router are decoupled, and the protec
</t> tion service instance and the backup service instance are hosted separately by t
he two routers.
<t> </t>
The framework is described by mainly referring to P2P (point-to-point) tu <t pn="section-1-6">
nnels. However, it is equally applicable to P2MP (point-to-multipoint), MP2P (mu The framework is described by mainly referring to point-to-point (P2P) tu
ltipoint-to-point), and MP2MP (multipoint-to-multipoint) tunnels, as the sub-LSP nnels. However, it is equally applicable to point-to-multipoint (P2MP), multipoi
s of these tunnels can be viewed as P2P tunnels. nt-to-point (MP2P), and multipoint-to-multipoint (MP2MP) tunnels, as the sub-LSP
</t> s of these tunnels can be viewed as P2P tunnels.
</t>
<t> <t pn="section-1-7">
The framework is a multi-service and multi-transport framework. It assume The framework is a multi-service and multi-transport framework. It assume
s a generic model where each service is comprised of a common set of components, s a generic model where each service is comprised of a common set of components,
including a service instance, a service label, a service label distribution pro including a service instance, a service label, a service label distribution pro
tocol, and an MPLS transport tunnel. The framework also assumes the service labe tocol, and an MPLS transport tunnel. The framework also assumes that the service
l to be downstream assigned, i.e., assigned by an egress router. Therefore, the label is downstream assigned, i.e., assigned by an egress router. Therefore, th
framework is generally applicable to most existing and future services. However, e framework is generally applicable to most existing and future services. Howeve
there are services with certain modes, where a protector is unable to pre-estab r, there are services with certain modes, where a protector is unable to pre-est
lish forwarding state for egress protection, or a PLR is not allowed to reroute ablish the forwarding state for egress protection, or a PLR is not allowed to re
traffic to other routers in order to avoid traffic duplication, e.g., the broadc route traffic to other routers in order to avoid traffic duplication, e.g., the
ast, multicast, and unknown unicast traffic in VPLS and EVPN. These cases are le broadcast, multicast, and unknown unicast traffic in Virtual Private LAN Service
ft for future study. Services which use upstream-assigned service labels are als (VPLS) and Ethernet VPN (EVPN). These cases are left for future study. Services
o out of scope of this document and left for future study. that use upstream-assigned service labels are also out of scope of this documen
</t> t and left for future study.
</t>
<t> <t pn="section-1-8">
The framework does not require extensions for the existing signaling and The framework does not require extensions for the existing signaling and
label distribution protocols (e.g., RSVP, LDP, BGP, etc.) of MPLS tunnels. It label distribution protocols (e.g., RSVP, LDP, BGP, etc.) of MPLS tunnels. It
assumes transport tunnels and bypass tunnels to be established by using the assumes that transport tunnels and bypass tunnels are to be established by using the
generic procedures provided by the protocols. On the other hand, it does not generic procedures provided by the protocols. On the other hand, it does not
preclude extensions to the protocols which may facilitate the procedures. One preclude extensions to the protocols that may facilitate the procedures. One
example of such extension is <xref target="RFC8400"/>. The framework does see th example of such extension is <xref target="RFC8400" format="default" sectionForm
e need for extensions of IGPs and service label distribution protocols in some p at="of" derivedContent="RFC8400"/>. The framework does see the need for extensio
rocedures, particularly for supporting protection establishment and context labe ns of IGPs and service label distribution protocols in some procedures, particul
l switching. This document provides guidelines for these extensions, but leaves arly for supporting protection establishment and context label switching. This d
the specific details to separate documents. ocument provides guidelines for these extensions, but it leaves the specific det
</t> ails to separate documents.
</t>
<t> <t pn="section-1-9">
The framework is intended to complement control-plane convergence and The framework is intended to complement control-plane convergence and
global repair. Control-plane convergence relies on control protocols to react global repair. Control-plane convergence relies on control protocols to react
on the topology changes due to a failure. Global repair relies an ingress on the topology changes due to a failure. Global repair relies on an ingress
router to remotely detect a failure and switch traffic to an alternative router to remotely detect a failure and switch traffic to an alternative
path. An example of global repair is the BGP Prefix Independent Convergence path. An example of global repair is the BGP prefix independent convergence
mechanism <xref target="BGP-PIC"/> for BGP established services. Compared with t mechanism <xref target="I-D.ietf-rtgwg-bgp-pic" format="default" sectionFormat="
hese mechanisms, this framework is considered as faster in traffic restoration, of" derivedContent="BGP-PIC"/> for BGP-established services. Compared with these
due to the nature of local failure detection and local repair. It is RECOMMENDED mechanisms, this framework is considered faster in traffic restoration, due to
that the framework be used in conjunction with control-plane convergence or glo the nature of local failure detection and local repair. It is <bcp14>RECOMMENDED
bal repair, in order to take the advantages of both approaches. That is, the fra </bcp14> that the framework be used in conjunction with control-plane convergenc
mework provides fast and temporary repair, while control-plane convergence or gl e or global repair, in order to take the advantages of both approaches. That is,
obal repair provides ultimate and permanent repair. the framework provides fast and temporary repair, while control-plane convergen
</t> ce or global repair provides ultimate and permanent repair.
</section> </t>
</section>
<section title="Specification of Requirements"> <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <name slugifiedName="name-specification-of-requiremen">Specification of Re
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this quirements</name>
document are to be interpreted as described in <xref target="RFC2119"/> <t pn="section-2-1"> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NO
and <xref target="RFC8174"/>.</t> T</bcp14>",
</section> "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
<section anchor="terms" title="Terminology"> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
<t> to be interpreted as described in BCP 14 <xref target="RFC2119" format="defa
Egress router - A router at the egress endpoint of a tunnel. It hosts ser ult" sectionFormat="of" derivedContent="RFC2119"/>
vice instances for all the services carried by the tunnel, and has connectivity <xref target="RFC8174" format="default" sectionFormat="of" derivedConten
with the destinations of the services. t="RFC8174"/> when, and only when, they appear in all capitals,
</t> as shown here. </t>
</section>
<t> <section anchor="terms" numbered="true" toc="include" removeInRFC="false" pn
Egress node failure - A failure of an egress router. ="section-3">
</t> <name slugifiedName="name-terminology">Terminology</name>
<dl newline="true" spacing="normal" pn="section-3-1">
<t> <dt pn="section-3-1.1">Egress router:</dt>
Egress link failure - A failure of the egress link (e.g., PE-CE link, att <dd pn="section-3-1.2">A router at the egress endpoint of a tunnel. It h
achment circuit) of a service. osts service instances for all the services carried by the tunnel and has connec
</t> tivity with the destinations of the services.
</dd>
<t> <dt pn="section-3-1.3">Egress node failure:</dt>
Egress failure - An egress node failure or an egress link failure. <dd pn="section-3-1.4">A failure of an egress router.
</t> </dd>
<dt pn="section-3-1.5">
<t> Egress link failure:</dt>
Egress-protected tunnel - A tunnel whose egress router is protected by a <dd pn="section-3-1.6">A failure of the egress link (e.g., PE-CE link, a
mechanism according to this framework. The egress router is hence called a prote ttachment circuit) of a service.
cted egress router. </dd>
</t> <dt pn="section-3-1.7">
Egress failure:</dt>
<t> <dd pn="section-3-1.8"> An egress node failure or an egress link failure
Egress-protected service - An IP or MPLS service which is carried by an e .
gress-protected tunnel, and hence protected by a mechanism according to this fra </dd>
mework. <dt pn="section-3-1.9">
</t> Egress-protected tunnel:</dt>
<dd pn="section-3-1.10">A tunnel whose egress router is protected by a m
<t> echanism according to this framework. The egress router is hence called a protec
Backup egress router - Given an egress-protected tunnel and its egress ro ted egress router.
uter, this is another router which has connectivity with all or a subset of the </dd>
destinations of the egress-protected services carried by the egress-protected tu <dt pn="section-3-1.11">
nnel. Egress-protected service:</dt>
</t> <dd pn="section-3-1.12">An IP or MPLS service that is carried by an egre
ss-protected tunnel and hence protected by a mechanism according to this framewo
<t> rk.
Backup service instance - A service instance which is hosted by a backup </dd>
egress router, and corresponding to an egress-protected service on a protected e <dt pn="section-3-1.13">
gress router. Backup egress router:</dt>
</t> <dd pn="section-3-1.14">Given an egress-protected tunnel and its egress
router, this is another router that has connectivity with all or a subset of the
<t> destinations of the egress-protected services carried by the egress-protected t
Protector - A role acted by a router as an alternate of a protected egres unnel.
s router, to handle service packets in the event of an egress failure. A protect </dd>
or may be physically co-located with or decoupled from a backup egress router, d <dt pn="section-3-1.15">
epending on the co-located or centralized protector mode. Backup service instance:</dt>
</t> <dd pn="section-3-1.16">A service instance that is hosted by a backup eg
ress router and corresponds to an egress-protected service on a protected egress
<t> router.
Protection service instance - A service instance hosted by a protector, c </dd>
orresponding to the service instance of an egress-protected service on a protect <dt pn="section-3-1.17">
ed egress router. A protection service instance is a backup service instance, if Protector:</dt>
the protector is co-located with a backup egress router. <dd pn="section-3-1.18">A role acted by a router as an alternate of a pr
</t> otected egress router, to handle service packets in the event of an egress failu
re. A protector may be physically co-located with or decoupled from a backup egr
<t> ess router, depending on the co-located or centralized protector mode.
PLR - A router at the point of local repair. In egress node protection, i </dd>
t is the penultimate-hop router on an egress-protected tunnel. In egress link pr <dt pn="section-3-1.19">
otection, it is the egress router of the egress-protected tunnel. Protection service instance:</dt>
</t> <dd pn="section-3-1.20">A service instance hosted by a protector that co
rresponds to the service instance of an egress-protected service on a protected
<t> egress router. A protection service instance is a backup service instance, if th
Protected egress {E, P} - A virtual node consisting of an ordered pair of e protector is co-located with a backup egress router.
egress router E and protector P. It serves as the virtual destination of an egr </dd>
ess-protected tunnel, and as the virtual location of the egress-protected servic <dt pn="section-3-1.21">
es carried by the tunnel. PLR:</dt>
</t> <dd pn="section-3-1.22"> A router at the point of local repair. In egres
s node protection, it is the penultimate hop router on an egress-protected tunne
<t> l. In egress link protection, it is the egress router of the egress-protected tu
Context identifier (ID) - A globally unique IP address assigned to a prot nnel.
ected egress {E, P}. </dd>
</t> <dt pn="section-3-1.23">
Protected egress {E, P}:</dt>
<t> <dd pn="section-3-1.24"> A virtual node consisting of an ordered pair of
Context label - A non-reserved label assigned to a context ID by a protec egress router E and protector P. It serves as the virtual destination of an egr
tor. ess-protected tunnel and as the virtual location of the egress-protected service
</t> s carried by the tunnel.
</dd>
<t> <dt pn="section-3-1.25">
Egress-protection bypass tunnel - A tunnel used to reroute service packet Context identifier (ID):</dt>
s around an egress failure. <dd pn="section-3-1.26">A globally unique IP address assigned to a prote
</t> cted egress {E, P}.
</dd>
<t> <dt pn="section-3-1.27">
Co-located protector mode - The scenario where a protector and a backup e Context label:</dt>
gress router are co-located as one router, and hence each backup service instanc <dd pn="section-3-1.28">A non-reserved label assigned to a context ID by
e serves as a protection service instance. a protector.
</t> </dd>
<dt pn="section-3-1.29">
<t> Egress-protection bypass tunnel:</dt>
Centralized protector mode - The scenario where a protector is a dedicate <dd pn="section-3-1.30">A tunnel used to reroute service packets around
d router, and is decoupled from backup egress routers. an egress failure.
</t> </dd>
<dt pn="section-3-1.31">
<t> Co-located protector mode:</dt>
Context label switching - Label switching performed by a protector, in th <dd pn="section-3-1.32">The scenario where a protector and a backup egre
e label space of an egress router indicated by a context label. ss router are co-located as one router; hence, each backup service instance serv
</t> es as a protection service instance.
</dd>
<t> <dt pn="section-3-1.33">
Context IP forwarding - IP forwarding performed by a protector, in the IP Centralized protector mode:</dt>
address space of an egress router indicated by a context label. <dd pn="section-3-1.34">The scenario where a protector is a dedicated ro
</t> uter and is decoupled from backup egress routers.
</dd>
</section> <dt pn="section-3-1.35">
Context label switching:</dt>
<section anchor="req" title="Requirements"> <dd pn="section-3-1.36">Label switching performed by a protector in the
<t> label space of an egress router indicated by a context label.
</dd>
<dt pn="section-3-1.37">
Context IP forwarding:</dt>
<dd pn="section-3-1.38">IP forwarding performed by a protector in the IP
address space of an egress router indicated by a context label.
</dd>
</dl>
</section>
<section anchor="req" numbered="true" toc="include" removeInRFC="false" pn="
section-4">
<name slugifiedName="name-requirements">Requirements</name>
<t pn="section-4-1">
This document considers the following as the design requirements of this egress protection framework. This document considers the following as the design requirements of this egress protection framework.
</t> </t>
<ul spacing="normal" bare="false" empty="false" pn="section-4-2">
<t> <li pn="section-4-2.1">
<list style ="symbols"> The framework must support P2P tunnels. It should equally support P2MP
<t> , MP2P, and MP2MP tunnels, by treating each sub-LSP as a P2P tunnel.
The framework must support P2P tunnels. It should equally support P2MP </li>
, MP2P and MP2MP tunnels, by treating each sub-LSP as a P2P tunnel. <li pn="section-4-2.2">
</t> The framework must support multi-service and multi-transport networks.
It must accommodate existing and future signaling and label-distribution protoc
<t> ols of tunnels and bypass tunnels, including RSVP, LDP, BGP, IGP, Segment Routin
The framework must support multi-service and multi-transport networks. g, and others. It must also accommodate existing and future IP/MPLS services, in
It must accommodate existing and future signaling and label-distribution protoc cluding Layer 2 VPNs, Layer 3 VPNs, hierarchical LSP, and others. It <bcp14>MUST
ols of tunnels and bypass tunnels, including RSVP, LDP, BGP, IGP, segment routin </bcp14> provide a general solution for networks where different types of servic
g, and others. It must also accommodate existing and future IP/MPLS services, in es and tunnels co-exist.
cluding layer-2 VPNs, layer-3 VPNs, hierarchical LSP, and others. It MUST provid </li>
e a general solution for networks where different types of services and tunnels <li pn="section-4-2.3">
co-exist. The framework must consider minimizing disruption during deployment. I
</t> t should only involve routers close to the egress and be transparent to ingress
routers and other transit routers.
<t> </li>
The framework must consider minimizing disruption during deployment. I <li pn="section-4-2.4">
t should only involve routers close to egress, and be transparent to ingress rou In egress node protection, for scalability and performance reasons, a
ters and other transit routers. PLR must be agnostic to services and service labels. It must maintain bypass tun
</t> nels and bypass forwarding state on a per-transport-tunnel basis rather than on
a per-service-destination or per-service-label basis. It should also support byp
<t> ass tunnel sharing between transport tunnels.
In egress node protection, for scalability and performance reasons, a </li>
PLR must be agnostic to services and service labels. It must maintain bypass tun <li pn="section-4-2.5">
nels and bypass forwarding state on a per-transport-tunnel basis, rather than on
a per-service-destination or per-service-label basis. It should also support by
pass tunnel sharing between transport tunnels.
</t>
<t>
A PLR must be able to use its local visibility or information of routi ng or TE topology to compute or resolve a path for a bypass tunnel. A PLR must be able to use its local visibility or information of routi ng or TE topology to compute or resolve a path for a bypass tunnel.
</t> </li>
<li pn="section-4-2.6">
<t> A protector must be able to perform context label switching for rerout
A protector must be able to perform context label switching for rerout ed MPLS service packets, based on a service label(s) assigned by an egress route
ed MPLS service packets, based on service label(s) assigned by an egress router. r. It must be able to perform context IP forwarding for rerouted IP service pack
It must be able to perform context IP forwarding for rerouted IP service packet ets, in the public or private IP address space used by an egress router.
s, in the public or private IP address space used by an egress router. </li>
</t> <li pn="section-4-2.7">
<t>
The framework must be able to work seamlessly with transit link/node p rotection mechanisms to achieve end-to-end coverage. The framework must be able to work seamlessly with transit link/node p rotection mechanisms to achieve end-to-end coverage.
</t> </li>
<li pn="section-4-2.8">
<t> The framework must be able to work in conjunction with global repair a
The framework must be able to work in conjunction with global repair a nd control-plane convergence.
nd control plane convergence. </li>
</t> </ul>
</list> </section>
</t> <section anchor="egress-node-protection" numbered="true" toc="include" remov
</section> eInRFC="false" pn="section-5">
<name slugifiedName="name-egress-node-protection">Egress Node Protection</
<section anchor="egress-node-protection" title = "Egress node protection"> name>
<section anchor="ref-topo" numbered="true" toc="include" removeInRFC="fals
<section anchor="ref-topo" title = "Reference topology"> e" pn="section-5.1">
<t> <name slugifiedName="name-reference-topology">Reference Topology</name>
<t pn="section-5.1-1">
This document refers to the following topology when describing the proce dures of egress node protection. This document refers to the following topology when describing the proce dures of egress node protection.
</t> </t>
<figure anchor="Figure-1" align="left" suppress-title="false" pn="figure
<figure align="center" anchor="Figure-1"> -1">
<preamble></preamble> <artwork align="center" name="" type="ascii-art" alt="" pn="section-5.
1-2.1">
<artwork align="center"><![CDATA[
services 1, ..., N services 1, ..., N
=====================================> tunnel =====================================&gt; tunnel
I ------ R1 ------- PLR --------------- E ---- I ------ R1 ------- PLR --------------- E ----
ingress penultimate-hop egress \ ingress penultimate hop egress \
| . (primary \ | . (primary \
| . service \ | . service \
| . instances) \ | . instances ) \
| . \ | . \
| . \ service | . \ service
| . destinations | . destinations
| . / (CEs, sites) | . / (CEs, sites)
| . / | . /
| . bypass / | . bypass /
| . tunnel / | . tunnel /
| . / | . /
| ............... / | ............... /
R2 --------------- P ---- R2 --------------- P ----
protector protector
(protection (protection
service service
instances) instances) </artwork>
</figure>
]]></artwork> </section>
<postamble></postamble> <section anchor="egress-node-failure" numbered="true" toc="include" remove
</figure> InRFC="false" pn="section-5.2">
<name slugifiedName="name-egress-node-failure-and-det">Egress Node Failu
</section> re and Detection</name>
<t pn="section-5.2-1">
<section anchor="egress-node-failure" title = "Egress node failure and dete
ction">
<t>
An egress node failure refers to the failure of an MPLS tunnel's egress router. At the service level, it is also a service instance failure for each IP/ MPLS service carried by the tunnel. An egress node failure refers to the failure of an MPLS tunnel's egress router. At the service level, it is also a service instance failure for each IP/ MPLS service carried by the tunnel.
</t> </t>
<t pn="section-5.2-2">
<t> An egress node failure can be detected by an adjacent router (i.e., PLR
An egress node failure can be detected by an adjacent router (i.e., PLR in this framework) through a node liveness detection mechanism or a mechanism ba
in this framework) through a node liveness detection mechanism, or a mechanism b sed on a collective failure of all the links to that node. The mechanisms <bcp14
ased on a collective failure of all the links to that node. The mechanisms MUST >MUST</bcp14> be reasonably fast, i.e., faster than control-plane failure detect
be reasonably fast, i.e., faster than control plane failure detection and remote ion and remote failure detection. Otherwise, local repair will not be able to pr
failure detection. Otherwise, local repair will not be able to provide much ben ovide much benefit compared to control-plane convergence or global repair. In ge
efit compared to control plane convergence or global repair. In general, the spe neral, the speed, accuracy, and reliability of a failure detection mechanism are
ed, accuracy, and reliability of a failure detection mechanism are the key facto the key factors to decide its applicability in egress node protection. This doc
rs to decide its applicability in egress node protection. This document provides ument provides the following guidelines for network operators to choose a proper
the following guidelines for network operators to choose a proper type of prote type of protection on a PLR.
ction on a PLR. </t>
</t> <ul spacing="normal" bare="false" empty="false" pn="section-5.2-3">
<t> <li pn="section-5.2-3.1">
<list style ="symbols"> If the PLR has a mechanism to detect and differentiate a link failur
<t> e (of the link between the PLR and the egress node) and an egress node failure,
If the PLR has a mechanism to detect and differentiate a link failur it <bcp14>SHOULD</bcp14> set up both link protection and egress node protection
e (of the link between the PLR and the egress node) and an egress node failure, and trigger one and only one protection upon a corresponding failure.
it SHOULD set up both link protection and egress node protection, and trigger on </li>
e and only one protection upon a corresponding failure. <li pn="section-5.2-3.2">
</t> <t pn="section-5.2-3.2.1">
If the PLR has a fast mechanism to detect a link failure and an egre
<t> ss node failure, but it cannot distinguish them, or if the PLR has a fast mechan
If the PLR has a fast mechanism to detect a link failure and an egre ism to detect a link failure only, but not an egress node failure, the PLR has t
ss node failure, but cannot distinguish them; or, if the PLR has a fast mechanis wo options:
m to detect a link failure only, but not an egress node failure, the PLR has two
options:
<list style ="numbers">
<t>
It MAY set up link protection only, and leave the egress node fa
ilure to be handled by global repair and control plane convergence.
</t>
<t>
It MAY set up egress node protection only, and treat a link fail
ure as a trigger for the egress node protection. The assumption is that treating
a link failure as an egress node failure MUST NOT have a negative impact on ser
vices. Otherwise, it SHOULD adopt the previous option.
</t>
</list>
</t>
</list>
</t>
</section>
<section anchor="protector" title = "Protector and PLR">
<t>
A router is assigned to the "protector" role to protect a tunnel and the
services carried by the tunnel against an egress node failure. The protector is
responsible for hosting a protection service instance for each protected servic
e, serving as the tailend of a bypass tunnel, and performing context label switc
hing and/or context IP forwarding for rerouted service packets.
</t>
<t> </t>
<ol spacing="normal" type="1" start="1" pn="section-5.2-3.2.2">
<li pn="section-5.2-3.2.2.1" derivedCounter="1.">
It <bcp14>MAY</bcp14> set up link protection only and leave the
egress node failure to be handled by global repair and control-plane convergence
.
</li>
<li pn="section-5.2-3.2.2.2" derivedCounter="2.">
It <bcp14>MAY</bcp14> set up egress node protection only and tre
at a link failure as a trigger for the egress node protection. The assumption is
that treating a link failure as an egress node failure <bcp14>MUST NOT</bcp14>
have a negative impact on services. Otherwise, it <bcp14>SHOULD</bcp14> adopt th
e previous option.
</li>
</ol>
</li>
</ul>
</section>
<section anchor="protector" numbered="true" toc="include" removeInRFC="fal
se" pn="section-5.3">
<name slugifiedName="name-protector-and-plr">Protector and PLR</name>
<t pn="section-5.3-1">
A router is assigned to the "protector" role to protect a tunnel and the
services carried by the tunnel against an egress node failure. The protector is
responsible for hosting a protection service instance for each protected servic
e, serving as the tail end of a bypass tunnel, and performing context label swit
ching and/or context IP forwarding for rerouted service packets.
</t>
<t pn="section-5.3-2">
A tunnel is protected by only one protector. Multiple tunnels to a given egress router may be protected by a common protector or different protectors. A protector may protect multiple tunnels with a common egress router or different egress routers. A tunnel is protected by only one protector. Multiple tunnels to a given egress router may be protected by a common protector or different protectors. A protector may protect multiple tunnels with a common egress router or different egress routers.
</t> </t>
<t pn="section-5.3-3">
<t> For each tunnel, its penultimate hop router acts as a PLR. The PLR pre-e
For each tunnel, its penultimate-hop router acts as a PLR. The PLR pre-e stablishes a bypass tunnel to the protector and pre-installs bypass forwarding s
stablishes a bypass tunnel to the protector, and pre-installs bypass forwarding tate in the data plane. Upon detection of an egress node failure, the PLR rerout
state in the data plane. Upon detection of an egress node failure, the PLR rerou es all the service packets received on the tunnel through the bypass tunnel to t
tes all the service packets received on the tunnel though the bypass tunnel to t he protector. For MPLS service packets, the PLR keeps service labels intact in t
he protector. For MPLS service packets, the PLR keeps service labels intact in t he packets. In turn, the protector forwards the service packets towards the ulti
he packets. The protector in turn forwards the service packets towards the ultim mate service destinations. Specifically, it performs context label switching for
ate service destinations. Specifically, it performs context label switching for MPLS service packets, based on the service labels assigned by the protected egr
MPLS service packets, based on the service labels assigned by the protected egre ess router; it performs context IP forwarding for IP service packets, based on t
ss router; it performs context IP forwarding for IP service packets, based on th heir destination addresses.
eir destination addresses. </t>
</t> <t pn="section-5.3-4">
The protector <bcp14>MUST</bcp14> have its own connectivity with each se
<t> rvice destination, via a direct link or a multi-hop path, which <bcp14>MUST NOT<
The protector MUST have its own connectivity with each service destinati /bcp14> traverse the protected egress router or be affected by the egress node f
on, via a direct link or a multi-hop path, which MUST NOT traverse the protected ailure. This also means that each service destination <bcp14>MUST</bcp14> be dua
egress router or be affected by the egress node failure. This also means that e l-homed or have dual paths to the egress router and a backup egress router that
ach service destination MUST be dual-homed or have dual paths to the egress rout may serve as the protector. Each protection service instance on the protector re
er and a backup egress router which may serve as the protector. Each protection lies on such connectivity to set up forwarding state for context label switching
service instance on the protector relies on such connectivity to set up forwardi and context IP forwarding.
ng state for context label switching and context IP forwarding. </t>
</t> </section>
</section> <section anchor="protected-egress" numbered="true" toc="include" removeInR
FC="false" pn="section-5.4">
<section anchor="protected-egress" title = "Protected egress"> <name slugifiedName="name-protected-egress">Protected Egress</name>
<t> <t pn="section-5.4-1">
This document introduces the notion of "protected egress" as a virtual n This document introduces the notion of "protected egress" as a virtual n
ode consisting of the egress router E of a tunnel and a protector P. It is denot ode consisting of the egress router E of a tunnel and a protector P. It is denot
ed by an ordered pair of {E, P}, indicating the primary-and-protector relationsh ed by an ordered pair of {E, P}, indicating the primary-and-protector relationsh
ip between the two routers. It serves as the virtual destination of the tunnel, ip between the two routers. It serves as the virtual destination of the tunnel a
and the virtual location of service instances for the services carried by the tu nd the virtual location of service instances for the services carried by the tun
nnel. The tunnel and services are considered as being "associated" with the prot nel. The tunnel and services are considered as being "associated" with the prote
ected egress {E, P}. cted egress {E, P}.
</t> </t>
<t pn="section-5.4-2">
<t> A given egress router E may be the tail end of multiple tunnels. In gener
A given egress router E may be the tailend of multiple tunnels. In genera al, the tunnels may be protected by multiple protectors, e.g., P1, P2, and so on
l, the tunnels may be protected by multiple protectors, e.g., P1, P2, and so on, , with each Pi protecting a subset of the tunnels. Thus, these routers form mult
with each Pi protecting a subset of the tunnels. Thus, these routers form multi iple protected egresses, i.e., {E, P1}, {E, P2}, and so on. Each tunnel is assoc
ple protected egresses, i.e., {E, P1}, {E, P2}, and so on. Each tunnel is associ iated with one and only one protected egress {E, Pi}. All the services carried
ated with one and only one protected egress {E, Pi}. All the services carried by by the tunnel are then automatically associated with the protected egress {E, Pi
the tunnel are then automatically associated with the protected egress {E, Pi}. }. Conversely, a service associated with a protected egress {E, Pi} <bcp14>MUST<
Conversely, a service associated with a protected egress {E, Pi} MUST be carrie /bcp14> be carried by a tunnel associated with the protected egress {E, Pi}. Thi
d by a tunnel associated with the protected egress {E, Pi}. This mapping MUST be s mapping <bcp14>MUST</bcp14> be ensured by the ingress router of the tunnel and
ensured by the ingress router of the tunnel and the service (<xref target="ep-t the service (<xref target="ep-tunnel-service" format="default" sectionFormat="o
unnel-service" />). f" derivedContent="Section 5.5"/>).
</t> </t>
<t pn="section-5.4-3">
<t> The two routers X and Y may be protectors for each other. In this case,
Two routers X and Y may be protectors for each other. In this case, they they form two distinct protected egresses: {X, Y} and {Y, X}.
form two distinct protected egresses {X, Y} and {Y, X}. </t>
</t> </section>
<section anchor="ep-tunnel-service" numbered="true" toc="include" removeIn
</section> RFC="false" pn="section-5.5">
<name slugifiedName="name-egress-protected-tunnel-and">Egress-Protected
<section anchor="ep-tunnel-service" title = "Egress-protected tunnel and se Tunnel and Service</name>
rvice"> <t pn="section-5.5-1">
<t> A tunnel, which is associated with a protected egress {E, P}, is called
A tunnel, which is associated with a protected egress {E, P}, is called an egress-protected tunnel. It is associated with one and only one protected egr
an egress-protected tunnel. It is associated with one and only one protected egr ess {E, P}. Multiple egress-protected tunnels may be associated with a given pr
ess {E, P}. Multiple egress-protected tunnels may be associated with a given pro otected egress {E, P}. In this case, they share the common egress router and pr
tected egress {E, P}. In this case, they share the common egress router and prot otector, but they may or may not share a common ingress router or a common PLR (
ector, but may or may not share a common ingress router, or a common PLR (i.e., i.e., penultimate hop router).
penultimate-hop router). </t>
</t> <t pn="section-5.5-2">
An egress-protected tunnel is considered as logically "destined" for its
<t> protected egress {E, P}. Its path <bcp14>MUST</bcp14> be resolved and establis
An egress-protected tunnel is considered as logically "destined" for its hed with E as the physical tail end.
protected egress {E, P}. Its path MUST be resolved and established with E as th </t>
e physical tailend. <t pn="section-5.5-3">
</t> A service, which is associated with a protected egress {E, P}, is called
an egress-protected service. Egress router E hosts the primary instance of the
<t> service, and protector P hosts the protection instance of the service.
A service, which is associated with a protected egress {E, P}, is called </t>
an egress-protected service. The egress router E hosts the primary instance of <t pn="section-5.5-4">
the service, and the protector P hosts the protection instance of the service. An egress-protected service is associated with one and only one protecte
</t> d egress {E, P}. Multiple egress-protected services may be associated with a gi
ven protected egress {E, P}. In this case, these services share the common egre
<t> ss router and protector, but they may or may not be carried by a common egress-p
An egress-protected service is associated with one and only one protecte rotected tunnel or a common ingress router.
d egress {E, P}. Multiple egress-protected services may be associated with a giv </t>
en protected egress {E, P}. In this case, these services share the common egress <t pn="section-5.5-5">
router and protector, but may or may not be carried by a common egress-protecte An egress-protected service <bcp14>MUST</bcp14> be mapped to an egress-p
d tunnel or a common ingress router. rotected tunnel by its ingress router, based on the common protected egress {E,
</t> P} of the service and the tunnel. This is achieved by introducing the notion of
a "context ID" for a protected egress {E, P}, as described in <xref target="cid"
<t> format="default" sectionFormat="of" derivedContent="Section 5.7"/>.
An egress-protected service MUST be mapped to an egress-protected tunnel </t>
by its ingress router, based on the common protected egress {E, P} of the servi </section>
ce and the tunnel. This is achieved by introducing the notion of "context ID" fo <section anchor="ep-bypass" numbered="true" toc="include" removeInRFC="fal
r protected egress {E, P}, as described in (<xref target="cid" />). se" pn="section-5.6">
</t> <name slugifiedName="name-egress-protection-bypass-tu">Egress-Protection
</section> Bypass Tunnel</name>
<t pn="section-5.6-1">
<section anchor="ep-bypass" title = "Egress-protection bypass tunnel"> An egress-protected tunnel destined for a protected egress {E, P} <bcp14
>MUST</bcp14> have a bypass tunnel from its PLR to protector P. This bypass tunn
<t> el is called an egress-protection bypass tunnel. The bypass tunnel is considered
An egress-protected tunnel destined for a protected egress {E, P} MUST h as logically "destined" for the protected egress {E, P}. Due to its bypass natu
ave a bypass tunnel from its PLR to the protector P. This bypass tunnel is calle re, it <bcp14>MUST</bcp14> be established with P as the physical tail end and E
d an egress-protection bypass tunnel. The bypass tunnel is considered as logical as the node to avoid.
ly "destined" for the protected egress {E, P}. Due to its bypass nature, it MUST
be established with P as the physical tailend and E as the node to avoid. The b
ypass tunnel MUST have the property that it MUST NOT be affected by the topology
change caused by an egress node failure.
</t>
<t> The bypass tunnel <bcp14>MUST NOT</bcp14> be affected by the topology change cau
sed by an egress node failure; thus, it <bcp14>MUST</bcp14> contain a property t
hat protects it from this scenario.
</t>
<t pn="section-5.6-2">
An egress-protection bypass tunnel is associated with one and only one p rotected egress {E, P}. A PLR may share an egress-protection bypass tunnel for m ultiple egress-protected tunnels associated with a common protected egress {E, P }. An egress-protection bypass tunnel is associated with one and only one p rotected egress {E, P}. A PLR may share an egress-protection bypass tunnel for m ultiple egress-protected tunnels associated with a common protected egress {E, P }.
</t> </t>
</section>
</section> <section anchor="cid" numbered="true" toc="include" removeInRFC="false" pn
="section-5.7">
<section anchor="cid" title = "Context ID, context label, and context-based <name slugifiedName="name-context-id-context-label-an">Context ID, Conte
forwarding"> xt Label, and Context-Based Forwarding</name>
<t pn="section-5.7-1">
<t> In this framework, a globally unique IPv4 or IPv6 address is assigned as
In this framework, a globally unique IPv4 or IPv6 address is assigned to the identifier of the protected egress {E, P}. It is called a "context ID" due
a protected egress {E, P} as the identifier of the protected egress {E, P}. It to its specific usage in context label switching and context IP forwarding on th
is called a "context ID" due to its specific usage in context label switching an e protector. It is an IP address that is logically owned by both the egress rout
d context IP forwarding on the protector. It is an IP address that is logically er and the protector. For the egress router, it indicates the protector. For the
owned by both the egress router and the protector. For the egress router, it ind protector, it indicates the egress router, particularly the egress router's for
icates the protector. For the protector, it indicates the egress router, particu warding context. For other routers in the network, it is an address reachable vi
larly the egress router's forwarding context. For other routers in the network, a both the egress router and the protector (<xref target="adv" format="default"
it is an address reachable via both the egress router and the protector (<xref t sectionFormat="of" derivedContent="Section 5.8"/>), similar to an anycast addres
arget="adv" />), similar to an anycast address. s.
</t> </t>
<t pn="section-5.7-2">
<t> The main purpose of a context ID is to coordinate the ingress router, eg
The main purpose of a context ID is to coordinate ingress router, egress ress router, PLR, and protector to establish egress protection. The procedures a
router, PLR and protector to establish egress protection. The procedures are de re described below, given an egress-protected service associated with a protecte
scribed below, given an egress-protected service associated with a protected egr d egress {E, P} with a context ID.
ess {E, P} with context ID. </t>
</t> <ul spacing="normal" bare="false" empty="false" pn="section-5.7-3">
<t> <li pn="section-5.7-3.1">
<list style ="symbols"> If the service is an MPLS service, when E distributes a service labe
<t> l binding message to the ingress router, E attaches the context ID to the messag
If the service is an MPLS service, when E distributes a service labe e. If the service is an IP service, when E advertises the service destination ad
l binding message to the ingress router, E attaches the context ID to the messag dress to the ingress router, E attaches the context ID to the advertisement mess
e. If the service is an IP service, when E advertises the service destination ad age. The service protocol chooses how the context ID is encoded in the messages.
dress to the ingress router, E attaches the context ID to the advertisement mess A protocol extension of a "context ID" object may be needed, if there is no exi
age. How the context ID is encoded in the messages is a choice of the service pr sting mechanism for this purpose.
otocol. A protocol extension of a "context ID" object may be needed, if there is </li>
no existing mechanism for this purpose. <li pn="section-5.7-3.2">
</t>
<t>
The ingress router uses the service's context ID as the destination to establish or resolve an egress-protected tunnel. The ingress router then maps the service to the tunnel for transportation. The semantics of the context ID i s transparent to the ingress router. The ingress router only treats the context ID as an IP address of E, in the same manner as establishing or resolving a regu lar transport tunnel. The ingress router uses the service's context ID as the destination to establish or resolve an egress-protected tunnel. The ingress router then maps the service to the tunnel for transportation. The semantics of the context ID i s transparent to the ingress router. The ingress router only treats the context ID as an IP address of E, in the same manner as establishing or resolving a regu lar transport tunnel.
</t> </li>
<t> <li pn="section-5.7-3.3">
The context ID is conveyed to the PLR by the signaling protocol of t The context ID is conveyed to the PLR by the signaling protocol of t
he egress-protected tunnel, or learned by the PLR via an IGP (i.e., OSPF or ISIS he egress-protected tunnel or learned by the PLR via an IGP (i.e., OSPF or IS-IS
) or a topology-driven label distribution protocol (e.g., LDP). The PLR uses the ) or a topology-driven label distribution protocol (e.g., LDP). The PLR uses the
context ID as destination to establish or resolve an egress-protection bypass t context ID as the destination to establish or resolve an egress-protection bypa
unnel to P while avoiding E. ss tunnel to P while avoiding E.
</t> </li>
<t> <li pn="section-5.7-3.4">
P maintains a dedicated label space and a dedicated IP address space for E. They are referred to as "E's label space" and "E's IP address space", re spectively. P uses the context ID to identify the label space and IP address spa ce. P maintains a dedicated label space and a dedicated IP address space for E. They are referred to as "E's label space" and "E's IP address space", re spectively. P uses the context ID to identify the label space and IP address spa ce.
</t> </li>
<t> <li pn="section-5.7-3.5">
If the service is an MPLS service, E also distributes the service la If the service is an MPLS service, E also distributes the service la
bel binding message to P. This is the same label binding message that E advertis bel binding message to P. This is the same label binding message that E advertis
es to the ingress router, which includes the context ID. Based on the context ID es to the ingress router, which includes the context ID. Based on the context ID
, P installs the service label in an MPLS forwarding table corresponding to E's , P installs the service label in an MPLS forwarding table corresponding to E's
label space. If the service is an IP service, P installs an IP route in an IP fo label space. If the service is an IP service, P installs an IP route in an IP fo
rwarding table corresponding to E's IP address space. In either case, the protec rwarding table corresponding to E's IP address space. In either case, the protec
tion service instance on P constructs forwarding state for the label route or IP tion service instance on P constructs the forwarding state for the label route o
route based on P's own connectivity with the service's destination. r IP route based on P's own connectivity with the service's destination.
</t> </li>
<t> <li pn="section-5.7-3.6">
P assigns a non-reserved label to the context ID. In the data plane, this label represents the context ID and indicates E's label space and IP addre ss space. Therefore, it is called a "context label". P assigns a non-reserved label to the context ID. In the data plane, this label represents the context ID and indicates E's label space and IP addre ss space. Therefore, it is called a "context label".
</t> </li>
<t> <li pn="section-5.7-3.7">
The PLR may establish the egress-protection bypass tunnel to P in se The PLR may establish the egress-protection bypass tunnel to P in se
veral manners. If the bypass tunnel is established by RSVP, the PLR signals the veral manners. If the bypass tunnel is established by RSVP, the PLR signals the
bypass tunnel with the context ID as destination, and P binds the context label bypass tunnel with the context ID as the destination, and P binds the context la
to the bypass tunnel. If the bypass tunnel is established by LDP, P advertises t bel to the bypass tunnel. If the bypass tunnel is established by LDP, P advertis
he context label for the context ID as an IP prefix FEC. If the bypass tunnel is es the context label for the context ID as an IP prefix Forwarding
established by the PLR in a hierarchical manner, the PLR treats the context lab Equivalence Class (FEC). If the bypass tunnel is established by the PLR in a
el as a one-hop LSP over a regular bypass tunnel to P (e.g., a bypass tunnel to hierarchical manner, the PLR treats the context label as a one-hop LSP over a re
P's loopback IP address). If the bypass tunnel is constructed by using segment r gular bypass tunnel to P (e.g., a bypass tunnel to P's loopback IP address). If
outing, the bypass tunnel is represented by a stack of SID labels with the conte the bypass tunnel is constructed by using Segment Routing, the bypass tunnel is
xt label as the inner-most SID label (<xref target="bypass-estb" />). In any cas represented by a stack of Segment Identifier (SID) labels with the context label
e, the bypass tunnel is a ultimate-hop-popping (UHP) tunnel whose incoming label as the inner-most SID label (<xref target="bypass-estb" format="default" sectio
on P is the context label. nFormat="of" derivedContent="Section 5.9"/>). In any case, the bypass tunnel is
</t> an ultimate hop-popping (UHP) tunnel whose incoming label on P is the context la
<t> bel.
During local repair, all the service packets received by P on the by </li>
pass tunnel have the context label as the top label. P first pops the context la <li pn="section-5.7-3.8">
bel. For an MPLS service packet, P further looks up the service label in E's lab During local repair, all the service packets received by P on the by
el space indicated by the context label. Such kind of forwarding is called conte pass tunnel have the context label as the top label. P first pops the context la
xt label switching. For an IP service packet, P looks up the IP destination addr bel. For an MPLS service packet, P looks up the service label in E's label space
ess in E's IP address space indicated by the context label. Such kind of forward indicated by the context label. Such kind of forwarding is called context label
ing is called context IP forwarding. switching. For an IP service packet, P looks up the IP destination address in E
</t> 's IP address space indicated by the context label. Such kind of forwarding is c
</list> alled context IP forwarding.
</t> </li>
</section> </ul>
</section>
<section anchor="adv" title = "Advertisement and path resolution for contex <section anchor="adv" numbered="true" toc="include" removeInRFC="false" pn
t ID"> ="section-5.8">
<name slugifiedName="name-advertisement-and-path-reso">Advertisement and
<t> Path Resolution for Context ID</name>
Path resolution and computation for a context ID are done on ingress rou <t pn="section-5.8-1">
ters for egress-protected tunnels, and on PLRs for egress-protection bypass tunn Path resolution and computation for a context ID are done on ingress rou
els. Given a protected egress {E, P} and its context ID, E and P MUST coordinate ters for egress-protected tunnels and on PLRs for egress-protection bypass tunne
on the reachability of the context ID in the routing domain and the TE domain. ls. Given a protected egress {E, P} and its context ID, E and P <bcp14>MUST</bcp
The context ID MUST be advertised in such a manner that all egress-protected tun 14> coordinate on the reachability of the context ID in the routing domain and t
nels MUST have E as tailend, and all egress-protection bypass tunnels MUST have he TE domain. The context ID <bcp14>MUST</bcp14> be advertised in such a manner
P as tailend while avoiding E. that all egress-protected tunnels <bcp14>MUST</bcp14> have E as the tail end, an
</t> d all egress-protection bypass tunnels <bcp14>MUST</bcp14> have P as the tail en
d while avoiding E.
<t> </t>
<t pn="section-5.8-2">
This document suggests three approaches: This document suggests three approaches:
</t> </t>
<ul empty="true" bare="false" spacing="normal" pn="section-5.8-3">
<t> <li pn="section-5.8-3.1">
<list style ="numbers"> <ol spacing="normal" type="1" start="1" pn="section-5.8-3.1.1">
<t> <li pn="section-5.8-3.1.1.1" derivedCounter="1.">
The first approach is called "proxy mode". It requires E and P, but The first approach is called "proxy mode". It requires E and P, but
not the PLR, to have the knowledge of the egress protection schema. E and P adve not the PLR, to have the knowledge of the egress protection schema. E and P adve
rtise the context ID as a virtual proxy node (i.e., a logical node) connected to rtise the context ID as a virtual proxy node (i.e., a logical node) connected to
the two routers, with the link between the proxy node and E having more prefera the two routers, with the link between the proxy node and E having more prefera
ble IGP and TE metrics than the link between the proxy node and P. Therefore, al ble IGP and TE metrics than the link between the proxy node and P. Therefore, al
l egress-protected tunnels destined for the context ID will automatically follow l egress-protected tunnels destined for the context ID will automatically follow
the IGP or TE paths to E. Each PLR will no longer view itself as a penultimate- the IGP or TE paths to E. Each PLR will no longer view itself as a penultimate
hop, but rather two hops away from the proxy node, via E. The PLR will be able t hop but rather as two hops away from the proxy node, via E. The PLR will be able
o find a bypass path via P to the proxy node, while the bypass tunnel is actuall to find a bypass path via P to the proxy node, while the bypass tunnel is actua
y be terminated by P. lly terminated by P.
</t> </li>
<li pn="section-5.8-3.1.1.2" derivedCounter="2.">
<t>
The second approach is called "alias mode". It requires P and the The second approach is called "alias mode". It requires P and the
PLR, but not E, to have the knowledge of the egress protection schema. E simply PLR, but not E, to have the knowledge of the egress protection schema. E simply
advertises the context ID as an IP address. P advertises the context ID and the advertises the context ID as an IP address. P advertises the context ID and the
context label by using a "context ID label binding" advertisement. In both context label by using a "context ID label binding" advertisement. In both
routing domain and TE domain, the context ID is only reachable via the routing domain and TE domain, the context ID is only reachable via
E. Therefore, all egress-protected tunnels destined for the context ID will E. Therefore, all egress-protected tunnels destined for the context ID will
have E as tailend. Based on the "context ID label binding" advertisement, the have E as the tail end. Based on the "context ID label binding" advertisement, t
PLR can establish an egress-protection bypass tunnel in several manners (<xref he
target="bypass-estb"/>). The "context ID label binding" advertisement is PLR can establish an egress-protection bypass tunnel in several manners (<xref t
defined as IGP mirroring context segment in <xref target="RFC8402"/> and <xref t arget="bypass-estb" format="default" sectionFormat="of" derivedContent="Section
arget="RFCYYYY"/>. These IGP extensions are generic in nature, and hence can be 5.9"/>). The "context ID label binding" advertisement is
used for egress protection purposes. It is RECOMMENDED that a similar advertisem defined as the IGP Mirroring Context segment in <xref target="RFC8402" format="d
ent be defined for OSPF as well. efault" sectionFormat="of" derivedContent="RFC8402"/> and <xref target="RFC8667"
</t> format="default" sectionFormat="of" derivedContent="RFC8667"/>. These IGP exten
sions are generic in nature and hence can be used for egress protection purposes
<t> . It is <bcp14>RECOMMENDED</bcp14> that a similar advertisement be defined for O
The third approach is called "stub link mode". In this mode, both E SPF as well.
and P advertise the context ID as a link to a stub network, essentially modellin </li>
g the context ID as an anycast IP address owned by the two routers. E, P and the <li pn="section-5.8-3.1.1.3" derivedCounter="3.">
PLR do not need to have the knowledge of the egress protection schema. The corr The third approach is called "stub link mode". In this mode, both E
ectness of the egress-protected tunnels and the bypass tunnels relies on the pat and P advertise the context ID as a link to a stub network, essentially modeling
h computations for the anycast IP address performed by the ingress routers and P the context ID as an anycast IP address owned by the two routers. E, P, and the
LR. Therefore, care MUST be taken for the applicability of this approach to a ne PLR do not need to have the knowledge of the egress protection schema. The corr
twork. ectness of the egress-protected tunnels and the bypass tunnels relies on the pat
</t> h computations for the anycast IP address performed by the ingress routers and P
</list> LR. Therefore, care <bcp14>MUST</bcp14> be taken for the applicability of this a
</t> pproach to a network.
</li>
<t> </ol>
This framework considers the above approaches as technically equal, and </li>
the feasibility of each approach in a given network as dependent on the topology </ul>
, manageability, and available protocols of the network. For a given context ID, <t pn="section-5.8-4">
all relevant routers, including primary PE, protector, and PLR, MUST support an This framework considers the above approaches as technically equal and t
d agree on the chosen approach. The coordination between these routers can be ac he feasibility of each approach in a given network as dependent on the topology,
hieved by configuration. manageability, and available protocols of the network. For a given context ID,
</t> all relevant routers, including the primary PE, protector, and PLR, <bcp14>MUST<
/bcp14> support and agree on the chosen approach. The coordination between these
<t> routers can be achieved by configuration.
In a scenario where an egress-protected tunnel is an inter-area or inter </t>
-AS tunnel, its associated context ID MUST be propagated by IGP or BGP from the <t pn="section-5.8-5">
original area or AS to the area or AS of the ingress router. The propagation pro In a scenario where an egress-protected tunnel is an inter-area or inter
cess of the context ID SHOULD be the same as that of an IP address in an inter-a -Autonomous-System (inter-AS) tunnel, its associated context ID <bcp14>MUST</bcp
rea or inter-AS environment. 14> be propagated by IGP or BGP from the original area or AS to the area or AS o
</t> f the ingress router. The propagation process of the context ID <bcp14>SHOULD</b
</section> cp14> be the same as that of an IP address in an inter-area or inter-AS environm
ent.
<section anchor="bypass-estb" title = "Egress-protection bypass tunnel esta </t>
blishment"> </section>
<t> <section anchor="bypass-estb" numbered="true" toc="include" removeInRFC="f
A PLR MUST know the context ID of a protected egress {E, P} in order to alse" pn="section-5.9">
establish an egress-protection bypass tunnel. The information is obtained from t <name slugifiedName="name-egress-protection-bypass-tun">Egress-Protectio
he signaling or label distribution protocol of the egress-protected tunnel. The n Bypass Tunnel Establishment</name>
PLR may or may not need to have the knowledge of the egress protection schema. A <t pn="section-5.9-1">
ll it does is to set up a bypass tunnel to a context ID while avoiding the next- A PLR <bcp14>MUST</bcp14> know the context ID of a protected egress {E,
hop router (i.e., egress router). This is achievable by using a constraint-based P} in order to establish an egress-protection bypass tunnel. The information is
computation algorithm similar to those commonly used for traffic engineering pa obtained from the signaling or label distribution protocol of the egress-protect
ths and loop-free alternate (LFA) paths. Since the context ID is advertised in t ed tunnel. The PLR may or may not need to have the knowledge of the egress-prote
he routing domain and the TE domain by IGP according to <xref target="adv" />, t ction schema. All it does is set up a bypass tunnel to a context ID while avoidi
he PLR is able to resolve or establish such a bypass path with the protector as ng the next-hop router (i.e., egress router). This is achievable by using a cons
tailend. In the case of proxy mode, the PLR may do so in the same manner as tran traint-based computation algorithm similar to those commonly used for traffic en
sit node protection. gineering paths and Loop-Free Alternate (LFA) paths. Since the context ID is adv
</t> ertised in the routing domain and in the TE domain by IGP according to <xref tar
get="adv" format="default" sectionFormat="of" derivedContent="Section 5.8"/>, th
<t> e PLR is able to resolve or establish such a bypass path with the protector as t
he tail end. In the case of proxy mode, the PLR may do so in the same manner as
transit node protection.
</t>
<t pn="section-5.9-2">
An egress-protection bypass tunnel may be established via several method s: An egress-protection bypass tunnel may be established via several method s:
</t> </t>
<ul empty="true" bare="false" spacing="normal" pn="section-5.9-3">
<t> <li pn="section-5.9-3.1">
(1) It may be established by a signaling protocol (e.g., RSVP), with the <ol spacing="normal" type="1" start="1" pn="section-5.9-3.1.1">
context ID as destination. The protector binds the context label to the bypass <li pn="section-5.9-3.1.1.1" derivedCounter="1.">It may be establi
tunnel. shed by a signaling protocol (e.g., RSVP), with the context ID as the destinatio
</t> n. The protector binds the context label to the bypass tunnel.
</li>
<t> <li pn="section-5.9-3.1.1.2" derivedCounter="2."> It may be formed
(2) It may be formed by a topology driven protocol (e.g., LDP with vario by a topology-driven protocol (e.g., LDP with various LFA mechanisms). The prot
us LFA mechanisms). The protector advertises the context ID as an IP prefix FEC, ector advertises the context ID as an IP prefix FEC, with the context label boun
with the context label bound to it. d to it.
</t> </li>
<li pn="section-5.9-3.1.1.3" derivedCounter="3.">It may be constru
<t> cted as a hierarchical tunnel. When the protector uses the alias mode (<xref tar
(3) It may be constructed as a hierarchical tunnel. When the protector u get="adv" format="default" sectionFormat="of" derivedContent="Section 5.8"/>), t
ses the alias mode (<xref target="adv" />), the PLR will have the knowledge of t he PLR will have the knowledge of the context ID, context label, and protector (
he context ID, context label, and protector (i.e., the advertiser). The PLR can i.e., the advertiser). The PLR can then establish the bypass tunnel in a hierarc
then establish the bypass tunnel in a hierarchical manner, with the context labe hical manner, with the context label as a one-hop LSP over a regular bypass tunn
l as a one-hop LSP over a regular bypass tunnel to the protector's IP address (e el to the protector's IP address (e.g., loopback address). This regular bypass t
.g., loopback address). This regular bypass tunnel may be established by RSVP, L unnel may be established by RSVP, LDP, Segment Routing, or another protocol.
DP, segment routing, or another protocol. </li>
</t> </ol>
</li>
</section> </ul>
</section>
<section anchor="local-repair" title = "Local repair on PLR"> <section anchor="local-repair" numbered="true" toc="include" removeInRFC="
<t> false" pn="section-5.10">
In this framework, a PLR is agnostic to services and service labels. Thi <name slugifiedName="name-local-repair-on-plr">Local Repair on PLR</name
s obviates the need to maintain bypass forwarding state on a per-service basis, >
and allows bypass tunnel sharing between egress-protected tunnels. The PLR may s <t pn="section-5.10-1">
hare an egress-protection bypass tunnel for multiple egress-protected tunnels as In this framework, a PLR is agnostic to services and service labels. Thi
sociated with a common protected egress {E, P}. During local repair, the PLR rer s obviates the need to maintain bypass forwarding state on a per-service basis a
outes all service packets received on the egress-protected tunnels to the egress nd allows bypass tunnel sharing between egress-protected tunnels. The PLR may sh
-protection bypass tunnel. Service labels remain intact in MPLS service packets. are an egress-protection bypass tunnel for multiple egress-protected tunnels ass
</t> ociated with a common protected egress {E, P}. During local repair, the PLR rero
utes all service packets received on the egress-protected tunnels to the egress-
<t> protection bypass tunnel. Service labels remain intact in MPLS service packets.
Label operation performed by the PLR depends on the bypass tunnel's char </t>
acteristics. If the bypass tunnel is a single level tunnel, the rerouting will i <t pn="section-5.10-2">
nvolve swapping the incoming label of an egress-protected tunnel to the outgoing Label operation performed by the PLR depends on the bypass tunnel's char
label of the bypass tunnel. If the bypass tunnel is a hierarchical tunnel, the acteristics. If the bypass tunnel is a single level tunnel, the rerouting will i
rerouting will involve swapping the incoming label of an egress-protected tunnel nvolve swapping the incoming label of an egress-protected tunnel to the outgoing
to a context label, and pushing the outgoing label of a regular bypass tunnel. label of the bypass tunnel. If the bypass tunnel is a hierarchical tunnel, the
If the bypass tunnel is constructed by segment routing, the rerouting will invol rerouting will involve swapping the incoming label of an egress-protected tunnel
ve swapping the incoming label of an egress-protected tunnel to a context label, to a context label and pushing the outgoing label of a regular bypass tunnel. I
and pushing the stack of SID labels of the bypass tunnel. f the bypass tunnel is constructed by Segment Routing, the rerouting will involv
</t> e swapping the incoming label of an egress-protected tunnel to a context label a
nd pushing the stack of SID labels of the bypass tunnel.
</section> </t>
</section>
<section anchor="upstream-label-distrib" title = "Service label distributio <section anchor="upstream-label-distrib" numbered="true" toc="include" rem
n from egress router to protector"> oveInRFC="false" pn="section-5.11">
<name slugifiedName="name-service-label-distribution-">Service Label Dis
<t> tribution from Egress Router to Protector</name>
When a protector receives a rerouted MPLS service packet, it performs co <t pn="section-5.11-1">
ntext label switching based on the packet's service label which is assigned by t When a protector receives a rerouted MPLS service packet, it performs co
he corresponding egress router. In order to achieve this, the protector MUST mai ntext label switching based on the packet's service label, which is assigned by
ntain the labels of egress-protected services in dedicated label spaces on a per the corresponding egress router. In order to achieve this, the protector <bcp14>
protected egress {E, P} basis, i.e., one label space for each egress router tha MUST</bcp14> maintain the labels of egress-protected services in dedicated label
t it protects. spaces on a per-protected-egress {E, P} basis, i.e., one label space for each e
</t> gress router that it protects.
</t>
<t> <t pn="section-5.11-2">
Also, there MUST be a service label distribution protocol session betwee Also, there <bcp14>MUST</bcp14> be a service label distribution protocol
n each egress router and the protector. Through this protocol, the protector lea session between each egress router and the protector. Through this protocol, th
rns the label binding of each egress-protected service. This is the same label b e protector learns the label binding of each egress-protected service. This is t
inding that the egress router advertises to the service's ingress router, which he same label binding that the egress router advertises to the service's ingress
includes a context ID. The corresponding protection service instance on the prot router, which includes a context ID. The corresponding protection service insta
ector recognizes the service, and resolves forwarding state based on its own con nce on the protector recognizes the service and resolves forwarding state based
nectivity with the service's destination. It then installs the service label wit on its own connectivity with the service's destination. It then installs the ser
h the forwarding state in the label space of the egress router, which is indicat vice label with the forwarding state in the label space of the egress router, wh
ed by the context ID (i.e., context label). ich is indicated by the context ID (i.e., context label).
</t> </t>
<t pn="section-5.11-3">
<t>
Different service protocols may use different mechanisms for such kind Different service protocols may use different mechanisms for such kind
of label distribution. Specific extensions may be needed on a per-protocol of label distribution. Specific extensions may be needed on a per-protocol
basis or per-service-type basis. The details of the extensions should be or per-service-type basis. The details of the extensions should be
specified in separate documents. As an example, <xref target="RFC8104"/> specifi specified in separate documents. As an example, the LDP extensions for pseudowir
es the LDP extensions for pseudowire services. e services are specified in <xref target="RFC8104" format="default" sectionForma
</t> t="of" derivedContent="RFC8104"/>.
</t>
</section> </section>
<section anchor="centralized" numbered="true" toc="include" removeInRFC="f
<section anchor="centralized" title = "Centralized protector mode"> alse" pn="section-5.12">
<name slugifiedName="name-centralized-protector-mode">Centralized Protec
<t> tor Mode</name>
In this framework, it is assumed that the service destination of an egre <t pn="section-5.12-1">
ss-protected service MUST be dual-homed to two edge routers of an MPLS network. In this framework, it is assumed that the service destination of an egre
One of them is the protected egress router, and the other is a backup egress rou ss-protected service <bcp14>MUST</bcp14> be dual-homed to two edge routers of an
ter. So far in this document, the discussion has been focusing on the scenario w MPLS network. One of them is the protected egress router, and the other is a ba
here a protector and a backup egress router are co-located as one router. Theref ckup egress router. So far in this document, the focus of discussion has been on
ore, the number of protectors in a network is equal to the number of backup egre the scenario where a protector and a backup egress router are co-located as one
ss routers. As another scenario, a network may assign a small number of routers router. Therefore, the number of protectors in a network is equal to the number
to serve as dedicated protectors, each protecting a subset of egress routers. Th of backup egress routers. As another scenario, a network may assign a small num
ese protectors are called centralized protectors. ber of routers to serve as dedicated protectors, each protecting a subset of egr
</t> ess routers. These protectors are called centralized protectors.
</t>
<t> <t pn="section-5.12-2">
Topologically, a centralized protector may be decoupled from all backup egress routers, or it may be co-located with one backup egress router while deco upled from the other backup egress routers. The procedures in this section assum e that a protector and a backup egress router are decoupled. Topologically, a centralized protector may be decoupled from all backup egress routers, or it may be co-located with one backup egress router while deco upled from the other backup egress routers. The procedures in this section assum e that a protector and a backup egress router are decoupled.
</t> </t>
<figure anchor="Figure-2" align="left" suppress-title="false" pn="figure
<figure align="center" anchor="Figure-2"> -2">
<preamble></preamble> <artwork align="center" name="" type="ascii-art" alt="" pn="section-5.
12-3.1">
<artwork align="center"><![CDATA[
services 1, ..., N services 1, ..., N
=====================================> tunnel =====================================&gt; tunnel
I ------ R1 ------- PLR --------------- E ---- I ------ R1 ------- PLR --------------- E ----
ingress penultimate-hop egress \ ingress penultimate hop egress \
| . (primary \ | . (primary \
| . service \ | . service \
| . instances) \ | . instances) \
| . \ | . \
| . bypass \ service | . bypass \ service
R2 . tunnel destinations R2 . tunnel destinations
| . / (CEs, sites) | . / (CEs, sites)
| . / | . /
| . / | . /
| . / | . /
| . tunnel / | . tunnel /
| =============> / | =============&gt; /
P ---------------- E' --- P ---------------- E' ---
protector backup egress protector backup egress
(protection (backup (protection (backup
service service service service
instances) instances) instances) instances) </artwork>
</figure>
]]></artwork> <t pn="section-5.12-4">
<postamble></postamble> Like a co-located protector, a centralized protector hosts protection se
</figure> rvice instances, receives rerouted service packets from PLRs, and performs conte
xt label switching and/or context IP forwarding. For each service, instead of se
<t> nding service packets directly to the service destination, the protector <bcp14>
Like a co-located protector, a centralized protector hosts protection se MUST</bcp14> send them via another transport tunnel to the corresponding backup
rvice instances, receives rerouted service packets from PLRs, and performs conte service instance on a backup egress router. The backup service instance in turn
xt label switching and/or context IP forwarding. For each service, instead of se forwards the service packets to the service destination. Specifically, if the se
nding service packets directly to the service destination, the protector MUST se rvice is an MPLS service, the protector <bcp14>MUST</bcp14> swap the service lab
nd them via another transport tunnel to the corresponding backup service instanc el in each received service packet to the label of the backup service advertised
e on a backup egress router. The backup service instance in turn forwards the se by the backup egress router, and then push the label (or label stack) of the tr
rvice packets to the service destination. Specifically, if the service is an MPL ansport tunnel.
S service, the protector MUST swap the service label in each received service pa </t>
cket to the label of the backup service advertised by the backup egress router, <t pn="section-5.12-5">
and then push the label (or label stack) of the transport tunnel. In order for a centralized protector to map an egress-protected MPLS ser
</t> vice to a service hosted on a backup egress router, there <bcp14>MUST</bcp14> be
a service label distribution protocol session between the backup egress router
<t> and the protector. Through this session, the backup egress router advertises the
In order for a centralized protector to map an egress-protected MPLS ser service label of the backup service, attached with the FEC of the egress-protec
vice to a service hosted on a backup egress router, there MUST be a service labe ted service and the context ID of the protected egress {E, P}. Based on this inf
l distribution protocol session between the backup egress router and the protect ormation, the protector associates the egress-protected service with the backup
or. Through this session, the backup egress router advertises the service label service, resolves or establishes a transport tunnel to the backup egress router,
of the backup service, attached with the FEC of the egress-protected service and and sets up forwarding state for the label of the egress-protected service in t
the context ID of the protected egress {E, P}. Based on this information, the p he label space of the egress router.
rotector associates the egress-protected service with the backup service, resolv </t>
es or establishes a transport tunnel to the backup egress router, and sets up fo <t pn="section-5.12-6">
rwarding state for the label of the egress-protected service in the label space The service label that the backup egress router advertises to the protec
of the egress router. tor can be the same as the label that the backup egress router advertises to the
</t> ingress router(s), if and only if the forwarding state of the label does not di
rect service packets towards the protected egress router. Otherwise, the label <
<t> bcp14>MUST NOT</bcp14> be used for egress protection, because it would create a
The service label which the backup egress router advertises to the prote loop for the service packets. In this case, the backup egress router <bcp14>MUST
ctor can be the same as the label which the backup egress router advertises to t </bcp14> advertise a unique service label for egress protection and set up the f
he ingress router(s), if and only if the forwarding state of the label does not orwarding state of the label to use the backup egress router's own connectivity
direct service packets towards the protected egress router. Otherwise, the label with the service destination.
MUST NOT be used for egress protection, because it would create a loop for the </t>
service packets. In this case, the backup egress router MUST advertise a unique </section>
service label for egress protection, and set up the forwarding state of the labe </section>
l to use the backup egress router's own connectivity with the service destinatio <section anchor="link-protection" numbered="true" toc="include" removeInRFC=
n. "false" pn="section-6">
</t> <name slugifiedName="name-egress-link-protection">Egress Link Protection</
name>
</section> <t pn="section-6-1">
</section> Egress link protection is achievable through procedures similar to that o
f egress node protection. In normal situations, an egress router forwards servic
<section anchor="link-protection" title = "Egress link protection"> e packets to a service destination based on a service label, whose forwarding st
ate points to an egress link. In egress link protection, the egress router acts
<t> as the PLR and performs local failure detection and local repair. Specifically,
Egress link protection is achievable through procedures similar to that o the egress router pre-establishes an egress-protection bypass tunnel to a protec
f egress node protection. In normal situations, an egress router forwards servic tor and sets up the bypass forwarding state for the service label to point to th
e packets to a service destination based on a service label, whose forwarding st e bypass tunnel. During local repair, the egress router reroutes service packets
ate points to an egress link. In egress link protection, the egress router acts via the bypass tunnel to the protector. The protector in turn forwards the pack
as the PLR, and performs local failure detection and local repair. Specifically, ets to the service destination (in the co-located protector mode, as shown in <x
the egress router pre-establishes an egress-protection bypass tunnel to a prote ref target="Figure-3" format="default" sectionFormat="of" derivedContent="Figure
ctor, and sets up the bypass forwarding state for the service label to point to 3"/>) or forwards the packets to a backup egress router (in the centralized pro
the bypass tunnel. During local repair, the egress router reroutes service packe tector mode, as shown in <xref target="Figure-4" format="default" sectionFormat=
ts via the bypass tunnel to the protector. The protector in turn forwards the pa "of" derivedContent="Figure 4"/>).
ckets to the service destination (in the co-located protector mode, as shown in </t>
Figure 3), or forwards the packets to a backup egress router (in the centralized <figure anchor="Figure-3" align="left" suppress-title="false" pn="figure-3
protector mode, as shown in Figure 4). ">
</t> <artwork align="center" name="" type="ascii-art" alt="" pn="section-6-2.
1">
<figure align="center" anchor="Figure-3">
<preamble></preamble>
<artwork align="center"><![CDATA[
service service
=====================================> tunnel =====================================&gt; tunnel
I ------ R1 ------- R2 --------------- E ---- I ------ R1 ------- R2 --------------- E ----
ingress | ............. egress \ ingress | ............. egress \
| . PLR \ | . PLR \
| . (primary \ | . (primary \
| . service \ | . service \
| . instance) \ | . instance) \
| . \ | . \
| . bypass service | . bypass service
| . tunnel destination | . tunnel destination
| . / (CE, site) | . / (CE, site)
| . / | . /
| . / | . /
| . / | . /
| . / | . /
| ............... / | ............... /
R3 --------------- P ---- R3 --------------- P ----
protector protector
(protection (protection
service service
instance) instance) </artwork>
]]></artwork> </figure>
<postamble></postamble> <figure anchor="Figure-4" align="left" suppress-title="false" pn="figure-4
</figure> ">
<artwork align="center" name="" type="ascii-art" alt="" pn="section-6-3.
<figure align="center" anchor="Figure-4"> 1">
<preamble></preamble>
<artwork align="center"><![CDATA[
service service
=====================================> tunnel =====================================&gt; tunnel
I ------ R1 ------- R2 --------------- E ---- I ------ R1 ------- R2 --------------- E ----
ingress | ............. egress \ ingress | ............. egress \
| . PLR \ | . PLR \
| . (primary \ | . (primary \
| . service \ | . service \
| . instance) \ | . instance) \
| . \ | . \
| . bypass service | . bypass service
| . tunnel destination | . tunnel destination
| . / (CE, site) | . / (CE, site)
| . / | . /
| . / | . /
| . / | . /
| . tunnel / | . tunnel /
| =============> / | =============&gt; /
R3 --------------- P ---- R3 --------------- P ----
protector backup egress protector backup egress
(protection (backup (protection (backup
service service service service
instance) instance) instance) instance) </artwork>
</figure>
]]></artwork> <t pn="section-6-4">
<postamble></postamble> There are two approaches for setting up the bypass forwarding state on t
</figure> he egress router, depending on whether the egress router knows the service label
allocated by the backup egress router. The difference is that one approach requ
<t> ires the protector to perform context label switching, and the other one does no
There are two approaches to set up the bypass forwarding state on the eg t. Both approaches are equally supported by this framework.
ress router, depending on whether the egress router knows the service label allo </t>
cated by the backup egress router. The difference is that one approach requires <ul empty="true" spacing="normal" bare="false" pn="section-6-5">
the protector to perform context label switching, and the other one does not. Bo <li pn="section-6-5.1">
th approaches are equally supported by this framework. <ol spacing="normal" type="1" start="1" pn="section-6-5.1.1">
</t> <li pn="section-6-5.1.1.1" derivedCounter="1.">The first approach ap
plies when the egress router does not know the service label allocated by the ba
<t> ckup egress router. In this case, the egress router sets up the bypass forwardin
<list> g state as a label push with the outgoing label of the egress-protection bypass
<t> tunnel. Rerouted packets will have the egress router's service label intact. The
(1) The first approach applies when the egress router does not know th refore, the protector <bcp14>MUST</bcp14> perform context label switching, and t
e service label allocated by the backup egress router. In this case, the egress he bypass tunnel <bcp14>MUST</bcp14> be destined for the context ID of the prote
router sets up the bypass forwarding state as a label push with the outgoing lab cted egress {E, P} and established as described in <xref target="bypass-estb" fo
el of the egress-protection bypass tunnel. Rerouted packets will have the egress rmat="default" sectionFormat="of" derivedContent="Section 5.9"/>. This approach
router's service label intact. Therefore, the protector MUST perform context la is consistent with egress node protection. Hence, a protector can serve in egres
bel switching, and the bypass tunnel MUST be destined for the context ID of the s node protection and egress link protection in a consistent manner, and both th
protected egress {E, P} and established as described in <xref target="bypass-est e co-located protector mode and the centralized protector mode are supported (se
b" />. This approach is consistent with egress node protection. Hence, a protect e Figures <xref target="Figure-3" format="counter" sectionFormat="of" derivedCon
or can serve in egress node protection and egress link protection in a consisten tent="3"/> and <xref target="Figure-4" format="counter" sectionFormat="of" deriv
t manner, and both the co-located protector mode and the centralized protector m edContent="4"/>).
ode are supported (Figure 3 and Figure 4). </li>
</t> <li pn="section-6-5.1.1.2" derivedCounter="2."> The second approach
applies when the egress router knows the service label allocated by the backup e
<t> gress router, via a label distribution protocol session. In this case, the backu
(2) The second approach applies when the egress router knows the servic p egress router serves as the protector for egress link protection, regardless o
e label allocated by the backup egress router, via a label distribution protocol f the protector of egress node protection, which will be the same router in the
session. In this case, the backup egress router serves as the protector for egr co-located protector mode but a different router in the centralized protector mo
ess link protection, regardless of the protector of egress node protection, whic de. The egress router sets up the bypass forwarding state as a label swap from t
h will be the same router in the co-located protector mode but a different route he incoming service label to the service label of the backup egress router (i.e.
r in the centralized protector mode. The egress router sets up the bypass forwar , protector), followed by a push with the outgoing label (or label stack) of the
ding state as a label swap from the incoming service label to the service label egress link protection bypass tunnel. The bypass tunnel is a regular tunnel des
of the backup egress router (i.e., protector), followed by a push with the outgo tined for an IP address of the protector, instead of the context ID of the prote
ing label (or label stack) of the egress link protection bypass tunnel. The bypa cted egress {E, P}. The protector simply forwards rerouted service packets based
ss tunnel is a regular tunnel destined for an IP address of the protector, inste on its own service label rather than performing context label switching. In thi
ad of the context ID of the protected egress {E, P}. The protector simply forwar s approach, only the co-located protector mode is applicable.
ds rerouted service packets based on its own service label, rather than performi </li>
ng context label switching. In this approach, only the co-located protector mode </ol>
is applicable. </li>
</t> </ul>
<t pn="section-6-6">
</list> Note that for a bidirectional service, the physical link of an egress lin
</t> k may carry service traffic bidirectionally. Therefore, an egress link failure m
ay simultaneously be an ingress link failure for the traffic in the opposite dir
<t> ection. Protection for ingress link failure <bcp14>SHOULD</bcp14> be provided by
Note that for a bidirectional service, the physical link of an egress lin a separate mechanism and hence is out of the scope of this document.
k may carry service traffic bi-directionally. Therefore, an egress link failure </t>
may simultaneously be an ingress link failure for the traffic in the opposite di </section>
rection. Protection for ingress link failure SHOULD be provided by a separate me <section numbered="true" toc="include" removeInRFC="false" pn="section-7">
chanism, and hence is out of the scope of this document. <name slugifiedName="name-global-repair">Global Repair</name>
</t> <t pn="section-7-1">
This framework provides a fast but temporary repair for egress node and e
</section> gress link failures. For permanent repair, the services affected by a failure <b
cp14>SHOULD</bcp14> be moved to an alternative tunnel, or replaced by alternativ
<section title = "Global repair"> e services, which are fully functional. This is referred to as global repair. Po
ssible triggers of global repair include control-plane notifications of tunnel s
<t> tatus and service status, end-to-end OAM and fault detection at the tunnel and s
This framework provides a fast but temporary repair for egress node and e ervice level, and others. The alternative tunnel and services may be pre-establi
gress link failures. For permanent repair, the services affected by a failure SH shed in standby state or dynamically established as a result of the triggers or
OULD be moved to an alternative tunnel, or replaced by alternative services, whi network protocol convergence.
ch are fully functional. This is referred to as global repair. Possible triggers </t>
of global repair include control plane notifications of tunnel status and servi </section>
ce status, end-to-end OAM and fault detection at tunnel and service level, and o <section numbered="true" toc="include" removeInRFC="false" pn="section-8">
thers. The alternative tunnel and services may be pre-established in standby sta <name slugifiedName="name-operational-considerations">Operational Consider
te, or dynamically established as a result of the triggers or network protocol c ations</name>
onvergence. <t pn="section-8-1">
</t> When a PLR performs local repair, the router <bcp14>SHOULD</bcp14> genera
</section> te an alert for the event. The alert may be logged locally for tracking purposes
, or it may be sent to the operator at a management station. The communication c
<section title = "Operational Considerations"> hannel and protocol between the PLR and the management station may vary dependin
<t> g on networks and are out of the scope of this document.
When a PLR performs local repair, the router SHOULD generate an alert for </t>
the event. The alert may be logged locally for tracking purposes, or it may be </section>
sent to the operator at a management station. The communication channel and prot <section numbered="true" toc="include" removeInRFC="false" pn="section-9">
ocol between the PLR and the management station may vary depending on networks, <name slugifiedName="name-general-context-based-forwa">General Context-Bas
and are out of the scope of this document. ed Forwarding</name>
</t> <t pn="section-9-1">
</section> So far, this document has been focusing on the cases where service
packets are MPLS or IP packets, and protectors perform context label
<section title = "General context-based forwarding"> switching or context IP forwarding.
<t>
So far, this document has been focusing on the cases where service packet
s are MPLS or IP packets and protectors perform context label switching or conte
xt IP forwarding. Although this should cover most common services, it is worth m
entioning that the framework is also applicable to services or sub-modes of serv
ices where service packets are layer-2 packets or encapsulated in non-IP/MPLS fo
rmats. The only specific in these cases is that a protector MUST perform context
-based forwarding based on the layer-2 table or corresponding lookup table which
is indicated by a context ID (i.e., context label).
</t>
</section>
<section title = "Example: Layer-3 VPN egress protection">
<t>
This section shows an example of egress protection for layer-3 IPv4 and I
Pv6 VPNs.
</t>
<figure align="center" anchor="Figure-5">
<preamble></preamble>
<artwork align="center"><![CDATA[
Although this should cover most common services, it is worth mentioning that the
framework is also applicable to services or sub-modes of services where service
packets are Layer 2 packets or encapsulated in non-IP and non-MPLS formats. The
only specific in these cases is that a protector <bcp14>MUST</bcp14> perform co
ntext-based forwarding based on the Layer 2 table or corresponding lookup table,
which is indicated by a context ID (i.e., context label).
</t>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-10">
<name slugifiedName="name-example-layer-3-vpn-egress-">Example: Layer 3 VP
N Egress Protection</name>
<t pn="section-10-1">
This section shows an example of egress protection for Layer 3 IPv4 and I
Pv6 VPNs.
</t>
<figure anchor="Figure-5" align="left" suppress-title="false" pn="figure-5
">
<artwork align="center" name="" type="ascii-art" alt="" pn="section-10-2
.1">
---------- R1 ----------- PE2 - ---------- R1 ----------- PE2 -
/ (PLR) (PLR) \ / (PLR) (PLR) \
( ) / | | ( ) ( ) / | | ( )
( ) / | | ( ) ( ) / | | ( )
( site 1 )-- PE1 < | R3 ( site 2 ) ( site 1 )-- PE1 &lt; | R3 ( site 2 )
( ) \ | | ( ) ( ) \ | | ( )
( ) \ | | ( ) ( ) \ | | ( )
\ | | / \ | | /
---------- R2 ----------- PE3 - ---------- R2 ----------- PE3 -
(protector) (protector) </artwork>
</figure>
]]></artwork> <t pn="section-10-3">
<postamble></postamble> In this example, the core network is IPv4 and MPLS. Both of the IPv4 and
</figure> IPv6 VPNs consist of sites 1 and 2. Site 1 is connected to PE1, and site 2 is du
al-homed to PE2 and PE3. Site 1 includes an IPv4 subnet 203.0.113.64/26 and an I
<t> Pv6 subnet 2001:db8:1:1::/64. Site 2 includes an IPv4 subnet 203.0.113.128/26 an
In this example, the core network is IPv4 and MPLS. Both of the IPv4 VPN d an IPv6 subnet 2001:db8:1:2::/64. PE2 is the primary PE for site 2, and PE3 is
and the IPv6 VPN consist of site 1 and site 2. Site 1 is connected to PE1, and s the backup PE. Each of PE1, PE2, and PE3 hosts an IPv4 VPN instance and an IPv6
ite 2 is dual-homed to PE2 and PE3. Site 1 includes an IPv4 subnet 203.0.113.64/ VPN instance. The PEs use BGP to exchange VPN prefixes and VPN labels between e
26 and an IPv6 subnet 2001:db8:1:1::/64. Site 2 includes an IPv4 subnet 203.0.11 ach other. In the core network, R1 and R2 are transit routers, OSPF is used as t
3.128/26 and an IPv6 subnet 2001:db8:1:2::/64. PE2 is the primary PE for site 2, he routing protocol, and RSVP-TE is used as the tunnel signaling protocol.
and PE3 is the backup PE. Each of PE1, PE2 and PE3 hosts an IPv4 VPN instance a </t>
nd an IPv6 VPN instance. The PEs use BGP to exchange VPN prefixes and VPN labels <t pn="section-10-4">
between each other. In the core network, R1 and R2 are transit routers, OSPF is Using the framework in this document, the network assigns PE3 to be the p
used as the routing protocol, and RSVP-TE as the tunnel signaling protocol. rotector of PE2 to protect the VPN traffic in the direction from site 1 to site
</t> 2. This is the co-located protector mode. PE2 and PE3 form a protected egress {P
E2, PE3}. Context ID 198.51.100.1 is assigned to the protected egress {PE2, PE3}
<t> . (If the core network is IPv6, the context ID would be an IPv6 address.) The IP
Using the framework in this document, the network assigns PE3 to be the p v4 and IPv6 VPN instances on PE3 serve as protection instances for the correspon
rotector of PE2 to protect the VPN traffic in the direction from site 1 to site ding VPN instances on PE2. On PE3, context label 100 is assigned to the context
2. This is the co-located protector mode. PE2 and PE3 form a protected egress {P ID, and a label table pe2.mpls is created to represent PE2's label space. PE3 in
E2, PE3}. A context ID 198.51.100.1 is assigned to the protected egress {PE2, PE stalls label 100 in its MPLS forwarding table, with the next hop pointing to the
3}. (If the core network is IPv6, the context ID would be an IPv6 address.) The label table pe2.mpls. PE2 and PE3 are coordinated to use the proxy mode to adve
IPv4 and IPv6 VPN instances on PE3 serve as protection instances for the corresp rtise the context ID in the routing domain and the TE domain.
onding VPN instances on PE2. On PE3, a context label 100 is assigned to the cont </t>
ext ID, and a label table pe2.mpls is created to represent PE2's label space. PE <t pn="section-10-5">
3 installs label 100 in its MPLS forwarding table, with nexthop pointing to the PE2 uses the label allocation mode per Virtual Routing and Forwarding (VR
label table pe2.mpls. PE2 and PE3 are coordinated to use the proxy mode to adver F) for both of its IPv4 and IPv6 VPN instances. It assigns label 9000 to the IPv
tise the context ID in the routing domain and the TE domain. 4 VRF, and label 9001 to the IPv6 VRF. For the IPv4 prefix 203.0.113.128/26 in s
</t> ite 2, PE2 advertises it with label 9000 and NEXT_HOP 198.51.100.1 to PE1 and PE
3 via BGP. Likewise, for the IPv6 prefix 2001:db8:1:2::/64 in site 2, PE2 advert
<t> ises it with label 9001 and NEXT_HOP 198.51.100.1 to PE1 and PE3 via BGP.
PE2 uses per-VRF label allocation mode for both of its IPv4 and IPv6 VPN </t>
instances. It assigns label 9000 to the IPv4 VRF, and label 9001 to the IPv6 VRF <t pn="section-10-6">
. For the IPv4 prefix 203.0.113.128/26 in site 2, PE2 advertises it with label 9 PE3 also uses per-VRF VPN label allocation mode for both of its IPv4 and
000 and NEXT_HOP 198.51.100.1 to PE1 and PE3 via BGP. Likewise, for the IPv6 pre IPv6 VPN instances. It assigns label 10000 to the IPv4 VRF and label 10001 to th
fix 2001:db8:1:2::/64 in site 2, PE2 advertises it with label 9001 and NEXT_HOP e IPv6 VRF. For the prefix 203.0.113.128/26 in site 2, PE3 advertises it with la
198.51.100.1 to PE1 and PE3 via BGP. bel 10000 and NEXT_HOP as itself to PE1 and PE2 via BGP. For the IPv6 prefix 200
</t> 1:db8:1:2::/64 in site 2, PE3 advertises it with label 10001 and NEXT_HOP as its
elf to PE1 and PE2 via BGP.
<t> </t>
PE3 also uses per-VRF VPN label allocation mode for both of its IPv4 and <t pn="section-10-7">
IPv6 VPN instances. It assigns label 10000 to the IPv4 VRF, and label 10001 to t Upon receipt of the above BGP advertisements from PE2, PE1 uses the conte
he IPv6 VRF. For the prefix 203.0.113.128/26 in site 2, PE3 advertises it with l xt ID 198.51.100.1 as the destination to compute a path for an egress-protected
abel 10000 and NEXT_HOP as itself to PE1 and PE2 via BGP. For the IPv6 prefix 20 tunnel. The resultant path is PE1-&gt;R1-&gt;PE2. PE1 then uses RSVP to signal t
01:db8:1:2::/64 in site 2, PE3 advertises it with label 10001 and NEXT_HOP as it he tunnel, with the context ID 198.51.100.1 as the destination, with the "node p
self to PE1 and PE2 via BGP. rotection desired" flag set in the SESSION_ATTRIBUTE of the RSVP Path message. O
</t> nce the tunnel comes up, PE1 maps the VPN prefixes 203.0.113.128/26 and 2001:db8
:1:2::/64 to the tunnel and installs a route for each prefix in the correspondin
<t> g IPv4 or IPv6 VRF. The next hop of route 203.0.113.128/26 is a push of the VPN
Upon receipt of the above BGP advertisements from PE2, PE1 uses the conte label 9000, followed by a push of the outgoing label of the egress-protected tun
xt ID 198.51.100.1 as destination to compute a path for an egress-protected tunn nel. The next hop of route 2001:db8:1:2::/64 is a push of the VPN label 9001, fo
el. The resultant path is PE1->R1->PE2. PE1 then uses RSVP to signal the tunnel, llowed by a push of the outgoing label of the egress-protected tunnel.
with the context ID 198.51.100.1 as destination, and with the "node protection </t>
desired" flag set in the SESSION_ATTRIBUTE of RSVP Path message. Once the tunnel <t pn="section-10-8">
comes up, PE1 maps the VPN prefixes 203.0.113.128/26 and 2001:db8:1:2::/64 to t Upon receipt of the above BGP advertisements from PE2, PE3 recognizes the
he tunnel, and installs a route for each prefix in the corresponding IPv4 or IPv context ID 198.51.100.1 in the NEXT_HOP attribute and installs a route for labe
6 VRF. The nexthop of the route 203.0.113.128/26 is a push of the VPN label 9000 l 9000 and a route for label 9001 in the label table pe2.mpls. PE3 sets the next
, followed by a push of the outgoing label of the egress-protected tunnel. The n hop of route 9000 to the IPv4 protection VRF and the next hop of route 9001 to
exthop of the route 2001:db8:1:2::/64 is a push of the VPN label 9001, followed the IPv6 protection VRF. The IPv4 protection VRF contains the routes to the IPv4
by a push of the outgoing label of the egress-protected tunnel. prefixes in site 2. The IPv6 protection VRF contains the routes to the IPv6 pre
</t> fixes in site 2. The next hops of these routes must be based on PE3's connectivi
ty with site 2, even if the connectivity may not have the best metrics (e.g., Mu
<t> lti-Exit Discriminator (MED), local preference, etc.) to be used in PE3's own VR
Upon receipt of the above BGP advertisements from PE2, PE3 recognizes the F. The next hops must not use any path traversing PE2. Note that the protection
context ID 198.51.100.1 in the NEXT_HOP attribute, and installs a route for lab VRFs are a logical concept, and they may simply be PE3's own VRFs if they satisf
el 9000 and a route for label 9001 in the label table pe2.mpls. PE3 sets the nex y the requirement.
thop of the route 9000 to the IPv4 protection VRF, and the nexthop of the route </t>
9001 to the IPv6 protection VRF. The IPv4 protection VRF contains the routes to <section numbered="true" toc="include" removeInRFC="false" pn="section-10.
the IPv4 prefixes in site 2. The IPv6 protection VRF contains the routes to the 1">
IPv6 prefixes in site 2. The nexthops of these routes must be based on PE3's con <name slugifiedName="name-egress-node-protection-2">Egress Node Protecti
nectivity with site 2, even if the connectivity may not have the best metrics (e on</name>
.g., MED, local preference, etc.) to be used in PE3's own VRF. The nexthops must <t pn="section-10.1-1">
not use any path traversing PE2. Note that the protection VRFs are a logical co R1, i.e., the penultimate hop router of the egress-protected tunnel, ser
ncept, and they may simply be PE3's own VRFs if they satisfies the requirement. ves as the PLR for egress node protection. Based on the "node protection desired
</t> " flag and the destination address (i.e., context ID 198.51.100.1) of the tunnel
, R1 computes a bypass path to 198.51.100.1 while avoiding PE2. The resultant by
<section title = "Egress node protection"> pass path is R1-&gt;R2-&gt;PE3. R1 then signals the path (i.e., egress-protectio
<t> n bypass tunnel), with 198.51.100.1 as the destination.
R1, i.e., the penultimate-hop router of the egress-protected tunnel, ser </t>
ves as the PLR for egress node protection. Based on the "node protection desired <t pn="section-10.1-2">
" flag and the destination address (i.e., context ID 198.51.100.1) of the tunnel Upon receipt of an RSVP Path message of the egress-protection bypass tun
, R1 computes a bypass path to 198.51.100.1 while avoiding PE2. The resultant by nel, PE3 recognizes the context ID 198.51.100.1 as the destination and responds
pass path is R1->R2->PE3. R1 then signals the path (i.e., egress-protection bypa with context label 100 in an RSVP Resv message.
ss tunnel), with 198.51.100.1 as destination. </t>
</t> <t pn="section-10.1-3">
After the egress-protection bypass tunnel comes up, R1 installs a bypass
<t> next hop for the egress-protected tunnel. The bypass next hop is a label swap f
Upon receipt of an RSVP Path message of the egress-protection bypass tun rom the incoming label of the egress-protected tunnel to the outgoing label of t
nel, PE3 recognizes the context ID 198.51.100.1 as the destination, and responds he egress-protection bypass tunnel.
with the context label 100 in an RSVP Resv message. </t>
</t> <t pn="section-10.1-4">
When R1 detects a failure of PE2, it will invoke the above bypass next h
<t> op to reroute VPN packets. Each IPv4 VPN packet will have the label of the bypas
After the egress-protection bypass tunnel comes up, R1 installs a bypass s tunnel as outer label, and the IPv4 VPN label 9000 as inner label. Each IPv6 V
nexthop for the egress-protected tunnel. The bypass nexthop is a label swap fro PN packet will have the label of the bypass tunnel as the outer label and the IP
m the incoming label of the egress-protected tunnel to the outgoing label of the v6 VPN label 9001 as the inner label. When the packets arrive at PE3, they will
egress-protection bypass tunnel. have the context label 100 as the outer label and the VPN label 9000 or 9001 as
</t> the inner label. The context label will first be popped, and then the VPN label
will be looked up in the label table pe2.mpls. The lookup will cause the VPN lab
<t> el to be popped and the IPv4 and IPv6 packets to be forwarded to site 2 based on
When R1 detects a failure of PE2, it will invoke the above bypass nextho the IPv4 and IPv6 protection VRFs, respectively.
p to reroute VPN packets. Each IPv4 VPN packet will have the label of the bypass </t>
tunnel as outer label, and the IPv4 VPN label 9000 as inner label. Each IPv6 VP </section>
N packets will have the label of the bypass tunnel as outer label, and the IPv6 <section numbered="true" toc="include" removeInRFC="false" pn="section-10.
VPN label 9001 as inner label. When the packets arrive at PE3, they will have th 2">
e context label 100 as outer label, and the VPN label 9000 or 9001 as inner labe <name slugifiedName="name-egress-link-protection-2">Egress Link Protecti
l. The context label will first be popped, and then the VPN label will be looked on</name>
up in the label table pe2.mpls. The lookup will cause the VPN label to be poppe <t pn="section-10.2-1">
d, and the IPv4 and IPv6 packets to be forwarded to site 2 based on the IPv4 and PE2 serves as the PLR for egress link protection. It has already learned
IPv6 protection VRFs, respectively. PE3's IPv4 VPN label 10000 and IPv6 VPN label 10001. Hence, it uses approach (2
</t> ) as described in <xref target="link-protection" format="default" sectionFormat=
"of" derivedContent="Section 6"/> to set up the bypass forwarding state. It sign
</section> als an egress-protection bypass tunnel to PE3, by using the path PE2-&gt;R3-&gt;
PE3, and PE3's IP address as the destination. After the bypass tunnel comes up,
<section title = "Egress link protection"> PE2 installs a bypass next hop for the IPv4 VPN label 9000 and a bypass next hop
<t> for the IPv6 VPN label 9001. For label 9000, the bypass next hop is a label swa
PE2 serves as the PLR for egress link protection. It has already learned p to label 10000, followed by a label push with the outgoing label of the bypass
PE3's IPv4 VPN label 10000 and IPv6 VPN label 10001. Hence it uses the approach tunnel. For label 9001, the bypass next hop is a label swap to label 10001, fol
(2) described in <xref target="link-protection" /> to set up bypass forwarding lowed by a label push with the outgoing label of the bypass tunnel.
state. It signals an egress-protection bypass tunnel to PE3, by using the path P </t>
E2->R3->PE3, and PE3's IP address as destination. After the bypass tunnel comes <t pn="section-10.2-2">
up, PE2 installs a bypass nexthop for the IPv4 VPN label 9000, and a bypass next When PE2 detects a failure of the egress link, it will invoke the above
hop for the IPv6 VPN label 9001. For label 9000, the bypass nexthop is a label s bypass next hop to reroute VPN packets. Each IPv4 VPN packet will have the label
wap to label 10000, followed by a label push with the outgoing label of the bypa of the bypass tunnel as the outer label and label 10000 as the inner label. Eac
ss tunnel. For label 9001, the bypass nexthop is a label swap to label 10001, fo h IPv6 VPN packet will have the label of the bypass tunnel as the outer label an
llowed by a label push with the outgoing label of the bypass tunnel. d label 10001 as the inner label. When the packets arrive at PE3, the VPN label
</t> 10000 or 10001 will be popped, and the exposed IPv4 and IPv6 packets will be for
warded based on PE3's IPv4 and IPv6 VRFs, respectively.
<t> </t>
When PE2 detects a failure of the egress link, it will invoke the above </section>
bypass nexthop to reroute VPN packets. Each IPv4 VPN packet will have the label <section numbered="true" toc="include" removeInRFC="false" pn="section-10.
of the bypass tunnel as outer label, and label 10000 as inner label. Each IPv6 V 3">
PN packet will have the label of the bypass tunnel as outer label, and label 100 <name slugifiedName="name-global-repair-2">Global Repair</name>
01 as inner label. When the packets arrive at PE3, the VPN label 10000 or 10001 <t pn="section-10.3-1">
will be popped, and the exposed IPv4 and IPv6 packets will be forwarded based on Eventually, global repair will take effect, as control-plane protocols c
PE3's IPv4 and IPv6 VRFs, respectively. onverge on the new topology. PE1 will choose PE3 as a new entrance to site 2. Be
</t> fore that happens, the VPN traffic has been protected by the above local repair.
</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-10.
<section title = "Global repair"> 4">
<t> <name slugifiedName="name-other-modes-of-vpn-label-al">Other Modes of VP
Eventually, global repair will take effect, as control plane protocols c N Label Allocation</name>
onverge on the new topology. PE1 will choose PE3 as a new entrance to site 2. Be <t pn="section-10.4-1">
fore that happens, the VPN traffic has been protected by the above local repair. It is also possible that PE2 may use per-route or per-interface VPN labe
</t> l allocation mode. In either case, PE3 will have multiple VPN label routes in th
</section> e pe2.mpls table, corresponding to the VPN labels advertised by PE2. PE3 forward
s rerouted packets by popping a VPN label and performing an IP lookup in the cor
<section title = "Other modes of VPN label allocation"> responding protection VRF. PE3's forwarding behavior is consistent with the abov
e case where PE2 uses per-VRF VPN label allocation mode. PE3 does not need to kn
<t> ow PE2's VPN label allocation mode or construct a specific next hop for each VPN
It is also possible that PE2 may use per-route or per-interface VPN labe label route in the pe2.mpls table.
l allocation mode. In either case, PE3 will have multiple VPN label routes in th </t>
e pe2.mpls table, corresponding to the VPN labels advertised by PE2. PE3 forward </section>
s rerouted packets by popping a VPN label and performing an IP lookup in the cor </section>
responding protection VRF. PE3's forwarding behavior is consistent with the abov <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn=
e case where PE2 uses per-VRF VPN label allocation mode. PE3 does not need to kn "section-11">
ow PE2's VPN label allocation mode, or construct a specific nexthop for each VPN <name slugifiedName="name-iana-considerations">IANA Considerations</name>
label route in the pe2.mpls table. <t pn="section-11-1">
</t> This document has no IANA actions.
</section> </t>
</section> </section>
<section anchor="Security" numbered="true" toc="include" removeInRFC="false"
<section anchor="IANA" title="IANA Considerations"> pn="section-12">
<t> <name slugifiedName="name-security-considerations">Security Considerations
This document has no request for new IANA allocation. </name>
</t> <t pn="section-12-1">
</section>
<section anchor="Security" title="Security Considerations">
<t>
The framework in this document involves rerouting traffic around an egres s node or link failure, via a bypass path from a PLR to a protector, and ultimat ely to a backup egress router. The forwarding performed by the routers in the da ta plane is anticipated, as part of the planning of egress protection. The framework in this document involves rerouting traffic around an egres s node or link failure, via a bypass path from a PLR to a protector, and ultimat ely to a backup egress router. The forwarding performed by the routers in the da ta plane is anticipated, as part of the planning of egress protection.
</t> </t>
<t pn="section-12-2">
<t> Control-plane protocols <bcp14>MAY</bcp14> be used to facilitate the prov
Control plane protocols MAY be used to facilitate the provisioning of the isioning of the egress protection on the routers. In particular, the framework
egress protection on the routers. In particular, the framework requires a serv requires a service label distribution protocol between an egress router and a pr
ice label distribution protocol between an egress router and a protector over a otector over a secure session. The security properties of this provisioning and
secure session. The security properties of this provisioning and label distribu label distribution depend entirely on the underlying protocol chosen to impleme
tion depend entirely on the underlying protocol chosen to implement these activi nt these activities. Their associated security considerations apply. This framew
ties . Their associated security considerations apply. This framework introduces ork introduces no new security requirements or guarantees relative to these acti
no new security requirements or guarantees relative to these activities. vities.
</t> </t>
<t pn="section-12-3">
<t> Also, the PLR, protector, and backup egress router are located close to t
Also, the PLR, protector, and backup egress router are located close to t he protected egress router, which is normally in the same administrative domain.
he protected egress router, and normally in the same administrative domain. If If they are not in the same administrative domain, a certain level of trust <b
they are not in the same administrative domain, a certain level of trust MUST be cp14>MUST</bcp14> be established between them in order for the protocols to run
established between them in order for the protocols to run securely across the securely across the domain boundary. The basis of this trust is the security mo
domain boundary. The basis of this trust is the security model of the protocols del of the protocols (as described above), and further security considerations f
(as described above), and further security considerations for inter-domain scen or inter-domain scenarios should be addressed by the protocols as a common requi
arios should be addressed by the protocols as a common requirement. rement.
</t> </t>
<t pn="section-12-4">
<t> Security attacks may sometimes come from a customer domain. Such attacks
Security attacks may sometimes come from a customer domain. Such kind of are not introduced by the framework in this document and may occur regardless of
attacks are not introduced by the framework in this document, and may occur rega the existence of egress protection. In one possible case, the egress link betwe
rdless of the existence of egress protection. In one possible case, the egress l en an egress router and a CE could become a point of attack. An attacker that g
ink between an egress router and a CE could become a point of attack. An attack ains control of the CE might use it to simulate link failures and trigger consta
er that gains control of the CE might use it to simulate link failures and trigg nt and cascading activities in the network. If egress link protection is in plac
er constant and cascading activities in the network. If egress link protection i e, egress link protection activities may also be triggered. As a general solutio
s in place, egress link protection activities may also be triggered. As a genera n to defeat the attack, a damping mechanism <bcp14>SHOULD</bcp14> be used by the
l solution to defeat the attack, a damping mechanism SHOULD be used by the egres egress router to promptly
s router to promptly
suppress the services associated with the link or CE. The egress router woul d stop advertising the services, essentially detaching them from the network and eliminating the effect of the simulated link failures. suppress the services associated with the link or CE. The egress router woul d stop advertising the services, essentially detaching them from the network and eliminating the effect of the simulated link failures.
</t> </t>
<t pn="section-12-5">
<t>
From the above perspectives, this framework does not introduce any new se curity threat to networks. From the above perspectives, this framework does not introduce any new se curity threat to networks.
</t> </t>
</section> </section>
</middle>
<section anchor="ack" title="Acknowledgements"> <back>
<t> <displayreference target="I-D.ietf-rtgwg-bgp-pic" to="BGP-PIC"/>
This document leverages work done by Yakov Rekhter, Kevin Wang and Zhaohu <references pn="section-13">
i Zhang on MPLS egress protection. Thanks to Alexander Vainshtein, Rolf Winter, <name slugifiedName="name-references">References</name>
Lizhong Jin, Krzysztof Szarkowicz, Roman Danyliw, and Yuanlong Jiang for their v <references pn="section-13.1">
aluable comments that helped to shape this document and improve its clarity. <name slugifiedName="name-normative-references">Normative References</na
</t> me>
</section> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" quoteTitle="true" derivedAnchor="RFC2119">
</middle> <front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
<back> le>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<references title="Normative References"> <organization showOnFrontPage="true"/>
</author>
&RFC2119; <date year="1997" month="March"/>
&RFC8174; <abstract>
&RFC8402; <t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized.
<!-- <reference anchor="SR-ISIS"> value="draft-ietf-isis-segment-routing-extensi This document defines these words as they should be interpreted in IETF document
ons"; companion document RFC YYYY --> s. This document specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for improvements.</t>
<reference anchor='RFCYYYY'> </abstract>
<front> </front>
<title>IS-IS Extensions for Segment Routing</title> <seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<author initials='S' surname='Previdi' fullname='Stefano Previdi'> <seriesInfo name="DOI" value="10.17487/RFC2119"/>
<organization /> </reference>
</author> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<author initials='L' surname='Ginsberg' fullname='Les Ginsberg'> <front>
<organization /> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
</author> tle>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<author initials='C' surname='Filsfils' fullname='Clarence Filsfils'> <organization showOnFrontPage="true"/>
<organization /> </author>
</author> <date year="2017" month="May"/>
<abstract>
<author initials='A' surname='Bashandy' fullname='Ahmed Bashandy'> <t>RFC 2119 specifies common key words that may be used in protoco
<organization /> l specifications. This document aims to reduce the ambiguity by clarifying tha
</author> t only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
<author initials='H' surname='Gredler' fullname='Hannes Gredler'> </front>
<organization /> <seriesInfo name="BCP" value="14"/>
</author> <seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
<author initials='B' surname='Decraene' fullname='Bruno Decraene'> </reference>
<organization /> <reference anchor="RFC8402" target="https://www.rfc-editor.org/info/rfc8
</author> 402" quoteTitle="true" derivedAnchor="RFC8402">
<front>
<date month='May' day='19' year='2019' /> <title>Segment Routing Architecture</title>
<author initials="C." surname="Filsfils" fullname="C. Filsfils" role
<abstract><t>Segment Routing (SR) allows for a flexible definition of end-to-end ="editor">
paths within IGP topologies by encoding paths as sequences of topological sub-p <organization showOnFrontPage="true"/>
aths, called "segments". These segments are advertised by the link-state routin </author>
g protocols (IS-IS and OSPF). This draft describes the necessary IS-IS extensio <author initials="S." surname="Previdi" fullname="S. Previdi" role="
ns that need to be introduced for Segment Routing operating on an MPLS data-plan editor">
e.</t></abstract> <organization showOnFrontPage="true"/>
</author>
</front> <author initials="L." surname="Ginsberg" fullname="L. Ginsberg">
<organization showOnFrontPage="true"/>
<seriesInfo name="RFC" value="YYYY"/> </author>
<seriesInfo name="DOI" value="10.17487/RFCYYYY"/> <author initials="B." surname="Decraene" fullname="B. Decraene">
<organization showOnFrontPage="true"/>
</reference> </author>
<author initials="S." surname="Litkowski" fullname="S. Litkowski">
</references> <organization showOnFrontPage="true"/>
</author>
<references title="Informative References"> <author initials="R." surname="Shakir" fullname="R. Shakir">
&RFC4090; <organization showOnFrontPage="true"/>
&RFC5286; </author>
&RFC7490; <date year="2018" month="July"/>
&RFC7812; <abstract>
&RFC8104; <t>Segment Routing (SR) leverages the source routing paradigm. A
&RFC8400; node steers a packet through an ordered list of instructions, called "segments".
A segment can represent any instruction, topological or service based. A segm
<!-- <reference anchor="BGP-PIC"> value="draft-ietf-rtgwg-bgp-pic-09.txt"; I-D E ent can have a semantic local to an SR node or global within an SR domain. SR p
xists --> rovides a mechanism that allows a flow to be restricted to a specific topologica
l path, while maintaining per-flow state only at the ingress node(s) to the SR d
<reference anchor='BGP-PIC'> omain.</t>
<front> <t>SR can be directly applied to the MPLS architecture with no cha
<title>BGP Prefix Independent Convergence</title> nge to the forwarding plane. A segment is encoded as an MPLS label. An ordered
list of segments is encoded as a stack of labels. The segment to process is on
<author initials='A' surname='Bashandy' fullname='Ahmed Bashandy'> the top of the stack. Upon completion of a segment, the related label is poppe
<organization /> d from the stack.</t>
</author> <t>SR can be applied to the IPv6 architecture, with a new type of
routing header. A segment is encoded as an IPv6 address. An ordered list of se
<author initials='C' surname='Filsfils' fullname='Clarence Filsfils'> gments is encoded as an ordered list of IPv6 addresses in the routing header. T
<organization /> he active segment is indicated by the Destination Address (DA) of the packet. T
</author> he next active segment is indicated by a pointer in the new routing header.</t>
</abstract>
<author initials='P' surname='Mohapatra' fullname='Prodosh Mohapatra'> </front>
<organization /> <seriesInfo name="RFC" value="8402"/>
</author> <seriesInfo name="DOI" value="10.17487/RFC8402"/>
</reference>
<date month='April' day='1' year='2019' /> <reference anchor="RFC8667" target="https://www.rfc-editor.org/info/rfc8
667" quoteTitle="true" derivedAnchor="RFC8667">
<abstract><t>In the network comprising thousands of iBGP peers exchanging millio <front>
ns of routes, many routes are reachable via more than one next-hop. Given the la <title>IS-IS Extensions for Segment Routing</title>
rge scaling targets, it is desirable to restore traffic after failure in a time <seriesInfo name="RFC" value="8667"/>
period that does not depend on the number of BGP prefixes. In this document we p <seriesInfo name="DOI" value="10.17487/RFC8667"/>
roposed an architecture by which traffic can be re-routed to ECMP or pre-calcula <author initials="S" surname="Previdi" fullname="Stefano Previdi">
ted backup paths in a timeframe that does not depend on the number of BGP prefix <organization showOnFrontPage="true"/>
es. The objective is achieved through organizing the forwarding data structures </author>
in a hierarchical manner and sharing forwarding elements among the maximum possi <author initials="L" surname="Ginsberg" fullname="Les Ginsberg">
ble number of routes. The proposed technique achieves prefix independent converg <organization showOnFrontPage="true"/>
ence while ensuring incremental deployment, complete automation, and zero manage </author>
ment and provisioning effort. It is noteworthy to mention that the benefits of B <author initials="C" surname="Filsfils" fullname="Clarence Filsfils"
GP-PIC are hinged on the existence of more than one path whether as ECMP or prim >
ary-backup.</t></abstract> <organization showOnFrontPage="true"/>
</author>
</front> <author initials="A" surname="Bashandy" fullname="Ahmed Bashandy">
<organization showOnFrontPage="true"/>
<seriesInfo name='Work in Progress,' value='draft-ietf-rtgwg-bgp-pic-09' /> </author>
</reference> <author initials="H" surname="Gredler" fullname="Hannes Gredler">
<organization showOnFrontPage="true"/>
</references> </author>
<author initials="B" surname="Decraene" fullname="Bruno Decraene">
</back> <organization showOnFrontPage="true"/>
</author>
<date month="December" year="2019"/>
<abstract>
<t>Segment Routing (SR) allows for a flexible definition of end-to
-end paths within IGP topologies by encoding paths as sequences of topological s
ub-paths, called "segments". These segments are advertised by the link-state ro
uting protocols (IS-IS and OSPF). This draft describes the necessary IS-IS exte
nsions that need to be introduced for Segment Routing operating on an MPLS data-
plane.</t>
</abstract>
</front>
</reference>
</references>
<references pn="section-13.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="I-D.ietf-rtgwg-bgp-pic" quoteTitle="true" target="htt
ps://tools.ietf.org/html/draft-ietf-rtgwg-bgp-pic-10" derivedAnchor="BGP-PIC">
<front>
<title>BGP Prefix Independent Convergence</title>
<author initials="A" surname="Bashandy" fullname="Ahmed Bashandy">
<organization showOnFrontPage="true"/>
</author>
<author initials="C" surname="Filsfils" fullname="Clarence Filsfils"
>
<organization showOnFrontPage="true"/>
</author>
<author initials="P" surname="Mohapatra" fullname="Prodosh Mohapatra
">
<organization showOnFrontPage="true"/>
</author>
<date month="October" day="2" year="2019"/>
<abstract>
<t>In the network comprising thousands of iBGP peers exchanging mi
llions of routes, many routes are reachable via more than one next-hop. Given th
e large scaling targets, it is desirable to restore traffic after failure in a t
ime period that does not depend on the number of BGP prefixes. In this document
we proposed an architecture by which traffic can be re-routed to ECMP or pre-cal
culated backup paths in a timeframe that does not depend on the number of BGP pr
efixes. The objective is achieved through organizing the forwarding data structu
res in a hierarchical manner and sharing forwarding elements among the maximum p
ossible number of routes. The proposed technique achieves prefix independent con
vergence while ensuring incremental deployment, complete automation, and zero ma
nagement and provisioning effort. It is noteworthy to mention that the benefits
of BGP-PIC are hinged on the existence of more than one path whether as ECMP or
primary-backup.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-rtgwg-bgp-pic-10"/
>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-i
etf-rtgwg-bgp-pic-10.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="RFC4090" target="https://www.rfc-editor.org/info/rfc4
090" quoteTitle="true" derivedAnchor="RFC4090">
<front>
<title>Fast Reroute Extensions to RSVP-TE for LSP Tunnels</title>
<author initials="P." surname="Pan" fullname="P. Pan" role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Swallow" fullname="G. Swallow" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Atlas" fullname="A. Atlas" role="edit
or">
<organization showOnFrontPage="true"/>
</author>
<date year="2005" month="May"/>
<abstract>
<t>This document defines RSVP-TE extensions to establish backup la
bel-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanis
ms enable the re-direction of traffic onto backup LSP tunnels in 10s of millisec
onds, in the event of a failure.</t>
<t>Two methods are defined here. The one-to-one backup method cre
ates detour LSPs for each protected LSP at each potential point of local repair.
The facility backup method creates a bypass tunnel to protect a potential fail
ure point; by taking advantage of MPLS label stacking, this bypass tunnel can pr
otect a set of LSPs that have similar backup constraints. Both methods can be u
sed to protect links and nodes during network failure. The described behavior a
nd extensions to RSVP allow nodes to implement either method or both and to inte
roperate in a mixed network. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4090"/>
<seriesInfo name="DOI" value="10.17487/RFC4090"/>
</reference>
<reference anchor="RFC5286" target="https://www.rfc-editor.org/info/rfc5
286" quoteTitle="true" derivedAnchor="RFC5286">
<front>
<title>Basic Specification for IP Fast Reroute: Loop-Free Alternates
</title>
<author initials="A." surname="Atlas" fullname="A. Atlas" role="edit
or">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Zinin" fullname="A. Zinin" role="edit
or">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="September"/>
<abstract>
<t>This document describes the use of loop-free alternates to prov
ide local protection for unicast traffic in pure IP and MPLS/LDP networks in the
event of a single failure, whether link, node, or shared risk link group (SRLG)
. The goal of this technology is to reduce the packet loss that happens while r
outers converge after a topology change due to a failure. Rapid failure repair
is achieved through use of precalculated backup next-hops that are loop-free and
safe to use until the distributed network convergence process completes. This s
imple approach does not require any support from other routers. The extent to wh
ich this goal can be met by this specification is dependent on the topology of t
he network. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5286"/>
<seriesInfo name="DOI" value="10.17487/RFC5286"/>
</reference>
<reference anchor="RFC7490" target="https://www.rfc-editor.org/info/rfc7
490" quoteTitle="true" derivedAnchor="RFC7490">
<front>
<title>Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)</title>
<author initials="S." surname="Bryant" fullname="S. Bryant">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Filsfils" fullname="C. Filsfils">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Previdi" fullname="S. Previdi">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Shand" fullname="M. Shand">
<organization showOnFrontPage="true"/>
</author>
<author initials="N." surname="So" fullname="N. So">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="April"/>
<abstract>
<t>This document describes an extension to the basic IP fast rerou
te mechanism, described in RFC 5286, that provides additional backup connectivit
y for point-to-point link failures when none can be provided by the basic mechan
isms.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7490"/>
<seriesInfo name="DOI" value="10.17487/RFC7490"/>
</reference>
<reference anchor="RFC7812" target="https://www.rfc-editor.org/info/rfc7
812" quoteTitle="true" derivedAnchor="RFC7812">
<front>
<title>An Architecture for IP/LDP Fast Reroute Using Maximally Redun
dant Trees (MRT-FRR)</title>
<author initials="A." surname="Atlas" fullname="A. Atlas">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Bowers" fullname="C. Bowers">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Enyedi" fullname="G. Enyedi">
<organization showOnFrontPage="true"/>
</author>
<date year="2016" month="June"/>
<abstract>
<t>This document defines the architecture for IP and LDP Fast Rero
ute using Maximally Redundant Trees (MRT-FRR). MRT-FRR is a technology that giv
es link-protection and node-protection with 100% coverage in any network topolog
y that is still connected after the failure.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7812"/>
<seriesInfo name="DOI" value="10.17487/RFC7812"/>
</reference>
<reference anchor="RFC8104" target="https://www.rfc-editor.org/info/rfc8
104" quoteTitle="true" derivedAnchor="RFC8104">
<front>
<title>Pseudowire (PW) Endpoint Fast Failure Protection</title>
<author initials="Y." surname="Shen" fullname="Y. Shen">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Aggarwal" fullname="R. Aggarwal">
<organization showOnFrontPage="true"/>
</author>
<author initials="W." surname="Henderickx" fullname="W. Henderickx">
<organization showOnFrontPage="true"/>
</author>
<author initials="Y." surname="Jiang" fullname="Y. Jiang">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="March"/>
<abstract>
<t>This document specifies a fast mechanism for protecting pseudow
ires (PWs) transported by IP/MPLS tunnels against egress endpoint failures, incl
uding egress attachment circuit (AC) failure, egress provider edge (PE) failure,
multi-segment PW terminating PE failure, and multi-segment PW switching PE fail
ure. Operating on the basis of multihomed customer edge (CE), redundant PWs, up
stream label assignment, and context-specific label switching, the mechanism ena
bles local repair to be performed by the router upstream adjacent to a failure.
The router can restore a PW in the order of tens of milliseconds, by rerouting
traffic around the failure to a protector through a pre-established bypass tunne
l. Therefore, the mechanism can be used to reduce traffic loss before global re
pair reacts to the failure and the network converges on the topology changes due
to the failure.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8104"/>
<seriesInfo name="DOI" value="10.17487/RFC8104"/>
</reference>
<reference anchor="RFC8400" target="https://www.rfc-editor.org/info/rfc8
400" quoteTitle="true" derivedAnchor="RFC8400">
<front>
<title>Extensions to RSVP-TE for Label Switched Path (LSP) Egress Pr
otection</title>
<author initials="H." surname="Chen" fullname="H. Chen">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Liu" fullname="A. Liu">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Saad" fullname="T. Saad">
<organization showOnFrontPage="true"/>
</author>
<author initials="F." surname="Xu" fullname="F. Xu">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Huang" fullname="L. Huang">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="June"/>
<abstract>
<t>This document describes extensions to Resource Reservation Prot
ocol - Traffic Engineering (RSVP-TE) for locally protecting the egress node(s) o
f a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic Engineered (TE) L
abel Switched Path (LSP).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8400"/>
<seriesInfo name="DOI" value="10.17487/RFC8400"/>
</reference>
</references>
</references>
<section anchor="ack" numbered="false" toc="include" removeInRFC="false" pn=
"section-appendix.a">
<name slugifiedName="name-acknowledgements">Acknowledgements</name>
<t pn="section-appendix.a-1">
This document leverages work done by Yakov Rekhter, Kevin Wang, and Zhaoh
ui Zhang on MPLS egress protection. Thanks to Alexander Vainshtein, Rolf Winter,
Lizhong Jin, Krzysztof Szarkowicz, Roman Danyliw, and Yuanlong Jiang for their
valuable comments that helped to shape this document and improve its clarity.
</t>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.b">
<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author fullname="Yimin Shen" surname="Shen" initials="Y">
<organization showOnFrontPage="true">Juniper Networks</organization>
<address>
<postal>
<street>10 Technology Park Drive</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
<country>United States of America</country>
</postal>
<phone>+1 978 589 0722</phone>
<email>yshen@juniper.net</email>
</address>
</author>
<author fullname="Minto Jeyananth" surname="Jeyananth" initials="M">
<organization showOnFrontPage="true">Juniper Networks</organization>
<address>
<postal>
<street>1133 Innovation Way</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>United States of America</country>
</postal>
<phone>+1 408 936 7563</phone>
<email>minto@juniper.net</email>
</address>
</author>
<author fullname="Bruno Decraene" surname="Decraene" initials="B">
<organization showOnFrontPage="true">Orange</organization>
<address>
<email>bruno.decraene@orange.com</email>
</address>
</author>
<author fullname="Hannes Gredler" surname="Gredler" initials="H">
<organization showOnFrontPage="true">RtBrick Inc.</organization>
<address>
<email>hannes@rtbrick.com</email>
</address>
</author>
<author fullname="Carsten Michel" surname="Michel" initials="C">
<organization showOnFrontPage="true">Deutsche Telekom</organization>
<address>
<email>c.michel@telekom.de</email>
</address>
</author>
<author fullname="Huaimo Chen" surname="Chen" initials="H">
<organization showOnFrontPage="true">Futurewei</organization>
<address>
<postal>
<street/>
<city>Boston</city>
<region>MA</region>
<code/>
<country>United States of America</country>
</postal>
<email>Huaimo.chen@futurewei.com</email>
</address>
</author>
</section>
</back>
</rfc> </rfc>
 End of changes. 62 change blocks. 
1391 lines changed or deleted 1909 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/