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 09:14:23 +0000

Andy,

Lots of thanks for the clarification.

Regards,

Thumb typed on my LG,
Sasha

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

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]<mailto:[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<tel:%2B972-39266302>
Cell:      +972-549266302<tel:%2B972-549266302>
Email:   [email-masked]<mailto:[email-masked]>

From: mpls [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Andrew G. Malis
Sent: Tuesday, July 21, 2015 11:03 AM
To: 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

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 28 Jul 2015 18:06:27 +0000

Andrew,

From my POV the answer to your conditional question is:

NO. An *architectural* primitive for NO_SWAP is not necessary because it can be easily modeled by SWAP to the same label.

Of course this does not mean that your implementation can not do some internal optimization and implement SWAP to the same label more effectively. However, your real gain would be probably negligible IMHO.

My 2c.

Thumb typed on my LG,
Sasha

------ Original message ------
From: Andrew Qu
Date: 28/07/2015 20:56
To: Shahram Davari;
Cc: [email-masked];Alexander Vainshtein;Robert Raszuk;[email-masked];
Subject:RE: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

Hi Shahram,

This is a question that must be answered,  but could you please hold the question for now?

I just want to have one issue clarified before moving to another.

Do we agree that _IF_ global label becomes necessary,  no-swap as primitive is necessary?

Understood that _IF_ will be next topic to follow.

Thanks,

Andrew

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Tuesday, July 28, 2015 9:40 AM
To: Andrew Qu
Cc: [email-masked]; Alexander Vainshtein; Robert Raszuk; [email-masked]
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

Andrew

Continue operation in segment routing and in HSDN is not global label. Global label means every router knows how to forward a global label. What is the application for a global label and how does each router know how to forward it?

Regards,
Shahram

> On Jul 28, 2015, at 7:58 AM, Andrew Qu <[email-masked]> wrote:
>
> Hi Stewart,
>
> Agreed that SWAP must be kept because MPLS fundamentals can't be broken.
> And I agreed that _if_ there is NO such global label space idea,
> no-swap is optimization of swap as well.
>
> However I don't agree no-swap become an optimization in terms of
> network Behavior when global label idea become a needed thing.
>
>
> When global Label introduced, then no_swap is the conceptually right
> thing for the transition [even Local implementation can use swap to
> achieve, again, per previous conversation, the popular wisdom, which I
> agreed as well,  is that this is local implementation, we should not
> get involved, so we must define no-swap as the new primitive at RFC
> level]
>
>
> So the question really boils down to that do we need global label?
>
> I believe that is the key thing here.  May be we can put swap/no-swap aside for the moment.
>
> Thanks,
>
> Andrew
>
>
> -----Original Message-----
> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Tuesday, July 28, 2015 4:03 AM
> To: Andrew Qu; Alexander Vainshtein; Robert Raszuk; Shahram Davari
> Cc: [email-masked]
>> Adding "NO_SWAP" for new/future generation DEVICE does NOT break
>> backward capability.
> Andrew
>
> Existing devices should be assumed to have non-aligned label spaces.
> (there is much empirical evidence to support this position)
>
> So if you have a no-swap only device between two existing devices you cannot be sure that you can build an LSP.
>
> A backwards compatible device would therefore need to support swap.
>
> Once you support swap then no-swap become an optimization.
>
> - Stewart
>
>
> ************* 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!
>
************* 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!