Subject: Re: [mpls] draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kumarkini-mpls-spring-lsp-ping

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Wed, 10 Sep 2014 01:38:03 +0000

Hi Bruno/Nobo,

I agree with you both that this use case is useful. Per my understanding, extending RFC7110 and let Initiator to pre-calculate the reverse segment stack and populating the same is also possible. While I understand the concern raised b Nobo, I think the FRR will be in place for reverse path as well and so should be able to reach the Initiator.

The other approach of having the responder calculate the return path is also reasonable. In either case, I think the extension should be included in draft-kumarkini-mpls-spring-lsp-ping.

Thanks,
Nagendra

From: "Nobo Akiya (nobo)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 5, 2014 at 9:26 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kumarkini-mpls-spring-lsp-ping

Hi Bruno,

I very much agree that the use case that you raised is useful for LSP Ping/Trace on SPRING.

In terms of how, there are few aspects that I’d like to highlight.

1.      To accomplish MPLS Echo Reply messages taking a return path that mirrors the forward path, generally there are two approaches.

a.      Sender of MPLS Echo Request messages (initiator) to compute the mirroring return path and include the information in the MPLS Echo Request. This can be done via extending RFC7110.

b.      Sender of MPLS Echo Reply messages (responder) to compute the mirroring return path (this is the logic you described in your email).

2.      With the approach (1a), return path computation requires that the initiator try to determine where the packet will terminate (thus incoming label stack on that node). That will be ok in a stable state but can get problematic when there are changes happening in the network (convergence, FRR). Instead, I tend to think (and agree) the approach (1b) of the responder computing the mirroring return path is superior.

3.      I’ve heard some stories about folks wanting to do path association on end-points in SPRING to create bi-directional “tunnels”. These “tunnels” will have a real reverse LSP. So the Reply Mode “reverse LSP” should apply to such bi-directional “tunnels”.

4.      Thus to address this use case, I think we need a new Reply Mode defined instead of using Reply Mode “reverse LSP”.

5.      How do we preserve the forward segment stack in the MPLS Echo Request?

a.      One way is for the entire segment stack to be described in the Target FEC Stack TLV. Although when LSP Traceroute is done on SRPING, what is expected normally is that Target FEC Stack shrinks as initiator receives “FEC Stack Change with POP” from downstream LSRs. It’s worth keeping this behavior.

b.      Another way is to introduce a new TLV that describes the entire segment stack pushed by the initiator, and that can get used by the responder along with the logic you described.

In summary, my personal opinion will be (1b), new Reply Mode, (5b) is a good way to address the use case you raised.

Logistically, these extensions (if we agree to extend) should be described in draft-kumarkini-mpls-spring-lsp-ping.

I would certainly like to hear from other experts on this matter as well.

Thanks!

-Nobo

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, September 05, 2014 9:03 AM
To: [email-masked]<mailto:[email-masked]>; Nobo Akiya (nobo)
Subject: draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kumarkini-mpls-spring-lsp-ping

Hi all,

*) Short version (use case):
draft-akiya-mpls-lsp-ping-reply-mode-simple defines a new Reply mode for MPLS LSP Ping: “Reply via reverse LSP”, with an applicability to “RSVP LSPs and TP LSPs”.
I have the rough impression that this mode would also be very applicable in SPRING networks/LSPs since the responder would be able send the reply along the same (reverse)/co-routed path than the requester.
Could this be investigated? (on the mailing list or in either of the above 2 drafts).

*) Long version (proposed solution):

a)      The responder is/should be able to get/infer the incoming path

a.      Get the end to end segment list/path a priori from the Target FEC stack TLV (e.g. L1, L2 … Ln)

b.      Get the local to end segment list/path from the label stack in the received packet (e.g. L3… Ln)

c.      Get the ingress to local segment list/path by subtracting both stacks (e.g. L1, L2)

b)      Using SR, the responder is able to enforce any explicit path, so in particular the reverse path from local to ingress. 2 options for this:

a.      Simple one: reverse the order of the segments in the path. For node segments, keep them unchanged, for adjacency segment, use the reverse adjacency. This is computationally very simple and but requires the IGP metric to be symmetric to enforce the same path in the reverse direction.

b.      Exact one: compute the exact forward path (SPF rooted on the sender then follow the segments stack).Then reverse the path and compute the list of segments required to enforce this path as with any explicitly rooted path. (a naïve algo would require 1 SPF per segment). This is computationally more expensive but enforces the same path in all cases. (seems a bit scary from a DOS perspective, to use significant control plane resources in response to a forwarding plane packet, but in essence, that’s already the case for ping/traceroute)
I guess that the choice could be a local choice on the responder, configured by the SP (e.g. depending on its use of asymmetric IGP costs)

A priori this would be applicable to both MPLS ping and traceroute.

Caveats:
1) restricted to a single IGP area. But this is a usual limitation of TE in a multi-area network. (and typical solution may also apply e.g. PCE)
2) The spring ingress router may have pushed the packet on a non shortest path interface (i.e. PHP/”pre POP” the initial adjacency label). To address this, the ingres router could indicate this initial adjacency label in the Target FEC stack of the LSP request.

Comments welcomed.
Thanks,
Regards,
Bruno

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 10 Sep 2014 01:53:19 +0000

Hi,
sorry I've missed the initial question by Bruno.
I'd like to refer to the Bidirectional Forwarding Detection (BFD) Directed Return Path draft that was presented and discussed at BFD, MPLS, and SPRING WGs in Toronto. Sections 3.1.2 and 3.2 introduce new sub-TLVs for MPLS and IPv6 data plane of Segment Routing domain that can be used in combination with RFC 7110.

                Regards,
                                Greg

From: mpls [mailto:[email-masked]] On Behalf Of Nagendra Kumar Nainar (naikumar)
Sent: Tuesday, September 09, 2014 6:38 PM
To: Nobo Akiya (nobo); [email-masked]; [email-masked]
Subject: Re: [mpls] draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kumarkini-mpls-spring-lsp-ping

Hi Bruno/Nobo,

Thanks,
Nagendra

Hi Bruno,

In terms of how, there are few aspects that I'd like to highlight.

3.       I've heard some stories about folks wanting to do path association on end-points in SPRING to create bi-directional "tunnels". These "tunnels" will have a real reverse LSP. So the Reply Mode "reverse LSP" should apply to such bi-directional "tunnels".

4.       Thus to address this use case, I think we need a new Reply Mode defined instead of using Reply Mode "reverse LSP".

a.       One way is for the entire segment stack to be described in the Target FEC Stack TLV. Although when LSP Traceroute is done on SRPING, what is expected normally is that Target FEC Stack shrinks as initiator receives "FEC Stack Change with POP" from downstream LSRs. It's worth keeping this behavior.

Thanks!

-Nobo

Hi all,

*) Short version (use case):
draft-akiya-mpls-lsp-ping-reply-mode-simple defines a new Reply mode for MPLS LSP Ping: "Reply via reverse LSP", with an applicability to "RSVP LSPs and TP LSPs".
I have the rough impression that this mode would also be very applicable in SPRING networks/LSPs since the responder would be able send the reply along the same (reverse)/co-routed path than the requester.
Could this be investigated? (on the mailing list or in either of the above 2 drafts).

a.       Get the end to end segment list/path a priori from the Target FEC stack TLV (e.g. L1, L2 ... Ln)

b.      Get the local to end segment list/path from the label stack in the received packet (e.g. L3... Ln)

b.      Exact one: compute the exact forward path (SPF rooted on the sender then follow the segments stack).Then reverse the path and compute the list of segments required to enforce this path as with any explicitly rooted path. (a naïve algo would require 1 SPF per segment). This is computationally more expensive but enforces the same path in all cases. (seems a bit scary from a DOS perspective, to use significant control plane resources in response to a forwarding plane packet, but in essence, that's already the case for ping/traceroute)
I guess that the choice could be a local choice on the responder, configured by the SP (e.g. depending on its use of asymmetric IGP costs)

Caveats:
1) restricted to a single IGP area. But this is a usual limitation of TE in a multi-area network. (and typical solution may also apply e.g. PCE)
2) The spring ingress router may have pushed the packet on a non shortest path interface (i.e. PHP/"pre POP" the initial adjacency label). To address this, the ingres router could indicate this initial adjacency label in the Target FEC stack of the LSP request.

Comments welcomed.
Thanks,
Regards,
Bruno

Thank you.