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

Hi Sam,

Please see in-line with [NOBO].

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

Hi Nobo,

Inline for my comments.

On Aug 21, 2014, at 1:43 PM, Nobo Akiya (nobo) wrote:

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

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

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.

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

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.

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

>> 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.
Then why to introduce new TLV, as it could be solved without it and by using right reply mode. :D

[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

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

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 <rcallon@juniper.net<mailto:rcallon@juniper.net>> wrote:

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 (mpls@ietf.org<mailto:mpls@ietf.org>).

This poll will end Thursday September 4, 2014.

Thanks, Ross

_______________________________________________
mpls mailing list
mpls@ietf.org<mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls