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

[John E Drake <[e-mail]>]

Curtis,

What you are doing is speculating that our EL solution could be  
morphed to solve a problem for which the requirements are ill-defined.

You refuse to understand that ELI is required in only a few cases and  
we do not want to make it mandatory.

Have you actually read the I-D or are you simply assuming that it  
mirrors your pre-conceived notions?

John

Sent from my iPhone

On Aug 2, 2010, at 8:39 PM, "Curtis Villamizar" <[e-mail]>  
wrote:

>
> In message <[e-mail]>
> John E Drake writes:
>>
>> Hi,
>>
>> I think there is a misunderstanding.  EL support is loosely coupled
>> between the ingress and egress and intermediate nodes have no
>> knowledge of its usage.   Further, the ELI is normally *not* present.
>> The normal mode of operation is for the egress to see a label for
>> which it is expecting to see BOS set.  The fact that it isn't tells
>> the egress that an EL is present.
>
> John,
>
> You are jumping in without understanding the context of the
> discussion.
>
> If stack depth used for hash is purposely limited for the purpose of
> supporting a client MPLS-TP within an MPLS LSP, then the ELI and the
> EL allow the label carrying entropy to be moved up the stack to where
> it would be visible to the hash.
>
> For example, if an MPLS LSP carried one MPLS-TP LSP and one very large
> IP/MPLS LSP, the forwarding label could be followed by ELI and then
> EL.  If the hash is limited to two, then MPLS-TP is unaffected.  If
> the midpoint LSR do not know the value of ELI being used, they cannot
> look past it at the third label in the stack.
>
> This could also be solved by the ingress padding all LSP not using ELI
> (by signaling an additional LSP that does nothing) but that is a very
> ugly solution.
>
>> ELI is for IPv4/6 forwarding where there is no label in which to  
>> check
>> for BOS not being set.  Effectively, the ELI becomes that label.
>
> That was the original use, to avoid looking past BOS at the first
> nibble.  Keeping that behaviour (looking past BOS) solves the
> multipath with MPLS-TP case since the hash is not label stack based,
> as long as MPLS-TP always uses a control word.  That is too limitiing
> as MPLS-TP may also want to carry IP.
>
>> This renders any transit router usage of an ELI with a reserved value
>> moot since most of the time it won't be there.
>>
>> Wrt p2mp, we cannot add either an EL or a reserved value ELI unless
>> *all* receivers have indicated that they can receive it.
>
> Yes we all agree on that.
>
>> Thanks,
>>
>> John
>
> btw- The length of messages that you send from a phone never ceases to
> amaze me.
>
> Curtis
>
>> Sent from my iPhone
>>
>> On Aug 2, 2010, at 10:18 AM, "Curtis Villamizar" <[e-mail]>
>> wrote:
>>
>>>
>>> In message <[e-mail]>
>>> Shane Amante writes:
>>>>
>>>> Hi Curtis,
>>>>
>>>> I had some time to think about this some more on the plane ride  
>>>> home.
>>>> See below.
>>>>
>>>> On Jul 30, 2010, at 14:02 GMT+02:00, Curtis Villamizar wrote:
>>>>> In message <[e-mail]>
>>>>> Shane Amante writes:
>>>>>>
>>>>>> Curtis,
>>>>>>
>>>>>> On Jul 30, 2010, at 11:06 GMT+02:00, Curtis Villamizar wrote:
>>>>>>> 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 .
>>>>>>
>>>>>> 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 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.
>>>
>>> The use of a reserved label doesn't remove the requirement to figure
>>> out if the egress can support ELI.  It just removes the  
>>> requirement to
>>> put a separate ELI label on for each egress.
>>>
>>> If some P2MP paths don't need to load balance (no multipath on that
>>> leg) but other paths do, as long as all egress can support ELI, then
>>> at worst it is 8 bytes of overhead that some paths don't need.
>>>
>>> I don't see an alternative for P2MP in your paragraph above.  Are  
>>> the
>>> branch points assumed to selectively add a different ELI (or none)  
>>> and
>>> should branch point remove ELI and the entropy label if ELI is not
>>> needed downstream or to the next branch point?  Would this be a lot
>>> more complicated with different values of ELI per egress (and  
>>> possibly
>>> also per branch point)?
>>>
>>>> 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.
>>>
>>> OK.
>>>
>>>> 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.  :-)
>>>
>>> For load balance to work with stack limited, then all midpoints  
>>> would
>>> need to know what ELI was being used.
>>>
>>> This is a bit like each P2MP needing to know which ELI is needed
>>> downstream of it, but not quite as bad.
>>>
>>> OTOH, putting the ELI that is being used on a P2P LSP in the PATH or
>>> RESV message for that P2P LSP would solve this for "Use of Multipath
>>> with MPLS-TP and MPLS" aka draft-villamizar-mpls-tp-multipath-00.  I
>>> could reference draft-kompella-mpls-entropy-label and make the  
>>> request
>>> that you put the ELI label in the PATH or RESV message somewhere.
>>>
>>>> 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 :-).
>>>
>>> OK.  Just try to get the ELI into the PATH or RESV so all LSR on the
>>> PATH can see it.
>>>
>>> BTW - There are some implications for facilities FRR.  On the
>>> facilities backup path there is no per LSP PATH or RESV message to
>>> look at to see what value of ELI is being used.  If the facilities
>>> backup path is over multipath (ie: LAG, bundle, or RSVP ECMP), then
>>> the value of ELI will not be known.  This might force detour style  
>>> FRR
>>> or use of GMPLS path protection (or segemenbt which is more
>>> detour-like).  A fixed ELI would help here too (allowing bypass  
>>> FRR).
>>>
>>>> -shane
>>>
>>> Maybe we should continue offline and then go back to the list.
>>>
>>> Curtis