rfc9721v1.txt   rfc9721.txt 
Internet Engineering Task Force (IETF) N. Malhotra, Ed. Internet Engineering Task Force (IETF) N. Malhotra, Ed.
Request for Comments: 9721 A. Sajassi Request for Comments: 9721 A. Sajassi
Category: Standards Track A. Pattekar Category: Standards Track A. Pattekar
ISSN: 2070-1721 Cisco Systems ISSN: 2070-1721 Cisco Systems
J. Rabadan J. Rabadan
Nokia Nokia
A. Lingala A. Lingala
AT&T AT&T
J. Drake J. Drake
Juniper Networks Independent
April 2025 April 2025
Extended Mobility Procedures for Ethernet VPN Integrated Routing and Extended Mobility Procedures for Ethernet VPN Integrated Routing and
Bridging (EVPN-IRB) Bridging (EVPN-IRB)
Abstract Abstract
This document specifies extensions to the Ethernet VPN Integrated This document specifies extensions to the Ethernet VPN Integrated
Routing and Bridging (EVPN-IRB) procedures specified in RFCs 7432 and Routing and Bridging (EVPN-IRB) procedures specified in RFCs 7432 and
9135 to enhance the mobility mechanisms for networks based on EVPN- 9135 to enhance the mobility mechanisms for networks based on EVPN-
skipping to change at line 66 skipping to change at line 66
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction 1. Introduction
1.1. Document Structure 1.1. Document Structure
2. Requirements Language and Terminology 2. Requirements Language and Terminology
2.1. Abbreviations
2.2. Definitions
3. Background and Problem Statement 3. Background and Problem Statement
3.1. Optional MAC-Only RT-2 3.1. Optional MAC-Only RT-2
3.2. Mobility Use Cases 3.2. Mobility Use Cases
3.2.1. Host MAC+IP Address Move 3.2.1. Host MAC+IP Address Move
3.2.2. Host IP Address Move to New MAC Address 3.2.2. Host IP Address Move to New MAC Address
3.2.2.1. Host Reload 3.2.2.1. Host Reload
3.2.2.2. MAC Address Sharing 3.2.2.2. MAC Address Sharing
3.2.2.3. Problem 3.2.2.3. Problem
3.2.3. Host MAC Address Move to New IP Address 3.2.3. Host MAC Address Move to New IP Address
3.2.3.1. Problem 3.2.3.1. Problem
skipping to change at line 153 skipping to change at line 155
While the existing mobility procedure can manage the MAC+IP address While the existing mobility procedure can manage the MAC+IP address
move in the first scenario, the subsequent scenarios lead to new MAC- move in the first scenario, the subsequent scenarios lead to new MAC-
IP address associations. Therefore, a single sequence number IP address associations. Therefore, a single sequence number
assigned independently for each {MAC address, IP address} is assigned independently for each {MAC address, IP address} is
insufficient to determine the most recent reachability for both MAC insufficient to determine the most recent reachability for both MAC
address and IP address, unless the sequence number assignment address and IP address, unless the sequence number assignment
algorithm allows for changing MAC-IP address bindings across moves. algorithm allows for changing MAC-IP address bindings across moves.
This document updates the sequence number assignment procedures This document updates the sequence number assignment procedures
defined in [RFC7432] to adequately address mobility support across defined in [RFC7432] to 1) adequately address mobility support across
EVPN-IRB overlay use cases that permit MAC-IP address bindings to EVPN-IRB overlay use cases that permit MAC-IP address bindings to
change across host moves and support mobility for both MAC and IP change across host moves and 2) support mobility for both MAC and IP
route components carried in an EVPN RT-2 for these use cases. route components carried in an EVPN RT-2 for these use cases.
Additionally, for hosts on an Ethernet Segment Identifier (ESI) that Additionally, for hosts on an Ethernet Segment Identifier (ESI) that
is multi-homed to multiple Provider Edge (PE) devices, additional is multi-homed to multiple Provider Edge (PE) devices, additional
procedures are specified to ensure synchronized sequence number procedures are specified to ensure synchronized sequence number
assignments across the multi-homing devices. assignments across the multi-homing devices.
This document addresses mobility for the following cases, independent This document addresses mobility for the following cases, independent
of the overlay encapsulation (e.g., MPLS, Segment Routing over IPv6 of the overlay encapsulation (e.g., MPLS, Segment Routing over IPv6
(SRv6), and Network Virtualization Overlay (NVO) tunnel): (SRv6), and Network Virtualization Overlay (NVO) tunnel):
skipping to change at line 206 skipping to change at line 208
for EVPN-IRB and routed overlays. for EVPN-IRB and routed overlays.
2. Requirements Language and Terminology 2. Requirements Language and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
EVPN-IRB: Ethernet VPN Integrated Routing and Bridging. A BGP-EVPN 2.1. Abbreviations
distributed control plane that is based on the integrated routing
and bridging fabric overlay discussed in [RFC9135].
Underlay: An IP, MPLS, or SRv6 fabric core network that provides
routed reachability between EVPN PEs.
Overlay: L2 and L3 VPNs that are enabled via NVO3, VXLAN, SRv6, or
MPLS service-layer encapsulation.
SRv6: Segment Routing over IPv6 (as specified in [RFC8986]).
NVO: Network Virtualization Overlay.
NVO3: Network Virtualization over Layer 3 (as specified in ARP: Address Resolution Protocol [RFC0826]. ARP references in this
[RFC8926]). document are equally applicable to both ARP and NDP.
VXLAN: Virtual eXtensible Local Area Network (as specified in CE: Customer Edge.
[RFC7348]).
MPLS: Multiprotocol Label Switching (as specified in [RFC3031]). ES: Ethernet Segment. A physical ethernet or LAG port that connects
an access device to an EVPN PE, as defined in [RFC7432].
EVPN PE: Ethernet VPN Provider Edge. A PE switch router in an EVPN- EVPN PE: Ethernet VPN Provider Edge. A PE switch router in an EVPN-
IRB network that runs overlay BGP-EVPN control planes and connects IRB network that runs overlay BGP-EVPN control planes and connects
to overlay CE host devices. An EVPN PE may also be the first-hop to overlay CE host devices. An EVPN PE may also be the first-hop
L3 gateway for CE host devices. This document refers to EVPN PE L3 gateway for CE host devices. This document refers to EVPN PE
as a logical function in an EVPN-IRB network. This EVPN PE as a logical function in an EVPN-IRB network. This EVPN PE
function may be physically hosted on a ToR switching device or at function may be physically hosted on a ToR switching device or at
layer(s) above the ToR in the Clos fabric. An EVPN PE is layer(s) above the ToR in the Clos fabric. An EVPN PE is
typically also an IP or MPLS tunnel endpoint for overlay VPN typically also an IP or MPLS tunnel endpoint for overlay VPN
flows. flows.
Symmetric EVPN-IRB: A specific design approach used in EVPN-based EVPN-IRB: Ethernet VPN Integrated Routing and Bridging. A BGP-EVPN
networks [RFC9135] to handle both L2 and L3 forwarding within the distributed control plane that is based on the integrated routing
same network infrastructure. The key characteristic of symmetric and bridging fabric overlay discussed in [RFC9135].
EVPN-IRB is that both ingress and egress PE routers perform
routing for inter-subnet traffic.
Asymmetric EVPN-IRB: A design approach used in EVPN-based networks L2: Layer 2.
[RFC9135] to handle L2 and L3 forwarding. In this approach, only
the ingress PE router performs routing for inter-subnet traffic,
while the egress PE router performs bridging.
ARP: Address Resolution Protocol [RFC0826]. ARP references in this L3: Layer 3.
document are equally applicable to both ARP and NDP.
LAG: Link Aggregation Group.
MC-LAG: Multi-Chassis Link Aggregation Group.
MPLS: Multiprotocol Label Switching (as specified in [RFC3031]).
NDP: Neighbor Discovery Protocol (for IPv6 [RFC4861]). NDP: Neighbor Discovery Protocol (for IPv6 [RFC4861]).
ES: Ethernet Segment. A physical ethernet or LAG port that connects NVO: Network Virtualization Overlay.
an access device to an EVPN PE, as defined in [RFC7432].
MC-LAG: Multi-Chassis Link Aggregation Group. NVO3: Network Virtualization over Layer 3 (as specified in
[RFC8926]).
EVPN all-active multi-homing: A redundancy and load-sharing PE: Provider Edge.
mechanism used in EVPN networks. This method allows multiple PE
devices to simultaneously provide L2 and L3 connectivity to a
single CE device or network segment.
RT-2: Route Type 2. EVPN RT-2 carrying both MAC address and IP RT-2: Route Type 2. EVPN RT-2 carrying both MAC address and IP
address reachability as specified in [RFC7432]. address reachability as specified in [RFC7432].
RT-5: Route Type 5. EVPN RT-5 carrying IP prefix reachability as RT-5: Route Type 5. EVPN RT-5 carrying IP prefix reachability as
specified in [RFC7432]. specified in [RFC9136].
SRv6: Segment Routing over IPv6 (as specified in [RFC8986]).
ToR: Top-of-Rack.
VM: Virtual Machine (or containerized workloads).
VXLAN: Virtual eXtensible Local Area Network (as specified in
[RFC7348]).
2.2. Definitions
Asymmetric EVPN-IRB: A design approach used in EVPN-based networks
[RFC9135] to handle L2 and L3 forwarding. In this approach, only
the ingress PE router performs routing for inter-subnet traffic,
while the egress PE router performs bridging.
EVPN all-active multi-homing: A redundancy and load-sharing
mechanism used in EVPN networks. This method allows multiple PE
devices to simultaneously provide L2 and L3 connectivity to a
single CE device or network segment.
Host: In this document, generically refers to any user or CE
endpoint attached to an EVPN-IRB network, which may be a VM,
containerized workload, physical endpoint, or CE device.
MAC-IP address: The IPv4 and/or IPv6 address and MAC address binding MAC-IP address: The IPv4 and/or IPv6 address and MAC address binding
for an overlay host. for an overlay host.
Peer-Sync-Local MAC route: The learned BGP EVPN MAC route for a host Overlay: L2 and L3 VPNs that are enabled via NVO3, VXLAN, SRv6, or
that is directly attached to a local multi-homed ES. MPLS service-layer encapsulation.
Peer-Sync-Local MAC-IP route: The learned BGP EVPN MAC-IP route for Peer-Sync-Local MAC-IP route: The learned BGP EVPN MAC-IP route for
a host that is directly attached to a local multi-homed ES. a host that is directly attached to a local multi-homed ES.
Peer-Sync-Local MAC sequence number: The sequence number received
with a Peer-Sync-Local MAC route.
Peer-Sync-Local MAC-IP sequence number: The sequence number received Peer-Sync-Local MAC-IP sequence number: The sequence number received
with a Peer-Sync-Local MAC-IP route. with a Peer-Sync-Local MAC-IP route.
VM: Virtual Machine (or containerized workloads). Peer-Sync-Local MAC route: The learned BGP EVPN MAC route for a host
that is directly attached to a local multi-homed ES.
Host: In this document, generically refers to any user or CE Peer-Sync-Local MAC sequence number: The sequence number received
endpoint attached to an EVPN-IRB network, which may be a VM, with a Peer-Sync-Local MAC route.
containerized workload, physical endpoint, or CE device.
Symmetric EVPN-IRB: A specific design approach used in EVPN-based
networks [RFC9135] to handle both L2 and L3 forwarding within the
same network infrastructure. The key characteristic of symmetric
EVPN-IRB is that both ingress and egress PE routers perform
routing for inter-subnet traffic.
Underlay: An IP, MPLS, or SRv6 fabric core network that provides
routed reachability between EVPN PEs.
3. Background and Problem Statement 3. Background and Problem Statement
3.1. Optional MAC-Only RT-2 3.1. Optional MAC-Only RT-2
In an EVPN-IRB scenario where a single MAC+IP RT-2 advertisement In an EVPN-IRB scenario where a single MAC+IP RT-2 advertisement
carries both IP and MAC routes, a MAC-only RT-2 advertisement becomes carries both IP and MAC routes, a MAC-only RT-2 advertisement becomes
redundant for host MAC addresses already advertised via MAC+IP RT-2. redundant for host MAC addresses already advertised via MAC+IP RT-2.
Consequently, the advertisement of a local MAC-only RT-2 is optional Consequently, the advertisement of a local MAC-only RT-2 is optional
at an EVPN PE. This consideration is important for mobility at an EVPN PE. This consideration is important for mobility
skipping to change at line 312 skipping to change at line 330
locally on a PE, and only the advertisement of this route to other locally on a PE, and only the advertisement of this route to other
PEs is optional. PEs is optional.
MAC-only RT-2 advertisements may still be issued for non-IP host MAC MAC-only RT-2 advertisements may still be issued for non-IP host MAC
addresses that are not included in MAC+IP RT-2 advertisements. addresses that are not included in MAC+IP RT-2 advertisements.
3.2. Mobility Use Cases 3.2. Mobility Use Cases
This section outlines the IRB mobility use cases addressed in this This section outlines the IRB mobility use cases addressed in this
document. Detailed procedures to handle these scenarios are provided document. Detailed procedures to handle these scenarios are provided
in Sections 6 and 7. in Sections 6 and 7. The following IRB mobility scenarios are
considered:
* A host move results in both the host's IP and MAC addresses moving * A host move results in both the host's IP and MAC addresses moving
together. together.
* A host move results in the host's IP address moving to a new MAC * A host move results in the host's IP address moving to a new MAC
address association. address association.
* A host move results in the host's MAC address moving to a new IP * A host move results in the host's MAC address moving to a new IP
address association. address association.
skipping to change at line 683 skipping to change at line 702
be able to look up MAC-IP routes for a given IP and update the be able to look up MAC-IP routes for a given IP and update the
sequence number for its parent MAC route and for its MAC-IP route sequence number for its parent MAC route and for its MAC-IP route
children. children.
5.3. Sequence Number Synchronization 5.3. Sequence Number Synchronization
To support mobility for multi-homed hosts, local MAC and MAC-IP To support mobility for multi-homed hosts, local MAC and MAC-IP
routes learned on a shared ES must be advertised with the same routes learned on a shared ES must be advertised with the same
sequence number by all PE devices to which the ES is multi-homed. sequence number by all PE devices to which the ES is multi-homed.
This applies to local MAC-only routes as well. MAC and MAC-IP routes This applies to local MAC-only routes as well. MAC and MAC-IP routes
for a host that is attached to a local ES may be learned natively via for a host that is attached to a local ES may be learned via data
data plane and ARP/NDP, respectively, as well as via BGP EVPN from plane and ARP/NDP, respectively, as well as via BGP EVPN from another
another multi-homing PE to achieve local switching. MAC and MAC-IP multi-homing PE to achieve local switching. MAC and MAC-IP routes
routes learned natively via data plane and ARP/NDP are respectively learned via data plane and ARP/NDP are respectively referred to as
referred to as local MAC routes and local MAC-IP routes. BGP EVPN local MAC routes and local MAC-IP routes. BGP EVPN learned MAC and
learned MAC and MAC-IP routes for a host that is attached to a local MAC-IP routes for a host that is attached to a local ES are
ES are respectively referred to as Peer-Sync-Local MAC routes and respectively referred to as Peer-Sync-Local MAC routes and Peer-Sync-
Peer-Sync-Local MAC-IP routes as they are effectively local routes Local MAC-IP routes as they are effectively local routes synchronized
synchronized from a multi-homing peer. Local and Peer-Sync-Local from a multi-homing peer. Local and Peer-Sync-Local route learning
route learning can occur in any order. Local MAC-IP routes can occur in any order. Local MAC-IP routes advertised by all multi-
advertised by all multi-homing PE devices sharing the ES must carry homing PE devices sharing the ES must carry the same sequence number,
the same sequence number, independent of the order in which they are independent of the order in which they are learned. This implies
learned. This implies that: that:
* On local or Peer-Sync-Local MAC-IP route learning, the sequence * On local or Peer-Sync-Local MAC-IP route learning, the sequence
number for the local MAC-IP route must be compared and updated to number for the local MAC-IP route must be compared and updated to
the higher value. the higher value.
* On local or Peer-Sync-Local MAC route learning, the sequence * On local or Peer-Sync-Local MAC route learning, the sequence
number for the local MAC route must be compared and updated to the number for the local MAC route must be compared and updated to the
higher value. higher value.
If an update to the local MAC-IP route sequence number is required as If an update to the local MAC-IP route sequence number is required as
a result of the comparison with the Peer-Sync-Local MAC-IP route, it a result of the comparison with the Peer-Sync-Local MAC-IP route, it
essentially amounts to a sequence number update on the parent local essentially amounts to a sequence number update on the parent local
MAC route, resulting in an inherited sequence number update on the MAC route, resulting in an inherited sequence number update on the
local MAC-IP route. local MAC-IP route.
6. Methods for Sequence Number Assignment 6. Methods for Sequence Number Assignment
The following sections specify the sequence number assignment The following sections specify the sequence number assignment
procedures required for local and Peer-Sync-Local MAC and MAC-IP procedures required for local MAC, local MAC-IP, Peer-Sync-Local MAC,
route learning events to achieve the outlined objectives. and Peer-Sync-Local MAC-IP route learning events to achieve the
outlined objectives.
6.1. Local MAC-IP Learning 6.1. Local MAC-IP Learning
A local Mx-IPx learning via ARP or NDP should result in the A local Mx-IPx learning via ARP or NDP should result in the
computation or re-computation of the parent MAC route Mx's sequence computation or re-computation of the parent MAC route Mx's sequence
number, following which the MAC-IP route Mx-IPx inherits the parent number. After this, the MAC-IP route Mx-IPx inherits the parent MAC
MAC route's sequence number. The parent MAC route Mx sequence number route's sequence number. The parent MAC route Mx sequence number
MUST be computed as follows: MUST be computed as follows:
* It MUST be higher than any existing remote MAC route for Mx, as * It MUST be higher than any existing remote MAC route for Mx, as
per [RFC7432]. per [RFC7432].
* It MUST be at least equal to the corresponding Peer-Sync-Local MAC * It MUST be at least equal to the corresponding Peer-Sync-Local MAC
route sequence number, if present. route sequence number, if present.
* It MUST be higher than the "Mz" sequence number if the IP is also * It MUST be higher than the "Mz" sequence number if the IP is also
associated with a different remote MAC "Mz". associated with a different remote MAC "Mz".
skipping to change at line 827 skipping to change at line 847
Generally, if all PE nodes in the overlay network follow the above Generally, if all PE nodes in the overlay network follow the above
sequence number assignment procedures and the PE is advertising both sequence number assignment procedures and the PE is advertising both
MAC+IP and MAC routes, the sequence numbers advertised with the MAC MAC+IP and MAC routes, the sequence numbers advertised with the MAC
and MAC+IP routes with the same MAC address would always be the same. and MAC+IP routes with the same MAC address would always be the same.
However, an interoperability scenario with a different implementation However, an interoperability scenario with a different implementation
could arise, where a non-compliant PE implementation assigns and could arise, where a non-compliant PE implementation assigns and
advertises independent sequence numbers to MAC and MAC+IP routes. To advertises independent sequence numbers to MAC and MAC+IP routes. To
handle this case, if different sequence numbers are received for handle this case, if different sequence numbers are received for
remote MAC+IP routes and corresponding remote MAC routes from a remote MAC+IP routes and corresponding remote MAC routes from a
remote PE, the sequence number associated with the remote MAC route remote PE, the sequence number associated with the remote MAC route
MUST be computed and interpreted as: MUST be:
* The highest of all received sequence numbers with remote MAC+IP * computed and interpreted as the highest of all received sequence
and MAC routes with the same MAC address. numbers with remote MAC+IP and MAC routes with the same MAC
address and
* The MAC route sequence number would be re-computed on a MAC or * re-computed on a MAC or MAC+IP route withdraw as per the above.
MAC+IP route withdraw as per the above.
A MAC and/or IP address move to the local PE would then result in the A MAC and/or IP address move to the local PE would then result in the
MAC (and hence all MAC-IP) route sequence numbers being incremented MAC (and hence all MAC-IP) route sequence numbers being incremented
from the above computed remote MAC route sequence number. from the above computed remote MAC route sequence number.
If MAC-only routes are not advertised at all, and different sequence If MAC-only routes are not advertised at all, and different sequence
numbers are received with multiple MAC+IP routes for a given MAC numbers are received with multiple MAC+IP routes for a given MAC
address, the sequence number associated with the derived remote MAC address, the sequence number associated with the derived remote MAC
route should still be computed as the highest of all received MAC+IP route should still be computed as the highest of all received MAC+IP
route sequence numbers with the same MAC address. route sequence numbers with the same MAC address.
skipping to change at line 1091 skipping to change at line 1111
MAC or IP addresses. Un-provisioning refers to corrective action MAC or IP addresses. Un-provisioning refers to corrective action
taken on the host side. Following this correction, normal operation taken on the host side. Following this correction, normal operation
will not resume until the duplicate MAC or IP address ages out, will not resume until the duplicate MAC or IP address ages out,
unless additional action is taken to expedite recovery. unless additional action is taken to expedite recovery.
Possible additional corrective actions for faster recovery are Possible additional corrective actions for faster recovery are
outlined in the following sections. outlined in the following sections.
8.4.1. Route Unfreezing Configuration 8.4.1. Route Unfreezing Configuration
Unfreezing the duplicate or frozen MAC or IP route via a CLI can be Unfreezing the duplicate or frozen MAC or IP route via a command-line
used to recover from the duplicate and frozen state following interface (CLI) can be used to recover from the duplicate and frozen
corrective un-provisioning of the duplicate MAC or IP address. state following corrective un-provisioning of the duplicate MAC or IP
Unfreezing the MAC or IP route should result in advertising it with a address. Unfreezing the MAC or IP route should result in advertising
sequence number higher than that advertised from the other location. it with a sequence number higher than that advertised from the other
location.
Two scenarios exist: Two scenarios exist:
* Scenario A: The duplicate MAC or IP address is un-provisioned at * Scenario A: The duplicate MAC or IP address is un-provisioned at
the location where it was not marked as duplicate. the location where it was not marked as duplicate.
* Scenario B: The duplicate MAC or IP address is un-provisioned at * Scenario B: The duplicate MAC or IP address is un-provisioned at
the location where it was marked as duplicate. the location where it was marked as duplicate.
Unfreezing the duplicate and frozen MAC or IP route will result in Unfreezing the duplicate and frozen MAC or IP route will result in
skipping to change at line 1227 skipping to change at line 1248
"Geneve: Generic Network Virtualization Encapsulation", "Geneve: Generic Network Virtualization Encapsulation",
RFC 8926, DOI 10.17487/RFC8926, November 2020, RFC 8926, DOI 10.17487/RFC8926, November 2020,
<https://www.rfc-editor.org/info/rfc8926>. <https://www.rfc-editor.org/info/rfc8926>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986, (SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021, DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>. <https://www.rfc-editor.org/info/rfc8986>.
[RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and
A. Sajassi, "IP Prefix Advertisement in Ethernet VPN
(EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021,
<https://www.rfc-editor.org/info/rfc9136>.
Acknowledgements Acknowledgements
The authors would like to thank Gunter Van de Velde for the The authors would like to thank Gunter Van de Velde for the
significant contributions to improve the readability of this significant contributions to improve the readability of this
document. The authors would also like to thank Sonal Agarwal and document. The authors would also like to thank Sonal Agarwal and
Larry Kreeger for multiple contributions through the implementation Larry Kreeger for multiple contributions through the implementation
process. The authors would like to thank Vibov Bhan and Patrice process. The authors would like to thank Vibov Bhan and Patrice
Brissette for early feedback during the implementation and testing of Brissette for early feedback during the implementation and testing of
several procedures defined in this document. The authors would like several procedures defined in this document. The authors would like
to thank Wen Lin for a detailed review and valuable comments related to thank Wen Lin for a detailed review and valuable comments related
skipping to change at line 1293 skipping to change at line 1319
Email: jorge.rabadan@nokia.com Email: jorge.rabadan@nokia.com
Avinash Lingala Avinash Lingala
AT&T AT&T
3400 W Plano Pkwy 3400 W Plano Pkwy
Plano, TX 75075 Plano, TX 75075
United States of America United States of America
Email: ar977m@att.com Email: ar977m@att.com
John Drake John Drake
Juniper Networks Independent
Email: jdrake@juniper.net Email: je_drake@yahoo.com
 End of changes. 29 change blocks. 
77 lines changed or deleted 103 lines changed or added

This html diff was produced by rfcdiff 1.48.