Re: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-mode-simple

["Nobo Akiya (nobo)" <[e-mail]>]

Hi Sam,

Thanks for your patience and continued discussions.
I agree that we have reached saturation between us.
We will proceed to roll out -02 shortly, addressing comments you’ve provided.

-Nobo

From: Sam Aldrin [mailto:[e-mail]]
Sent: Monday, April 14, 2014 6:54 PM
To: Nobo Akiya (nobo)
Cc: Mach Chen; [e-mail]; [e-mail]; Curtis Villamizar
Subject: Re: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-mode-simple

Hi Nobo,

Thanks again for the reply.
Find my replies inline with %sam2. Kept only relevant text for readability sakes.



- Sec 2

This document adds one Reply Mode to describe reverse LSP, and one

   optional TLV to describe ordered list of reply modes.  Based on

   operational needs, the TLV can describe multiple Reply Mode values in

   preferred order to allow responder to use first available Reply Mode

   from the list.  This eliminates the need for initiator to compute, or

   sometimes "guess", the "default" return path encoding.  And that will

   result in simplified implementations across vendors, and result in

   improved usability to fit operational needs.


- Sec 3.1, how is this different from RFC 7110? If same, please call it out here and remove TBD1 as sec 4.1 of RFC7110 added reply mode 5 for the same. If different to the RFC, I would like to see those details here.

[NOBO] Reply Mode introduced by RFC7110 specifies that MPLS echo reply is to be sent on LSP corresponding to FEC described in Reply Path TLV. Although Reply Path TLV has added B flag to indicate “reverse LSP”, Reply Mode 5 still require Reply Path TLV with B flag to describe “reverse LSP”. Reply Path TLV is good when wanting to use specific LSP as return path, but it’s more difficult than necessary when wanting to just use reverse LSP. I will add some texts to clarify this.
%sam - Are you saying that reply mode 5 with B bit set is not solving the problem or not optimal (because a TLV is being added?). The text in RFC7110 says, "B (Bidirectional): the return path is required to follow the

         reverse direction of the tested bidirectional LSP.  If B bit is

         set, there is no need to carry any specific reply path sub-
         TLVs, and when received, the sub-TLVs SHOULD be ignored."
As author of RFC7110 is also author of this draft, it would be good to clarification. From what I see, this new reply mode  proposed in this draft is already addressed in RFC7110. If the new reply mode adds optimization to the existing solution, why to add a new mode?

[NOBO2] Reply mode 5 requires a TLV, whether or not B bit is used. The text from RFC7110 above describes, further sub-TLV is not required when B bit is used. So yes, one aspect of this draft is optimization on how “Reply Mode = Reverse LSP” is described (i.e. Reverse LSP Reply Mode value that does not require any TLVs nor sub-TLVs).
%sam2 - We may disagree here but that is exactly my point. Why to introduce one more mode for the same functionality? If we take this path, then we will end up with too many options, with optimization as a reason. As the functionality is already solved by RFC7110, albeit extra TLV which is harmless, I'd rather not have this new mode.



General comments:

- I believe this new enhancement will only provide a degree of variance to RFC4379, where the response could be received back at initiator. Here is why
1. If the response is not received back at source, even with the new TLV, one cannot conclude that LSP is broken.

[NOBO] It depends on how you look at this. With this new TLV, it is difficult to figure out if lack of response is due to something broken or responder didn’t have the return path specified. With this new TLV, list of return paths are provided. Thus lack of response means either something is broken or none of the return paths specified were available at responder … which, if return path list contained everything, then it can only mean something is broken.
%sam - the assumption you are making here is, the responding node is broken locally. If the reply path in the middle is broken, this will solution not help either, because responding node picks the top reply mode and sends it. It doesn't know to pick #2 or later in the list, because #1 response mode didn't make it to source.
Is the scope limited to the ability of responding node to reply, hence providing multiple reply mode options?

[NOBO2] You are absolutely right that responder will not have any knowledge of what is available in transit node in the reverse direction. I think we are discussing glass is half full or empty though. Let me give one scenario.

There’s associated LSP between node A and node B. Let’s say ping is done from node A with just Reverse LSP Reply Mode. In the forward direction, a transit node X incorrectly forwards the packet to node Y. Node Y is not part of this LSP, thus node Y will obviously not have reverse LSP. In this case, ping will just timeout (i.e. node Y cannot send MPLS echo reply due to lack of reverse LSP). However, it is very beneficial for node A to still get “fec mismatch” error from node Y for diagnostic purpose, and that will be possible if node Y can respond with IP  path. In this case, Reply Mode Order TLV can have (1. Reverse LSP, 2. IP) which satisfies operator needs whilst still providing good diagnostic in case of failure.

This draft is indeed a small enhancements, but adds value to both simplicity and diagnostic aspect. Hopefully I was successful in swaying you in the direction of “supportive”, let me know?

%sam2 - This above works only if node Y is upgraded to support this new TLV :D. My take is, you could still detect the error in the above scenario, without any upgrade, albeit with an extra request with different reply mode type. I think we both agree that this enhancement is not to discover errors, which cannot be discovered with RFC4379. Rather, it optimises how it is discovered i.e. one request vs multiple requests. With your proposal, in order to gain the real optimization, you need to have the support on devices across the core. On the contrary, if you build application, which is just a workflow upgrade, all it has do is issue multiple requests when timeout happens. This doesn't require any upgrade of s/w on the network devices. In fact I know of applications which already do that.

Having said that, we both have clarified the understanding of what this draft means. What we differ is not technical content, rather the need to have this standardized, considering cost of upgrading Vs optimisation gain. I'll leave it to WG to see, if it really feels the need to enhance by standardizing it.

cheers
-sam


-Nobo



Thanks again
-sam