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

[t.petch <[e-mail]>]

Me too

Tom Petch


----- Original Message -----
From: "Adrian Farrel" <[e-mail]>
To: "'Loa Andersson'" <[e-mail]>; "'Nobo Akiya'"
<[e-mail]>
Cc: "'t.petch'" <[e-mail]>; "'Ross Callon'"
<[e-mail]>; "'mpls'" <[e-mail]>;
<[e-mail]>;
<[e-mail]>
Sent: Tuesday, April 28, 2015 2:59 PM


I'm OK with what Nobo said.

A

> -----Original Message-----
> From: Loa Andersson [mailto:[e-mail]]
> Sent: 28 April 2015 13:48
> To: Nobo Akiya; [e-mail]
> Cc: t.petch; Ross Callon; mpls; [e-mail];
draft-ietf-mpls-lsp-
> [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
>
> 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]
64
> >     <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]