< draft-ietf-trill-irb-09.txt   draft-ietf-trill-irb-10.txt >
skipping to change at page 1, line 13 skipping to change at page 1, line 13
INTERNET-DRAFT Y. Li INTERNET-DRAFT Y. Li
Intended Status: Standard Track Huawei Intended Status: Standard Track Huawei
A. Qu A. Qu
MediaTec MediaTec
M. Durrani M. Durrani
Cisco Cisco
P. Sivamurugan P. Sivamurugan
IP Infusion IP Infusion
L. Xia L. Xia
Huawei Huawei
Expires: June 10, 2016 December 10, 2015 Expires: July 28, 2016 January 28, 2016
TRILL Distributed Layer 3 Gateway TRILL Distributed Layer 3 Gateway
draft-ietf-trill-irb-09.txt draft-ietf-trill-irb-10.txt
Abstract Abstract
The base TRILL protocol provides optimal pair-wise data frame The base TRILL protocol provides optimal pair-wise data frame
forwarding for layer 2 intra-subnet traffic but not for layer 3 forwarding for layer 2 intra-subnet traffic but not for layer 3
inter-subnet traffic. A centralized gateway solution is typically inter-subnet traffic. A centralized gateway solution is typically
used for layer 3 inter-subnet traffic forwarding but has the used for layer 3 inter-subnet traffic forwarding but has the
following issues: following issues:
1. Sub-optimum forwarding paths for inter-subnet traffic. 1. Sub-optimum forwarding paths for inter-subnet traffic.
skipping to change at page 2, line 33 skipping to change at page 2, line 33
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction ................................................ 3 1. Introduction ................................................ 3
1.1. Document Organization................................... 3 1.1. Document Organization................................... 3
2. Conventions used in this document............................ 4 2. Conventions used in this document............................ 4
3. Simplified Example and Problem Statement .................... 5 3. Simplified Example and Problem Statement..................... 5
3.1. Simplified Example...................................... 5 3.1. Simplified Example...................................... 5
3.2. Problem Statement Summary............................... 8 3.2. Problem Statement Summary............................... 8
4. Layer 3 Traffic Forwarding Model............................. 9 4. Layer 3 Traffic Forwarding Model............................. 9
5. Distributed Gateway Solution Details ........................ 9 5. Distributed Gateway Solution Details......................... 9
5.1. Local Routing Information.............................. 10 5.1. Local Routing Information.............................. 10
5.2. Local Routing Information Synchronization ............. 11 5.2. Local Routing Information Synchronization.............. 11
5.3. Active-active Access................................... 13 5.3. Active-active Access................................... 13
5.4. Data Traffic Forwarding Process ....................... 14 5.4. Data Traffic Forwarding Process........................ 14
6. Distributed Layer 3 Gateway Process Example ................ 14 6. Distributed Layer 3 Gateway Process Example................. 15
6.1. Control plane process.................................. 16 6.1. Control plane process.................................. 16
6.2. Data Plane Process..................................... 16 6.2. Data Plane Process..................................... 17
7. TRILL Protocol Extensions................................... 17 7. TRILL Protocol Extensions................................... 18
7.1. The Tenant Label and Gateway MAC APPsub-TLV ........... 18 7.1. The Tenant Label and Gateway MAC APPsub-TLV............ 18
7.2. "SE" Flag in NickFlags APPsub-TLV ..................... 19 7.2. "SE" Flag in NickFlags APPsub-TLV...................... 19
7.3. The IPv4 Prefix APPsub-TLV............................. 19 7.3. The IPv4 Prefix APPsub-TLV............................. 19
7.4. The IPv6 Prefix APPsub-TLV ............................ 20 7.4. The IPv6 Prefix APPsub-TLV............................. 20
8. Security Considerations..................................... 21 8. Security Considerations..................................... 21
9. IANA Considerations ........................................ 21 9. IANA Considerations ........................................ 22
10. Normative References....................................... 22 10. Normative References....................................... 22
11. Informative References..................................... 23 11. Informative References..................................... 23
Acknowledgments ............................................... 23 Acknowledgments ............................................... 23
Authors' Addresses ............................................ 23 Authors' Addresses ............................................ 23
1. Introduction 1. Introduction
The TRILL (Transparent Interconnection of Lots of Links) protocol The TRILL (Transparent Interconnection of Lots of Links) protocol
[RFC6325] provides a solution for least cost transparent routing in [RFC6325] provides a solution for least cost transparent routing in
multi-hop networks with arbitrary topologies and link technologies, multi-hop networks with arbitrary topologies and link technologies,
skipping to change at page 6, line 27 skipping to change at page 6, line 27
|TOR1 | |TOR2 | |TOR3 | |TOR4 | |TOR1 | |TOR2 | |TOR3 | |TOR4 |
------- ------- ------- ------- ------- ------- ------- -------
| | | | | | | | | | | | | | | |
----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
|ES1| |ES2| |ES3| |ES4| |ES5| |ES6| |ES7| |ES8| |ES1| |ES2| |ES3| |ES4| |ES5| |ES6| |ES7| |ES8|
----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
Figure 1. A Typical TRILL DC Network Figure 1. A Typical TRILL DC Network
Figure 1 depicts a TRILL Data Center Network where Top of Rack (ToR) Figure 1 depicts a TRILL Data Center Network where Top of Rack (ToR)
switches are edge RBridges. ES1 to ES8 belong to one tenant, the switches are edge RBridges. ES1 to ES8 belong to one tenant network
tenant has four subnets, each subnet corresponds to one VLAN and the tenant has four subnets with each subnet corresponding to
indicating one individual layer 2 virtual network, each ES's IP one VLAN (which indicates one individual layer 2 virtual
address, VLAN and subnet are listed as follows: network). Each ES's IP address, VLAN and subnet are listed below:
+----+----------------+-----------------+----------+ +----+----------------+-----------------+----------+
| ES | IP Address | Subnet | VLAN | | ES | IP Address | Subnet | VLAN |
+----+----------------+-----------------+----------+ +----+----------------+-----------------+----------+
| ES1| 192.0.2.2 | 192.0.2.0/24 | 10 | | ES1| 192.0.2.2 | 192.0.2.0/24 | 10 |
+----+----------------+-----------------+----------+ +----+----------------+-----------------+----------+
| ES2| 198.51.100.2 | 198.51.100.0/24 | 11 | | ES2| 198.51.100.2 | 198.51.100.0/24 | 11 |
+----+----------------+-----------------+----------+ +----+----------------+-----------------+----------+
| ES3| 192.0.2.3 | 192.0.2.0/24 | 10 | | ES3| 192.0.2.3 | 192.0.2.0/24 | 10 |
+----+----------------+-----------------+----------+ +----+----------------+-----------------+----------+
skipping to change at page 7, line 44 skipping to change at page 7, line 44
When each end station ARPs for their layer 3 gateway, that is, their When each end station ARPs for their layer 3 gateway, that is, their
IP router, the edge RBridge to which it is connected will respond IP router, the edge RBridge to which it is connected will respond
with that RBridge's 'gateway MAC'. When the end station later sends with that RBridge's 'gateway MAC'. When the end station later sends
IP traffic to the layer 3 gateway, which it does if the destination IP traffic to the layer 3 gateway, which it does if the destination
IP is outside of its subnet, the edge RBridge intercepts the IP IP is outside of its subnet, the edge RBridge intercepts the IP
packet because the destination MAC is its gateway MAC. That RBridge packet because the destination MAC is its gateway MAC. That RBridge
routes the IP packet using the routing instance associated with that routes the IP packet using the routing instance associated with that
tenant, handling it in one of three ways: tenant, handling it in one of three ways:
(1) ES1 communicates with ES2. The destination IP is (1) ES1 communicates with ES2. The destination IP is
connected to the same edge RBridge, the RBridge of TOR1 can simply connected to the same edge RBridge, the RBridge of TOR1 can simply
transmit the IP packet out the right edge port in the destination transmit the IP packet out the right edge port in the destination
VLAN. VLAN.
(2) If the destination IP is located in an outside network, (2) If the destination IP is located in an outside network,
the edge RBridge encapsulates it as a TRILL Data packet and sends it the edge RBridge encapsulates it as a TRILL Data packet and sends it
to the actual TRILL campus edge RBridge connecting to an external IP to the actual TRILL campus edge RBridge connecting to an external IP
router. router.
(3) ES1 communicates with ES4. The destination end station (3) ES1 communicates with ES4. The destination end station
is connected to a different edge RBridge, the ingress RBridge TOR1 is connected to a different edge RBridge, the ingress RBridge TOR1
uses TRILL encapsulation to route the IP packet to the correct uses TRILL encapsulation to route the IP packet to the correct
egress RBridge TOR2, using the egress RBridge's gateway MAC and an egress RBridge TOR2, using the egress RBridge's gateway MAC and an
Inner.VLAN identifying the tenant. Finally, the egress RBridge Inner.VLAN identifying the tenant. Finally, the egress RBridge
terminates the TRILL encapsulation and routes the IP packet to the terminates the TRILL encapsulation and routes the IP packet to the
destination end station based on the routing instance for that destination end station based on the routing instance for that
tenant. tenant.
3.2. Problem Statement Summary 3.2. Problem Statement Summary
skipping to change at page 11, line 4 skipping to change at page 11, line 4
5.1. Local Routing Information 5.1. Local Routing Information
An ES can be locally connected to an edge RBridges through a layer 2 An ES can be locally connected to an edge RBridges through a layer 2
network (such as a point-to-point Ethernet link or a bridged LAN) or network (such as a point-to-point Ethernet link or a bridged LAN) or
externally connected through a layer 3 IP network. externally connected through a layer 3 IP network.
If the ES is connected to an edge RBridge through a Layer 2 network, If the ES is connected to an edge RBridge through a Layer 2 network,
then the edge RBridge acts as a Layer 3 Gateway for the ES. A then the edge RBridge acts as a Layer 3 Gateway for the ES. A
gateway interface is established on the edge RBridge for the gateway interface is established on the edge RBridge for the
connecting ES. Because the ESs in a subnet may be spread over connecting ES. Because the ESs in a subnet may be spread over
multiple edge RBridges, each of these edge RBridges establishes its multiple edge RBridges, in each of these edge RBridges which
gateway interface for the subnet and these gateway interfaces on establishes its gateway interface for the subnet the edge RBridges
different edge RBridges share the same gateway MAC and gateway IP SHOULD share the same gateway MAC and gateway IP address
address. configuration. Sharing the configuration and insuring configuration
consistency can be done by local configuration and netconf/Yang
models.
With distributed gateway, the edge RBridge to which an end station With distributed gateway, the edge RBridge to which an end station
is connected appears to be the local IP router on its link. As in is connected appears to be the local IP router on its link. As in
any IP network, before the end station starts to send inter-subnet any IP network, before the end station starts to send inter-subnet
traffic, it acquires its gateway's MAC through the ARP/ND process. traffic, it acquires its gateway's MAC through the ARP/ND process.
Local connecting edge RBridges that support this distributed gateway Local connecting edge RBridges that support this distributed gateway
feature always respond with the gateway MAC address when receiving feature always respond with the gateway MAC address when receiving
ARP/ND requests for the gateway IP. Through the ARP/ND process, the ARP/ND requests for the gateway IP. Through the ARP/ND process, the
edge RBridge can learn the IP and MAC correspondence of a local ES edge RBridge can learn the IP and MAC correspondence of a local ES
connected to the edge RBridge by Layer 2 and then generate local IP connected to the edge RBridge by Layer 2 and then generate local IP
skipping to change at page 11, line 47 skipping to change at page 11, line 49
egress RBridge as the inner VLAN or FGL and uses the tenant gateway egress RBridge as the inner VLAN or FGL and uses the tenant gateway
MAC advertised by the egress RBridge as the Inner.MacDA. The egress MAC advertised by the egress RBridge as the Inner.MacDA. The egress
RBridge relies on this tenant Data Label to find the local VRF RBridge relies on this tenant Data Label to find the local VRF
instance for the IP forwarding process when receiving inter-subnet instance for the IP forwarding process when receiving inter-subnet
traffic from the TRILL campus. (The role of tenant Label is akin to traffic from the TRILL campus. (The role of tenant Label is akin to
an MPLS VPN Label in an MPLS IP/MPLS VPN network.) Tenant Data an MPLS VPN Label in an MPLS IP/MPLS VPN network.) Tenant Data
Labels are independently allocated on each edge RBridge for each Labels are independently allocated on each edge RBridge for each
routing domain. An edge RBridge can use an access Data Label from a routing domain. An edge RBridge can use an access Data Label from a
routing domain to act as the inter-subnet Label, or the edge RBridge routing domain to act as the inter-subnet Label, or the edge RBridge
can use a Label different from any access Labels to be a tenant can use a Label different from any access Labels to be a tenant
Label. It's implementation dependant and there is no restriction on Label. It is implementation dependent and there is no restriction on
this. The tenant gateway MAC differentiates inter-subnet Layer 3 this assignment of labels.
traffic or intra-subnet Layer 2 traffic on the egress RBridge. Each
tenant on a RBridge can use a different gateway MAC or same tenant The tenant gateway MAC differentiates inter-subnet Layer 3 traffic
gateway MAC for inter-subnet traffic purposes. This is also or intra-subnet Layer 2 traffic on the egress RBridge. Each tenant
implementation dependant and there is no restriction on it. on a RBridge can use a different gateway MAC or same tenant gateway
MAC for inter-subnet traffic purposes. This is also implementation
dependant and there is no restriction on it.
When a local IP prefix is learned in a routing instance on an edge When a local IP prefix is learned in a routing instance on an edge
RBridge, the edge RBridge should advertise the IP prefix information RBridge, the edge RBridge should advertise the IP prefix information
for the routing instance so that other edge RBridges will generate for the routing instance so that other edge RBridges will generate
IP routing entries. If the ESs in a VN are spread over multiple IP routing entries. If the ESs in a VN are spread over multiple
RBridges, these RBridges should advertise each local connecting end RBridges, these RBridges should advertise each local connecting end
station's IP address in the VN to other RBridges. If the ESs in a VN station's IP address in the VN to other RBridges. If the ESs in a VN
are only connected to one edge RBridge, that RBridge only needs to are only connected to one edge RBridge, that RBridge only needs to
advertise the subnet corresponding to the VN to other RBridges. A advertise the subnet corresponding to the VN to other RBridges. A
globally unique tenant ID is also carried in the advertisement to globally unique tenant ID is also carried in the advertisement to
differentiate IP prefixes between different tenants, because the IP differentiate IP prefixes between different tenants, because the IP
address space of different tenants can overlap (see Sections 7.3 and address space of different tenants can overlap (see Sections 7.3 and
7.4). 7.4).
If a tenant is deleted on an edge Rbridge RB1, RB1 notifies all If a tenant is deleted on an edge Rbridge RB1, RB1 SHOULD re-
other edge Rbridges to delete the tenant Label, tenant gateway MAC, advertise the local tenant Label, tenant gateway MAC, and related IP
and related IP prefixes that were local to RB1 by withdrawing its prefixes information of the rest tenants to other edge Rbridges. It
advertisement of that information. If there is a new tenant which is may take some time for the re-advertisement to reach all other
created and the original's tenant label is assigned to the new RBridges, so during this period of time there may be transient
tenant immediately, it may cause a security policy violation for the routes inconsistency among the edge RBridges. If there are traffic
traffic in flight, because when the egress Rbridge receives traffic in flight during this time, it will be dropped at egress RBridge due
from the old tenant, it will forward it in the new tenant's routing to local tenant deletion. In stable state, the traffic to the
instance and deliver it to wrong destination. So tenant Label MUST deleted tenant will be dropped in ingress RBridge. Therefore the
NOT be re-allocated until a reasonable amount of time, for example transient routes consistency won't cause other issues other than
twice the IS-IS Holding Time generally in use in the TRILL campus, some unnecessary network bandwidth wasting.
has passed to allow any traffic in flight to be discarded.
If there is a new tenant which is created and the original's tenant
label is assigned to the new tenant immediately, it may cause a
security policy violation for the traffic in flight, because when
the egress Rbridge receives traffic from the old tenant, it will
forward it in the new tenant's routing instance and deliver it to
wrong destination. So tenant Label MUST NOT be re-allocated until a
reasonable amount of time, for example twice the IS-IS Holding Time
generally in use in the TRILL campus, has passed to allow any
traffic in flight to be discarded.
When the ARP entry in an edge Rbridge for an ES times out, it will When the ARP entry in an edge Rbridge for an ES times out, it will
trigger an edge Rbridge LSP advertisement to other edge Rbridges trigger an edge Rbridge LSP advertisement to other edge Rbridges
with the corresponding IP routing entry deleted. If the ES is an IP with the corresponding IP routing entry deleted. If the ES is an IP
router, the edge Rbridge also notifies other edge Rbridges that they router, the edge Rbridge also notifies other edge Rbridges that they
must delete the routing entries corresponding to the IP prefixes must delete the routing entries corresponding to the IP prefixes
accessible through that IP router. During the IP prefix deleting accessible through that IP router. During the IP prefix deleting
process, if there is traffic in flight, the traffic will be process, if there is traffic in flight, the traffic will be
discarded at the egress Rbridge because there is no local IP routing discarded at the egress Rbridge because there is no local IP routing
entry to the destination. entry to the destination.
skipping to change at page 14, line 28 skipping to change at page 14, line 36
traffic detour through the centralized gateway is avoided. traffic detour through the centralized gateway is avoided.
If ES2 is attached to a remote edge RBridge, the remote edge RBridge If ES2 is attached to a remote edge RBridge, the remote edge RBridge
is IP next hop and the inter-subnet traffic is forwarded to the IP is IP next hop and the inter-subnet traffic is forwarded to the IP
next hop through TRILL encapsulation. If there are multiple equal next hop through TRILL encapsulation. If there are multiple equal
cost shortest paths between ingress RBridge and egress RBridge, all cost shortest paths between ingress RBridge and egress RBridge, all
these paths can be used for inter-subnet traffic forwarding, so load these paths can be used for inter-subnet traffic forwarding, so load
spreading can be achieved for inter-subnet traffic. spreading can be achieved for inter-subnet traffic.
When the remote RBridge receives the inter-subnet TRILL encapsulated When the remote RBridge receives the inter-subnet TRILL encapsulated
traffic, the RBridge decapsulates the TRILL encapsulation and checks traffic, the RBridge decapsulates the TRILL encapsulation and check
the Inner.MacDA, if that MAC address is the local gateway MAC the Inner.MacDA. If that MAC address is the local gateway MAC
corresponding to the inner Label (VLAN or FGL), the inner Label will corresponding to the inner Label (VLAN or FGL), the inner Label will
be used to find the corresponding local VRF, then the IP routing be used to find the corresponding local VRF, then the IP routing
process in that VRF will be performed, and the traffic will be process in that VRF will be performed, and the traffic will be
locally forwarded to the destination ES2. locally forwarded to the destination ES2.
In summary, this solution avoids traffic detours through a central In summary, this solution avoids traffic detours through a central
gateway, both inter-subnet and intra-subnet traffic can be forwarded gateway, both inter-subnet and intra-subnet traffic can be forwarded
along pair-wise shortest paths, and network bandwidth is conserved. along pair-wise shortest paths, and network bandwidth is conserved.
6. Distributed Layer 3 Gateway Process Example 6. Distributed Layer 3 Gateway Process Example
skipping to change at page 16, line 7 skipping to change at page 16, line 18
| RB | Nickname| Tenant | VRF | Tenant Label | Gateway MAC | | RB | Nickname| Tenant | VRF | Tenant Label | Gateway MAC |
+----+---------+----------+-------+--------------+--------------+ +----+---------+----------+-------+--------------+--------------+
| RB1| nick1 | Tenant1 | VRF1 | 100 | MAC1 | | RB1| nick1 | Tenant1 | VRF1 | 100 | MAC1 |
+----+---------+----------+-------+--------------+--------------+ +----+---------+----------+-------+--------------+--------------+
| RB2| nick2 | Tenant1 | VRF2 | 100 | MAC2 | | RB2| nick2 | Tenant1 | VRF2 | 100 | MAC2 |
+----+---------+----------+-------+--------------+--------------+ +----+---------+----------+-------+--------------+--------------+
Figure 5. RBridge information Figure 5. RBridge information
6.1. Control plane process 6.1. Control plane process
RB1 advertises the following local routing information to the TRILL RB1 advertises the following local routing information to the TRILL
campus: campus:
Tenant ID: 1 Tenant ID: 1
Tenant gateway MAC: MAC1 Tenant gateway MAC: MAC1
Tenant Label for Tenant1: VLAN 100. Tenant Label for Tenant1: VLAN 100.
IP prefix in Tenant1: 192.0.2.2/32. IP prefix in Tenant1: 192.0.2.2/32.
RB2 announces the following local routing information to TRILL RB2 announces the following local routing information to TRILL
campus: campus:
Tenant ID: 1 Tenant ID: 1
Tenant gateway MAC: MAC2 Tenant gateway MAC: MAC2
Tenant Label for Tenant1: VLAN 100. Tenant Label for Tenant1: VLAN 100.
IP prefix in Tenant1: 198.51.100.2/32. IP prefix in Tenant1: 198.51.100.2/32.
skipping to change at page 16, line 40 skipping to change at page 17, line 4
on RB1 are generated as follows: on RB1 are generated as follows:
+---------------+-------------+--------------+----------------+ +---------------+-------------+--------------+----------------+
| Prefix/Mask | Inner.MacDA | inner VLAN | egress nickname| | Prefix/Mask | Inner.MacDA | inner VLAN | egress nickname|
+---------------+-------------+--------------+----------------+ +---------------+-------------+--------------+----------------+
|198.51.100.2/32| MAC2 | 100 | nick2 | |198.51.100.2/32| MAC2 | 100 | nick2 |
+---------------+-------------+--------------+----------------+ +---------------+-------------+--------------+----------------+
Figure 6. Tenant 1 remote routing table on RB1 Figure 6. Tenant 1 remote routing table on RB1
Similarly, relying on the routing information from RB1, remote Similarly, relying on the routing information from RB1, remote
routing entries on RB2 are generated as follows: routing entries on RB2 are generated as follows:
+------------+-------------+-----------+---------------+ +------------+-------------+-----------+---------------+
|Prefix/Mask | Inner.MacDA |inner VLAN |egress nickname| |Prefix/Mask | Inner.MacDA |inner VLAN |egress nickname|
+------------+-------------+-----------+---------------+ +------------+-------------+-----------+---------------+
|192.0.2.2/32| MAC1 | 100 | nick1 | |192.0.2.2/32| MAC1 | 100 | nick1 |
+------------+-------------+-----------+---------------+ +------------+-------------+-----------+---------------+
Figure 7. Tenant 1 remote routing table on RB2 Figure 7. Tenant 1 remote routing table on RB2
6.2. Data Plane Process 6.2. Data Plane Process
Assuming ES1 sends unicast inter-subnet traffic to ES2, the traffic Assuming ES1 sends unicast inter-subnet traffic to ES2, the traffic
forwarding process is as follows: forwarding process is as follows:
1. ES1 sends unicast inter-subnet traffic to RB1 with RB1's 1. ES1 sends unicast inter-subnet traffic to RB1 with RB1's
gateway's MAC as the destination MAC and VLAN as VLAN 10.
2. Ingress RBridge (RB1) forwarding process: gateway's MAC as the destination MAC and VLAN as VLAN 10.
RB1 checks the destination MAC, if the destination MAC equals the 2. Ingress RBridge (RB1) forwarding process:
local gateway MAC, the gateway function will terminate the Layer 2
header and perform L3 routing.
RB1 looks up IP routing table information by destination IP and RB1 checks the destination MAC, if the destination MAC equals the
Tenant ID to get IP next hop information, which includes the egress local gateway MAC, the gateway function will terminate the Layer 2
RBridge's gateway MAC (MAC2), tenant Label (VLAN 100) and egress header and perform L3 routing.
nickname (nick2). Using this information, RB1 will perform inner
Ethernet header encapsulation and TRILL encapsulation. RB1 will use
MAC2 as the Inner.MacDA, MAC1 (RB1's own gateway MAC) as the
Inner.MacSA, VLAN 100 as the Inner.VLAN, nick2 as the egress
nickname and nick1 as the ingress nickname.
RB1 looks up TRILL forwarding information by egress nickname and RB1 looks up IP routing table information by destination IP and
sends the traffic to the TRILL next hop as per [RFC6325]. The Tenant ID to get IP next hop information, which includes the egress
traffic will be sent to RB3 or RB4 as a result of load balancing. RBridge's gateway MAC (MAC2), tenant Label (VLAN 100) and egress
nickname (nick2). Using this information, RB1 will perform inner
Ethernet header encapsulation and TRILL encapsulation. RB1 will use
MAC2 as the Inner.MacDA, MAC1 (RB1's own gateway MAC) as the
Inner.MacSA, VLAN 100 as the Inner.VLAN, nick2 as the egress
nickname and nick1 as the ingress nickname.
Assuming the traffic is forwarded to RB3, the following occurs: RB1 looks up TRILL forwarding information by egress nickname and
sends the traffic to the TRILL next hop as per [RFC6325]. The
traffic will be sent to RB3 or RB4 as a result of load balancing.
3. Transit RBridge (RB3) forwarding process: Assuming the traffic is forwarded to RB3, the following occurs:
RB3 looks up TRILL forwarding information by egress nickname and 3. Transit RBridge (RB3) forwarding process:
forwards the traffic to RB2 as per [RFC6325].
4. Egress RBridge forwarding process: RB3 looks up TRILL forwarding information by egress nickname and
forwards the traffic to RB2 as per [RFC6325].
As the egress nickname is RB2's own nickname, RB2 performs TRILL 4. Egress RBridge forwarding process:
decapsulation. Then it checks the Inner.MacDA and, because that MAC
is equal to the local gateway MAC, performs inner Ethernet header As the egress nickname is RB2's own nickname, RB2 performs TRILL
termination. Using the inner VLAN, RB2 finds the local corresponding decapsulation. Then it checks the Inner.MacDA and, because that MAC
VRF and looks up the packets destination IP address in the VRF's IP is equal to the local gateway MAC, performs inner Ethernet header
routing table. The traffic is then be locally forwarded to ES2 with termination. Using the inner VLAN, RB2 finds the local
VLAN 20. corresponding VRF and looks up the packets destination IP address
in the VRF's IP routing table. The traffic is then be locally
forwarded to ES2 with VLAN 20.
7. TRILL Protocol Extensions 7. TRILL Protocol Extensions
If an edge RBridge RB1 participates in the distributed gateway If an edge RBridge RB1 participates in the distributed gateway
function, it announces its tenant gateway MAC and tenant Data Label function, it announces its tenant gateway MAC and tenant Data Label
to the TRILL campus through the tenant Label and gateway MAC APPsub- to the TRILL campus through the tenant Label and gateway MAC APPsub-
TLV, it should announce its local IPv4 and IPv6 prefixs through the TLV, it should announce its local IPv4 and IPv6 prefixs through the
IPv4 Prefix APPsub-TLV and the IPv6 Prefix APPsub-TLV respectively. IPv4 Prefix APPsub-TLV and the IPv6 Prefix APPsub-TLV respectively.
If RB1 has multiple nicknames, it can announce one nickname for If RB1 has multiple nicknames, it can announce one nickname for
distributed gateway use using Nickname Flags APPsub-TLV with "SE" distributed gateway use using Nickname Flags APPsub-TLV with "SE"
skipping to change at page 18, line 33 skipping to change at page 18, line 46
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tenant ID (4 bytes) | | Tenant ID (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv1 | Label1 | (2 bytes) | Resv1 | Label1 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv2 | Label2 | (2 bytes) | Resv2 | Label2 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+....-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+....-+-+-+-+-+-+-+-+-+-+
| Tenant Gateway Mac (6 bytes) | | Tenant Gateway Mac (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+....-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+....-+-+-+-+-+-+-+-+-+-+
o Type: Set to TENANT-LABEL sub-TLV type (TBD1). Two bytes, o Type: Set to TENANT-LABEL sub-TLV type (TBD1). Two bytes, because
because this APPsub-TLV appears in an extended TLV [RFC7356]. this APPsub-TLV appears in an extended TLV [RFC7356].
o Length: If Label1 field is used to represent a VLAN, the o Length: If Label1 field is used to represent a VLAN, the value of
value of the length field is 12. If Label1 and Label2 field are used the length field is 12. If Label1 and Label2 field are used to
to represent an FGL, the value of the length field is 14. represent an FGL, the value of the length field is 14.
o Tenant ID: This identifies a global tenant ID. o Tenant ID: This identifies a global tenant ID.
o Resv1: 4 bits that MUST be sent as zero and ignored on o Resv1: 4 bits that MUST be sent as zero and ignored on receipt.
receipt.
o Label1: If the value of the length field is 12, it o Label1: If the value of the length field is 12, it identifies a
identifies a tenant Label corresponding to a VLAN ID. If the value tenant Label corresponding to a VLAN ID. If the value of the length
of the length field is 14, it identifies the higher 12 bits of a field is 14, it identifies the higher 12 bits of a tenant Label
tenant Label corresponding to a FGL. corresponding to a FGL.
o Resv2: 4 bits that MUST be sent as zero and ignored on o Resv2: 4 bits that MUST be sent as zero and ignored on receipt.
receipt. Only present if the length field is 14. Only present if the length field is 14.
o Label2: This field has the lower 12 bits of tenant Label o Label2: This field has the lower 12 bits of tenant Label
corresponding to a FGL. Only present if the length field is 14. corresponding to a FGL. Only present if the length field is 14.
o Tenant Gateway MAC: This identifies the local gateway MAC o Tenant Gateway MAC: This identifies the local gateway MAC
corresponding to the tenant ID. The remote ingress RBridges uses the corresponding to the tenant ID. The remote ingress RBridges uses
Gateway MAC as Inner.MacDA. The advertising TRILL RBridge uses the the Gateway MAC as Inner.MacDA. The advertising TRILL RBridge uses
gateway MAC to differentiate layer 2 intra-subnet traffic and layer the gateway MAC to differentiate layer 2 intra-subnet traffic and
3 inter-subnet traffic in the egress direction. layer 3 inter-subnet traffic in the egress direction.
7.2. "SE" Flag in NickFlags APPsub-TLV 7.2. "SE" Flag in NickFlags APPsub-TLV
The NickFlags APPsub-TLV is specified in [rfc7180bis] where the IN The NickFlags APPsub-TLV is specified in [rfc7180bis] where the IN
flag is described. The SE Flag is assigned as follows: flag is described. The SE Flag is assigned as follows:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Nickname | | Nickname |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|IN|SE| RESV | |IN|SE| RESV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NICKFLAG RECORD NICKFLAG RECORD
o SE. If the SE flag is one, it indicates that the advertising o SE. If the SE flag is one, it indicates that the advertising
RBridge suggests the nickname SHOULD be used as the Inter-Subnet RBridge suggests the nickname SHOULD be used as the Inter-Subnet
Egress nickname for inter-subnet traffic forwarding. If flag is zero, Egress nickname for inter-subnet traffic forwarding. If flag is
that nickname SHOULD NOT be used for that purpose. zero, that nickname SHOULD NOT be used for that purpose.
7.3. The IPv4 Prefix APPsub-TLV 7.3. The IPv4 Prefix APPsub-TLV
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | (2 bytes) | Type | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Length | (2 bytes) | Total Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| Tenant ID | (4 bytes) | Tenant ID | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
|PrefixLength(1)| (1 byte) |PrefixLength(1)| (1 byte)
skipping to change at page 20, line 7 skipping to change at page 20, line 22
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| ..... | (1 byte) | ..... | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| ..... | (variable) | ..... | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
|PrefixLength(N)| (1 byte) |PrefixLength(N)| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| Prefix (N) | (variable) | Prefix (N) | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
o Type: Set to IPV4-PREFIX sub-TLV type (TBD2). Two bytes, o Type: Set to IPV4-PREFIX sub-TLV type (TBD2). Two bytes, because
because this APPsub-TLV appears in an extended TLV [RFC7356]. this APPsub-TLV appears in an extended TLV [RFC7356].
o Total Length: This 2-byte unsigned integer indicates the o Total Length: This 2-byte unsigned integer indicates the total
total length of the Tenant ID, the Prefix Length, and the Prefix length of the Tenant ID, the Prefix Length, and the Prefix fields
fields in octets. A value of 0 indicates that no IPv4 prefix is being in octets. A value of 0 indicates that no IPv4 prefix is being
advertised. advertised.
o Tenant ID: This identifies a global tenant ID. o Tenant ID: This identifies a global tenant ID.
o Prefix Length: The Prefix Length field indicates the length o Prefix Length: The Prefix Length field indicates the length in bits
in bits of the IPv4 address prefix. A length of zero indicates a of the IPv4 address prefix. A length of zero indicates a prefix
prefix that matches all IPv4 addresses (with prefix, itself, of zero that matches all IPv4 addresses (with prefix, itself, of zero
octets). octets).
o Prefix: The Prefix field contains an IPv4 address prefix, o Prefix: The Prefix field contains an IPv4 address prefix, followed
followed by enough trailing bits to make the end of the field fall on by enough trailing bits to make the end of the field fall on an
an octet boundary. Note that the value of the trailing bits is octet boundary. Note that the value of the trailing bits is
irrelevant. For example, if the Prefix Length is 12, indicating 12 irrelevant. For example, if the Prefix Length is 12, indicating 12
bits, then the Prefix is 2 octets and the low order 4 bits of the bits, then the Prefix is 2 octets and the low order 4 bits of the
Prefix are irrelevant. Prefix are irrelevant.
7.4. The IPv6 Prefix APPsub-TLV 7.4. The IPv6 Prefix APPsub-TLV
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | (2 bytes) | Type | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Length | (2 bytes) | Total Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| Tenant ID | (4 bytes) | Tenant ID | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
|PrefixLength(1)| (1 byte) |PrefixLength(1)| (1 byte)
skipping to change at page 20, line 50 skipping to change at page 21, line 16
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| ..... | (1 byte) | ..... | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| ..... | (variable) | ..... | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
|PrefixLength(N)| (1 byte) |PrefixLength(N)| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| Prefix (N) | (variable) | Prefix (N) | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
o Type: Set to IPV6-PREFIX sub-TLV type (TBD3). Two bytes, o Type: Set to IPV6-PREFIX sub-TLV type (TBD3). Two bytes, because
because this APPsub-TLV appears in an extended TLV [RFC7356]. this APPsub-TLV appears in an extended TLV [RFC7356].
o Total Length: This 2-byte unsigned integer indicates the o Total Length: This 2-byte unsigned integer indicates the total
total length of the Tenant ID, the Prefix Length, and the Prefix length of the Tenant ID, the Prefix Length, and the Prefix fields
fields in octets. A value of 0 indicates that no IPv6 prefix is being in octets. A value of 0 indicates that no IPv6 prefix is being
advertised. advertised.
o Tenant ID: This identifies a global tenant ID. o Tenant ID: This identifies a global tenant ID.
o Prefix Length: The Prefix Length field indicates the length o Prefix Length: The Prefix Length field indicates the length in bits
in bits of the IPv6 address prefix. A length of zero indicates a of the IPv6 address prefix. A length of zero indicates a prefix
prefix that matches all IPv6 addresses (with prefix, itself, of zero that matches all IPv6 addresses (with prefix, itself, of zero
octets). octets).
o Prefix: The Prefix field contains an IPv6 address prefix, o Prefix: The Prefix field contains an IPv6 address prefix, followed
followed by enough trailing bits to make the end of the field fall on by enough trailing bits to make the end of the field fall on an
an octet boundary. Note that the value of the trailing bits is octet boundary. Note that the value of the trailing bits is
irrelevant. For example, if the Prefix Length is 100, indicating 100 irrelevant. For example, if the Prefix Length is 100, indicating
bits, then the Prefix is 13 octets and the low order 4 bits of the 100 bits, then the Prefix is 13 octets and the low order 4 bits of
Prefix are irrelevant. the Prefix are irrelevant.
8. Security Considerations 8. Security Considerations
Correct configuration of the edge RBridges participating is Correct configuration of the edge RBridges participating is
important to assure that data is not delivered to the wrong tenant, important to assure that data is not delivered to the wrong tenant,
which would violate security constrains. IS-IS security [RFC5310] which would violate security constrains. IS-IS security [RFC5310]
can be used to secure the information advertised by the edge can be used to secure the information advertised by the edge
RBridges in LSPs and FS-LSPs. RBridges in LSPs and FS-LSPs.
See Section 5.2 for constraints on re-use of a tenant ID and on See Section 5.2 for constraints on re-use of a tenant ID and on
skipping to change at page 23, line 28 skipping to change at page 23, line 40
February 2009. February 2009.
[RFC7379] - Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, [RFC7379] - Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai,
"Problem Statement and Goals for Active-Active Connection at the "Problem Statement and Goals for Active-Active Connection at the
Transparent Interconnection of Lots of Links (TRILL) Edge", RFC 7379, Transparent Interconnection of Lots of Links (TRILL) Edge", RFC 7379,
October 2014, <http://www.rfc-editor.org/info/rfc7379>. October 2014, <http://www.rfc-editor.org/info/rfc7379>.
Acknowledgments Acknowledgments
The authors wish to acknowledge the important contributions of The authors wish to acknowledge the important contributions of
Donald Eastlake, Gayle Noble, Muhammed Umair, Guangrui Wu, Zhenbin Li, Donald Eastlake, Gayle Noble, Muhammed Umair, Susan Hares, Guangrui Wu,
Zhibo Hu. Zhenbin Li, Zhibo Hu.
Authors' Addresses Authors' Addresses
Weiguo Hao Weiguo Hao
Huawei Technologies Huawei Technologies
101 Software Avenue, 101 Software Avenue,
Nanjing 210012, China Nanjing 210012, China
Phone: +86-25-56623144 Phone: +86-25-56623144
Email: haoweiguo@huawei.com Email: haoweiguo@huawei.com
Yizhou Li Yizhou Li
Huawei Technologies Huawei Technologies
101 Software Avenue, 101 Software Avenue,
Nanjing 210012, China Nanjing 210012, China
Phone: +86-25-56625375 Phone: +86-25-56625375
Email: liyizhou@huawei.com Email: liyizhou@huawei.com
 End of changes. 51 change blocks. 
137 lines changed or deleted 150 lines changed or added

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