Subject: [mpls] Review of draft-renwei-mpls-bgp-big-label-00

From: William McCall <[email-masked]>
Date: Fri, 05 Jul 2013 05:06:08 -0500

This is my first review, so please feel free to correct me on procedure, 
etc.

In the introduction, the problem statement revolves around L3VPNs and 
large numbers of labels needed in an environment with ~16 million 
virtual networks in conjunction with work in VXLAN, NVGRE and NVO3. In 
it, the proposal is to extend the MPLS label size by assigning a 
reserved label to indicate that a 32 bit label immediately follows.

Among my observations are the following--

[technical]

1) BGP/MPLS L3VPNs can convey label stacks per rfc3107. What would this 
change alleviate that could not already be solved by adding another 
label to the stack?

2) If the label size is to be extended in this manner, would it be 
expected to create a separate label space for 32-bit values? If not, 
would the 20-bit label range be excluded from use in the 32-bit labels? 
This should be clarified. The only statement regarding this from the doc is:

" When an MPLS LSR receivs an MPLS packet, it reads out the MPLS label. 
If the MPLS label is a Big Label Indicator, it will use the subsequent 
32-bit value as the MPLS label for the forwarding purpose."

[editorial]

3) Obsolete RFC 2547 is referenced.

4) A few miscellaneous wording changes could be used. I can discuss in private to avoid spamming the list.

Thanks,

--WM

---

From: William McCall <[email-masked]>
Date: Fri, 05 Jul 2013 05:34:03 -0500

So sorry, but I referenced the wrong draft.

On 07/05/2013 05:06 AM, William McCall wrote:
> This is my first review, so please feel free to correct me on 
> procedure, etc.
>
> 1) BGP/MPLS L3VPNs can convey label stacks per rfc3107. What would 
> this change alleviate that could not already be solved by adding 
> another label to the stack?
>
> would the 20-bit label range be excluded from use in the 32-bit 
> labels? This should be clarified. The only statement regarding this 
> from the doc is:
>
> " When an MPLS LSR receivs an MPLS packet, it reads out the MPLS 
> label. If the MPLS label is a Big Label Indicator, it will use the 
> subsequent 32-bit value as the MPLS label for the forwarding purpose."
>
> [editorial]
>

---

From: Eric Rosen <[email-masked]>
Date: Fri, 05 Jul 2013 11:50:05 -0400

> What would this change alleviate that could not already be solved by
> adding another label to the stack?

Excellent point.

Please see also section 3 (especially the last paragraph) of RFC 5331 on
"context labels".  By using one label as a "context label" identifying a
context in which the subsequent label is interpreted, one gets the effect of
a 40-bit label space, and the same mechanism can also be used to support
upstream-assigned labels.

It's also worth noting that the "big label" proposal would probably end up
using three label stack entries per big label: special purpose label
indicator, big label indicator, big label value.  The use of context labels
will require only two label stack entries.

---

From: Richard Li <[email-masked]>
Date: Wed, 17 Jul 2013 15:38:12 +0000

Hi!

Thanks for the comments. And I am sorry for the late reply; I was on vacations.

Now let me clarify and explain why we need something like big labels.

1. 
You do have a good point here. Yes, it is true that one can always get a bigger label space by stacking labels over labels. The combination of two "small" labels may achieve what a "big" label can do. But their fundamental concepts and the consequences will be totally different. Conceptually, a label has four components:  label value, BOS indicator, the EXP bits and the TTL value. If you use two "small" labels to represent a "big" label, you will run into TWO BOS indicators, TWO EXP bits, and TWO TTL values. You can semantically combine the two label values, but you can't combine other fields such as TTL. If the two labels are collectively considered as ONE label, they should have one TTL, one EXP, and one BOS since they should be treated and processed as a single and inseparable entity. Having multiple TTLs/EXPs/BOSes is conceptually counter-intuitive against the very idea of "a label". 

2. 
Context was introduced in the context of upstream-assigned labels for multicast LSPs. It provides the concept of context, but it doesn't provide the concept of "big labels". The label itself is still 20 bits in length. The label space in a context is not expanded; it is still 1M. 

3. 
If you use context labels, you will need 16 contexts since each context will only hold 1M labels. Which label belongs to which context will be very arbitrary; If someone put a label in one context, it won't be wrong if another one put the same label in a different context. There is no semantic association at all between contexts and labels, which is different from the situation about contexts for upstream-assigned labels where one simply can't put upstream-assigned labels in an arbitrary context.

4. 
In this proposal, we only need two 32-bit entries for a "big label": the big label indicator + big label value. The big label indicator is a reserved label. We don't need three label entries in an MPLS packet.

5.
With respect to the BGP protocol, the "big label" proposal has some scaling benefits over the context-based solution. If you use context labels, you will need to add 64 extra bits in BGP's NLRI: context label and a secondary label.  But if you use the big label proposal in this draft, you will only need to add 32 bits:  big label value. Saving the extra 32 bits to each VPN route can be a big deal, especially when we are talking about up to 16M VPNs here for virtualized networks currently being standardized by NVO3/VXLAN/NVGRE.

6.
In the operating system and line cards, the "big label" proposal also has some benefits over the context-based solution. If you use contexts, you have to store the context label in conjunction with the VPN label. But if you use the big label proposal, you only need an attribute flag bit to mean the VPN label is a big one. The same thing holds true in the forwarding software. 

Regards,

Richard

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]] 
Sent: Friday, July 05, 2013 11:50 PM
To: William McCall
Cc: [email-masked]; Richard Li; Mli; [email-masked]
Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00)

Excellent point.

Please see also section 3 (especially the last paragraph) of RFC 5331 on "context labels".  By using one label as a "context label" identifying a context in which the subsequent label is interpreted, one gets the effect of a 40-bit label space, and the same mechanism can also be used to support upstream-assigned labels.

It's also worth noting that the "big label" proposal would probably end up using three label stack entries per big label: special purpose label indicator, big label indicator, big label value.  The use of context labels will require only two label stack entries.

---

From: "Nagendra Kumar (naikumar)" <[email-masked]>
Date: Wed, 17 Jul 2013 17:46:10 +0000

Hi Richard,

Is the proposal is to use the big label indicator only when the label size is more than 20 bits?.  If not, I think it is a trade off between label stack size vs fwding semantic. With big label, any service like VPN will require 2 big label indicator (each 32 bits) and 2 * 32 bits big label (IGP label and application label) which is equivalent to 4 labels. But with context label, it is going to be 3 labels.

While context label is explained in terms of upstream label for MP-LSP, I think nothing stops its usage for unicast LSP. 

-Nagendra

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Li
Sent: Wednesday, July 17, 2013 9:08 PM
To: Eric Rosen (erosen); William McCall
Cc: Mli; [email-masked]
Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00)

Hi!

1. 

2. 

3. 

4. 

5.

6.

Regards,

Richard

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]] 
Sent: Friday, July 05, 2013 11:50 PM
To: William McCall
Cc: [email-masked]; Richard Li; Mli; [email-masked]
Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00)

Excellent point.

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

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 17 Jul 2013 18:39:41 +0000

Hi Richard,

I agree with Eric and Nagendra. What you want is achievable with context-based label. Please see my comments inline.

Thanks
Shahram 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nagendra Kumar (naikumar)
Sent: Wednesday, July 17, 2013 10:46 AM
To: Richard Li; Eric Rosen (erosen); William McCall
Cc: Mli; [email-masked]
Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00)

Hi Richard,

-Nagendra

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Li
Sent: Wednesday, July 17, 2013 9:08 PM
To: Eric Rosen (erosen); William McCall
Cc: Mli; [email-masked]
Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00)

Hi!

1. 

SD> There are 2 TTL/EXP/BOS but you could configure the same TTL and EXP for both labels (redundant). 

2. 

SD> Multicast was one of the applications of context-based lookup. This can be another application.  The labels space with context is not 1M anymore. It is 1Mx1M. Because for context-based MPLS lookup does a 40-bit lookup.

3. 

SD> I think you have may not have understood the context label well. The context label tells you the meaning of the label under it. Think of it as 40 bit label, that is how it works. 

4. 

SD>  draft-ietf-mpls-special-purpose-labels-03.txt from now on requires using a special label indicator before the special big label indicator. So you need 3 labels.

5.

SD> BGP packet size is not an issue, after all it is just control packet.

6.

SD> Also in big label you have to store a 32-bit label value instead of 20 bit label. But the advantage of context-based method is that you won't need new hardware. While for big label you will need new hardware.

Regards,

Richard

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]] 
Sent: Friday, July 05, 2013 11:50 PM
To: William McCall
Cc: [email-masked]; Richard Li; Mli; [email-masked]
Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00)

Excellent point.

---

From: John E Drake <[email-masked]>
Date: Wed, 17 Jul 2013 19:06:45 +0000

Shahram,

Your email, below, is excellent. 

Yours Irrespectively,

John

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Shahram Davari
> Sent: Wednesday, July 17, 2013 11:40 AM
> To: Nagendra Kumar (naikumar); Richard Li; Eric Rosen (erosen); William
> McCall
> Cc: Mli; [email-masked]
> Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was:
> Review of draft-renwei-mpls-bgp-big-label-00)
> 
> Hi Richard,
> 
> I agree with Eric and Nagendra. What you want is achievable with
> context-based label. Please see my comments inline.
> 
> Thanks
> Shahram
> 
> Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was:
> Review of draft-renwei-mpls-bgp-big-label-00)
> 
> Hi Richard,
> 
> Is the proposal is to use the big label indicator only when the label
> size is more than 20 bits?.  If not, I think it is a trade off between
> label stack size vs fwding semantic. With big label, any service like
> VPN will require 2 big label indicator (each 32 bits) and 2 * 32 bits
> big label (IGP label and application label) which is equivalent to 4
> labels. But with context label, it is going to be 3 labels.
> 
> While context label is explained in terms of upstream label for MP-LSP,
> I think nothing stops its usage for unicast LSP.
> 
> -Nagendra
> 
> Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was:
> Review of draft-renwei-mpls-bgp-big-label-00)
> 
> Hi!
> 
> You do have a good point here. Yes, it is true that one can always get
> a bigger label space by stacking labels over labels. The combination of
> two "small" labels may achieve what a "big" label can do. But their
> fundamental concepts and the consequences will be totally different.
> Conceptually, a label has four components:  label value, BOS indicator,
> the EXP bits and the TTL value. If you use two "small" labels to
> represent a "big" label, you will run into TWO BOS indicators, TWO EXP
> bits, and TWO TTL values. You can semantically combine the two label
> values, but you can't combine other fields such as TTL. If the two
> labels are collectively considered as ONE label, they should have one
> TTL, one EXP, and one BOS since they should be treated and processed as
> a single and inseparable entity. Having multiple TTLs/EXPs/BOSes is
> conceptually counter-intuitive against the very idea of "a label".
> 
> Context was introduced in the context of upstream-assigned labels for
> multicast LSPs. It provides the concept of context, but it doesn't
> provide the concept of "big labels". The label itself is still 20 bits
> in length. The label space in a context is not expanded; it is still
> 1M.
> 
> SD> Multicast was one of the applications of context-based lookup. This
> can be another application.  The labels space with context is not 1M
> anymore. It is 1Mx1M. Because for context-based MPLS lookup does a 40-
> bit lookup.
> 
> 3.
> If you use context labels, you will need 16 contexts since each context
> will only hold 1M labels. Which label belongs to which context will be
> very arbitrary; If someone put a label in one context, it won't be
> wrong if another one put the same label in a different context. There
> is no semantic association at all between contexts and labels, which is
> different from the situation about contexts for upstream-assigned
> labels where one simply can't put upstream-assigned labels in an
> arbitrary context.
> 
> SD> I think you have may not have understood the context label well.
> The context label tells you the meaning of the label under it. Think of
> it as 40 bit label, that is how it works.
> 
> 4.
> In this proposal, we only need two 32-bit entries for a "big label":
> the big label indicator + big label value. The big label indicator is a
> reserved label. We don't need three label entries in an MPLS packet.
> 
> SD>  draft-ietf-mpls-special-purpose-labels-03.txt from now on requires
> using a special label indicator before the special big label indicator.
> So you need 3 labels.
> 
> 5.
> With respect to the BGP protocol, the "big label" proposal has some
> scaling benefits over the context-based solution. If you use context
> labels, you will need to add 64 extra bits in BGP's NLRI: context label
> and a secondary label.  But if you use the big label proposal in this
> draft, you will only need to add 32 bits:  big label value. Saving the
> extra 32 bits to each VPN route can be a big deal, especially when we
> are talking about up to 16M VPNs here for virtualized networks
> currently being standardized by NVO3/VXLAN/NVGRE.
> 
> In the operating system and line cards, the "big label" proposal also
> has some benefits over the context-based solution. If you use contexts,
> you have to store the context label in conjunction with the VPN label.
> But if you use the big label proposal, you only need an attribute flag
> bit to mean the VPN label is a big one. The same thing holds true in
> the forwarding software.
> 
> SD> Also in big label you have to store a 32-bit label value instead of
> 20 bit label. But the advantage of context-based method is that you
> won't need new hardware. While for big label you will need new
> hardware.
> 
> 
> Regards,
> 
> 
> Richard
> 
> 
> 
> Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was:
> Review of draft-renwei-mpls-bgp-big-label-00)
> 
> 
> Please see also section 3 (especially the last paragraph) of RFC 5331
> on "context labels".  By using one label as a "context label"
> identifying a context in which the subsequent label is interpreted, one
> gets the effect of a 40-bit label space, and the same mechanism can
> also be used to support upstream-assigned labels.
> 
> It's also worth noting that the "big label" proposal would probably end
> up using three label stack entries per big label: special purpose label
> indicator, big label indicator, big label value.  The use of context
> labels will require only two label stack entries.
> 
>

---

From: Richard Li <[email-masked]>
Date: Wed, 17 Jul 2013 22:25:02 +0000

Hi Nagendra,

Actually, only one big label indicator is needed. Not two.

When you send packets from the customer side to the data center side, you need three labels: transport label + big label indicator + big label value.
When you send packets from the data center side to the customer side, you need two labels as before: transport label + VPN label.

Regards,

Richard

-----Original Message-----
From: Nagendra Kumar (naikumar) [mailto:[email-masked]] 
Sent: Thursday, July 18, 2013 1:46 AM
To: Richard Li; Eric Rosen (erosen); William McCall
Cc: Mli; [email-masked]
Subject: RE: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00)

Hi Richard,

-Nagendra

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Li
Sent: Wednesday, July 17, 2013 9:08 PM
To: Eric Rosen (erosen); William McCall
Cc: Mli; [email-masked]
Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00)

Hi!

1. 

2. 

3. 

4. 

5.

6.

Regards,

Richard

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]] 
Sent: Friday, July 05, 2013 11:50 PM
To: William McCall
Cc: [email-masked]; Richard Li; Mli; [email-masked]
Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00)

Excellent point.

---

From: Richard Li <[email-masked]>
Date: Wed, 17 Jul 2013 23:04:45 +0000

In line with <RL> prefix...

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Thursday, July 18, 2013 2:40 AM
To: Nagendra Kumar (naikumar); Richard Li; Eric Rosen (erosen); William McCall
Cc: Mli; [email-masked]
Subject: RE: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00)

Hi Richard,

Thanks
Shahram 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nagendra Kumar (naikumar)
Sent: Wednesday, July 17, 2013 10:46 AM
To: Richard Li; Eric Rosen (erosen); William McCall
Cc: Mli; [email-masked]
Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00)

Hi Richard,

-Nagendra

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Li
Sent: Wednesday, July 17, 2013 9:08 PM
To: Eric Rosen (erosen); William McCall
Cc: Mli; [email-masked]
Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00)

Hi!

1. 

<RL>  Does user like to configure more or less? Is redundancy a good thing or bad one?

2. 

<RL> I am talking about the concept here. In context-based label, there is a sub-stack of two label entries. 

3. 

<RL> Please do a simple math. In order to achieve the 16M goal, how many context labels you will need? And how are you going to allocate those labels in your implementation.

4. 

5.

<RL> I am not sure if I should agree. Here we are dealing with a problem with potentially 16M VPNs. When you add 32 bits to a BGP packet, you need to read and write. For me, I have been always sensitive to the BGP reconvergence time.

6.

<RL> It depends on your line card. If you use ASIC, perhaps you are right. But if you use NP, you don't need new hardware. Actually, no matter you need to store 20 bits or 32 bits, you always need a long integer in NP.

Regards,

Richard

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]] 
Sent: Friday, July 05, 2013 11:50 PM
To: William McCall
Cc: [email-masked]; Richard Li; Mli; [email-masked]
Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00)

Excellent point.

---

From: William McCall <[email-masked]>
Date: Thu, 18 Jul 2013 00:40:15 -0500

My simpleton observations to the responses below tagged with <wm>.

On 07/17/2013 06:04 PM, Richard Li wrote:
> Cc: Mli;[email-masked]
> From:[email-masked]  [mailto:[email-masked]] On Behalf Of Nagendra Kumar (naikumar)
> Cc: Mli;[email-masked]
> From:[email-masked]  [mailto:[email-masked]] On Behalf Of Richard Li
> Cc: Mli;[email-masked]
<wm>Maybe there should be clarification on the appropriate way to do 
this in context labels. I haven't found anything that clarifies this, 
but I reckon it isn't the biggest problem anyway.
> <RL> I am talking about the concept here. In context-based label, there is a sub-stack of two label entries.
<wm>I don't get this point at all. It's two 32 bit values anyway. Either 
two labels or a standard label and a 32 bit label (and IRL, probably 2 
standard labels per #4 below). And bits are wasted in the standard 
label. The context label and the next label can mean whatever the PE 
wants it to mean as far as I can tell.
> <RL> Please do a simple math. In order to achieve the 16M goal, how many context labels you will need? And how are you going to allocate those labels in your implementation.
<wm>The allocations can be done however the PE pleases. "Context" is, in 
my simple mind, a misnomer. It is just another way of saying "if you see 
this label here, it means read the next label too and make it into one 
big label," however the implementation defines it. And it's 
interpretation is local to the PE, so I see no need for any other nodes 
to care nor for the specific implementations to be much of a driver in a 
comparison in the standards process.
> SD>  draft-ietf-mpls-special-purpose-labels-03.txt from now on requires using a special label indicator before the special big label indicator. So you need 3 labels.
<wm>This alone makes the idea a deal breaker for my opinion unless there 
is agreement to hook this up with a reserved label. Furthermore, I think 
using a reserved label for this is a bad idea.

> <RL> I am not sure if I should agree. Here we are dealing with a problem with potentially 16M VPNs. When you add 32 bits to a BGP packet, you need to read and write. For me, I have been always sens…
<wm>Maybe. But does it justify having to upgrade every PE's/RR's BGPd 
out there to support this? I can put a label stack in NLRI today without 
having to jump through software upgrade hoops and the associated 
entities screaming about having to do the upgrade. Personally, I would 
prefer to avoid playing with BGP code more than I have to.
> <RL> It depends on your line card. If you use ASIC, perhaps you are right. But if you use NP, you don't need new hardware. Actually, no matter you need to store 20 bits or 32 bits, you always need…
<wm>This is my main concern: that this idea will break in ASICs. Too 
many are deployed today. You deploy a 32 bit label and distribute it to 
a PE with ASICs that cannot support this. Are we going to now punt to 
rewrite the packet? That would be pretty awful. I think most of them 
will be fine with an old school label stack though. Someone may show me 
to be wrong on this though.
> Cc:[email-masked]; Richard Li; Mli;[email-masked]

---

From: Richard Li <[email-masked]>
Date: Thu, 18 Jul 2013 08:01:39 +0000

Hi Bill,

Thanks for comments. In line with <RL> prefix.

> <RL>  Does user like to configure more or less? Is redundancy a good thing or bad one?
<wm>Maybe there should be clarification on the appropriate way to do this in context labels. I haven't found anything that clarifies this, but I reckon it isn't the biggest problem anyway.

<RL> I always believe that to have more config and redundancy is something we should avoid. Maybe I am too biased.

> <RL> I am talking about the concept here. In context-based label, there is a sub-stack of two label entries.
<wm>I don't get this point at all. It's two 32 bit values anyway. Either two labels or a standard label and a 32 bit label (and IRL, probably 2 standard labels per #4 below). And bits are wasted in the standard label. The context label and the next label can mean whatever the PE wants it to mean as far as I can tell.

<RL> Their interpretations are different, and thus they will yield to different consequences. For the context approach, there are two labels. For the big label approach, there is only one label. And thus, for the context approach the BGP needs to carry two labels, while for the big label approach the BGP carries only one label.

> <RL> Please do a simple math. In order to achieve the 16M goal, how many context labels you will need? And how are you going to allocate those labels in your implementation.
<wm>The allocations can be done however the PE pleases. "Context" is, in my simple mind, a misnomer. It is just another way of saying "if you see this label here, it means read the next label too and make it into one big label," however the implementation defines it. And it's interpretation is local to the PE, so I see no need for any other nodes to care nor for the specific implementations to be much of a driver in a comparison in the standards process.

<RL> Actually context was not a misnomer when it was proposed. It was a perfect name. But now when it is used (or misused) to attempt to achieve the effect of big labels, it becomes a misnomer. For the upstream-assigned labels, all of them are in the same context. But now VPN labels can't be in the same context. Isn't it weird and counter-intuitive?

> <RL> I am not sure if I should agree. Here we are dealing with a problem with potentially 16M VPNs. When you add 32 bits to a BGP packet, you need to read and write. For me, I have been always sens…
<wm>Maybe. But does it justify having to upgrade every PE's/RR's BGPd out there to support this? I can put a label stack in NLRI today without having to jump through software upgrade hoops and the associated entities screaming about having to do the upgrade. Personally, I would prefer to avoid playing with BGP code more than I have to.

<RL> No matter if you use context or big label, you will have to change BGP codes. I haven't seen any commercial BGP software to carry context + vpn label for L3VPN. Actually, the changes are very minimal.

> <RL> It depends on your line card. If you use ASIC, perhaps you are right. But if you use NP, you don't need new hardware. Actually, no matter you need to store 20 bits or 32 bits, you always need…
<wm>This is my main concern: that this idea will break in ASICs. Too many are deployed today. You deploy a 32 bit label and distribute it to a PE with ASICs that cannot support this. Are we going to now punt to rewrite the packet? That would be pretty awful. I think most of them will be fine with an old school label stack though. Someone may show me to be wrong on this though.

<RL> Even for context labels, I believe you still need to change your ASICs since you have to let your ASICs to take 40 bits as a whole. 

Regards,

Richard

---

From: Pablo Frank <[email-masked]>
Date: Thu, 18 Jul 2013 13:24:46 -0400

No matter how you look at it, it's a fundamentally different forwarding
paradigm.  It won't be implementable in some existing and deployed
hardware.  Sure, NPU-based or FPGA-based forwarding hardware could
implement it but the reason that there are ASICs out there with hard MPLS
dataplanes is because the MPLS dataplane is mature and has been a de facto
standard for a long time.  Now, if you want to make the case for some kind
of "MPLSv6", maybe you'll find others willing to embark on that scary
adventure...

On Wed, Jul 17, 2013 at 7:04 PM, Richard Li <[email-masked]> wrote:

> Nagendra Kumar (naikumar)
> Is the proposal is to use the big label indicator only when the label size
> is more than 20 bits?.  If not, I think it is a trade off between label
> stack size vs fwding semantic. With big label, any service like VPN will
> require 2 big label indicator (each 32 bits) and 2 * 32 bits big label (IGP
> label and application label) which is equivalent to 4 labels. But with
> context label, it is going to be 3 labels.
>
> While context label is explained in terms of upstream label for MP-LSP, I
> think nothing stops its usage for unicast LSP.
>
> -Nagendra
>
> Richard Li
> You do have a good point here. Yes, it is true that one can always get a
> bigger label space by stacking labels over labels. The combination of two
> "small" labels may achieve what a "big" label can do. But their fundamental
> concepts and the consequences will be totally different. Conceptually, a
> label has four components:  label value, BOS indicator, the EXP bits and
> the TTL value. If you use two "small" labels to represent a "big" label,
> you will run into TWO BOS indicators, TWO EXP bits, and TWO TTL values. You
> can semantically combine the two label values, but you can't combine other
> fields such as TTL. If the two labels are collectively considered as ONE
> label, they should have one TTL, one EXP, and one BOS since they should be
> treated and processed as a single and inseparable entity. Having multiple
> TTLs/EXPs/BOSes is conceptually counter-intuitive against the very idea of
> "a label".
>
> multicast LSPs. It provides the concept of context, but it doesn't provide
> the concept of "big labels". The label itself is still 20 bits in length.
> The label space in a context is not expanded; it is still 1M.
>
> anymore. It is 1Mx1M. Because for context-based MPLS lookup does a 40-bit
> lookup.
>
> will only hold 1M labels. Which label belongs to which context will be very
> arbitrary; If someone put a label in one context, it won't be wrong if
> another one put the same label in a different context. There is no semantic
> association at all between contexts and labels, which is different from the
> situation about contexts for upstream-assigned labels where one simply
> can't put upstream-assigned labels in an arbitrary context.
>
> SD> I think you have may not have understood the context label well. The
> context label tells you the meaning of the label under it. Think of it as
> 40 bit label, that is how it works.
>
> <RL> Please do a simple math. In order to achieve the 16M goal, how many
> context labels you will need? And how are you going to allocate those
> labels in your implementation.
>
>
>
>
> 4.
> In this proposal, we only need two 32-bit entries for a "big label": the
> big label indicator + big label value. The big label indicator is a
> using a special label indicator before the special big label indicator. So
> you need 3 labels.
>
> 5.
> labels, you will need to add 64 extra bits in BGP's NLRI: context label and
> a secondary label.  But if you use the big label proposal in this draft,
> you will only need to add 32 bits:  big label value. Saving the extra 32
> bits to each VPN route can be a big deal, especially when we are talking
> about up to 16M VPNs here for virtualized networks currently being
> standardized by NVO3/VXLAN/NVGRE.
>
> <RL> I am not sure if I should agree. Here we are dealing with a problem
> with potentially 16M VPNs. When you add 32 bits to a BGP packet, you need
> to read and write. For me, I have been always sensitive to the BGP
> reconvergence time.
>
>
>
> 6.
> In the operating system and line cards, the "big label" proposal also has
> some benefits over the context-based solution. If you use contexts, you
> have to store the context label in conjunction with the VPN label. But if
> you use the big label proposal, you only need an attribute flag bit to mean
> the VPN label is a big one. The same thing holds true in the forwarding
> software.
>
> SD> Also in big label you have to store a 32-bit label value instead of 20
> bit label. But the advantage of context-based method is that you won't need
> new hardware. While for big label you will need new hardware.
>
> <RL> It depends on your line card. If you use ASIC, perhaps you are right.
> But if you use NP, you don't need new hardware. Actually, no matter you
> need to store 20 bits or 32 bits, you always need a long integer in NP.
>
>
> Regards,
>
>
> Richard
>
>
>
> context in which the subsequent label is interpreted, one gets the effect
> of a 40-bit label space, and the same mechanism can also be used to support

---

From: Saku Ytti <[email-masked]>
Date: Thu, 18 Jul 2013 20:39:55 +0300

> of "MPLSv6", maybe you'll find others willing to embark on that scary

I've been worrying about this same thing very often lately. I have same
issue with several other new MPLS enhancements which essentially mean when
magic label is hit, your behavior changes.

I understand rationale why many of the enhancements are needed, but I
wonder if doing 'MPLSv2' would be in the end be cleaner solution. If you
cannot support old ASIC platforms and you essentially need NPU based
platform, then you might as well be bit more progressive?

-- 
  ++ytti

---

From: Richard Li <[email-masked]>
Date: Thu, 18 Jul 2013 23:57:45 +0000

Hi Saku,

I am very interested in knowing what are those new MPLS enhancements you are having issues with. Can you share them with this community?

MPLS has been alive for about 15 years. A teenager often changes and is different from when it was born.

Thanks,

Richard

From: Saku Ytti [mailto:[email-masked]]
Sent: Friday, July 19, 2013 1:40 AM
To: Pablo Frank
Cc: Richard Li; [email-masked]; Mli; Nagendra Kumar (naikumar)
Subject: Re: [mpls] Review of draft-renwei-mpls-big-label-00 (was: Review of draft-renwei-mpls-bgp-big-label-00)

On 18 July 2013 20:24, Pablo Frank <[email-masked]<mailto:[email-masked]>> wrote:
No matter how you look at it, it's a fundamentally different forwarding paradigm.  It won't be implementable in some existing and deployed hardware.  Sure, NPU-based or FPGA-based forwarding hardware could implement it but the reason that there are ASICs out there with hard MPLS dataplanes is because the MPLS dataplane is mature and has been a de facto standard for a long time.  Now, if you want to make the case for some kind of "MPLSv6", maybe you'll find others willing to embark on that scary adventure...

I've been worrying about this same thing very often lately. I have same issue with several other new MPLS enhancements which essentially mean when magic label is hit, your behavior changes.

I understand rationale why many of the enhancements are needed, but I wonder if doing 'MPLSv2' would be in the end be cleaner solution. If you cannot support old ASIC platforms and you essentially need NPU based platform, then you might as well be bit more progressive?

--
  ++ytti

---

From: Saku Ytti <[email-masked]>
Date: Fri, 19 Jul 2013 11:02:44 +0300

On 19 July 2013 02:57, Richard Li <[email-masked]> wrote:

Hello Richard,

I am very interested in knowing what are those new MPLS enhancements you
> are having issues with. Can you share them with this community?
>
Top of my head  draft-ietf-mpls-special-purpose-labels and
this draft-renwei-mpls-big-label.

> different from when it was born.
Absolutely, I don't disagree that the drafts don't solve real issue.

To me, inability to capitalize on the new features on old ASIC gear and the
fact that deployed NPU plaforms (Huawei NE/CX, Cisco ASR9k, Juniper MX,
Alcatel SR etc) all could today support pretty much arbitrary half-sane
wire-format for MPLS, seems to indicate that it might be useful to review
what would be benefits of more progressive changes to wire-format.

Some issues I'd like to handle:

a) retaining label history
b) low byte overhead (this is MPLS's major selling point against IP
tunnels. Our TTL and COS are redundant repeated information for majority of
use-cases)
c) remove need for transit P duck-typing/guessing payload (this makes P
more complex than it must be)
d) extendable by design (today we essentially need 8B for every 1-4B we
want to add)
e) increased label space
f) coexistance with MPLSv1 for gradual/partial deployment

-- 
  ++ytti

---

From: Eric Rosen <[email-masked]>
Date: Fri, 19 Jul 2013 14:29:02 -0400

> If you use two "small" labels to represent a "big" label, you will run
> into  TWO BOS indicators, TWO EXP bits, and TWO TTL values ...  Having
> multiple TTLs/EXPs/BOSes is conceptually counter-intuitive

This seems like something that is of no consequence (no practical import).
That is, this doesn't seem to be a technical argument.

> The label space in a context is not expanded; it is still 1M.

Per context label.

> Which label belongs to which context will be very arbitrary; If someone
> put a label in one context, it won't be wrong if another one put the same
> label in a different context.

One of the characteristics of MPLS is that the label value that gets bound
to a given FEC by a given LSR is arbitrary.  If you use a pair of labels to
represent a given FEC, of course the value of the label pair is arbitrary.

> There is no semantic association at all between contexts and labels, which
> is different from the situation about contexts for upstream-assigned
> labels where one simply can't put upstream-assigned labels in an arbitrary
> context.

The only requirement on the use of labels is that the LSR imposing the label
(or label pair) and the LSR interpreting the label (or label pair) have a
common understanding of the FEC that is represented by that label (or label
pair).  MPLS requires no other "semantic associations".

> reserved label. We don't need three label entries in an MPLS packet.

As others have pointed out, the "big label indicator" may itself require two
label stack entries.

> If you use context labels, you will need to add 64 extra bits in BGP's
> NLRI: context label and a secondary label.  But if you use the big label
> proposal in this draft, you will only need to add 32 bits:

This is a "red herring".  The encoding technique used to represent a label
in BGP is unrelated to the representation of the labels in the data plane.

> you use the big label proposal, you only need an attribute flag bit to
> mean the VPN label is a big one. The same thing holds true in the
> forwarding software.

This doesn't seem like a very thorough analysis of implementation
techniques. 

Context labels are really just a technique that allows MPLS to support (a)
upstream-assigned labels, (b) downstream-assigned labels that are only valid
when preceded by a particular "context label", and (c) larger than 20-bit
label space.  The "big label" proposal only does (c), not (a) or (b).  To
argue for the "big label" proposal, one would have to argue that it has
implementation advantages in the forwarding plane (ASICs, NPUs) that
outweigh the fact that it provides less functionality.

---

From: Loa Andersson <[email-masked]>
Date: Sun, 21 Jul 2013 19:56:21 +0200

Eric,

correct me if I'm wrong but I think that your response below is a
bit off the mark.

For the TC field (four years since we changed name), you you are in 
control of the field for both the labels when you create the packet
and can set them to whatever you want (given any normal rules
applicable in your network).

RFC 3443 allow you to make the TTL behave as a single TLL for the
entire label stack or for a set of labels within the stack if you
want to do that.

So not only of no consequence, but also a solved "problem".

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64