Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01

From: Sam Aldrin <[email-masked]>
Date: Mon, 6 Apr 2015 13:15:32 -0700

Useful draft from operator perspective. Thank the authors for considering my comments. Support its last call.

Sam

Sent from my iPhone

> On Mar 20, 2015, at 7:03 AM, Ross Callon <[email-masked]> wrote:
> 
> Working Group,
>  
> This is to initiate a working group last call on draft-ietf-mpls-lsp-ping-reply-mode-simple-01.
> Because this WGLC will span the IETF in Dallas, it will be extended to three weeks.
>  
> Please send your comments to the mpls wg mailing list ([email-masked]).
>  
> There are no IPR disclosures against this document. All the authors have stated that they
> are not aware of any IPR that relates to this draft.
>  
> This working group last call ends Friday  April 10, 2015. 
>  
> Ross
> for the MPLS WG chairs
>  
>  
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 7 Apr 2015 21:57:34 +0100

Hi,
 
I have read the most recent revision of this document and have no objection to
the WG requesting its publication.
 
I have some comments that I think should be addressed before publication.
 
Thanks,
Adrian
 
I don't believe this document updates 4379. It certainly does not
explain how it updates 4379, and since 7110 did not update 4379, it
seems unlikely that this document does. However, if the authors feel that
it is intended to update 4379 (i.e., an implementation of 4379 will not
be complete without also including the function of this document, for 
example, there is a problem in 4379 that this document fixes) then the
document needs to explain what the update is and how 4379 implementations
are affected.
 
I *can* believe that this document updates 7110, but it needs to explain
it and (presumably) observe that 7110 is not complete without this
document. (Actually, section 3.1 has most of this text, but the
Introduction should make the clear linkage to the "update".)
 
---
 
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?)
 
---
                                                     
The last guidance in 3.2 is:
 
   8.  Reply Mode value 1 (Do not reply) SHOULD NOT be used in the Reply
       Mode Order TLV.
 
"SHOULD NOT" means "you can do it if you have good reason." Please can
you explain the good reason and how the receiver should interpret a 
"Do not reply" mode coming, say, third in a list of five modes.
 
---
 
The security considerations are hard to believe!
At the very least, 7110 makes some security observations that surely
apply here.
 
From: mpls [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: 20 March 2015 14:04
To: [email-masked]
Cc: Loa Andersson; [email-masked]
Subject: [mpls] working group last call for
draft-ietf-mpls-lsp-ping-reply-mode-simple-01
 
Working Group,
 
This is to initiate a working group last call on
draft-ietf-mpls-lsp-ping-reply-mode-simple-01.
Because this WGLC will span the IETF in Dallas, it will be extended to three
weeks. 

There are no IPR disclosures against this document. All the authors have stated
that they 
are not aware of any IPR that relates to this draft.

Ross
for the MPLS WG chairs

---

From: "Nobo Akiya" <[email-masked]>
Date: Sun, 12 Apr 2015 11:34:27 -0700

Hello Adrian,

Many thanks for your comments.

Please see in-line with [NOBO].

From: mpls [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: April-07-15 1:58 PM
To: 'Ross Callon'; [email-masked]
Cc: [email-masked]; 'Loa Andersson'
Subject: Re: [mpls] working group last call for
draft-ietf-mpls-lsp-ping-reply-mode-simple-01

Hi,

I have read the most recent revision of this document and have no objection
to the WG requesting its publication.

Thanks,

Adrian

are affected.

[NOBO] Let me discuss this one with authors and get back to you.

---

[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.

---

       Mode Order TLV.

[NOBO] Another good point. Here, we should replace the "SHOULD NOT" to "MUST
NOT" as exhausting all specified reply mode options implicitly means that
the responder does not have any path to reply and no message will be send
anyways.

---

apply here.

[NOBO] At the least, we will reference RFC7110 in the Security Consideration
section. Additionally, we'll see if there are any additional vulnerabilities
exposed by the changes and add those (if any).

Thanks!

-Nobo

From: mpls [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: 20 March 2015 14:04
To: [email-masked] <mailto:[email-masked]> 
Cc: Loa Andersson; [email-masked]
<mailto:[email-masked]> 
Subject: [mpls] working group last call for
draft-ietf-mpls-lsp-ping-reply-mode-simple-01

Working Group,

Please send your comments to the mpls wg mailing list ([email-masked]
<mailto:[email-masked]> ).

There are no IPR disclosures against this document. All the authors have
stated that they 

Ross

for the MPLS WG chairs

---

From: Ross Callon <[email-masked]>
Date: Mon, 13 Apr 2015 16:03:26 +0000

This working group last call has ended, with sufficient support and no opposition. There have however been a number of comments received. Thanks to everyone who took the time to review the draft and comment.

Authors, please update the draft in response to the comments. After this is done, I will submit the document for publication.

Thanks, Ross

From: mpls [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Friday, March 20, 2015 10:04 AM
To: [email-masked]
Cc: Loa Andersson; [email-masked]
Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01

Working Group,

Please send your comments to the mpls wg mailing list ([email-masked]<mailto:[email-masked]>).

Ross
for the MPLS WG chairs

---

From: Nobo Akiya <[email-masked]>
Date: Thu, 16 Apr 2015 10:06:27 -0700

Hi Ross,

Thank you for Shepherding this document.

We (authors) have posted the revision (-02) addressing all comments
received during the LC of this document (thanks to those who provided
comments!).

Thanks!

-Nobo, on behalf of authors

On Mon, Apr 13, 2015 at 9:03 AM, Ross Callon <[email-masked]> wrote:

>  This working group last call has ended, with sufficient support and no
> opposition. There have however been a number of comments received. Thanks
> to everyone who took the time to review the draft and comment.
>
>
>
> Authors, please update the draft in response to the comments. After this
> is done, I will submit the document for publication.
>
>
>
> Thanks, Ross
>
>
>
> *From:* mpls [mailto:[email-masked]] *On Behalf Of *Ross Callon
> *Sent:* Friday, March 20, 2015 10:04 AM
> *To:* [email-masked]
> *Cc:* Loa Andersson; [email-masked]
> *Subject:* [mpls] working group last call for

---

From: t.petch <[email-masked]>
Date: Thu, 16 Apr 2015 18:30:27 +0100

Nobo

I was struck by Adrian's comment which, if I understand correctly, was
what to do if a MUST or SHOULD is violated and as I see it, I am unclear
if this was addressed.

Thus 3.2 2) what should a recipient do when the echo reply does contain
a Reply Mode Order TLV ?

Or in 6), 'SHOULD contain at least two Reply Mode values' - when may
that SHOULD be violated and if it is, does that render the TLV not valid
as described in 4?

Tom Petch

----- Original Message -----
From: "Nobo Akiya" <[email-masked]>
To: "Ross Callon" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Thursday, April 16, 2015 6:06 PM
Subject: Re: [mpls] end of WGLC, RE: working group last call for
draft-ietf-mpls-lsp-ping-reply-mode-simple-01

> > Because this WGLC will span the IETF in Dallas, it will be extended
to
> > three weeks.

------------------------------------------------------------------------
--------

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 16 Apr 2015 19:10:06 +0100

Tom captures my point.

---

From: Nobo Akiya <[email-masked]>
Date: Sat, 18 Apr 2015 10:23:28 -0700

Hi Tom,

Although we have added this text after the list/bullet items in section 3.2:

   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.

You are right, it doesn't cover the case where a receiver (the
initiator LSR) receives an MPLS echo reply with a Reply Mode Order
TLV. Perhaps above text should be changed to:

   If an LSR receives a Reply Mode Order TLV which does not
   comply to the rules described above, then the LSR MUST
   ignore the Reply Mode Order TLV.

Will that address your first comment?

Regarding your second comment (3.2-6), is that really too ambiguous?
To me, that text translates to following implementations:

- When sending a Reply Mode Order TLV, 2 or more Reply Mode values
shall be present.

- When receiving a Reply Mode Order TLV, accept 1 or more Reply Mode values.

If you think the text really should be updated, then we can change (3.2-6):

[OLD]

   6.  Reply Mode Order TLV MUST contain at least one Reply Mode value,
       and SHOULD contain at least two Reply Mode values.

[NEW]

   6.  Reply Mode Order TLV MUST contain at least one Reply Mode value.

Thoughts?

Thanks!

-Nobo

---

From: t.petch <[email-masked]>
Date: Sun, 19 Apr 2015 10:07:23 +0100

Inline, and including Adrian in the reply since really I am piggybacking
on his comment.

Tom Petch

---- Original Message -----
From: "Nobo Akiya" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Ross Callon" <[email-masked]>; "mpls" <[email-masked]>;
<[email-masked]>;
<[email-masked]>
Sent: Saturday, April 18, 2015 6:23 PM

> Will that address your first comment?

<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>
> - When receiving a Reply Mode Order TLV, accept 1 or more Reply Mode
values.

<tp>

Again, that is a change of meaning to me.  SHALL, if not shall, is the
same as MUST while  'SHOULD', in our jargon, says there are reasons
(not) to do it and RFC commonly spell out such reasons for doing so.  So
the NEW text below is a change IMHO.  But again, I have no strong
feelings about it.

Tom Petch
</tp>

> > > >  This working group last call has ended, with sufficient support
and
> > no
> > > > opposition. There have however been a number of comments
received.
> > Thanks
> > > > Authors, please update the draft in response to the comments.
After
> > this
> > > > There are no IPR disclosures against this document. All the
authors
> > have

---

From: Nobo Akiya <[email-masked]>
Date: Sun, 19 Apr 2015 15:07:22 -0700

Hi Tom,

> difficult to know but don't feel strongly about that choice so will go

[NOBO] I see where you are coming from. We explicitly made the Reply Mode
Order TLV an optional TLV (i.e., requests code point from 32768-49161).
There are still many ways one can behave when a received optional TLV was
"bad", but let's not get into that with this thread. Instead, let me just
state that dropping just this optional TLV when the TLV is bad is not a
wrong behavior. We will respin the document to update the text to cover the
"initiator" side as well. Thanks for catching this!

> the NEW text below is a change IMHO.  But again, I have no strong
[NOBO] Ok, probably best to just say "MUST have at least one Reply Mode
value" (and remove the SHOULD portion of this bullet/item) to avoid any
confusion. We will update this document with this change.

Thanks!

-Nobo

---

From: Loa Andersson <[email-masked]>
Date: Wed, 22 Apr 2015 15:15:17 +0200

Tom,

>     difficult to know but don't feel strongly about that choice so will go

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 "cooment", 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?

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: t.petch <[email-masked]>
Date: Thu, 23 Apr 2015 12:02:33 +0100

---- Original Message -----
From: "Loa Andersson" <[email-masked]>
Sent: Wednesday, April 22, 2015 2:15 PM

>     type to be silently dropped if not recognized.

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

---

From: Loa Andersson <[email-masked]>
Date: Thu, 23 Apr 2015 14:59:03 +0200

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:
>> that is kind of essence of a "comment", right?
>>

--

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 24 Apr 2015 00:38:51 +0100

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:[email-masked]] On Behalf Of Loa Andersson
> Sent: 23 April 2015 13:59
> To: t.petch; Nobo Akiya
> Cc: Ross Callon; mpls; [email-masked];
draft-ietf-mpls-lsp-ping-reply-
> [email-masked]
> 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,
>

---

From: Nobo Akiya <[email-masked]>
Date: Fri, 24 Apr 2015 21:49:53 -0700

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 25 Apr 2015 17:17:43 +0100

Hi Nobo,
 
Let's come back to my original review comments.
 
> 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...

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:[email-masked]] 
Sent: 25 April 2015 05:50
To: [email-masked]
Cc: Loa Andersson; t.petch; Ross Callon; mpls; [email-masked]; [email-masked]
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

A

group
> >> Huawei Technologies (consultant)     phone: +46 739 81 21 64 <tel:%2B46%20739%2081%2021%2064> 
> >
>
> --
>
>
> Huawei Technologies (consultant)     phone: +46 739 81 21 64 <tel:%2B46%20739%2081%2021%2064> 
>

---

From: Nobo Akiya <[email-masked]>
Date: Sun, 26 Apr 2015 18:36:21 -0700

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.

   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.

   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.

   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.

[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.

   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 <[email-masked]> wrote:

> 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...
>
>
>
> 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."
>
> 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.
>
>
>
>
>
> The TLV is from the optional range. It can be ignored if it is not
> understood, and does not require to be included.
>
> *From:* Nobo Akiya [mailto:[email-masked]]
> *Sent:* 25 April 2015 05:50
> *To:* [email-masked]
> *Cc:* Loa Andersson; t.petch; Ross Callon; mpls;
> [email-masked];
> [email-masked]
> *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,
>
>
>

---

From: Loa Andersson <[email-masked]>
Date: Tue, 28 Apr 2015 14:48:19 +0200

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]
>
> On Sat, Apr 25, 2015 at 9:17 AM, Adrian Farrel <[email-masked]
> <mailto:[email-masked]>> 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...____
>
>     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:[email-masked]
>     <mailto:[email-masked]>]
>     *To:* [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>;
>     <mailto:[email-masked]>
>     *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.____
>
>     __ __
>
>     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.____
>
>     __ __
>
>     incorporating comments from Tom).____
>
>     __ __
>
>     Thanks!____
>
>     __ __
>
>     -Nobo____
>
>     __ __
>
>     On Thu, Apr 23, 2015 at 4:38 PM, Adrian Farrel <[email-masked]
>     <mailto:[email-masked]>> wrote:____
>
>     Thanks Loa,
>
>      > From: mpls [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Loa Andersson
>      > Cc: Ross Callon; mpls; [email-masked]
>     <mailto:[email-masked]>;
>      > [email-masked] <mailto:[email-masked]>
>      > > From: "Loa Andersson" <[email-masked] <mailto:[email-masked]>>
>      > >>>      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>
>      > >>
>      > >> Loa Andersson                        email:
>     [email-masked] <mailto:[email-masked]>
>      > >> Senior MPLS Expert [email-masked] <mailto:[email-masked]>
>     <tel:%2B46%20739%2081%2021%2064>
>      > >
>     >
>     > --
>     >
>     >
>     > Loa Andersson                        email:[email-masked] <mailto:[email-masked]>
>     > Senior MPLS [email-masked] <mailto:[email-masked]>
>     > Huawei Technologies (consultant)     phone:+46 739 81 21 64 <tel:%2B46%20739%2081%2021%2064>
>     >
>     >[email-masked] <mailto:[email-masked]>
>     >https://www.ietf.org/mailman/listinfo/mpls____
>
>     __ __
>
>

--

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 28 Apr 2015 14:59:16 +0100

I'm OK with what Nobo said.

A

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

---

From: t.petch <[email-masked]>
Date: Tue, 28 Apr 2015 18:55:16 +0100

Me too

Tom Petch

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

A

> >     > Mode Order TLV but not on what to do if a received TLV
deviates from
> the____
> >     > ignoring the TLV, ignoring the message. But presumably not
sending
> an____
> >     Personally I have no particular preference for where it is
nailed,
> >     but I don't
<mailto:[email-masked]>
> >      > Subject: [mpls] George can yu look at this - Re: end of WGLC,
RE:
> >     working
> >      > I wonder if the TLV should be assigned from the mandatory
range
> >     instead?
> >      > >>>      Yes but ... I think that it is a change of meaning.
Is is
> >      > > enough just
> >      > >> 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",
> >      > >> intentionally requested from a space where it can be
silently
> >     dropped
> >      > > 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
> >      > > entry and ignoring the traditional TLV.  Not a problem just
a
> >     change
> >      > > 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
> >      > > 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
> >     > Loa Andersson
email:[email-masked]
> <mailto:[email-masked]>