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?

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. 

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

-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; 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> 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).
>  
> This poll will end Thursday September 4, 2014.
>  
> Thanks, Ross
>  
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls