Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 1 Jul 2014 16:08:08 +0000

I have reviewed the draft and believe it is ready for WG adoption consideration.

I do have one suggestion - could we allow multiple return paths to be specified via multiple "Replay Mode 5" in the new "Reply Mode Order TLV" and multiple Reply Path TLVs (currently it is not allowed).

Thanks.
Jeffrey
      _____________________________________________
      From: Ross Callon
      Sent: Tuesday, June 17, 2014 4:52 PM
      To: Jeffrey (Zhaohui) Zhang; Aissaoui, Mustapha (Mustapha); [email-masked]
      Cc: [email-masked]; [email-masked]; Martin Vigoureux
      Subject: MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02

      Jeff, Mustapha, Jeremy;

      You have been selected as MPLS Review team reviewers for draft-akiya-mpls-lsp-ping-reply-mode-simple-02.

      Note to authors: You have been CC'd on this email so that you can know that this review is going on. However, please do not review your own document. Also please don't update the draft while the reviews are in progress (we would like the reviewers to all review the same version).

      Reviews should comment on whether the document is coherent, is it useful (ie, is it likely to be actually useful in operational networks), and is the document technically sound?  Also, is the text and grammar understandable (it doesn't need to be perfect at this point, but should be reasonably clear). We are interested in knowing whether the document is ready to be considered for WG adoption (ie, it doesn't have to be perfect at this point, but should be a good start).

      Reviews should be sent to the document authors, WG co-chairs and WG secretary, and CC'd to the MPLS WG email list. If necessary, Comments may be sent privately to only the WG chairs.

      Are you able to review this draft by July 2, 2014?

      Thanks, Ross
      (as MPLS WG chair)

---

From: "Whittaker, Jeremy M" <[email-masked]>
Date: Tue, 1 Jul 2014 12:41:38 -0400

I have also reviewed this draft, and in my opinion it is coherent and useful.

One additional suggestion is that the reverse LSP sections (3.1 and 6.1) might benefit from more explanation of the LSP types included or not included.  Nevertheless, I would recommend it move forward as well.

Regards,
Jeremy Whittaker

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Tuesday, July 01, 2014 11:08 AM
To: Ross Callon; Aissaoui, Mustapha (Mustapha); Whittaker, Jeremy M; Harish Sitaraman; Kapil Arora
Cc: [email-masked]; [email-masked]; Martin Vigoureux; [email-masked]
Subject: RE: MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02

Thanks.
Jeffrey
_____________________________________________
From: Ross Callon
Sent: Tuesday, June 17, 2014 4:52 PM
To: Jeffrey (Zhaohui) Zhang; Aissaoui, Mustapha (Mustapha); [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Martin Vigoureux
Subject: MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02

Jeff, Mustapha, Jeremy;

Thanks, Ross
(as MPLS WG chair)

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 2 Jul 2014 00:58:02 +0000

Hi Jeffrey,

Thank you for reviewing this document.

> I do have one suggestion - could we allow multiple return paths to be
> specified via multiple "Replay Mode 5" in the new "Reply Mode Order TLV"
> and multiple Reply Path TLVs (currently it is not allowed).

Interesting, I do find what you suggested to be useful. I went back to RFC7110 and read up on the Reply Path TLV definition. The TLV can contain zero, one or more FECs.

   Reply Path:  It is used to describe the return path that an echo
      reply will be send along.  It is variable in length and can
      contain zero, one or more Target FEC sub-TLVs [RFC4379].  

So it appears that "Reply Mode 5" can be one of the entries in the "Reply Mode Order TLV", and "Reply Path TLV" can contain multiple FECs.

(1) What is possible as is:
  Pref#1: Reply Mode 4    Reply via application level control channel
  Pref#2a: Reply Mode 5    Reply via Specified Path -> First FEC listed
  Pref#2b: Reply Mode 5    Reply via Specified Path -> Second FEC listed
  Pref#3: Reply Mode 2    Reply via an IPv4/IPv6 UDP packet

(2) What is not possible as is:
  Pref#1: Reply Mode 4    Reply via application level control channel
  Pref#2: Reply Mode 5    Reply via Specified Path -> First FEC listed
  Pref#3: Reply Mode 2    Reply via an IPv4/IPv6 UDP packet
  Pref#4: Reply Mode 5    Reply via Specified Path -> Second FEC listed

Granularity of really mixing up Reply Modes and return FECs like (2) cannot be accomplished, but I'm not sure if we need such granularity and I believe (1) is reasonable. If you are ok with this, then I think it's worth adding texts to describe this usages. Do let us know you preference.

Thanks!

-Nobo

> -----Original Message-----
> From: mpls [mailto:[email-masked]] On Behalf Of Jeffrey (Zhaohui)
> Zhang
> Sent: Tuesday, July 01, 2014 12:08 PM
> To: Ross Callon; Aissaoui, Mustapha (Mustapha);
> [email-masked]; Harish Sitaraman; Kapil Arora
> Cc: [email-masked]; [email-masked]; draft-akiya-mpls-lsp-ping-
> [email-masked]
> Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-
> mode-simple-02
> 
> I do have one suggestion - could we allow multiple return paths to be
> specified via multiple "Replay Mode 5" in the new "Reply Mode Order TLV"
> and multiple Reply Path TLVs (currently it is not allowed).
> 
> Thanks.
> Jeffrey
> Note to authors: You have been CC'd on this email so that you can know that
> this review is going on. However, please do not review your own document.
> Also please don't update the draft while the reviews are in progress (we
> would like the reviewers to all review the same version).
> 
> Reviews should comment on whether the document is coherent, is it useful
> (ie, is it likely to be actually useful in operational networks), and is the
> document technically sound?  Also, is the text and grammar understandable
> (it doesn't need to be perfect at this point, but should be reasonably clear).
> We are interested in knowing whether the document is ready to be
> considered for WG adoption (ie, it doesn't have to be perfect at this point,
> but should be a good start).
> 
> Reviews should be sent to the document authors, WG co-chairs and WG
> secretary, and CC'd to the MPLS WG email list. If necessary, Comments may
> be sent privately to only the WG chairs.
>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 2 Jul 2014 01:31:12 +0000

Hi Jeremy,

> One additional suggestion is that the reverse LSP sections (3.1 and 6.1)
> might benefit from more explanation of the LSP types included or not
> included.  Nevertheless, I would recommend it move forward as well.

Agree, that will improve the readability of this document. We certain do not want to list LSPs restrict the term "reverse LSP" to be applicable only for them, but we will list associated RSVP LSPs and TP LSPs as examples. Would this be ok with you?

Thanks!

-Nobo

> From: Whittaker, Jeremy M [mailto:[email-masked]]
> Sent: Tuesday, July 01, 2014 12:42 PM
> To: Jeffrey (Zhaohui) Zhang; Ross Callon; Aissaoui, Mustapha (Mustapha);
> Harish Sitaraman; Kapil Arora
> Cc: [email-masked]; mpls-
> [email-masked]; Martin Vigoureux; [email-masked]
> One additional suggestion is that the reverse LSP sections (3.1 and 6.1)
> might benefit from more explanation of the LSP types included or not
> included.  Nevertheless, I would recommend it move forward as well.
> 
> Regards,
> Jeremy Whittaker
> 
> Cc: [email-masked]; mpls-
> [email-masked]; Martin Vigoureux; [email-masked]

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Thu, 3 Jul 2014 22:47:57 +0000

Dear all,
I was asked to review this draft and I think it describes valid issues to be resolved. I however have a couple of comments about the way the authors went about to address them.

1.    Relation to RFC 7110 - Return Path Specified Label Switched Path (LSP) Ping.

Section 4.1 argues the reason why a separate reply mode is needed is for wanting to omit the Reply Path TLV defined in RFC 7110 when the sender of the echo request just wanted to use the return path of the tested LSP. I do not see this as a strong justification. In many cases, the LSP is unidirectional or the responder node is a transit LSR and may not be able to inject the reply in the reverse direction of that LSP. In that case, I can see that providing a specific return LSP which is different than the tested LSP is required and the Reply Path TLV is needed.

Assuming this is still an important issue for the authors, I would suggest to relax the rule in RFC 7110 such that if the echo request includes reply mode 5 "Reply via Specified Path" and the Reply Path TLV is not included, the responder node will interpret this as an implicit request to reply via the reverse direction of the tested LSP.

2.    Reply Mode Order TLV

I am not convinced of the need for this TLV. There is not much reply modes which are usable today together. Only reply mode 2 can be concurrently used with reply mode 5 in RFC 7110 or reply mode 4. Reply mode 3 is not very popular as far as I know. Also, most applications would reply with mode 2 if the requested mode is not available. So, I can't see how this new TLV will be useful in practice.

Regards,
Mustapha.

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 3 Jul 2014 16:16:16 -0700

Authors,

I too raised the below points highlighted by Mustapha, earlier. In addition I have a more high-level question.

In the Introduction it says 
"However, it is becoming increasingly difficult for an initiator to
   select a valid return path to encode in the MPLS LSP echo request
   packets.  If the initiator does not select a valid return path, the
   MPLS LSP echo reply will not get back to the initiator.  This results
   in a false failure of MPLS LSP Ping and Traceroute operation.  In an
   effort to minimize such false failures, different implementations
   have chosen different default return path encoding for different LSP
   types and LSP operations.  The problem with implementations having
   different default return path encoding is that the MPLS echo reply
   will not work in many cases, and the default value may not be the
   preferred choice by the operators.
"

The problems I have is regarding the need for this ID are
1. Can we solve the problem without the need for this ID/solution? 
Answer is yes, albeit it takes one or more requests. If you say, it is solving a problem which was couldn’t be solved earlier, I would like to see.
2. The proposal still cannot identify the problem even with multiple reply modes. If reply cannot be received, adding more reply types may not solve the issue.
3. This proposed solution works only if the problem is on the replying node. But if the problem is on the transit node of the reply path, this solution will not work either.
4. As I mentioned earlier, for this new proposal to work effectively, the responding device has to support this new TLV. Which means, whole of the network has to support at one point of time of the other.
5. With the proposed solution, to determine the problem, one also needs to read the ‘reply mode’ used by the replying device. IOW, return code + reply mode used will actually define the behavior. This changes the definition of RFC4379. 
6. Specific to the text above, I do not agree that the problem is due to implementation. It is the user choice which ever reply mode he/she wants to use. If using CLI, could chose different reply mode. If it is application, he/she could select it there. 

The point is, why to introduce this optimization solution, where one could solve the problem without any of this new upgrade?
Alternatively, for ex: If the reply was being received with reply mode ‘5, but now I don’t receive it now, send a new request with reply mode 1. 
This is more simple than the proposed solution without needing any change.
I’d be open to hearing the strong reason, this ID is solving, which couldn’t be solved with RFC4379.

cheers
-sam

On Jul 3, 2014, at 3:47 PM, Aissaoui, Mustapha (Mustapha) <[email-masked]> wrote:

> Assuming this is still an important issue for the authors, I would suggest to relax the rule in RFC 7110 such that if the echo request includes reply mode 5 “Reply via Specified Path” and the Reply Path TLV is not included, the responder node will interpret this as an implicit request to reply via the reverse direction of the tested LSP.
>  
> 2.    Reply Mode Order TLV
> I am not convinced of the need for this TLV. There is not much reply modes which are usable today together. Only reply mode 2 can be concurrently used with reply mode 5 in RFC 7110 or reply mode 4. Reply mode 3 is not very popular as far as I know. Also, most applications would reply with mode 2 if the requested mode is not available. So, I can’t see how this new TLV will be useful in practice.
>  
> Regards,
> Mustapha.
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 4 Jul 2014 00:56:04 +0000

Hello Mustapha,

Thank you for reviewing this document!

Let me provide my individual reply (not speaking for all the authors).

> From: Aissaoui, Mustapha (Mustapha) [mailto:mustapha.aissaoui@alcatel-
> lucent.com]
> Sent: Thursday, July 03, 2014 6:48 PM
> To: [email-masked]
> [email-masked]; VIGOUREUX, MARTIN (MARTIN); Aissaoui, Mustapha
> (Mustapha); Ross Callon; Jeffrey (Zhaohui) Zhang;
> [email-masked]
> I was asked to review this draft and I think it describes valid issues to be
> resolved. I however have a couple of comments about the way the authors
> went about to address them.
> 
> Section 4.1 argues the reason why a separate reply mode is needed is for
> wanting to omit the Reply Path TLV defined in RFC 7110 when the sender of
> the echo request just wanted to use the return path of the tested LSP. I do
> not see this as a strong justification. In many cases, the LSP is unidirectional
> or the responder node is a transit LSR and may not be able to inject the reply
> in the reverse direction of that LSP. In that case, I can see that providing a
> specific return LSP which is different than the tested LSP is required and the
> Reply Path TLV is needed.
> 
> Assuming this is still an important issue for the authors, I would suggest to
> relax the rule in RFC 7110 such that if the echo request includes reply mode
> 5 "Reply via Specified Path" and the Reply Path TLV is not included, the
> responder node will interpret this as an implicit request to reply via the
> reverse direction of the tested LSP.

If that's more desired by the WG, I have no objection to that as long as it doesn't require a TLV to indicate reverse LSP :)

> 
> 2. Reply Mode Order TLV
> I am not convinced of the need for this TLV. There is not much reply modes
> which are usable today together. Only reply mode 2 can be concurrently
> used with reply mode 5 in RFC 7110 or reply mode 4. Reply mode 3 is not
> very popular as far as I know. Also, most applications would reply with
> mode 2 if the requested mode is not available. So, I can't see how this new
> TLV will be useful in practice.

You are absolutely correct, not all combinations of the reply modes in the Reply Mode TLV is realistic.

      Value    Meaning
      -----    -------
          1    Do not reply
          2    Reply via an IPv4/IPv6 UDP packet
          3    Reply via an IPv4/IPv6 UDP packet with Router Alert
          4    Reply via application level control channel
          5    Reply via Specified Path 
          6    Reply via reverse LSP 

Ping is simple, but let's talk about traceroute.

I can imagine following example usage:

(1) User prefers IP return path:

If (LSP_w_reverse_LSP) {
    ReplyModeTLV{2, 6}
} else if (LSP_w_control_channel) {
    ReplyModeTLV{2, 4}
} else {
    ReplyMode{2}
}

(2) User does not prefer IP return path:

If (LSP_w_reverse_LSP) {
    ReplyModeTLV{6, 2}
} else if (LSP_w_control_channel) {
    ReplyModeTLV{4, 2}
} else {
    ReplyMode{2}
}

Or user can specify a preference to be used for all LSP types (those who wants to make sure response is received back one way or another).

(3) User prefers IP return path:

If (all_LSP_types) {
    ReplyModeTLV{2, 6, 4}
} else {
    ReplyMode{2}
}

(4) User does not prefer IP return path:

If (all_LSP_types) {
    ReplyModeTLV{4, 6, 2}
} else {
    ReplyMode{2}
}

I hope this answers your comments/concerns a bit :)

Thanks!

-Nobo

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 4 Jul 2014 01:25:49 +0000

Hi again Sam :)

Please see in-line.

> From: mpls [mailto:[email-masked]] On Behalf Of Sam Aldrin
> Sent: Thursday, July 03, 2014 7:16 PM
> To: Aissaoui, Mustapha (Mustapha)
> Cc: [email-masked]; Jeffrey (Zhaohui) Zhang; draft-akiya-mpls-lsp-ping-reply-
> [email-masked]; Ross Callon; [email-masked];
> The problems I have is regarding the need for this ID are 1. Can we solve the
> problem without the need for this ID/solution? Answer is yes, albeit it takes
> one or more requests. If you say, it is solving a problem which was couldn't
> be solved earlier, I would like to see.

The problem can be addressed with vendors iterating the operation with multiple Return Paths when the previous try didn't work. And exact behavior being well document and operators fully understanding potentially different behavior per LSP types, per ping/trace operation type and deviating behaviors across multiple vendors/products. If you implement this, with user preference knob (yes some prefers IP return path while other do not prefer IP return path), imagine yourself trying to explain to users how things work, and imagine yourself trying to explain why vendors/products behave differently. I sure wouldn't want to :) It's indeed not a problem that cannot be solved, but it's an aspect of LSP Ping/Trace that can be simplified in terms of implementations and especially operations!

> 2. The proposal still cannot identify the problem even with multiple reply
> modes. If reply cannot be received, adding more reply types may not solve
> the issue.

That is not what the document is trying to achieve.

> 3. This proposed solution works only if the problem is on the replying node.
> But if the problem is on the transit node of the reply path, this solution will
> not work either.

Again, that is not what the document is trying to achieve.

> 4. As I mentioned earlier, for this new proposal to work effectively, the
> responding device has to support this new TLV. Which means, whole of the
> network has to support at one point of time of the other.

Correct, those transit LSRs not understanding this procedure will simply use the Reply Mode field in the MPLS echo request.

> 5. With the proposed solution, to determine the problem, one also needs to
> read the 'reply mode' used by the replying device. IOW, return code + reply
> mode used will actually define the behavior. This changes the definition of
> RFC4379. 6. Specific to the text above, I do not agree that the problem is due
> to implementation. It is the user choice which ever reply mode he/she
> wants to use. If using CLI, could chose different reply mode. If it is
> application, he/she could select it there.

User prefers control channel for operations on TP tunnels.

traceroute mpls ... [default reply mode 4 used]

Timeout
Timeout
Timeout
Timeout
...
Success

Operator: What the heck!

<20 minutes later>

Operator: Oh man, there is no problem! This is tunnel 100 and is not 200, it's not co-routed!

Just an example :)

If possible (and yes it is), the tool should provide better experience to users.

> 
> The point is, why to introduce this optimization solution, where one could
> solve the problem without any of this new upgrade?

Well, this is my 3rd or 4th attempt to convince you on this topic, so I'll skip this question :)

> Alternatively, for ex: If the reply was being received with reply mode '5, but
> now I don't receive it now, send a new request with reply mode 1. This is
> more simple than the proposed solution without needing any change.
> I'd be open to hearing the strong reason, this ID is solving, which couldn't be
> solved with RFC4379.

Why would you send reply mode 1 (Do no reply) if reply mode 5 (Reply via Specified Path) starts timing out? That sounds a very silly, but maybe I'm missing something.

Thanks!

-Nobo
 
> 
> cheers
> -sam
> 
> 
> On Jul 3, 2014, at 3:47 PM, Aissaoui, Mustapha (Mustapha)
> <[email-masked]> wrote:
> 
> 
> Dear all,

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 3 Jul 2014 19:32:50 -0700

Hi Nobo,

thanks again :D
Inline for my comments.
On Jul 3, 2014, at 6:25 PM, Nobo Akiya (nobo) <[email-masked]> wrote:

> The problem can be addressed with vendors iterating the operation with multiple Return Paths when the previous try didn't work.
> And exact behavior being well document and operators fully understanding potentially different behavior per LSP types, per ping/trace operation type and deviating behaviors across multiple vendors/products. If you implement this, with user preference knob (yes some prefers IP return path while other do not prefer IP return path), imagine yourself trying to explain to users how things work, and imagine yourself trying to explain why vendors/products behave differently. I sure wouldn't want to :) It's indeed not a problem that cannot be solved, but it's an aspect of LSP Ping/Trace that can be simplified in terms of implementations and especially operations!
%sam - You say it didn’t work. Could you provide info why it didn’t work? In the last sentence you say it simplifies. So does it simplify or is it fixing something which was not working earlier?
LSP ping itself is full of knobs and it has to be explained. You could find that in every vendors documentation and it is nothing knew. I know it because I have authored much of the documentation.
> That is not what the document is trying to achieve.
%sam - ok. we agree.
> Again, that is not what the document is trying to achieve.
%sam - so, we agree that this enhancement is for replying node only.
> Correct, those transit LSRs not understanding this procedure will simply use the Reply Mode field in the MPLS echo request.
%sam - nod.
> If possible (and yes it is), the tool should provide better experience to users.
Here is a counter example and response to your example, below.

traceroute mpls …[new tlv - reply mode 5, 2] /* reply mode 5 or 4, I am just illustrating with 5 here */

success
success
success
success

1hr later, oh shoot, return path is broken but I am getting success because replies are in the ip path and not on reverse LSP.

this is much more harmful than not receiving reply.

And to your example, few very important points I’d like to make
1. getting a timeout is not an issue, when lsp ping command is incorrectly issued. Infact it is correct. No one can set that right, when user issues wrong command.
2. What I fail to understand is, how does your proposed solution make it right? Just because you get the reply all is well? what if the return path is indeed broken (as illustrated in my example above), you will not be able to infer something is wrong, (strictly interpreting RFC4379) because return code received is ‘3/8/5/6’. 
3. Specific to your example, when you perform trace on non-corouted TP tunnels, timeout SHOULD be returned when there is no return lsp for in band reply from p1 and p2, because the return path chosen is ‘reply mode 4’. In order to give ‘better experience’ what command will you issue and how different the o/p will be, assuming there is no ip on intermediate nodes.(p1, p2,p3,p4) Sample topology below

               /————P1——P2———\
PE1———                                         PE2
              \————P3——P4--——-/

PE1->PE2 lsp is via p1, p2
PE2->PE1 lsp is via p4,p3
> Well, this is my 3rd or 4th attempt to convince you on this topic, so I'll skip this question :)
%sam - That is fine. Point remains though :D
> Why would you send reply mode 1 (Do no reply) if reply mode 5 (Reply via Specified Path) starts timing out? That sounds a very silly, but maybe I'm missing something.
typo. Meant to say reply mode 2.

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Fri, 4 Jul 2014 16:39:52 +0000

Hi Nobo,
Regarding the combinations of reply modes, my point is that usually type 2 is treated as the default mode which the responder node will usually attempt if say type 4 or type 5 were requested in the echo request message but were not available. What would be a use case where you want to prefer type 2 over types 4 or 5? I would have thought the latter being very specific return paths, the user would first try them and in case they are not available then resort to type 2. Not the other way around.

Also, do you have a use case for requesting types 4 and 5 together for the same target FEC stack? I would have thought these not to be compatible. For example, type 4 could be the return path of the tested PW but the responder node would not normally use type 5 and send the reply to the VCC ping using some other LSP.

Mustapha.

> From: Nobo Akiya (nobo) [mailto:[email-masked]]
> Sent: Thursday, July 03, 2014 8:56 PM
> To: Aissaoui, Mustapha (Mustapha); [email-masked]
> [email-masked]; VIGOUREUX, MARTIN (MARTIN); Ross Callon; Jeffrey
> (Zhaohui) Zhang; [email-masked]
> > I was asked to review this draft and I think it describes valid issues
> > to be resolved. I however have a couple of comments about the way the
> > authors went about to address them.
> >
> > Section 4.1 argues the reason why a separate reply mode is needed is
> > for wanting to omit the Reply Path TLV defined in RFC 7110 when the
> > sender of the echo request just wanted to use the return path of the
> > tested LSP. I do not see this as a strong justification. In many
> > cases, the LSP is unidirectional or the responder node is a transit
> > LSR and may not be able to inject the reply in the reverse direction
> > of that LSP. In that case, I can see that providing a specific return
> > LSP which is different than the tested LSP is required and the Reply Path TLV is
> needed.
> >
> > Assuming this is still an important issue for the authors, I would
> > suggest to relax the rule in RFC 7110 such that if the echo request
> > includes reply mode
> > 5 "Reply via Specified Path" and the Reply Path TLV is not included,
> > the responder node will interpret this as an implicit request to reply
> > via the reverse direction of the tested LSP.
> 
> > I am not convinced of the need for this TLV. There is not much reply
> > modes which are usable today together. Only reply mode 2 can be
> > concurrently used with reply mode 5 in RFC 7110 or reply mode 4. Reply
> > mode 3 is not very popular as far as I know. Also, most applications
> > would reply with mode 2 if the requested mode is not available. So, I
> > can't see how this new TLV will be useful in practice.
> 
> Or user can specify a preference to be used for all LSP types (those who wants to
> make sure response is received back one way or another).
>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 4 Jul 2014 17:21:26 +0000

Hi Mustapha,

> Sent: Friday, July 04, 2014 12:40 PM
> To: Nobo Akiya (nobo); [email-masked]
> Regarding the combinations of reply modes, my point is that usually type 2
> is treated as the default mode which the responder node will usually
> attempt if say type 4 or type 5 were requested in the echo request message
> but were not available.

LSP ping/trace is design such that behavior is strictly controlled by the initiator. I'd say any behavior which the responder does not comply to the instruction in received MPLS echo request and starts to decide its own behavior on reply contents or how to reply is a bad idea.

> What would be a use case where you want to prefer
> type 2 over types 4 or 5?
> I would have thought the latter being very specific
> return paths, the user would first try them and in case they are not available
> then resort to type 2. Not the other way around.

Ask operators :)

There are some operators who prefer (2 > (4 or 5)) and there are some operators who prefer ((4 or 5) > 2).

This is exactly one of the items which lead the authors to coming up with this document.

> 
> Also, do you have a use case for requesting types 4 and 5 together for the
> same target FEC stack? I would have thought these not to be compatible. For
> example, type 4 could be the return path of the tested PW but the
> responder node would not normally use type 5 and send the reply to the
> VCC ping using some other LSP.

Correct. Whether 4 or 5 can be used is LSP dependant, meaning the tool or user have to know that. For those users who are only concerned about ping/trace succeeding in the forward path, users can configure (5, 4, 2) (or whatever) and tools can default to that for all LSP types, ping or trace or ping w/ specific TTL.

Thanks!

-Nobo

> > Subject: RE: MPLS-RT review of
> > draft-akiya-mpls-lsp-ping-reply-mode-simple-02
> >
> > Hello Mustapha,
> >
> > > Cc: [email-masked];
> > > mpls- [email-masked]; VIGOUREUX, MARTIN (MARTIN); Aissaoui,
> > > Mustapha (Mustapha); Ross Callon; Jeffrey (Zhaohui) Zhang;
> > > I was asked to review this draft and I think it describes valid
> > > issues to be resolved. I however have a couple of comments about the
> > > way the authors went about to address them.
> > >
> > > of that LSP. In that case, I can see that providing a specific
> > > return LSP which is different than the tested LSP is required and
> > > the Reply Path TLV is
> > needed.
> > >
> > > the responder node will interpret this as an implicit request to
> > > reply via the reverse direction of the tested LSP.
> >
> > If that's more desired by the WG, I have no objection to that as long
> > as it doesn't require a TLV to indicate reverse LSP :)
> >
> > >
> > > 2. Reply Mode Order TLV
> > > concurrently used with reply mode 5 in RFC 7110 or reply mode 4.
> > > Reply mode 3 is not very popular as far as I know. Also, most
> > > applications would reply with mode 2 if the requested mode is not
> > > available. So, I can't see how this new TLV will be useful in practice.
> >
> > Or user can specify a preference to be used for all LSP types (those
> > who wants to make sure response is received back one way or another).
> >

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 4 Jul 2014 18:12:32 +0000

Hi Sam,

> The problem can be addressed with vendors iterating the operation with
> multiple Return Paths when the previous try didn't work.
> And exact behavior being well document and operators fully understanding
> potentially different behavior per LSP types, per ping/trace operation type
> and deviating behaviors across multiple vendors/products. If you
> implement this, with user preference knob (yes some prefers IP return path
> while other do not prefer IP return path), imagine yourself trying to explain
> to users how things work, and imagine yourself trying to explain why
> vendors/products behave differently. I sure wouldn't want to :) It's indeed
> not a problem that cannot be solved, but it's an aspect of LSP Ping/Trace that
> can be simplified in terms of implementations and especially operations!
> %sam - You say it didn't work. Could you provide info why it didn't work? In
> the last sentence you say it simplifies. So does it simplify or is it fixing
> something which was not working earlier?

Perhaps the right thing to say is, it doesn't work with one MPLS echo request message today. Sure the initiating device can, automatically or user initiated, issue 2 or 3 MPLS echo request to the same target, cycling through list of Reply Modes. With the change, it now works with one MPLS echo request message, and it is simplified because you only need one MPLS echo request vs. few that you needed before.

> LSP ping itself is full of knobs and it has to be explained. You could find that
> in every vendors documentation and it is nothing knew. I know it because I
> have authored much of the documentation.

Yup, I am well aware of that Sam, and which is why this discussion is so worth the effort!
I am hoping, one of these replies, I'll get a message saying "yes this is a reasonable extension" :)

> traceroute mpls .[new tlv - reply mode 5, 2] /* reply mode 5 or 4, I am just
> illustrating with 5 here */
> 
> success
> success
> success
> success
> 
> 1hr later, oh shoot, return path is broken but I am getting success because
> replies are in the ip path and not on reverse LSP.
> 

No no no, the output should be:

success [Reply Mode: IPv4 UDP]
success [Reply Mode: IPv4 UDP]
success [Reply Mode: IPv4 UDP]
success [Reply Mode: application level control channel]

So that it's obvious to users that what is working and what is not working.

Maybe not exactly in that output format, but you get the idea.

And with that, there is absolutely no harm, rather you are providing much more information back to the user than what is available today.

Not to mention the command will finish right away instead of waiting [timeout] from every LSR.

Imagine if this was an application running the command, do you really want the application to take 5 seconds or few tens of milliseconds? And do you want the application to run the same command again to get the information which would've been possible to get in the first try?

> 
> And to your example, few very important points I'd like to make
> 1. getting a timeout is not an issue, when lsp ping command is incorrectly
> issued. Infact it is correct. No one can set that right, when user issues wrong
> command.

How "timeout" contributes to the usability has been answered above.

> 2. What I fail to understand is, how does your proposed solution make it
> right? Just because you get the reply all is well? what if the return path is
> indeed broken (as illustrated in my example above), you will not be able to
> infer something is wrong, (strictly interpreting RFC4379) because return
> code received is '3/8/5/6'.

Ok this one is already answered above as well.

> 3. Specific to your example, when you perform trace on non-corouted TP
> tunnels, timeout SHOULD be returned when there is no return lsp for in
> band reply from p1 and p2, because the return path chosen is 'reply mode 4'.
> In order to give 'better experience' what command will you issue and how
> different the o/p will be, assuming there is no ip on intermediate nodes.(p1,
> p2,p3,p4) Sample topology below

No, it's not the timeout that user is interested in seeing.

If control channel is preferred:
- responder uses the control channel. If timeout is seen with this, then that's a good thing (as you indicated, and I fully agree).
- if there is no control channel at the responder node, then that should be notified by the responder to the initiator via alternate path (instead of just timing out).

>                /----P1--P2---\
> PE1---                                         PE2
>               \----P3--P4-----/

If you are saying don't introduce extension to improve the tool because there's a way to do the same even if that's inefficient, then there isn't much more I can say. However, I do believe in a good extension if inefficiency can be made efficient.

> Why would you send reply mode 1 (Do no reply) if reply mode 5 (Reply via
> Specified Path) starts timing out? That sounds a very silly, but maybe I'm
> missing something.

Ah lol.

Thanks!

-Nobo

---

From: Sam Aldrin <[email-masked]>
Date: Sat, 5 Jul 2014 00:21:04 -0700

Hi Nobo,

Thank you for the reply.
Please find my replies inline.

> Perhaps the right thing to say is, it doesn't work with one MPLS echo request message today. Sure the initiating device can, automatically or user initiated, issue 2 or 3 MPLS echo request to the s…
As you can see, my argument, just like every other argument made at IETF is, why one more extra option, when it already works, albeit with extra request. Also this requires all nodes to be upgraded to supported to fully functional as you describe. The extra cost is not worth it, when you could achieve the same with small cost in workflow but no upgrade or protocol/TLV change.
> I am hoping, one of these replies, I'll get a message saying "yes this is a reasonable extension" :)
My anticipation is that we need not make this one more addition when there is no real need and hope WG agrees with me :D
Reason is, I feel is, cost outweigh any benefit it brings. More details in the below responses.
> Imagine if this was an application running the command, do you really want the application to take 5 seconds or few tens of milliseconds? And do you want the application to run the same command aga…
Usually, when ping fails, trace is used. Trace is not really used like ping as it causes lot of extra traffic. and with network running with huge number of LSP’s and load balanced paths, trace is performed to further diagnosed when ping fails.
Having said that, two things we need to see.
1. What are the LSP types it will be really useful to have multiple reply modes at the same time.
Resp> At present, TP and PW are only LSP’s which are bidirectional . 
With PW VCCV, you cannot do trace for intermediate nodes anyway. So, trace is not an option. 
With TP, one could have IP enabled and non-ip enabled P routers With non-IP enabled, you can only use reply mode 5(or 4, not sure what diff vendors implemented). IOW, you cannot use reply mode 3 or 2.
So, that leaves with TP LSP’s with IP enabled P routers. And within that, this is really useful only if the LSP’s are non-corouted. 
Let me know if which other LSP’s missed out here.

2. 
For the above trace example, in order for the output to receive ‘success' from all hops, you need to have all devices supporting this TLV. 
Let us take this, you send the this new TLV with reply modes [5,2], if you receive all timeouts, what do you conclude? in-band reply mode is broken + IP path also broken OR nodes do not support this TLV?

> - if there is no control channel at the responder node, then that should be notified by the responder to the initiator via alternate path (instead of just timing out).
Solution is there and very simple.
If there is IP reply path and no control channel as you say, just use reply mode 2 for Trace and  use reply mode ‘4’ for Ping.
Why is that a problem?

If I am missing something here, could you clarify with real lsp example and how this TLV is solving that existing solution is not able to, will clarify things better.
 
> If you are saying don't introduce extension to improve the tool because there's a way to do the same even if that's inefficient, then there isn't much more I can say. However, I do believe in a goo…
That is where I disagree. what you say is efficient, is not true, because of the cost this solution for this to work and that too only for a corner case lsp type.
We could debate this point, but I doubt we could converge on the efficiency part.
It is like the debate, more vs less. :D

cheers
-sam

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sun, 6 Jul 2014 13:03:56 +0000

Hi Sam,

Let me cut most of our discussions, and try to bring this to closure.
If you feel that we should continue our discussion, feel free to revive them.

> As you can see, my argument, just like every other argument made at IETF is,
> why one more extra option, when it already works, albeit with extra
> request. Also this requires all nodes to be upgraded to supported to fully
> functional as you describe. The extra cost is not worth it, when you could
> achieve the same with small cost in workflow but no upgrade or
> protocol/TLV change.

I agree that it is important to ask "why is this required". And this is where we seem to have different scale to measure (at least this for this one).

As for this extension, it's not just "extra request" that I'm concerned about, but they are:

1. Extra request = more system/network resources.
2. Users/tools requiring to put up with timeout from many LSRs = bad usability.
3. Users/tools requiring to know which Reply Mode timed out and what to use next = bad usability.
4. Every product/vendor having [more] vastly different behavior = bad usability.

So to me, it's worth the effort to do something about it. If above results in "not worth it" on your scale, then that's that. We can conclude that our scales are different, but that's IETF :)

As always, thanks for the discussions Sam.
Despite the fact we couldn't converge, I do appreciate your time and effort.

Thanks!

-Nobo

---

From: Sam Aldrin <[email-masked]>
Date: Sun, 6 Jul 2014 13:14:11 -0700

Hi Nobo,

Not sure if the email you send was with reply mode 1 or with new TLV :D. 
Sending my response as top post. :D

I do not think we could converge on efficiency or which is bad/good, neither would I like to debate about bad usability.

My previous questions remain unanswered. Will leave it to you and co-authors, whether to respond or not.
As far as my concerns regarding the ID is concerned, would be good to illustrate with example lsp's, be it TP or LDP or something else, it is solving. And quantifying the solution to show it really is required that existing solutions could not solve it, would help WG.

At this point of time, I could not change my conclusion. Sorry.

-sam

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sun, 6 Jul 2014 20:21:22 +0000

Hi Sam,

> Not sure if the email you send was with reply mode 1 or with new TLV :D.

It was actually a Reply Mode Order TLV containing [new TLV, reply mode 1], so you did the right thing :)

> As far as my concerns regarding the ID is concerned, would be good to
> illustrate with example lsp's, be it TP or LDP or something else, it is solving.
> And quantifying the solution to show it really is required that existing
> solutions could not solve it, would help WG.

That will indeed be a good addition to this document. We will add texts for this in the next revision.

Thanks!

-Nobo

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 7 Jul 2014 12:59:36 +0000

Nobo,

Sorry for the late response. Holidays.

I am not sure if it is necessary to have the flexibility of (2), but it is always good to have the flexibility if it does not introduce much complexity. If we allow multiple mode 5, then (2) is achieved.

I'll leave this up to you.

Jeffrey

> Sent: Tuesday, July 01, 2014 8:58 PM
> Cc: [email-masked]; [email-masked]; draft-akiya-mpls-lsp-
> [email-masked]
> Subject: RE: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-
> mode-simple-02
> 
> Hi Jeffrey,
> 
> Interesting, I do find what you suggested to be useful. I went back to
> RFC7110 and read up on the Reply Path TLV definition. The TLV can
> contain zero, one or more FECs.
> 
> So it appears that "Reply Mode 5" can be one of the entries in the
> "Reply Mode Order TLV", and "Reply Path TLV" can contain multiple FECs.
> 
> Granularity of really mixing up Reply Modes and return FECs like (2)
> cannot be accomplished, but I'm not sure if we need such granularity and
> I believe (1) is reasonable. If you are ok with this, then I think it's
> worth adding texts to describe this usages. Do let us know you
> preference.
> 
> Thanks!
> 
> -Nobo
> 
> 
> > [email-masked]; Martin Vigoureux
> > Subject: MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-
> simple-
> > 02
> >
> >
> > Jeff, Mustapha, Jeremy;
> >

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Mon, 7 Jul 2014 23:01:16 +0000

Hi Jeffrey,

Please see in-line.

> Sent: Monday, July 07, 2014 9:00 AM
> To: Nobo Akiya (nobo); Ross Callon; Aissaoui, Mustapha (Mustapha);

No problem, and thanks for getting back!

> 
> I am not sure if it is necessary to have the flexibility of (2), but it is always
> good to have the flexibility if it does not introduce much complexity. If we
> allow multiple mode 5, then (2) is achieved.
> 

I believe (1) strikes the right balance between flexibility vs. complexity. I will add some text describing this usage.

Thanks!

-Nobo
 
> > To: Jeffrey (Zhaohui) Zhang; Ross Callon; Aissaoui, Mustapha
> > (Mustapha); [email-masked]; Harish Sitaraman; Kapil
> > Arora
> > > I do have one suggestion - could we allow multiple return paths to
> > > be specified via multiple "Replay Mode 5" in the new "Reply Mode
> > > Order
> > TLV"
> > cannot be accomplished, but I'm not sure if we need such granularity
> > and I believe (1) is reasonable. If you are ok with this, then I think
> > it's worth adding texts to describe this usages. Do let us know you
> > preference.
> >
> > Thanks!
> >
> > -Nobo
> >
> >
> > > I do have one suggestion - could we allow multiple return paths to
> > > be specified via multiple "Replay Mode 5" in the new "Reply Mode
> > > Order
> > TLV"
> > > mpls- [email-masked]; Martin Vigoureux
> > > You have been selected as MPLS Review team reviewers for
> > > draft-akiya- mpls-lsp-ping-reply-mode-simple-02.
> > >
> > > Note to authors: You have been CC'd on this email so that you can
> > > know
> > that
> > > (ie, is it likely to be actually useful in operational networks),
> > > and
> > is the
> > > (it doesn't need to be perfect at this point, but should be
> > > reasonably
> > clear).
> > > considered for WG adoption (ie, it doesn't have to be perfect at
> > > this
> > point,
> > > secretary, and CC'd to the MPLS WG email list. If necessary,
> > > Comments
> > may