Re: [mpls] [Bier] problem bier-mpls-encap-sraft

David Mozes <davidm@mellanox.com> Wed, 09 March 2016 16:44 UTC

Return-Path: <davidm@mellanox.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9887312D883; Wed, 9 Mar 2016 08:44:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mellanox.com
Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ekp2poJNQuoD; Wed, 9 Mar 2016 08:43:58 -0800 (PST)
Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0631.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00B3D12D7C5; Wed, 9 Mar 2016 08:43:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IVopzqBG/tJUlBJdMjA+bdj0pCiTqE61PP7WE7/dHzA=; b=hhtwS1ThmTkfdMKI1XD2CXZC3uPSeBVUrpKMr1b800BiSeOaRG1DwY7JDaNoP9fypNVtK+h1D/DtL4RrwYxbVGruFxIu56ZpZJpY0qiXbyLCk8ltLlQskWV8bAEB91sKzDym5LsrThsgsgzmcXN3vXqA9INzALOTzjHOH4hnzsE=
Received: from VI1PR05MB1456.eurprd05.prod.outlook.com (10.164.85.26) by VI1PR05MB1453.eurprd05.prod.outlook.com (10.164.85.23) with Microsoft SMTP Server (TLS) id 15.1.415.20; Wed, 9 Mar 2016 16:43:36 +0000
Received: from VI1PR05MB1456.eurprd05.prod.outlook.com ([10.164.85.26]) by VI1PR05MB1456.eurprd05.prod.outlook.com ([10.164.85.26]) with mapi id 15.01.0415.024; Wed, 9 Mar 2016 16:43:36 +0000
From: David Mozes <davidm@mellanox.com>
To: Xuxiaohu <xuxiaohu@huawei.com>, Tony Przygienda <tonysietf@gmail.com>
Thread-Topic: [Bier] problem bier-mpls-encap-sraft
Thread-Index: AdFzdh+eS8hcXNwMSGq0bB02yIBhtwAAsIOAAYw+nQAAHa0QQA==
Date: Wed, 9 Mar 2016 16:43:35 +0000
Message-ID: <VI1PR05MB1456F87EFC9B3ED82A417C2FB6B30@VI1PR05MB1456.eurprd05.prod.outlook.com>
References: <VI1PR05MB14562DDD9EE8AD28F10729D8B6BB0@VI1PR05MB1456.eurprd05.prod.outlook.com> <CA+wi2hNNH7-mEgUBv8NN0m5ePb=fzqzz7jNz1W95aZp=+PR8BQ@mail.gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D527F01@NKGEML515-MBX.china.huawei.com>
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D527F01@NKGEML515-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=mellanox.com;
x-originating-ip: [193.47.165.251]
x-microsoft-exchange-diagnostics: 1; VI1PR05MB1453; 5:Vh1APJQoxF4oCSipcGNmaqdSy2JRCY0hhgDPeQ39Gq41UEhTsjzJ0ntABvmS9Au0z2A0plsrppBZhQpsoGV/TB2OPfjxbCJfKWjZ6PL7e3hMuUO0UDtZAa8IY7fUV2Rv+rd1SNp9osnPOwwUgKKoIw==; 24:q41qhhBz+1pAkHwTgGoq2O6GlmtJufIEC8sf6M90djgOByFSCp079mAVolkan4lTXX4NNzxi/Fve8+hwAmWp/wymc/t2iyBw0kVndlDLr88=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR05MB1453;
x-ms-office365-filtering-correlation-id: b91b83c1-1396-4aec-5f1a-08d34839f5ce
x-microsoft-antispam-prvs: <VI1PR05MB145381DA043547604AF80104B6B30@VI1PR05MB1453.eurprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:VI1PR05MB1453; BCL:0; PCL:0; RULEID:; SRVR:VI1PR05MB1453;
x-forefront-prvs: 0876988AF0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(377454003)(230783001)(19300405004)(4326007)(76576001)(189998001)(5002640100001)(11100500001)(2950100001)(10400500002)(87936001)(92566002)(3280700002)(2900100001)(86362001)(2906002)(81166005)(50986999)(6116002)(66066001)(76176999)(77096005)(54356999)(3846002)(1220700001)(1096002)(19617315012)(586003)(102836003)(15975445007)(5008740100001)(122556002)(19609705001)(790700001)(19625215002)(33656002)(74316001)(19580395003)(3660700001)(16236675004)(5001770100001)(5003600100002)(5004730100002)(19580405001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR05MB1453; H:VI1PR05MB1456.eurprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR05MB1456F87EFC9B3ED82A417C2FB6B30VI1PR05MB1456eurp_"
MIME-Version: 1.0
X-OriginatorOrg: Mellanox.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2016 16:43:35.9587 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR05MB1453
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/Q1V6lmrrhKQbtkJjZ-sVNlneYhA>
Cc: "'mpls@ietf.org'" <mpls@ietf.org>, "bier@ietf.org" <bier@ietf.org>
Subject: Re: [mpls] [Bier] problem bier-mpls-encap-sraft
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 09 Mar 2016 16:44:02 -0000

Hi ,
I can’t open  the doc  .
From: Xuxiaohu [mailto:xuxiaohu@huawei.com]
Sent: Wednesday, March 09, 2016 4:18 AM
To: Tony Przygienda <tonysietf@gmail.com>om>; David Mozes <davidm@mellanox.com>
Cc: bier@ietf.org; 'mpls@ietf.org' <mpls@ietf.org>
Subject: RE: [Bier] problem bier-mpls-encap-sraft



From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Tony Przygienda
Sent: Tuesday, March 01, 2016 1:12 PM
To: David Mozes
Cc: bier@ietf.org<mailto:bier@ietf.org>
Subject: Re: [Bier] problem bier-mpls-encap-sraft

David,

1) there was a longish discussion on the list about the 4 bits and the value chosen & the DPI-ECMP problem. I suggest to read the archives. the problem is not specific to BIER. Actually, I recently heard a suggestion that we should provide from IETF side a registry for the values in the 4 bits but it's A-Ds business, not WG level IMO (if there isn't such a registry for 'IP versions' already).

Wouldn’t be better to define a protocol field in the MPLS label stack (e.g., https://tools.ietf.org/html/draft-xu-mpls-payload-protocol-identifier) rather than interfering  in the definition of the 4-bit of the MPLS payload?

Best regards,
Xiaohu

2) The length is present for analytics tools but silicon MUST NOT use it to derive the length but the length is implied in the label. It's simply architectural DRY. If you repeat semantically the length implied in the label, you'll end up with error scenarios you need to provide for. Actually, the draft already mandates that on mismatch the packet SHOULD be discarded (which means silicon doesn't actually need to check it if it wants to go at max. speed).

Generally, sweeping assertions like "using the label as the bier identifier on the packet as well as the bit string length is not a good approach for HW/Silicon supporting" would need a little more elaboration as to what they're based upon ?

thanks

--- tony


On Mon, Feb 29, 2016 at 9:02 PM, David Mozes <davidm@mellanox.com<mailto:davidm@mellanox.com>> wrote:
Hi * ,
I have problems with the MPLS encap draft  .

I thing using the label as the bier identifier on the packet as well as the bit string length is not a good approach for HW/Silicon supporting  .
This make the support difficult  and very unique,especially to intermedia node that not supporting MPLS  entropy label  and like   to support ECMP by deep looking inside the IP header .
I think we should :

1)      Define some protocol type or control  word  to strictly detect the beir header . Or define the guessing of the first 4 bits as a valid parsing  approach  .

2)      Make the  bits string  length inside the bear header as  mandatory  .

This will help a lot

Your thought  ?
Thx

_______________________________________________
BIER mailing list
BIER@ietf.org<mailto:BIER@ietf.org>
https://www.ietf.org/mailman/listinfo/bier



--
We’ve heard that a million monkeys at a million keyboards could produce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.
—Robert Wilensky