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

From: Sam Aldrin <[email-masked]>
Date: Fri, 11 Apr 2014 11:42:48 -0700

[Better late than never]

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.

-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

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

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?

%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>]).".

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

Thanks again
-sam

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sun, 13 Apr 2014 14:01:21 +0000

Hi Sam,

Please see in-line with [NOBO2].

From: Sam Aldrin [mailto:[email-masked]]
Sent: Friday, April 11, 2014 2:43 PM
To: Nobo Akiya (nobo)
Cc: Mach Chen; [email-masked]; [email-masked]; 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

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?

[snip]

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

- Sec 2

- 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

         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

   [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

---

From: Sam Aldrin <[email-masked]>
Date: Mon, 14 Apr 2014 15:53:59 -0700

Hi Nobo,

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

> 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”.
> it’s more difficult than necessary when wanting to just use reverse LSP. I
>  %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
>
> [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.

> responder didn’t have the return path specified. With this new TLV, list of
> broken or none of the return paths specified were available at responder …
>  %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.
>
> [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

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 15 Apr 2014 12:46:41 +0000

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:[email-masked]]
Sent: Monday, April 14, 2014 6:54 PM
To: Nobo Akiya (nobo)
Cc: Mach Chen; [email-masked]; [email-masked]; 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

[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

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

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

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