One document matched: draft-minto-2547-egress-node-fast-protection-01.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-01"
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="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 day="22" month="oct" year="2012"/>
<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/>
<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/>
</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 and 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 prefixes.</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 set context-identifier as nexthop for VPN-IPv4 and IPv4-Mapped
context-identifier for VPN-IPv6 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="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 (excluding the RD)</t>
</list></t>
<t>will be eligible as alternate egress PE for prefix.</t>
</section>
</section>
<section anchor="MPLS-egress-frr" title="MPLS egress Fast reroute">
<t>A Protector should able to receive the traffic from PLR in the
event of an egress PE failure with forwarding context that enable
protector to repair the traffic. </t>
<section anchor="RSVP-egress-frr" title="RSVP">
<t>If RSVP LSP is used for transport then protector, primary and PLR
MUST follow backup egress procedure specified in <xref
target="rsvp-egress-frr"/>. So that P router redirects the traffic
during primary PE failure.</t>
</section>
<section anchor="LDP-egress-frr" title="LDP">
<t>If it is LDP LSP then LDP FEC for this LSP MUST be the context
identifier of the protected segment. Prefix LFA or remote prefix LFA
with node protection can be used for redirect traffic to
protector.</t>
</section>
</section>
</section>
<section anchor="PE_failure" title=" Egress node Failure">
<t>This section summarizes the procedures egress protection described
above section for completeness. A Egress PE, Protector, PLR follows the
methods described in [rsvp-egress-frr]. 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 draft is based on the ideas originally developed by JL Le Roux,
Bruno Decraene and Zubair Ahmad. This document leverages work done by
Yakov Rekhter and several others on LSP tail-end protection. Thanks to
Nischal Sheth, Nitin Bahadur, Yimin shen and Maciek Konstantynowicz 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/>
</author>
<author fullname="E. Rosen" initials="E." surname="Rosen">
<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/>
</author>
<author fullname="Alex Zinin" initials="A" role="editor"
surname="Zinin">
<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 fullname="Stewart Bryant" initials="S" surname="Bryant"/>
<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>
<reference anchor="rsvp-egress-frr" target="rsvp egress frr">
<front>
<title>IP Fast Reroute Framework</title>
<author fullname="Jeyananth Minto Jeganathan" initials="J"
surname="Jeganathan"/>
<author fullname="Hannes Gredler" initials="H" surname="Gredler"/>
<author fullname="Yimin Shen" initials="Y" surname="Shen"/>
<date month="Oct " year="2012"/>
</front>
<seriesInfo name="Internet-Draft"
value="draft-minto-rsvp-lsp-egress-fast-protection-01"/>
<format target="http://tools.ietf.org/html/draft-minto-rsvp-lsp-egress-fast-protection-01"
type="TXT"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 17:33:57 |