Re: [mpls] Comments on draft-ietf-mpls-return-path-specified-lsp-ping-12.txt

Hi Nobo,

Many thanks for your comments!

Please see my reply inline...

> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
> Nobo Akiya (nobo)
> Sent: Thursday, August 15, 2013 6:10 AM
> To: draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org
> Cc: mpls@ietf.org
> Subject: [mpls] Comments on
> draft-ietf-mpls-return-path-specified-lsp-ping-12.txt
> 
> 
> Dear Authors, et al,
> 
> Draft adds new reply mode (5 - Reply via Specified Path) which looks to provide
> initiator great control on return path. Draft considers bidirectional LSP, and allows
> specifying of reverse LSP in a new TLV, but ... for bidirectional LSP ping, having
> reply mode to indicate reverse LSP would appear to take care of large majority of
> use, and there'll be no need to encode/decode additional TLV. Is there any
> reason why reply mode to specify reverse LSP is not added?

The draft uses the "reply mode 5 + B bit" to achieve this, using a reply mode to indicate the reverse LSP is an alternate way, we considered this and it also works. The reason not using dedicated reply mode is that we don't want to define too many reply modes, indicating reverse LSP is kind of specifying reply path and using the same reply mode seems reasonable. 

>From the implementation point of view, IMHO, the two ways have not too much differences, from the operation point of view, there should be no difference. 

> 
> And reply path TLV allows for initiator to specify a particular return path, but
> allows responder to choose different path if initiator specified one cannot be
> accommodated. This aspect is very interesting. Reason being that specifying of
> the "right" reply mode in echo request seems to be getting more and more
> complicated these days.
> 
> For example, bidirectional LSP with some transit nodes non-co-routed:
>     - ping:
>         * IP reply mode works
>         * Reverse LSP reply mode works
>     - ping with TTL terminating on mid:
>         * IP reply mode works
>         * Reverse LSP reply mode may or may not work
>     - traceroute:
>         * IP reply mode works
>         * Reverse LSP reply mode may or may not work
> 
> In above cases, what I would like to specify in most cases is to say "take reverse
> LSP as return path if available, otherwise take IP return path". Yes reply path TLV
> allows this, but I'm thinking if this can be done in a simpler way.

As you said, the reply path TLV allows this. In addition, to localize the failure point, sometime it may need to specify an explicit reply path other than the reverse path and IP return path, that is the main reason why we introduce the reply path TLV. 

> 
> Reply mode 2: Reply via an IPv4/IPv6 UDP packet
> Reply mode 4: Reply via application level control channel
> Reply mode 6: Reply via reverse LSP (assume this exists)
> 
> Let's say there existed:
> 
> Reply mode 7: Reply via pre-defined preference
> 
> When responder receives reply mode 7, then return path is chosen from
> pre-defined preference list (ex: control-channel > reverse LSP > IP). Reply mode
> used can be encoded in the reply mode field of echo rely so initiator knows which
> was used.

The difficulty is that the responder may not have the ability to judge whether the control-channel, reverse LSP and IP is workable or not. For example, when it thinks that the control-channel is workable, it will always choose it but the control-channel may not workable (e.g., a failure in the middle of the channel) . 

Best regards,
Mach

> 
> I see the new TLV useful for specific scenarios, but I've been trying to see how
> things (implementations and operations) can be simplified for those non-specific
> (majority) of cases. Was something like above considered as part of this draft?
> 
> Regards,
> Nobo
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls