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

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