Last Call Review of draft-ietf-mpls-extended-admin-group-05
review-ietf-mpls-extended-admin-group-05-opsdir-lc-brownlee-2014-05-08-00

Hi all:

I have performed an Operations Directorate review of
   draft-ietf-mpls-extended-admin-group-06

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

1. Is the specification complete?  Can multiple interoperable
      implementations be built based on the specification?

Yes.

2. Is the proposed specification deployable?  If not, how could it be
      improved?

Yes.  It includes clear comments about transitioning from the current
AG TLV (Admin Group, max 32 'colours') to the proposed EAG (Extended
Admin Group, no limit to the number of 'colours').

3. Does the proposed approach have any scaling issues that could
      affect usability for large scale operation?

No. The size of an EAG TLV is only limited by factors such as restrictions
on TLV size or link MTU.

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?

5. Do you anticipate any manageability issues with the specification?

Operators who wish to use EAGs will need to update their management
system to a new version that implements them, but that should be
a normal system upgrade across their whole network.

6. Does the specification introduce new potential security risks or
      avenues for fraud?

This proposal adds a new TLV into MPLS LSAs; it's Security Considerations
section says that "adds no new security considerations;"  that seems
reasonable.

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/

Cheers, Nevil
Co-chair, IPFIX and EMAN WGs

--
---------------------------------------------------------------------
 Nevil Brownlee                    Computer Science Department | ITS
 Phone: +64 9 373 7599 x88941             The University of Auckland
 FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand