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

Robert Raszuk <robert@raszuk.net> Fri, 24 July 2015 09:04 UTC

Return-Path: <rraszuk@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657C51A1A6D for <mpls@ietfa.amsl.com>; Fri, 24 Jul 2015 02:04:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.023
X-Spam-Level: *
X-Spam-Status: No, score=1.023 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_YOUR=2.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id La4WIIl-J8QR for <mpls@ietfa.amsl.com>; Fri, 24 Jul 2015 02:04:43 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0C951A023E for <mpls@ietf.org>; Fri, 24 Jul 2015 02:04:42 -0700 (PDT)
Received: by wibud3 with SMTP id ud3so56791221wib.1 for <mpls@ietf.org>; Fri, 24 Jul 2015 02:04:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=N7Btv/W2xSVhPO43kccgXiBckx+kR1rHIQSYSrJjSo0=; b=iSFgG5bGzi8+md/LZpO1P8VRSUv9K8HW4VLnpbXSoSnkXRtRVk/AK+yyd5VDuj06YW LhAzXphPUoZeu1QvmZ6e4BUJ6PqXJb8tKX31mAL3P0X3//kFz6x7ClMzYVjZSBcCdAaq 3La4xHEvQrDc550ir+o0/PC35OSt3zVTaIXUTL2CcBO2Gz3SXGro0LUT1iGrScUhn3d4 VISTDBwDh3asGEOUoLzy7tdpzEv1t3LfN8UlQrVyZtGcCA4VrjyQWYupnaXLHbIqkTQ3 T34WsKSI7Pi98pUiAqsGdlKdfp//kW4lrmLnO62CqP1dsfgQlz+NzdCIeAGKV+0If3J8 tN4w==
MIME-Version: 1.0
X-Received: by 10.194.120.198 with SMTP id le6mr24624765wjb.133.1437728681398; Fri, 24 Jul 2015 02:04:41 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.194.95.168 with HTTP; Fri, 24 Jul 2015 02:04:41 -0700 (PDT)
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB0190E@NKGEML512-MBS.china.huawei.com>
References: <DB3PR03MB0780C71D3CF8426A5CA06C1F9D810@DB3PR03MB0780.eurprd03.prod.outlook.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB0190E@NKGEML512-MBS.china.huawei.com>
Date: Fri, 24 Jul 2015 11:04:41 +0200
X-Google-Sender-Auth: gbtO08V5sXnqJvIfofMWDmoMXtE
Message-ID: <CA+b+ERku6xp6WFOgESxdqjGH3Z0DiHbu5ZPBNegynzV8+GNqeg@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
To: Xuxiaohu <xuxiaohu@huawei.com>
Content-Type: multipart/alternative; boundary=089e011600025697aa051b9b4bc5
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/3-rDuCjfvbX-8HBaKkaCKJzrR44>
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jul 2015 09:04:46 -0000

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 <xuxiaohu@huawei.com> 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 [Alexander.Vainshtein@ecitele.com]
> *发送时间:* 2015年7月24日 16:31
> *收件人:* Xuxiaohu; Robert Raszuk; Shahram Davari
> *抄送:* mpls@ietf.org
> *主题:* 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: *mpls@ietf.org;
> *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 [mpls-bounces@ietf.org] 代表 Alexander Vainshtein [
> Alexander.Vainshtein@ecitele.com]
> *发送时间:* 2015年7月24日 13:26
> *收件人:* Robert Raszuk; Shahram Davari
> *抄送:* mpls@ietf.org
> *主题:* 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: *mpls@ietf.org;
> *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  <davari@broadcom.com>
> 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:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Robert
>> Raszuk
>> *Sent:* Thursday, July 23, 2015 2:12 PM
>> *To:* Shahram Davari
>> *Cc:* Eric C Rosen; stbryant@cisco.com; mpls@ietf.org
>>
>> *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 <davari@broadcom.com>
>> wrote:
>>
>> Hi Robert,
>>
>>
>>
>> How are these labels distributed? Via LDP or via SDN controller?
>>
>>
>>
>> Thanks
>>
>> Shahram
>>
>>
>>
>> *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Robert
>> Raszuk
>> *Sent:* Thursday, July 23, 2015 12:58 PM
>> *To:* Eric C Rosen
>> *Cc:* Shahram Davari; stbryant@cisco.com; mpls@ietf.org
>> *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.
>>
>>
>>
>>
>>
>
>