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

Shahram Davari <davari@broadcom.com> Mon, 20 July 2015 16:27 UTC

Return-Path: <davari@broadcom.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 770C91A8AA8 for <mpls@ietfa.amsl.com>; Mon, 20 Jul 2015 09:27:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 dpwL3kdRnc-l for <mpls@ietfa.amsl.com>; Mon, 20 Jul 2015 09:27:41 -0700 (PDT)
Received: from mail-gw1-out.broadcom.com (mail-gw1-out.broadcom.com [216.31.210.62]) by ietfa.amsl.com (Postfix) with ESMTP id 27A091A88EB for <mpls@ietf.org>; Mon, 20 Jul 2015 09:27:41 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.15,508,1432623600"; d="scan'208";a="70369511"
Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw1-out.broadcom.com with ESMTP; 20 Jul 2015 10:37:14 -0700
Received: from SJEXCHCAS07.corp.ad.broadcom.com (10.16.203.16) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 20 Jul 2015 09:27:40 -0700
Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS07.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Mon, 20 Jul 2015 09:27:40 -0700
From: Shahram Davari <davari@broadcom.com>
To: "stbryant@cisco.com" <stbryant@cisco.com>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?
Thread-Index: AQHQwwR9OwfTAAS3/0O9L44IGnUJ+p3kitkg
Date: Mon, 20 Jul 2015 16:27:39 +0000
Message-ID: <4A6CE49E6084B141B15C0713B8993F2831F73A21@SJEXCHMB12.corp.ad.broadcom.com>
References: <55AD19F2.1010206@cisco.com>
In-Reply-To: <55AD19F2.1010206@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.16.203.100]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/4w6_HCgVjEU9UDxjyxxjpRArN70>
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: Mon, 20 Jul 2015 16:27:42 -0000

Hi Stewart,

This draft actually saves a lot of memory as it requires only very little MPLS entry table and associated processing.
There are only a few Ethernet MAC headers used in MPLS forwarding, typically one MAC per port, but there can be thousands 
Of swapped labels. So it is not a matter of 14 bytes vs 18 bytes.

We have seen this requirement come up from various data enter operators in Segment routing context.

Thanks
Shahram

-----Original Message-----
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Monday, July 20, 2015 8:55 AM
To: mpls@ietf.org
Subject: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?


I am curious about how much is actually saved with the MPLS dataplane
change proposed in this draft.

If this is used in an Ethernet environment the LSR already needs to
remove and replace the Ethernet header.

In many implementations the datalink header and the MPLS outer
label are part of the same re-write string. So what is the true
gain in writing 14 bytes instead of 18 bytes?

... or is this planned for use with some pt-pt data link other
than Ethernet which is required to be constant end to end?

- Stewart


_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls