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

[Robert Raszuk <[e-mail]>]

Xu,

I very much agree 100% with your comments and comments from Robin.

Thank you,
R.

On Fri, Jul 24, 2015 at 10:59 AM, Xuxiaohu <[e-mail]> wrote:

>  Hi Sasha,
>
>
>
> Regarding why anycast segment would require global labels, please look
> at page 4 of this .pdf (
> https://www.ietf.org/proceedings/93/slides/slides-93-spring-1.pdf) IMHO,
>  it seems more acceptable to use global labels rather than introducing a
> new forwarding paradigm (i.e., SID-based forwarding) to achieve anycast
> segment functionality.
>
>
>
> Best regards,
>
> Xiaohu
>  ------------------------------
> *发件人:* Alexander Vainshtein [[e-mail]]
> *发送时间:* 2015年7月24日 16:31
> *收件人:* Xuxiaohu; Robert Raszuk; Shahram Davari
> *抄送:* [e-mail]
> *主题:* Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does
> it really save?
>
>   Xiaohu hi!
>
>
>
> First of all I think that you are asking the right question:-( .
>
>
>
> This said I think that the answer to this question is NO.
>
>
>
> I do not see why anycast segment in SR would require global labels - could
> you please elaborate?
>
>
> Thumb typed on my LG,
> Sasha
>
> ------ Original message ------
> *From: *Xuxiaohu
> *Date: *24/07/2015 10:49
> *To: *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?
>
>  Hi all,
>
>
>
> Before considering the possible MPLS forwarding optimization for global
> labels (a.k.a., domain-wide labels), should we firstly legalize the usage
> of global labels within the MPLS community? BTW, I believe global labels
> would be very useful and neccessary in some use cases, such as anycast
> segment.
>
>
>
> Best regards,
>
> Xiaohu
>  ------------------------------
> *发件人:* mpls [[e-mail]] 代表 Alexander Vainshtein [
> [e-mail]]
> *发送时间:* 2015年7月24日 13:26
> *收件人:* Robert Raszuk; Shahram Davari
> *抄送:* [e-mail]
> *主题:* Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does
> it really save?
>
>
>
> Hi all,
>
> Please note that CONTINUE in SPRING is:
>
> 1. A DP-agnostic primitive
>
> 2. *Implemented* as SWAP instruction with MPLS DP.
>
>
>
> So claiming equivalence of CONTINUE and NO-SWAP seems to be inaccurate IMO.
>
>
>
> As for global labels (in SDN, MPLS-TP or any other technology) - this
> definitely looks to me like a very bad idea for networks comprised of
> devices that support different label ranges. From my experience these
> scenarios have been encountered in real MPLS-TP deployments  and resulted
> in eventually dropping the "simple" solution as live networks have been
> extended with new NEs supporting a more narrow label space than the
> original ones.
>
>
>
> Adding a new forwarding primitive to MPLS architecture (yet another
> argument on this thread) immediately raises the question:
>
>
>
> Is support of the new primitive mandatory?
>
>
>
> If it is not (and this is clearly the case for NO-SWAP), then why should
> we bother? Occam's rasor cuts this off IMHO.
>
>
>
> My personal bottom line: this is a strictly NO GO proposal.
>
>
>
> My 2c.
>
>
> Thumb typed on my LG,
> Sasha
>
> ------ Original message ------
> *From: *Robert Raszuk
> *Date: *24/07/2015 00:22
> *To: *Shahram Davari;
> *Cc: *[e-mail];
> *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.
>
>  Ref: https://goo.gl/3oxRbl
>
>  Thx,
> R.
>
>
> On Thu, Jul 23, 2015 at 11:16 PM, Shahram Davari  <[e-mail]>
> 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
>>
>>
>>
>> *From:* [e-mail] [mailto:[e-mail]] *On Behalf Of *Robert
>> Raszuk
>> *Sent:* Thursday, July 23, 2015 2:12 PM
>> *To:* Shahram Davari
>> *Cc:* Eric C Rosen; [e-mail]; [e-mail]
>>
>> *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 <[e-mail]>
>> wrote:
>>
>> Hi Robert,
>>
>>
>>
>> How are these labels distributed? Via LDP or via SDN controller?
>>
>>
>>
>> Thanks
>>
>> Shahram
>>
>>
>>
>> *From:* [e-mail] [mailto:[e-mail]] *On Behalf Of *Robert
>> Raszuk
>> *Sent:* Thursday, July 23, 2015 12:58 PM
>> *To:* Eric C Rosen
>> *Cc:* Shahram Davari; [e-mail]; [e-mail]
>> *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.
>>
>>
>>
>> ​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.
>>
>>
>>
>>
>>
>
>