draft-ietf-l2vpn-pbb-evpn-01.txt   draft-ietf-l2vpn-pbb-evpn-02.txt 
skipping to change at page 1, line 17 skipping to change at page 1, line 17
Florin Balus Nabil Bitar Florin Balus Nabil Bitar
Wim Henderickx Verizon Wim Henderickx Verizon
Alcatel-Lucent Alcatel-Lucent
Aldrin Isaac Aldrin Isaac
Clarence Filsfils Bloomberg Clarence Filsfils Bloomberg
Dennis Cai Dennis Cai
Cisco Lizhong Jin Cisco Lizhong Jin
ZTE ZTE
Expires: September 9, 2012 March 9, 2012 Expires: September 29, 2012 March 29, 2012
PBB E-VPN PBB E-VPN
draft-ietf-l2vpn-pbb-evpn-01 draft-ietf-l2vpn-pbb-evpn-02
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 23 skipping to change at page 3, line 23
7.4. Frame Forwarding . . . . . . . . . . . . . . . . . . . . . 13 7.4. Frame Forwarding . . . . . . . . . . . . . . . . . . . . . 13
7.4.1. Unicast . . . . . . . . . . . . . . . . . . . . . . . 13 7.4.1. Unicast . . . . . . . . . . . . . . . . . . . . . . . 13
7.4.2. Multicast/Broadcast . . . . . . . . . . . . . . . . . 13 7.4.2. Multicast/Broadcast . . . . . . . . . . . . . . . . . 13
8. Minimizing ARP Broadcast . . . . . . . . . . . . . . . . . . . 14 8. Minimizing ARP Broadcast . . . . . . . . . . . . . . . . . . . 14
9. Seamless Interworking with TRILL . . . . . . . . . . . . . . . 14 9. Seamless Interworking with TRILL . . . . . . . . . . . . . . . 14
9.1 TRILL Nickname Assignment . . . . . . . . . . . . . . . . . 15 9.1 TRILL Nickname Assignment . . . . . . . . . . . . . . . . . 15
9.2 TRILL Nickname Advertisement Route . . . . . . . . . . . . 16 9.2 TRILL Nickname Advertisement Route . . . . . . . . . . . . 16
9.3 Frame Format . . . . . . . . . . . . . . . . . . . . . . . . 16 9.3 Frame Format . . . . . . . . . . . . . . . . . . . . . . . . 16
9.4 Unicast Forwarding . . . . . . . . . . . . . . . . . . . . 17 9.4 Unicast Forwarding . . . . . . . . . . . . . . . . . . . . 17
9.5 Handling Multicast . . . . . . . . . . . . . . . . . . . . . 18 9.5 Handling Multicast . . . . . . . . . . . . . . . . . . . . . 18
10. Seamless Interworking with IEEE 802.1aq/802.1Qbp . . . . . . . 18 9.5.1 Multicast Stitching with Per-Source Load Balancing . . . 19
10.2 B-MAC Address Assignment . . . . . . . . . . . . . . . . . 19 9.5.2 Multicast Stitching with Per-VLAN Load Balancing . . . . 19
10.2 IEEE 802.1aq / 802.1Qbp B-MAC Advertisement Route . . . . 19 9.5.3 Multicast Stitching with Per-Flow Load Balancing . . . . 20
10.3 Operation: . . . . . . . . . . . . . . . . . . . . . . . . 20 9.5.4 Multicast Stitching with Per-Tree Load Balancing . . . . 20
11. Solution Advantages . . . . . . . . . . . . . . . . . . . . . 20 10. Seamless Interworking with IEEE 802.1aq/802.1Qbp . . . . . . . 21
11.1. MAC Advertisement Route Scalability . . . . . . . . . . . 20 10.2 B-MAC Address Assignment . . . . . . . . . . . . . . . . . 21
11.2. C-MAC Mobility with MAC Sub-netting . . . . . . . . . . . 21 10.2 IEEE 802.1aq / 802.1Qbp B-MAC Advertisement Route . . . . 21
11.3. C-MAC Address Learning and Confinement . . . . . . . . . 21 10.3 Operation: . . . . . . . . . . . . . . . . . . . . . . . . 22
11. Solution Advantages . . . . . . . . . . . . . . . . . . . . . 22
11.1. MAC Advertisement Route Scalability . . . . . . . . . . . 22
11.2. C-MAC Mobility with MAC Sub-netting . . . . . . . . . . . 23
11.3. C-MAC Address Learning and Confinement . . . . . . . . . 23
11.4. Seamless Interworking with TRILL and 802.1aq Access 11.4. Seamless Interworking with TRILL and 802.1aq Access
Networks . . . . . . . . . . . . . . . . . . . . . . . . 21 Networks . . . . . . . . . . . . . . . . . . . . . . . . 23
11.5. Per Site Policy Support . . . . . . . . . . . . . . . . . 22 11.5. Per Site Policy Support . . . . . . . . . . . . . . . . . 24
11.6. Avoiding C-MAC Address Flushing . . . . . . . . . . . . . 22 11.6. Avoiding C-MAC Address Flushing . . . . . . . . . . . . . 24
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
13. Security Considerations . . . . . . . . . . . . . . . . . . . 23 13. Security Considerations . . . . . . . . . . . . . . . . . . . 25
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
15. Intellectual Property Considerations . . . . . . . . . . . . 23 15. Intellectual Property Considerations . . . . . . . . . . . . 25
16. Normative References . . . . . . . . . . . . . . . . . . . . 23 16. Normative References . . . . . . . . . . . . . . . . . . . . 25
17. Informative References . . . . . . . . . . . . . . . . . . . 23 17. Informative References . . . . . . . . . . . . . . . . . . . 25
18. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 23 18. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
[E-VPN] introduces a solution for multipoint L2VPN services, with [E-VPN] introduces a solution for multipoint L2VPN services, with
advanced multi-homing capabilities, using BGP for distributing advanced multi-homing capabilities, using BGP for distributing
customer/client MAC address reach-ability information over the core customer/client MAC address reach-ability information over the core
MPLS/IP network. [802.1ah] defines an architecture for Ethernet MPLS/IP network. [802.1ah] defines an architecture for Ethernet
Provider Backbone Bridging (PBB), where MAC tunneling is employed to Provider Backbone Bridging (PBB), where MAC tunneling is employed to
improve service instance and MAC address scalability in Ethernet as improve service instance and MAC address scalability in Ethernet as
well as VPLS networks [PBB-VPLS]. well as VPLS networks [PBB-VPLS].
skipping to change at page 18, line 37 skipping to change at page 18, line 37
- LSM with Aggregate Selective trees - LSM with Aggregate Selective trees
When LSM is used, the trees may be either P2MP or MP2MP. When LSM is used, the trees may be either P2MP or MP2MP.
The MES nodes are responsible for stitching the TRILL multicast The MES nodes are responsible for stitching the TRILL multicast
trees, on the access side, to the ingress replication tunnels or LSM trees, on the access side, to the ingress replication tunnels or LSM
trees in the MPLS/IP core. The stitching must ensure that the trees in the MPLS/IP core. The stitching must ensure that the
following characteristics are maintained at all times: following characteristics are maintained at all times:
1. Avoiding Packet Duplication: In the case where the TRILL network 1. Avoiding Packet Duplication: In the case where the TRILL network
is multi-homed to multiple MES nodes. This applies to both multicast is multi-homed to multiple MES nodes, if all of the MES nodes forward
traffic from site to core as well as core to site. the same multicast frame, then packet duplication would arise. This
applies to both multicast traffic from site to core as well as from
core to site.
2. Avoiding Forwarding Loops: Again in the case of multi-homing 2. Avoiding Forwarding Loops: In the case of TRILL network multi-
above. homing, the solution must ensure that a multicast frame forwarded by
a given MES to the MPLS core is not forwarded back by another MES (in
the same TRILL network) to the TRILL network of origin. The same
applies for traffic in the core to site direction.
3. Pacifying TRILL RPF Checks: For multicast traffic originating from 3. Pacifying TRILL RPF Checks: For multicast traffic originating from
a different TRILL network, the RPF checks must be performed against a different TRILL network, the RPF checks must be performed against
the disposition MES (i.e. the MES on which the traffic ingress into the disposition MES (i.e. the MES on which the traffic ingress into
the destination TRILL network). the destination TRILL network).
There are two approaches by which the above operation can be
guaranteed: one offers per-source load-balancing while the other
offers per-flow load-balancing.
9.5.1 Multicast Stitching with Per-Source Load Balancing
The MES nodes, connected to a multi-homed TRILL network, perform BGP
DF election to decide which MES is responsible for forwarding
multicast traffic from a given source RBridge. An MES would only
forward multicast traffic from source RBridges for which it is the
DF, in both the site to core as well as core to site directions. This
solves both the issue of avoiding packet duplication as well as the
issue of avoiding forwarding loops.
In addition, the MES node advertises in IS-IS the nicknames of remote
RBridges, learnt in BGP, for which it is the elected DF. This allows
all RBridges in the local TRILL network to build the correct RPF
state for these remote RBridge nicknames. Note that this results in
all unicast traffic to a given remote RBridge being forwarded to the
DF MES only (i.e. load-balancing of unicast traffic would not be
possible in the site to core direction).
Alternatively, all MES nodes in a redundancy group can advertise the
nicknames of all remote RBridges learnt in BGP. In addition, each MES
advertises the Affinity sub-TLV, defined in [TRILL-CMT], on behalf of
each of the remote RBridges for which it is the elected DF. This
ensures that the RPF check state is set up correctly in the TRILL
network, while allowing load-balancing of unicast traffic among the
MES nodes.
In this approach, all MES nodes in a given redundancy group can
forward and receive traffic on all TRILL trees.
9.5.2 Multicast Stitching with Per-VLAN Load Balancing
The MES nodes, connected to a multi-homed TRILL network, perform BGP
DF election to decide which MES node is responsible for forwarding
multicast traffic associated with a given VLAN. An MES would forward
multicast traffic for a given VLAN only when it is the DF for this
VLAN. This forwarding rule applies in both the site to core as well
as core to site directions.
In addition, the MES nodes in the redundancy group partition among
themselves the set of TRILL multicast trees so that each MES only
sends traffic on a unique set of trees. This can be done using the RP
Election Protocol as discussed in [TRILL-MULTILEVEL]. Alternatively,
the BGP DF election could be used for that. Each MES, then,
advertises to the local TRILL network a Default Affinity sub-TLV, per
[TRILL-MULTILEVEL], listing the trees that it will be using for
multicast traffic originating from remote RBridges.
In this approach, each MES node in given TRILL network receives
traffic from all TRILL trees but forwards traffic on only a dedicated
subset of trees. Hence, the TRILL network must have at least as many
multicast trees as the number of directly attached MES nodes.
9.5.3 Multicast Stitching with Per-Flow Load Balancing
This approach is similar to the per-VLAN load-balancing approach
described above, with the difference being that the MES nodes perform
the BGP DF election on a per-flow basis. The flow is identified by an
N-Tuple comprising of Layer 2 and Layer 3 addresses in addition to
Layer 4 ports. This can be done by treating the N-Tuple as a numeric
value, and performing, for e.g., a modulo hash function against the
number of PEs in the redundancy group in order to identify the index
of the PE that is the DF for a given N-Tuple.
In this approach, each MES node in given TRILL network receives
traffic from all TRILL trees but forwards traffic on only a dedicated
subset of trees. Hence, the TRILL network must have at least as many
multicast trees as the number of directly attached MES nodes.
9.5.4 Multicast Stitching with Per-Tree Load Balancing
The MES nodes, connected to a multi-homed TRILL network, perform BGP
DF election to decide which MES node is responsible for forwarding
multicast traffic associated with a given TRILL multicast tree. An
MES would forward multicast traffic with a given destination RBridge
nickname only when it is the DF for this nickname. This forwarding
rule applies in both the site to core as well as core to site
directions. The outcome of the BGP DF election is then used to drive
TRILL IS-IS advertisements: the MES advertises to the local TRILL
network a Default Affinity sub-TLV, per [TRILL-MULTILEVEL], listing
the trees for which it is the elected DF.
Note that on the egress MES, the destination RBridge Nickname in
multicast frames identifies the multicast tree of the remote TRILL
network from which the frame originated. If the TRILL tree
identifiers are not coordinated between sites, then the egress
Nickname has no meaning in the directly attached (destination) TRILL
network. So, the MES needs to select a new tree (after the MPLS
disposition) based on a hash function, and rewrite the frame with
this new destination Nickname before forwarding the traffic. This may
be necessary in certain deployments to ensure complete decoupling
between the TRILL sites connected to the MPLS core. On the other
hand, if the TRILL tree identifiers are coordinated between sites,
then the MES doesn't have to rewrite the destination nickname in the
TRILL header, after the MPLS disposition.
In this approach, each MES node in a given redundancy group forwards
and receives traffic on a disjoint set of TRILL trees. At a minimum,
the TRILL network must have as many multicast trees as the number of
directly attached MES nodes.
10. Seamless Interworking with IEEE 802.1aq/802.1Qbp 10. Seamless Interworking with IEEE 802.1aq/802.1Qbp
+--------------+ +--------------+
| | | |
+---------+ | MPLS | +---------+ +---------+ | MPLS | +---------+
+----+ | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ | | +----+
|SW1 |--| | |MES1| |MES2| | |--| SW3| |SW1 |--| | |MES1| |MES2| | |--| SW3|
+----+ | 802.1aq |---| | | |--| 802.1aq | +----+ +----+ | 802.1aq |---| | | |--| 802.1aq | +----+
+----+ | .1Qbp | +----+ +----+ | .1Qbp | +----+ +----+ | .1Qbp | +----+ +----+ | .1Qbp | +----+
|SW2 |--| | | Backbone | | |--| SW4| |SW2 |--| | | Backbone | | |--| SW4|
+----+ +---------+ +--------------+ +---------+ +----+ +----+ +---------+ +--------------+ +---------+ +----+
skipping to change at page 23, line 42 skipping to change at page 25, line 42
Backbone Bridges", draft-ietf-l2vpn-vpls-pbb-interop- Backbone Bridges", draft-ietf-l2vpn-vpls-pbb-interop-
02.txt, work in progress, July, 2011. 02.txt, work in progress, July, 2011.
[EVPN-REQ] Sajassi et al., "Requirements for Ethernet VPN (E-VPN)", [EVPN-REQ] Sajassi et al., "Requirements for Ethernet VPN (E-VPN)",
draft-sajassi-raggarwa-l2vpn-evpn-req-01.txt, work in draft-sajassi-raggarwa-l2vpn-evpn-req-01.txt, work in
progress, July, 2011. progress, July, 2011.
[E-VPN] Aggarwal et al., "BGP MPLS Based Ethernet VPN", draft-ietf- [E-VPN] Aggarwal et al., "BGP MPLS Based Ethernet VPN", draft-ietf-
l2vpn-evpn-00.txt, work in progress, February, 2012. l2vpn-evpn-00.txt, work in progress, February, 2012.
18. Authors' Addresses [TRILL-CMT] Senevirathne et al., "Coordinated Multicast Trees for
TRILL", draft-tissa-trill-cmt-00.txt, work in progress,
January 2012.
[TRILL-MULTILEVEL] Senevirathne et al., "Default Nickname Based
Approach for Multilevel TRILL", draft-tissa-trill-
multilevel-00.txt, work in progress, February 2012.
18. Authors' Addresses
Ali Sajassi Ali Sajassi
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134, US San Jose, CA 95134, US
Email: sajassi@cisco.com Email: sajassi@cisco.com
Samer Salam Samer Salam
Cisco Cisco
595 Burrard Street, Suite 2123 595 Burrard Street, Suite 2123
Vancouver, BC V7X 1J1, Canada Vancouver, BC V7X 1J1, Canada
Email: ssalam@cisco.com Email: ssalam@cisco.com
Sami Boutros Sami Boutros
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134, US San Jose, CA 95134, US
 End of changes. 11 change blocks. 
25 lines changed or deleted 148 lines changed or added

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