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

[Stewart Bryant <[e-mail]>]

On 28/07/2015 18:55, Andrew Qu wrote:
> 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?
No, the primitive is not *needed*.

Stewart
>
> Understood that _IF_ will be next topic to follow.
>
> Thanks,
>
> Andrew
>
> -----Original Message-----
> From: Shahram Davari [mailto:[e-mail]]
> Sent: Tuesday, July 28, 2015 9:40 AM
> To: Andrew Qu
> Cc: [e-mail]; Alexander Vainshtein; Robert Raszuk; [e-mail]
> 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 <[e-mail]> 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:[e-mail]]
>> Sent: Tuesday, July 28, 2015 4:03 AM
>> To: Andrew Qu; Alexander Vainshtein; Robert Raszuk; Shahram Davari
>> Cc: [e-mail]
>> Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?
>>
>>> 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!
>
> .
>


-- 
For corporate legal information go to:

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