One document matched: draft-manral-isis-trill-multi-topo-01.txt
Differences from draft-manral-isis-trill-multi-topo-00.txt
TRILL Working Group V. Manral, Ed.
INTERNET-DRAFT Hewlett-Packard Co.
Intended status: Proposed Standard D. Eastlake
Expires: November 18, 2011 Huawei
A. Banerjee
Cisco Systems
May 19, 2011
Multi Topology Routing Extensions for Transparent Interconnection of
Lots of Links (TRILL)
draft-manral-isis-trill-multi-topo-01
Abstract
This document describes an optional extensions to the TRILL protocol.
The extensions uses Intermediate System to Intermediate Systems (IS-
IS) as the control plane, to support multiple topologies (MT) within
the same TRILL protocol instance of IS-IS. It describes how to run
Multiple Independent TRILL topologies, within a single IS-IS domain.
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. Distribution of this document is
unlimited. Comments should be sent to the TRILL working group
mailing list <rbridge@postel.org>.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
V. Manral, et al [Page 1]
INTERNET-DRAFT TRILL Multi Topology Extensions
Table of Contents
1. Introduction............................................3
2. Terminology.............................................3
3. TLV enhancement for Multitopology.......................3
4. Multi-Topology changes to Routing.......................4
5. Multi-Topology changes to Appointer Forwarders.........4
6. Security Considerations.................................5
7. IANA Considerations.....................................5
8. Acknowledgements........................................5
9. References..............................................6
9.1 Normative References...................................6
9.2 Informative References.................................6
Authors' Addresses.........................................7
V. Manral, et al [Page 2]
INTERNET-DRAFT TRILL Multi Topology Extensions
1. Introduction
Maintaining Multiple topologies in an Rbridge campus requires
extensions to the base TRILL protocol and its use of IS-IS. These
extensions change the packet encoding on the wire as well as the SPF
calculation. This document describes all such extensions so that
multiple topologies can be supported as described in [RFC5120].
2. Terminology
IS-IS: Intermediate-System to Intermediate-System
LSP: Link State Protocol Data Unit (PDU)
Rbridge: Routing Bridge
SPF: Shortest Path First Algorithm
TRILL: Transparent Interconnection with Lots of Links
TLV: Type, Length and Value
3. TLV enhancement for Multitopology
Currently the Router Capability TLV is specified in [RFC4971]. For
TRILL most sub-TLV's are carried in the Router Capability TLV. The
Router Capability TLV carries information only for a single Topology.
The following are the extensions required to TRILL use of IS-IS to
support multi-topology use:
1. The Trees sub-TLV, the Tree Identifiers sub-TLV and the VLAN Group
sub-TLV, MAY be encapsulated in the MT-CAP TLV [ISISieee].
2. The Multi-Topology TLV [RFC5120] MAY be advertized in the TRILL
LAN Hellos. It will contain one or more MT's the Rbridge is
participating in.
3. The MTU sub-TLV [ISIStrill] MAY occur in the MT ISN TLV #222
[RFC5120] as well as in the Extended IS Reachability TLV #22.
V. Manral, et al [Page 3]
INTERNET-DRAFT TRILL Multi Topology Extensions
4. Multi-Topology changes to Routing
For unicast, the Multi-Topology SPF routing calculations will be done
spearately for each topology. The ingress RBridge and each transit
RBridge forwarding a unicast frame addressed to a know destination
will forward the frame in a particular topology. The method by which
such known unicast frames are classified as belonging to a particular
topology is beyond the scope of this document.
Multi-destination frames (broadcast, multicast, and unicast to an
unkown destination) are sent over a distribution tree but each
distribution tree is calculated for a single topology. Thus, the
ingress RBridge for a multi-destination frame is the only RBridge
that must classify that frame as being in a particular topology as
part of the process of deciding which tree to distribute it over.
The method by which the ingress RBridge makes this determination is
beyond the scope of this document.
Should the information being advertised in the link state by the
RBridge with the highest priority to be a tree root appear to specify
that the same tree (i.e., same nickname) be calculated in more than
one topology, that tree is only calculated in the lowest numbered of
those topologies. If it is desired to have two distribution trees
rooted at the same RBridge in different topologies, then that RBridge
must be allocated at least two nicknames (a capability already preent
in TRILL) so that different nicnames can be used for the different
topology trees.
The sub-TLV's, if any, present in the Router Capability TLV will be
used for MT#0 calculations, only if the information is not there for
MT#0 in the MT-CAP-TLV.
5. Multi-Topology changes to Appointer Forwarders
The TRILL ISIS election protocol is a bit different from Layer-3 IS-
IS. The DRB is responsible for specifing the designated VLAN for
communication between the Rbridges on the Link [RFCtrill] [RFCadj].
The DRB algorithm is changed such that there is an appointed VLAN
forwarder for each of the topologies for each VLAN. The appointed
forwarder sub-TLV is already a part of the MT-PORT-CAP TLV, which is
Multi-Topology Aware.
V. Manral, et al [Page 4]
INTERNET-DRAFT TRILL Multi Topology Extensions
6. Security Considerations
The extensions to TRILL use of IS-IS specified herein add no new
Security Considerations beyond those already present with multi-
topology IS-IS and TRILL. See [RFC5120] for IS-IS multi-topology
security considerations. See [RFCtrill] for TRILL base protocol
security considerations.
7. IANA Considerations
IANA is requested to update the subregistry of the IS-IS TLV Code
points Registry which shows permitted occurrence of sub-TLVs within
TLVs #22, #141, and #222 to show that the MTU sub-TLV is permitted in
TLV #222 as well as in TLV #22.
IANA is requested to assign sub-TLV numbers within the MT-CAP TLV
[ISISieee] for the Trees sub-TLV, the Tree Identifiers sub-TLV, and
the VLAN Group sub-TLV [ISIStrill]. Noting that there is no conflict
between the numbers of these sub-TLVs within the Router Capabilities
TLV #242 and with any other number so far assigned within the MT-CAP
TLV, it is requested that these sub-TLVs be assigned the same number
within the MT-CAP TLV as they have within the Router Capabilities TLV
#242.
It is further suggested that the sub-registries for Router
Capabilities TLV #242 and the MT-CAP TLV [ISIStrill] might be
combined in the style of the existing IANA sub-registry for sub-TLVs
of TLVs #22, #141, and #222. While there would be some duplication
of sub-TLV numbers in such a combined registry, there would be no
duplication within a particular TLV because, where there are two sub-
TLVs with the same number, one is limited to the Router Capability
TLV and the other is limited to the MT-CAP TLV.
IANA is requested to allocate a value in the IS-IS Multi-Topology ID
Values registry as follows:
TBD TRILL multicast routing topology
8. Acknowledgements
The authors would like to thank Meenakshi Kaushik and Dinesh Dutta.
V. Manral, et al [Page 5]
INTERNET-DRAFT TRILL Multi Topology Extensions
9. References
Normative and informative references are given below.
9.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate
System to Intermediate System (IS-IS) Extensions for
Advertising Router Information", RFC 4971, July 2007.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
[RFCtrill] R. Perlman, D. Eastlake, D. Dutt, S. Gai, and A.
Ghanwani, "RBridges: Base Protocol Specification", draft-
ietf-trill-rbridge-protocol-16.txt, in RFC Editor queue.
[ISIStrill] D. Eastlake, A. Banerjee, D. Dutt, R. Perlman, A.
Ghanwani, "TRILL Use of IS-IS", draft-ietf-isis-
trill-05.txt, work in progress.
[RFCadj] D. Eastlake, R. Perlman, A. Ghanwani, D. Dutt, V. Manral,
"RBridges: Adjacency", draft-ietf-trill-adj, work in
progress.
[ISISieee] D. Fedyk, P. Ashwood-Smith, "IS-IS Extensions Supporting
IEEE 802.1aq Shortest Path Bridging", draft-ietf-isis-
ieee-aq-05.txt, in RFC Editor queue.
9.2 Informative References
None.
V. Manral, et al [Page 6]
INTERNET-DRAFT TRILL Multi Topology Extensions
Authors' Addresses
Vishwas Manral (editor)
Hewlett-Packard Co.
19111 Pruneridge Ave.
Cupertino, CA 95014
USA
Phone: 408-447-0000
Email: vishwas.manral@hp.com
Donald Eastlake
Huawei Technologies
155 Beaver Street
Milford, MA 01757
USA
Phone: 508-333-2270
Email: d3e3e3@gmail.com
Ayan Banerjee
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
USA
Email: ayabaner@cisco.com
V. Manral, et al [Page 7]
INTERNET-DRAFT TRILL Multi Topology Extensions
Copyright and IPR Provisions
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. The definitive version of
an IETF Document is that published by, or under the auspices of, the
IETF. Versions of IETF Documents that are published by third parties,
including those that are translated into other languages, should not
be considered to be definitive versions of IETF Documents. The
definitive version of these Legal Provisions is that published by, or
under the auspices of, the IETF. Versions of these Legal Provisions
that are published by third parties, including those that are
translated into other languages, should not be considered to be
definitive versions of these Legal Provisions. For the avoidance of
doubt, each Contributor to the IETF Standards Process licenses each
Contribution that he or she makes as part of the IETF Standards
Process to the IETF Trust pursuant to the provisions of RFC 5378. No
language to the contrary, or terms, conditions or rights that differ
from or are inconsistent with the rights and licenses granted under
RFC 5378, shall have any effect and shall be null and void, whether
published or posted by such Contributor, or included with or in such
Contribution.
V. Manral, et al [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 01:45:24 |