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

[Mach Chen <[e-mail]>]

Hi Deborah, Stewart and Mirja,

After considering and discussing this with the co-authors and some implementers. I realized that change to one bit may not a good idea at this stage, since there may be some implementations out there. Thus, I agree with Stewart and Deborah that we do not need to do a fundamental change to the document given that the current design works fine. And Stewart's new text should cover the corner case.

Best regards,
Mach
> -----Original Message-----
> From: BRUNGARD, DEBORAH A [mailto:[e-mail]]
> Sent: Wednesday, July 06, 2016 11:35 PM
> To: Stewart Bryant; Mirja Kuehlewind; The IESG
> 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)
> 
> 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:-)
> 
> 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.
> 
> 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