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

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

Hi Sam,

Please see in-line with [NOBO2].

From: Sam Aldrin [mailto:[e-mail]]
Sent: Friday, April 11, 2014 2:43 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

[Better late than never]

[NOBO2] Certainly, and thank you!

Thank you Nobo, for replying to my comments with %sam.
See inline for my comments. Removed ones which I considered were answered, for readability sake. Hope you don't mind it.

[NOBO2] Don't mind at all.

-sam



- In sec 2

Some return path(s) are more preferred than others, but preferred

   cannot be used in all cases.  Thus implementations are required to

   compute when preferred return path encoding can and cannot be used,

   and that computation is becoming more and more difficult.

As response code is initiated by the initiator, user in this case, the preferred return path is for UI implementation and not the actual LSP ping functionality. Which/what part of implementation are you referring to?

[NOBO] Ok, this below text more clearer?

[snip]
   Operators prefer some return path(s) over others for specific LSP
   types.  To accommodate this, implementations may default to operator
   preferred return path (or allow default return path to be configured)
   for specific operation.  However, if the sender of MPLS echo request
   knew that "preferred" return path will not be available at intended
   target node, then it is not very beneficial to specify Reply Mode
   corresponding to "preferred" return path (i.e. sender of MPLS echo
   request will not receive MPLS echo reply in the success case).  What
   would be beneficial, for a given operation, is for the sender of MPLS
   echo request to determine which return path(s) can and cannot be used
   ahead of time.  Thus implementations often compute when preferred
   return path encoding can and cannot be used, and that computation is
   becoming more and more difficult.
[snip]
%sam - Looks ok, but don't mind removing last sentence. :D

[NOBO2] That's true. Last sentence removed (from -02 candidate).

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

I'll add more to this. Even with RFC7110 or this draft, there is no way to know the support for these new reply modes, when looking from the source node. So, if the request is received with this new reply mode, (depending on implementation) the request may get dropped?

[NOBO2] Exactly. This is why Reply Mode Order TLV optional TLV is beneficial. Implementations can continue to use currently used/computed "Reply Mode" value in the MPLS echo request. Reply Mode Order TLV can provide ordered list of Reply Modes, which can be used by the responder if responder understands this draft (i.e. If not, responder will just use Reply Mode in received MPLS echo request). And because responder is to set Reply Mode used (if chosen from Reply Mode Order TLV)  in the Reply Mode field of MPLS echo reply, initiator knows what happened at the responder. This provide a clean transition.

%sam - For RFC4379bis? In RFC4379 sec 4.5, it says "If the reply is sent over an LSP, the



   topmost label MUST in this case be the Router Alert label (1) (see

   [LABEL-STACK<http://tools.ietf.org/html/rfc4379#ref-LABEL-STACK>]).".



[NOBO2] I agree. I think mandating RA label here is questionable. We should list this up as a topic to follow up for bis.


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?

-Nobo



Thanks again
-sam