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

["Adrian Farrel" <[e-mail]>]

Hi Carlos

Thanks for the time and effort.

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

I'll start discussing these issues here, but hopefully these are not points (given your summary) that need delay adoption.

> 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?

2119 "RECOMMENDED" is the equivalent of "SHOULD". That means that implementations "MAY" vary the behavior. In this case, the variance is local policy. I think that "RECOMMENDED" means exactly what you suggest, viz. "If you don't have a good reason to do otherwise, your default behavior is (should be) to set to zero."

I'm happy to be guided by WG opinion on this. 

I suppose a return question to you is "What damage will it do to make this recommendation"?

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

I looked at...
    https://en.wikipedia.org/wiki/Binary_number#Representation
and found a number of options including:
      0b100101 (a prefix indicating binary format, common in programming languages)

>  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?

I think there is a common misunderstanding of "MUST" in this sort of case.
Consider that when a specific meaning is assigned to the TC in the GAL LSE, this will be done in a new document that will update this document.
It will be really, really important that when new meanings of this TC are defined, they pass safely through legacy nodes.
It's also pretty important that this TC field is not used as a covert channel by implementations that might fail to interoperate correctly.

So, there is an alternative to "MUST ignore on receipt" and that is "MUST set to zero on transmission".
I'd be happy to go either way.

> 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

I'll respond to George in his thread.

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

Yup.

> I hope these are useful — thanks!

Thanks again.

Adrian