Re: [Pals] Mirja Kühlewind's Discuss on draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-08: (with DISCUSS and COMMENT)

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Deborah, hi Stewart, hi all,

see below.

> Am 06.07.2016 um 17:34 schrieb BRUNGARD, DEBORAH A <[e-mail]>:
> 
> I agree with Stewart - for the two bits to be set would be an implementation error. Not an operational error. The use of the two bits has been stable from the -00 version of the draft. There are always multiple ways to do a protocol design. And various tradeoffs. There are also operational positives for having two bits. Sub-TLVs are very common (PW, MPLS, GMPLS). The extra bit in an optional sub-TLV used when setting up a path is not going to break any bandwidth bank:-)

I personally think having these two bits here is really bad protocol design practice (and has no gain but can cause errors) but that’s not what my discuss is on. This design decision is the decision of the wg and I only made a proposal in the comments. However, the document makes unfortunately the impression to me that there was actually not enough wg discussion about this doc and the protocol design itself.

My discuss is on the part that the spec is not fully specified. Having both bits set or not set is not only an implementation error, this can also happen on the path. So how to react to these situations at receiver side should still be specified. Further, the case where both bits are set is specified as an error case while both bits unset is not; that just doesn’t make sense…

These things can be easily fixed (with probably 2 extra sentences) but MUST be fixed before publication.

In case the authors decide to actually change the protocol design (based on my suggestions) as Mach indicated earlier, the chairs and the AD have to decide if this doc has to go back to the wg.

> 
> As Stewart noted on his other email, PALS followed the Routing Area process of asking on IPR at the time of Last Call. We don't require positive confirmation that no one has concerns, only if they have concerns.

This was just a clarification question because I’ve read this sentence in the shepherd write-up and it was not fully clear to me what this was supposed to say. Thanks for the clarification! That’s all good.

Mirja



> 
> Much thanks Mirja for your interest and very comprehensive review - let us know if Stewart's proposal is acceptable to clear your discuss.
> 
> Deborah
> 
> -----Original Message-----
> From: iesg [mailto:[e-mail]] On Behalf Of Stewart Bryant
> Sent: Wednesday, July 06, 2016 8:58 AM
> To: Mirja Kuehlewind <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-08: (with DISCUSS and COMMENT)
> 
> 
> 
>>> 
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>> 
>>> I think the protocol specification is not complete:
>>> 
>>> - What happens if none of the two S and C bits are set?
>> Since the text specifically states that they are mutually exclusive, 
>> that would be
>> an implementation error. I don't think that it is within the scope of 
>> this draft to
>> state what should happen when there is an implementation error.
> 
> Thinking about this some more, we could say:
> 
>    Either the C-bit or the S-bit MUST be set.
>    the C-bit and S-bit are mutually exclusive from each other, and 
> cannot be
>    set in the same message.  Otherwise, a Label Release message with
>    status code set to "The C-bit and S-bit can not both be set" (TBD5)
>    MUST be replied, and the PW will not be established.
> 
> We could introduce an additional error message, but it's probably 
> adequate to
> say:
> 
>    Either the C-bit or the S-bit MUST be set.
>    The C-bit and S-bit are mutually exclusive from each other, and 
> cannot be
>    set in the same message.  In the case of either error, a Label 
> Release message with
>    status code set to "The C-bit and S-bit error" (TBD5)
>    MUST be replied, and the PW will not be established.
> 
> If parametrised messages are allowed I would say:
> 
> "The C-bit and S-bit error [<C-bit>, <S-bit>]"
> 
> Since zero or two bits are clearly an implementation error, I am not
> convinced that we need to do more than flag it up sufficiently that
> the an implementer can figure out what they got wrong.
> 
> Stewart
>