draft-ietf-bess-evpn-etree-11.txt   draft-ietf-bess-evpn-etree-12.txt 
skipping to change at page 1, line 15 skipping to change at page 1, line 15
Intended Status: Standards Track Cisco Intended Status: Standards Track Cisco
Updates: 7385 J. Drake Updates: 7385 J. Drake
Juniper Juniper
J. Uttaro J. Uttaro
ATT ATT
S. Boutros S. Boutros
VMware VMware
J. Rabadan J. Rabadan
Nokia Nokia
Expires: November 12, 2017 May 12, 2017 Expires: December 22, 2017 June 22, 2017
E-TREE Support in EVPN & PBB-EVPN E-TREE Support in EVPN & PBB-EVPN
draft-ietf-bess-evpn-etree-11 draft-ietf-bess-evpn-etree-12
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). A solution Ethernet service known as Ethernet Tree (E-Tree). A solution
framework for supporting this service in MPLS networks is proposed in framework for supporting this service in MPLS networks is proposed in
RFC7387 ("A Framework for Ethernet Tree (E-Tree) Service over a RFC7387 ("A Framework for Ethernet Tree (E-Tree) Service over a
Multiprotocol Label Switching (MPLS) Network"). This document Multiprotocol Label Switching (MPLS) Network"). This document
discusses how those functional requirements can be easily met with discusses how those functional requirements can be easily met with
Ethernet VPN (EVPN) and how EVPN offers a more efficient Ethernet VPN (EVPN) and how EVPN offers a more efficient
skipping to change at page 3, line 7 skipping to change at page 3, line 7
3.2.4 BUM traffic originated from a multi-homed site on a 3.2.4 BUM traffic originated from a multi-homed site on a
root AC . . . . . . . . . . . . . . . . . . . . . . . . 10 root AC . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 E-TREE Traffic Flows for EVPN . . . . . . . . . . . . . . . 10 3.3 E-TREE Traffic Flows for EVPN . . . . . . . . . . . . . . . 10
3.3.1 E-Tree with MAC Learning . . . . . . . . . . . . . . . . 11 3.3.1 E-Tree with MAC Learning . . . . . . . . . . . . . . . . 11
3.3.2 E-Tree without MAC Learning . . . . . . . . . . . . . . 12 3.3.2 E-Tree without MAC Learning . . . . . . . . . . . . . . 12
4 Operation for PBB-EVPN . . . . . . . . . . . . . . . . . . . . . 12 4 Operation for PBB-EVPN . . . . . . . . . . . . . . . . . . . . . 12
4.1 Known Unicast Traffic . . . . . . . . . . . . . . . . . . . 13 4.1 Known Unicast Traffic . . . . . . . . . . . . . . . . . . . 13
4.2 BUM Traffic . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2 BUM Traffic . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 E-Tree without MAC Learning . . . . . . . . . . . . . . . . 13 4.3 E-Tree without MAC Learning . . . . . . . . . . . . . . . . 13
5 BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5 BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1 E-TREE Extended Community . . . . . . . . . . . . . . . . . 14 5.1 E-Tree Extended Community . . . . . . . . . . . . . . . . . 14
5.2 PMSI Tunnel Attribute . . . . . . . . . . . . . . . . . . . 15 5.2 PMSI Tunnel Attribute . . . . . . . . . . . . . . . . . . . 15
6 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 16 6 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 16
7 Security Considerations . . . . . . . . . . . . . . . . . . . . 16 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 16
8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16
8.1 Considerations for PMSI Tunnel Types . . . . . . . . . . . . 16 8.1 Considerations for PMSI Tunnel Types . . . . . . . . . . . . 17
9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1 Normative References . . . . . . . . . . . . . . . . . . . 17 9.1 Normative References . . . . . . . . . . . . . . . . . . . 17
9.2 Informative References . . . . . . . . . . . . . . . . . . 17 9.2 Informative References . . . . . . . . . . . . . . . . . . 18
Appendix-A . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Appendix-A . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
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) [MEF6.1]. In an E- Ethernet service known as Ethernet Tree (E-Tree) [MEF6.1]. In an E-
Tree service, Attachment Circuits (ACs) are labeled as either Root or Tree service, Attachment Circuits (ACs) are labeled as either Root or
Leaf ACs. Root ACs can communicate with all other ACs. Leaf ACs can Leaf ACs. Root ACs can communicate with all other ACs. Leaf ACs can
communicate with Root ACs but not with other Leaf ACs. communicate with Root ACs but not with other Leaf ACs.
skipping to change at page 14, line 11 skipping to change at page 14, line 11
broadcast, the PEs implementing an E-Tree service do not need to do broadcast, the PEs implementing an E-Tree service do not need to do
any MAC learning. In such scenarios the filtering must be performed any MAC learning. In such scenarios the filtering must be performed
on egress PEs. For PBB-EVPN, the handling of such traffic is per on egress PEs. For PBB-EVPN, the handling of such traffic is per
section 4.2 without C-MAC learning part of it at both ingress and section 4.2 without C-MAC learning part of it at both ingress and
egress PEs. egress PEs.
5 BGP Encoding 5 BGP Encoding
This document defines a new BGP Extended Community for EVPN. This document defines a 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 This Extended Community is a new transitive Extended Community
[RFC4360] having a Type field value of 0x06 (EVPN) and the Sub-Type [RFC4360] having a Type field value of 0x06 (EVPN) and the Sub-Type
0x05. It is used for leaf indication of known unicast and BUM 0x05. It is used for leaf indication of known unicast and BUM
traffic. traffic.
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=0x05 | Flags(1 Octet)| Reserved=0 | | Type=0x06 | Sub-Type=0x05 | Flags(1 Octet)| Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved=0 | Leaf Label | | Reserved=0 | Leaf Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: E-TREE Extended Community Figure 4: E-TREE Extended Community
The low-order bit of the Flags octet is defined as the "Leaf- The Flags field has the following format:
Indication" bit. A value of one indicates a Leaf AC/Site. The rest of
flag bits should be set to zero. 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| reserved |L|
+-+-+-+-+-+-+-+-+
This document defines the following flags:
+ Leaf-Indication (L)
A value of one indicates a Leaf AC/Site. The rest of flag bits are
reserved and should be set to zero.
When this Extended Community (EC) is advertised along with MAC/IP When this Extended Community (EC) is advertised along with MAC/IP
Advertisement route (for known unicast traffic) per section 3.1, the Advertisement route (for known unicast traffic) per section 3.1, the
Leaf-Indication flag MUST be set to one and Leaf Label SHOULD be set Leaf-Indication flag MUST be set to one and Leaf Label SHOULD be set
to zero. The label value is encoded in the high-order 20 bits of the to zero. The label value is encoded in the high-order 20 bits of the
Leaf Label field. The received PE SHOULD ignore Leaf Label and only Leaf Label field. The received PE SHOULD ignore Leaf Label and only
processes Leaf-Indication flag. A value of zero for Leaf-Indication processes Leaf-Indication flag. A value of zero for Leaf-Indication
flag is invalid when sent along with MAC/IP advertisement route and flag is invalid when sent along with MAC/IP advertisement route and
an error should be logged. an error should be logged.
skipping to change at page 15, line 33 skipping to change at page 15, line 43
| Tunnel Identifier (variable) | | Tunnel Identifier (variable) |
+---------------------------------+ +---------------------------------+
Figure 5: PMSI Tunnel Attribute Figure 5: PMSI Tunnel Attribute
This document defines a new Composite tunnel type by introducing a This document defines a new Composite tunnel type by introducing a
new 'Composite Tunnel' bit in the Tunnel Type field and adding a MPLS new 'Composite Tunnel' bit in the Tunnel Type field and adding a MPLS
label to the Tunnel Identifier field of PMSI Tunnel attribute as label to the Tunnel Identifier field of PMSI Tunnel attribute as
detailed below. This document uses all other remaining fields per detailed below. This document uses all other remaining fields per
existing definition. Composite tunnel type is advertised by the root existing definition. Composite tunnel type is advertised by the root
PE to simultaneously indicate a P2MP tunnel in transmit direction and PE to simultaneously indicate a non-ingress replication tunnel (e.g.,
an ingress-replication tunnel in the receive direction for the BUM P2MP tunnel) in transmit direction and an ingress-replication tunnel
traffic. in the receive direction for the BUM traffic.
When receiver ingress-replication label is needed, the high-order bit When receiver ingress-replication label is needed, the high-order bit
of the tunnel type field (Composite Tunnel bit) is set while the of the tunnel type field (Composite Tunnel bit) is set while the
remaining low-order seven bits indicate the tunnel type as before. remaining low-order seven bits indicate the tunnel type as before.
When this Composite Tunnel bit is set, the "tunnel identifier" field When this Composite Tunnel bit is set, the "tunnel identifier" field
would begin with a three-octet label, followed by the actual tunnel would begin with a three-octet label, followed by the actual tunnel
identifier for the transmit tunnel. PEs that don't understand the identifier for the transmit tunnel. PEs that don't understand the
new meaning of the high-order bit would treat the tunnel type as an new meaning of the high-order bit would treat the tunnel type as an
undefined tunnel type and would treat the PMSI tunnel attribute as a undefined tunnel type and would treat the PMSI tunnel attribute as a
malformed attribute [RFC6514]. For the PEs that do understand the new malformed attribute [RFC6514]. For the PEs that do understand the new
meaning of the high-order, if ingress replication is desired when meaning of the high-order, if ingress replication is desired when
sending BUM traffic, the PE will use the the label in the Tunnel sending BUM traffic, the PE will use the the label in the Tunnel
Identifier field when sending its BUM traffic. Identifier field when sending its BUM traffic.
skipping to change at page 16, line 38 skipping to change at page 16, line 48
8 IANA Considerations 8 IANA Considerations
IANA has allocated value 5 in the "EVPN Extended Community Sub-Types" IANA has allocated value 5 in the "EVPN Extended Community Sub-Types"
registry defined in [RFC7153] as follow: registry defined in [RFC7153] as follow:
SUB-TYPE VALUE NAME Reference SUB-TYPE VALUE NAME Reference
0x05 E-TREE Extended Community This document 0x05 E-TREE Extended Community This document
This document creates a one-octet registry called "E-Tree Flags".
New registrations will be made through the "RFC Required" procedure
defined in [RFC5226]. Initial registrations are as follows:
bit Name Reference
0-6 Reserved This document
7 Leaf-Indication This document
8.1 Considerations for PMSI Tunnel Types 8.1 Considerations for PMSI Tunnel Types
The "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" The "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types"
registry in the "Border Gateway Protocol (BGP) Parameters" registry registry in the "Border Gateway Protocol (BGP) Parameters" registry
needs to be updated to reflect the use of the most significant bit as needs to be updated to reflect the use of the most significant bit as
"Composite Tunnel" bit (section 5.2). "Composite Tunnel" bit (section 5.2).
For this purpose, this document updates [RFC7385]. For this purpose, this document updates [RFC7385].
The registry is to be updated, by removing the entries for 0xFB-0xFE The registry is to be updated, by removing the entries for 0xFB-0xFE
 End of changes. 11 change blocks. 
13 lines changed or deleted 33 lines changed or added

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