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

Gregory Mirsky <gregory.mirsky@ericsson.com> Thu, 23 July 2015 21:43 UTC

Return-Path: <gregory.mirsky@ericsson.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 752061B29AA for <mpls@ietfa.amsl.com>; Thu, 23 Jul 2015 14:43:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.2
X-Spam-Level:
X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
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 DRp9RrZi9JQI for <mpls@ietfa.amsl.com>; Thu, 23 Jul 2015 14:43:28 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E5CB1B2A13 for <mpls@ietf.org>; Thu, 23 Jul 2015 14:42:15 -0700 (PDT)
X-AuditID: c6180641-f794d6d000001dfb-9d-55b0f79933b2
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id CF.5A.07675.997F0B55; Thu, 23 Jul 2015 16:18:01 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0210.002; Thu, 23 Jul 2015 17:42:12 -0400
From: Gregory Mirsky <gregory.mirsky@ericsson.com>
To: Robert Raszuk <robert@raszuk.net>, Shahram Davari <davari@broadcom.com>
Thread-Topic: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?
Thread-Index: AQHQwwR+4j+0b+JzE0iI4/eDDDIUYp3kzwKAgAAOiYCAAA1IgIAACkSAgATLuYCAABNcAIAAAT6AgAABKQCAAAHBgIAAAZ2AgAACWgD//74Z0A==
Date: Thu, 23 Jul 2015 21:42:13 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF112218831E0@eusaamb103.ericsson.se>
References: <55AD19F2.1010206@cisco.com> <4A6CE49E6084B141B15C0713B8993F2831F73A21@SJEXCHMB12.corp.ad.broadcom.com> <55AD2DAD.4060908@juniper.net> <4A6CE49E6084B141B15C0713B8993F2831F73F3A@SJEXCHMB12.corp.ad.broadcom.com> <55AD416D.2020306@juniper.net> <CA+b+ER=nEqxiHigEFbgY9LehQMRNH8rOzQKeTQpmMrHh6_-MEA@mail.gmail.com> <4A6CE49E6084B141B15C0713B8993F2831F7A945@SJEXCHMB12.corp.ad.broadcom.com> <CA+b+ERkcfqNRDZc_cv8WB56OHrbhfzSxx2aKdACeUjtOKwL6YQ@mail.gmail.com> <4A6CE49E6084B141B15C0713B8993F2831F7AAC7@SJEXCHMB12.corp.ad.broadcom.com> <CA+b+ER=_PJYsDyngQxaxwqbxKQDUN1gT0rYKy5L07HuEovshCQ@mail.gmail.com> <4A6CE49E6084B141B15C0713B8993F2831F7ABC0@SJEXCHMB12.corp.ad.broadcom.com> <CA+b+ERmjv0Z_g2P4D3HgWU_80M5fh=3M188Y1DjoVBQ=MTb-NQ@mail.gmail.com>
In-Reply-To: <CA+b+ERmjv0Z_g2P4D3HgWU_80M5fh=3M188Y1DjoVBQ=MTb-NQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.12]
Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF112218831E0eusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZXLonXHfm9w2hBl3TlSzW93pa3Fq6ktWi aWETswOzx6z7Z9k8liz5yeSxe+MCpgDmKC6blNSczLLUIn27BK6Mze23GAse7WSqWDf7NUsD 44mNTF2MnBwSAiYSby7fYYewxSQu3FvP1sXIxSEkcJRR4vPa+awQznJGiQ+zLrKBVLEJGEm8 2NgD1iEi4C1xpmEOUJyDg1lAWeLUXRmQsLBAnMShdVsZIUriJXp2dUPZdRKvD65hBrFZBFQl fp18C3YEr4CvxMqZW6F2tbNJzDzwghUkwSkQKLHu/1GwIkag676fWgNmMwuIS9x6Mh/qAwGJ JXvOM0PYohIvH/9jhbCVJOa8vsYMUZ8v8X/BL6hlghInZz5hmcAoOgvJqFlIymYhKZsF9pqm xPpd+hAlihJTuh+yQ9gaEq1z5rIjiy9gZF/FyFFanFqWm25kuIkRGGvHJNgcdzAu+GR5iFGA g1GJhzdBaEOoEGtiWXFl7iFGaQ4WJXFeab+8UCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M Luv+L5Z7GVcarWOybsP0r9M3KWfs5Tse6Ty5puD25yKty5n/Yi/tiQsxdrrVFfL9++yQvYvm FLwzd5HTXFVVElhsYebmolo7u8p978Sbk84Vn9rA9Klx/RvjDbNv2h5ltPh+f+JV9QWPtp19 FmTe+uBOorNqobiY0Sn+F892MYbsnuJwy0I4QImlOCPRUIu5qDgRAJaB26eWAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/rjgW_jmLdGq8HiTl5ZkeRNX_yk4>
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: Thu, 23 Jul 2015 21:43:31 -0000

Hi Robert,
with global labels and the fact that MPLS doesn’t have source identifier, how one proposes to do OAM, e.g. CC or PM?

                Regards,
                                Greg

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Thursday, July 23, 2015 11:37 PM
To: Shahram Davari
Cc: mpls@ietf.org
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

Hi Shahram,

Both IGP and BGP extensions are proposed.

As described they use the trick of locally defining a NO_SWAP semantics (for example by defining "CONTINUE" action as "swap to the same label") and using this notion in their architecture.

They do it as there is no MPLS architecture semantics for that.

Is it possible .. sure.

Is it optimal and good practice going forward .. I do not think so.

Best,
R.


On Thu, Jul 23, 2015 at 11:28 PM, Shahram Davari <davari@broadcom.com<mailto:davari@broadcom.com>> wrote:
Which control planes are already defined for this global label? IS-IS? BGP? If it is defined then what do you need?

Thx
SD

From: rraszuk@gmail.com<mailto:rraszuk@gmail.com> [mailto:rraszuk@gmail.com<mailto:rraszuk@gmail.com>] On Behalf Of Robert Raszuk
Sent: Thursday, July 23, 2015 2:22 PM

To: Shahram Davari
Cc: Eric C Rosen; stbryant@cisco.com<mailto:stbryant@cisco.com>; mpls@ietf.org<mailto: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<mailto: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> [mailto: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<mailto:stbryant@cisco.com>; mpls@ietf.org<mailto: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<mailto: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> [mailto: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<mailto:stbryant@cisco.com>; mpls@ietf.org<mailto: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.