Subject: [mpls] LSP ping clarification

From: Kireeti Kompella <[email-masked]>
Date: Thu, 2 Aug 2012 09:52:37 -0700

Hi All,

Since there have been some questions about how LSP ping works in the context of entropy labels, and concerns about the mechanism, I thought I would explain how LSP ping explores ECMP paths, what some of the limitations are, and to what extent they can be overcome.

To begin, LSP ping explores ECMP paths.  It does so by finding a value for a specific field while leaving the remaining fields used for load balancing fixed (think partial derivatives) (okay, that probably wasn't helpful).  In the IP case, this field is the IP dest address; in the label case, it is the entropy label field.  Example: for a packet that is part of an Ethernet PW, assume all routers use as load balancing fields: outer label, entropy label, PW label.  The field that changes is the entropy label, and the rest are kept constant.  Note: since the ELI is a reserved label, it is not used for load balancing.

Let's say the ping is from node X to node Y.  X has one downstream, A.  A has two downstreams, B1 and B2.  B1 has two downstreams, C11 and C12; B2 has three downstreams: C21, C22 and C23.  Cij are connected to Y.

To explore paths, X creates a label stack <TL, ELI, E, PL>, where TL is the label that goes from X via A to Y, and PL is the signaled PW label from X to Y.  In the payload (LSP ping packet), X inserts a description of a set S of labels, typically including E, sets TTL=1 and sends the packet to A.

X then changes E (and TTL) such that the resulting packet traverses each of the 5 paths from X to Y.  

Let's say that X chooses as the initial set of labels 20-24; A replies that 20 and 21 go to B1 (i.e., if A got a label stack of <TL, ELI, 20, PL>, it would send the packet to B1) and 22-24 go to B2.  X then sends a packet with label stack <TL, ELI, 20, PL> to B1 (by setting TTL=2, and inserts the label set of {20, 21}.  If all the stars line up, B1 could reply that an entropy label of 20 goes to C11, and 21 goes to C12.  Similarly, X sends a ping packet to B2 with label set {22, 23, 24}.  So, if X was really lucky, an initial label set of just five labels could be sufficient to explore the 5 paths.

It is possible that no choice of entropy label will explore a particular path.  If A sent only packets with <TL, ELI, E, PL> with odd E to B1, and B1 sent all packets with <TL', ELI, E, PL> with odd E to C11, there is no entropy label that would explore the path to C12.  Highly unlikely, but possible.  It could also be that a very small set of labels explore the path to C12; finding one such label might require that X sends different label sets to B1 over several iterations until it found one.

In general, the more ECMP choices one has to be make to pick a particular path, the harder it is to find a label to explore it.

To sum up, the methodology is reasonably reasonable but not fool-proof.  It is up to X to pick adequate-sized label sets to explore paths: large enough to expect non-empty replies, but not too large as to be unwieldy.  It is also up to X to retry a few times if it got back empty replies, but to throw up its hands (and report to the user/logging system) if it can't explore some sub-dag of ECMP paths.

I would be very happy to hear other approaches to exploring ECMPs.

Proposed action item 1: reduce the OAM section to refer to a future draft that explains the above.

PAI 2: write said future draft.

If acceptable, I will do both the above.  If someone has a new/tweaked mechanism that better addresses the problem of exploring paths, that should go into this draft.

Kireeti.

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 2 Aug 2012 10:02:51 -0700

Hi Kireeti,

From high level perspective, it works.
I have few thoughts which would make the solution robust. It also involves without changing much of the existing format. Do you have some time to discuss? Would be happy to share my input with you.

cheers
-sam
On Aug 2, 2012, at 9:52 AM, Kireeti Kompella <[email-masked]> wrote:

> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 2 Aug 2012 14:38:45 -0700

Kireeti, et al,

The below mechanism is exactly how the present deployments are using to monitor ECMP paths.
The only caveat is, as there was no entropy label being present thus far, the only way one could use was IP destination address (which is local host address). Many hardware platforms have an issue with destination address as local host address and in some cases the devices need not be IP aware.
Entropy label provides a clean way to make this work to monitor/diagnose the ECMP paths. All one needs to do is use hash type 2 or 4 and choose the multi path info appropriately.

To Kireeti's statement "In general, the more ECMP choices one has to be make to pick a particular path, the harder it is to find a label to explore it.". Having implemented ECMP monitoring with LSP ping, I do not think this is hard. Perfectly achievable and unless the load balance algorithm on a h/w is 'extremely' sub-optimal, it is not that difficult to find right hash to traverse each of the ECMP paths. RFC4379 provides option to increase the size and range to extend the labels upon exhaustion.

I do not see a problem why ECMP OAM for MPLS LSP's cannot be achieved with entropy label. I also do not see the need for a new draft or extension as RFC4379 is well written and captures this case as well. But if WG feels the need for an informational draft on how to achieve ECMP monitoring in different cases with or without entropy label, glad to write one.

HTH,
-sam