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

[Loa Andersson <[e-mail]>]

Nobo,

I think this is fine.

Bullet 4 says what to do if the Reply Mode Order TLV is mal-formed.

Bullet 6-9 describe the mal-formednesses.

Is it "invalid" rather than "not valid"?

Tom and Adrian are you OK with this?

/Loa

On 2015-04-27 03:36, Nobo Akiya wrote:
> Hi Adrian,
>
> Many thanks for very helpful comments. I have carefully read your
> comments and made modifications to section 3.2 in my private copy.
>
> [OLD]
>
>     1.  The Reply Mode Order TLV MAY be included in MPLS echo request.
>
>     2.  The Reply Mode Order TLV MUST NOT be included in MPLS echo reply.
>
>     3.  The Reply Mode field of an MPLS echo request MUST be set to a
>         valid value even when supplying the Reply Mode Order TLV.  The
>         initiator LSR SHOULD set the Reply Mode field of MPLS echo
>         request to a value that corresponds to a return path which most
>         likely to be available, in case the responder LSR does not
>         understand the Reply Mode Order TLV.
>
>     4.  If a responder LSR understands the Reply Mode Order TLV but the
>         TLV is not valid (due to conditions described in the items 6, 8
>         and 9 immediately below), then the responder LSR MUST only use
>         the value described in the Reply Mode field of received MPLS echo
>         request.
>
>     5.  If a responder LSR understands the Reply Mode Order TLV and the
>         TLV is valid, then the responder LSR MUST consider the Reply Mode
>         values described in the TLV and MUST NOT use the value described
>         in the Reply Mode field of received MPLS echo request.  In other
>         words, a valid Reply Mode Order TLV overrides the value specified
>         in the Reply Mode field of received MPLS echo request.
>
>     6.  Reply Mode Order TLV MUST contain at least one Reply Mode value,
>         and SHOULD contain at least two Reply Mode values.
>
>     7.  A Reply Mode value, except for Reply Mode value 5 (Reply via
>         Specified Path), MUST NOT be repeated (i.e., MUST NOT appear
>         multiple times) in the Reply Mode Order TLV.
>
>     8.  The Reply Mode value 5 (Reply via Specified Path) MAY be included
>         more than once in the Reply Mode Order TLV.  However, in such
>         case a Reply Path TLV MUST be included for all instances of the
>         Reply Mode value 5 included in the Reply Mode Order TLV.  In
>         other words, 3 instances of the Reply Mode value 5 in the Reply
>         Mode Order TLV will require 3 instances of the Reply Path TLVs.
>
>     9.  The Reply Mode value 1 (Do not reply) MUST NOT be used in the
>         Reply Mode Order TLV.
>
>     If a responder LSR receives a Reply Mode Order TLV which does not
>     comply to the rules described above, then the responder LSR MUST
>     ignore the Reply Mode Order TLV.
>
>
> [NEW]
>
>     1.  The Reply Mode Order TLV MUST NOT be included in MPLS echo reply.
>         If the initiator LSR receives an MPLS echo reply with the Reply
>         Mode Order TLV, the initiator LSR MUST ignore the whole Reply
>         Mode Order TLV and MUST only use the value from the Reply Mode
>         field of the received MPLS echo reply.  It may be beneficial for
>         implementations to provide counters and/or loggings, with
>         appropriate log dampening, to record this error case.
>
>     2.  The Reply Mode Order TLV MAY be included in MPLS echo request.
>
>     3.  The Reply Mode field of an MPLS echo request MUST be set to a
>         valid value even when supplying the Reply Mode Order TLV.  The
>         initiator LSR SHOULD set the Reply Mode field of MPLS echo
>         request to a value that corresponds to a return path which most
>         likely to be available, in case the responder LSR does not
>         understand the Reply Mode Order TLV.
>
>     4.  If a responder LSR understands the Reply Mode Order TLV but the
>         TLV is not valid (due to conditions described in the items 6, 7,
>         8 and 9 immediately below), then the responder LSR MUST ignore
>         the whole Reply Mode Order TLV and MUST only use the value from
>         the Reply Mode field of the received MPLS echo request.  It may
>         be beneficial for implementations to provide counters and/or
>         loggings, with appropriate log dampening, to record this error
>         case.
>
>     5.  If a responder LSR understands the Reply Mode Order TLV and the
>         TLV is valid, then the responder LSR MUST consider the Reply Mode
>         values described in the TLV and MUST NOT use the value described
>         in the Reply Mode field of received MPLS echo request.  In other
>         words, a valid Reply Mode Order TLV overrides the value specified
>         in the Reply Mode field of received MPLS echo request.
>
>     6.  Reply Mode Order TLV MUST contain at least one Reply Mode value.
>
>     7.  A Reply Mode value, except for Reply Mode value 5 (Reply via
>         Specified Path), MUST NOT be repeated (i.e., MUST NOT appear
>         multiple times) in the Reply Mode Order TLV.
>
>     8.  The Reply Mode value 5 (Reply via Specified Path) MAY be included
>         more than once in the Reply Mode Order TLV.  However, in such
>         case a Reply Path TLV MUST be included for all instances of the
>         Reply Mode value 5 included in the Reply Mode Order TLV.  In
>         other words, 3 instances of the Reply Mode value 5 in the Reply
>         Mode Order TLV will require 3 instances of the Reply Path TLVs.
>
>     9.  The Reply Mode value 1 (Do not reply) MUST NOT be used in the
>         Reply Mode Order TLV.
>
>
> Thanks!
>
> -Nobo
>
>
> On Sat, Apr 25, 2015 at 9:17 AM, Adrian Farrel <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Hi Nobo,____
>
>     __ __
>
>     Let's come back to my original review comments.____
>
>     __ __
>
>     > Section 3.2 gives clear instructions and guidance on forming the Reply____
>
>     > Mode Order TLV but not on what to do if a received TLV deviates from the____
>
>     > MUST and MUST NOT instructions. Options might include ignoring errors,____
>
>     > ignoring the TLV, ignoring the message. But presumably not sending an____
>
>     > error response (because how would you know how to send it?)____
>
>     __ __
>
>     You responded:____
>
>     __ __
>
>     | [NOBO] That’s a good point. What the document really state is that
>     The____
>
>     | Reply Mode value 5 (Reply via Specified Path) MAY be repeated but
>     all ____
>
>     | other Reply Mode values MUST NOT be repeated. Will update the____
>
>     | document to make it clear.____
>
>     __ __
>
>     That's a fine thing to say, but doesn't answer my question about how
>     an implementation is supposed to behave when a received Reply Mode
>     Order TLV is "malformed".____
>
>     __ __
>
>     You posted draft-ietf-mpls-lsp-ping-reply-mode-simple-02. Section
>     3.2 swapped the order of points 4 and 5, and enhanced the text to
>     read...____
>
>     __ __
>
>     4.If a responder LSR understands the Reply Mode Order TLV but the____
>
>     TLV is not valid (due to conditions described in the items 6, 8____
>
>     and 9 immediately below), then the responder LSR MUST only use____
>
>     the value described in the Reply Mode field of received MPLS echo____
>
>     request.____
>
>     __ __
>
>     That seems to cover most bases. Good.____
>
>     It might also be helpful to say "...the responder LSR MUST silently
>     ignore the whole Reply Mode Order TLV and MUST only use the value
>     from the Reply Mode field of the received MPLS echo request."____
>
>     Saying this helps clarify the behavior.____
>
>     __ __
>
>     The only things I don't find covered are:____
>
>     __ __
>
>     a. how to handle a violation of the seventh point____
>
>     __ __
>
>     7.A Reply Mode value, except for Reply Mode value 5 (Reply via____
>
>     Specified Path), MUST NOT be repeated (i.e., MUST NOT appear____
>
>     multiple times) in the Reply Mode Order TLV.____
>
>     __ __
>
>     I think you can address this by adding "7" to the list of conditions
>     in point 4.____
>
>     __ __
>
>     b. how to handle a violation of the second point____
>
>     __ __
>
>     2. The Reply Mode Order TLV MUST NOT be included in MPLS echo reply.____
>
>     __ __
>
>     I think this will need additional text.____
>
>     __ __
>
>     I note that after the numbered bullets you also now have the
>     following text...____
>
>     __ __
>
>     If a responder LSR receives a Reply Mode Order TLV which does not____
>
>     comply to the rules described above, then the responder LSR MUST____
>
>     ignore the Reply Mode Order TLV.____
>
>     __ __
>
>     This is better than point 4 and covers everything.____
>
>     You might consider whether "ignore" means "silently ignore" or
>     whether you want to give advice about logging. It seems probable
>     that (because of the nature of ping) if you do suggest logging, you
>     also want to describe some form of thresholding or damping.____
>
>     __ __
>
>     __ __
>
>     To address Loa's concern...____
>
>     The TLV is from the optional range. It can be ignored if it is not
>     understood, and does not require to be included.____
>
>     Loa asserted that the document says that the TLV MUST be included,
>     but I don't find this in -02.____
>
>     Therefore, I think this is all fine.____
>
>     __ __
>
>     Adrian____
>
>     __ __
>
>     *From:*Nobo Akiya [mailto:[e-mail]
>     <mailto:[e-mail]>]
>     *Sent:* 25 April 2015 05:50
>     *To:* [e-mail] <mailto:[e-mail]>
>     *Cc:* Loa Andersson; t.petch; Ross Callon; mpls;
>     [e-mail] <mailto:[e-mail]>;
>     [e-mail]
>     <mailto:[e-mail]>
>     *Subject:* 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____
>
>     __ __
>
>     Hi Adrian, Tom, Loa,____
>
>     __ __
>
>     This extension is currently structured such that it allows for
>     backwards compatibility (i.e., transit LSR not supporting this
>     mechanism will not return "malformed request" ... because the TLV is
>     optional).____
>
>     __ __
>
>     The result is that this mechanism becomes a best effort mechanism,
>     and we will not get the full benefit until all LSRs along the LSP
>     (and other LSRs which could falsely receive the echo request)
>     implements this extension.____
>
>     __ __
>
>     One way to allow the initiator LSR to determine whether or not the
>     responder LSR understood this TLV, and still keeping the backwards
>     compatibility, is that we keep the Reply Mode Order TLV as an
>     optional TLV, but require (i.e., MUST) the responder LSR
>     understanding this TLV to include the Reply Mode Order TLV in the
>     echo reply, potentially with result of parsing/handling that TLV.____
>
>     __ __
>
>     However, that's probably not the path we want to go, as all (or
>     most) optional TLVs will have to do something similar (i.e., include
>     the same TLV in the echo reply). This will quickly result in echo
>     reply packet bloat ... we should prevent that as echo reply usually
>     tends to include more information (ILS, DSMAP/DDMAP per nexthop,
>     multipath Sub-TLVs per nexthop, etc).____
>
>     __ __
>
>     To me, the right way to solve this is to create a capability TLV
>     that mandates the reponder LSR to return which features it supports
>     in bitmaps or something very compact. But this can be done in a
>     separate effort/draft.____
>
>     __ __
>
>     In short, my preference for this document is to go as is (after
>     incorporating comments from Tom).____
>
>     __ __
>
>     Thanks!____
>
>     __ __
>
>     -Nobo____
>
>     __ __
>
>     On Thu, Apr 23, 2015 at 4:38 PM, Adrian Farrel <[e-mail]
>     <mailto:[e-mail]>> wrote:____
>
>     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]
>     <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]
>     <mailto:[e-mail]>;
>     draft-ietf-mpls-lsp-ping-reply-
>      > [e-mail] <mailto:[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] <mailto:[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] <mailto:[e-mail]>
>      > >> Senior MPLS Expert [e-mail] <mailto:[e-mail]>
>      > >> Huawei Technologies (consultant)     phone: [phone]
>     <tel:%2B46%20739%2081%2021%2064>
>      > >
>     >
>     > --
>     >
>     >
>     > Loa Andersson                        email:[e-mail] <mailto:[e-mail]>
>     > Senior MPLS [e-mail] <mailto:[e-mail]>
>     > Huawei Technologies (consultant)     phone:[phone] <tel:%2B46%20739%2081%2021%2064>
>     >
>     > _______________________________________________
>     > mpls mailing list
>     >[e-mail] <mailto:[e-mail]>
>     >https://www.ietf.org/mailman/listinfo/mpls____
>
>     __ __
>
>

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]