[mpls] MPLS-RT review of draft-vainshtein-mpls-gal-tc-ttl-handling-01

["Carlos Pignataro (cpignata)" <[e-mail]>]

Hi,

I’ve been selected as MPLS-RT reviewer for draft-vainshtein-mpls-gal-tc-ttl-handling-01. Please find my review below.

I believe this is a useful, coherent, and technically sound document. However, it does have issues that require attention and consideration.

Technical Issues:

3.1.  New Procedures for Handling the TC Field in an LSE That Contains
      the GAL

   Setting the value of the TC field in an LSE that contains the GAL is
   done by the LER that originates the G-ACh packet and is a matter of
   local policy for that LER.  It is RECOMMENDED that implementations
   set the TC field of an LSE that contains the GAL to all zero (0b000).

CMP: If it is a local policy, why the RECOMMENDED language? Why not state a default policy, such that lacking any other it is set to 0, but RECOMMENDED sounds too strong. In fact, it has no interop considerations, does it?

CMP: A nit, is 0b000 the same as 000b? Not sure the notation.

   The LER that inspects an LSE that contains the GAL MUST ignore the
   value of the TC field.

CMP: Similarly, this document concerns itself with maximizing interoperability. Why this strongest “MUST”? Setting ourselves up for updating this when there is a use?

3.2.  New Procedures for Handling the TTL Field in an LSE Containing GAL

CMP: I agree with this comment: http://www.ietf.org/mail-archive/web/mpls/current/msg14300.html <http://www.ietf.org/mail-archive/web/mpls/current/msg14300.html>

Nits:

 Handling the TC and TTL fields in a Label Stack Entry when the Generic
                  Associated Channel Label is Present

CMP: When I read this, I was not sure if the GAL was present in any LSE. This is likely just me, but it would be best to disambiguate potential misreads (like mine) with "Label Stack Entry (LSE) containing the GAL” (i.e., otherwise present where?)

I hope these are useful — thanks!

— Carlos.