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

[Sam Aldrin <[e-mail]>]

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