draft-ietf-bess-evpn-overlay-09.txt   draft-ietf-bess-evpn-overlay-10.txt 
skipping to change at page 1, line 16 skipping to change at page 1, line 16
Juniper Juniper
N. Bitar N. Bitar
Nokia Nokia
R. Shekhar R. Shekhar
Juniper Juniper
J. Uttaro J. Uttaro
AT&T AT&T
W. Henderickx W. Henderickx
Nokia Nokia
Expires: May 7, 2018 December 7, 2017 Expires: May 8, 2018 December 8, 2017
A Network Virtualization Overlay Solution using EVPN A Network Virtualization Overlay Solution using EVPN
draft-ietf-bess-evpn-overlay-09 draft-ietf-bess-evpn-overlay-10
Abstract Abstract
This document specifies how Ethernet VPN (EVPN) can be used as a This document specifies how Ethernet VPN (EVPN) can be used as a
Network Virtualization Overlay (NVO) solution and explores the Network Virtualization Overlay (NVO) solution and explores the
various tunnel encapsulation options over IP and their impact on the various tunnel encapsulation options over IP and their impact on the
EVPN control-plane and procedures. In particular, the following EVPN control-plane and procedures. In particular, the following
encapsulation options are analyzed: VXLAN, NVGRE, and MPLS over GRE. encapsulation options are analyzed: VXLAN, NVGRE, and MPLS over GRE.
This document also specifies new multi-homing procedures for split- This specification is also applicable to GENEVE encapsulation;
horizon filtering and mass-withdraw. It also specifies EVPN route however, some incremental work is required which will be covered in a
constructions for VxLAN/NvGRE encapsulations and ASBR procedures for separate document. This document also specifies new multi-homing
multi-homing NV Edge devices. procedures for split-horizon filtering and mass-withdraw. It also
specifies EVPN route constructions for VxLAN/NvGRE encapsulations and
ASBR procedures for multi-homing NV Edge devices.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 3, line 10 skipping to change at page 3, line 11
8.1 EVPN Multi-Homing Features . . . . . . . . . . . . . . . . 17 8.1 EVPN Multi-Homing Features . . . . . . . . . . . . . . . . 17
8.1.1 Multi-homed Ethernet Segment Auto-Discovery . . . . . . 17 8.1.1 Multi-homed Ethernet Segment Auto-Discovery . . . . . . 17
8.1.2 Fast Convergence and Mass Withdraw . . . . . . . . . . . 17 8.1.2 Fast Convergence and Mass Withdraw . . . . . . . . . . . 17
8.1.3 Split-Horizon . . . . . . . . . . . . . . . . . . . . . 17 8.1.3 Split-Horizon . . . . . . . . . . . . . . . . . . . . . 17
8.1.4 Aliasing and Backup-Path . . . . . . . . . . . . . . . . 17 8.1.4 Aliasing and Backup-Path . . . . . . . . . . . . . . . . 17
8.1.5 DF Election . . . . . . . . . . . . . . . . . . . . . . 18 8.1.5 DF Election . . . . . . . . . . . . . . . . . . . . . . 18
8.2 Impact on EVPN BGP Routes & Attributes . . . . . . . . . . . 19 8.2 Impact on EVPN BGP Routes & Attributes . . . . . . . . . . . 19
8.3 Impact on EVPN Procedures . . . . . . . . . . . . . . . . . 19 8.3 Impact on EVPN Procedures . . . . . . . . . . . . . . . . . 19
8.3.1 Split Horizon . . . . . . . . . . . . . . . . . . . . . 19 8.3.1 Split Horizon . . . . . . . . . . . . . . . . . . . . . 19
8.3.2 Aliasing and Backup-Path . . . . . . . . . . . . . . . . 20 8.3.2 Aliasing and Backup-Path . . . . . . . . . . . . . . . . 20
8.3.3 Unknown Unicast Traffic Designation . . . . . . . . . . 20 8.3.3 Unknown Unicast Traffic Designation . . . . . . . . . . 21
9 Support for Multicast . . . . . . . . . . . . . . . . . . . . . 21 9 Support for Multicast . . . . . . . . . . . . . . . . . . . . . 21
10 Data Center Interconnections - DCI . . . . . . . . . . . . . . 22 10 Data Center Interconnections - DCI . . . . . . . . . . . . . . 22
10.1 DCI using GWs . . . . . . . . . . . . . . . . . . . . . . . 22 10.1 DCI using GWs . . . . . . . . . . . . . . . . . . . . . . . 22
10.2 DCI using ASBRs . . . . . . . . . . . . . . . . . . . . . . 23 10.2 DCI using ASBRs . . . . . . . . . . . . . . . . . . . . . . 23
10.2.1 ASBR Functionality with Single-Homing NVEs . . . . . . 24 10.2.1 ASBR Functionality with Single-Homing NVEs . . . . . . 24
10.2.2 ASBR Functionality with Multi-Homing NVEs . . . . . . . 24 10.2.2 ASBR Functionality with Multi-Homing NVEs . . . . . . . 24
11 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 26 11 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 26
12 Security Considerations . . . . . . . . . . . . . . . . . . . 26 12 Security Considerations . . . . . . . . . . . . . . . . . . . 27
13 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 13 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
14 References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 14 References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
14.1 Normative References . . . . . . . . . . . . . . . . . . . 27 14.1 Normative References . . . . . . . . . . . . . . . . . . . 27
14.2 Informative References . . . . . . . . . . . . . . . . . . 27 14.2 Informative References . . . . . . . . . . . . . . . . . . 28
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1 Introduction 1 Introduction
This document specifies how Ethernet VPN (EVPN) can be used as a
Network Virtualization Overlay (NVO) solution and explores the
various tunnel encapsulation options over IP and their impact on the
EVPN control-plane and procedures. In particular, the following
encapsulation options are analyzed: VXLAN [RFC7348], NVGRE [RFC7637],
and MPLS over GRE [RFC4023]. This specification is also applicable to
[GENEVE] encapsulation; however, some incremental work is required
which will be covered in a separate document [EVPN-GENEVE]. This
document also specifies new multi-homing procedures for split-horizon
filtering and mass-withdraw. It also specifies EVPN route
constructions for VxLAN/NvGRE encapsulations and ASBR procedures for
multi-homing NV Edge devices.
In the context of this document, a Network Virtualization Overlay In the context of this document, a Network Virtualization Overlay
(NVO) is a solution to address the requirements of a multi-tenant (NVO) is a solution to address the requirements of a multi-tenant
data center, especially one with virtualized hosts, e.g., Virtual data center, especially one with virtualized hosts, e.g., Virtual
Machines (VMs) or virtual workloads. The key requirements of such a Machines (VMs) or virtual workloads. The key requirements of such a
solution, as described in [RFC7364], are: solution, as described in [RFC7364], are:
- Isolation of network traffic per tenant - Isolation of network traffic per tenant
- Support for a large number of tenants (tens or hundreds of - Support for a large number of tenants (tens or hundreds of
thousands) thousands)
skipping to change at page 13, line 15 skipping to change at page 13, line 19
bundle service in [RFC7432]. Such setting must be done consistently bundle service in [RFC7432]. Such setting must be done consistently
on all PE devices participating in that EVI within a given domain. on all PE devices participating in that EVI within a given domain.
For global VNIs, the value advertised in the Ethernet Tag field For global VNIs, the value advertised in the Ethernet Tag field
SHOULD be set to a VNI as long as it matches the existing semantics SHOULD be set to a VNI as long as it matches the existing semantics
of the Ethernet Tag, i.e., it identifies a bridge table within a MAC- of the Ethernet Tag, i.e., it identifies a bridge table within a MAC-
VRF and the set of VNIs are configured consistently on each PE in VRF and the set of VNIs are configured consistently on each PE in
that EVI. that EVI.
In order to indicate which type of data plane encapsulation (i.e., In order to indicate which type of data plane encapsulation (i.e.,
VXLAN, NVGRE, MPLS, or MPLS in GRE) is to be used, the BGP VXLAN, NVGRE, MPLS, or MPLS in GRE) is to be used, the BGP
Encapsulation extended community defined in [TUNNEL-ENCAP] and Encapsulation extended community defined in [TUNNEL-ENCAP] is
[RFC5512] is included with all EVPN routes (i.e. MAC Advertisement, included with all EVPN routes (i.e. MAC Advertisement, Ethernet AD
Ethernet AD per EVI, Ethernet AD per ESI, Inclusive Multicast per EVI, Ethernet AD per ESI, Inclusive Multicast Ethernet Tag, and
Ethernet Tag, and Ethernet Segment) advertised by an egress PE. Five Ethernet Segment) advertised by an egress PE. Five new values have
new values have been assigned by IANA to extend the list of been assigned by IANA to extend the list of encapsulation types
encapsulation types defined in [TUNNEL-ENCAP] and they are listed in defined in [TUNNEL-ENCAP] and they are listed in section 13.
section 13.
The MPLS encapsulation tunnel type, listed in section 13, is needed The MPLS encapsulation tunnel type, listed in section 13, is needed
in order to distinguish between an advertising node that only in order to distinguish between an advertising node that only
supports non-MPLS encapsulations and one that supports MPLS and non- supports non-MPLS encapsulations and one that supports MPLS and non-
MPLS encapsulations. An advertising node that only supports MPLS MPLS encapsulations. An advertising node that only supports MPLS
encapsulation does not need to advertise any encapsulation tunnel encapsulation does not need to advertise any encapsulation tunnel
types; i.e., if the BGP Encapsulation extended community is not types; i.e., if the BGP Encapsulation extended community is not
present, then either MPLS encapsulation or a statically configured present, then either MPLS encapsulation or a statically configured
encapsulation is assumed. encapsulation is assumed.
skipping to change at page 13, line 49 skipping to change at page 14, line 4
described in section 8.2.2.2 of [TUNNEL-ENCAP] ("When a Valid VNI has described in section 8.2.2.2 of [TUNNEL-ENCAP] ("When a Valid VNI has
not been Signaled"). not been Signaled").
5.2 MPLS over GRE 5.2 MPLS over GRE
The EVPN data-plane is modeled as an EVPN MPLS client layer sitting The EVPN data-plane is modeled as an EVPN MPLS client layer sitting
over an MPLS PSN-tunnel server layer. Some of the EVPN functions over an MPLS PSN-tunnel server layer. Some of the EVPN functions
(split-horizon, aliasing, and backup-path) are tied to the MPLS (split-horizon, aliasing, and backup-path) are tied to the MPLS
client layer. If MPLS over GRE encapsulation is used, then the EVPN client layer. If MPLS over GRE encapsulation is used, then the EVPN
MPLS client layer can be carried over an IP PSN tunnel transparently. MPLS client layer can be carried over an IP PSN tunnel transparently.
Therefore, there is no impact to the EVPN procedures and associated Therefore, there is no impact to the EVPN procedures and associated
data-plane operation. data-plane operation.
The existing standards for MPLS over GRE encapsulation as defined by The existing standards for MPLS over GRE encapsulation as defined by
[RFC4023] can be used for this purpose; however, when it is used in [RFC4023] can be used for this purpose; however, when it is used in
conjunction with EVPN the GRE key field SHOULD be present, and SHOULD conjunction with EVPN, it is recommended that the GRE key field be
be used to provide a 32-bit entropy value. The Checksum and Sequence present and be used to provide a 32-bit entropy value only if the P
nodes can perform ECMP hashing based on the GRE key; otherwise, the
GRE header should not include the GRE key. The Checksum and Sequence
Number fields MUST NOT be included and the corresponding C and S bits Number fields MUST NOT be included and the corresponding C and S bits
in the GRE Packet Header MUST be set to zero. A PE capable of in the GRE Packet Header MUST be set to zero. A PE capable of
supporting this encapsulation, should advertise its EVPN routes along supporting this encapsulation, should advertise its EVPN routes along
with the Tunnel Encapsulation extended community indicating MPLS over with the Tunnel Encapsulation extended community indicating MPLS over
GRE encapsulation, as described in previous section. GRE encapsulation as described in previous section.
6 EVPN with Multiple Data Plane Encapsulations 6 EVPN with Multiple Data Plane Encapsulations
The use of the BGP Encapsulation extended community per [TUNNEL- The use of the BGP Encapsulation extended community per [TUNNEL-
ENCAP] and [RFC5512] allows each NVE in a given EVI to know each of ENCAP] allows each NVE in a given EVI to know each of the
the encapsulations supported by each of the other NVEs in that EVI. encapsulations supported by each of the other NVEs in that EVI.
i.e., each of the NVEs in a given EVI may support multiple data plane i.e., each of the NVEs in a given EVI may support multiple data plane
encapsulations. An ingress NVE can send a frame to an egress NVE encapsulations. An ingress NVE can send a frame to an egress NVE
only if the set of encapsulations advertised by the egress NVE forms only if the set of encapsulations advertised by the egress NVE forms
a non-empty intersection with the set of encapsulations supported by a non-empty intersection with the set of encapsulations supported by
the ingress NVE, and it is at the discretion of the ingress NVE which the ingress NVE, and it is at the discretion of the ingress NVE which
encapsulation to choose from this intersection. (As noted in encapsulation to choose from this intersection. (As noted in
section 5.1.3, if the BGP Encapsulation extended community is not section 5.1.3, if the BGP Encapsulation extended community is not
present, then the default MPLS encapsulation or a locally configured present, then the default MPLS encapsulation or a locally configured
encapsulation is assumed.) encapsulation is assumed.)
skipping to change at page 21, line 23 skipping to change at page 21, line 28
MAC address to be unknown on the ingress PE but be known on the MAC address to be unknown on the ingress PE but be known on the
egress PE(s). Therefore, when a packet destined to that host MAC egress PE(s). Therefore, when a packet destined to that host MAC
address arrives on the ingress PE, it floods it via ingress address arrives on the ingress PE, it floods it via ingress
replication to all the egress PE(s) and since they are known to the replication to all the egress PE(s) and since they are known to the
egress PE(s), multiple copies is sent to the All-Active multi-homed egress PE(s), multiple copies is sent to the All-Active multi-homed
site. It should be noted that such transient packet duplication only site. It should be noted that such transient packet duplication only
happens when a) the destination host is multi-homed via All-Active happens when a) the destination host is multi-homed via All-Active
redundancy mode, b) flooding of unknown unicast is enabled in the redundancy mode, b) flooding of unknown unicast is enabled in the
network, c) ingress replication is used, and d) traffic for the network, c) ingress replication is used, and d) traffic for the
destination host is arrived on the ingress PE before it learns the destination host is arrived on the ingress PE before it learns the
host MAC address via BGP EVPN advertisement. In order to prevent such host MAC address via BGP EVPN advertisement. If it is desired to
occurrence of packet duplication (however low probability that may avoid occurrence of such transient packet duplication (however low
be), the ingress PE MAY set the BUM Traffic Bit (B bit) [VXLAN-GPE] probability that may be), then VxLAN-GPE encapsulation needs to be
to indicate BUM traffic. used between these PEs and the ingress PE needs to set the BUM
Traffic Bit (B bit) [VXLAN-GPE] to indicate that this is an ingress-
replicated BUM traffic.
9 Support for Multicast 9 Support for Multicast
The E-VPN Inclusive Multicast Ethernet Tag (IMET) route is used to The E-VPN Inclusive Multicast Ethernet Tag (IMET) route is used to
discover the multicast tunnels among the endpoints associated with a discover the multicast tunnels among the endpoints associated with a
given EVI (e.g., given VNI) for VLAN-based service and a given given EVI (e.g., given VNI) for VLAN-based service and a given
<EVI,VLAN> for VLAN-aware bundle service. All fields of this route is <EVI,VLAN> for VLAN-aware bundle service. All fields of this route is
set as described in section 5.1.3. The Originating router's IP set as described in section 5.1.3. The Originating router's IP
address field is set to the NVE's IP address. This route is tagged address field is set to the NVE's IP address. This route is tagged
with the PMSI Tunnel attribute, which is used to encode the type of with the PMSI Tunnel attribute, which is used to encode the type of
skipping to change at page 27, line 10 skipping to change at page 27, line 14
12 Security Considerations 12 Security Considerations
This document uses IP-based tunnel technologies to support data This document uses IP-based tunnel technologies to support data
plane transport. Consequently, the security considerations of those plane transport. Consequently, the security considerations of those
tunnel technologies apply. This document defines support for VXLAN tunnel technologies apply. This document defines support for VXLAN
[RFC7348] and NVGRE [RFC7637] encapsulations. The security [RFC7348] and NVGRE [RFC7637] encapsulations. The security
considerations from those RFCs apply to the data plane aspects of considerations from those RFCs apply to the data plane aspects of
this document. this document.
As with [RFC5512], any modification of the information that is used As with [TUNNEL-ENCAP], any modification of the information that is
to form encapsulation headers, to choose a tunnel type, or to choose used to form encapsulation headers, to choose a tunnel type, or to
a particular tunnel for a particular payload type may lead to user choose a particular tunnel for a particular payload type may lead to
data packets getting misrouted, misdelivered, and/or dropped. user data packets getting misrouted, misdelivered, and/or dropped.
More broadly, the security considerations for the transport of IP More broadly, the security considerations for the transport of IP
reachability information using BGP are discussed in [RFC4271] and reachability information using BGP are discussed in [RFC4271] and
[RFC4272], and are equally applicable for the extensions described [RFC4272], and are equally applicable for the extensions described
in this document. in this document.
13 IANA Considerations 13 IANA Considerations
IANA has allocated the following BGP Tunnel Encapsulation Attribute IANA has allocated the following BGP Tunnel Encapsulation Attribute
Tunnel Types: Tunnel Types:
skipping to change at page 27, line 35 skipping to change at page 27, line 39
8 VXLAN Encapsulation 8 VXLAN Encapsulation
9 NVGRE Encapsulation 9 NVGRE Encapsulation
10 MPLS Encapsulation 10 MPLS Encapsulation
11 MPLS in GRE Encapsulation 11 MPLS in GRE Encapsulation
12 VXLAN GPE Encapsulation 12 VXLAN GPE Encapsulation
14 References 14 References
14.1 Normative References 14.1 Normative References
[KEYWORDS] 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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
May 2017, <http://www.rfc-editor.org/info/rfc8174>. <http://www.rfc-editor.org/info/rfc8174>.
[RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP
Tunnel Encapsulation Attribute", RFC 5512, April 2009.
[RFC7432] Sajassi et al., "BGP MPLS Based Ethernet VPN", RFC 7432, [RFC7432] Sajassi et al., "BGP MPLS Based Ethernet VPN", RFC 7432,
February 2014 February 2014
[RFC7348] Mahalingam, M., et al, "VXLAN: A Framework for Overlaying
Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, August
2014
[RFC7637] Garg, P., et al., "NVGRE: Network Virtualization using
Generic Routing Encapsulation", RFC 7637, September, 2015
[TUNNEL-ENCAP] Rosen et al., "The BGP Tunnel Encapsulation
Attribute", draft-ietf-idr-tunnel-encaps-03, work in progress, May
31, 2016.
[VXLAN-GPE] Maino et al., "Generic Protocol Extension for VXLAN",
draft-ietf-nvo3-vxlan-gpe-03, work in progress October 25, 2016.
[RFC4023] T. Worster et al., "Encapsulating MPLS in IP or Generic
Routing Encapsulation (GRE)", RFC 4023, March 2005
14.2 Informative References 14.2 Informative References
[RFC7209] Sajassi et al., "Requirements for Ethernet VPN (EVPN)", RFC [RFC7209] Sajassi et al., "Requirements for Ethernet VPN (EVPN)", RFC
7209, May 2014 7209, May 2014
[RFC7348] Mahalingam, M., et al, "VXLAN: A Framework for Overlaying
Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, August
2014
[RFC4272] S. Murphy, "BGP Security Vulnerabilities Analysis.", [RFC4272] S. Murphy, "BGP Security Vulnerabilities Analysis.",
January 2006. January 2006.
[RFC7637] Garg, P., et al., "NVGRE: Network Virtualization using
Generic Routing Encapsulation", RFC 7637, September, 2015
[RFC7364] Narten et al., "Problem Statement: Overlays for Network [RFC7364] Narten et al., "Problem Statement: Overlays for Network
Virtualization", RFC 7364, October 2014. Virtualization", RFC 7364, October 2014.
[RFC7365] Lasserre et al., "Framework for DC Network Virtualization", [RFC7365] Lasserre et al., "Framework for DC Network Virtualization",
RFC 7365, October 2014. RFC 7365, October 2014.
[DCI-EVPN-OVERLAY] Rabadan et al., "Interconnect Solution for EVPN [DCI-EVPN-OVERLAY] Rabadan et al., "Interconnect Solution for EVPN
Overlay networks", draft-ietf-bess-dci-evpn-overlay-04, work in Overlay networks", draft-ietf-bess-dci-evpn-overlay-04, work in
progress, February 29, 2016. progress, February 29, 2016.
[RFC4271] Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed., "A Border [RFC4271] Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed., "A Border
Gateway Protocol 4 (BGP-4)", January 2006. Gateway Protocol 4 (BGP-4)", January 2006.
[TUNNEL-ENCAP] Rosen et al., "The BGP Tunnel Encapsulation
Attribute", draft-ietf-idr-tunnel-encaps-03, work in progress, May
31, 2016.
[VXLAN-GPE] Maino et al., "Generic Protocol Extension for VXLAN",
draft-ietf-nvo3-vxlan-gpe-03, work in progress October 25, 2016.
[RFC4364] Rosen, E., et al, "BGP/MPLS IP Virtual Private Networks [RFC4364] Rosen, E., et al, "BGP/MPLS IP Virtual Private Networks
(VPNs)", RFC 4364, February 2006. (VPNs)", RFC 4364, February 2006.
[RFC4023] T. Worster et al., "Encapsulating MPLS in IP or Generic
Routing Encapsulation (GRE)", RFC 4023, March 2005
[RFC6514] R. Aggarwal et al., "BGP Encodings and Procedures for [RFC6514] R. Aggarwal et al., "BGP Encodings and Procedures for
Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012 Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012
Contributors [GENEVE] J. Gross et al., "Geneve: Generic Network Virtualization
Encapsulation", draft-ietf-nvo3-geneve-05, September 2017
[EVPN-GENEVE] S. Boutros et al., "EVPN control plane for Geneve",
draft-boutros-bess-evpn-geneve-00.txt, June 2017
Contributors
S. Salam S. Salam
K. Patel K. Patel
D. Rao D. Rao
S. Thoria S. Thoria
D. Cai D. Cai
Cisco Cisco
Y. Rekhter Y. Rekhter
A. Issac A. Issac
Wen Lin Wen Lin
Nischal Sheth Nischal Sheth
Juniper Juniper
L. Yong L. Yong
Huawei Huawei
Authors' Addresses Authors' Addresses
Ali Sajassi Ali Sajassi
Cisco Cisco
USA
Email: sajassi@cisco.com Email: sajassi@cisco.com
John Drake John Drake
Juniper Networks Juniper Networks
USA
Email: jdrake@juniper.net Email: jdrake@juniper.net
Nabil Bitar Nabil Bitar
Nokia Nokia
USA
Email : nabil.bitar@nokia.com Email : nabil.bitar@nokia.com
R. Shekhar R. Shekhar
Juniper Juniper
USA
Email: rshekhar@juniper.net Email: rshekhar@juniper.net
James Uttaro James Uttaro
AT&T AT&T
USA
Email: uttaro@att.com Email: uttaro@att.com
Wim Henderickx Wim Henderickx
Alcatel-Lucent Nokia
USA
e-mail: wim.henderickx@nokia.com e-mail: wim.henderickx@nokia.com
 End of changes. 30 change blocks. 
58 lines changed or deleted 83 lines changed or added

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