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

Xuxiaohu <xuxiaohu@huawei.com> Wed, 09 March 2016 02:17 UTC

Return-Path: <xuxiaohu@huawei.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 2486212DD59; Tue, 8 Mar 2016 18:17:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 3mFcXzyZ30cS; Tue, 8 Mar 2016 18:17:53 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C37D812DD57; Tue, 8 Mar 2016 18:17:52 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKA42375; Wed, 09 Mar 2016 02:17:50 +0000 (GMT)
Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 9 Mar 2016 02:17:49 +0000
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0235.001; Wed, 9 Mar 2016 10:17:43 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: Tony Przygienda <tonysietf@gmail.com>, David Mozes <davidm@mellanox.com>
Thread-Topic: [Bier] problem bier-mpls-encap-sraft
Thread-Index: AdFzdh+eS8hcXNwMSGq0bB02yIBht///f2eA//MZ+XA=
Date: Wed, 09 Mar 2016 02:17:42 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D527F01@NKGEML515-MBX.china.huawei.com>
References: <VI1PR05MB14562DDD9EE8AD28F10729D8B6BB0@VI1PR05MB1456.eurprd05.prod.outlook.com> <CA+wi2hNNH7-mEgUBv8NN0m5ePb=fzqzz7jNz1W95aZp=+PR8BQ@mail.gmail.com>
In-Reply-To: <CA+wi2hNNH7-mEgUBv8NN0m5ePb=fzqzz7jNz1W95aZp=+PR8BQ@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.99.55]
Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D527F01NKGEML515MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.56DF87CF.008C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 622db3ae17baf57554399c87eb34c2c8
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/n4I8IR5DS6NiO7bl58ASRLbsY6M>
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 02:17:55 -0000


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
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