Skip to main content

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

Yes

(Adrian Farrel)

No Objection

(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Richard Barnes)
(Spencer Dawkins)

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

Adrian Farrel Former IESG member
Yes
Yes (for -06)

                            
Alia Atlas Former IESG member
Yes
Yes (2014-05-14 for -06)
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?
Alissa Cooper Former IESG member
No Objection
No Objection (2014-05-12 for -06)
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/
Barry Leiba Former IESG member
(was Discuss) No Objection
No Objection (2014-05-29)
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.
Benoît Claise Former IESG member
No Objection
No Objection (2014-05-12 for -06)
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/
Brian Haberman Former IESG member
No Objection
No Objection (2014-05-12 for -06)
I support Barry's point on section 3 and the security considerations section.
Jari Arkko Former IESG member
No Objection
No Objection (for -06)

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -06)

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2014-05-14 for -06)
I have nothing new to add, but did like Alia's suggestion for the security considerations section.
Martin Stiemerling Former IESG member
No Objection
No Objection (for -06)

                            
Pete Resnick Former IESG member
No Objection
No Objection (for -06)

                            
Richard Barnes Former IESG member
No Objection
No Objection (for -06)

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -06)

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2014-05-13 for -06)
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.)
Ted Lemon Former IESG member
No Objection
No Objection (2014-05-13 for -06)
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.