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

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/

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.

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/

I support Barry's point on section 3 and the security considerations section.

I have nothing new to add, but did like Alia's suggestion for the security considerations section.

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.)

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.