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

Hi Mirja,

Sure, thanks for your detailed review and valuable comments. Will update the document accordingly.

Best regards,
Mach 

> -----Original Message-----
> From: Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net]
> Sent: Tuesday, July 12, 2016 3:46 PM
> To: Mach Chen
> Cc: BRUNGARD, DEBORAH A; Stewart Bryant; pals-chairs@ietf.org; The IESG;
> draft-ietf-pals-mpls-tp-pw-over-bidir-lsp@ietf.org; pals@ietf.org
> Subject: Re: [Pals] Mirja Kühlewind's Discuss on
> draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-08: (with DISCUSS and COMMENT)
> 
> Thanks, I clear my discuss. Please update the draft and resubmit.
> 
> Mirja
> 
> 
> > Am 12.07.2016 um 09:42 schrieb Mach Chen <mach.chen@huawei.com>:
> >
> > Hi Mirja, all,
> >
> > Usually unknown or unexpected TLVs are usually simply silently discarded in
> MPLS. Usually protocols designs we prefer not to be complicated for
> implementation errors ("too chatty"). As you say, though, we already noted for
> an error for "C-bit set and S-bit set" so we'll do the same for "C-bit clear and
> S-bit clear. If "both C-bit and S-bit" are set or "both C-bit and S-bit are clear" are
> received, we will use the error code "C-bit or S-bit unknown". This error code
> will also allow future extensions which may use those bits.
> >
> > So, how about the following modification?
> >
> > OLD:
> > " 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 cannot both be set" (TBD5) MUST be replied, and the PW
> will not be established."
> >
> > New:
> > "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. If "both
> C-bit and S-bit are set" or "both C-bit and S-bit are clear" are received, a Label
> Release message with status code set to "The C-bit or S-bit unknown" (TBD5)
> MUST be replied, and the PW will not be established."
> >
> > Hope this addresses your DISCUSS!
> >
> > Thanks,
> > Mach
> >
> >> -----Original Message-----
> >> From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Mirja
> >> Kuehlewind (IETF)
> >> Sent: Thursday, July 07, 2016 4:57 AM
> >> To: BRUNGARD, DEBORAH A
> >> Cc: Stewart Bryant; pals-chairs@ietf.org; The IESG;
> >> draft-ietf-pals-mpls-tp-pw-over-bidir-lsp@ietf.org; pals@ietf.org
> >> Subject: Re: [Pals] Mirja Kühlewind's Discuss on
> >> draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-08: (with DISCUSS and
> >> COMMENT)
> >>
> >> Hi Deborah, hi Stewart, hi all,
> >>
> >> see below.
> >>
> >>> Am 06.07.2016 um 17:34 schrieb BRUNGARD, DEBORAH A
> >> <db3546@att.com>:
> >>>
> >>> 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:iesg-bounces@ietf.org] On Behalf Of Stewart
> >>> Bryant
> >>> Sent: Wednesday, July 06, 2016 8:58 AM
> >>> To: Mirja Kuehlewind <ietf@kuehlewind.net>; The IESG <iesg@ietf.org>
> >>> Cc: pals-chairs@ietf.org;
> >>> draft-ietf-pals-mpls-tp-pw-over-bidir-lsp@ietf.org; pals@ietf.org
> >>> 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
> >>>
> >>
> >> _______________________________________________
> >> Pals mailing list
> >> Pals@ietf.org
> >> https://www.ietf.org/mailman/listinfo/pals