draft-ietf-mpls-extended-admin-group-06.txt   draft-ietf-mpls-extended-admin-group-07.txt 
Network Working Group E. Osborne Network Working Group E. Osborne
Internet-Draft Internet-Draft
Intended status: Standards Track April 29, 2014 Intended status: Standards Track May 29, 2014
Expires: October 31, 2014 Expires: November 30, 2014
Extended Administrative Groups in MPLS-TE Extended Administrative Groups in MPLS-TE
draft-ietf-mpls-extended-admin-group-06 draft-ietf-mpls-extended-admin-group-07
Abstract Abstract
MPLS-TE advertises 32 administrative groups (commonly referred to as MPLS-TE advertises 32 administrative groups (commonly referred to as
"colors" or "link colors") using the Administrative Group sub-TLV of "colors" or "link colors") using the Administrative Group sub-TLV.
the Link TLV. This is defined for OSPFv2 (RFC3630), OSPFv3 (RFC5329) This is defined for OSPFv2 (RFC3630), OSPFv3 (RFC5329) and ISIS
and ISIS (RFC5305). (RFC5305).
This document adds a sub-TLV to the IGP TE extensions, "Extended This document adds a sub-TLV to the IGP TE extensions, "Extended
Administrative Group". This sub-TLV provides for additional Administrative Group". This sub-TLV provides for additional
administrative groups (link colors) beyond the current limit of 32. administrative groups (link colors) beyond the current limit of 32.
Requirements Language Requirements Language
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].
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 31, 2014. This Internet-Draft will expire on November 30, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 47 skipping to change at page 2, line 47
[RFC5305]) define a link TLV known as Administrative Group (AG) with [RFC5305]) define a link TLV known as Administrative Group (AG) with
a limit of 32 AGs per link. The concept of Administrative Groups a limit of 32 AGs per link. The concept of Administrative Groups
comes from section 6.2 of RFC 2702 [RFC2702], which calls them comes from section 6.2 of RFC 2702 [RFC2702], which calls them
Resource Classes. RFCs 3630 [RFC3630] and 5305 [RFC5305] describe Resource Classes. RFCs 3630 [RFC3630] and 5305 [RFC5305] describe
the mechanics of the TLV and use the term Administrative Groups the mechanics of the TLV and use the term Administrative Groups
(sometimes abbreviated herein as AGs), as does this document. (sometimes abbreviated herein as AGs), as does this document.
Networks have grown over time, and MPLS-TE has grown right along with Networks have grown over time, and MPLS-TE has grown right along with
them. Administrative Groups are advertised as a fixed-length 32-bit them. Administrative Groups are advertised as a fixed-length 32-bit
bitmask. This can be quite constraining, as it is possible to run bitmask. This can be quite constraining, as it is possible to run
out of vaues rather quickly. One such use case is #5 in Section 6.2 out of values rather quickly. One such use case is #5 in Section 6.2
of RFC 2702 [RFC2702], using AGs to constrain traffic within specific of RFC 2702 [RFC2702], using AGs to constrain traffic within specific
topological regions of the network. A large network may well have topological regions of the network. A large network may well have
far more than 32 geographic regions. One particular operator builds far more than 32 geographic regions. One particular operator builds
their network along the lines of this use case, using AGs to flag their network along the lines of this use case, using AGs to flag
network regions down to the metro scale, e.g. Seattle, San Francisco, network regions down to the metro scale, e.g. Seattle, San
Dallas, Chicago, St. Louis, etc. MPLS-TE tunnels are then specified Francisco, Dallas, Chicago, St. Louis, etc. MPLS-TE tunnels are then
with affinities to include or exclude specific metro regions in their specified with affinities to include or exclude specific metro
path calculation. Each metro region is given its own bit in the AG regions in their path calculation. Each metro region is given its
bitmask. This means that 32 bits can only (cleanly) represent 32 own bit in the AG bitmask. This means that 32 bits can only
metro areas. It should be obvious that 32 may not be enough even for (cleanly) represent 32 metro areas. It should be obvious that 32 may
a US-based network, nevermind a worldwide network. not be enough even for a US-based network, nevermind a worldwide
network.
There may be some opportunity for color reuse; that is, bit 0x8 may There may be some opportunity for color reuse; that is, bit 0x8 may
mean 'Seattle' or 'Prague' or 'Singapore' depending on the geography mean 'Seattle' or 'Prague' or 'Singapore' depending on the geography
in which it is used. In practice, coordinating this reuse is fraught in which it is used. In practice, coordinating this reuse is fraught
with peril and the reuse effectively becomes the limiting factor in with peril and the reuse effectively becomes the limiting factor in
MPLS-TE deployment. With this example it is not possible to build an MPLS-TE deployment. With this example it is not possible to build an
LSP which avoids Seattle while including Prague, as it is the same AG LSP which avoids Seattle while including Prague, as it is the same AG
value. value.
This document provides Extended Administrative Groups (EAGs). The This document provides Extended Administrative Groups (EAGs). The
number of EAGs has no fixed limit, it is constrained only by number of EAGs has no fixed limit, it is constrained only by
protocol-specific restrictions such as LSA or MTU size. While an protocol-specific restrictions such as LSA or MTU size. While an
operator may one day need to go beyond these protocol-specific operator may one day need to go beyond these protocol-specific
restrictions, allow for an arbitrary number of EAGs should easily restrictions, allowing for an arbitrary number of EAGs should easily
provide the operator with hundreds or thousands of bit values, thus provide the operator with hundreds or thousands of bit values, thus
no longer making the number of AGs an impediment to network growth. no longer making the number of AGs an impediment to network growth.
EAG's intended use case is within a single domain. As such, this EAG's intended use case is within a single domain. As such, this
document provides no support for signaling EAG. It provides no document provides no support for signaling EAG. It provides no
analog to either the SESSION_ATTRIBUTE of C-Type 1 defined in analog to either the SESSION_ATTRIBUTE of C-Type 1 defined in
[RFC3209], nor the LSPA object of the Path Computation Element [RFC3209], nor the LSPA object of the Path Computation Element
Communication Protocol (PCEP) defined in [RFC5440]. Communication Protocol (PCEP) defined in [RFC5440]. Since this
specification provides no way of signaling an LSP's path requirements
in reference to the EAG, such constraints may only be applied at the
ingress.
2. Extended Administrative Groups sub-TLV 2. Extended Administrative Groups sub-TLV
This document defines a sub-TLV of the Link TLV for both OSPF This document defines the Extended Administrative Group (EAG) sub-TLV
[RFC3630] and ISIS [RFC5305] called the Extended Administrative for both OSPF [RFC3630] and ISIS [RFC5305]. The EAG sub-TLV is used
Groups (EAG) sub-TLV. The EAG sub-TLV is used in addition to the in addition to the Administrative Groups when an operator wants to
Administrative Groups when an operator wants to make more than 32 make more than 32 colors available for advertisement in a network.
colors available for advertisement in a network. The EAG sub-TLV is The EAG sub-TLV is optional. Coexistence of EAG and AG TLVs is
optional. Coexistence of EAG and AG TLVs is covered in Section 2.3.1 covered in Section 2.3.1 of this document.
of this document.
This document uses the term 'colors' as a shorthand to refer to This document uses the term 'colors' as a shorthand to refer to
particular bits with an AG or EAG. The examples in this document use particular bits with an AG or EAG. The examples in this document use
'red' to represent the least significant bit in the AG (red == 0x1), 'red' to represent the least significant bit in the AG (red == 0x1),
'blue' to represent the second bit (blue == 0x2). To say that a link 'blue' to represent the second bit (blue == 0x2). To say that a link
has a given color or that the specified color is set on the link is has a given color or that the specified color is set on the link is
to say that the corresponding bit or bits in the link's AG are set to to say that the corresponding bit or bits in the link's AG are set to
1. 1.
2.1. Packet Format 2.1. Packet Format
skipping to change at page 4, line 28 skipping to change at page 4, line 30
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type of the sub-TLV for OSPF and ISIS is TBD. The Length is the The Type of the sub-TLV for OSPF and ISIS is TBD. The Length is the
size of the Extended Admin Group (EAG) value in bytes. The EAG may size of the Extended Admin Group (EAG) value in bytes. The EAG may
be of any non-zero length, but MUST be a multiple of 4 bytes. The be of any non-zero length, but MUST be a multiple of 4 bytes. The
only limits on EAG size are those which are imposed by protocol- only limits on EAG size are those which are imposed by protocol-
specific or media-specific constraints (e.g. max packet length). specific or media-specific constraints (e.g. max packet length).
2.2. Admin group numbering 2.2. Admin group numbering
By convention, the existing Administrative Group TLVs are numbered 0 By convention, the existing Administrative Group sub-TLVs are
(LSB) to 31 (MSB). The EAG values are a superset of AG. That is, numbered 0 (LSB) to 31 (MSB). The EAG values are a superset of AG.
bits 0-31 in the EAG have the same meaning and MUST have the same That is, bits 0-31 in the EAG have the same meaning and MUST have the
values as an AG flooded for the same link. If an EAG's length is same values as an AG flooded for the same link. If an EAG's length
more than 4 bytes, numbering for these additional bytes picks up is more than 4 bytes, numbering for these additional bytes picks up
where the previous byte left off. For example, the least significant where the previous byte left off. For example, the least significant
bit in the 5th byte of an 8-byte EAG is referred to as bit 32. bit in the 5th byte of an 8-byte EAG is referred to as bit 32.
2.3. Backward compatability 2.3. Backward compatability
There are two questions to consider for backward compatibility with There are two questions to consider for backward compatibility with
existing AG implementations - how do AG and EAG coexist, and what existing AG implementations - how do AG and EAG coexist, and what
happens if a node has matching criteria for unadvertised EAG bits? happens if a node has matching criteria for unadvertised EAG bits?
2.3.1. AG and EAG coexistence 2.3.1. AG and EAG coexistence
skipping to change at page 5, line 32 skipping to change at page 5, line 32
is set, but it is also arguably incorrect to assume that red is NOT is set, but it is also arguably incorrect to assume that red is NOT
set, as a bit must first exist before it can be set to 0. set, as a bit must first exist before it can be set to 0.
Practically speaking this has not been an issue for deployments, as Practically speaking this has not been an issue for deployments, as
many implementations always advertise the AG bits, often with a many implementations always advertise the AG bits, often with a
default value of 0x00000000. However, this issue may be of more default value of 0x00000000. However, this issue may be of more
concern once EAGs are added to the network. EAGs may exist on some concern once EAGs are added to the network. EAGs may exist on some
nodes but not others, and the EAG length may be longer for some links nodes but not others, and the EAG length may be longer for some links
than for others. than for others.
Each implementation is free to choose its own method for handling To allow for maximum interoperability, an implementation SHOULD treat
this question. However, to allow for maximum interoperability an desired but unadvertised EAG bits as if they were set to 0. Consider
implementation SHOULD treat desired but unadvertised EAG bits as if the case where a node wants to only use links where the 127th bit of
they are set to 0. Consider the case where a node wants to only use an EAG is set to 1. If a link is only advertising 64 EAG bits, the
links where the 127th bit of an EAG is set to 1. If a link is only setting of the 127th EAG bit is not known - that is, it is neither
advertising 64 EAG bits, clearly the 127th EAG bit is not defined - explicitly 0 nor 1. The node that wants the 127th EAG bit to be 1
that is, it is neither explicitly 0 nor 1. The node which wants the will not use this link when implementing the recommended behavior, as
127th EAG bit to be 1 MUST NOT use this link when implementing the the assumption is than the unadvertised 127th bit is set to 0.
recommended behavior, as the assumption is than an unadvertised bit
is set to 0.
A node MAY provide other strategies for handling this case. A That said, each implementation makes its own choices based on
strategy which deviates from the recommended behavior in this necessary constraints, and there might be reasons to provide other
document SHOULD be configurable, in order to provide maximum strategies for handling this case. A strategy that deviates from the
interoperability. behavior this document recommends SHOULD be configurable to use the
recommended behavior, in order to provide maximum interoperability.
3. Security Considerations 3. Security Considerations
This extension adds no new security considerations. This extension adds no new security considerations.
4. IANA Considerations 4. IANA Considerations
This document requests a sub-TLV allocation in both OSPF and ISIS. This document requests a sub-TLV allocation in both OSPF and ISIS.
For OSPF, the name space is "Types for sub-TLVs of TE Link TLV (Value For OSPF, the name space is "Types for sub-TLVs of TE Link TLV (Value
2)" in the "Open Shortest Path First (OSPF) Traffic Engineering 2)" in the "Open Shortest Path First (OSPF) Traffic Engineering
TLVs". TLVs".
For ISIS, it is "Sub-TLVs for TLV 22, 141, and 222" in the "IS-IS TLV For ISIS, it is "Sub-TLVs for TLV 22, 141, and 222" in the "IS-IS TLV
Codepoints" registry. For IS-IS the value should be marked 'y' for Codepoints" registry. For IS-IS the value should be marked 'y' for
Sub-TLVs 22, 141 and 222; this is identical to the allocation for the Sub-TLVs 22, 141 and 222; this is identical to the allocation for the
Administrative Group sub-TLV (value 3). Administrative Group sub-TLV (value 3).
In both registries the first free value should be assigned. As of In both registries the first free value should be assigned. As of
this writing, that's 26 in the OSPF registry and 14 in the IS-IS this writing, that's 26 in the OSPF registry and 14 in the IS-IS
registry. The Sub-TLV should be caled "Extended Administrative registry. The Sub-TLV should be called "Extended Administrative
Group". Group".
5. Acknowledgements 5. Acknowledgements
Thanks to Santiago Alvarez, Rohit Gupta, Liem Nguyen, Tarek Saad, Thanks to Santiago Alvarez, Rohit Gupta, Liem Nguyen, Tarek Saad,
Robert Sawaya, Andy Malis, Les Ginsberg and Adrian Farrel for their Robert Sawaya, Andy Malis, Les Ginsberg and Adrian Farrel for their
review and comments. review and comments.
6. References 6. References
 End of changes. 13 change blocks. 
44 lines changed or deleted 46 lines changed or added

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