Re: [mpls] George can yu look at this - Re: end of WGLC, RE: working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01

["Adrian Farrel" <[e-mail]>]

Thanks Loa,

You captured it. The edge cases need to be nailed down.

Personally I have no particular preference for where it is nailed, but I don't
want it flapping in the breeze.

A

> -----Original Message-----
> From: mpls [mailto:[e-mail]] On Behalf Of Loa Andersson
> Sent: 23 April 2015 13:59
> To: t.petch; Nobo Akiya
> Cc: Ross Callon; mpls; [e-mail];
draft-ietf-mpls-lsp-ping-reply-
> [e-mail]
> Subject: [mpls] George can yu look at this - Re: end of WGLC, RE: working
group
> last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01
> 
> Tom,
> 
> The question you and Adrian asks is what to do if the Reply Mode
> Order TLV is missing.
> 
> There is something fishy here, I'd like George to look at this.
> 
> The LSP Ping design says that TLVs from this range may be silentsly
> dropped, my take is that we don't need to specify anything more
> than that.
> 
> Now, we say that it MUST be present, and after thinking around a bit
> I wonder if the TLV should be assigned from the mandatory range instead?
> 
> Or if the MUST be present means that the message will be malformed if
> it is not there, and the message should be discarded.
> 
> OK - now I'm confused.
> 
> /Loa
> 
> On 2015-04-23 13:02, t.petch wrote:
> > ---- Original Message -----
> > From: "Loa Andersson" <[e-mail]>
> > Sent: Wednesday, April 22, 2015 2:15 PM
> >
> >> Tom,
> >>
> >> On 2015-04-20 00:07, Nobo Akiya wrote:
> >>>      <tp>
> >>>
> >>>      Yes but ... I think that it is a change of meaning.  Is is
> > enough just
> >>>      to ignore the TLV or should the whole PDU be discarded?  I find
> > it
> >>>      difficult to know but don't feel strongly about that choice so
> > will go
> >>>      with what you suggest.
> >>>
> >>>      </tp>
> >>
> >> So I don't misunderstand what you are saying. It seems to me like the
> >> comments made by Adrian and you actually requires a "change of
> > meaning",
> >> that is kind of essence of a "comment", right?
> >>
> >> As for what to do with if the TLV is not recognized, it is
> >> intentionally requested from a space where it can be silently dropped
> >> (i.e. "ignored").
> >>
> >>      The new TLV Type value should be assigned from the range
> >>      (32768-49161) specified in [RFC4379] section 3 that allows the TLV
> >>      type to be silently dropped if not recognized.
> >>
> >>        Type   Meaning                            Reference
> >>        ----   -------                            ---------
> >>        TBD1   Reply Mode Order TLV               this document
> >>
> >> What is it that I miss?
> >
> > Nothing serious.  My initial thought was to echo Adrian, that, at least
> > in this context, there should be an indication what to do if a MUST or
> > SHOULD was violated without just then having a clear sense of what it
> > should be instead.
> >
> > The I-D did require (MUST) one entry in the TLV and wanted (SHOULD)
> > more.  Adding what to do if that did not happen I was seeing as
> > clarification.  I then read Nobo as proposing going a bit further saying
> > requires (MUST) one or more.  Which might lead to boxes taking a
> > simplistic approach and always putting in the new TLV with a single
> > entry and ignoring the traditional TLV.  Not a problem just a change
> > from what others might think that they have consented to.
> >
> > On the question of what to do when the rules are violated, again I did
> > not initially think of what the action should be.  On reflection, I am
> > still unsure.  I understand that the Reply Mode Order TLV  is optional
> > and so can be ignored when not understood; that's fine.  But if it is
> > understood and can be seen to be defective, should the box with that
> > knowledge discard just that TLV and accept the remainder of the message?
> > Or should it argue that if this TLV is defective, then likely the rest
> > is as well and should be ignored?  I am unsure.
> >
> > If there is scope for a breach of security, or taking a hit in
> > performance, then ignore is the right policy. If the requirement is to
> > get as much data as possible from a failing network, then use it is the
> > right policy.  As long as the I-D is clear, I am not too fussed which
> > way it goes.  I am content with the changes that Nobo has proposed.
> >
> > Tom Petch
> >
> >> /Loa
> >>
> >> --
> >>
> >>
> >> Loa Andersson                        email: [e-mail]
> >> Senior MPLS Expert                          [e-mail]
> >> Huawei Technologies (consultant)     phone: [phone]
> >
> 
> --
> 
> 
> Loa Andersson                        email: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Huawei Technologies (consultant)     phone: [phone]
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls