Subject: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

From: Stewart Bryant <[email-masked]>
Date: Mon, 20 Jul 2015 16:55:30 +0100

I am curious about how much is actually saved with the MPLS dataplane
change proposed in this draft.

If this is used in an Ethernet environment the LSR already needs to
remove and replace the Ethernet header.

In many implementations the datalink header and the MPLS outer
label are part of the same re-write string. So what is the true
gain in writing 14 bytes instead of 18 bytes?

... or is this planned for use with some pt-pt data link other
than Ethernet which is required to be constant end to end?

- Stewart

---

From: Shahram Davari <[email-masked]>
Date: Mon, 20 Jul 2015 16:27:39 +0000

Hi Stewart,

This draft actually saves a lot of memory as it requires only very little MPLS entry table and associated processing.
There are only a few Ethernet MAC headers used in MPLS forwarding, typically one MAC per port, but there can be thousands 
Of swapped labels. So it is not a matter of 14 bytes vs 18 bytes.

We have seen this requirement come up from various data enter operators in Segment routing context.

Thanks
Shahram

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Monday, July 20, 2015 8:55 AM
To: [email-masked]
Subject: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

- Stewart

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

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 20 Jul 2015 13:19:41 -0400

On 7/20/2015 12:27 PM, Shahram Davari wrote:
> This draft actually saves a lot of memory as it requires only very
> little MPLS entry table and associated processing. There are only a
> few Ethernet MAC headers used in MPLS forwarding, typically one MAC
> per port, but there can be thousands Of swapped labels. So it is not
> a matter of 14 bytes vs 18 bytes.

This seems like purely a local implementation matter.  You still have to 
look up the label, don't you?  If you want to optimize for the case 
where the top label doesn't actually change its value, just use a 
14-byte rewrite string instead of an 18-byte string for those labels, 
and allow multiple label lookups to result in a pointer to the same 
14-byte rewrite string.

I don't really see the point of the draft, as this optimization does not 
require any architecture changes or any protocol changes.

---

From: Shahram Davari <[email-masked]>
Date: Mon, 20 Jul 2015 18:07:13 +0000

Hi Eric,

The new swapped labels (The outgoing  label that replaces the incoming label) need to be stored in a table. Using this draft reduces the number of swapped labels that needs to be store, regardless of  implementation. Don't you agree?

Thanks
Shahram

---

From: Shahram Davari <[email-masked]>
Date: Mon, 20 Jul 2015 18:11:49 +0000

It also reduces the configuration and management of the new swapped labels.

Thx
SD

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Monday, July 20, 2015 11:07 AM
To: Eric C Rosen; [email-masked]; [email-masked]
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

Hi Eric,

Thanks
Shahram

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 20 Jul 2015 14:43:57 -0400

On 7/20/2015 2:07 PM, Shahram Davari wrote:
> The new swapped labels (The outgoing  label that replaces the
> incoming label) need to be stored in a table. Using this draft
> reduces the number of swapped labels that needs to be stored,
> regardless of  implementation. Don't you agree?

No.  If you notice that the incoming label needs to be 'replaced' by an 
outgoing label of the same value, you could just make the rewrite string 
shorter, so it won't overwrite the top label on the stack.  This seems 
to be what the draft suggests, but it could be done as an optimization 
for the particular case where the incoming and outgoing labels have the 
same value.  You could do this today, as a local implementation 
optimization. There doesn't seem to be any interop issue or any change 
to the data plane semantics.

> It also reduces the configuration and management of the new swapped labels.

We're not discussing whether there are any advantages to the use of 
domain-wide labels.  We're discussing whether the use of domain-wide 
labels requires a change in the forwarding plane architecture.  I just 
don't see that it does.

---

From: "S. Davari" <[email-masked]>
Date: Mon, 20 Jul 2015 11:52:35 -0700

Eric

I agree no standard change is required since this is a local optimization issue.

Regards,
Shahram

> On Jul 20, 2015, at 11:43 AM, Eric C Rosen <[email-masked]> wrote:
> 
> No.  If you notice that the incoming label needs to be 'replaced' by an outgoing label of the same value, you could just make the rewrite string shorter, so it won't overwrite the top label on the stack.  This seems to be what the draft suggests, but it could be done as an optimization for the particular case where the incoming and outgoing labels have the same value.  You could do this today, as a local implementation optimization. There doesn't seem to be any interop issue or any change to the data plane semantics.
> 
> We're not discussing whether there are any advantages to the use of domain-wide labels.  We're discussing whether the use of domain-wide labels requires a change in the forwarding plane architecture.  I just don't see that it does.
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 21 Jul 2015 10:02:36 +0200

As there are no architectural or protocol changes or IANA considerations,
this draft should be informational if it goes forward (it currently says
"standards track").

Cheers,
Andy

On Mon, Jul 20, 2015 at 8:52 PM, S. Davari <[email-masked]> wrote:

> shorter, so it won't overwrite the top label on the stack.  This seems to
> be what the draft suggests, but it could be done as an optimization for the
> particular case where the incoming and outgoing labels have the same
> value.  You could do this today, as a local implementation optimization.
> There doesn't seem to be any interop issue or any change to the data plane
> semantics.
> >
> domain-wide labels.  We're discussing whether the use of domain-wide labels
> requires a change in the forwarding plane architecture.  I just don't see
> that it does.
> >

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 21 Jul 2015 08:26:13 +0000

Andy, Shahram and all,

I may have missed something, but I do not understand why this draft is needed even as an Informational since, as Eric has noticed, it describes a local optimization trick.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

From: mpls [mailto:[email-masked]] On Behalf Of Andrew G. Malis
Sent: Tuesday, July 21, 2015 11:03 AM
To: S. Davari
Cc: [email-masked]
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

As there are no architectural or protocol changes or IANA considerations, this draft should be informational if it goes forward (it currently says "standards track").

Cheers,
Andy

On Mon, Jul 20, 2015 at 8:52 PM, S. Davari <[email-masked]<mailto:[email-masked]>> wrote:
Eric

Regards,
Shahram

> On Jul 20, 2015, at 11:43 AM, Eric C Rosen <[email-masked]<mailto:[email-masked]>> wrote:
>
> [email-masked]<mailto:[email-masked]>

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 21 Jul 2015 10:29:01 +0200

Sasha,

That's why I said "if it goes forward".

Cheers,
Andy

On Tue, Jul 21, 2015 at 10:26 AM, Alexander Vainshtein <
[email-masked]> wrote:

>  Andy, Shahram and all,
>
>
>
> I may have missed something, but I do not understand why this draft is
> needed even as an Informational since, as Eric has noticed, it describes a
> local optimization trick.
>
>
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell:      +972-549266302
>
> *From:* mpls [mailto:[email-masked]] *On Behalf Of *Andrew G. Malis
> *Sent:* Tuesday, July 21, 2015 11:03 AM
> *To:* S. Davari
> *Cc:* [email-masked]
> *Subject:* Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much
> does it really save?
>
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 21 Jul 2015 15:58:09 +0100

This draft proposes architectural changes, and as we can show that
these changes are not needed, in my view, this draft should not go
forward.

- Stewart

On 21/07/2015 09:02, Andrew G. Malis wrote:
> As there are no architectural or protocol changes or IANA 
> considerations, this draft should be informational if it goes forward 
> (it currently says "standards track").
>
> Cheers,
> Andy
>
>
>     > No.  If you notice that the incoming label needs to be
>     'replaced' by an outgoing label of the same value, you could just
>     make the rewrite string shorter, so it won't overwrite the top
>     label on the stack.  This seems to be what the draft suggests, but
>     it could be done as an optimization for the particular case where
>     the incoming and outgoing labels have the same value.  You could
>     do this today, as a local implementation optimization. There
>     doesn't seem to be any interop issue or any change to the data
>     plane semantics.
>     >
>     > We're not discussing whether there are any advantages to the use
>     of domain-wide labels.  We're discussing whether the use of
>     domain-wide labels requires a change in the forwarding plane
>     architecture.  I just don't see that it does.
>     >
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

-- 
For corporate legal information go to:

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 23 Jul 2015 21:58:09 +0200

​Hi Eric,​

> ​​
> If you notice that the incoming label needs to be 'replaced' by an
> particular case where the incoming and outgoing labels have the same value.

​This is precisely ​the crux where your statement fails.

You use term "incoming label" and "outgoing lable" ... well in the new
architectures there is no such things.

It is a "global label" or "path label" with adjacency information.

So to support legacy hardware new control plane has to make up from single
label now two (identical) labels to pass it to data plane. Now also data
plane must be smart to check that and program its state per your
suggestion.

Why would we do that other then due to worry about legacy chipsets feared
to be non compliant to new RFC ?

Many thx,
R.

---

From: Shahram Davari <[email-masked]>
Date: Thu, 23 Jul 2015 21:07:26 +0000

Hi Robert,

How are these labels distributed? Via LDP or via SDN controller?

Thanks
Shahram

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, July 23, 2015 12:58 PM
To: Eric C Rosen
Cc: Shahram Davari; [email-masked]; [email-masked]
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

​Hi Eric,​

​​
If you notice that the incoming label needs to be 'replaced' by an outgoing label of the same value, you could just make the rewrite string shorter, so it won't overwrite the top label on the stack.  This seems to be what the draft suggests, but it could be done as an optimization for the particular case where the incoming and outgoing labels have the same value.

You use term "incoming label" and "outgoing lable" ... well in the new architectures there is no such things.

So to support legacy hardware new control plane has to make up from single label now two (identical) labels to pass it to data plane. Now also data plane must be smart to check that and program its state per your suggestion.

Why would we do that other then due to worry about legacy chipsets feared to be non compliant to new RFC ?

Many thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 23 Jul 2015 23:11:53 +0200

Hi Shahram,

Labels which are non of a local significance can be distributed by flooding
protocols extensions (ISIS, OSPF) or by direct p2p sessions (BGP 3107,
sessions from the controller, XMPP etc ...)

The important part is that the actual forwarding is computed recursively or
set at the controller.

AFAIK I have not seen any proposal where LDP would play any role in such
distribution.

Regards,
R.

On Thu, Jul 23, 2015 at 11:07 PM, Shahram Davari <[email-masked]>
wrote:

> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Thursday, July 23, 2015 12:58 PM
> *To:* Eric C Rosen
> *Cc:* Shahram Davari; [email-masked]; [email-masked]

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 23 Jul 2015 21:14:48 +0000

Hi Robert,
RE: “new architectures”
It does look very much like Ethernet or TRILL. Why not to use one of them?

                Regards,
                                Greg

From: mpls [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, July 23, 2015 9:58 PM
To: Eric C Rosen
Cc: [email-masked]
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

​Hi Eric,​

​​

Many thx,
R.

---

From: Shahram Davari <[email-masked]>
Date: Thu, 23 Jul 2015 21:16:02 +0000

Robert,

So instead of calling it no-swap probably you should call it global label or so, and then define new control plane for it. But seems the data-pane behavior does not change and existing hardware can support this global label.  So maybe you just need new control plane.

Thx
Shahram

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, July 23, 2015 2:12 PM
To: Shahram Davari
Cc: Eric C Rosen; [email-masked]; [email-masked]
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

Hi Shahram,

Labels which are non of a local significance can be distributed by flooding protocols extensions (ISIS, OSPF) or by direct p2p sessions (BGP 3107, sessions from the controller, XMPP etc ...)

The important part is that the actual forwarding is computed recursively or set at the controller.

AFAIK I have not seen any proposal where LDP would play any role in such distribution.

Regards,
R.

On Thu, Jul 23, 2015 at 11:07 PM, Shahram Davari <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Thanks
Shahram

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Thursday, July 23, 2015 12:58 PM
To: Eric C Rosen
Cc: Shahram Davari; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

​Hi Eric,​

​​

Many thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 23 Jul 2015 23:19:03 +0200

Gregory,

I would not compare it to ethernet or trill but more to mpls-tp. But I
think it is advisable to separate discussions about architecture from basic
primitives of mpls.

Cheers,
R.

PS. I am ready to talk about both but let's handle one at a time ;)

On Thu, Jul 23, 2015 at 11:14 PM, Gregory Mirsky <
[email-masked]> wrote:

> *From:* mpls [mailto:[email-masked]] *On Behalf Of *Robert Raszuk
> *Sent:* Thursday, July 23, 2015 9:58 PM
> *To:* Eric C Rosen
> *Cc:* [email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 23 Jul 2015 23:22:19 +0200

The point is that new control plane is already defined. In fact we already
have two :)

As I mentioned in my first mail to the list the concept of NO_SWAP/CONTINUE
is common to both H-SDN and SEGMENT ROUTING architectures.

Ref: https://goo.gl/3oxRbl

Thx,
R.

On Thu, Jul 23, 2015 at 11:16 PM, Shahram Davari <[email-masked]>
wrote:

>  Robert,
>
>
>
> So instead of calling it no-swap probably you should call it global label
> or so, and then define new control plane for it. But seems the data-pane
> behavior does not change and existing hardware can support this global
> label.  So maybe you just need new control plane.
>
>
>
> Thx
> Shahram
>
>
>
> *Sent:* Thursday, July 23, 2015 2:12 PM
> *To:* Shahram Davari
> *Cc:* Eric C Rosen; [email-masked]; [email-masked]
>
> Labels which are non of a local significance can be distributed by
> flooding protocols extensions (ISIS, OSPF) or by direct p2p sessions (BGP
> 3107, sessions from the controller, XMPP etc ...)
>
>
>

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 23 Jul 2015 17:27:53 -0400

> You use term "incoming label" and "outgoing label" ... well in the
> new architectures there is no such things.

The incoming label is the label on the packet when it arrives, and the
outgoing label is the label on the packet when it departs.  If a packet
arrives with a label and leaves with a label, it has an incoming label 
and an outgoing label.  I believe that even in the "new architectures", 
  packets still arrive and depart.

> So to support legacy hardware new control plane has to make up from
> single label now two (identical) labels to pass it to data plane. Now
> also data plane must be smart to check that and program its state
> per your suggestion.

I don't really understand what you are saying here.  The control plane
determines the rewrite string and causes it to be programmed into the
data plane.  There are many ways to implement this interaction.

Are you worried about the following:

> What happens if hardware vendor comes with hardware which exposes to
> control plane API which allow protocols to signal that mpls label Y
> is not to be swapped ? If so which IETF document such API would be
> compliant with ?

I don't understand this point either.  RFC 3031 does not specify an API, 
so it doesn't make any sense to ask whether a particular API is or is 
not compliant with it.

---

From: Shahram Davari <[email-masked]>
Date: Thu, 23 Jul 2015 21:28:05 +0000

Which control planes are already defined for this global label? IS-IS? BGP? If it is defined then what do you need?

Thx
SD

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, July 23, 2015 2:22 PM
To: Shahram Davari
Cc: Eric C Rosen; [email-masked]; [email-masked]
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

The point is that new control plane is already defined. In fact we already have two :)

As I mentioned in my first mail to the list the concept of NO_SWAP/CONTINUE is common to both H-SDN and SEGMENT ROUTING architectures.

Thx,
R.

On Thu, Jul 23, 2015 at 11:16 PM, Shahram Davari <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Thx
Shahram

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Thursday, July 23, 2015 2:12 PM
To: Shahram Davari
Cc: Eric C Rosen; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Shahram,

Regards,
R.

Thanks
Shahram

​Hi Eric,​

​​

Many thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 23 Jul 2015 23:31:51 +0200

Eric,

Going by your logic we would have a notion of "incoming IP address" and
"outgoing IP address" in all routers in the world doing basic non NAT
routing.

While packets still arrive and depart they do not change label value hence
it makes rather limited sense to divide the label they carry into "incoming
label" and "outgoing label". Wouldn't you agree ?

Cheers,
R.

On Thu, Jul 23, 2015 at 11:27 PM, Eric C Rosen <[email-masked]> wrote:

> arrives with a label and leaves with a label, it has an incoming label and
> an outgoing label.  I believe that even in the "new architectures",
> so it doesn't make any sense to ask whether a particular API is or is not
> compliant with it.
>
>
>
>
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 23 Jul 2015 23:36:30 +0200

Hi Shahram,

Both IGP and BGP extensions are proposed.

As described they use the trick of locally defining a NO_SWAP semantics
(for example by defining "CONTINUE" action as "swap to the same label") and
using this notion in their architecture.

They do it as there is no MPLS architecture semantics for that.

Is it possible .. sure.

Is it optimal and good practice going forward .. I do not think so.

Best,
R.

On Thu, Jul 23, 2015 at 11:28 PM, Shahram Davari <[email-masked]>
wrote:

>  Which control planes are already defined for this global label? IS-IS?
> BGP? If it is defined then what do you need?
>
>
>
> Thx
> SD
>
>
>
> *Sent:* Thursday, July 23, 2015 2:22 PM
>
> *To:* Shahram Davari
> As I mentioned in my first mail to the list the concept of
> NO_SWAP/CONTINUE is common to both H-SDN and SEGMENT ROUTING architectures.
>
>
>

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 23 Jul 2015 21:42:13 +0000

Hi Robert,
with global labels and the fact that MPLS doesn’t have source identifier, how one proposes to do OAM, e.g. CC or PM?

                Regards,
                                Greg

From: mpls [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, July 23, 2015 11:37 PM
To: Shahram Davari
Cc: [email-masked]
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

Hi Shahram,

As described they use the trick of locally defining a NO_SWAP semantics (for example by defining "CONTINUE" action as "swap to the same label") and using this notion in their architecture.

Is it possible .. sure.

Best,
R.

On Thu, Jul 23, 2015 at 11:28 PM, Shahram Davari <[email-masked]<mailto:[email-masked]>> wrote:
Which control planes are already defined for this global label? IS-IS? BGP? If it is defined then what do you need?

Thx
SD

To: Shahram Davari

Thx,
R.

Thx
Shahram

Hi Shahram,

Regards,
R.

Thanks
Shahram

​Hi Eric,​

​​

Many thx,
R.

---

From: Eric C Rosen <[email-masked]>
Date: Fri, 24 Jul 2015 12:29:42 -0400

On 7/23/2015 5:31 PM, Robert Raszuk wrote:
> routing

I'm not sure I understand what it means to "have a notion ... in all 
routers".  A given router only needs to implement the functionality that 
it needs to provide to those who are going to deploy it.

However, certainly there is a distinction to be made between "incoming" 
and "outgoing" even in the case of "pure" IP.  The incoming IP header of 
a packet is always different than the outgoing IP header of that packet, 
due to the need to modify the TTL and checksum fields.

In addition, as you point out, the incoming source address field may be 
different than the outgoing source address field, due to NAT.  And use 
of the source routing option can result in there being a difference 
between the incoming destination address field and the outgoing 
destination address field.

Another interesting case is tunnel stitching, where the incoming source 
and destination address fields may both be different than the outgoing 
source and destination address fields.  If you want to optimize for 
tunnel stitching, you precompute the rewrite string, and to the 
forwarding plane it looks like an ordinary case of forwarding a packet.

Of course, if your platform doesn't need to perform any of these 
functions, it doesn't have to implement them.  Similarly, if you think 
that the most common operation (or even the only operation) your 
platform will have to perform on an MPLS packet is "don't modify the 
label stack except for the TTL of the top entry", nothing stops you from 
optimizing for that case.

BTW, I understand perfectly well that there is some controversy about 
whether it is or is not a good idea to use domain-wide labels, but that 
is not a data plane issue, and the use of domain-wide labels does not 
require a change in the data plane architecture.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 24 Jul 2015 18:55:29 +0200

Eric,

This discussion to me is not related to data plane.

I look at it from control plane perspective which needs to pass label
values to date plane.

Creating non standard optimised APIs or YANG models to send single label or
artificially send identical labels an in and out when given architecture
does not have it seems like no-op to me.

Best,
R.
On Jul 24, 2015 6:29 PM, "Eric C Rosen" <[email-masked]> wrote:

> routers".  A given router only needs to implement the functionality that it
> needs to provide to those who are going to deploy it.
>
> and "outgoing" even in the case of "pure" IP.  The incoming IP header of a
> packet is always different than the outgoing IP header of that packet, due
> to the need to modify the TTL and checksum fields.
>
> different than the outgoing source address field, due to NAT.  And use of
> the source routing option can result in there being a difference between
> the incoming destination address field and the outgoing destination address
> field.
>
> source and destination address fields.  If you want to optimize for tunnel
> stitching, you precompute the rewrite string, and to the forwarding plane
> it looks like an ordinary case of forwarding a packet.
>
> functions, it doesn't have to implement them.  Similarly, if you think that
> the most common operation (or even the only operation) your platform will
> have to perform on an MPLS packet is "don't modify the label stack except
> for the TTL of the top entry", nothing stops you from optimizing for that
> case.
>
> whether it is or is not a good idea to use domain-wide labels, but that is
> not a data plane issue, and the use of domain-wide labels does not require
> a change in the data plane architecture.
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 24 Jul 2015 18:08:37 +0100

> require a change in the data plane architecture.

Thank you Eric!

It always saddens me when people choose to implement functional architectures as
though they were design documents for their product. Of course, the resulting
product will be functionally adequate, but it will not perform well. This
problem is well known across a number of standards organizations and we are not
immune, it would seem.

Some other standards bodies produce "equipment specifications" and these seem to
be used by a number of implementers to design their products without considering
best practices or optimizations. Equipment specifications from a  standards body
describe *a* way to achieve the required functionality, but they describe the
internals of a box and that is not something that can or should be standardized.
We specify black boxes and interoperate on the wire.

RFC 3031, as it describes the forwarding plane, is a functional architecture.
When it talks about label operations it describes, in functional terms, things
that happen and change the externally visible behavior (i.e. the packets). It is
completely true that 3031 could have described SWAP as POP'n'PUSH, and could
have introduced a term NO-SWAP equivalent to SWAP-TO-SAME or POP'n'PUSH-SAME.
But it didn't and it didn't lose any generality by doing so.

And it is OK for people to talk about NO-SWAP forwarding. You can even write an
informational I-D to say "There is an optimization in the MPLS forwarding plane
when the same label is used on a packet that comes in and goes out." I don't
believe such a document is needed, but why not write it if it helps you or you
strongly feel it might help others? It doesn't update 3031, but it provides some
alternative view. And yes, you describe all operations as POP'n'PUSH as well if
you want to, but again, I don't think it is needed.

With respect to domain-wide labels, please consider a network in which a mix of
labels is used. Some are per-interface, some are upstream-assigned, some are
per-platform, and some are global. Some LSPs terminate at this node (POP) and
some don't (SWAP, or NO-SWAP). Perhaps some LSPs are tunnelled onwards from this
node (SWAP or NO-SWAP, followed by PUSH). Perhaps other LSPs are stitched
(POP'n'PUSH, or SWAP, or NO-SWAP). When you receive a packet on an interface you
will have to examine the label and do some form of look-up. You cannot simply do
pass-through (decrementing and checking the TTL). You have to look up the label
at least to find out what type of label it is and decide what to do with it. The
look-up may be into a range or into the NHLFE for a one-to-one mapping. Etc.,
etc.

3031 does not mention global labels except for the special purpose label space.
That could be fixed with an update, or it could be observed that the global
label space is actually a mirrored (or distributed) per-platform label space
where each LSR uses the same label for the same destination. Which, by the
 way, is why SR could be supported using LDP (not that I am saying you'd want to
do this).

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 24 Jul 2015 18:15:35 +0100

Robert, 
You want to specify the interface between control plane and data plane?
That's OK (although it may have been done once or twice before).
And if you want to specify the interface between the management plane and the data plane, that is also OK (although it has been done before as well).
 
If you want to specify that for a packet with incoming label the operation is NO-SWAP, that's OK.
But note that your data model (to be generic) is going to need to also support SWAP.
Thus, you will have objects...
IN-INTERFACE (ifid)
IN-LABEL (label)
OPERATION {POP, PUSH, SWAP, NO-SWAP} 
OUT-INTERFACE (ifid)
OUT-LABEL (label)
 
Setting OPERATION to NO-SWAP saves you from setting OUT-LABEL, but doesn't save you from needing the object in your data model. So it is a trade in the design of the data model and either approach is fine. 
 
You can see a similar model in the LSR MIB module (3813 IIRC) and in the olde ATM MIB modules.
 
None of the above has the slightest to do with 3031 being right or wrong.
 
Adrian

Sent: 24 July 2015 17:55
To: Eric Rosen
 
Eric,
This discussion to me is not related to data plane.
I look at it from control plane perspective which needs to pass label values to date plane.
Creating non standard optimised APIs or YANG models to send single label or artificially send identical labels an in and out when given architecture does not have it seems like no-op to me.
Best,
R.
On Jul 24, 2015 6:29 PM, "Eric C Rosen" <[email-masked]> wrote:
On 7/23/2015 5:31 PM, Robert Raszuk wrote:
Going by your logic we would have a notion of "incoming IP address" and
"outgoing IP address" in all routers in the world doing basic non NAT
routing

I'm not sure I understand what it means to "have a notion ... in all routers".  A given router only needs to implement the functionality that it needs to provide to those who are going to deploy it.

However, certainly there is a distinction to be made between "incoming" and "outgoing" even in the case of "pure" IP.  The incoming IP header of a packet is always different than the outgoing IP header of that packet, due to the need to modify the TTL and checksum fields.

In addition, as you point out, the incoming source address field may be different than the outgoing source address field, due to NAT.  And use of the source routing option can result in there being a difference between the incoming destination address field and the outgoing destination address field.

Another interesting case is tunnel stitching, where the incoming source and destination address fields may both be different than the outgoing source and destination address fields.  If you want to optimize for tunnel stitching, you precompute the rewrite string, and to the forwarding plane it looks like an ordinary case of forwarding a packet.

Of course, if your platform doesn't need to perform any of these functions, it doesn't have to implement them.  Similarly, if you think that the most common operation (or even the only operation) your platform will have to perform on an MPLS packet is "don't modify the label stack except for the TTL of the top entry", nothing stops you from optimizing for that case.

BTW, I understand perfectly well that there is some controversy about whether it is or is not a good idea to use domain-wide labels, but that is not a data plane issue, and the use of domain-wide labels does not require a change in the data plane architecture.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 24 Jul 2015 20:25:16 +0200

Adrian,

No one in this thread is saying that 3031 is wrong. All we are saying is
that it is incomplete.

As to your objects for the domain wide/global label case I only need two:

LABEL_VALUE
BINDED_IP_ADDRESS

I do not need IN_INTERFACE .. in fact as I am sure you know per interface
label space was practically never implemented. Even where it is very needed
implementations  use well known trick around it (example: for inter-as
option B on ASBRs or CSC).

As far as OUT_INTERFACE I would also leave it to FIB recursive resolution
to dynamically set it based on the BGP/IGP information.

So is this still MPLS per 3031 ? I am actually not that sure anymore.

Maybe it would be cleaner to call this MPLSv2 and document it in its own
RFC?

Then of course question will come why not just use remote next hop
attribute and encapsulate with IP. Well there is class of switches which do
brilliant L2 and L2.5 but not L3. I am not sure if cost of high speed
ports, very competitive power consumption, great cooling characteristics
would be a sufficient of the market for this new work - but I do not think
this is us here in IETF to decide that.

Best,
r.

On Fri, Jul 24, 2015 at 7:15 PM, Adrian Farrel <[email-masked]> wrote:

> And if you want to specify the interface between the management plane and
> the data plane, that is also OK (although it has been done before as well).
>
>
>
> Setting OPERATION to NO-SWAP saves you from setting OUT-LABEL, but doesn't
> save you from needing the object in your data model. So it is a trade in
> the design of the data model and either approach is fine.
>
>
>
> *Sent:* 24 July 2015 17:55
> *To:* Eric Rosen
> *Cc:* [email-masked]
> Creating non standard optimised APIs or YANG models to send single label
> or artificially send identical labels an in and out when given architecture

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 24 Jul 2015 22:03:29 +0200

Robert,

You're free to implement your switch as you see fit. If your switch sees
identical in and out labels being provisioned (by whatever means), then you
are free to store that in an internal FIB/LIB as NOSWAP, and your data
plane will be optimized. The nice thing is that externally, your switch
(and controller, or control plane) will conform to existing MPLS specs, and
interoperate with existing equipment. This will give your customers a way
to gracefully migrate from the old switches to new ones without requiring a
fork lift upgrade, coordinating both the data and control planes.

Cheers,
Andy

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 24 Jul 2015 22:21:12 +0200

Andy,

Let me make it very simple.

This discussion is not about how to build a LSR. This discussion is also
not about modyfing anything in the data plane as far as MPLS encapsulation
is concerned.

This thread is about amending 3031 with new primitive such that new control
planes would be able to be used in a straight forward way to program it.

Practical example:

Assume I have a HSDN model and want to set DC labels from controller to the
switch using mpls YANG I2RS channel - how would I do it ?

Please provide real YANG or YIN example where I can bind label 44 to
anycast address 1.1.1.44 where this address is a ghost loopback from my
MPLS WAN to DC44 gateways.

With that please do reference drafts used as a normative references for
provided encoding.

This is as simple as this :)

Best,
R.

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 27 Jul 2015 11:45:15 -0400

On 7/24/2015 4:21 PM, Robert Raszuk wrote:
> Assume I have a HSDN model and want to set DC labels from controller to
> the switch using mpls YANG I2RS channel - how would I do it ?

Robert,

Perhaps you could take that question to whichever WG is doing the Yang 
model in question.

You seem to be speculating that a Yang model with the properties you'd 
like to see would be rejected as a standard, due to some incompatibility 
with RFC3031.

I'd suggest that you work to get the Yang model the way you think it 
should be.  If it is later claimed by some WG or AD that the model 
cannot be standardized because it is incompatible with RFC3031, the MPLS 
WG can evaluate the specifics of that claim, and determine whether it 
needs to take any action.

Eric

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 27 Jul 2015 20:54:48 +0200

Eric,

Just FYI I have already started last week to review and discuss with
openconfig team this topic. So Thank You for advice but it came a bit too
late :)

As to the core of the issue .. looking strictly technical I am really not
clear why there is so much resistance to add NO_SWAP/CONTINUE primitive to
3031bis .... would it break anything ?

Cheers,
R.

On Mon, Jul 27, 2015 at 5:45 PM, Eric C Rosen <[email-masked]> wrote:

> should be.  If it is later claimed by some WG or AD that the model cannot
> be standardized because it is incompatible with RFC3031, the MPLS WG can
> evaluate the specifics of that claim, and determine whether it needs to
> take any action.
>
> Eric
>
>