Internet DRAFT - draft-bashandy-mpls-ldp-bgp-frr
draft-bashandy-mpls-ldp-bgp-frr
Network Working Group A. Bashandy
Internet Draft K. Raza
Intended status: Standards Track Cisco Systems
Expires: September 2012 March 5, 2012
LDP Extension for FRR Edge Node Protection in BGP-Free LDP Core
draft-bashandy-mpls-ldp-bgp-frr-00.txt
Abstract
Consider a BGP free core scenario with LDP running in the core.
Suppose the edge BGP speakers PE1 and PE2 know about a prefix P/m
via the external routers CE1 and CE2. If the edge LSR PE1 crashes
or becomes totally disconnected from the core, it is desirable for a
core LSR "P", that is carrying traffic to the failed edge LSR PE1,
to immediately restore traffic by re-routing packets destined to the
prefix P/m from the LSP terminating on PE1 to be forwarded over the
LSP terminating on PE2, until BGP reconverges. If the packets
originally flowing to the failed edge LSR PE1 are BGP labeled, then
the repairing core LSR P must swap the label (corresponding to
prefix P/m) advertised by the failed edge LSR PE1 with the label
advertised for the same prefix by the edge LSR PE2 before re-routing
the packets through an LSP terminating on PE2. To implement BGP edge
node protection in a BGP-free LDP core, this document proposes an
extension to LDP. This extension allows an LDP speaker running on a
Edge LSR Node (e.g. PE1) to inform the LDP speakers running on core
LSRs about the "Repair" edge LSR (e.g. PE2), as well as Repair LSR's
label for prefix P/m, if any.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s)
controlling the copyright in such materials, this document may not
be modified outside the IETF Standards Process, and derivative
works of it may not be created outside the IETF Standards Process,
except to format it for publication as an RFC or to translate it
into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
Bashandy Expires September 5, 2012 [Page 1]
Internet-Draft LDP Extension for FRR Edge Node March 2012
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 5, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) 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.
Table of Contents
1. Introduction...................................................3
1.1. Conventions used in this document.........................4
1.2. Terminology...............................................4
1.3. Problem definition........................................5
2. The Proposed LDP Extension.....................................5
2.1. The LDP "BGP Repair Path status" Code.....................5
2.2. The LDP "BGP Repair Path Status" TLV......................6
2.3. LDP Capability Negotiation................................8
2.4. BGP Repair Status in a LDP Notification message...........8
3. BGP Repair Path Signaling Procedures...........................9
3.1. Signaling a BGP Repair Path...............................9
3.2. Updating a BGP Repair Path...............................10
3.3. Withdrawing a BGP Repair Path............................10
Bashandy Expires September 5, 2012 [Page 2]
Internet-Draft LDP Extension for FRR Edge Node March 2012
4. Security Considerations.......................................10
5. IANA Considerations...........................................11
6. Conclusions...................................................11
7. References....................................................11
7.1. Normative References.....................................11
7.2. Informative References...................................11
8. Acknowledgments...............................................12
1. Introduction
In a BGP free core, where traffic is tunneled between edge
routers/LSRs, (MP)BGP [2][3] speakers advertise reachability
information about prefixes to edge routers only. For labeled
address families, namely AFI/SAFI 1/4, 2/4, 1/128, and 2/128, an
edge LSR assigns local labels to prefixes and associates the local
label with each advertised prefix such as L3VPN [9], 6PE [10], and
Softwire [8]. Suppose that a given edge LSR is chosen as the best
next-hop for a prefix P/m. An ingress LSR receives a packet
destined for the prefix P/m from an external router, and sends the
packet to that egress LSR through an LSP terminating on the egress
LSR. If the prefix P/m is a BGP labeled prefix, the ingress LSR
pushes the BGP label advertised by the egress LSR before sending
the packet into the LDP LSP terminating on the egress LSR. Upon
receiving the packet from the core, the egress LSR takes the
appropriate forwarding decision based on the content of the packet
and/or the label(s) pushed on the packet.
In modern networks with redundancy in place, it is not uncommon to
have a prefix reachable via multiple edge routers. One example is
the best external path [7]. Another more common and widely deployed
scenario is L3VPN [9] with multi-homed VPN sites. As an example,
consider the L3VPN topology depicted in Figure 1.
Bashandy Expires September 5, 2012 [Page 3]
Internet-Draft LDP Extension for FRR Edge Node March 2012
PE1
\
\
\
\
CE1....... VPN prefix
/ (10.0.0.0/8)
/
/
/
iPE ----- LDP core P----PE0
\
\
\
\
CE2....... VPN prefix
/ (20.0.0.0/8)
/
/
/
PE2
Figure 1 VPN prefix reachable via multiple PEs
As illustrated in Figure 1, the edge router PE0 is the primary NH
for both 10.0.0.0/8 and 20.0.0.0/8. At the same time, both
10.0.0.0/8 and 20.0.0.0/8 are reachable through the other edge
routers PE1 and PE2, respectively.
1.1. Conventions used in this document
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 [1].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
1.2. Terminology
o LSR : Label Switched Router (In the context of this document,
this refers to a router doing label switching on LDP and/or BGP
labels)
o LSP: Label Switched Path
Bashandy Expires September 5, 2012 [Page 4]
Internet-Draft LDP Extension for FRR Edge Node March 2012
o Primary LSP: It is the LSP from the ingress PE to the primary
egress PE. This is the LDP implementation of the primary tunnel
defined in [6].
o Repair LSP: It is the LSP from the repairing P router to the
repair egress PE. This is the LDP implementation of the repair
tunnel defined in [6].
For the rest of the terms, refer to [6].
1.3. Problem definition
The general problem for the example shown in Section 1. is specified
in [6]. The objective of this document is to specify an LDP [4]
extension to let the primary egress PE inform repairing core
router(s) about the repair path in an LDP core for both labeled and
unlabeled protected prefixes. In other words, this is an LDP-based
implementation of step 3 in [6]. Other problems, such as determining
the repair PE, detecting the protected PE (node/connectivity)
failure, and interactions between LDP and BGP on protected edge PE
LSR, are beyond the scope of this document.
2. The Proposed LDP Extension
As specified in [4] section 3.5.1, an LDP speaker can use LDP
Notification message to send its status or advisory information
towards a peer. An LDP Notification message consists of a Status TLV
and optional parameters, whereas "Status" TLV holds the status code
being signaled. For an egress PE LSR to convey repair path info (for
a BGP next-hop) to core LSRs, we propose to convey this information
via a LDP Notification message that carries a new status code in "LDP
Status" TLV, a new "BGP Repair Path Status" TLV and FEC TLV
(corresponding to BGP next-hop) as optional parameters. This
information is to be advertised to a peer only if the peer has
signaled the support for "Unrecognized Notification" capability a
specified in [5].
The proposed extensions are described more in details in following
sub-sections.
2.1. The LDP "BGP Repair Path status" Code
A new LDP status code, namely "BGP Repair Path status" is defined
that is to be set in the "Status Code" field of the "Status TLV" as
defined in [4] section 3.4.6.
Bashandy Expires September 5, 2012 [Page 5]
Internet-Draft LDP Extension for FRR Edge Node March 2012
2.2. The LDP "BGP Repair Path Status" TLV
A new LDP TLV, namely "BGP Repair Path Status TLV", is defined to be
used in an LDP Notification message under optional parameters section
only if the Notification message status code is set to "BGP Repair
Path status".
This TLV is an implementation of the repair path defined in [6] and
is used to convey the information about the Repair edge LSR and its
associated BGP label, if any, for traffic destination prefix P/m.
This information is conveyed in the context of the protected primary
BGP nexthop [6], whose information is carried in the FEC TLV. This
document allows only one repair path per BGP nexthop.
The encoding of the "BGP Repair Path Status TLV" is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Repair Path TLV Type(TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|L|P| Reserved | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Repair PE Address (variable size) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Underlying Repair label (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Format of BGP Repair Path Status TLV
The fields are as follows
U/F:
Must be set to 1/0 respectively so that this TLV can be
ignored if not known or not supported.
Repair Path TLV Type:
IANA assigned TLV value
A bit
Indicates if Repair Path information is to be "added" or
"removed". MUST be set to 1 to signal addition of the
information, and set to signal addition of the information,
and set to
L Bit:
Bashandy Expires September 5, 2012 [Page 6]
Internet-Draft LDP Extension for FRR Edge Node March 2012
Indicates whether optional "Underlying Repair Label" [6] field
is present or not. Must be set to 1 if the TLV also
contains/encodes "Underlying Repair Label", else must be set
to 0. This bit MUST be set to 0 when A bit is set to 0.
P Bit:
If set, then the label in the "Underlying Repair label" sub
field MUST be pushed instead of swapped. The "P" bit has the
same semantics of the "Push" flag in [6]. If the "L" bit is
zero then the "P" bit MUST be set to zero.
Reserved:
MUST be zero on transmit and ignored in receipt
Address Family
Identical to the "Address Family" field used in encoding the
Prefix FEC element value specified in Section 3.4.1 in [4]. May
be different of the address family of the prefix in the FEC
Repair PE Address
The length of this field is dependent on the Address Family
field. This is either the 4 octet IPv4 address or 16 octet
IPv6 address of a host address belonging to repair PE. The
encoding of the Repair PE Address is identical to the encoding
of the value of the IPv4 or IPv6 Transport Address TLV
specified in Section 3.5.2 in [4]. This field encodes the
"Repair Next-hop" defined in [6].
Underlying Repair Label (optional)
If included in the TLV, it is a single label defined in
accordance to Generic Label TLV specified in Section 3.4.2.1 in
[4]. This field encodes the "Underlying Repair Label" defined
in [6].
Length
The length (in octets) of the TLV following the "Length" field.
For example, the length MUST be 8 with IPv4 Repair PE address
or 20 with IPv6 Repair PE address when L bit is set to 0, and
MUST be 12 and 24 octets otherwise for IPV4 and IPv6 address
families, respectively.
Bashandy Expires September 5, 2012 [Page 7]
Internet-Draft LDP Extension for FRR Edge Node March 2012
2.3. LDP Capability Negotiation
This BGP Repair Path information is to be computed by an edge PE LSR
under a user configuration control. Once computed, this information
can be unsolicitedly sent to core P LSRs for edge PE node protection,
and it is up to the receiving P LSR to store and use this information
to protect the edge PE LSR.
Given above procedures, no new LDP capability [RFC5561] negotiation
is needed between PE and P LSRs to support this feature extensions.
However, to ensure backward compatibility and deterministic behavior,
it is required that this information be sent to only those P LSRs
that support "Unrecognized Notification" capability as specified in
[5]. This will ensure that these new status and TLV does not cause
any issue at a receiving P LSR if not known or not supported, and be
discarded in accordance with "Unrecognized Notification" procedures.
2.4. BGP Repair Status in a LDP Notification message
The general format of an LDP Notification message that carries
information regarding BGP repair path is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Repair Path Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 : LDP Notification message with BGP Repair Status
The "Status TLV" status code is set to "BGP Repair Path status" to
indicate that the message is used to convey BGP Repair Path
information. When this status code is set, a Notification message
MUST contain both "BGP Repair Status TLV" and a "FEC TLV" in the
message.
Since this notification does not refer to any particular message, the
"Message ID" and "Message Type" fields in the "Status TLV" MUST be
set to 0.
Bashandy Expires September 5, 2012 [Page 8]
Internet-Draft LDP Extension for FRR Edge Node March 2012
The "BGP Repair Path Status TLV" is encoded as described earlier.
The FEC TLV MUST contain a single "Prefix FEC Element" that encodes
the BGP nexthop information as host prefix. This field encodes the
"Primary Next-hop" defined in [6].
3. BGP Repair Path Signaling Procedures
To describe the signaling procedures clearly, let's first assume
that:
o Protected edge LSR is PE1, Repair edge LSR is PE2 and repairing
core LSR is P1 LSR router, and P2 is also a core LSR that does not
support BGP Repair Path functionality.
o IPv4 Host addresses for PE1 and PE2 are A1 and A2 respectively.
o Protected BGP IPv4 prefix is P/m.
o BGP label assigned by PE2 for P/m is L2.
o P1 and P2 LSR support LDP "Unrecognized Notification" Capability.
3.1. Signaling a BGP Repair Path
An operator enables this feature on PE1 using a configuration knob.
The PE1 computes Repair PE information (PE2 address A2, and PE2 BGP
label L2) for a given BGP prefix P/m. PE1 encodes the LDP
Notification to advertise the Repair path information to all those
core LSR peers (including P1/P2 LSRs) who have advertised
"Unrecognized Notification" Capability TLV for given LDP session.
The PE1 LSR encodes the following TLVs:
o "Status" TLV: status code is set to "BGP Repair Path status"
and "Message Type" and Message ID fields set to 0.
o "BGP Repair Path Status" TLV: This TLV is encoded with A-bit
set to 1, L-bit set to 1, P-bit set to 0, Address Family set
to 1 (IPv4), "Repair PE Address" field populated with A2, and
"Repair PE's Label" field set to L2.
o "FEC" TLV: This TLV is encoded with a single "Prefix FEC
Element" whose Address Family is set to 1 (IPv4) to indicate
IPV4 prefix, and prefix P/m encoded accordingly.
After encoding these TLVs, PE1 LSR bundles them in an LDP
Notification message, as shown in Figure 3, and sends them to its
upstream core peer P1 and P2 LSRs.
Bashandy Expires September 5, 2012 [Page 9]
Internet-Draft LDP Extension for FRR Edge Node March 2012
On receipt of this information, P1 stores this information and uses
this to fast reroute the BGP destined traffic to PE2 upon PE2
node/connectivity failure detection. P2, on the other hand, does not
recognize this new status in the LDP Notification message and hence
discards it silently.
In order to be able to protect primary BGP nexthops, it is required
that the repairing P LSR (P1) must have a LSP terminating on Repair
PE host prefix (as indicated by "Repair PE Address" field in the
received "BGP Repair Path Status" TLV).
3.2. Updating a BGP Repair Path
The repair path information is identified by
o the "primary next-hop" encoded in the "FEC TLV" shown in
Figure 3 and,
o the "Repair Next-hop" encoded in the "Repair PE Address" shown
in Figure 2.
Once a repair path has been signaled to P core LSR, it can be updated
by simply sending another LDP Notification message using the
procedures described in the previous section.
Upon receipt of a new repair path information, the LDP receiver (P1
LSR) MUST discard any previously learnt Repair information from the
sending PE1 LSR, and update it with the most recently received.
3.3. Withdrawing a BGP Repair Path
Once a repair path has been signaled to P core LSR, it can be
withdrawn by simply sending another LDP Notification message using
the procedures described in the previous section with following
changes:
o Set A-bit, L-bit, and P-bit in "BGP Repair Path Status" TLV to
0
o No "Underlying Repair Label" field included
Upon receipt of a withdrawal of a repair path, the LDP receiver (P1
LSR) MUST discard any previously learnt Repair information from the
sending PE1 LSR for a given BGP prefix.
4. Security Considerations
No additional security risk is introduced by using the mechanisms
proposed in this document
Bashandy Expires September 5, 2012 [Page 10]
Internet-Draft LDP Extension for FRR Edge Node March 2012
5. IANA Considerations
This document introduces the following new protocol elements that
require code point assignment by IANA:
o "BGP Repair Path status" status code from "LDP Status Code Name
Space" registry (requested code point: 0x00000050)
o "BGP Repair Path Status TLV" from "LDP TLV Type Name Space"
registry (requested code point: 0x050F)
6. Conclusions
This document proposes a an LDP extension that allows an egress PE
to advertise a repair path consisting of a repair egress PE and an
underlying label to repairing core router. Advertising this
information to core routers allows core routers to provide FRR
protection against primary egress PE node failure while keeping the
core BGP-free.
7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol
4 (BGP-4), RFC 4271, January 2006
[3] Bates, T., Chandra, R., Katz, D., and Rekhter Y.,
"Multiprotocol Extensions for BGP", RFC 4760, January 2007
[4] Anderson, L., Minei, I., and Thomas, B., "LDP
Specifications", RFC 5036, October 2007
[5] R. Asati, P. Mohapatra, E. Chen, B. Thomas, " Signaling LDP
Label Advertisement Completion", RFC5919, August 2010
7.2. Informative References
[6] Bashandy, A., Pithawala, B., and Patel, K., "Scalable BGP FRR
Protection against Edge Node Failure", draft-bashandy-bgp-
edge-node-frr-02.txt, January 2012
[7] Marques,P., Fernando, R., Chen, E, Mohapatra, P.,
"Advertisement of the best external route in BGP", draft-
ietf-idr-best-external-02.txt, April 2004.
Bashandy Expires September 5, 2012 [Page 11]
Internet-Draft LDP Extension for FRR Edge Node March 2012
[8] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", RFC 5565, June 2009.
[9] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[10] De Clercq, J. , Ooms, D., Prevost, S., Le Faucheur, F.,
Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider
Edge Routers (6PE)", RFC 4798, February 2007
[11] Atlas, A. and A. Zinin, "Basic Specification for IP Fast
Reroute: Loop-Free Alternates", RFC 5286, September 2008.
[12] Shand, S., and Bryant, S., "IP Fast Reroute", RFC5714,
January 2010
[13] Shand, M. and S. Bryant, "A Framework for Loop-Free
Convergence", RFC 5715, January 2010.
[14] Rosen, E., Biswanathan, A., and Callon, A. "Multiprotocol
Label Switching Architecture", RFC3031, January 2001
8. Acknowledgments
Special thanks to Keyur Patel and Alton Lo for the valuable help.
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Ahmed Bashandy
Cisco Systems
170 West Tasman Dr, San Jose, CA 95134
Email: bashandy@cisco.com
Kamran Raza
Cisco Systems,
2000 Innovation Dr., Kanata, ON K2K 3E8, Canada
EMail: skraza@cisco.com
Bashandy Expires September 5, 2012 [Page 12]
