draft-ietf-bess-evpn-etree-03.txt   draft-ietf-bess-evpn-etree-04.txt 
skipping to change at page 1, line 15 skipping to change at page 1, line 15
Intended Status: Standards Track Sami Boutros Intended Status: Standards Track Sami Boutros
Cisco Cisco
Wim Henderickx Wim Henderickx
Jorge Rabadan Jim Uttaro Jorge Rabadan Jim Uttaro
Alcatel-Lucent AT&T Alcatel-Lucent AT&T
John Drake Aldrin Isaac John Drake Aldrin Isaac
Wen Lin Juniper Wen Lin Juniper
Juniper Juniper
Expires: April 10, 2016 October 10, 2015 Expires: August 2, 2016 February 2, 2016
E-TREE Support in EVPN & PBB-EVPN E-TREE Support in EVPN & PBB-EVPN
draft-ietf-bess-evpn-etree-03 draft-ietf-bess-evpn-etree-04
Abstract Abstract
The Metro Ethernet Forum (MEF) has defined a rooted-multipoint The Metro Ethernet Forum (MEF) has defined a rooted-multipoint
Ethernet service known as Ethernet Tree (E-Tree). [ETREE-FMWK] Ethernet service known as Ethernet Tree (E-Tree). [ETREE-FMWK]
proposes a solution framework for supporting this service in MPLS proposes a solution framework for supporting this service in MPLS
networks. This document discusses how those functional requirements networks. This document discusses how those functional requirements
can be easily met with (PBB-)EVPN and how (PBB-)EVPN offers a more can be easily met with (PBB-)EVPN and how (PBB-)EVPN offers a more
efficient implementation of these functions. efficient implementation of these functions.
skipping to change at page 3, line 8 skipping to change at page 3, line 8
4 Operation for PBB-EVPN . . . . . . . . . . . . . . . . . . . . . 11 4 Operation for PBB-EVPN . . . . . . . . . . . . . . . . . . . . . 11
4.1 Known Unicast Traffic . . . . . . . . . . . . . . . . . . . 12 4.1 Known Unicast Traffic . . . . . . . . . . . . . . . . . . . 12
4.2 BUM Traffic . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2 BUM Traffic . . . . . . . . . . . . . . . . . . . . . . . . 12
5 BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5 BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1 E-TREE Extended Community . . . . . . . . . . . . . . . . . 13 5.1 E-TREE Extended Community . . . . . . . . . . . . . . . . . 13
5.2 PMSI Tunnel Attribute . . . . . . . . . . . . . . . . . . . 14 5.2 PMSI Tunnel Attribute . . . . . . . . . . . . . . . . . . . 14
6 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 14 6 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 14
7 Security Considerations . . . . . . . . . . . . . . . . . . . . 14 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 14
8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14
9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1 Normative References . . . . . . . . . . . . . . . . . . . 15 9.1 Normative References . . . . . . . . . . . . . . . . . . . 15
9.2 Informative References . . . . . . . . . . . . . . . . . . 15 9.2 Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1 Introduction 1 Introduction
The Metro Ethernet Forum (MEF) has defined a rooted-multipoint The Metro Ethernet Forum (MEF) has defined a rooted-multipoint
Ethernet service known as Ethernet Tree (E-Tree). In an E-Tree Ethernet service known as Ethernet Tree (E-Tree). In an E-Tree
service, endpoints are labeled as either Root or Leaf sites. Root service, endpoints are labeled as either Root or Leaf sites. Root
sites can communicate with all other sites. Leaf sites can sites can communicate with all other sites. Leaf sites can
skipping to change at page 5, line 32 skipping to change at page 5, line 32
service using topology constraint among the PEs belonging to the same service using topology constraint among the PEs belonging to the same
EVI. The purpose of this topology constraint is to avoid having PEs EVI. The purpose of this topology constraint is to avoid having PEs
with only Leaf sites importing and processing BGP MAC routes from with only Leaf sites importing and processing BGP MAC routes from
each other. To support such topology constrain in EVPN, two BGP each other. To support such topology constrain in EVPN, two BGP
Route-Targets (RTs) are used for every EVPN Instance (EVI): one RT is Route-Targets (RTs) are used for every EVPN Instance (EVI): one RT is
associated with the Root sites and the other is associated with the associated with the Root sites and the other is associated with the
Leaf sites. On a per EVI basis, every PE exports the single RT Leaf sites. On a per EVI basis, every PE exports the single RT
associated with its type of site(s). Furthermore, a PE with Root associated with its type of site(s). Furthermore, a PE with Root
site(s) imports both Root and Leaf RTs, whereas a PE with Leaf site(s) imports both Root and Leaf RTs, whereas a PE with Leaf
site(s) only imports the Root RT. If the number of EVIs is very large site(s) only imports the Root RT. If the number of EVIs is very large
(e.g., more than 32K or 64K), then RT type 0 as defined in [RFC4360] (e.g., more than 64K), then RT type 0 as defined in [RFC4360] SHOULD
SHOULD be used; otherwise, RT type 2 is sufficient. be used; otherwise, RT type 2 is sufficient [RFC7153].
2.2 Scenario 2: Leaf OR Root site(s) per AC 2.2 Scenario 2: Leaf OR Root site(s) per AC
In this scenario, a PE receives traffic from either Root OR Leaf In this scenario, a PE receives traffic from either Root OR Leaf
sites (but not both) on a given Attachment Circuit (AC) of an EVI. In sites (but not both) on a given Attachment Circuit (AC) of an EVI. In
other words, an AC (ES or ES/VLAN) is either associated with a Root other words, an AC (ES or ES/VLAN) is either associated with a Root
or Leaf (but not both). or Leaf (but not both).
+---------+ +---------+ +---------+ +---------+
| PE1 | | PE2 | | PE1 | | PE2 |
skipping to change at page 8, line 27 skipping to change at page 8, line 27
EVI route as described above. EVI route as described above.
3.2 BUM Traffic 3.2 BUM Traffic
For BUM traffic, it is not possible to perform filtering on the For BUM traffic, it is not possible to perform filtering on the
ingress PE, as is the case with known unicast, because of the multi- ingress PE, as is the case with known unicast, because of the multi-
destination nature of the traffic. As such, the solution relies on destination nature of the traffic. As such, the solution relies on
egress filtering. In order to apply the proper egress filtering, egress filtering. In order to apply the proper egress filtering,
which varies based on whether a packet is sent from a Leaf AC or a which varies based on whether a packet is sent from a Leaf AC or a
root AC, the MPLS-encapsulated frames MUST be tagged with an root AC, the MPLS-encapsulated frames MUST be tagged with an
indication of whether they originated from a Leaf AC or not. In other indication when they originated from a Leaf AC. In other words, leaf
words, leaf/root indication for BUM traffic is done at the indication for BUM traffic is done at the granularity of AC. This can
granularity of AC. This can be achieved in EVPN through the use of be achieved in EVPN through the use of a MPLS label where it can be
the ESI MPLS label. Therefore, the ESI MPLS label can be used to used to either identify the Ethernet segment of origin per [RFC 7432]
either identify the Ethernet segment of origin per [RFC 7432] or it (i.e., ESI label) or it can be used to indicate that the packet is
can be used to indicate that the packet is originated from a leaf originated from a leaf site (Leaf label).
site.
BUM traffic sent over a P2MP LSP or ingress replication, may need to BUM traffic sent over a P2MP LSP or ingress replication, may need to
carry an upstream assigned or downstream assigned MPLS label carry an upstream assigned or downstream assigned MPLS label
(respectively) for the purpose of egress filtering to indicate to the (respectively) for the purpose of egress filtering to indicate to the
egress PEs whether this packet is originated from a root AC or a leaf egress PEs whether this packet is originated from a leaf AC.
AC.
The main difference between downstream and upstream assigned ESI MPLS The main difference between downstream and upstream assigned MPLS
label is that in case of downstream assigned not all egress PE label is that in case of downstream assigned not all egress PE
devices need to receive the ESI label just like ingress replication devices need to receive the label just like ingress replication
procedures defined in [RFC7432]. procedures defined in [RFC7432].
There are four scenarios to consider as follow. In all these There are four scenarios to consider as follow. In all these
scenarios, the imposition PE imposes the right ESI MPLS label scenarios, the imposition PE imposes the right MPLS label associated
depending on whether the Ethernet frame originated from a Root or a with the originated Ethernet Segment (ES) depending on whether the
Leaf site on that Ethernet Segment. The mechanism by which the PE Ethernet frame originated from a Root or a Leaf site on that Ethernet
identifies whether a given frame originated from a Root or a Leaf Segment (ESI or Leaf label). The mechanism by which the PE identifies
site on the segment is based on the Ethernet Tag associated with the whether a given frame originated from a Root or a Leaf site on the
frame (e.g., whether the frame received on a leaf or a root AC). segment is based on the Ethernet Tag associated with the frame (e.g.,
whether the frame received on a leaf or a root AC). Other mechanisms
Other mechanisms for identifying whether an egress AC is a root or for identifying whether an ingress AC is a root or leaf is beyond the
leaf is beyond the scope of this document. scope of this document.
3.2.1 BUM traffic originated from a single-homed site on a leaf AC 3.2.1 BUM traffic originated from a single-homed site on a leaf AC
In this scenario, the ingress PE adds a special MPLS label indicating In this scenario, the ingress PE adds a special MPLS label indicating
a Leaf site. This special Leaf MPLS label, used for single-homing a Leaf site. This special Leaf MPLS label, used for single-homing
scenarios, is not on a per ES basis but rather on a per PE basis - scenarios, is not on a per ES basis but rather on a per PE basis -
i.e., a single Leaf MPLS label is used for all single-homed ES's on i.e., a single Leaf MPLS label is used for all single-homed ES's on
that PE. This Leaf MPLS label is advertised to other PE devices, that PE. This Leaf label is advertised to other PE devices, using a
using a new EVPN Extended Community called E-TREE Extended Community new EVPN Extended Community called E-TREE Extended Community (section
(section 5.1) along with an Ethernet A-D per ES route with ESI of 5.1) along with an Ethernet A-D per ES route with ESI of zero and a
zero and a set of Route Targets (RTs) corresponding to all the leaf set of Route Targets (RTs) corresponding to all EVIs on the PE with
ACs on the PE. The set of Ethernet A-D per ES routes may be needed if at least one leaf site per EVI. The set of Ethernet A-D per ES routes
the number of Route Targets (RTs) that need to be sent exceed the may be needed if the number of Route Targets (RTs) that need to be
limit on a single route per [RFC 7432]. The RT(s) represent EVIs with sent exceed the limit on a single route per [RFC 7432]. The ESI for
at least a leaf site in them. The ESI for the Ethernet A-D per ES the Ethernet A-D per ES route is set to zero to indicate single-homed
route is set to zero to indicate single-homed sites. sites.
When a PE receives this special ESI MPLS label in the data path, it When a PE receives this special Leaf label in the data path, it
blocks the packet if the destination AC is of type Leaf; otherwise, blocks the packet if the destination AC is of type Leaf; otherwise,
it forwards the packet. it forwards the packet.
3.2.2 BUM traffic originated from a single-homed site on a root AC 3.2.2 BUM traffic originated from a single-homed site on a root AC
In this scenario, the ingress PE does not add any ESI or Leaf MPLS In this scenario, the ingress PE does not add any ESI or Leaf label
label and it operates per [RFC7432] procedures. and it operates per [RFC7432] procedures.
3.2.3 BUM traffic originated from a multi-homed site on a leaf AC 3.2.3 BUM traffic originated from a multi-homed site on a leaf AC
In this scenario, it is assumed that a multi-homed Ethernet Segment In this scenario, it is assumed that While different ACs (VLANs) on
(ES) can have a mixed of both leaf and root ACs with each AC the same ES could have different root/leaf designation (some being
designating a subnet (e.g., a VLAN). Furthermore, it is assumed that roots and some being leaves), the same VLAN does have the same
there is no forwarding among subnets - ie, the service is EVPN L2 and root/leaf designation on all PEs on the same ES. Furthermore, it is
not EVPN IRB. IRB use case is for further study. assumed that there is no forwarding among subnets - ie, the service
is EVPN L2 and not EVPN IRB. IRB use case is outside the scope of
this document.
In such scenarios, If a multicast packet is originated from a leaf In such scenarios, If a multicast packet is originated from a leaf
AC, then it only needs to carry Leaf MPLS label described in section AC, then it only needs to carry Leaf label described in section
3.2.1. This label is sufficient in providing the necessary egress 3.2.1. This label is sufficient in providing the necessary egress
filtering of BUM traffic from getting sent to leaf ACs including the filtering of BUM traffic from getting sent to leaf ACs including the
leaf AC on the same Ethernet Segment. leaf AC on the same Ethernet Segment.
3.2.4 BUM traffic originated from a multi-homed site on a root AC 3.2.4 BUM traffic originated from a multi-homed site on a root AC
In this scenario, both the ingress and egress PE devices follows the In this scenario, both the ingress and egress PE devices follows the
procedure defined in [RFC 7432] for adding and/or processing an ESI procedure defined in [RFC 7432] for adding and/or processing an ESI
MPLS label. MPLS label.
skipping to change at page 10, line 29 skipping to change at page 10, line 29
In the subsections that follow, we will describe the operation of In the subsections that follow, we will describe the operation of
EVPN to support E-Tree service with and without MAC learning. EVPN to support E-Tree service with and without MAC learning.
3.3.1 E-Tree with MAC Learning 3.3.1 E-Tree with MAC Learning
The PEs implementing an E-Tree service must perform MAC learning when The PEs implementing an E-Tree service must perform MAC learning when
unicast traffic flows must be supported among Root and Leaf sites. In unicast traffic flows must be supported among Root and Leaf sites. In
this case, the PE with Root sites performs MAC learning in the data- this case, the PE with Root sites performs MAC learning in the data-
path over the Ethernet Segments, and advertises reachability in EVPN path over the Ethernet Segments, and advertises reachability in EVPN
MAC Advertisement routes. These routes will be imported by PEs that MAC Advertisement routes. These routes will be imported by all PEs
have Leaf sites as well as by PEs that have Root sites, in a given for that EVI (i.e., PEs that have Leaf sites as well as PEs that have
EVI. Similarly, the PEs with Leaf sites perform MAC learning in the Root sites). Similarly, the PEs with Leaf sites perform MAC learning
data-path over their Ethernet Segments, and advertise reachability in in the data-path over their Ethernet Segments, and advertise
EVPN MAC Advertisement routes which are imported only by PEs with at reachability in EVPN MAC Advertisement routes. For the scenario
least one Root site in the EVI. A PE with only Leaf sites will not described in section 2.1 (or possibly section 2.2), these routes are
import these routes. PEs with Root and/or Leaf sites may use the imported only by PEs with at least one Root site in the EVI - i.e., a
Ethernet A-D routes for aliasing (in the case of multi-homed PE with only Leaf sites will not import these routes. PEs with Root
segments) and for mass MAC withdrawal per [RFC 7432]. and/or Leaf sites may use the Ethernet A-D routes for aliasing (in
the case of multi-homed segments) and for mass MAC withdrawal per
[RFC 7432].
To support multicast/broadcast from Root to Leaf sites, either a P2MP To support multicast/broadcast from Root to Leaf sites, either a P2MP
tree rooted at the PE(s) with the Root site(s) or ingress replication tree rooted at the PE(s) with the Root site(s) or ingress replication
can be used. The multicast tunnels are set up through the exchange of can be used. The multicast tunnels are set up through the exchange of
the EVPN Inclusive Multicast route, as defined in [RFC7432]. the EVPN Inclusive Multicast route, as defined in [RFC7432].
To support multicast/broadcast from Leaf to Root sites, ingress To support multicast/broadcast from Leaf to Root sites, ingress
replication should be sufficient for most scenarios where there are replication should be sufficient for most scenarios where there are
only a few Roots (typically two). Therefore, in a typical scenario, a only a few Roots (typically two). Therefore, in a typical scenario, a
root PE needs to support both a P2MP tunnel in transmit direction root PE needs to support both a P2MP tunnel in transmit direction
skipping to change at page 11, line 16 skipping to change at page 11, line 18
in the receive direction for the BUM traffic. in the receive direction for the BUM traffic.
If the number of Roots is large, P2MP tunnels originated at the PEs If the number of Roots is large, P2MP tunnels originated at the PEs
with Leaf sites may be used and thus there will be no need to use the with Leaf sites may be used and thus there will be no need to use the
modified PMSI tunnel attribute in section 5.2 for composite tunnel modified PMSI tunnel attribute in section 5.2 for composite tunnel
type. type.
3.3.2 E-Tree without MAC Learning 3.3.2 E-Tree without MAC Learning
The PEs implementing an E-Tree service need not perform MAC learning The PEs implementing an E-Tree service need not perform MAC learning
when the traffic flows between Root and Leaf sites are multicast or when the traffic flows between Root and Leaf sites are only multicast
broadcast. In this case, the PEs do not exchange EVPN MAC or broadcast. In this case, the PEs do not exchange EVPN MAC
Advertisement routes. Instead, the Inclusive Multicast Ethernet Tag Advertisement routes. Instead, the Inclusive Multicast Ethernet Tag
(IMET) routes are used to support BUM traffic. (IMET) routes are used to support BUM traffic.
The fields of the IMET route are populated per the procedures defined The fields of the IMET route are populated per the procedures defined
in [RFC7432], and the route import rules are as described in previous in [RFC7432], and the multicast tunnel setup criteria are as
sections. described in the previous section.
Just as in the previous section, if the number of PEs with root sites Just as in the previous section, if the number of PEs with root sites
are only a few and thus ingress replication is desired from leaf PEs are only a few and thus ingress replication is desired from leaf PEs
to these root PEs, then the modified PMSI attribute as defined in to these root PEs, then the modified PMSI attribute as defined in
section 5.3 should be used. section 5.3 should be used.
4 Operation for PBB-EVPN 4 Operation for PBB-EVPN
In PBB-EVPN, the PE must advertise a Root/Leaf indication along with In PBB-EVPN, the PE must advertise a Root/Leaf indication along with
each B-MAC Advertisement route, to indicate whether the associated B- each B-MAC Advertisement route, to indicate whether the associated B-
skipping to change at page 13, line 12 skipping to change at page 13, line 13
among Leaf segments. This split-horizon function applies to BUM among Leaf segments. This split-horizon function applies to BUM
traffic. traffic.
5 BGP Encoding 5 BGP Encoding
This document defines two new BGP Extended Community for EVPN. This document defines two new BGP Extended Community for EVPN.
5.1 E-TREE Extended Community 5.1 E-TREE Extended Community
This Extended Community is a new transitive Extended Community having This Extended Community is a new transitive Extended Community having
a Type field value of 0x06 (EVPN) and the Sub-Type 0x05. It is used a Type field value of 0x06 (EVPN) and the Sub-Type 0x04. It is used
for leaf indication of known unicast and BUM traffic. For BUM for leaf indication of known unicast and BUM traffic. For BUM
traffic, the Leaf Label field is set to a valid MPLS label and this traffic, the Leaf Label field is set to a valid MPLS label and this
EC is advertised along with Ethernet A-D per ES route with an ESI of EC is advertised along with Ethernet A-D per ES route with an ESI of
zero to enable egress filtering on disposition PEs per section 3.2.1 zero to enable egress filtering on disposition PEs per section 3.2.1
and 3.2.3. For known unicast traffic, the Leaf flag bit is set to one and 3.2.3. For known unicast traffic, the Leaf flag bit is set to one
and this EC is advertised along with MAC/IP Advertisement route per and this EC is advertised along with MAC/IP Advertisement route per
section 3.1. section 3.1.
The E-TREE Extended Community is encoded as an 8-octet value as The E-TREE Extended Community is encoded as an 8-octet value as
follows: follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type=0x04 | Flags(1 Octet)| | | Type=0x06 | Sub-Type=0x04 | Flags(1 Octet)| Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved=0 | Leaf Label | | Reserved=0 | Leaf Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The low-order bit of the Flags octet is defined as the "Leaf- The low-order bit of the Flags octet is defined as the "Leaf-
Indication" bit. A value of one indicates a Leaf AC/Site. Indication" bit. A value of one indicates a Leaf AC/Site.
When this EC is advertised along with MAC/IP Advertisement route, the When this EC is advertised along with MAC/IP Advertisement route, the
Leaf-Indication flag MUST be set to one and Leaf Label is set to Leaf-Indication flag MUST be set to one and Leaf Label is set to
zero. The received PE should ignore Leaf Label and only processes zero. The received PE should ignore Leaf Label and only processes
skipping to change at page 14, line 46 skipping to change at page 14, line 46
We would like to thank Dennis Cai, Antoni Przygienda, and Jeffrey We would like to thank Dennis Cai, Antoni Przygienda, and Jeffrey
Zhang for their valueable comments. Zhang for their valueable comments.
7 Security Considerations 7 Security Considerations
Same security considerations as [RFC7432]. Same security considerations as [RFC7432].
8 IANA Considerations 8 IANA Considerations
Allocation of Extended Community Type and Sub-Type for EVPN. This document requests the allocation of value 4 in the "EVPN
Extended Community Sub-Types" registry defined in [RFC7153] and
modification of the registry as follow:
SUB-TYPE VALUE NAME Reference
0x04 E-TREE Extended Community This document
6-255 Unassigned
9 References 9 References
9.1 Normative References 9.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] 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.
[RFC4360] S. Sangli et al, ""BGP Extended Communities Attribute",
February, 2006.
[RFC7432] Sajassi et al., "BGP MPLS Based Ethernet VPN", February, [RFC7432] Sajassi et al., "BGP MPLS Based Ethernet VPN", February,
2015. 2015.
9.2 Informative References 9.2 Informative References
[ETREE-FMWK] Key et al., "A Framework for E-Tree Service over MPLS [ETREE-FMWK] Key et al., "A Framework for E-Tree Service over MPLS
Network", draft-ietf-l2vpn-etree-frwk-03, work in progress, September Network", draft-ietf-l2vpn-etree-frwk-03, work in progress, September
2013. 2013.
[PBB-EVPN] Sajassi et al., "PBB-EVPN", draft-ietf-l2vpn-pbb-evpn- [PBB-EVPN] Sajassi et al., "PBB-EVPN", draft-ietf-l2vpn-pbb-evpn-
05.txt, work in progress, October, 2013. 05.txt, work in progress, October, 2013.
[RFC4360] S. Sangli et al, "BGP Extended Communities Attribute",
February, 2006.
[RFC7153] Rosen et al., "IANA Registries for BGP Extended
Communities", March, 2014.
Authors' Addresses Authors' Addresses
Ali Sajassi Ali Sajassi
Cisco Cisco
Email: sajassi@cisco.com Email: sajassi@cisco.com
Samer Salam Samer Salam
Cisco Cisco
Email: ssalam@cisco.com Email: ssalam@cisco.com
 End of changes. 23 change blocks. 
62 lines changed or deleted 75 lines changed or added

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