Subject: [mpls] entropy labels: associate with tunnels or apps?

From: Kireeti Kompella <[email-masked]>
Date: Thu, 12 Apr 2012 13:20:40 -0700

This email is about: 2) should we associate the EL with tunnel labels or with application labels?

NOTE: this is for all applications OTHER THAN LDP pseudowires, where we already have a solution.

The philosophy here is that entropy labels are for improved ECMP; tunnels have ECMP; apps are point-to-point-ish.

Here's how it would work: an egress LSR signals, along with a tunnel (LDP or RSVP), its ability to process entropy labels.
An ingress LSR X, when it resolves an application (e.g. L3VPN) to a tunnel whose egress can process entropy labels, either decides not to insert entropy labels, or:
1. X hashes on the incoming packet, using its knowledge of the application.
2. X uses the result of the hash to choose the outgoing tunnel label TL
3. X makes an entropy label from the hash.
4. X pushes the following label stack: <TL, ELI, EL, AL>

Here are the benefits of associating the entropy label with tunnels:
a) there are far fewer tunneling protocols than applications.  Standardizing, implementing, testing, and interop-ing entropy labels just for tunnels rather than for all apps (and doing it again in the future for new apps) is a huge win.

b) if a provider has multiple tunnel types (LDP + tactical RSVP-TE for specific ingress-egress pairs), the ingress can meaningfully put/not put ELs in the packet, based on the tunnel rather than the application.

c) app label processing on the egress is unaffected.  The label stack that the egress would get (assuming PHP) is <ELI, EL, AL>.  Preprocessing pops ELI+EL, leaving the processing of the AL the same as before.  Processing <AL, EL> (if the entropy label is associated with the application) would mean touching the application label processing microcode for each app, some of which (like VPLS) is fairly complex.

d) the "app" of carrying IP over MPLS is no longer a special case.  [context: for IP over MPLS, as there is no app label, the label stack has to be <TL, ELI, EL>, not <TL, EL>.]

e) if multiple providers are involved in providing a service (CoC VPNs, hierarchical tunnels, etc.), then each provider can autonomously insert an entropy label for their tunnel.

The downside is that the label stack has one more label because the ELI would be mandatory: <TL, ELI, EL, AL> rather than <TL, AL, EL>.

So, the question: should we associate ELs with tunnels rather than with applications (apart from PWs)?  (if no, a short reason why would be helpful.)

Thanks,
Kireeti.

---

From: John E Drake <[email-masked]>
Date: Thu, 12 Apr 2012 14:07:44 -0700

Yes, although I think the term 'associating the EL with tunnel labels' and its variants are terrible.

What we a really saying is that the ability to process entropy labels is a nodal capability that is indicated in the signaling of tunnels to that node.  

We are also saying that the application is still responsible for creating the entropy label and for placing it in the MPLS label stack.  All we are doing is specifying a different order in which the application places labels in the stack.  

I think the most compelling reasons for specifying this order is that it makes the egress node processing uniform and amenable to hardware implementation, and that it ensures that the applications on the egress node are blissfully unaware of entropy labels.

Sent from my iPhone

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Kireeti Kompella
> Sent: Thursday, April 12, 2012 1:21 PM
> To: [email-masked]
> Subject: [mpls] entropy labels: associate with tunnels or apps?
> 
> The philosophy here is that entropy labels are for improved ECMP;
> tunnels have ECMP; apps are point-to-point-ish.
> 
> Here's how it would work: an egress LSR signals, along with a tunnel
> (LDP or RSVP), its ability to process entropy labels.
> An ingress LSR X, when it resolves an application (e.g. L3VPN) to a
> tunnel whose egress can process entropy labels, either decides not to
> insert entropy labels, or:
> a) there are far fewer tunneling protocols than applications.
> Standardizing, implementing, testing, and interop-ing entropy labels
> just for tunnels rather than for all apps (and doing it again in the
> future for new apps) is a huge win.
> 
> b) if a provider has multiple tunnel types (LDP + tactical RSVP-TE for
> specific ingress-egress pairs), the ingress can meaningfully put/not
> put ELs in the packet, based on the tunnel rather than the application.
> 
> c) app label processing on the egress is unaffected.  The label stack
> that the egress would get (assuming PHP) is <ELI, EL, AL>.
> Preprocessing pops ELI+EL, leaving the processing of the AL the same as
> before.  Processing <AL, EL> (if the entropy label is associated with
> the application) would mean touching the application label processing
> microcode for each app, some of which (like VPLS) is fairly complex.
> 
> d) the "app" of carrying IP over MPLS is no longer a special case.
> [context: for IP over MPLS, as there is no app label, the label stack
> has to be <TL, ELI, EL>, not <TL, EL>.]
> 
> e) if multiple providers are involved in providing a service (CoC VPNs,
> hierarchical tunnels, etc.), then each provider can autonomously insert
> an entropy label for their tunnel.
> 
> The downside is that the label stack has one more label because the ELI
> would be mandatory: <TL, ELI, EL, AL> rather than <TL, AL, EL>.
> 
> So, the question: should we associate ELs with tunnels rather than with
> applications (apart from PWs)?  (if no, a short reason why would be
> helpful.)
> 
> Thanks,
> Kireeti.
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 12 Apr 2012 17:18:55 -0400

Hi Kireeti,

IMO EL should be application agnostic as hash result for most application would be exactly the same (flow) - 5 tuple based for IPv4 or IPv6 or MAC for non IP. 

Regards,
Jeff
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kireeti Kompella
Sent: Thursday, April 12, 2012 1:21 PM
To: [email-masked]
Subject: [mpls] entropy labels: associate with tunnels or apps?

2. X uses the result of the hash to choose the outgoing tunnel label TL 3. X makes an entropy label from the hash.

Thanks,
Kireeti.

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 12 Apr 2012 20:52:26 -0400

Hi John,
this is not to answer Kireeti's question.
I think that, strictly speaking, scope of "the ability to process entropy labels" depends on label allocation mode. For per-interface it is an interface's capability. 

	Regards,
		Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Thursday, April 12, 2012 2:08 PM
To: Kireeti Kompella; [email-masked]
Subject: Re: [mpls] entropy labels: associate with tunnels or apps?

Sent from my iPhone

> 2. X uses the result of the hash to choose the outgoing tunnel label 
> TL 3. X makes an entropy label from the hash.
> Preprocessing pops ELI+EL, leaving the processing of the AL the same 
> as before.  Processing <AL, EL> (if the entropy label is associated 
> with the application) would mean touching the application label 
> processing microcode for each app, some of which (like VPLS) is fairly complex.
> 
> e) if multiple providers are involved in providing a service (CoC 
> VPNs, hierarchical tunnels, etc.), then each provider can autonomously 
> insert an entropy label for their tunnel.
> 
> The downside is that the label stack has one more label because the 
> ELI would be mandatory: <TL, ELI, EL, AL> rather than <TL, AL, EL>.
> 
> So, the question: should we associate ELs with tunnels rather than 
> with applications (apart from PWs)?  (if no, a short reason why would 
> be
> helpful.)
> 
> Thanks,
> Kireeti.
>

---

From: John E Drake <[email-masked]>
Date: Fri, 13 Apr 2012 04:15:46 -0700

Greg,

Why do you make that coupling?  It's not obvious to me that the label allocation mode has anything to do with the ability to recognize and discard ELI/EL label pairs.

Thanks,

John

Sent from my iPhone

> From: Gregory Mirsky [mailto:[email-masked]]
> Sent: Thursday, April 12, 2012 5:52 PM
> To: John E Drake; Kireeti Kompella; [email-masked]
> Subject: RE: entropy labels: associate with tunnels or apps?
> 
> Hi John,
> I think that, strictly speaking, scope of "the ability to process
> entropy labels" depends on label allocation mode. For per-interface it
> is an interface's capability.
> 
> 	Regards,
> 		Greg
> 
> John E Drake
> What we a really saying is that the ability to process entropy labels
> is a nodal capability that is indicated in the signaling of tunnels to
> that node.
> 
> We are also saying that the application is still responsible for
> creating the entropy label and for placing it in the MPLS label stack.
> All we are doing is specifying a different order in which the
> application places labels in the stack.
> 
> I think the most compelling reasons for specifying this order is that
> it makes the egress node processing uniform and amenable to hardware
> implementation, and that it ensures that the applications on the egress
> node are blissfully unaware of entropy labels.
> 
> Sent from my iPhone
>

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 13 Apr 2012 14:52:11 -0400

Hi John,
I think that "nodal capability" is too strong requirement in case of per-interface label allocation. I think that in case of per-interface label allocation interpretation of capability to process ELI/EL labels can be limited to scope of that interface.

	Regards,
		Greg

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Friday, April 13, 2012 4:16 AM
To: Gregory Mirsky; Kireeti Kompella; [email-masked]
Subject: RE: entropy labels: associate with tunnels or apps?

Greg,

Thanks,

John

Sent from my iPhone

> implementation, and that it ensures that the applications on the 
> egress node are blissfully unaware of entropy labels.
> 
> Sent from my iPhone
> 
> > tunnel whose egress can process entropy labels, either decides not 
> > to insert entropy labels, or:
> > c) app label processing on the egress is unaffected.  The label 
> > stack that the egress would get (assuming PHP) is <ELI, EL, AL>.
> > [context: for IP over MPLS, as there is no app label, the label 
> > stack has to be <TL, ELI, EL>, not <TL, EL>.]
> >
> > with applications (apart from PWs)?  (if no, a short reason why 
> > would be
> > helpful.)
> >
> > Thanks,
> > Kireeti.
> >

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 13 Apr 2012 12:12:01 -0700

Hi John,

> Yes, although I think the term 'associating the EL with tunnel labels' and its variants are terrible.

You're right.  It sets up the wrong mental picture.

> What we a really saying is that the ability to process entropy labels is a nodal capability that is indicated in the signaling of tunnels to that node.  

Right.

> We are also saying that the application is still responsible for creating the entropy label and for placing it in the MPLS label stack.  All we are doing is specifying a different order in which th…

Right.

> I think the most compelling reasons for specifying this order is that it makes the egress node processing uniform and amenable to hardware implementation, and that it ensures that the applications…

Reason (a) is also pretty compelling, but point taken.

Thanks,
Kireeti.

---

From: John E Drake <[email-masked]>
Date: Fri, 13 Apr 2012 13:02:58 -0700

Greg,

The EL draft has always described EL capability as a nodal property.

Thanks,

John 

Sent from my iPhone

> Sent: Friday, April 13, 2012 11:52 AM
> I think that "nodal capability" is too strong requirement in case of
> per-interface label allocation. I think that in case of per-interface
> label allocation interpretation of capability to process ELI/EL labels
> can be limited to scope of that interface.
> 
> 	Regards,
> 		Greg
> 
> Why do you make that coupling?  It's not obvious to me that the label
> allocation mode has anything to do with the ability to recognize and
> discard ELI/EL label pairs.
> 
> Thanks,
> 
> John
> 
> Sent from my iPhone
> 
> 
> > Yes, although I think the term 'associating the EL with tunnel
> labels'
> > and its variants are terrible.
> >
> > > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > > Of Kireeti Kompella
> > > NOTE: this is for all applications OTHER THAN LDP pseudowires,
> where
> > > we already have a solution.
> > >

---

From: Shane Amante <[email-masked]>
Date: Fri, 13 Apr 2012 18:18:20 -0600

Kireeti, All,

> This email is about: 2) should we associate the EL with tunnel labels or with application labels?

EL's with tunnel labels.  Definitely, tunnel labels.

IMO, the most compelling reasons are (in addition to those you've already provided below):
1)  We solve for entropy labels _once_ at the tunnel-layer and we're done.  IOW, entropy-labels should become a first-class citizen of the overall MPLS architecture, which is goodness.
2)  As an SP, testing entropy-labels at the tunnel layer in all future HW/SW releases that gets pushed out to the network is _much_ more straightforward.  In summary, I would expect it to be much easier to _understand_ and see when entropy-labels are being used at the tunnel layer vs. when & why they are not.  IOW, when troubleshooting it will be much more noticeable that _ALL_ traffic is getting fine-grained load-balancing between a pair of PE's, i.e.: at the tunnel-layer, compared to the machinations one may have to go through to figure out if a _set_ of applications on a PE are _each_ "doing the right thing" wrt signaling entropy-labels for themselves.

One more thing below.

> The downside is that the label stack has one more label because the ELI would be mandatory: <TL, ELI, EL, AL> rather than <TL, AL, EL>.

I am not concerned, in the least, of "burning" an extra 4-Bytes on the wire for an always present ELI: a) all links are already configured for Jumbo frames and will not even notice an extra 4-Bytes; and, b) this is an extremely small price to pay (sorry for the pun), for the substantial and significant CapEx & OpEx savings for ensuring [very] good, fine-grained load-balancing over LAG & ECMP paths in the Core.

> So, the question: should we associate ELs with tunnels rather than with applications (apart from PWs)?  (if no, a short reason why would be helpful.)

EL's with tunnels, please!

-shane

---

From: Alia Atlas <[email-masked]>
Date: Fri, 13 Apr 2012 20:28:17 -0400

I agree with Shane & Kireeti - ELs at the tuunel-layer so it is solved
once and done.

Alia

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 13 Apr 2012 20:29:01 -0400

+1

Regards,
Jeff

---

From: Lucy yong <[email-masked]>
Date: Mon, 16 Apr 2012 21:20:24 +0000

I support the following:
1) use one reserved label for ELI
2) ELs associate with the tunnel layer

Cheers,
Lucy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Friday, April 13, 2012 7:28 PM
To: Shane Amante
Cc: [email-masked]
Subject: Re: [mpls] entropy labels: associate with tunnels or apps?

Alia