Subject: [mpls] ELI as a reserved label

From: Curtis Villamizar <[email-masked]>
Date: Fri, 30 Jul 2010 05:06:06 -0400

The Entropy Label Indicator (ELI) is called for in
draft-kompella-mpls-entropy-label-01.txt

After brief discussion with Stewart and with Kireeti and Lucy Yong,
there were three uses of ELI that would benefit from making the ELI a
reserved label.  It may be premature to make any such request and the
remaining reserved label number space is sparse, so this will be
floated as a separate draft, and put on hold awaiting advancement of
the drafts that depend on it.

The three benefits of making ELI a reserved label are in:

  1.  Extending any use of entropy-label to P2MP (where there are
      multiple egress and the possibility of each egress requiring a
      separate entropy label value is problematic for the ingress).

  2.  Extending any use of entropy-label to any arbitrary position in
      the label stack such that in an aggregation LSP with aggregates
      both MPLS-TP and MPLS LSP, load split on the MPLS LSPs is
      simplified and not impacted by limiting label stack depth for
      the MPLS-TP LSPs.  This is when label stack hash is limited to
      support MPLS-TP as proposed in
      draft-villamizar-mpls-tp-multipath-00.txt .

  3.  Providing a means to carry indication of large flow as described
      in draft-yong-pwe3-enhance-ecmp-lfat-01.txt and
      draft-yong-pwe3-lfc-fat-pw-01.txt without changing the use of TC
      in a forwarding LSP label.

This would reuse one reserved label for three purposes.

This email is to gauge the reaction to this proposal (preferably among
those familiar with these drafts) before taking the time to write a
new draft proposing that a reserved label be allocated.

Curtis

---

From: Shane Amante <[email-masked]>
Date: Fri, 30 Jul 2010 11:34:45 +0200

Curtis,

>      draft-villamizar-mpls-tp-multipath-00.txt .

I agree there are benefits to a reserved label for the above two applications.  Most importantly, a receiving node would have pretty clearly semantics that what [immediately] follows a reserved ELI is the entropy-label, regardless of where the ELI is in the MPLS label stack and without needing to be in the signaling path to know what is the ELI value.

>      in a forwarding LSP label.

I'm unclear how a single, reserved label would be a means of signaling a large vs. small flow.  How can a single label represent two states (large vs. small flow)?

Thanks,

-shane

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

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 30 Jul 2010 08:02:13 -0400

In message <[email-masked]>
Shane Amante writes:
> I agree there are benefits to a reserved label for the above two
> applications.  Most importantly, a receiving node would have pretty
> clearly semantics that what [immediately] follows a reserved ELI is
> the entropy-label, regardless of where the ELI is in the MPLS label
> stack and without needing to be in the signaling path to know what is
> the ELI value.

"Now don't be sad ... 'cause two out of three aint bad".  [meatloaf]

Its good to hear that you consider these to be useful.

Note that an ingress LSR still needs to determine that egress LSR
understands ELI to do anything.  To support MPLS-TP in MPLS the
ingress needs to veryify that all LSR on the path support MPLS in a
way that provides a compliant path for a contained TP LSP, but that is
out of scope of this discussion.

> I'm unclear how a single, reserved label would be a means of signaling
> a large vs. small flow.  How can a single label represent two states
> (large vs. small flow)?

That's the slightly ugly part.  If ELI carries a TTL=0 then it can't
be used to forward and among those that discussed this (in one of the
"hallway sessions" near the registration desk) it was not seen as too
horribly ugly if TC meaned something else in the ELI label stack entry
only.

Lucy has a different way to do multipath and this is an enabler.  If
your LSRs don't use it, then it does no harm as long as the hashed
entropy value is there too.

> -shane

Thanks for the input on this.

Curtis

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

---

From: Shane Amante <[email-masked]>
Date: Fri, 30 Jul 2010 17:31:23 +0200

Curtis,

>> On Jul 30, 2010, at 11:06 GMT+02:00, Curtis Villamizar wrote:

[--snip--]

> entropy value is there too.

Understood.

I would note that in draft-kompella-mpls-entropy-label-01 it is NOT envisioned that there will be a "standalone ELI" in all cases.  Specifically, in the case where application labels are in use, (e.g.: 2547 VPN's, 6PE, etc.), the application label itself is intended to serve the purpose of an ELI, indicating that the label that immediately follows the application label is an entropy-label, i.e.:

+----------------+
|  Tunnel Label  |
+----------------+
|   App. Label   |
+----------------+
| Entropy Label  |
+----------------+

In these cases, there wouldn't be a reserved label used for a ELI in the label stack.  Thus, I'm not sure you can count on the LFC-bit *only* being set in entropy-labels that are immediately preceded by a reserved ELI label.

So, with respect to LFC, IMO it's:
a)  orthogonal to the discussion of whether or not a reserved label for the ELI is absolutely _required_ or just nice-to-have; and,
b)  the MPLS WG needs to weigh in with a definitive answer on whether changing the semantics of the MPLS TC is appropriate to accommodate end-users who desire LFC.

-shane

---

From: Shane Amante <[email-masked]>
Date: Sun, 1 Aug 2010 04:38:17 +0200

Hi Curtis,

I had some time to think about this some more on the plane ride home.  See below.

> out of scope of this discussion.

I need to revise my statements wrt entropy-labels and P2MP LSP's.  After thinking about this some more, I no longer believe it makes sense to use a reserved ELI value for P2MP LSP's.  More specifically, for a given P2MP LSP, all receivers /MUST/ agree to receive entropy labels, because it would be silly to (for example) expect core LSR's to strip-off the ELI and an entropy-label mid-flight toward receivers that don't understand (or, can't receive) entropy-labels.  The ramifications of this are that if a head-end detects any receivers of a P2MP LSP that can't receive entropy-labels, then the head-end LER/LSR must either: a) re-signal the whole P2MP LSP toward all receivers so that the head-end will not send any entropy-labels at all on the P2MP LSP; or, b) signal 2 separate P2MP LSP's: one for entropy-label capable receivers and a second for non-entropy-label capable receivers.  I don't know that we want to mandate one of those two behaviors over the other, because SP's may make separate choices depending on whether they want to avoid extra replication in the network at the expense of not being able to do flow-based load-balancing, i.e.: Option (a), or don't mind the extra replication of (potentially) 2 parallel P2MP trees on the same links in order to attain some amount of flow-based load-balancing of the P2MP traffic.

So, in summary, I no longer see that draft-kompella-mpls-entropy-label has a requirement for reserved labels for either P2P or P2MP LSP's (scenario 1 in your original e-mail).  Furthermore, I still maintain that discussion of LFC and use of the MPLS TC field for indication of large vs. small flows is orthogonal to draft-kompella-mpls-entropy-label (scenario 3 in your original e-mail).  I haven't read draft-villamizar-mpls-tp-multipath-00 (scenario 2 in your original e-mail) so I can't speak to whether or not there is a requirement for a reserved label there.

Anyway, perhaps this will save you some time in that you don't need to write a whole new draft as you originally proposed and, instead, may only need to look at modifying your original draft.  :-)

On a separate note, we intend to update draft-kompella-mpls-entropy-label shortly to cover P2MP LSP's (RSVP & mLDP), plus add details surrounding labelled BGP and RSVP P2P LSP's so that we have a more thorough treatment of all use cases to hopefully make all of this more clear.  (In fact, I got a good start on this text on this on the plane ride home :-).

-shane