< draft-ietf-trill-rbridge-multilevel-05.txt   draft-ietf-trill-rbridge-multilevel-06.txt >
TRILL Working Group Radia Perlman TRILL Working Group Radia Perlman
INTERNET-DRAFT EMC INTERNET-DRAFT EMC
Intended status: Informational Donald Eastlake Intended status: Informational Donald Eastlake
Mingui Zhang Mingui Zhang
Huawei Huawei
Anoop Ghanwani Anoop Ghanwani
Dell Dell
Hongjun Zhai Hongjun Zhai
JIT JIT
Expires: October 26, 2017 April 27, 2017 Expires: December 15, 2017 June 16, 2017
Alternatives for Multilevel TRILL Alternatives for Multilevel TRILL
(Transparent Interconnection of Lots of Links) (Transparent Interconnection of Lots of Links)
<draft-ietf-trill-rbridge-multilevel-05.txt> <draft-ietf-trill-rbridge-multilevel-06.txt>
Abstract Abstract
Although TRILL is based on IS-IS, which supports multilevel unicast Although TRILL is based on IS-IS, which supports multilevel unicast
routing, extending TRILL to multiple levels has challenges that are routing, extending TRILL to multiple levels has challenges that are
not addressed by the already-existing capabilities of IS-IS. One not addressed by the already-existing capabilities of IS-IS. One
issue is with the handling of multi-destination packet distribution issue is with the handling of multi-destination packet distribution
trees. Other issues are with TRILL switch nicknames. How are such trees. Other issues are with TRILL switch nicknames. How are such
nicknames allocated across a multilevel TRILL network? Do nicknames nicknames allocated across a multilevel TRILL network? Do nicknames
need to be unique across an entire multilevel TRILL network or can need to be unique across an entire multilevel TRILL network or can
skipping to change at page 3, line 45 skipping to change at page 3, line 45
3. Area Partition.........................................20 3. Area Partition.........................................20
4. Multi-Destination Scope................................21 4. Multi-Destination Scope................................21
4.1 Unicast to Multi-destination Conversions..............21 4.1 Unicast to Multi-destination Conversions..............21
4.1.1 New Tree Encoding...................................22 4.1.1 New Tree Encoding...................................22
4.2 Selective Broadcast Domain Reduction..................22 4.2 Selective Broadcast Domain Reduction..................22
5. Co-Existence with Old TRILL switches...................24 5. Co-Existence with Old TRILL switches...................24
6. Multi-Access Links with End Stations...................25 6. Multi-Access Links with End Stations...................25
7. Summary................................................27 7. Summary................................................27
8. Security Considerations................................28 8. Security Considerations................................28
9. IANA Considerations....................................28 9. IANA Considerations....................................28
Normative References......................................29 Normative References......................................29
Informative References....................................29 Informative References....................................29
Acknowledgements..........................................31
Authors' Addresses........................................32
INTERNET-DRAFT Multilevel TRILL INTERNET-DRAFT Multilevel TRILL
1. Introduction 1. Introduction
The IETF TRILL (Transparent Interconnection of Lot of Links) protocol The IETF TRILL (Transparent Interconnection of Lot of Links) protocol
[RFC6325] [RFC7177] [RFC7780] provides optimal pair-wise data routing [RFC6325] [RFC7177] [RFC7780] provides optimal pair-wise data routing
without configuration, safe forwarding even during periods of without configuration, safe forwarding even during periods of
temporary loops, and support for multipathing of both unicast and temporary loops, and support for multipathing of both unicast and
multicast traffic in networks with arbitrary topology and link multicast traffic in networks with arbitrary topology and link
technology, including multi-access links. TRILL accomplishes this by technology, including multi-access links. TRILL accomplishes this by
skipping to change at page 12, line 37 skipping to change at page 12, line 37
the TRILL switches inside the area from choosing nicknames outside the TRILL switches inside the area from choosing nicknames outside
the area's nickname block), or a new TLV would be needed to announce the area's nickname block), or a new TLV would be needed to announce
the allowable or the prohibited nicknames, and all TRILL switches in the allowable or the prohibited nicknames, and all TRILL switches in
the area would need to understand that new TLV. the area would need to understand that new TLV.
Currently the encoding of nickname information in TLVs is by listing Currently the encoding of nickname information in TLVs is by listing
of individual nicknames; this would make it painful for a border of individual nicknames; this would make it painful for a border
TRILL switch to announce into an area that it is holding all other TRILL switch to announce into an area that it is holding all other
nicknames to limit the nicknames available within that area. Painful nicknames to limit the nicknames available within that area. Painful
means tens of thousands of individual nickname entries in the Level 1 means tens of thousands of individual nickname entries in the Level 1
LSDB. The information could be encoded as ranges of nicknames to LSDB. The information could be encoded as ranges of nicknames to make
make this manageable by specifying a new TLV similar to the Nickname this manageable by specifying a new TLV similar to the Nickname Flags
Flags APPsubTLV specified in [RFC7780] but providing flags for blocks APPsubTLV specified in [RFC7780] but providing flags for blocks of
of nicknames rather than single nicknames. Although this would nicknames rather than single nicknames. Although this would require
require updating software, such a new TLV is the preferred method. updating software, such a new TLV is the preferred method.
There is also an issue with the unique nicknames approach in building There is also an issue with the unique nicknames approach in building
distribution trees, as follows: distribution trees, as follows:
With unique nicknames in the TRILL campus and TRILL header With unique nicknames in the TRILL campus and TRILL header
nicknames not rewritten by the border TRILL switches, there would nicknames not rewritten by the border TRILL switches, there would
have to be globally known nicknames for the trees. Suppose there have to be globally known nicknames for the trees. Suppose there
are k trees. For all of the trees with nicknames located outside are k trees. For all of the trees with nicknames located outside
an area, the local trees would be rooted at a border TRILL switch an area, the local trees would be rooted at a border TRILL switch
or switches. Therefore, there would be either no splitting of or switches. Therefore, there would be either no splitting of
skipping to change at page 25, line 21 skipping to change at page 25, line 21
that end stations are TRILL ignorant. In particular, it is essential that end stations are TRILL ignorant. In particular, it is essential
that only one TRILL switch ingress/egress any given data packet that only one TRILL switch ingress/egress any given data packet
from/to an end station so that connectivity is provided to that end from/to an end station so that connectivity is provided to that end
station without duplicating end station data and that loops are not station without duplicating end station data and that loops are not
formed due to one TRILL switch egressing data in native form (i.e., formed due to one TRILL switch egressing data in native form (i.e.,
with no TRILL header) and having that data re-ingressed by another with no TRILL header) and having that data re-ingressed by another
TRILL switch on the link. TRILL switch on the link.
With existing, single level TRILL, this is done by electing a single With existing, single level TRILL, this is done by electing a single
Designated RBridge per link, which appoints a single Appointed Designated RBridge per link, which appoints a single Appointed
Forwarder per VLAN [RFC7177] [rfc6439bis]. This mechanism depends on Forwarder per VLAN [RFC7177] [RFC8139]. This mechanism depends on the
the RBridges establishing adjacency. But suppose there are two (or RBridges establishing adjacency. But suppose there are two (or more)
more) TRILL switches on a link in different areas, say RB1 in area A1 TRILL switches on a link in different areas, say RB1 in area A1 and
and RB2 in area A2, as shown below, and that the link also has one or RB2 in area A2, as shown below, and that the link also has one or
more end stations attached. If RB1 and RB2 ignore each other's more end stations attached. If RB1 and RB2 ignore each other's
Hellos because they are in different areas, as they are required to Hellos because they are in different areas, as they are required to
do under normal IS-IS PDU processing rules, then they will not form do under normal IS-IS PDU processing rules, then they will not form
an adjacency. If they are not adjacent, they will ignore each other an adjacency. If they are not adjacent, they will ignore each other
for the Appointed Forwarder mechanism and will both ingress/egress for the Appointed Forwarder mechanism and will both ingress/egress
end station traffic on the link causing loops and duplication. end station traffic on the link causing loops and duplication.
The problem is not avoiding adjacency of avoiding TRILL Data packet The problem is not avoiding adjacency or avoiding TRILL Data packet
transfer between RB1 and RB2. The area address mechanism of IS-IS or transfer between RB1 and RB2. The area address mechanism of IS-IS or
possibly the use of topology constraints or the like does that quite possibly the use of topology constraints or the like does that quite
well. The problem stems from end stations being TRILL ignorant so well. The problem stems from end stations being TRILL ignorant so
care must be taken that multiple RBridges on a link do not ingress care must be taken that multiple RBridges on a link do not ingress
the same frame originated by an end station and so that an RBridge the same frame originated by an end station and so that an RBridge
does not ingress a native frame egressed by a different RBridge does not ingress a native frame egressed by a different RBridge
because it mistakes if for a frame originated by an end station. because the RBridge mistakes the frame for a frame originated by an
end station.
+--------------------------------------------+ +--------------------------------------------+
| Level 2 | | Level 2 |
+----------+---------------------+-----------+ +----------+---------------------+-----------+
| Area A1 | | Area A2 | | Area A1 | | Area A2 |
| +---+ | | +---+ | | +---+ | | +---+ |
| |RB1| | | |RB2| | | |RB1| | | |RB2| |
| +-+-+ | | +-+-+ | | +-+-+ | | +-+-+ |
| | | | | | | | | | | |
+-----|----+ +-----|-----+ +-----|----+ +-----|-----+
skipping to change at page 26, line 24 skipping to change at page 26, line 24
Other methods are possible. For example doing the selection of Other methods are possible. For example doing the selection of
Appointed Forwarders and of the TRILL switch in charge of that Appointed Forwarders and of the TRILL switch in charge of that
selection across all TRILL switches on the link regardless of area. selection across all TRILL switches on the link regardless of area.
However, a special case would then have to be made for legacy TRILL However, a special case would then have to be made for legacy TRILL
switches using area number zero. switches using area number zero.
These techniques require multilevel aware TRILL switches to take These techniques require multilevel aware TRILL switches to take
actions based on Hellos from RBridges in other areas even though they actions based on Hellos from RBridges in other areas even though they
will not form an adjacency with such RBridges. However, the action is will not form an adjacency with such RBridges. However, the action is
quite simple in the preferred case: if a TRILL switch seems Hellos quite simple in the preferred case: if a TRILL switch sees Hellos
from lower numbered areas, then they would not act as an Appointed from lower numbered areas, then they would not act as an Appointed
Forwarder on the link until the Hello timer for such Hellos had Forwarder on the link until the Hello timer for such Hellos had
expired. expired.
INTERNET-DRAFT Multilevel TRILL INTERNET-DRAFT Multilevel TRILL
7. Summary 7. Summary
This draft describes potential scaling issues in TRILL and discusses This draft describes potential scaling issues in TRILL and discusses
possible approaches to multilevel TRILL as a solution or element of a possible approaches to multilevel TRILL as a solution or element of a
skipping to change at page 29, line 29 skipping to change at page 29, line 29
and V. Manral, "Transparent Interconnection of Lots of Links and V. Manral, "Transparent Interconnection of Lots of Links
(TRILL): Adjacency", RFC 7177, May 2014, <http://www.rfc- (TRILL): Adjacency", RFC 7177, May 2014, <http://www.rfc-
editor.org/info/rfc7177>. editor.org/info/rfc7177>.
[RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
Ghanwani, A., and S. Gupta, "Transparent Interconnection of Ghanwani, A., and S. Gupta, "Transparent Interconnection of
Lots of Links (TRILL): Clarifications, Corrections, and Lots of Links (TRILL): Clarifications, Corrections, and
Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
<http://www.rfc-editor.org/info/rfc7780>. <http://www.rfc-editor.org/info/rfc7780>.
[rfc6439bis] - Eastlake, D., Li, Y., Umair, M., Banerjee, A., and F. [RFC8139] - Eastlake, D., Li, Y., Umair, M., Banerjee, A., and F. Hu,
Hu, "Routing Bridges (RBridges): Appointed Forwarders", draft- "Transparent Interconnection of Lots of Links (TRILL):
ietf-trill-rfc6439bis, work in progress, February 2017. Appointed Forwarders", RFC 8139, DOI 10.17487/RFC8139, June
2017, <http://www.rfc-editor.org/info/rfc8139>.
Informative References Informative References
[RFC3194] - Durand, A. and C. Huitema, "The H-Density Ratio for [RFC3194] - Durand, A. and C. Huitema, "The H-Density Ratio for
Address Assignment Efficiency An Update on the H ratio", RFC Address Assignment Efficiency An Update on the H ratio", RFC
3194, DOI 10.17487/RFC3194, November 2001, <http://www.rfc- 3194, DOI 10.17487/RFC3194, November 2001, <http://www.rfc-
editor.org/info/rfc3194>. editor.org/info/rfc3194>.
[RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent
Interconnection of Lots of Links (TRILL) Protocol Control Interconnection of Lots of Links (TRILL) Protocol Control
skipping to change at page 29, line 53 skipping to change at page 30, line 4
[RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R.,
and D. Dutt, "Transparent Interconnection of Lots of Links and D. Dutt, "Transparent Interconnection of Lots of Links
(TRILL): Fine-Grained Labeling", RFC 7172, May 2014 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014
[RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt,
D., and A. Banerjee, "Transparent Interconnection of Lots of D., and A. Banerjee, "Transparent Interconnection of Lots of
Links (TRILL) Use of IS-IS", RFC 7176, May 2014. Links (TRILL) Use of IS-IS", RFC 7176, May 2014.
[RFC7357] - Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. [RFC7357] - Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O.
Stokes, "Transparent Interconnection of Lots of Links (TRILL):
INTERNET-DRAFT Multilevel TRILL INTERNET-DRAFT Multilevel TRILL
Stokes, "Transparent Interconnection of Lots of Links (TRILL):
End Station Address Distribution Information (ESADI) Protocol", End Station Address Distribution Information (ESADI) Protocol",
RFC 7357, September 2014, <http://www.rfc- RFC 7357, September 2014, <http://www.rfc-
editor.org/info/rfc7357>. editor.org/info/rfc7357>.
[RFC7781] - Zhai, H., Senevirathne, T., Perlman, R., Zhang, M., and [RFC7781] - Zhai, H., Senevirathne, T., Perlman, R., Zhang, M., and
Y. Li, "Transparent Interconnection of Lots of Links (TRILL): Y. Li, "Transparent Interconnection of Lots of Links (TRILL):
Pseudo-Nickname for Active-Active Access", RFC 7781, DOI Pseudo-Nickname for Active-Active Access", RFC 7781, DOI
10.17487/RFC7781, February 2016, <http://www.rfc- 10.17487/RFC7781, February 2016, <http://www.rfc-
editor.org/info/rfc7781>. editor.org/info/rfc7781>.
 End of changes. 12 change blocks. 
18 lines changed or deleted 24 lines changed or added

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