Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)
RFC 7308

Note: This ballot was opened for revision 06 and is now closed.

(Alia Atlas) Yes

Comment (2014-05-14 for -06)
No email
send info
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?

(Adrian Farrel) Yes

(Jari Arkko) No Objection

(Richard Barnes) No Objection

(Benoît Claise) No Objection

Comment (2014-05-12 for -06)
No email
send info
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/

(Alissa Cooper) No Objection

Comment (2014-05-12 for -06)
No email
send info
Section 1:

s/allow for an arbitrary/allowing for an arbitrary/

Section 2:

s/bits with an AG or EAG/bits within an AG or EAG/

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2014-05-13 for -06)
No email
send info
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.)

(Brian Haberman) No Objection

Comment (2014-05-12 for -06)
No email
send info
I support Barry's point on section 3 and the security considerations section.

(Joel Jaeggli) No Objection

(Barry Leiba) (was Discuss) No Objection

Comment (2014-05-29)
No email
send info
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.

(Ted Lemon) No Objection

Comment (2014-05-13 for -06)
No email
send info
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.

(Kathleen Moriarty) No Objection

Comment (2014-05-14 for -06)
No email
send info
I have nothing new to add, but did like Alia's suggestion for the security considerations section.

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection