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

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 27 Jun 2015 22:26:51 +0000

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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 28 Jun 2015 18:02:56 +0100

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.

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

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

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

> 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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 28 Jun 2015 19:07:03 +0000

Hi Adrian,

> On Jun 28, 2015, at 1:02 PM, Adrian Farrel <[email-masked]> wrote:
> 
> Hi Carlos
> 

Certainly non-blocking.

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

>      0b100101 (a prefix indicating binary format, common in programming languages)

Ack.

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

>> I hope these are useful — thanks!

Thank you for the quick response!

— Carlos.

---

From: Loa Andersson <[email-masked]>
Date: Mon, 29 Jun 2015 15:53:11 +0200

Carlos,

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

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 29 Jun 2015 14:16:38 +0000

Loa,

-----Original Message-----
From: Loa Andersson <[email-masked]>
Date: Monday, June 29, 2015 at 9:53 AM
To: Carlos Pignataro <[email-masked]>, Adrian Farrel
<[email-masked]>
Cc: "[email-masked]"
<[email-masked]>,
"[email-masked]" <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: MPLS-RT review of draft-vainshtein-mpls-gal-tc-ttl-handling-01

>> TC field of an LSE that contains the GAL to all zero (0b000).²,
>
>> I understand you say that there is an ³there may be valid reasons
>> doing so² implicit to the SHOULD.
>

That does not mean ³Absent local policy, then it is RECOMMENDED Š². The
text shows an absolute recommendation.

Carlos.

>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.
>>
>>
>> To me, it is an absolute recommendation without basis on interop, and
>>somewhat contradics the previous sentence.
>>
>>>
>>>> Why this strongest ³MUST²? Setting ourselves up for updating this
>>>>when there
>>>> is a use?
>>>
>>> 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.
>>>
>> 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²?
>>
>>>
>>>> misreads (like mine) with "Label Stack Entry (LSE) containing the GAL²
>>>> I hope these are useful ‹ thanks!
>>>
>>> Thanks again.
>>
>>
>> ‹ Carlos.

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 29 Jun 2015 22:12:05 +0100

I'd like to avoid going round and round on this (partly because I am too busy to
be pedantic today :-)

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

There is no such thing as "an absolute recommendation" because a 2119
recommendation is a should.

[Aside: Two years ago, in an airport not far from Washington DC...
TSA Officer: You are recommended to remove your shoes.
Me: No thanks, I'm OK with them on.
TSA Officer: No sir, you are recommended to remove your shoes.
Me: I think I'll be OK with them on. 
TSA Officer (louder): Sir! You are recommended to remove your shoes.
Me: Ah, I see. I'm sorry. I didn't realise. You're telling me to remove my
shoes.
TSA Officer: No sir, I cannot tell you to remove your shoes.

When we do a 2119 recommendation we mean "absent a reason to do otherwise".

But the crunch is that the documentation needs to give advice about when to vary
from the recommendation.
I thought we had that covered, albeit implicitly, by the previous sentence.

However, I have no problem with being super-explicit.

OLD
   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).
NEW
   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), 
   but they MAY vary this according to local policy.
END

Ciao,
Adrian