Re: [mpls] [PWE3] ELI as a reserved label

[Shane Amante <[e-mail]>]

Curtis,

On Jul 30, 2010, at 14:02 GMT+02:00, Curtis Villamizar wrote:
> In message <[e-mail]>
> Shane Amante writes:
>> On Jul 30, 2010, at 11:06 GMT+02:00, Curtis Villamizar wrote:

[--snip--]

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

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