draft-ietf-mpls-extended-admin-group-02.txt   draft-ietf-mpls-extended-admin-group-03.txt 
Network Working Group E. Osborne Network Working Group E. Osborne
Internet-Draft Internet-Draft
Intended status: Standards Track January 24, 2014 Intended status: Standards Track March 6, 2014
Expires: July 28, 2014 Expires: September 7, 2014
Extended Administrative Groups in MPLS-TE Extended Administrative Groups in MPLS-TE
draft-ietf-mpls-extended-admin-group-02 draft-ietf-mpls-extended-admin-group-03
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 of
the Link TLV. This is defined for OSPFv2 [RFC3630], OSPFv3 [RFC5329] the Link TLV. This is defined for OSPFv2 [RFC3630], OSPFv3 [RFC5329]
and ISIS [RFC5305]. and ISIS [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
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 July 28, 2014. This Internet-Draft will expire on September 7, 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 23 skipping to change at page 2, line 23
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Extended Administrative Groups sub-TLV . . . . . . . . . . . 3 2. Extended Administrative Groups sub-TLV . . . . . . . . . . . 3
2.1. Packet Format . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Packet Format . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Admin group numbering . . . . . . . . . . . . . . . . . . 4 2.2. Admin group numbering . . . . . . . . . . . . . . . . . . 4
2.3. Backward compatability . . . . . . . . . . . . . . . . . 4 2.3. Backward compatability . . . . . . . . . . . . . . . . . 4
2.3.1. AG and EAG coexistence . . . . . . . . . . . . . . . 4 2.3.1. AG and EAG coexistence . . . . . . . . . . . . . . . 4
2.3.2. Desire for unadvertised EAG bits . . . . . . . . . . 4 2.3.2. Desire for unadvertised EAG bits . . . . . . . . . . 5
3. Signaling Extended Administrative Groups in RSVP . . . . . . 5 3. Signaling Extended Administrative Groups in RSVP . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. Normative References . . . . . . . . . . . . . . . . . . . . 6 7. Normative References . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
Do we need more than 32 bits? Do we need more than 32 bits?
The IGP extensions to support MPLS-TE (RFCs 3630 and 5305) define a The IGP extensions to support MPLS-TE (RFCs 3630 [RFC3630] and 5305
link TLV known as Administrative Group (AG) with a limit of 32 AGs [RFC5305]) define a link TLV known as Administrative Group (AG) with
per link. The concept of Administrative Groups comes from section a limit of 32 AGs per link. The concept of Administrative Groups
6.2 of RFC 2702 [RFC2702], which calls them Resource Classes. RFCs comes from section 6.2 of RFC 2702 [RFC2702], which calls them
3630 and 5305 describe the mechanics of the TLV and use the term Resource Classes. RFCs 3630 [RFC3630] and 5305 [RFC5305] describe
Administrative Groups (sometimes abbreviated herein as AGs), as does the mechanics of the TLV and use the term Administrative Groups
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. Administative Groups as are advertised as a fixed-length them. Administative Groups as are advertised as a fixed-length
32-bit bitmask. This can be quite constraining, as it is possible to 32-bit bitmask. This can be quite constraining, as it is possible to
run out of vaues rather quickly. One such use case is #5 in run out of vaues rather quickly. One such use case is #5 in
Section 6.2 of RFC2702, using AGs to constrain traffic within Section 6.2 of RFC 2702 [RFC2702], using AGs to constrain traffic
specific topological regions of the network. A large network may within specific topological regions of the network. A large network
well have far more than 32 geographic regions. One particular may well have far more than 32 geographic regions. One particular
operator builds their network along the lines of this use case, using operator builds their network along the lines of this use case, using
AGs to flag network regions down to the metro scale, e.g. Seattle, AGs to flag network regions down to the metro scale, e.g. Seattle,
San Francisco, Dallas, Chicago, St. Louis, etc. MPLS-TE tunnels are San Francisco, Dallas, Chicago, St. Louis, etc. MPLS-TE tunnels are
then specified with affinities to include or exclude specific metro then specified with affinities to include or exclude specific metro
regions in their path calculation. Each metro region is given its regions in their path calculation. Each metro region is given its
own bit in the AG bitmask. This means that 32 bits can only own bit in the AG bitmask. This means that 32 bits can only
(cleanly) represent 32 metro areas. It should be obvious that 32 may (cleanly) represent 32 metro areas. It should be obvious that 32 may
not be enough even for a US-based network, nevermind a worldwide not be enough even for a US-based network, nevermind a worldwide
network. network.
skipping to change at page 4, line 8 skipping to change at page 4, line 8
1. 1.
2.1. Packet Format 2.1. Packet Format
The format of the Extended Administrative Groups sub-TLV is the same The format of the Extended Administrative Groups sub-TLV is the same
for both OSPF and ISIS: for both OSPF and ISIS:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Extended Admin Group | Length | | Extended Admin Group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Admin Group Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........... | | ........... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Admin Group Flags | | Extended Admin Group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 length, but MUST be a multiple of 4 bytes. The only limits be of any length, but MUST be a multiple of 4 bytes. The only limits
on EAG size are those which are imposed by protocol-specific or on EAG size are those which are imposed by protocol-specific or
media-specific constraints (e.g. max packet length). 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 TLVs are numbered 0
(LSB) to 31 (MSB). The EAG values are a superset of AG. That is, (LSB) to 31 (MSB). The EAG values are a superset of AG. That is,
bits 0-31 in the EAG have the same meaning and MUST have the same bits 0-31 in the EAG have the same meaning and MUST have the same
values as an AG flooded for the same link. values as an AG flooded for the same link. If an EAG's length is
more than 4 bytes, numbering for these additional bytes picks up
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.
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
If a node advertises EAG it MAY also advertise AG. If a node If a node advertises EAG it MAY also advertise AG.
advertises both AG and EAG then the first 32 bits of the EAG MUST be
identical to the advertised AG. If the AG and EAG advertised for a If a node advertises both AG and EAG then the first 32 bits of the
link differ, the EAG MUST take priority. This allows nodes which do EAG MUST be identical to the advertised AG. If a receiving node
not support EAG to obtain some link color information from the notices that the AG differs from the first 32 bits of the EAG, it
network, but also allow for an eventual migration away from AG. SHOULD use the AG as the first 32 bits of the EAG, and SHOULD
indicate this mismatch to the operator.
If the AG and EAG advertised for a link differ, the EAG MUST take
priority. This allows nodes which do not support EAG to obtain some
link color information from the network, but also allow for an
eventual migration away from AG.
2.3.2. Desire for unadvertised EAG bits 2.3.2. Desire for unadvertised EAG bits
The existing AG sub-TLV is optional; thus a node may be configured The existing AG sub-TLV is optional; thus a node may be configured
with a preference to include red or exclude blue, and be faced with a with a preference to include red or exclude blue, and be faced with a
link that is not advertising a value for either blue or red. What link that is not advertising a value for either blue or red. What
does an implementation do in this case? It shouldn't assume that red does an implementation do in this case? It shouldn't assume that red
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 Each implementation is free to choose its own method for handling
this question. However, to encourage maximum interoperability an this question. However, to allow for maximum interoperability an
implementation SHOULD treat desired but unadvertised EAG bits as if implementation MUST treat desired but unadvertised EAG bits as if
they are set to 0. Consider the case where a node wants to only use they are set to 0. Consider the case where a node wants to only use
links where the 127th bit of an EAG is set to 1. If a link is only links where the 127th bit of an EAG is set to 1. If a link is only
advertising 64 EAG bits, clearly the 127th EAG bit is not defined - advertising 64 EAG bits, clearly the 127th EAG bit is not defined -
that is, it is neither explicitly 0 nor 1. The node which wants the that is, it is neither explicitly 0 nor 1. The node which wants the
127th EAG bit to be 1 SHOULD NOT use this link, as the assumption is 127th EAG bit to be 1 MUST NOT use this link, as the assumption is
than an unadvertised bit is set to 0. than an unadvertised bit is set to 0.
A node MAY provide other strategies for handling this case. A A node MAY provide other strategies for handling this case. A
strategy which deviates from the recommended behavior in this strategy which deviates from the recommended behavior in this
document SHOULD be configurable, in order to provide maximum document SHOULD be configurable, in order to provide maximum
interoperability. interoperability.
3. Signaling Extended Administrative Groups in RSVP 3. Signaling Extended Administrative Groups in RSVP
RSVP provides the ability to signal link affinity via the RSVP provides the ability to signal link affinity via the
SESSION_ATTRIBUTE object with C-Type 1 in [RFC3209]. At first glance SESSION_ATTRIBUTE object with C-Type 1 in RFC 3209 [RFC3209].
it seems useful to extend RSVP to provide a session attribute which Signaling EAG in RSVP is not addressed in this document. This
can signal extended affinities. As it turns out, there are several document does not preclude addressing this in the future should it be
non-trivial things to tackle were one to provide such an extension. deemed necessary.
In addition, an informal survey of the field, both MPLS-TE
implementors and network operators, suggests that the ability to
signal affinity bits in a SESSION_ATTRIBUTE object is not widely
deployed today. It is thus likely that signaling EAG in a
SESSION_ATTRIBUTE would see virtually no deployment. As this work
would be both non-trivial and aimed at a solution unlikely to be
deployed, it is not addressed in this document.
This document does not preclude solving this problem in the future
should it be deemed necessary.
4. Security Considerations 4. Security Considerations
This extension adds no new security considerations. This extension adds no new security considerations.
5. IANA Considerations 5. 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
 End of changes. 14 change blocks. 
44 lines changed or deleted 41 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/