One document matched: draft-minto-2547-egress-node-fast-protection-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2205 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2205.xml">
<!ENTITY RFC3031 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3031.xml">
<!ENTITY RFC3209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml">
<!ENTITY RFC4090 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4090.xml">
<!ENTITY RFC5036 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5036.xml">
<!ENTITY RFC4447 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4447.xml">
<!ENTITY RFC3471 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3471.xml">
<!ENTITY RFC3472 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3472.xml">
<!ENTITY RFC5331 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5331.xml">
<!ENTITY RFC5920 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5920.xml">
]>
<?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 category="std" docName="draft-minto-2547-egress-node-fast-protection-00"
ipr="trust200902">
<front>
<title>2547 egress PE Fast Failure Protection</title>
<author fullname="Jeyananth Minto Jeganathan" initials="J.M"
surname="Jeganathan">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 N Mathilda Avenue</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>USA</country>
</postal>
<email>minto@juniper.net</email>
</address>
</author>
<author fullname="Maciek Konstantynowicz" initials="M"
surname=" Konstantynowicz">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 N Mathilda Avenue</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>USA</country>
</postal>
<email>maciek@juniper.net</email>
</address>
</author>
<author fullname="Hannes Gredler" initials="H" surname="Gredler">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 N Mathilda Avenue</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>USA</country>
</postal>
<email>hannes@juniper.net</email>
</address>
</author>
<author>
<organization>Juniper Networks</organization>
</author>
<date year="2011" />
<area>Routing</area>
<workgroup>Network Working Group</workgroup>
<keyword>2547</keyword>
<keyword>l3vpn</keyword>
<keyword>protection</keyword>
<keyword>local repair</keyword>
<keyword>fast reroute</keyword>
<abstract>
<t>This document specifies a mechanism for protecting RFC2547 based VPN
service against egress node failure. The mechanism enables local repair
to be performed immediately upon a egress node failure. In particular,
the router at point of local repair (PLR) can redirect VPN traffic to a
protector to repair in the order of tens of milliseconds, achieving fast
protection that is comparable to MPLS fast reroute.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document specifies a mechanism for protecting RFC2547 based VPN
against egress PE failure. The procedures in this document are relevant
only when a VPN site is multi-homed to two or more PEs. This is designed
on the basis of MPLS context specific label switching [RFC 5331].
Fast-protection refers to the ability to provide local repair upon a
failure in the order of tens of milliseconds, which is comparable to
MPLS fast-reroute [RFC 4090]. This is achieved by establishing local
protection as close to a failure as possible. Compared with the existing
global repair mechanisms that rely on control plane convergence, these
procedures can provide faster restoration for VPN traffic. However, they
are intended to complement the global repair mechanisms, rather than
replacing them in any way.</t>
</section>
<section title="Specification of Requirements">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.</t>
</section>
<section title="Terminology">
<t>Protected PE: A PE which request protection for minimum one VPN
prefix.</t>
<t>Protected prefix: A VPN prefix that required protection in case of
Protected PE goes down.</t>
<t>Protector: A router which protect one or more VPN prefix when a
Protected PE goes down.</t>
<t>BGP nexthop: A nexthop advertised in the BGP-Update for the VPN
prefix by a BGP speaker.</t>
<t>VPN label: A label advertised by a BGP speaker for set of VPN
prefixes. This label can be per-VRF label or per nexthop label or per
prefix label.</t>
<t>Transport LSP: A LSP setup to BGP nexthop either by LDP or RSVP.</t>
<t>Alternative egress PE: A PE originates same IP prefix as Protected
prefix in a same VPN.</t>
<t>VPN transport LSP: A Transport LSP that carries VPN traffic.</t>
<t>Context table: A context-specific label space routing table. This
table is per is populated with VPN labels advertised by the
protected-PE.</t>
<t>Context node: A stub router advertised into IGP by protected PE for a
context-identifier.</t>
</section>
<section title="Reference topology">
<t>This document refers to the following topologies to describe various
roles and solution.</t>
<figure align="center" anchor="Topology-1">
<preamble></preamble>
<artwork align="center">
.......................
. .
+-------+--CE1----PE1 PE4----CE5---+-------+
| red | . \ / . | red |
| site1 | . \ / . | site2 |
+-------+--CE2-----+ P--P--PLR1 +----CE6---+-------+
. | / | | \ | .
. PE2 RR | PE5 .
. | \ | | / | .
+-------+--CE3-----+ P--P--PLR2 +----CE7--+-------+
| blue | . / \ . |blue |
| site1 | . / \ . |site2 |
+-------+--CE4-----PE3 PE6----CE8--+-------+
. .
. .
.......................
</artwork>
<postamble></postamble>
</figure>
<t>In Topology-1 two VPNs red and blue with two sites multihomed with
PEs. Let assume blue and red VPN site2 prefixes required egress
protection in case of PE5 goes down. PE5 is protected PE for site2
prefixes for both VPN. PE4 is alternate PE for red site2 prefixes. PE6
is alternate PE for blue site2 prefixes. For PE4 could act as protector
for red VPN site2 and PE6 could acts as protector for blue VPN site2.
This model is co-located protector model. RR could act as protector for
both red and blue VPN site2. This is Centralized protector model (A PE
protecting set of VPNs and not connected to any VPN site).</t>
<figure align="center" anchor="Topologgy-2">
<artwork>
.......................
. .
+-------+--CE1----PE1 PE4----CE5---+-------+
| red | . \ / . | red |
| site1 | . \ / . | site2 |
+-------+--CE2-----+ P--P--PLR1 +----CE6---+-------+
. | / | | \ | .
. PE2 RR | PE5 .
. | \ | | / | .
+-------+--CE3-----+ P--P--PLR2 +----CE7--+-------+
| red | . / \ . |red |
| site5 | . / \ . |site4 |
+-------+--CE4-----PE3 PE6----CE8--+-------+
. .
. .
.......................
</artwork>
</figure>
<t>In Topology-2 has a VPNs red with four sites and multihomed with PEs.
Let assume red VPN site2 and site4 prefixes required egress protection
in case of PE5 goes down. PE5 is protected PE for site2, site4 prefixes
for red VPN. PE4 is alternate PE for site2 prefixes. PE6 is alternate PE
for site4 prefixes. Either PE4 or PE6 could act as protector. This is a
slight variation of the co-located model.</t>
</section>
<section anchor="theory" title="Theory of Operation">
<t>The Egress PEs attached to multi-homed site export VPN prefixes with
different route distinguisher, different nexthop but with same route
target. The other PEs attached to other sites with same VPN import these
route into VRF creates more than one path to multi-homed sites. When one
egress PE goes down all VPN traffic towards the multihomed site moved to
alternate egress PEs attached to the multi-homed site. This is done by
ingress PE. The VPN traffic going via failed PE get dropped in
penultimate hop router until ingress PE reroute VPN traffic. Even though
connectivity of multi-homed site is not bound to an egress PE the
transport LSP bind to egress PE. As result of down transport LSP VPN
traffic getting dropped in P router. This document specifies a mechanism
that repair VPN traffic at point of failure (typically a P router which
penultimate hop of the transport LSP) and still keep P router unaware of
the VPN information with the help of protector (a new role). The PLR
(point of local repair) send VPN traffic to protector through bypass LSP
incase of egress PE failure. This protector send VPN traffic received
from PLR to the alternative egress PE until the ingress reroute traffic
to alternate egress PE.</t>
<section title="Protector and Protection Models">
<t>Protector, is a new role for the egress PE failure local repair.
This protector role could be played by a PE(alternate egress PE) or
any other nodes which participates in VPN control plane for VPN
prefixes that required egress node protection. Hence, there are two
protection models based on the location and role of a protector.</t>
<section title="Co-located protector">
<t>In this model, the protector is a alternate egress PE for a
protected prefix. It is co-located with the alternate PE for the
protected prefix, and it has a direct connection to the multi-homed
site that originate the protected prefix. In the event of an egress
node failure, the protector receives traffic from the PLR, and sends
the traffic to the multi-homed site. In the topology-1 PE4 could act
as protector for red VPN site2 and PE6 could acts as protector for
blue VPN site2. This model is co-located protector model. RR could
act as protector for both red and blue VPN site2. This is
Centralized protector model (A PE protecting set of VPNs and not
connected to any VPN site).</t>
<t>A slight variant of this model is, protector is not alternate PE
for a protected prefix but has same VRF. In the topology-2 either
PE4 or PE6 could act as protector. This is example for the above
model.</t>
</section>
<section title="Centralized protector">
<t>In this model, the protector serves as a centralized protector
MAY NOT have a direct connection to multi-homed site. This model can
be played by existing PEs or other PEs. In the event of an egress PE
failure, protector MUST send the traffic to a alternate egress PE
with VPN label advertised alternate egress PE for the prefix which
in turn sends the traffic to the multi-homed site. In the topology-1
RR could act as protector for both red and blue VPN site2. This is
Centralized protector model (A PE protecting set of VPNs and not
connected to any VPN site).</t>
<t>A network MAY use either protection model or a combination of
both, depending on requirements.</t>
</section>
</section>
<section title="Context Identifier and VPN prefixes.">
<t>The context-identifier is an IP address that is either globally
unique or unique in the private address space of the routing domain.
In Egress PE each VPN prefix is assigned to context-identifier. The
granularity of a context identifier is {Egress PE, VPN prefix} tuple.
However, a given context identifier MAY be assigned to one or multiple
VPN prefix.</t>
<t>Possible context identifier assignments are <list style="symbols">
<t>Unique context-identifier for all VPN prefixes, both VPN-IPv4
and VPN-IPv6.</t>
<t>Unique context-identifier per address family.</t>
<t>Unique context-identifier per site for all VPN prefixes, both
VPN-IPv4 and VPN-IPv6.</t>
<t>Unique context-identifier per site per address family.</t>
<t>Unique context-identifier per CE address (nexthop).</t>
<t>Unique context identifier for each prefix.</t>
</list></t>
<t>The first one is coarsest granularity of a context identifier and
the last one is finest granularity of a context identifier. While all
of the above options are possible in principle, their practical usage
is likely to vary widely, as not all of them may be of practical
usage. A given context identifier MUST NOT be used by more than one
protected PE. The egress PE that required protection for a VPN prefix
MUST put context-identifier as nexthop in BGP update. This
context-identifier as nexthop indicates to protector that this prefix
need protection. For e.g. In topology 1 PE5(protected PE) advertise
VPN prefixes with context-identifier as BGP nexthop.</t>
</section>
<section anchor="context_id"
title="Context Identifier Advertisement by IGP">
<t>IGP MUST advertise context identifiers to allow computation of TE
paths for bypass LSPs and VPN transport LSPs that are destined for
context identifiers. Context identifiers MUST be advertised a stub
router in IGP and TE. Advertised as a stub router allow operator to
deploy egress protection without upgrading all P routers.</t>
<t>A protected PE MUST advertise a context identifier as a stub router
to TE domain and in IGP. Also Protected PE MUST advertise a link to
the stub router.</t>
<t>A protector MUST advertise link to stub router advertised by
protected PE in IGP and TE.</t>
<section title="Context-identifier advertised as stub router. ">
<t>Context-identifier advertised as stub router required two parts.
A node representation (context-node) and links to the node. The
protected PE and protector advertise link to context-node and
protected PE advertise context-node.</t>
<t>The protected PE will advertise context-node in to IGP. The
router-id of the context-node is context-identifier. The system-ID
is derived from the context-identifier with BCD encoding. The
resulting system-ID MUST be unique with in IGP routing domain.
Context-node advertised with two unnumbered transit links with MAX
routable link metric to protected PE and protector. For TE these
unnumbered links advertised with zero bandwidth and MAX TE metric.
Other TE characteristic of TE links could be configured to
advertise. The router-ID or system-ID of the protector could be
dynamically learned from the IGP link state database or could be
configured in protected PE.</t>
<t>Protected PE MUST advertise unnumbered transit link with metric 1
and TE metric 1 to context-node. Protector MUST advertise unnumbered
transit link with maximum routable link metric and maximum TE metric
to the context-node. Other TE characteristic of the links could be
configured and advertised in to TE.</t>
<section title="ISIS context-node ">
<t>Only zeroth fragment of the context-node is only valid. All
Other fragments SHOULD be ignored. Zeroth fragment MUST include
area address TLV and MAY include hostname TLV.</t>
<t>The set of area addresses advertised MUST be a subset of the
set of Area Addresses advertised in the protected LSP number zero
at the corresponding level. Preferably, the advertisement SHOULD
be syntactically identical to that included in the normal LSP
number zero at the corresponding level. The hostname could be set
as <context-identifier+ protected PE hostname>.</t>
<t>The Overload (OL) MUST be set to 1. The Attached (ATT), and
Partition Repair (P) bits MUST be set to 0.</t>
</section>
<section title="OSPF context-node">
<t>The advertising router and Link State ID of router LSA MUST be
context-identifier. All options bits in router LSA MUST be set to
zero. The number of links MUST be 2.</t>
</section>
</section>
</section>
<section anchor="forwarding" title="Forwarding State on Protector PE">
<t>A protector maintain the forwarding state in context-specific label
spaces on a per protected PE basis. In particular, the protector MUST
learn the VPN label by participating the VPN routing and also MUST
keep all routes associated with VPN it required to protect.</t>
<t>For each VPN label with an associated context-identifier protector
MUST map the context identifier to a context-specific label space [RFC
5331], and program the VPN label in that label space in forwarding
plane. For each VPN prefix that required protection programmed in the
forwarding plane with BGP nexthop to alternate egress PE. This VPN
label in the context-specific label space identify the layer-3
forwarding table that need to lookup to send it alternate egress PE.
The protector MAY maintain only VPN prefix originated with-in the
multi-homed site for given {egress PE, VPN}. These VPN labels in
context table and VPN context table will not be used in forwarding
after ingress reroute the traffic to alternative PE. Protector MUST
delete VPN label and the VPN context table after ingress reroute the
traffic. This shall be achieved with a timer. This timer default value
is 180 seconds.</t>
<section title="Alternate egress PE for protected prefix.">
<t>Any route with BGP nexthop which has the following properties
<list>
<t>Exact matching route-target set (RD may be different)</t>
<t>Exact matching Prefix part (not RD)</t>
</list></t>
<t>will be eligible as alternate egress PE for prefix.</t>
</section>
</section>
<section anchor="bypass" title="Bypass LSP">
<t>An LSP MUST be either manually or automatically provisioned on a
PLR to enable the PLR to send traffic to a protector, in the event of
an egress PE failure. This LSP is referred to as a bypass LSP. The
bypass LSP MUST be a LSP with ultimate hop popping (UHP) [RFC 3031].
That is, the protector MUST assign an un-reserved label to the bypass
LSP. When the protector PE receives VPN packets on the bypass LSP from
a PLR, it MUST rely on the bypass LSP's UHP label to determine the
context-specific label space to forward the packets.</t>
<section anchor="rsvp_bypass"
title="RSVP-TE Signaled Bypass LSP and Backup LSP">
<t>If a bypass LSP is an RSVP-TE signaled LSP, its destination MUST
be the context identifier of the protected VPN prefix. The path
taken by the bypass LSP MAY be statically configured or dynamically
computed by CSPF. The signaling of the bypass LSP MUST be triggered
by the "local protection desired" and "node protection desired" bits
in SESSION_ATTRIBUTE of Path message of the transport LSP [RFC 2205,
RFC 3209, RFC 4090]. After the bypass LSP is established, the PLR
MUST set the "local protection available" and "node protection" bits
in RRO of Resv message of the transport LSP. The protector MUST
terminate the backup LSP as an egress. Once the local repair takes
effect, the PLR MUST set the "local protection in use" bit in RRO of
Resv message of the transport LSP.</t>
</section>
<section anchor="ldp_bypass" title="LDP Signaled Bypass LSP">
<t>If it is LDP LSP then LDP FEC for this LSP MUST be the context
identifier of the protected segment. Prefix LFA with node protection
can be used for bypass LSP computation.</t>
</section>
</section>
</section>
<section anchor="link_failure" title=" Egress node Failure">
<t>This section summarizes the procedures egress protection described
above section for completeness. A Egress PE and a protector both
advertise the context identifier of a protected prefixes in IGP as a
stub link or stub router, with the egress PE advertising a lower metric
and protector with maximum metric. The PLR establishes a UHP bypass LSP
to the protector. The destination address of the bypass LSP is the
context identifier. The protector programs forwarding state in such a
way that packets received on the bypass LSP will be forwarded based on
VPN label in the context table, and prefix lookup in VPN context table.
The context table identified by the UHP label of the bypass LSP, i.e.
the context identifier.</t>
<t>When the penultimate Hop router receives a VPN packet from the MPLS
network, if the egress PE is down, the PLR tunnels the packet through
the bypass LSP to the protector. The protector PE identifies the
forwarding context of the egress PE based on the top label of the packet
which is the UHP label of the bypass LSP. Then forwards protector the
packet based on a second label lookup in the protected PE's context
label space followed by layer-3 lookup in the VPN context table. These
UHP label, context table label and layer-3 lookup results in forwarding
the packet to the site or send it to alternate egress PE based on
protector model.</t>
<t>For E.g. In topology-1 RR is act as Protector and PE5 required
protection for red, blue site2 prefixes. As red, blue site2 VPN prefixes
advertised with context-identifier, the protector set up the forwarding
table for prefixes from site2 with alternative egress PE as nexthop.
When PLR detects PE5 failure it send to protector through bypass LSP. In
protector the top label identify the context space table. VPN label in
the context table identify the VPN layer-3 forwarding table with
contains site2 prefixes with alternate PE as nexthop. A Layer-3 lookup
gives mpls path to alternate egress PE and protector forward packet to
alternate egress PE and reach to the site2.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The security considerations discussed in RFC 5036, RFC 5331, RFC
3209, and RFC 4090 apply to this document.</t>
</section>
<section anchor="ack" title="Acknowledgements">
<t>This document leverages work done by Yakov Rekhter and several others
on LSP tail-end protection. Thanks to Nischal Sheth, Nitin Bahadur,
Yimin shen for their contribution.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC5331;
<reference anchor="RFC4364">
<front>
<title>BGP/MPLS IP Virtual Private Networks (VPNs)</title>
<author fullname="Y. Rekhter" initials="Y." surname="Rekhter">
<organization></organization>
</author>
<author fullname="E. Rosen" initials="E." surname="Rosen">
<organization></organization>
</author>
<date month="February " year="2006" />
<abstract>
<t>This document describes a method by which a Service Provider
may use an IP backbone to provide IP Virtual Private Networks
(VPNs) for its customers. This method uses a "peer model", in
which the customers' edge routers (CE routers) send their routes
to the Service Provider's edge routers (PE routers); there is no
"overlay" visible to the customer's routing algorithm, and CE
routers at different sites do not peer with each other. Data
packets are tunneled through the backbone, so that the core
routers do not need to know the VPN routes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4364" />
<format octets="30779"
target="http://www.rfc-editor.org/rfc/rfc4364.txt" type="TXT" />
</reference>
&RFC5036;
&RFC2205;
&RFC3209;
&RFC4090;
&RFC3471;
&RFC3031;
<reference anchor="LDP-UPSTREAM">
<front>
<title>MPLS Upstream Label Assignment for LDP</title>
<author fullname="Rahul Aggarwal" initials="R" surname="Aggarwal">
<organization>Juniper Networks</organization>
</author>
<author fullname="Jean-Louis Le Roux" initials="J. L. Le"
surname="Roux">
<organization>France Telecom</organization>
</author>
<date year="2011" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-mpls-ldp-upstream" />
<format target="http://tools.ietf.org/html/draft-ietf-mpls-ldp-upstream-10"
type="TXT" />
</reference>
<reference anchor="RSVP-NON-PHP-OOB">
<front>
<title>Non PHP Behavior and out-of-band mapping for RSVP-TE
LSPs</title>
<author fullname="Zafar Ali" initials="A" surname="Ali">
<organization>Cisco Systems, Inc</organization>
</author>
<author fullname="George Swallow" initials="Z" surname="Swallow">
<organization>Cisco Systems, Inc</organization>
</author>
<author fullname="Rahul Aggarwal" initials="R" surname="Aggarwal">
<organization>Juniper Networks</organization>
</author>
<date year="2011" />
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-mpls-rsvp-te-no-php-oob-mapping" />
<format target="http://tools.ietf.org/html/draft-ietf-mpls-rsvp-te-no-php-oob-mapping-07"
type="TXT" />
</reference>
</references>
<references title="Informative References">
&RFC5920;
<reference anchor="RFC5286">
<front>
<title>Basic Specification for IP Fast Reroute: Loop-Free
Alternates</title>
<author fullname="Alia K. Atlas" initials="A" role="editor"
surname="Atlas">
<organization></organization>
</author>
<author fullname="Alex Zinin" initials="A" role="editor"
surname="Zinin">
<organization></organization>
</author>
<date month="September" year=" 2008" />
<abstract>
<t>This document describes the use of loop-free alternates to
provide 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 routers
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 simple approach does not
require any support from other routers. The extent to which this
goal can be met by this specification is dependent on the topology
of the network.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5920" />
<format octets="152830"
target="http://www.rfc-editor.org/rfc/rfc5286.txt" type="TXT" />
</reference>
<reference anchor="RFC5714">
<front>
<title>IP Fast Reroute Framework</title>
<author fullname="Mike Shand" initials="M" surname="Shand"></author>
<author fullname="Stewart Bryant" initials="S" surname="Bryant"></author>
<date month="January " year="2010" />
</front>
<seriesInfo name="RFC" value="5714" />
<format octets="152830"
target="http://www.rfc-editor.org/rfc/rfc5714.txt" type="TXT" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 17:41:44 |