draft-ietf-bess-fat-pw-bgp-04.txt   rfc8395.txt 
INTERNET-DRAFT K. Patel Internet Engineering Task Force (IETF) K. Patel
Intended Status: Standard Track Arrcus Request for Comments: 8395 Arrcus
Updates: 4761 S. Boutros Updates: 4761 S. Boutros
VMware Category: Standards Track VMware
J. Liste ISSN: 2070-1721 J. Liste
Cisco Cisco
B. Wen B. Wen
Comcast Comcast
J. Rabadan J. Rabadan
Nokia Nokia
June 2018
Expires: September 3, 2018 March 2, 2018 Extensions to BGP-Signaled Pseudowires to
Support Flow-Aware Transport Labels
Extensions to BGP Signaled Pseudowires to support Flow-Aware Transport
Labels
draft-ietf-bess-fat-pw-bgp-04
Abstract Abstract
This draft defines protocol extensions required to synchronize flow This document defines protocol extensions required to synchronize
label states among Provider Edges PE(s) when using the BGP-based flow label states among Provider Edges (PEs) when using the BGP-based
signaling procedures. These protocol extensions are equally signaling procedures. These protocol extensions are equally
applicable to point-to-point Layer2 Virtual Private Networks applicable to point-to-point Layer 2 Virtual Private Networks
(L2VPNs). This draft updates RFC 4761 by defining new flags in the (L2VPNs). This document updates RFC 4761 by defining new flags in
Control Flags field of the Layer2 Info Extended Community. the Control Flags field of the Layer2 Info Extended Community.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
http://www.ietf.org/1id-abstracts.html (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.
The list of Internet-Draft Shadow Directories can be accessed at Information about the current status of this document, any errata,
http://www.ietf.org/shadow.html and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8395.
Copyright and License Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
1.1 Requirements Language . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language ......................................3
2. Modifications to Layer2 Info Extended Community . . . . . . . . 5 2. Modifications to the Layer2 Info Extended Community .............4
3. Signaling the Presence of the Flow Label . . . . . . . . . . . 6 3. Signaling the Presence of the Flow Label ........................5
4 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations .............................................6
5 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations .........................................6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. References ......................................................7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References .......................................7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Informative References .....................................7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 Acknowledgements ...................................................8
8.2. Informative References . . . . . . . . . . . . . . . . . . 9 Contributors .......................................................8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses .................................................9
1 Introduction 1. Introduction
The mechanism described in [RFC6391] uses an additional label (Flow The mechanism described in [RFC6391] uses an additional label (Flow
Label) in the MPLS label stack to allow Label Switch Routers to Label) in the MPLS label stack to allow Label Switching Routers
balance flows within Pseudowires at a finer granularity than the (LSRs) to balance flows within Pseudowires (PWs) at a finer
individual Pseudowires across the Equal Cost Multiple Paths (ECMPs) granularity than the individual PWs across the Equal Cost Multiple
that exists within the Packet Switched Network (PSN). Paths (ECMPs) that exists within the Packet Switched Network (PSN).
Furthermore, [RFC6391] defines the LDP protocol extensions required Furthermore, [RFC6391] defines the LDP protocol extensions required
to synchronize the flow label states between the ingress and egress to synchronize the flow label states between the ingress and egress
PEs when using the signaling procedures defined in the [RFC8077]. PEs when using the signaling procedures defined in the [RFC8077].
A pseudowire (PW) [RFC3985] is transported over one single network A PW [RFC3985] is transported over one single network path, even if
path, even if Equal Cost Multiple Paths (ECMPs) exist between the ECMPs exist between the ingress and egress PW provider edge (PE)
ingress and egress PW provider edge (PE) equipment. This is required equipment. This is required to preserve the characteristics of the
to preserve the characteristics of the emulated service. emulated service.
This draft introduces an optional mode of operation allowing to This document introduces an optional mode of operation allowing a PW
transport a PW over ECMPs, for example when the use of these is known to be transported over ECMPs, for example when the use of ECMPs is
to be beneficial to the operation of the PW. This specification uses known to be beneficial to the operation of the PW. This
the principles defined in [RFC6391], and augments the BGP-signaling specification uses the principles defined in [RFC6391] and augments
procedures of [RFC4761] and [RFC6624]. The use of a single path to the BGP-signaling procedures of [RFC4761] and [RFC6624]. The use of
preserve the packet delivery order remains the default mode of a single path to preserve the packet delivery order remains the
operation of a PW, and is described in [RFC4385] and [RFC4928]. default mode of operation of a PW and is described in [RFC4385] and
[RFC4928].
High bandwidth Ethernet-based services are a prime example that High-bandwidth Ethernet-based services are a prime example that use
benefits from the ability to load-balance flows in a PW over multiple of the optional mode benefits from the ability to load-balance flows
PSN paths. In general, load-balancing is applicable when the PW in a PW over multiple PSN paths. In general, load-balancing is
attachment circuit bandwidth and PSN core link bandwidth are of same applicable when the PW attachment circuit bandwidth and PSN core link
order of magnitude. bandwidth are of the same order of magnitude.
To achieve the load-balancing goal, [RFC6391] introduces the notion To achieve the load-balancing goal, [RFC6391] introduces the notion
of an additional Label Stack Entry (LSE) (Flow label) located at the of an additional Label Stack Entry (LSE) (flow label) located at the
bottom of the stack (right after PW LSE). Label Switching Routers bottom of the stack (right after PW LSE). LSRs commonly generate a
(LSRs) commonly generate a hash of the label stack in order to hash of the label stack in order to discriminate and distribute flows
discriminate and distribute flows over available ECMPs. The presence over available ECMPs. The presence of the flow label (closely
of the Flow label (closely associated to a flow determined by the associated to a flow determined by the ingress PE) will normally
ingress PE) will normally provide the greatest entropy. provide the greatest entropy.
Furthermore, following the procedures for Inter-AS scenarios Furthermore, following the procedures for inter-AS scenarios
described in [RFC4761] section 3.4, the Flow label should never be described in Section 3.4 of [RFC4761], the flow label should never be
handled by the ASBRs, only the terminating PEs on each AS will be handled by the ASBRs; only the terminating PEs on each AS will be
responsible for popping or pushing this label. This is equally responsible for popping or pushing this label. This is equally
applicable to Method B [RFC4761] section 3.4.2 where ASBRs are applicable to Method B as described in Section 3.4.2 of [RFC4761],
responsible for swapping the PW label as traffic traverses from ASBR where ASBRs are responsible for swapping the PW label as traffic
to PE and ASBR to ASBR directions. Therefore, the Flow label will traverses from ASBR to PE and ASBR to ASBR. Therefore, the flow
remain untouched across AS boundaries. label will remain untouched across AS boundaries.
1.1 Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Modifications to Layer2 Info Extended Community 2. Modifications to the Layer2 Info Extended Community
The Layer2 Info Extended Community is used to signal control The Layer2 Info Extended Community is used to signal control
information about the pseudowires to be setup. The extended community information about the PWs to be set up. The Extended Community
format is described in [RFC4761]. The format of this extended format is described in [RFC4761]. The format of this Extended
community is described as: Community is described as:
+------------------------------------+ +------------------------------------+
| Extended community type (2 octets) | | Extended Community type (2 octets) |
+------------------------------------+ +------------------------------------+
| Encaps Type (1 octet) | | Encaps Type (1 octet) |
+------------------------------------+ +------------------------------------+
| Control Flags (1 octet) | | Control Flags (1 octet) |
+------------------------------------+ +------------------------------------+
| Layer-2 MTU (2 octet) | | Layer-2 MTU (2 octets) |
+------------------------------------+ +------------------------------------+
| Reserved (2 octets) | | Reserved (2 octets) |
+------------------------------------+ +------------------------------------+
Figure 1: Layer2 Info Extended Community Figure 1: Layer2 Info Extended Community
Control Flags: Control Flags:
This field contains bit flags relating to the control information This field contains bit flags relating to the control information
about pseudowires. This field is augmented with a definition of 2 new about PWs. This field is augmented with a definition of two new
flags field. flags fields.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Z|Z|Z|Z|T|R|C|S| (Z = MUST Be Zero) |Z|Z|Z|Z|T|R|C|S| (Z = MUST Be Zero)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 2: Control Flags Bit Vector Figure 2: Control Flags Bit Vector
With reference to the Control Flags Bit Vector, the following bits in With reference to the Control Flags Bit Vector, the following bits in
the Control Flags are defined; the remaining bits, designated Z, MUST the Control Flags are defined. The remaining bits, designated "Z",
be set to zero when sending and MUST be ignored when receiving this MUST be set to zero when sending and MUST be ignored when receiving
Extended Community. this Extended Community.
T When the bit value is 1, the PE announce the ability T When the bit value is 1, the PE announces the ability to send
to send a Pseudowire packet that includes a flow label. a PW packet that includes a flow label. When the bit value is
When the bit value is 0, the PE is indicating that it will 0, the PE is indicating that it will not send a PW packet
not send a Pseudowire packet containing a flow label. containing a flow label.
R When the bit value is 1, the PE is able to receive a R When the bit value is 1, the PE is able to receive a PW packet
Pseudowire packet with a flow label present. When the bit with a flow label present. When the bit value is 0, the PE is
value is 0, the PE is unable to receive a Pseudowire packet unable to receive a PW packet with the flow label present.
with the flow label present.
C Defined in [RFC4761]. C Defined in [RFC4761].
S Defined in [RFC4761]. S Defined in [RFC4761].
3. Signaling the Presence of the Flow Label 3. Signaling the Presence of the Flow Label
As part of the Pseudowire signaling procedures described in As part of the PW signaling procedures described in [RFC4761], a
[RFC4761], a Layer2 Info Extended Community is advertised in the VPLS Layer2 Info Extended Community is advertised in the Virtual Private
BGP NLRI. LAN Service (VPLS) BGP Network Layer Reachability Information (NLRI).
A PE that wishes to send a flow label in a Pseudowire packet MUST A PE that wishes to send a flow label in a PW packet MUST include in
include in its VPLS BGP NLRI a Layer2 Info Extended Community using its VPLS BGP NLRI a Layer2 Info Extended Community using Control
Control Flags field with T = 1. Flags field with T = 1.
A PE that is willing to receive a flow label in a Pseudowire packet A PE that is willing to receive a flow label in a PW packet MUST
MUST include in its VPLS BGP NLRI a Layer2 Info Extended Community include in its VPLS BGP NLRI a Layer2 Info Extended Community using
using Control Flags field with R = 1. Control Flags field with R = 1.
A PE that receives a VPLS BGP NLRI containing a Layer2 Info Extended A PE that receives a VPLS BGP NLRI containing a Layer2 Info Extended
Community with R = 0 MUST NOT include a flow label in the Pseudowire Community with R = 0 MUST NOT include a flow label in the PW packet.
packet.
Therefore, a PE sending a Control Flags field with T = 1 and Therefore, a PE sending a Control Flags field with T = 1 and
receiving a Control Flags field with R = 1 MUST include a flow label receiving a Control Flags field with R = 1 MUST include a flow label
in the Pseudowire packet. Under all other combinations, a PE MUST in the PW packet. With any other combination, a PE MUST NOT include
NOT include a flow label in the Pseudowire packet. a flow label in the PW packet.
A PE MAY support the configuration of the flow label (T and R bits) A PE MAY support the configuration of the flow label (T and R bits)
on a per-service (e.g., VPLS VFI) basis. Furthermore, it is also on a per-service basis (e.g., a VPLS VPN Forwarding Instance (VFI)).
possible that on a given service, PEs may not share the same flow Furthermore, it is also possible that on a given service, PEs may not
label settings. The presence of a flow label is therefore determined share the same flow label settings. The presence of a flow label is
on a per-peer basis and according to the local and remote T and R bit therefore determined on a per-peer basis and according to the local
values. For example, a PE part of a VPLS and with a local T = 1, and remote T and R bit values. For example, a PE part of a VPLS and
must only transmit traffic with a flow label to those peers that with a local T = 1 must only transmit traffic with a flow label to
signaled R = 1. And if the same PE has local R = 1, it must only those peers that signaled R = 1. If the same PE has local R = 1, it
expect to receive traffic with a flow label from peers with T = 1. must only expect to receive traffic with a flow label from peers with
Any other traffic must not have a flow label. A PE expecting to T = 1. Any other traffic must not have a flow label. A PE expecting
receive traffic from a remote peer with a flow label MAY drop traffic to receive traffic from a remote peer with a flow label MAY drop
that has no flow label. A PE expecting to receive traffic from a traffic that has no flow label. A PE expecting to receive traffic
remote peer with no flow label MAY drop traffic that has flow label. from a remote peer with no flow label MAY drop traffic that has a
flow label.
Modification of flow label settings may impact traffic over a PW as Modification of flow label settings may impact traffic over a PW, as
these could trigger changes in the PEs data-plane programming (i.e. these could trigger changes in the PEs data-plane programming (i.e.,
imposition / disposition of flow label). This is an implementation imposition/disposition of the flow label). This is an
specific behavior and outside the scope of this draft. implementation-specific behavior and is outside the scope of this
document.
The signaling procedures in [RFC4761] state that the unspecified bits The signaling procedures in [RFC4761] state that the unspecified bits
in the Control Flags field (bits 0-5) MUST be set to zero when in the Control Flags field (bits 0-5) MUST be set to zero when
sending and MUST be ignored when receiving. The signaling procedure sending and MUST be ignored when receiving. The signaling procedure
described here is therefore backwards compatible with existing described here is therefore backwards compatible with existing
implementations. A PE not supporting the extensions described in implementations. A PE not supporting the extensions described in
this draft will always advertise a value of ZERO in the position this document will always advertise a value of zero in the R bit;
assigned by this draft to the R bit and therefore a flow label will therefore, a flow label will never be included in a packet sent to it
never be included in a packet sent to it by one of its peers. by one of its peers. Similarly, it will always advertise a value of
Similarly, it will always advertise a value of ZERO in the position zero in the T bit; therefore, a peer will know that a flow label will
assigned by this draft to the T bit and therefore a peer will know never be included in a packet sent by it.
that a flow label will never be included in a packet sent by it.
Note that what is signaled is the desire to include the flow LSE in Note that what is signaled is the desire to include the flow LSE in
the label stack. The value of the flow label is a local matter for the label stack. The value of the flow label is a local matter for
the ingress PE, and the label value itself is not signaled. the ingress PE, and the label value itself is not signaled.
4 Acknowledgements 4. IANA Considerations
The authors would like to thank Bertrand Duvivier and John Drake for
their review and comments.
5 Contributors
In addition to the authors listed above, the following individuals
also contributed to this document:
Eric Lent
John Brzozowski
Steven Cotter
6. IANA Considerations
Although [RFC4761] defined a Control Flags Bit Vector as part of the Although [RFC4761] defined a Control Flags Bit Vector as part of the
Layer2 Info Extended Community, it did not ask for the creation of a Layer2 Info Extended Community, it did not ask for the creation of a
registry. registry.
This document requests that IANA creates a registry for this bit Per this document, IANA has created the "Layer2 Info Extended
vector and that it be called the "Layer2 Info Extended Community Community Control Flags Bit Vector" registry
Control Flags Bit Vector" registry. <https://www.iana.org/assignments/bgp-extended-communities>.
This registry should be created here:
https://www.iana.org/assignments/bgp-extended-communities/bgp-
extended-communities.xhtml.
Considering [RFC4761] and this document, the initial registry is as Based on [RFC4761] and this document, the initial contents of this
follows: registry are as follows:
Value Name Reference Value Name Reference
----- -------------------------------- -------------- ----- -------------------------------- --------------
S Sequenced delivery of frames RFC4761 T Request to send a flow label This document
C Presence of a Control Word RFC4761 R Ability to receive a flow label This document
T Request to send a flow label This document C Presence of a Control Word RFC 4761
R Ability to receive a flow label This document S Sequenced delivery of frames RFC 4761
As per [RFC4761] and this document, the remaining bits are As per [RFC4761] and this document, the remaining bits are
unassigned, and MUST be set to zero when sending and MUST be ignored unassigned, and MUST be set to zero when sending and MUST be ignored
when receiving the Layer2 Info Extended Community. when receiving the Layer2 Info Extended Community.
7. Security Considerations 5. Security Considerations
This extension to BGP does not change the underlying security issues This extension to BGP does not change the underlying security issues
inherent in the existing [RFC4271] and [RFC4761]. inherent in [RFC4271] and [RFC4761].
8. References 6. References
8.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March Requirement Levels", BCP 14, RFC 2119,
1997, <http://www.rfc-editor.org/info/rfc2119>. DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed.,
Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271,
January 2006, <http://www.rfc-editor.org/info/rfc4271>. DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC LAN Service (VPLS) Using BGP for Auto-Discovery and
4761, DOI 10.17487/RFC4761, January 2007, <http://www.rfc- Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
editor.org/info/rfc4761>. <https://www.rfc-editor.org/info/rfc4761>.
[RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V.,
Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over Regan, J., and S. Amante, "Flow-Aware Transport of
an MPLS Packet Switched Network", RFC 6391, DOI 10.17487/RFC6391, Pseudowires over an MPLS Packet Switched Network",
November 2011, <http://www.rfc-editor.org/info/rfc6391>. RFC 6391, DOI 10.17487/RFC6391, November 2011,
<https://www.rfc-editor.org/info/rfc6391>.
[RFC8126] M. Cotton, et al., "Guidelines for Writing an IANA [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
Considerations Section in RFCs", RFC 8126, DOI 10.17487/RFC6391, June RFC 2119 Key Words", BCP 14, RFC 8174,
2017, <http://www.rfc-editor.org/info/rfc8126>. DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References 6.2. Informative References
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation [RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, Edge-to-Edge (PWE3) Architecture", RFC 3985,
March 2005, <http://www.rfc-editor.org/info/rfc3985>. DOI 10.17487/RFC3985, March 2005,
<https://www.rfc-editor.org/info/rfc3985>.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, February 2006, Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
<http://www.rfc-editor.org/info/rfc4385>. February 2006, <https://www.rfc-editor.org/info/rfc4385>.
[RFC8077] Martini, L., and G. Heron, "Pseudowire Setup and [RFC8077] Martini, L., Ed., and G. Heron, Ed., "Pseudowire Setup and
Maintenance Using the Label Distribution Protocol (LDP)", RFC 8077, Maintenance Using the Label Distribution Protocol (LDP)",
DOI 10.17487/RFC8077, February 2017, <http://www.rfc- STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017,
editor.org/info/rfc8077>. <https://www.rfc-editor.org/info/rfc8077>.
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, DOI Cost Multipath Treatment in MPLS Networks", BCP 128,
10.17487/RFC4928, June 2007, <http://www.rfc- RFC 4928, DOI 10.17487/RFC4928, June 2007,
editor.org/info/rfc4928>. <https://www.rfc-editor.org/info/rfc4928>.
[RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2
Virtual Private Networks Using BGP for Auto-Discovery and Signaling", Virtual Private Networks Using BGP for Auto-Discovery and
RFC 6624, DOI 10.17487/RFC6624, May 2012, <http://www.rfc- Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012,
editor.org/info/rfc6624>. <https://www.rfc-editor.org/info/rfc6624>.
Acknowledgements
The authors would like to thank Bertrand Duvivier and John Drake for
their review and comments.
Contributors
In addition to the authors listed above, the following individuals
also contributed to this document:
Eric Lent
John Brzozowski
Steven Cotter
Authors' Addresses Authors' Addresses
Keyur Patel Keyur Patel
Arrcus Arrcus
Email: keyur@arrcus.com Email: keyur@arrcus.com
Sami Boutros Sami Boutros
VMware VMware
Email: sboutros@vmware.com
Email: boutros.sami@gmail.com
Jose Liste Jose Liste
Cisco Cisco
Email: jliste@cisco.com Email: jliste@cisco.com
Bin Wen Bin Wen
Comcast Comcast
Email: bin_wen@cable.comcast.com Email: bin_wen@cable.comcast.com
Jorge Rabadan Jorge Rabadan
Nokia Nokia
Email: jorge.rabadan@nokia.com Email: jorge.rabadan@nokia.com
 End of changes. 66 change blocks. 
212 lines changed or deleted 210 lines changed or added

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