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

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 21 Jul 2015 15:04:56 +0000

+1.

Thumb typed on my LG,
Sasha

------ Original message ------
From: Stewart Bryant
Date: 21/07/2015 17:58
To: Andrew G. Malis;S. Davari;
Cc: [email-masked];
Subject:Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

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

On Mon, Jul 20, 2015 at 8:52 PM, S. Davari  <[email-masked]<mailto:[email-masked]>> wrote:
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]<mailto:[email-masked]>> wrote:
>
>> 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.
>
> _______________________________________________
> mpls mailing list
> [email-masked]<mailto:[email-masked]>
>  https://www.ietf.org/mailman/listinfo/mpls

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

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

--
For corporate legal information go to:

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

---

From: Andrew Qu <[email-masked]>
Date: Thu, 23 Jul 2015 14:01:16 +0000

I don’t agree no-swap is the same as “swap with same value”.

I think if standard adds a no-swap operation, that would be great for people to implement
Either SW or HW.

Once the label is defined as swap, I need to consider

1)      TTL

Copy payload TTL ? or using const_value

2)      QoS (pipe mode or not)
If pipe mode => then I need to do something
If not=> then I need to do something else.

However if it is really a “no-swap”,  then it is very clear for HW/SW to implement such operation.
I don’t need to consider any part of above cases.

I don’t think swaping a same value label is NOT the same as “no-swap” at all.

From Standard point of view, we should NOT leave ambiguity here at all.

Thanks,

Andrew

From: mpls [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Tuesday, July 21, 2015 5:05 PM
To: Stewart Bryant; Andrew G. Malis; S. Davari
Cc: [email-masked]
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

+1.

Thumb typed on my LG,
Sasha

------ Original message ------
From: Stewart Bryant
Date: 21/07/2015 17:58
To: Andrew G. Malis;S. Davari;
Cc: [email-masked]<mailto:[email-masked]>;

- Stewart

Cheers,
Andy

Regards,
Shahram

mpls mailing list

--

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 23 Jul 2015 15:08:33 +0100

Andrew,
 
Are you mixing "no swap" with "bump in the wire"?
 
If you are going to not consider TTL then you are doing some far more "interesting" things: like not decrementing the TTL so not being counted as a hop; not appearing in OAM; not checking incoming packets for TTL going to zero.
 
The discussion of "no swap" as applied *solely* to the label is a black box optimisation. There is no difference at the external interfaces when "no swap" is done or when "pop'n'push" or "swap-inline" is done. The packet coming out has the same features in all cases.
 
But, if you are doing other special things to the label stack entry (e.g. not looking at it, or not changing it) then IMHO you are not a router, you are a wire.
 
Adrian
 
From: mpls [mailto:[email-masked]] On Behalf Of Andrew Qu
Sent: 23 July 2015 15:01
To: Alexander Vainshtein; Stewart Bryant; Andrew G. Malis; S. Davari
Cc: [email-masked]
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

 

 
 
Thanks,
 
Andrew

+1.
 
Thumb typed on my LG,
Sasha

------ Original message ------
From: Stewart Bryant
Date: 21/07/2015 17:58
To: Andrew G. Malis;S. Davari;
Cc: [email-masked];

- Stewart

Cheers,
Andy

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

Regards,
Shahram

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

[email-masked]

[email-masked]

************* Email Confidentiality Notice ********************
The information contained in this e-mail message (including any 
attachments) may be confidential, proprietary, privileged, or otherwise
exempt from disclosure under applicable laws. It is intended to be 
conveyed only to the designated recipient(s). Any use, dissemination, 
distribution, printing, retaining or copying of this e-mail (including its 
attachments) by unintended recipient(s) is strictly prohibited and may 
be unlawful. If you are not an intended recipient of this e-mail, or believe 
that you have received this e-mail in error, please notify the sender 
immediately (by replying to this e-mail), delete any and all copies of 
this e-mail (including any attachments) from your system, and do not
disclose the content of this e-mail to any other person. Thank you!

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 23 Jul 2015 14:13:42 +0000

Hi all,
I concur with Adrian.

I also think that the authors of the draft did not intend to change the TTL or TC processing rules with their “no-swap” option.

Regards,
Sasha

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

From: mpls [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Thursday, July 23, 2015 5:09 PM
To: 'Andrew Qu'
Cc: [email-masked]
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

Andrew,

Adrian

From: mpls [mailto:[email-masked]] On Behalf Of Andrew Qu
Sent: 23 July 2015 15:01
To: Alexander Vainshtein; Stewart Bryant; Andrew G. Malis; S. Davari
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

1)      TTL

Thanks,

Andrew

Cc: [email-masked]<mailto:[email-masked]>

+1.

Thumb typed on my LG,
Sasha

------ Original message ------
From: Stewart Bryant
Date: 21/07/2015 17:58
To: Andrew G. Malis;S. Davari;
Cc: [email-masked]<mailto:[email-masked]>;

- Stewart

Cheers,
Andy

Regards,
Shahram

mpls mailing list

--

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 23 Jul 2015 15:21:54 +0100

Adrian beat me to it, although I see no reference to the infinite loop 
that may also result.

You are also talking about operations that you do when you change level 
in the LSP hierarchy with operations that you do when forwarding at the 
same level in the hierarchy.

- Stewart

On 23/07/2015 15:08, Adrian Farrel wrote:
> If you are going to not consider TTL then you are doing some far more 
> "interesting" things: like not decrementing the TTL so not being 
> counted as a hop; not appearing in OAM; not checking incoming packets 
> for TTL going to zero.
>
> The discussion of "no swap" as applied *solely* to the label is a 
> black box optimisation. There is no difference at the external 
> interfaces when "no swap" is done or when "pop'n'push" or 
> "swap-inline" is done. The packet coming out has the same features in 
> all cases.
>
> But, if you are doing other special things to the label stack entry 
> (e.g. not looking at it, or not changing it) then IMHO you are not a 
> router, you are a wire.
>
> Adrian
>
> *From:*mpls [mailto:[email-masked]] *On Behalf Of *Andrew Qu
> *Sent:* 23 July 2015 15:01
> *To:* Alexander Vainshtein; Stewart Bryant; Andrew G. Malis; S. Davari
> *Cc:* [email-masked]
> *Subject:* Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how 
> much does it really save?
>
> 1)TTL
> 2)QoS (pipe mode or not)
> *From:*mpls [mailto:[email-masked]] *On Behalf Of *Alexander 
> Vainshtein
> *Sent:* Tuesday, July 21, 2015 5:05 PM
> *To:* Stewart Bryant; Andrew G. Malis; S. Davari
> *Cc:* [email-masked]
> *Subject:* Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how 
> much does it really save?
>
> +1.
>
> Thumb typed on my LG,
> Sasha
>
> *From: *Stewart Bryant
> *Date: *21/07/2015 17:58
> *To: *Andrew G. Malis;S. Davari;
> *Cc: [email-masked] <mailto:[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
>
>     > 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]>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: Loa Andersson <[email-masked]>
Date: Thu, 23 Jul 2015 18:59:25 +0200

Andrew,

> I don’t need to consider any part of above cases.

I've a little bit ambivalent (mostly thought this is a no go) about this
draft, bur if we say that no-swap and not considering TTL and QOS, then
this definitely a no go!

/Loa
> *Subject:*Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much
> does it really save?
>
>     > On Jul 20, 2015, at 11:43 AM, Eric C Rosen <[email-masked] <mailto:[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.
>     >

---

From: Shahram Davari <[email-masked]>
Date: Thu, 23 Jul 2015 17:18:03 +0000

I thought the idea was to decrement TTL and consider EXP bits for queuing and count as a hop so you can do OAM, etc.. Basically swap to itself.

Thx
Shahram

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Thursday, July 23, 2015 9:59 AM
To: Andrew Qu; Alexander Vainshtein; Stewart Bryant; Andrew G. Malis; S. Davari
Cc: [email-masked]
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

Andrew,

On 2015-07-23 16:01, Andrew Qu wrote:
> I don't agree no-swap is the same as "swap with same value".
>
> However if it is really a "no-swap",  then it is very clear for HW/SW to
> implement such operation.
>
> I don't need to consider any part of above cases.

/Loa
>
> I don't think swaping a same value label is NOT the same as "no-swap" at
> all.
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 23 Jul 2015 22:32:47 +0200

Sharam,

The point was made during the meeting that on the wire, "no swap" (but
still decrement TTL, etc.) is indistinguishable from "swap to the same
label". So this really is a local optimization in the switch, and not
subject to standardization.

Cheers,
Andy

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

> I thought the idea was to decrement TTL and consider EXP bits for queuing
> and count as a hop so you can do OAM, etc.. Basically swap to itself.
>
> Thx
> Shahram
>

---

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

That’s was my understanding too that TTL and EXP work as usual.

Thx
Shahram

From: Andrew G. Malis [mailto:[email-masked]]
Sent: Thursday, July 23, 2015 1:33 PM
To: Shahram Davari
Cc: Loa Andersson; Andrew Qu; Alexander Vainshtein; Stewart Bryant; S. Davari; [email-masked]
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

Sharam,

The point was made during the meeting that on the wire, "no swap" (but still decrement TTL, etc.) is indistinguishable from "swap to the same label". So this really is a local optimization in the switch, and not subject to standardization.

Cheers,
Andy

On Thu, Jul 23, 2015 at 7:18 PM, Shahram Davari <[email-masked]<mailto:[email-masked]>> wrote:
I thought the idea was to decrement TTL and consider EXP bits for queuing and count as a hop so you can do OAM, etc.. Basically swap to itself.

Thx
Shahram

---

From: Andrew Qu <[email-masked]>
Date: Thu, 23 Jul 2015 21:55:13 +0000

Hi Andy,

I believe it is RFC author’s duty to make RFC as clear as possible so that reader/implementation engineer to be clear
About the intent of authors.

In addition to what I brought up in my previous mail about the huge saving in HW resources when if on paper we have
Additional “no-swap” operation added to existing MPLS operation, I believe we should define “no-swap” first,
Let implementation folks to decide whether use “swap” operation logic to achieve “no-swap” or use specific
Way of achieving that.

Why RFC authors dictate the “real implementation” ?  all we need is just the “final compliant” result, however
“no-swap” is simply different than “swap”, why we ignore the fundamental difference.

Thanks,

Andrew

From: Andrew G. Malis [mailto:[email-masked]]
Sent: Thursday, July 23, 2015 10:33 PM
To: Shahram Davari
Cc: Loa Andersson; Andrew Qu; Alexander Vainshtein; Stewart Bryant; S. Davari; [email-masked]
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

Sharam,

Cheers,
Andy

Thx
Shahram

---

From: Andrew Qu <[email-masked]>
Date: Thu, 23 Jul 2015 21:55:11 +0000

It seems I mislead folks from my previous mail.

Please let me rephrase my points. :-)

>From a ASIC design engineer point of view,  I wanted to say swap and no-swap is
Very different meaning.

As long as there is a defined swap operation, I have to design the "swap" completely
In ASIC logic.

If there is a "no-swap" operation defined, then my ASIC engineer will implement it differently
than swap.

I used "TTL" and EXP handling as example.  Since the label is to be "swap"ed with a new LABEL stack,
then the design of SWAPING need to consider TTL handling such as 
1) just decrement of original TTL or 2) using a brand new TTL, such as using local new register stored value to
  Fill the sawp'ed new label stack.

And in reality,  the ASIC may chose a HW adjacency storage which has complete label stack space,  SW is resonspile
To file them up to fulfill so called "swap" operation.

When standard defines a "no-swap" operation,  ASIC engineer would implement such operation completely differently in
Real RTL design with regarding how to handling TTL or EXP.

If I am putting NETWORK meaning aside for the moment,  the wording in RFC about "swap" and "no-swap" is already making difference
to inplementor already.  So that is what I meant that as RFC writer, we should be as clear as possible.

That is first of my points.  

My next point is that:

As matter of fact,  "no-swap" operation has huge difference in the following implementation than "swap".

For example:

When without "no-swap" operation defined, in order to achieve "no-swap" result, as you suggested,
I would simply copy "in-label" and write it back to "out-label", but to HW, it means that
for different in-label, I must use different HW adjacency to support "no-swap" result.
So it will be 1-1 mapping of using adjacencies of HW resource even they share the rest of rewrite
Information such out going port and DMAC/SMAC etc.

However if we do have a "no-swap" operation defined,  then I can share no matter of how many in-coming
Label with just "ONE" HW adjacence to rewrite the in-coming packets.

The adjacency instruction would simply just be "no operation on label value, decrement TTL" and using
"out_port, DMAC, SMAC"  for all the incoming packet with different labels.

This is huge saving in terms of implementation when "no-swap" is defiend as a MPLS opearation option for
a ASIC design engineer..

Lastly, I still personally believe,  the network meaning of "swap" and "no-swap" can't be treated the same.
As Robert pointed out,  SR also has "CONTINUE" operation as well,  why SR keep that operation if we thing
SWAP is good to cover all cases including "CONTINUE" ?

The local implementation may use the "same" way to meet two different requirements does NOT mean they
Are the same, so from standard RFC point of view, we should not leave it as it is,  I feel when use
Case arises, we should add the clarification such as this draft to clarify.

Thanks,

Andrew

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: Thursday, July 23, 2015 6:59 PM
To: Andrew Qu; Alexander Vainshtein; Stewart Bryant; Andrew G. Malis; S. Davari
Cc: [email-masked]
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

Andrew,

On 2015-07-23 16:01, Andrew Qu wrote:
> However if it is really a "no-swap",  then it is very clear for HW/SW 
> to implement such operation.
>

I've a little bit ambivalent (mostly thought this is a no go) about this draft, bur if we say that no-swap and not considering TTL and QOS, then this definitely a no go!

/Loa
>
> I don't think swaping a same value label is NOT the same as "no-swap" 
> at all.
>
> ************* Email Confidentiality Notice ******************** The 
> information contained in this e-mail message (including any
> attachments) may be confidential, proprietary, privileged, or 
> otherwise exempt from disclosure under applicable laws. It is intended 
> to be conveyed only to the designated recipient(s). Any use, 
> dissemination, distribution, printing, retaining or copying of this 
> e-mail (including its
> be unlawful. If you are not an intended recipient of this e-mail, or 
> believe that you have received this e-mail in error, please notify the 
> sender immediately (by replying to this e-mail), delete any and all 
> copies of this e-mail (including any attachments) from your system, 
> and do not disclose the content of this e-mail to any other person. Thank you!
>
>
>

---

From: Shahram Davari <[email-masked]>
Date: Thu, 23 Jul 2015 22:06:08 +0000

Andrew,

Focusing on just the data-plane, do you agree that externally observable behavior of a router that does "no-swap" is same as "swap" to the same label.
If so why do you think a standards RFC for data-plane is required? since standards RFC should be something that is externally visible outside of a box.

Thanks
Shahram

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Andrew Qu
Sent: Thursday, July 23, 2015 2:55 PM
To: Loa Andersson; Alexander Vainshtein; Stewart Bryant; Andrew G. Malis; S. Davari
Cc: [email-masked]
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

Very different meaning.

My next point is that:

For example:

Thanks,

Andrew

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: Thursday, July 23, 2015 6:59 PM
To: Andrew Qu; Alexander Vainshtein; Stewart Bryant; Andrew G. Malis; S. Davari
Cc: [email-masked]
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

Andrew,

/Loa

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 24 Jul 2015 00:14:56 +0200

Hi Shahram,

This is first time I see that we judge what should the RFC contain by using
sniffer on the wire ... but as I pointed out this is besides the point.

Control plane is different and what currently defined primitives require
control plane to provide workarounds for the missing forwarding action.

Moreover think further ... look at I2RS and MPLS YANG models. Would it
contain something which is not in the MPLS architecture RFC .. I doubt as
by procedural requirements consulting normative reference section it will
be blocked.

As a consequence it is no longer just local RP/RE to data plane trick .. we
are not for new architectures impacting remote controllers which will need
to use concepts of incoming/outgoing labels when setting data plane using
global/path labels.

Is this sound design by any means ?

Cheers,
R.

On Fri, Jul 24, 2015 at 12:06 AM, Shahram Davari <[email-masked]>
wrote:

> Andrew,
>
> Focusing on just the data-plane, do you agree that externally observable
> behavior of a router that does "no-swap" is same as "swap" to the same
> label.
> If so why do you think a standards RFC for data-plane is required? since
> standards RFC should be something that is externally visible outside of a
> box.
>
>
> Thanks
> Shahram
>
> And in reality,  the ASIC may chose a HW adjacency storage which has
> complete label stack space,  SW is resonspile
> When standard defines a "no-swap" operation,  ASIC engineer would
> implement such operation completely differently in
> If I am putting NETWORK meaning aside for the moment,  the wording in RFC
> about "swap" and "no-swap" is already making difference
> >     > 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
> 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.
> >     >
> believe

---

From: Andrew Qu <[email-masked]>
Date: Thu, 23 Jul 2015 22:55:24 +0000

Hi Shahram,

That is not a fair question in the first place.  SWAP is defined in RFC which is already
Data-plane behavior, then why we purposely ignore to mention "no_swap"?

why only "no_swap" is data-plane specific but not swap? 

To me, Swap and no_swap is a twin siblings, they come together.

Missing "no_swap" in the RFC when "swap" was originally brought is mistake in the first place,
We should do due diligence to correct it when it is really needed.

Considering the following:
1) if NO_SWAP is additionally added but NOT breaking ANY existing framework
2) huge benefit might be potentially achieved
3) NO_SWAP is naturally coming after "SWAP" which RFC is defined in the first place.

Then on what base, we should not clarify it with an incremental change document?

Thanks,

Andrew

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Friday, July 24, 2015 12:06 AM
To: Andrew Qu; Loa Andersson; Alexander Vainshtein; Stewart Bryant; Andrew G. Malis; S. Davari
Cc: [email-masked]
Subject: RE: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

Andrew,

Thanks
Shahram

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Andrew Qu
Sent: Thursday, July 23, 2015 2:55 PM
To: Loa Andersson; Alexander Vainshtein; Stewart Bryant; Andrew G. Malis; S. Davari
Cc: [email-masked]
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

Very different meaning.

As long as there is a defined swap operation, I have to design the "swap" completely In ASIC logic.

If there is a "no-swap" operation defined, then my ASIC engineer will implement it differently than swap.

I used "TTL" and EXP handling as example.  Since the label is to be "swap"ed with a new LABEL stack, then the design of SWAPING need to consider TTL handling such as
1) just decrement of original TTL or 2) using a brand new TTL, such as using local new register stored value to
  Fill the sawp'ed new label stack.

And in reality,  the ASIC may chose a HW adjacency storage which has complete label stack space,  SW is resonspile To file them up to fulfill so called "swap" operation.

When standard defines a "no-swap" operation,  ASIC engineer would implement such operation completely differently in Real RTL design with regarding how to handling TTL or EXP.

If I am putting NETWORK meaning aside for the moment,  the wording in RFC about "swap" and "no-swap" is already making difference to inplementor already.  So that is what I meant that as RFC writer, we should be as clear as possible.

My next point is that:

For example:

When without "no-swap" operation defined, in order to achieve "no-swap" result, as you suggested, I would simply copy "in-label" and write it back to "out-label", but to HW, it means that for different in-label, I must use different HW adjacency to support "no-swap" result.
So it will be 1-1 mapping of using adjacencies of HW resource even they share the rest of rewrite Information such out going port and DMAC/SMAC etc.

However if we do have a "no-swap" operation defined,  then I can share no matter of how many in-coming Label with just "ONE" HW adjacence to rewrite the in-coming packets.

The adjacency instruction would simply just be "no operation on label value, decrement TTL" and using "out_port, DMAC, SMAC"  for all the incoming packet with different labels.

This is huge saving in terms of implementation when "no-swap" is defiend as a MPLS opearation option for a ASIC design engineer..

Lastly, I still personally believe,  the network meaning of "swap" and "no-swap" can't be treated the same.
As Robert pointed out,  SR also has "CONTINUE" operation as well,  why SR keep that operation if we thing SWAP is good to cover all cases including "CONTINUE" ?

The local implementation may use the "same" way to meet two different requirements does NOT mean they Are the same, so from standard RFC point of view, we should not leave it as it is,  I feel when use Case arises, we should add the clarification such as this draft to clarify.

Thanks,

Andrew

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: Thursday, July 23, 2015 6:59 PM
To: Andrew Qu; Alexander Vainshtein; Stewart Bryant; Andrew G. Malis; S. Davari
Cc: [email-masked]
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

Andrew,

/Loa
>     > 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 archi…
************* Email Confidentiality Notice ******************** The information contained in this e-mail message (including any
attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its
attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you!

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 24 Jul 2015 05:12:09 +0000

Hi Robert,
let me re-phrase my question about impact of this proposal on existing OAM for MPLS data plane:
How one identifies the source of a packet  without using incoming-outgoing paradigm?

                Regards,
                                Greg

From: mpls [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, July 24, 2015 12:15 AM
To: Shahram Davari
Cc: [email-masked]
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

Hi Shahram,

This is first time I see that we judge what should the RFC contain by using sniffer on the wire ... but as I pointed out this is besides the point.

Control plane is different and what currently defined primitives require control plane to provide workarounds for the missing forwarding action.

Moreover think further ... look at I2RS and MPLS YANG models. Would it contain something which is not in the MPLS architecture RFC .. I doubt as by procedural requirements consulting normative reference section it will be blocked.

As a consequence it is no longer just local RP/RE to data plane trick .. we are not for new architectures impacting remote controllers which will need to use concepts of incoming/outgoing labels when setting data plane using global/path labels.

Cheers,
R.

On Fri, Jul 24, 2015 at 12:06 AM, Shahram Davari <[email-masked]<mailto:[email-masked]>> wrote:
Andrew,

Thanks
Shahram

-----Original Message-----
From: mpls [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Andrew Qu
Sent: Thursday, July 23, 2015 2:55 PM
To: Loa Andersson; Alexander Vainshtein; Stewart Bryant; Andrew G. Malis; S. Davari
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

Very different meaning.

My next point is that:

For example:

Thanks,

Andrew

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, July 23, 2015 6:59 PM
To: Andrew Qu; Alexander Vainshtein; Stewart Bryant; Andrew G. Malis; S. Davari
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

Andrew,

/Loa
> *From:*mpls [mailto:[email-masked]<mailto:[email-masked]>] *On Behalf Of *Alexander
> Vainshtein
> *Cc:* [email-masked]<mailto:[email-masked]>
> *Cc: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>;
>     On Mon, Jul 20, 2015 at 8:52 PM, S. Davari  <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     Eric
>
>     > On Jul 20, 2015, at 11:43 AM, Eric C Rosen <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>     >
>     >[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     [email-masked]<mailto:[email-masked]>  <mailto:[email-masked]<mailto:[email-masked]>>
>

---

From: Eric C Rosen <[email-masked]>
Date: Fri, 24 Jul 2015 11:09:30 -0400

> implement such operation completely differently

Well, this is where we came in.  The RFCs do not dictate how the ASICs
should be designed, and your ASIC designers are free to design in
whatever way best meets the needs of the systems that are going to use
those ASICs.  You can put in any optimizations you think are warranted. 
  If you expect the ASICs to be used in products that will never need to 
swap label values, never need to push labels, never need to pop labels, 
then you are free to design the ASICs without any of these features.  If 
you think that these operations are needed, but that "don't change the 
label value or the stack size" are the most common operations, you can 
certainly optimize your design for that case.

But if you think you can get the ASICs designed properly simply by 
handing the RFCs to the ASIC designers, you may be in for an unpleasant 
surprise.

> Since the label is to be "swap"ed with a new LABEL stack, then the
> design of SWAPPING need to consider TTL handling such as 1) just
> decrement of original TTL or 2) using a brand new TTL, such as using
> local new register stored value to Fill the sawp'ed new label stack.

The TTL handling is exactly the same for both cases.  If you have been 
telling your ASIC designers something different, you most definitely are 
in for an unpleasant surprise.

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 24 Jul 2015 15:24:07 +0000

Experience talks ;-)

Would be really great to get quantification.

Regards,
Jeff

On Jul 24, 2015, at 5:09 PM, Eric C Rosen <[email-masked]> wrote:

> those ASICs.  You can put in any optimizations you think are warranted.  If you expect the ASICs to be used in products that will never need to swap label values, never need to push labels, never need to pop labels, then you are free to design the ASICs without any of these features.  If you think that these operations are needed, but that "don't change the label value or the stack size" are the most common operations, you can certainly optimize your design for that case.
> 
> But if you think you can get the ASICs designed properly simply by handing the RFCs to the ASIC designers, you may be in for an unpleasant surprise.
> 
> The TTL handling is exactly the same for both cases.  If you have been telling your ASIC designers something different, you most definitely are in for an unpleasant surprise.
> 
> 
> 
> 
> 
>

---

From: Andrew Qu <[email-masked]>
Date: Fri, 24 Jul 2015 15:45:55 +0000

-----Original Message-----
From: Eric C Rosen [mailto:[email-masked]] 
Sent: Friday, July 24, 2015 5:10 PM
To: Andrew Qu; Loa Andersson; Alexander Vainshtein; Stewart Bryant; Andrew G. Malis; S. Davari
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

> implement such operation completely differently

Well, this is where we came in.  

[Andrew]  That is right, we are supposed to do some bridging works.  But when RFC is better written, 
	You may be "called" in less and we can spend more time to do greater good.

The RFCs do not dictate how the ASICs should be designed, and your ASIC designers are free to design in whatever way best meets the needs of the systems that are going to use those ASICs.  You can put in any optimizations you think are warranted. 

  If you expect the ASICs to be used in products that will never need to swap label values, never need to push labels, never need to pop labels, then you are free to design the ASICs without any of these features.  If you think that these operations are needed, but that "don't change the label value or the stack size" are the most common operations, you can certainly optimize your design for that case.

[Andrew] I don't know where did you get this idea from,  it is funny that how can you concluded that when I am asking
	better written doc implies that I will simply hand off the work completely.

[Andrew] I am using this case to indicate better written doc might help to reduce confusion.  
	This is the human thought process when people read "swap" and "no_swap" and consider how to implement
	Them.  Hence my point of no_swap may be defined to differentiate "swap".  

Thanks,

Andrew

---

From: Andrew Qu <[email-masked]>
Date: Fri, 24 Jul 2015 15:54:45 +0000

Experience should have taught us that we should strive to get our doc/standard written as
clear as possible and don't count on our involvement to get things straight.

With due respect, I hope that all experienced folks can learn from bad experiences.

Thanks,

Andrew

-----Original Message-----
From: Jeff Tantsura [mailto:[email-masked]] 
Sent: Friday, July 24, 2015 5:24 PM
To: Eric C Rosen
Cc: Andrew Qu; Loa Andersson; Alexander Vainshtein; Stewart Bryant; Andrew G. Malis; S. Davari; [email-masked]
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

Experience talks ;-)

Regards,
Jeff

---

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

I always thought that #1 is "Money talks" ;).

And with that why don't we define NO_SWAP as experimental RFC and let the
market decide how useful it will be ?

If say after few years it will have zero adoption its pretty simple to move
it to historical status and consider experiment as concluded.

Best,
R.
On Jul 24, 2015 5:24 PM, "Jeff Tantsura" <[email-masked]> wrote:

> If you expect the ASICs to be used in products that will never need to swap
> label values, never need to push labels, never need to pop labels, then you
> are free to design the ASICs without any of these features.  If you think
> that these operations are needed, but that "don't change the label value or
> the stack size" are the most common operations, you can certainly optimize
> your design for that case.
> >
> telling your ASIC designers something different, you most definitely are in
> for an unpleasant surprise.
> >
> >
> >
> >
> >
> >