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

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

Hi Adrian,

> On Jun 28, 2015, at 1:02 PM, Adrian Farrel <[e-mail]> wrote:
> 
> 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.
> 

Certainly non-blocking.

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

My point is that the current text does not say what you say. The text says "It is RECOMMENDED that implementations set the TC field of an LSE that contains the GAL to all zero (0b000).”, and that statement does not include any qualifiers or conditionals. I understand you say that there is an “there may be valid reasons to do otherwise, with implications carefully understood before doing so” implicit to the SHOULD. However, that is different than saying “In the absence of local policy for setting those values, it is RECOMMENDED …”.

I suggest that a “Absent such local policy, “ be prepended to the reco.


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

To me, it is an absolute recommendation without basis on interop, and somewhat contradics the previous sentence.

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

Ack.

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

What if the receiving LER wants to apply a specific TC treatment? That is not a covert channel. Can there be different LSPs per TC?

In other words, is the document saying “on send you can use a local policy to set a value, but on receipt there is absolutely no reason to read it”?

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


Thank you for the quick response!

— Carlos.


> 
> Adrian
>