Subject: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02

From: Ross Callon <[email-masked]>
Date: Wed, 20 Aug 2014 15:20:54 +0000

This is to start a two week poll on adopting draft-akiya-mpls-lsp-ping-reply-mode-simple-02
as an MPLS working group document.

Please send your comments (support/not support) to the mpls working group
mailing list ([email-masked]).

This poll will end Thursday September 4, 2014.

Thanks, Ross

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 21 Aug 2014 01:24:44 +0000

Hi Ross, MPLS WG,

I understand that my "support" as co-authors of this document does not count towards this WG adoption poll, but I'd like to use this opportunity to say that:

(1) This document allows encoding of multiple Reply Modes in MPLS Echo Request.
(2) While (1) may be a trivial extension, significant benefit is that this extension can eliminate virtually all instances of LSP Ping/Traceroute "timeout" due to responder not having the only one Reply Mode specified.
(3) While (2) may just be a "would be nice" when LSP Ping/Traceroute is executed manually, avoiding "timeout" when executing LSP Ping/Traceroute from applications/scripts is a great benefit.

Due to above, I believe this document describes an useful extension that improves usability of the LSP Ping/Traceroute tool by users/applications/scripts.

Thanks!

-Nobo

> -----Original Message-----
> From: mpls [mailto:[email-masked]] On Behalf Of Ross Callon
> Sent: Wednesday, August 20, 2014 11:21 AM
> To: [email-masked]
> Cc: [email-masked]'
> Subject: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-
> simple-02
> 
> Please send your comments (support/not support) to the mpls working
> group mailing list ([email-masked]).
>

---

From: Sam Aldrin <[email-masked]>
Date: Wed, 20 Aug 2014 19:53:17 -0700

Hi Ross, et al,

I have discussed over the mailing alias why I do not support this draft in the current form.
<http://www.ietf.org/mail-archive/web/mpls/current/msg12403.html>
Authors and I could not converge to agreed conclusion.

Here are things I would like to see in the draft 

1. Provide an example with specific type of LSP and FEC type where is useful and also why existing RFC’s couldn’t solve it.
2. Details on how this draft will reduce ‘false failures’, given that every device has to support these new TLV’s.

As it was discussed in detail already over the mailing list, need to see the benefits for these extensions.
My point is, if problem is solved already with existing mechanisms, there is no need to solve with different method. We use that argument many times in the WG/IETF.
But if it is indeed solving something which couldn’t be solved thus far (I haven’t seen it yet), you will have my support.

cheers
-sam

On Aug 20, 2014, at 8:20 AM, Ross Callon <[email-masked]> wrote:

> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 21 Aug 2014 20:43:12 +0000

Hi Sam,

>> 1. Provide an example with specific type of LSP and FEC type where is useful and also why existing RFC's couldn't solve it.

The title of this WG adoption poll may have created some confusion. The latest version of this document is -03.

http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-reply-mode-simple-03

The latest version has Appendix A which was added as result of your comments.

>> 2. Details on how this draft will reduce 'false failures', given that every device has to support these new TLV's.

The extension itself is backwards compatible (i.e. adds an optional TLV), but benefit can obviously be achieved when corresponding LSRs support the extension. If there are one or more LSRs not supporting this extension, then it is no worse than today.

Thanks!

-Nobo

From: mpls [mailto:[email-masked]] On Behalf Of Sam Aldrin
Sent: Wednesday, August 20, 2014 10:53 PM
To: Ross Callon
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02

Hi Ross, et al,

1. Provide an example with specific type of LSP and FEC type where is useful and also why existing RFC's couldn't solve it.
2. Details on how this draft will reduce 'false failures', given that every device has to support these new TLV's.

As it was discussed in detail already over the mailing list, need to see the benefits for these extensions.
My point is, if problem is solved already with existing mechanisms, there is no need to solve with different method. We use that argument many times in the WG/IETF.
But if it is indeed solving something which couldn't be solved thus far (I haven't seen it yet), you will have my support.

cheers
-sam

On Aug 20, 2014, at 8:20 AM, Ross Callon <[email-masked]<mailto:[email-masked]>> wrote:

Please send your comments (support/not support) to the mpls working group
mailing list ([email-masked]<mailto:[email-masked]>).

Thanks, Ross

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: Ross Callon <[email-masked]>
Date: Thu, 21 Aug 2014 21:25:56 +0000

Oops, my apology. Yes, the poll for adoption is on version -03.

Thanks, Ross

From: Nobo Akiya (nobo) [mailto:[email-masked]]
Sent: Thursday, August 21, 2014 4:43 PM
To: Sam Aldrin; Ross Callon
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02

Hi Sam,

Thanks!

-Nobo

From: mpls [mailto:[email-masked]] On Behalf Of Sam Aldrin
Sent: Wednesday, August 20, 2014 10:53 PM
To: Ross Callon
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02

Hi Ross, et al,

cheers
-sam

Thanks, Ross

---

From: "Sam K. Aldrin" <[email-masked]>
Date: Thu, 21 Aug 2014 18:24:25 -0700

Hi Nobo,

Inline for my comments.

> The latest version has Appendix A which was added as result of your comments.
Yes, I am looking at the v03 itself.:D. The appendix doesn't mention which FEC type.
The only FEC type this extension will be helpful is MPLS TP with IP available on every node.
There are no other LSP's or FEC types which fits this scenario. Do they?

Let us take the MPLS TP with IP on every node.
The scenario you are talking about is 'associated bidirectional' tunnel.
Just because a 'vendor' implemented certain default method doesn't require new TLV support.
For associated bidirectional tunnel with IP on every node, perform reply mode as IP.
I don't think RFC4379 warrants certain default type to be fixed type for a given FEC.

I will also look at this way. When there is no reverse lsp available on a given node, performing LSP ping with reply mode as reverse lsp is not considered an issue. Rather it is user who chose wrong reply mode (or vendor provided wrong default option). LSP ping as such provides option to chose which reply mode to use. 

> The extension itself is backwards compatible (i.e. adds an optional TLV), but benefit can obviously be achieved when corresponding LSRs support the extension. If there are one or more LSRs not supp…
Then why to introduce new TLV, as it could be solved without it and by using right reply mode. :D

-sam

---

From: Loa Andersson <[email-masked]>
Date: Fri, 22 Aug 2014 12:34:02 +0200

Nobo,

> I understand that my "support" as co-authors of this document does not count towards this WG adoption poll, but I'd like to use this opportunity to say that:

I think that what wg chairs says that a support mail from co-authors
is redundant - co-authors are understood to support adoption of a
document simply because they co-authors.

However, mail like yours that gives background and arguments are always
welcome, authors does not to keep silent in wglc.

On the other hand supportive mail that only says "support" is a bit
hard to deal with for working group chairs, that is because we are
not just counting, we need to know what people think. Mails that only
says "+1" are in the same category (or maybe worse).
Mails sent to adoption poll should ideally be based on document review
and contain some motivation for why there is support or non-support
making a document a wg document.

/Loa

PS

I'm also a co-author of this document, and it should be quite obvious
that I support making it a wg document.
-- 

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

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sun, 24 Aug 2014 14:08:36 +0000

Hi Sam,

Please see in-line with [NOBO].

From: Sam K. Aldrin [mailto:[email-masked]]
Sent: Thursday, August 21, 2014 9:24 PM
To: Nobo Akiya (nobo)
Cc: Ross Callon; [email-masked]; [email-masked]
Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02

Hi Nobo,

Inline for my comments.

Hi Sam,

[NOBO] MPLS TP and associated RSVP-TE for sure. The reason why Appendix A is generally described is that we will likely have more LSPs down the road. One example will be associated SPRING LSPs where only the end-points have the state for the reverse LSP.

[NOBO] What you say is true only if all operators prefer IP return path over control channel and reverse LSP. I am aware of operators who wants to prefer control channel or reverse LSP whenever available, over IP path. The preference really varies depending on operators. This is exactly where this extension can benefit.

[NOBO] Ping is much simpler than traceroute. Take a look at Appendix A.1. In normal conditions, traceroute will work just fine with Reply Mode control channel or reverse LSP, except when there's an error. Then there will be a timeout and user/application will have to debug/re-try. If the extension described in this document was there, there is no timeout and user/application can immediately know where the breakage is.

[NOBO] It is ideal to design a diagnostic tool to not have "timeout" but rather get the response with a diagnostic reason. LSP Ping/Traceroute is a great diagnostic tool, but we are not using it enough IMHO. I, for one, think network monitoring can significantly benefit if we have an application that uses LSP Ping/Trace along with other OAM tools. And ever better if "timeout" (of seconds) can be avoided.

Despite the fact that we are still going on a parallel path, I do still appreciate you reviewing the document ... your comments have helped this document into much better shape.

Thanks!

-Nobo

-sam

Thanks!

-Nobo

Hi Ross, et al,

cheers
-sam

Thanks, Ross

---

From: "Sam K. Aldrin" <[email-masked]>
Date: Mon, 25 Aug 2014 16:07:22 -0700

Hi Nobo,

Thanks for the reply. See my replies inline with %sam. Will keep it brief.

> [NOBO] MPLS TP and associated RSVP-TE for sure. The reason why Appendix A is generally described is that we will likely have more LSPs down the road. One example will be associated SPRING LSPs wher…
%sam - RSVP-TE is still unidirectional LSP. For reverse direction it is different LSP altogether. W.r.t. SPRING, Unless you want to discuss LSP ping for SPRING here (I believe there exists a draft) do not want to further that.
> [NOBO] What you say is true only if all operators prefer IP return path over control channel and reverse LSP. I am aware of operators who wants to prefer control channel or reverse LSP whenever ava…
%sam - We discussed this before but ended up with opposite conclusion :D. If user want to perform return path via lsp or via IP, nothing prevents and one could chose either of them. The same goes for bitmap size, selector size etc.

> [NOBO] Ping is much simpler than traceroute. Take a look at Appendix A.1. In normal conditions, traceroute will work just fine with Reply Mode control channel or reverse LSP, except when there’s an error. Then there will be a timeout and user/application will have to debug/re-try. If the extension described in this document was there, there is no timeout and user/application can immediately know where the breakage is.
%sam - Again, this is more of an implementation of workflow. Traceroute is heavyweight and is performed only when needed or very infrequently. Ping is performed regularly to detect MPLS failures. Infact, in one of the vendor's implementation (I do not want to name :D), trace route is performed only after 3 successive failures, performed rapidly. One could perform single traceroute or two trace routes simultaneously with different reply modes. In the case of MPLS TP, BFD is actually used for failure detection, and lsp ping is used sparingly.

The point I am making is, the problem is not with the existing function/specification or how fast one could not detect, rather how the workflow could be implemented and achieve the same or better result, without implementing any changes. Fundamentally where I disagree is, why solve when there is solution already.
> [NOBO] It is ideal to design a diagnostic tool to not have “timeout” but rather get the response with a diagnostic reason. LSP Ping/Traceroute is a great diagnostic tool, but we are not using it enough IMHO. I, for one, think network monitoring can significantly benefit if we have an application that uses LSP Ping/Trace along with other OAM tools. And ever better if “timeout” (of seconds) can be avoided.
%sam - Having designed, deployed and trained how to use LSP ping/traceroute, I beg to differ that it is not used effectively. I can safely say, the same scenarios you are saying could be done or already being done, without this enhancement.
>  
> Despite the fact that we are still going on a parallel path, I do still appreciate you reviewing the document … your comments have helped this document into much better shape.
%sam - I am very happy to hear that and will continue to provide useful comments :D

-sam

---

From: Mach Chen <[email-masked]>
Date: Sat, 30 Aug 2014 03:32:33 +0000

Hi Sam,

Some replies inline...

Sniped.

> [NOBO] What you say is true only if all operators prefer IP return path over
> control channel and reverse LSP. I am aware of operators who wants to prefer
> control channel or reverse LSP whenever available, over IP path. The preference
> really varies depending on operators. This is exactly where this extension can
> benefit.
> %sam - We discussed this before but ended up with opposite conclusion :D. If
> user want to perform return path via lsp or via IP, nothing prevents and one could
> chose either of them. The same goes for bitmap size, selector size etc.

Your assumption is that all nodes along the path support both IP and LSP return path, this may not always true.  In some mobile backhaul networks that normally have access and core network parts, the nodes in the access may only support pure MPLS-TP and not support IP forwarding; the nodes in the core part normally support IP/MPLS. Then takes the picture in A.2 as an example:

                             +----C------D----+
                           /                                   \
  A'----A------B                                   G---H---H'
                           \                                  /
                            +----E------F----+

Where A', A, H and H' only support pure MPLS-TP and do not support IP forwarding, B and G support both LSP and IP return path, it means that reply mode 2 cannot be used when perform traceroute. But when  "Reply via reverse LSP" is used, since  C, D, E and F may not have reverse LSP path but have IP return path, it still cannot traceroute the whole path. In this case, actually, any single reply mode cannot satisfy the requirement. 

The essential of the Reply Mode Order TLV is to allow multiple reply modes to be used for a specific LSP, and each responder can select its appropriate reply mode to return the echo reply.

Best regards,
Mach

---

From: Sam Aldrin <[email-masked]>
Date: Sat, 30 Aug 2014 01:32:50 -0700

Hi Mach,

Inline for my brief comments

> Where A', A, H and H' only support pure MPLS-TP and do not support IP forwarding, B and G support both LSP and IP return path, it means that reply mode 2 cannot be used when perform traceroute. But…
Neither does this new TLV will help, nor mandating IP reply mode only trace is what I am advocating.
Head end do not know which nodes support IP or which don't. 
For the same topology, If C,D,E and F do not support IP, this new TLV is not going to help you either.
Solution cannot be topology specific, where the initiator do not know what the topology is or will be.
What you have is a solution, trying to find a problem.

As I said in my earlier emails, performing IP and reply via LSP trace simultaneously could achieve the same result, for mixed mode (some nodes do not support IP) topology. Performance or diagnosing is not an issue as Timeout value, ttl value etc are all configurable and 4379 does not mandate what those values should be.

> The essential of the Reply Mode Order TLV is to allow multiple reply modes to be used for a specific LSP, and each responder can select its appropriate reply mode to return the echo reply.
You could achieve that without the need for new TLV and upgrade of the network.

cheers
-sam

---

From: Mach Chen <[email-masked]>
Date: Sat, 30 Aug 2014 09:40:05 +0000

Hi Sam,

Thanks for your prompt response!

Please see my reply inline...

> From: Sam Aldrin [mailto:[email-masked]]
> Sent: Saturday, August 30, 2014 4:33 PM
> To: Mach Chen
> Cc: Nobo Akiya (nobo); Ross Callon; [email-masked]; [email-masked]
> Subject: Re: [mpls] Poll for Adoption
> draft-akiya-mpls-lsp-ping-reply-mode-simple-02
> 
> Hi Mach,
> 
> >> [NOBO] What you say is true only if all operators prefer IP return
> >> path over control channel and reverse LSP. I am aware of operators
> >> who wants to prefer control channel or reverse LSP whenever
> >> available, over IP path. The preference really varies depending on
> >> operators. This is exactly where this extension can benefit.
> >> %sam - We discussed this before but ended up with opposite conclusion
> >> :D. If user want to perform return path via lsp or via IP, nothing
> >> prevents and one could chose either of them. The same goes for bitmap size,
> selector size etc.
> >
> > Your assumption is that all nodes along the path support both IP and LSP return
> path, this may not always true.  In some mobile backhaul networks that
> normally have access and core network parts, the nodes in the access may only
> support pure MPLS-TP and not support IP forwarding; the nodes in the core part
> normally support IP/MPLS. Then takes the picture in A.2 as an example:
> >
> >                             +----C------D----+
> >                           /                                   \
> > Where A', A, H and H' only support pure MPLS-TP and do not support IP
> forwarding, B and G support both LSP and IP return path, it means that reply
> mode 2 cannot be used when perform traceroute. But when  "Reply via reverse
> LSP" is used, since  C, D, E and F may not have reverse LSP path but have IP
> return path, it still cannot traceroute the whole path. In this case, actually, any
> single reply mode cannot satisfy the requirement.

No, it can help only if C, D, E and F know how to handle the Reply Mode TLV. For your case, if C does not support IP, but it should support at least one other reply mode and then use that mode to send back the echo reply. 

> What you have is a solution, trying to find a problem.

The above scenario is a very typical MBB scenario that deploys pure MPLS-TP in access and reuse the IP/MPLS for core network. And even if operators know (and normally they do) the topologies, they cannot depend on the existing mechanisms to trace the path for reason that a single reply mode cannot apply to an LSP that across nodes support different modes.

> 
> As I said in my earlier emails, performing IP and reply via LSP trace simultaneously
> could achieve the same result, for mixed mode (some nodes do not support IP)
> topology. 

Given the above example, since A', A, H and H' only support pure MPLS forwarding and do not support IP forwarding, you cannot perform IP and rely via LSP trace simultaneously. Because when you reply mode 2 (IP path) to perform trace, the echo request will be dropped at A and will not have chance to reach to other nodes. Similarly, if you use reply via LSP, C,D, E and F will not find a reverse path.

Thanks,
Mach

> Performance or diagnosing is not an issue as Timeout value, ttl value
> etc are all configurable and 4379 does not mandate what those values should be.
> 
> 
> >
> > The essential of the Reply Mode Order TLV is to allow multiple reply modes to
> be used for a specific LSP, and each responder can select its appropriate reply
> mode to return the echo reply.

---

From: Mach Chen <[email-masked]>
Date: Sat, 30 Aug 2014 10:00:28 +0000

Hi Sam,

> > As I said in my earlier emails, performing IP and reply via LSP trace
> > simultaneously could achieve the same result, for mixed mode (some
> > nodes do not support IP) topology.
> 
> Given the above example, since A', A, H and H' only support pure MPLS
> forwarding and do not support IP forwarding, you cannot perform IP and rely via
> LSP trace simultaneously. Because when you reply mode 2 (IP path) to perform
> trace, the echo request will be dropped at A and will not have chance to reach to
> other nodes. 

Here I mean the nodes that do not support IP path will not correctly return the echo reply.

Best regards,
Mach

> From: Mach Chen
> Sent: Saturday, August 30, 2014 5:40 PM
> To: 'Sam Aldrin'
> Subject: RE: [mpls] Poll for Adoption
> > >> %sam - We discussed this before but ended up with opposite
> > >> conclusion :D. If user want to perform return path via lsp or via
> > >> IP, nothing prevents and one could chose either of them. The same
> > >> goes for bitmap size,
> > selector size etc.
> > >
> > normally have access and core network parts, the nodes in the access
> > may only support pure MPLS-TP and not support IP forwarding; the nodes
> > in the core part normally support IP/MPLS. Then takes the picture in A.2 as an
> example:
> > >
> > >                             +----C------D----+
> > >                           /                                   \
> > forwarding, B and G support both LSP and IP return path, it means that
> > reply mode 2 cannot be used when perform traceroute. But when  "Reply
> > via reverse LSP" is used, since  C, D, E and F may not have reverse
> > LSP path but have IP return path, it still cannot traceroute the whole
> > path. In this case, actually, any single reply mode cannot satisfy the
> requirement.
> No, it can help only if C, D, E and F know how to handle the Reply Mode TLV. For
> your case, if C does not support IP, but it should support at least one other reply
> mode and then use that mode to send back the echo reply.
> 
> The above scenario is a very typical MBB scenario that deploys pure MPLS-TP in
> access and reuse the IP/MPLS for core network. And even if operators know (and
> normally they do) the topologies, they cannot depend on the existing
> mechanisms to trace the path for reason that a single reply mode cannot apply to
> an LSP that across nodes support different modes.
> 
> >
> > As I said in my earlier emails, performing IP and reply via LSP trace
> > simultaneously could achieve the same result, for mixed mode (some
> > nodes do not support IP) topology.
> 
> Given the above example, since A', A, H and H' only support pure MPLS
> forwarding and do not support IP forwarding, you cannot perform IP and rely via
> LSP trace simultaneously. Because when you reply mode 2 (IP path) to perform
> trace, the echo request will be dropped at A and will not have chance to reach to
> other nodes. Similarly, if you use reply via LSP, C,D, E and F will not find a reverse
> path.
> 
> 
> Thanks,
> Mach
> 
> > be used for a specific LSP, and each responder can select its
> > appropriate reply mode to return the echo reply.

---

From: Sam Aldrin <[email-masked]>
Date: Sat, 30 Aug 2014 11:04:33 -0700

Hi Mach,

See inline.

> No, it can help only if C, D, E and F know how to handle the Reply Mode TLV. For your case, if C does not support IP, but it should support at least one other reply mode and then use that mode to s…
Please quote with real LSP example you are talking about and which other way and reply mode you are talking about.
Please refer to earlier emails, why I say that.

> The above scenario is a very typical MBB scenario that deploys pure MPLS-TP in access and reuse the IP/MPLS for core network. And even if operators know (and normally they do) the topologies, they…
I have deployed and helped networks operated and troubleshoot them, so I know what I am talking about.
Provided examples how one could make it work without the need. Also provided why this TLV cannot help in the so called mixed mode.
In your own example, if C, D, E and F do not support ‘IP’ (not just new TLV), your solution do not work.
> Given the above example, since A', A, H and H' only support pure MPLS forwarding and do not support IP forwarding, you cannot perform IP and rely via LSP trace simultaneously. Because when you repl…
Really? Then what is the purpose of TTL? Could you care to explain how the node drops a packet when TTL do not expire?

-sam

---

From: "Faisal Iqbal (faiqbal)" <[email-masked]>
Date: Sun, 31 Aug 2014 03:53:40 +0000

After closely following the lively debates among Nobo, Mach, and Sam, I believe that this document solves a very real problem. Simplifying Reply Mode via this draft will ease up on several implementation and deployment headaches, coming from different preferred reply modes for various LSP types.

I support this draft to be adopted as MPLS working group document.

Regards,
Faisal Iqbal

From: mpls [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Wednesday, August 20, 2014 11:21 AM
To: [email-masked]
Cc: [email-masked]'
Subject: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02

Thanks, Ross