Internet DRAFT - draft-eastlake-trill-nick-label-prop
draft-eastlake-trill-nick-label-prop
Network Working Group Donald Eastlake
INTERNET-DRAFT Weiguo Hao
Intended status: Proposed Standard Huawei
Expires: April 11, 2014 October 12, 2013
TRILL: Nickname and Label Properties
<draft-eastlake-trill-nick-label-prop-02.txt>
Abstract
There are a number of current and prospective requirements to
indicate properties of nicknames, labels, and blocks thereof, for use
with the TRILL (Transparent Interconnection of Lots of Links, RFC
6325) protocol. To meet that need, this document specifies IS-IS
(Intermediate System to Intermediate System) sub-TLVs and some of
their uses.
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.
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.
Donald Eastlake and Weiguo Hao [Page 1]
INTERNET-DRAFT Nick/Label Properties
Table of Contents
1. Introduction............................................3
1.1 Conventions Used in This Document......................3
2. The Nickname Properties Sub-TLV.........................4
3. The Label Properties Sub-TLV............................7
4. IANA Considerations.....................................9
5. Security Considerations.................................9
6. Normative References...................................10
7. Informative References.................................10
Acknowledgements..........................................11
Authors' Addresses........................................12
Donald Eastlake and Weiguo Hao [Page 2]
INTERNET-DRAFT Nick/Label Properties
1. Introduction
There are a number of current and prospective requirements to
indicate properties of Nicknames, data Labels, and blocks thereof,
for use with the TRILL (Transparent Interconnection of Lots of Links
[RFC6325]) protocol. To meet that need, this document specifies two
IS-IS (Intermediate System to Intermediate System [ISO-10589]
[RFC1195]) sub-TLVs and some of their uses.
These sub-TLVs are used to flag properties of Nicknames and data
Labels. Provision is made for flags associated with
o individual Nicknames,
o blocks of Nicknames,
o individual Labels, and
o blocks of Labels.
In addition, different sizes of Nicknames and data Labels can be
accommodated.
The sub-TLVs specified in this document are used as follows:
o They appear only in the IS-IS Router Capability and MT-Capability
TLVs, which are TLVs number 242 and 144 and are specified in
[RFC4971] and [RFC6329] respectively.
o They can appear multiple times in the same or different Capability
or MT-Capability TLVs.
1.1 Conventions Used in This Document
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].
Donald Eastlake and Weiguo Hao [Page 3]
INTERNET-DRAFT Nick/Label Properties
2. The Nickname Properties Sub-TLV
The structure of the Nickname properties (NICK-PROP) sub-TLV is as
shown below.
+-+-+-+-+-+-+-+-+
| Type = TBD | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+...
| NICK-PROP RECORD 1 (variable)
+-+-+-+-+-+-+-+-+-+-+-+...
| NICK-PROP RECORD 2 (variable)
+-+-+-+-+-+-+-+-+-+-+-+...
| ...
+-+-+-+-+-+-+-+-+-+-+-+...
| NICK-PROP RECORD K
+-+-+-+-+-+-+-+-+-+-+-+...
Figure 1. The Nickname Properties Sub-TLV
o Type: NICK-PROP Sub-TLV type, set to TBD.
o Length: Variable.
o NICK-PROP RECORD: Variable length record as described below.
Each NICK-PROP RECORD is structured as follows.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|NB| NKSZ |IN|OK| RESV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Nickname Information (variable)
+-+-+-+-+-+-+-+-+-+-+-+...
NB: If the NB (Nickname Block) flag is zero, the Nickname Information
is a single Nickname. If the NB flag is one, the Nickname
Information consists of an initial and final Nickname that are
treated as unsigned integers and specify a block of Nicknames
inclusively.
NKSZ: The NKSZ field specifies the size of each of the one or two
Nickname values (see NB bit) that occur in the Nickname
Information
The assigned value of NKSZ is as follows:
Donald Eastlake and Weiguo Hao [Page 4]
INTERNET-DRAFT Nick/Label Properties
NKSZ
----
0 16-bit Nicknames
1-7 Available for assignment
IN: The IN flag is ignored unless the NB flag is zero and the
Nickname Information is a Nickname owned by the RBridge
advertising the enclosing NICK-PROP sub-TLV. When it is not being
ignored and is equal to one, the IN flag indicates that the
Nickname may be used by the advertising RBridge as the ingress
Nickname for TRILL Data frames it creates.
TRILL switches may have multiple Nicknames [RFC6325] but there is
no reason within the TRILL protocol for a TRILL switch to use
more than one Nickname as the ingress Nickname for TRILL Data
frames it creates. If a TRILL switch is not using all the
Nicknames it holds as ingress Nicknames, it SHOULD use the NICK-
PROP sub-TLV to indicate the Nickname (or Nicknames) it is using
as ingress. This reduces the amount of Reverse Path Forwarding
Check (RPFC) state in the campus. The amount of such state at
each TRILL switch port is roughly proportional to the product the
number of ingress Nicknames in use and the number of multi-
destination distribution trees in use. If a TRILL switch does not
avertise any ingress Nickname or Nicknames using the IN flag, it
may use any Nickname it hold as an ingress Nickname.
OK: The OK flag is only effective if the NB flag is one and the NICK-
PROP sub-TLV is advertised by the TRILL switch that is highest
priority to be a tree root. TRILL switches that understand the OK
flag and see one or more OK flags that are effective and are set
to one dynamically select their Nickname as specified in
[RFC6325] and [clearcorrect] except that they do so only from the
block or blocks of nicknames advertised by NICK-PROP sub-TLV
NICK-PROP RECORDS with an effective OK flag set to one. Such
blocks are called the OK Nicknames blocks and a Nickname that is
included in them is called an OK Nickname. If any Nickname value
in the range from 0xFFC0 through 0xFFFF or equal to 0x0000 is
advertised as part of an OK Nickname block they are ignored. For
example, if 0xE000 through 0xFFFF was advertised as an OK
Nickname block, it would be treated as if 0xE000 through 0xFFBF
was advertised.
If the OK Nickname blocks change such that any TRILL switch is
holding a Nickname that is no longer OK, that TRILL switch MUST
allocate a new OK Nickname. To maximize network stability, all
TRILL switches that might become highest priority tree root
SHOULD advertise the same OK Nickname blocks.
Intended uses of this flag are to restrict Nicknames within part
of a network so as to support some methods to implement
Donald Eastlake and Weiguo Hao [Page 5]
INTERNET-DRAFT Nick/Label Properties
[multilevel] or [multidatacenter] TRILL.
RESV: The remaining 10 bits are reserved and MUST be set to zero and
ignored on receipt.
Nickname Information: If NB is zero, this information consists of
a single Nickname. If NB is one, this information consists of an
initial and final Nickname and represents a block of Nicknames.
The Nicknames are treated as unsigned integers in network byte
order. If the final Nickname of a block is less than the initial
Nickname, the NICK-PROP RECORD is ignored. If the initial and
final Nicknames are equal, then a block of size one is indicated.
Otherwise a block of Nickname values with a size greater than one
is indicated, starting with initial Nickname through and
including the final Nickname. If the size of each Nickname value
is not a multiple of 8 bits, the Nickname values are padded with
initial reserved bits up to the next multiple of 8. These
reserved bits MUST be sent as zero and ignored on receipt.
Each NICK-PROP RECORD must fit within the Length of the NICK-PROP
sub-TLV. If there is a truncated NICK-PROP RECORD at the end of hte
sub-TLV, that RECORD is ignored.
For IANA Considerations in assigning values of NKSZ and bits in the
RESV field, see Section 4.
Donald Eastlake and Weiguo Hao [Page 6]
INTERNET-DRAFT Nick/Label Properties
3. The Label Properties Sub-TLV
The structure of the Label properties (LABEL-PROP) sub-TLV is as
shown below.
+-+-+-+-+-+-+-+-+
| Type = TBD | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+...
| LABEL-PROP RECORD 1 (variable)
+-+-+-+-+-+-+-+-+-+-+-+...
| LABEL-PROP RECORD 2 (variable)
+-+-+-+-+-+-+-+-+-+-+-+...
| ...
+-+-+-+-+-+-+-+-+-+-+-+...
| LABEL-PROP RECORD K
+-+-+-+-+-+-+-+-+-+-+-+...
Figure 2. The Label Properties Sub-TLV
o Type: LABEL-PROP Sub-TLV type, set to TBD.
o Length: Variable.
o LABEL-PROP RECORD: Variable length record as described below.
Each LABEL-PROP RECORD is structured as follows.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|LB| LBSZ | SCP |MG| RESV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Label Information (variable)
+-+-+-+-+-+-+-+-+-+-+-+...
LB: If the LB (Label Block) flag is zero, the Label Information is a
single Label. If the LB flag is one, the Label Information
consists of an initial and final Label that are treated as
unsigned integers and specify a block of Labels inclusively.
LBSZ: The LBSZ field specifies the size and type of each of the one
or two Label values (see LB bit) that occur in the Nickname
Information
The assigned values of LBSZ are as follows:
Donald Eastlake and Weiguo Hao [Page 7]
INTERNET-DRAFT Nick/Label Properties
LBSZ
----
0 12-bit VLAN ID
1 24-bit FGL Label [FGL]
2-7
SCP: The SCP or Scope field only has an effect if it is non-zero and
the LABEL-PROP sub-TLV is advertised by the TRILL switch that is
highest priority to be a tree root. If indicates the scope of
propagation of TRILL Data frames having the data label or any of
the data labels in the block indicated by the PROPERTY RECORD.
The following values for SCP are currently specified:
SCP Meaning
--- -------
0 No scope specified
1 Available for assignment
2 Throughout a campus
3 Local, within part of a campus [TreeDistr]
MG: The MG bit is used to indicate the management Label. It is only
effective if the LB flag is zero and the LABEL-PROP sub-TLV is
advertised by the TRILL switch that is highest priority to be a
tree root. All TRILL switches that understand this bit MUST
indicate interest in the listed Label unless this bit is set for
more than one Label, in which case only the lowest valued such
Label will be considered the management Label. The failure of a
TRILL switch to indicate interest in this label will be ignored
and tree distribution of TRILL data frames with this label will
not be pruned.
RESV: The remaining 9 bits are reserved. See Section 4 for IANA
Considerations.
Label Information: If LB is zero, this information consists of a
single Label. If LB is one, this information consists of an
initial and final Label and represents a block of Labels. The
Labels are treated as unsigned integers in network byte order. If
the final Label for a block is less than the initial Label, the
LABEL-PROP RECORD is ignored. If the initial and final Labels are
equal, then a block of size one is indicated. Otherwise a block
of Label values with a size greater than one is indicated,
starting with initial Label through and including the final
Label. If the size of each Label value is not a multiple of 8
bits, each Label value is padded with initial reserved bits up to
the next multiple of 8. These reserved bits MUST be sent as zero
and ignored on receipt. For example, 12-bit Labels are padded
with four initial zeros.
Donald Eastlake and Weiguo Hao [Page 8]
INTERNET-DRAFT Nick/Label Properties
4. IANA Considerations
TBD
5. Security Considerations
TBD
For general TRILL security considerations, see [RFC6325].
Donald Eastlake and Weiguo Hao [Page 9]
INTERNET-DRAFT Nick/Label Properties
6. Normative References
[ISO-10589] - ISO/IEC 10589:2002, Second Edition, "Intermediate
System to Intermediate System Intra-Domain Routing Exchange
Protocol for use in Conjunction with the Protocol for Providing
the Connectionless-mode Network Service (ISO 8473)", 2002.
[RFC1195] - Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and
Dual Environments", 1990.
[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4971] - Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed.,
"Intermediate System to Intermediate System (IS-IS) Extensions
for Advertising Router Information", RFC 4971, July 2007
[RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, July 2011.
[RFC6329] - Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg,
A., and P. Unbehagen, "IS-IS Extensions Supporting IEEE 802.1aq
Shortest Path Bridging", RFC 6329, April 2012.
[clearcorrect] - D. Eastlake, M. Zhang, A. Ghanwani, A. Banerjee, V.
Manral, draft-ietf-trill-clear-correct-06.txt, in RFC Editor's
queue.
[FGL] - D. Eastlake, M. Zhang, P. Agarwal, R. Perlman, D. Dutt,
"TRILL (Transparent Interconnection of Lots of Links): Fine-
Grained Labeling", draft-ietf-trill-fine-labeling, in RFC
Editor queue.
[multilevel] - Perlman, R., D. Eastlake, A. Ghanwani, H. Zhai,
"Multilevel TRILL (Transparent Interconnection of Lots of
Links)", draft-perlman-trill-rbridge-multilevel, work in
progress.
7. Informative References
[TreeDistr] - draft-wu-trill-lsp-ext-tree-distr-opt, work in
progress.
Donald Eastlake and Weiguo Hao [Page 10]
INTERNET-DRAFT Nick/Label Properties
Acknowledgements
The authors gratefully acknowledge the contributions and review by
the following:
tbd
This document was produced with raw nroff. All macros used were
defined in the source files.
Donald Eastlake and Weiguo Hao [Page 11]
INTERNET-DRAFT Nick/Label Properties
Authors' Addresses
Donald Eastlake
Huawei R&D USA
155 Beaver Street
Milford, MA 01757 USA
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Weiguo Hao
Huawei Technologies
101 Software Avenue,
Nanjing 210012, China
Phone: +86-25-56623144
Email: haoweiguo@huawei.com
Donald Eastlake and Weiguo Hao [Page 12]
INTERNET-DRAFT Nick/Label Properties
Copyright, Disclaimer, and Additional IPR Provisions
Copyright (c) 2013 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.
Donald Eastlake and Weiguo Hao [Page 13]
