Subject: [mpls] entropy label indicator label in draft-kompella-mpls-entropy-label

From: Yong Lucy <[email-masked]>
Date: Tue, 27 Jul 2010 07:31:21 -0500

Hi Kireeti and Shane,

Could we consider use one of reserved label for ELI purpose? This will make
implementation much easy, i.e. not need to keep the state for each ELI
label. The approach can be used in general for RSVP-TE and BGP as well.

Regards,

Lucy

---

From: John E Drake <[email-masked]>
Date: Tue, 27 Jul 2010 06:09:56 -0700

Lucy, we discussed this and decided it was better to have the egress control the values of the ELI it advertises.  Plus, getting a reserved value would be difficult

From: [email-masked] [mailto:[email-masked]] On Behalf Of Yong Lucy
Sent: Tuesday, July 27, 2010 5:31 AM
To: Kireeti Kompella; 'Shane Amante'; [email-masked]
Subject: [mpls] entropy label indicator label in draft-kompella-mpls-entropy-label

Hi Kireeti and Shane,

Could we consider use one of reserved label for ELI purpose? This will make implementation much easy, i.e. not need to keep the state for each ELI label. The approach can be used in general for RSVP-TE and BGP as well.

Regards,
Lucy

---

From: Yong Lucy <[email-masked]>
Date: Tue, 27 Jul 2010 08:25:09 -0500

What is the benefit for such control? Egress LSR does not use this value.

Lucy

  _____  

From: John E Drake [mailto:[email-masked]] 
Sent: Tuesday, July 27, 2010 8:10 AM
To: Yong Lucy; Kireeti Kompella; 'Shane Amante'; [email-masked]
Subject: RE: [mpls] entropy label indicator label
indraft-kompella-mpls-entropy-label

Lucy, we discussed this and decided it was better to have the egress control
the values of the ELI it advertises.  Plus, getting a reserved value would
be difficult

From: [email-masked] [mailto:[email-masked]] On Behalf Of Yong
Lucy
Sent: Tuesday, July 27, 2010 5:31 AM
To: Kireeti Kompella; 'Shane Amante'; [email-masked]
Subject: [mpls] entropy label indicator label in
draft-kompella-mpls-entropy-label

Hi Kireeti and Shane,

Regards,

Lucy

---

From: John E Drake <[email-masked]>
Date: Tue, 27 Jul 2010 06:31:03 -0700

Lucy,

Yes it does.  That is the whole point.  That is how the egress knows whether the ingress has placed an entropy label in the stack.  (That is why we termed it the 'Entropy Label Indicator'.)

Thanks,

John

From: Yong Lucy [mailto:[email-masked]]
Sent: Tuesday, July 27, 2010 6:25 AM
To: John E Drake; Kireeti Kompella; 'Shane Amante'; [email-masked]
Subject: RE: [mpls] entropy label indicator label indraft-kompella-mpls-entropy-label

________________________________
From: John E Drake [mailto:[email-masked]]
Sent: Tuesday, July 27, 2010 8:10 AM
To: Yong Lucy; Kireeti Kompella; 'Shane Amante'; [email-masked]
Subject: RE: [mpls] entropy label indicator label indraft-kompella-mpls-entropy-label

Hi Kireeti and Shane,

Regards,
Lucy

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 27 Jul 2010 15:24:02 +0100

John

Why do you prefer to use an ELI as opposed to using a new set of FECs 
with the property that they are followed by an EL?

Stewart

On 27/07/2010 14:31, John E Drake wrote:
>
> Lucy,
>
> Yes it does.  That is the whole point.  That is how the egress knows 
> whether the ingress has placed an entropy label in the stack.  (That 
> is why we termed it the 'Entropy Label Indicator'.)
>
> Thanks,
>
> John
>
> *From:* Yong Lucy [mailto:[email-masked]]
> *Sent:* Tuesday, July 27, 2010 6:25 AM
> *To:* John E Drake; Kireeti Kompella; 'Shane Amante'; [email-masked]
> *Subject:* RE: [mpls] entropy label indicator label 
> ------------------------------------------------------------------------
>
> *From:* John E Drake [mailto:[email-masked]]
> *Sent:* Tuesday, July 27, 2010 8:10 AM
> *To:* Yong Lucy; Kireeti Kompella; 'Shane Amante'; [email-masked]
> *Subject:* RE: [mpls] entropy label indicator label 
> Lucy, we discussed this and decided it was better to have the egress 
> control the values of the ELI it advertises.  Plus, getting a reserved 
> value would be difficult
>
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Yong Lucy
> *Sent:* Tuesday, July 27, 2010 5:31 AM
> *To:* Kireeti Kompella; 'Shane Amante'; [email-masked]
> *Subject:* [mpls] entropy label indicator label in 
> Could we consider use one of reserved label for ELI purpose? This will 
> make implementation much easy, i.e. not need to keep the state for 
> each ELI label. The approach can be used in general for RSVP-TE and 
> BGP as well.
>
> Regards,
>
> Lucy
>
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 27 Jul 2010 07:35:27 -0700

Hi Stewart,

On Jul 27, 2010, at 07:24 , Stewart Bryant wrote:

> John
> 
> Why do you prefer to use an ELI as opposed to using a new set of FECs with the property that they are followed by an EL?

The ELI is a catch-all, in case there is any potential confusion that the EL may be interpreted as an app label.  Most app labels (PWs (via T-LDP or BGP), VPN labels, etc.) can easily be followed by an EL, as Shane's slides showed.  No need for new FECs.

The sticky case is "naked" IP over LDP tunnels.  Do you have a suggestion that doesn't need an ELI in that case?

Thanks,
Kireeti.

---

From: John E Drake <[email-masked]>
Date: Tue, 27 Jul 2010 07:35:05 -0700

Stewart,

Only the ingress and egress need to undestand entropy labels, so doing it this way makes incremental deployment easier.  The ingress and egress are also not coupled and can be upgraded separately.

Thanks,

John

Sent from my iPhone

On Jul 27, 2010, at 4:24 PM, "Stewart Bryant" <[email-masked]<mailto:[email-masked]>> wrote:

John

Stewart

Yes it does.  That is the whole point.  That is how the egress knows whether the ingress has placed an entropy label in the stack.  (That is why we termed it the ‘Entropy Label Indicator’.)

Thanks,

John

From: Yong Lucy [<mailto:[email-masked]>mailto:[email-masked]]
Sent: Tuesday, July 27, 2010 6:25 AM
To: John E Drake; Kireeti Kompella; 'Shane Amante'; <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
Subject: RE: [mpls] entropy label indicator label indraft-kompella-mpls-entropy-label

________________________________
From: John E Drake [<mailto:[email-masked]>mailto:[email-masked]]
Sent: Tuesday, July 27, 2010 8:10 AM
To: Yong Lucy; Kireeti Kompella; 'Shane Amante'; <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
Subject: RE: [mpls] entropy label indicator label indraft-kompella-mpls-entropy-label

From: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]> [<mailto:[email-masked]>mailto:[email-masked]] On Behalf Of Yong Lucy
Sent: Tuesday, July 27, 2010 5:31 AM
To: Kireeti Kompella; 'Shane Amante'; <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
Subject: [mpls] entropy label indicator label in draft-kompella-mpls-entropy-label

Hi Kireeti and Shane,

Regards,
Lucy

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

<http://www.cisco.com/web/about/doing_business/legal/cri/index.html>http://www.cisco.com/web/about/doing_business/legal/cri/index.html

<ATT00001..txt>

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 27 Jul 2010 16:02:28 +0100

> The sticky case is "naked" IP over LDP tunnels.  Do you have a suggestion that doesn't need an ELI in that case?
Hi Kireeti,

Well you could do this with a new IP FEC, but you would have to have 
this running on all P routers along the path and you would need to  PHP 
both the LSP and the entropy labels.

It's not clear which is worse here. Though I note that the core 
philosophy of MPLS is to signal in the control plane and not in the data 
plane.

Stewart

---

From: Yong Lucy <[email-masked]>
Date: Tue, 27 Jul 2010 10:06:29 -0500

Hi John,

I don't get it. If egress LSR asks ingress LSR to place ELI on the stack,
the ingress can insert a unique ELI label on the stack followed by entropy
label. When packet arrives to egress LSR, the LSR will find ELI on the
stack. Why is it important for egress LSP to allocate a value for ELI
instead of using standardized value? 

Regards,

Lucy

  _____  

Sent: Tuesday, July 27, 2010 8:31 AM

Lucy,

Yes it does.  That is the whole point.  That is how the egress knows whether
the ingress has placed an entropy label in the stack.  (That is why we
termed it the 'Entropy Label Indicator'.) 

Thanks,

John

Lucy

  _____  

Hi Kireeti and Shane,

Regards,

Lucy

---

From: Shane Amante <[email-masked]>
Date: Tue, 27 Jul 2010 18:22:21 +0200

Lucy,

On Jul 27, 2010, at 17:06 GMT+02:00, Yong Lucy wrote:
> Hi John,
> I don’t get it. If egress LSR asks ingress LSR to place ELI on the stack, the ingress can insert a unique ELI label on the stack followed by entropy label. When packet arrives to egress LSR, the LSR will find ELI on the stack. Why is it important for egress LSP to allocate a value for ELI instead of using standardized value?

I think John already answered this question, but I'll give it a try, as well.  It's really a design choice on the part of the co-authors, in an attempt to avoid asking the MPLS WG to allocate a reserved label from the very scarce reserved label space.  I would note that there are only 8 reserved MPLS label values that are currently unassigned:
http://www.iana.org/assignments/mpls-label-values/mpls-label-values.xhtml

So, if we believe it's "sound engineering" to use an ELI instead of a reserved label -- certainly a judgement call -- then, I believe, we should NOT request a reserved label in order that future applications that have a legitimate use (or, said differently, may not be able to function properly without a reserved label value) have an ability to acquire one.

-shane

---

From: John E Drake <[email-masked]>
Date: Tue, 27 Jul 2010 10:19:04 -0700

The egress signals the ability to support the receipt of an entropy label and the ELI value in the control plane.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stewart Bryant
> Sent: Tuesday, July 27, 2010 8:02 AM
> To: Kireeti Kompella
> Cc: [email-masked]
> Subject: Re: [mpls] entropy label indicator label indraft-kompella-
> mpls-entropy-label
> 
> >> Why do you prefer to use an ELI as opposed to using a new set of
> FECs with the property that they are followed by an EL?
> > The ELI is a catch-all, in case there is any potential confusion that
> the EL may be interpreted as an app label.  Most app labels (PWs (via
> T-LDP or BGP), VPN labels, etc.) can easily be followed by an EL, as
> Shane's slides showed.  No need for new FECs.
> >
> > The sticky case is "naked" IP over LDP tunnels.  Do you have a
> suggestion that doesn't need an ELI in that case?
> Hi Kireeti,
>

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 28 Jul 2010 03:17:30 -0400

> label. The approach can be used in general for RSVP-TE and BGP as well.

Kireeti, Shane, Lucy,

I agree that a reserved label would be useful.

You should also remove the restriction that the entropy label is on
the bottom of stack.

With three more bits of information in the TE-LSDB an LSR can identify
a path over which it can carry a very large aggregate MPLS LSP
containing smaller MPLS-TP LSP.

  1.  Each LSR must identify itelf as "entropy label capable" (if it
      is capable, otherwise it remains silent on this).

  2.  Each LSR must identify itself as capable of limiting the stack
      depth over which it will hash on a per LSP basis if it is
      capable, otherwise it remains silent on this).

  3.  Each LAG or bundle must identify itself as multipath capable
      (implied in LAG, currently uncertain for bundle) and indicate
      the largest microflow it can handle (this would be the largest
      component link minus some epsilon if it was capable of moving
      traffic to accommodate a large microflow).  This is similar to
      (but not identical to) Maximum-LSP-Bandwidth in bundles.
      Perhaps this could be called Maximum-Microflow.

If this approach is used, the CSPF for an MPLS LSP containing MPLS-TP
requires pruning all LSR that do not have the first two capabilities
and pruning all links that do not state a Maximum-Microflow or that
state a Maximum-Microflow that is less than the largest MPLS-TP LSP
being carried.

Signaling must indicate the depth to hash to.  The ingress of the
aggregated LSP would put the entropy label for all sub-LSP that can be
subdivided into flows (generally most or all non-MPLS-TP LSP).

At each forwarding hop the the hash depth limit must be respected but
with the entropy label above that depth the balance could be
maintained without impacting MPLS-TP.

Note: There is no requirement to identify the large flows through an
explicity marking at ingress.  This comment is not relevant to this
draft, but I thought I'd point this out before the thread goes off in
that direction.  Please keep that discussion on a separate thread.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 28 Jul 2010 03:24:09 -0400

In message <[email-masked]>
John E Drake writes:
> whethe= r the ingress has placed an entropy label in the stack.  (That
> is why we te= rmed it the 'Entropy Label Indicator'.)
>  
> Thanks,
>  
> John

OK.  I see the point of avoiding the reserved label and the reason
that the LSP egress only needs to recognize it.

I still feel that the restriction to put this at BOS is not necessary.
It must only be below the forwarding label of the egress for that LSP.

Curtis

> Subject: RE: [mpls] entropy label indicator label indraft-kompella-mpls-ent=
> ropy-label
>  
> Subject: RE: [mpls] entropy label indicator label indraft-kompella-mpls-ent=
> ropy-label
>  
> contro= l the values of the ELI it advertises.  Plus, getting a
> reserved value woul= d be difficult
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Yon=
> g Lucy
> Subject: [mpls] entropy label indicator label in draft-kompella-mpls-entrop=
> y-label
>  
> Hi Kireeti and Shane,
>  
>  make= implementation much easy, i.e. not need to keep the state for
>  each ELI lab= el. The approach can be used in general for RSVP-TE and
>  BGP as well.
>  
> Regards,
> Lucy

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 28 Jul 2010 03:37:38 -0400

In message <[email-masked]>

Stewart,

The same TE LSP can carry an IP payload and other MPLS LSP.  This
avoids confusing an entropy label with a forwarding label.

The egress does not have to know apriori whether the ingress is adding
an entropy label and the ingress is free to add an entropy label to
some but not all traffic.

The draft only provides LDP signaling.  TE signaling should also be
provided.  The entropy label can be a per host value (platform label
space) and it doesn't matter much where in OSPF-TE or ISIS-TE the TLV
is placed.

It would be nice if as we add further MPLS extensions we got the new
behavior we are looking for without making it such that MPLS-TP cannot
be accommodated on the same path and adding signaling to TE as well as
LDP is a small step in that direction.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 28 Jul 2010 03:48:23 -0400

In message <[email-masked]>
Shane Amante writes:
> > I don=92t get it. If egress LSR asks ingress LSR to place ELI on the =
> stack, the ingress can insert a unique ELI label on the stack followed =
> by entropy label. When packet arrives to egress LSR, the LSR will find =
> ELI on the stack. Why is it important for egress LSP to allocate a value =
> for ELI instead of using standardized value?
>  
> I think John already answered this question, but I'll give it a try, as =
> well.  It's really a design choice on the part of the co-authors, in an =
> attempt to avoid asking the MPLS WG to allocate a reserved label from =
> the very scarce reserved label space.  I would note that there are only =
> 8 reserved MPLS label values that are currently unassigned:
> =
> So, if we believe it's "sound engineering" to use an ELI instead of a =
> reserved label -- certainly a judgement call -- then, I believe, we =
> should NOT request a reserved label in order that future applications =
> that have a legitimate use (or, said differently, may not be able to =
> function properly without a reserved label value) have an ability to =
> acquire one.
>  
> -shane

Whether it is reserved or not, the ingress needs to verify that the
egress understands it so there is little additional change having the
egress provide its own reserved value.  This avoids using a scarse
resource for no good reason.

Curtis

---

From: Yong Lucy <[email-masked]>
Date: Wed, 28 Jul 2010 03:27:36 -0500

Yes, Egress PE has its own reserved value.

Cheers,
Lucy

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, July 28, 2010 2:48 AM
> To: Shane Amante
> Cc: Yong Lucy; [email-masked]
> Subject: Re: [mpls] entropy label indicator label indraft-kompella-mpls-
> entropy-label
> 
>

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 28 Jul 2010 02:05:35 -0700

Hi Curtis, Stewart,

> avoids confusing an entropy label with a forwarding label.

In a discussion yesterday, it occurred to me that upstream allocated labels also call for the use of ELI.  Again, the issue is confusing an EL with a forwarding label.  We'll spell this out in the next revision.

> space) and it doesn't matter much where in OSPF-TE or ISIS-TE the TLV

That's the plan (and BGP signaling as well).

Kireeti.

---

From: Yong Lucy <[email-masked]>
Date: Wed, 28 Jul 2010 06:06:09 -0500

Yes, each egress PE reserves its own ELI label value. Ingress PEs need
remember each PE reserved ELI label. For a large network, one PE may send
packets to many PEs.

Cheers,
Lucy 

> Curtis Villamizar
> Sent: Wednesday, July 28, 2010 2:38 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [mpls] entropy label indicator labelindraft-kompella-mpls-
> entropy-label
> 
>

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 28 Jul 2010 04:18:40 -0700

Hi Lucy,

> remember each PE reserved ELI label. For a large network, one PE may send

We might be making a bit too much of this.  A PE needs to allocate for reception only one ELI for *all* its apps/protocols.  In fact, a vendor will probably have a single ELI value across all their boxes.  We (the mpls WG) could pick a suggested value (outside the reserved range) that several vendors could choose to implement.  The net is that a PE even though it sends to many other PEs may have a small handful (or even one) value of ELI to send.

Folks, speak up, and if there is enough support, I'll throw in a para suggesting a common ELI value ... unless the chairs/ADs step in and provide technical reasons why not.

Kireeti.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 28 Jul 2010 08:00:14 -0400

> remember each PE reserved ELI label. For a large network, one PE may send

An LSR doing TE can afford another 20 bits of memory per node in
addition to the existing OSPF-TE and ISIS-TE information.  An LSR
doing PW can afford another 20 bits per T-LDP session.

BTW- (question to authors) does the FEC approach for LDP work for
MS-PW where the ingress and egress do not have a direct T-LDP
adjacency?

Curtis

---

From: Yong Lucy <[email-masked]>
Date: Wed, 28 Jul 2010 07:15:10 -0500

Kireeti,

There is one technical reason to have one common ELI label value: for
multicast packets. Multicast message may be sent to many egress PEs. Ingress
PE can only put one value for ELI label. So this enforces all PEs use the
same ELI label value. Is this right?

Regards,
Lucy

> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Wednesday, July 28, 2010 6:19 AM
> To: Yong Lucy
> Cc: [email-masked]
> We might be making a bit too much of this.  A PE needs to allocate for
> reception only one ELI for *all* its apps/protocols.  In fact, a vendor
> will probably have a single ELI value across all their boxes.  We (the
> mpls WG) could pick a suggested value (outside the reserved range) that
> several vendors could choose to implement.  The net is that a PE even
> though it sends to many other PEs may have a small handful (or even one)
> value of ELI to send.
> 
> Folks, speak up, and if there is enough support, I'll throw in a para
> suggesting a common ELI value ... unless the chairs/ADs step in and
> provide technical reasons why not.
> 
> Kireeti.
> 
> > Cheers,
> > Lucy
> >

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 28 Jul 2010 05:46:49 -0700

On Jul 28, 2010, at 05:15 , Yong Lucy wrote:

> multicast packets.

How does one signal a multi-path p2mp LSP?

Kireeti.

---

From: Yong Lucy <[email-masked]>
Date: Wed, 28 Jul 2010 08:14:38 -0500

What I mean is that this approach could apply to P2MP LSP. One value can
make the backward compatibility in future easy.

Lucy

> Sent: Wednesday, July 28, 2010 7:47 AM
> To: Yong Lucy
> Cc: [email-masked]

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 28 Jul 2010 09:25:27 -0400

In message <[email-masked]>
> How does one signal a multi-path p2mp LSP?

You signal an LSP that crosses a LAG.  (Or that crosses link bundles
that use the all-ones component link by default).

Curtis

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 28 Jul 2010 06:22:31 -0700

> There is one technical reason to have one common ELI label value: for

Shane gently pointed out that ELs can be used for better load balancing on LAGs (i.e., not just multi-path LSPs).

Given that, I'll ask the chairs to start a thread on how we can converge on a single ELI value.

George, Loa: having everyone agree on a common ELI is convenient, and necessary in some cases.  So, can we (a) ignore those cases; or (b) coopt a reserved label, or (c) coopt a regular label, or (d) [I'm open to other suggestions]

Kireeti.