Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)
draft-ietf-mpls-extended-admin-group-07

Received changes through RFC Editor sync (changed abstract to 'MPLS Traffic Engineering (MPLS-TE) advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV. This is defined for OSPFv2 (RFC 3630), OSPFv3 (RFC 5329) and IS-IS (RFC 5305).

This document adds a sub-TLV to the IGP TE extensions, "Extended Administrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32.')

[Ballot comment]
Version -07 addresses my comments; thanks for considering them.  And I have been convinced that there is, indeed, no security exposure created by the uncertain handling of "missing" bits.

[Ballot comment]
I do agree that Barry that I'd prefer to see clearer wording in Sec 2.3.2.  I really don't see a reason that this is a SHOULD instead of a MUST for understanding that unsignaled colors MUST be assumed to be 0.  I'm slightly concerned that we'll end up in a situation where a color can have three values - 0, 1, and unknown - and thus foster different behaviors.

I also found it slightly confusing in this section about being able to not advertise some EAG bits.  What I think is meant is that a router only needs to send colors up to the word including the highest set bit value.  I.e. if bit 74 is set, then bits 0 to 95 will be sent.  With the encoding, there's not a way of sending bit 528 without having sent all the lower bits.

For the Security Considerations, I agree that there aren't actual new attacks created - but I would recommend mentioning what the actual constraints on the EAGs adding data are and how they are limited by the protocol or media constraints (mentioned in Sec 2.1).

In the intro, it says:
"EAG's intended use case is within a single domain.  As such, this
  document provides no support for signaling EAG."

This is also restricting it to ingress full path computation since midpoint LSRs will not be able to see the constraints.  Could you please add such a clarification?

[Ballot comment]
I do agree that Barry that I'd prefer to see clearer wording in Sec 2.3.2.  I really don't see a reason that this is a SHOULD instead of a MUST for understanding that unsignaled colors MUST be assumed to be 0.  I'm slightly concerned that we'll end up in a situation where a color can have three values - 0, 1, and unknown - and thus foster different behaviors.

I also found it slightly confusing in this section about being able to not advertise some EAG bits.  What I think is meant is that a router only needs to send colors up to the word including the highest set bit value.  I.e. if bit 74 is set, then bits 0 to 95 will be sent.  With the encoding, there's not a way of sending bit 528 without having sent all the lower bits.

For the Security Considerations, I agree that there aren't actual new attacks created - but I would recommend mentioning what the actual constraints on the EAGs adding data are and how they are limited by the protocol or media constraints (mentioned in Sec 2.1).

[Ballot comment]

When both AG and EAG are sent the AG colours are
sent twice. That always bothers me since its always
possible that someone reads the wrong bits. The
spec is correct as-is I think, but just wondering
if you considered not sending those 32 bits twice?
(i.e. if AG and EAG both sent, then bit 0 of EAG
is the 33rd colour.)

[Ballot comment]
Minor nit in the introduction, paragraph 3:
  bitmask.  This means that 32 bits can only (cleanly) represent 32
  metro areas.  It should be obvious that 32 may not be enough even for
  a US-based network, nevermind a worldwide network.

This may well be too nit-picky, but this text can be read as implying an editorial assumption that the reader would naturally assume a US-based network unless otherwise specified.  This could be used to beat up the IETF for being U.S.-centric, which people apparently still do.  I suspect this assumption wasn't intended, but rather that you were continuing the example earlier in the paragraph where multiple U.S. cities were listed.  However, if you care to, you might want to change this to "single-country" instead of "US-based."  Or you can ignore this very minor nitpick, and it very likely won't matter.

In section 2.2:

  By convention, the existing Administrative Group TLVs are numbered 0
  (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
  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.

If I am reading this correctly, what this means is that the first byte in the TLV contains bits 24-31, the second bits 16-23, the third bits 8-15, the fourth bits 0-7 and the fifth bits 32-39.  This seems counterintuitive and likely to promote mismatches between the UI and the wire format on different implementations, if an implementor gets this wrong.  My concern is that two different devices from two different vendors could wind up accidentally being incompatibly configured in a way that would be difficult for the end-user to debug if such a mistake were made.  Did the working group consider this possibility?  It might be worth adding a small amount of text that calls attention to this counterintuitive numbering of bits more explicitly, so as to make such a mistake less likely.  I'm not raising this as a DISCUSS because a careful read of the text can produce only one interpretation, so a wrong implementation would not be following the spec.

[Ballot comment]
Agreed with Barry's DISCUSS point 1, and I believe Barry's new proposal improves the doc.


I've not yet seen an answer to Nevil's question in the OPS DIR review.

4. Are there any backward compatibility issues?

Section 2.3.1 covers AG and EAG coexistence.

I was puzzled by the paragraphs in 2.3.1 that says "If both an AG and
EAG are present, a receiving node MUST use the AG as the first 32 bits
(0-31) of administrative color and use the EAG for bits 32 and higher
if present."  Since the first 32 bits of an EAG should be the same
as the first 32 bits of an AG, why not change over now, and use the
first 32 bits of the EAG?

A few typos:

p3: s/restrictions, allow for/restrictions, allowing for/

p5: a/assumption is than an/assumption is that an/

p6: s/caled/called/

[Ballot discuss]
I think this is a good document, and have two points I'd like to discuss before approval.

The first is an easy one:

-- Section 2.3.2 --

I hate to pick on this, I really do -- because I know what you're trying to say -- but there's too much wrong with this bit:

  Each implementation is free to choose its own method for handling
  this question.  However, to allow for maximum interoperability an
  implementation SHOULD treat desired but unadvertised EAG bits as if
  they are set to 0.

"Free to choose" and "SHOULD" really don't go together, at least not with the definition of "SHOULD" from 2119 and any meaning of "free to choose" that I can think of.  What's more, you then have a "MUST NOT" later in the paragraph that should probably be a "SHOULD NOT" (because it goes with the "SHOULD".  On the other hand, if you really mean that "MUST NOT", then the "SHOULD" ought to be a "MUST".  Oh, and then there's a "MAY" in the next paragraph, which makes the whole thing worse.  Oy.

Because I really *do* hate to pick on this, and because I think I do know what you're trying to say, let me try proposing alternative wording for the last two paragraphs that should (ahem) keep us 2119-purists happy (or at least comparatively happier).  As a side effect, it makes subjunctive-mood-pedants somewhat happier, as well (changing "as if they are" to "as if they were"):

NEW
  To allow for maximum interoperability, an implementation SHOULD treat
  desired but unadvertised EAG bits as if they were 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 advertising 64 EAG bits, clearly
  the 127th EAG bit is not defined - that is, it is neither explicitly 0
  nor 1.  The node that wants the 127th EAG bit to be 1 will not use this
  link when implementing the recommended behavior, as the assumption is
  than the unadvertised 127th bit is set to 0.

  That said, each implementation makes its own choices based on necessary
  constraints, and there might be reasons to provide other strategies for
  handling this case.  A strategy that deviates from the behavior this
  document recommends SHOULD be configurable to use the recommended
  behavior, in order to provide maximum interoperability.
END

I think inverting the advice -- putting the desired behaviour first -- is a better choice anyway, because it highlights what you want implementations to do... and only after that does it backtrack and admit that, well, implementations will ultimately do what they want.

The second is probably somewhat harder:

-- Section 3 --

Is it really the case that there are no possible issues raised by suddenly having an open-ended number of EAG bits, having a different number of EAG bits than are expected or desired, and/or having uncertain behaviour in the face of a desired bit's not being there?  I'm not sure of the answer to that, but I am sure that it strikes me as very much open to issues, and I want to make sure you explicitly thought about it carefully and decided that there aren't... and that "no new security considerations" isn't just what we're accustomed to putting in when we think we're making a minor change.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-mpls-extended-admin-group-05.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the Types for sub-TLVs of TE Link TLV (Value 2) subregistry of the Open Shortest Path First (OSPF) Traffic Engineering TLVs registry located at:

http://www.iana.org/assignments/ospf-traffic-eng-tlvs/

a new type is to be registered as follows:

Value: [ TBD-at-registration ]
Sub-TLV: Extended Administrative Group
Reference: [ RFC-to-be ]

Second, in the Sub-TLVs for TLV 22, 141, and 222 subregistry of the IS-IS TLV Codepoints registry located at:


http://www.iana.org/assignments/isis-tlv-codepoints/

a new Sub-TLV will be registered as follows:

Type: [ TBD-at-registration ]
Description: Extended Administrative Group
22: y
141: y
222: y
Reference: [ RFC-to-be ]

IANA understands that these two actions are the only ones that need to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Extended Administrative Groups in MPLS-TE) to Proposed Standard

The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Extended Administrative Groups in MPLS-TE'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-05-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  MPLS-TE advertises 32 administrative groups (commonly referred to as
  "colors" or "link colors") using the Administrative Group sub-TLV of
  the Link TLV.  This is defined for OSPFv2 (RFC3630), OSPFv3 (RFC5329)
  and ISIS (RFC5305).

  This document adds a sub-TLV to the IGP TE extensions, "Extended
  Administrative Group".  This sub-TLV provides for additional
  administrative groups (link colors) beyond the current limit of 32.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-extended-admin-group/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-extended-admin-group/ballot/


No IPR declarations have been submitted directly on this I-D.

AD review
======

Hello,

I have done my usual AD review of your document upon receiving the
publication request. The purpose is to catch any issues that might
otherwise show up during IETF last call or IESG review and to get the
document into good shape so that those later reviews have a clearer
run.

There are a few comments below that I would like you to look at. The
I-D is very short and simple, so there is not much to comment on, but
I have a few concerns, clarifications, and editorial points that I
hope you will look at. You are, of course, welcome to dispute any of
these points and discuss them with me on the WG mailing list.

While you are working on this I will put the document into "Revised
I-D Needed" state and I will ask the WG chairs to send a notice about
this I-D to the OSPF, ISIS, and CCAMP mailing lists so that they are
aware of the draft and can comment immediately or during IETF last call
if they have any concerns.

Thanks for the work,
Adrian

===

This document adds a sub-TLV. I think it is your intention that this is
a sub-TLV of the Link TLV and not of the Administrative Group sub-TLV,
itself. That seems pretty important, so it needs to be stated clearly.

---

The use case in para 2 of Section 1 is, of course, predicated on using
a single IGP domain (area/level) to cover the whole network that is
being discussed.  That is OK, but the text should note this caveat lest
people think that admin colours are somehow globally unique.

---

Section 2.1

  The EAG may
  be of any length, but MUST be a multiple of 4 bytes.

Is a zero-length TLV allowed?

---

2.3.1

  If a receiving node
  notices that the AG differs from the first 32 bits of the EAG, it
  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.

Aren't these two statements contradictory?
I suspect the final "EAG" is supposed to read "AG" to be consistent
with the first paragraph and also to match the first motivation given
immediately after.

  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.

OTOH...

1. The second motivation seems to support EAG taking priority.

2. The first motivation seems to miss some really big issues concerning
  non-support of EAG. You need to discuss this processing in relation
  to signaling...

  Suppose a link is advertised with EAG and a node that does not
  support EAG signals an LSP?

  Suppose one end of a link supports EAG but the other does not and
  a signaling message includes EAG and the upstream end of the link
  ignores it?

  I think you have some edge conditions to describe in section 2.3

---

I read section 4.7.4 of RFC 3209 to compare it with what you say in
section 2.3.2 of this document.

I read it to say:
- a link can only be excluded if it advertises a specific color
- a link can only be included if it advertises a specific color
Thus, failure to include AG means a link cannot be excluded according
to an exclusion requirement. But it also means that it cannot be
included according to an include or include-any requirement.

Now, that is not how I read what you have said in 2.3.2. Here I see
you saying that if a node does not advertise AG the path selection
cannot decide whether an affinity is set of not. I believe that is
subtly different from what 3209 says - I think that says that if an
AG is not present then the inclusion test must fail as if the
affinity was not set.

Of course, you are right that a default advertisement of 0x0 is a
good way around this, and you are correct that this becomes confusing
with variable length EAGs. But it is important to note that a default
advertisement of 0x0 is still an explicit advertisement of no affinities
being set, and the default is being applied at the advertising node not
at the receiver of the advertisement.

You go on to say...                 

  Each implementation is free to choose its own method for handling
  this question.  However, to allow for maximum interoperability an
  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
  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 -
  that is, it is neither explicitly 0 nor 1.  The node which wants the
  127th EAG bit to be 1 MUST NOT use this link, as the assumption is
  than an unadvertised bit is set to 0.                                             

I think this is functionally equivalent to RFC 3209.
That is, a link cannot be excluded on the basis of an unadvertised
affinity because it is assumed to be 0.
And a link cannot be included on the basis of an unadvertised affinity
because it is assumed to be 0.

So it all ends up right in the end, but it took a lot of words!

---

In Section 2.3.2 you have an "interesting" mix of advice and 2119 words.

  Each implementation is free to choose its own method for handling
  this question. 

"Free to choose" is preparing me to not see any use of "MUST"
 
  However, to allow for maximum interoperability an
  implementation MUST treat desired but unadvertised EAG bits as if
  they are set to 0. 
                                                                                     
Oh, so my implementation is not free to choose! 
 
  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
  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
  127th EAG bit to be 1 MUST NOT use this link, as the assumption is
  than an unadvertised bit is set to 0.
                                                                                     
  A node MAY provide other strategies for handling this case.

Hello! I am now allowed to do something different from the "MUST"
 
  A
  strategy which deviates from the recommended behavior in this

Although this is a lower case "recommended" I associate that word with
"SHOULD" not the actual "MUST" that you used.

  document SHOULD be configurable, in order to provide maximum
  interoperability.

If it is only "SHOULD be configurable" then you allow "not configurable"
in which case you have a procedure that deviates from the "MUST" and is
not configurable.

Hmmmm.

I think you wanted to say:
- All implementations MUST support a mode of operation that assumes
  absent affinities are set to 0
- Implementations MAY support other modes of operation
- Implementations that support other modes of operation MUST have allow
  configuration to select the mode of operation, and MUST default to
  assume that absent affinities are set to 0

But, one final question...
Why do you want to allow other modes of operation?
What is the benefit, and why didn't you call it out?

---

Section 3 deliberately sidesteps the use of EAG in signaling. That is
"interesting" and makes me assume that the use of EAG you have in mind
applies only at the point of explicit path selection (i.e. no loose
hop selection).

I think that, in order to justify this work being limited to the IGPs
you need to be a bit more explicit, up front, that *your* use case
concerns pre-computation of paths.

Now, there are two places where path selection will be done:
1. The head-end LSR
2. A PCE

So, you should pick one or both of these as your use case and state it
clearly. If you include PCE, you will need to look at the applicability
to PCEP (see Section 7.11 of RFC 5440).

---

Section 5 could be made clearer by breaking the text out into separate
paragraphs or even separate sections. It would also be helpful to IANA
if you made little tables showing the exact information you want
recorded in each registry.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

    The MPLS working groups request that

                    Extended Administrative Groups in MPLS-TE
                      draft-ietf-mpls-extended-admin-group-03

    Is published as an RFC on the standards track.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

    We request that the document is published as a proposed standard.
    The document header says "Standards Track".

    This document defines additions to the TE extensions for OSPF-TE and
    ISIS-TE. Since it defines protocol element it needs to be on the standards
    track.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  In the current MPLS-TE specifications i is possible to advertise
  32 administrative groups (a.ka. "colors" or "link colors"). This is done
  by using the  using the Administrative Group sub-TLV in the Link TLV.
  This is defined for OSPFv2 in RFC3630, for OSPFv3 in RFC5329 and
    ISIS in RFC5305.

  This document adds a sub-TLV to the IGP TE extensions, "Extended
  Administrative Group".  This sub-TLV provides for additional
  administrative groups (link colors) beyond the current limit of 32.


  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

      No there is a general agreement in the working group that this
      is needed, there has been comments during the discussion
      in the in the working group and the working last call, but all them
      contributing to improving the document.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

      Currently we are aware of one commercial implementation.

      A mail requesting implementation information has been sent to
      the wg mailing list and the Shepherd Write-up will be updated
      if we receive further information.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

      Adrian Farrel is the Responsible AD.
      Loa Andersson i the document SHephed

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

      The document shepherd has reviewed the document three times;
        (1) when we prepared the poll to see if w had consensus to accept
      it as  working group document.
      (2) while preparing the wglc and (3) while preparing the shepherd
      write-up.
      The shepherd is convinced that the current version (-04) is ready for
        publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

      No such concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

      No such reviews necessary.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

      No such concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

      The author has stated on the working group mailing list that he is
      un-aware of any IPR that relates to this draft.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

      There are no IPR disclosures against his document.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

      The working group is behind this document.
         

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

      No such threas

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

      The document passes the clean.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

      No such reviews necessary

(13) Have all references within this document been identified as
either normative or informative?

      The references are correctly split into normative and informative
      references.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

      All the references are existing RFCs (including the informative
      reference).

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

      There are no  downward references,

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it un-necessary.

      This document does not update or change the status of any
      existing RFC.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

        The document request that one sub-TLV are allocated for OSPF and
        ISIS each. The IANA section is clear and easy to understand

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

      No such registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

      No such reviews necessary.