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

[Loa Andersson <[e-mail]>]

Carlos,

On 2015-06-28 21:07, Carlos Pignataro (cpignata) wrote:
> Hi Adrian,
<snip>

>>

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

Maybe naive, but I thought SHOULD and RECOMMENDED have the same implicit
conditions, RFC 2119 says:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.

/Loa


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

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]