draft-ietf-bess-evpn-inter-subnet-forwarding-02.txt   draft-ietf-bess-evpn-inter-subnet-forwarding-03.txt 
skipping to change at page 1, line 17 skipping to change at page 1, line 17
J. Drake J. Drake
Juniper Juniper
J. Rabadan J. Rabadan
Nokia Nokia
L. Yong L. Yong
Huawei Huawei
Expires: August 8, 2017 February 8, 2017 Expires: August 8, 2017 February 8, 2017
Integrated Routing and Bridging in EVPN Integrated Routing and Bridging in EVPN
draft-ietf-bess-evpn-inter-subnet-forwarding-02 draft-ietf-bess-evpn-inter-subnet-forwarding-03
Abstract Abstract
EVPN provides an extensible and flexible multi-homing VPN solution EVPN provides an extensible and flexible multi-homing VPN solution
for intra-subnet connectivity among hosts/VMs over an MPLS/IP for intra-subnet connectivity among hosts/VMs over an MPLS/IP
network. However, there are scenarios in which inter-subnet network. However, there are scenarios in which inter-subnet
forwarding among hosts/VMs across different IP subnets is required, forwarding among hosts/VMs across different IP subnets is required,
while maintaining the multi-homing capabilities of EVPN. This while maintaining the multi-homing capabilities of EVPN. This
document describes an Integrated Routing and Bridging (IRB) solution document describes an Integrated Routing and Bridging (IRB) solution
based on EVPN to address such requirements. based on EVPN to address such requirements.
skipping to change at page 3, line 16 skipping to change at page 3, line 16
7.1 TS Mobility & Optimum Forwarding for TS Outbound Traffic . . 24 7.1 TS Mobility & Optimum Forwarding for TS Outbound Traffic . . 24
7.2 TS Mobility & Optimum Forwarding for TS Inbound Traffic . . 24 7.2 TS Mobility & Optimum Forwarding for TS Inbound Traffic . . 24
7.2.1 Mobility without Route Aggregation . . . . . . . . . . . 25 7.2.1 Mobility without Route Aggregation . . . . . . . . . . . 25
8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
9 Security Considerations . . . . . . . . . . . . . . . . . . . . 25 9 Security Considerations . . . . . . . . . . . . . . . . . . . . 25
10 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 10 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1 Normative References . . . . . . . . . . . . . . . . . . . 25 11.1 Normative References . . . . . . . . . . . . . . . . . . . 25
11.2 Informative References . . . . . . . . . . . . . . . . . . 26 11.2 Informative References . . . . . . . . . . . . . . . . . . 26
12 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 12 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Terminology 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Broadcast Domain: In a bridged network, the broadcast domain Broadcast Domain: In a bridged network, the broadcast domain
corresponds to a Virtual LAN (VLAN), where a VLAN is typically corresponds to a Virtual LAN (VLAN), where a VLAN is typically
represented by a single VLAN ID (VID) but can be represented by represented by a single VLAN ID (VID) but can be represented by
skipping to change at page 17, line 44 skipping to change at page 17, line 44
- MAC Address = Mi ; where i = 1,2,3,4, or 5 in the above example - MAC Address = Mi ; where i = 1,2,3,4, or 5 in the above example
- IP Address Length = 32 or 128 - IP Address Length = 32 or 128
- IP Address = IPi ; where i = 1,2,3,4, or 5 in the above example - IP Address = IPi ; where i = 1,2,3,4, or 5 in the above example
- Label-1 = MPLS Label or VNID corresponding to MAC-VRF - Label-1 = MPLS Label or VNID corresponding to MAC-VRF
- Label-2 = MPLS Label or VNID corresponding to IP-VRF - Label-2 = MPLS Label or VNID corresponding to IP-VRF
Each NVE advertises an RT-2 route with two Route Targets (one Each NVE advertises an RT-2 route with two Route Targets (one
corresponding to its MAC-VRF and the other corresponding to its IP- corresponding to its MAC-VRF and the other corresponding to its IP-
VRF. Furthermore, the RT-2 is advertised with two BGP Extended VRF. Furthermore, the RT-2 is advertised with two BGP Extended
Communities. The first BGP Extended Community identifies the tunnel Communities. The first BGP Extended Community identifies the tunnel
type per section 4.5 of [RFC5512] and the second BGP Extended type per section 4.5 of [TUNNEL-ENCAP] and the second BGP Extended
Community includes the MAC address of the NVE (e.g., MACx for NVE1 or Community includes the MAC address of the NVE (e.g., MACx for NVE1 or
MACy for NVE2) as defined in section 6.1. This second Extended MACy for NVE2) as defined in section 6.1. This second Extended
Community (for the MAC address of NVE) is only required when Ethernet Community (for the MAC address of NVE) is only required when Ethernet
NVO tunnel type is used. If IP NVO tunnel type is used, then there is NVO tunnel type is used. If IP NVO tunnel type is used, then there is
no need to send this second Extended Community. no need to send this second Extended Community.
Upon receiving this advertisement, the receiving NVE performs the Upon receiving this advertisement, the receiving NVE performs the
following: following:
- It uses Route Targets corresponding to its MAC-VRF and IP-VRF for - It uses Route Targets corresponding to its MAC-VRF and IP-VRF for
skipping to change at page 24, line 22 skipping to change at page 24, line 22
6 BGP Encoding 6 BGP Encoding
This document defines one new BGP Extended Community for EVPN. This document defines one new BGP Extended Community for EVPN.
6.1 Router's MAC Extended Community 6.1 Router's MAC Extended Community
A new EVPN BGP Extended Community called Router's MAC is introduced A new EVPN BGP Extended Community called Router's MAC is introduced
here. This new extended community is a transitive extended community here. This new extended community is a transitive extended community
with the Type field of 0x06 (EVPN) and the Sub-Type of 0x03. It may with the Type field of 0x06 (EVPN) and the Sub-Type of 0x03. It may
be advertised along with BGP Encapsulation Extended Community define be advertised along with BGP Encapsulation Extended Community define
in section 4.5 of [RFC5512]. in section 4.5 of [TUNNEL-ENCAP].
The Router's MAC Extended Community is encoded as an 8-octet value as The Router's MAC 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=0x03 | Router's MAC | | Type=0x06 | Sub-Type=0x03 | Router's MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router's MAC Cont'd | | Router's MAC Cont'd |
skipping to change at page 25, line 39 skipping to change at page 25, line 39
Mobility extended community in the received MAC Advertisement route. Mobility extended community in the received MAC Advertisement route.
This is per the procedures already defined in [EVPN]. This is per the procedures already defined in [EVPN].
8 Acknowledgements 8 Acknowledgements
The authors would like to thank Sami Boutros for his valuable The authors would like to thank Sami Boutros for his valuable
comments. comments.
9 Security Considerations 9 Security Considerations
The security considerations discussed in [RFC7432] apply to this The security considerations discussed in [EVPN] apply to this
document. document.
10 IANA Considerations 10 IANA Considerations
IANA has allocated a new transitive extended community Type of 0x06 IANA has allocated a new transitive extended community Type of 0x06
and Sub-Type of 0x03 for EVPN Router's MAC Extended Community. and Sub-Type of 0x03 for EVPN Router's MAC Extended Community.
11 References 11 References
11.1 Normative References 11.1 Normative References
[RFC2119] 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.
[EVPN] Sajassi et al., "BGP MPLS Based Ethernet VPN", RFC 7432,
February, 2015.
[TUNNEL-ENCAP] Rosen et al., "The BGP Tunnel Encapsulation
Attribute", draft-ietf-idr-tunnel-encaps-03, November
2016.
[EVPN-PREFIX] Rabadan et al., "IP Prefix Advertisement in EVPN",
draft-ietf-bess-evpn-prefix-advertisement-03, September,
2016.
11.2 Informative References 11.2 Informative References
[EVPN] Sajassi et al., "BGP MPLS Based Ethernet VPN", draft-ietf- [802.1Q] "IEEE Standard for Local and metropolitan area networks -
l2vpn-evpn-04.txt, work in progress, July, 2014. Media Access Control (MAC) Bridges and Virtual Bridged Local Area
Networks", IEEE Std 802.1Q(tm), 2014 Edition, November 2014.
[EVPN-IPVPN-INTEROP] Sajassi et al., "EVPN Seamless Interoperability [EVPN-IPVPN-INTEROP] Sajassi et al., "EVPN Seamless Interoperability
with IP-VPN", draft-sajassi-l2vpn-evpn-ipvpn-interop-01, work in with IP-VPN", draft-sajassi-l2vpn-evpn-ipvpn-interop-01, work in
progress, October, 2012. progress, October, 2012.
[DC-MOBILITY] Aggarwal et al., "Data Center Mobility based on [DC-MOBILITY] Aggarwal et al., "Data Center Mobility based on
BGP/MPLS, IP Routing and NHRP", draft-raggarwa-data-center-mobility- BGP/MPLS, IP Routing and NHRP", draft-raggarwa-data-center-mobility-
05.txt, work in progress, June, 2013. 05.txt, work in progress, June, 2013.
[EVPN-PREFIX] Rabadan et al., "IP Prefix Advertisement in EVPN",
draft-rabadan-l2vpn-evpn-prefix-advertisement-02, July, 2014.
12 Contributors 12 Contributors
In addition to the authors listed on the front page, the following In addition to the authors listed on the front page, the following
co-authors have also contributed to this document: co-authors have also contributed to this document:
Samer Salam Samer Salam
Florin Balus Florin Balus
Cisco Cisco
Yakov Rekhter Yakov Rekhter
 End of changes. 8 change blocks. 
10 lines changed or deleted 19 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/