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

David Mozes <> Wed, 09 March 2016 16:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9887312D883; Wed, 9 Mar 2016 08:44:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ekp2poJNQuoD; Wed, 9 Mar 2016 08:43:58 -0800 (PST)
Received: from ( [IPv6:2a01:111:f400:fe04::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 00B3D12D7C5; Wed, 9 Mar 2016 08:43:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IVopzqBG/tJUlBJdMjA+bdj0pCiTqE61PP7WE7/dHzA=; b=hhtwS1ThmTkfdMKI1XD2CXZC3uPSeBVUrpKMr1b800BiSeOaRG1DwY7JDaNoP9fypNVtK+h1D/DtL4RrwYxbVGruFxIu56ZpZJpY0qiXbyLCk8ltLlQskWV8bAEB91sKzDym5LsrThsgsgzmcXN3vXqA9INzALOTzjHOH4hnzsE=
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.415.20; Wed, 9 Mar 2016 16:43:36 +0000
Received: from ([]) by ([]) with mapi id 15.01.0415.024; Wed, 9 Mar 2016 16:43:36 +0000
From: David Mozes <>
To: Xuxiaohu <>, Tony Przygienda <>
Thread-Topic: [Bier] problem bier-mpls-encap-sraft
Thread-Index: AdFzdh+eS8hcXNwMSGq0bB02yIBhtwAAsIOAAYw+nQAAHa0QQA==
Date: Wed, 9 Mar 2016 16:43:35 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-originating-ip: []
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: <>
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;; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR05MB1456F87EFC9B3ED82A417C2FB6B30VI1PR05MB1456eurp_"
MIME-Version: 1.0
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: <>
Cc: "''" <>, "" <>
Subject: Re: [mpls] [Bier] problem bier-mpls-encap-sraft
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Mar 2016 16:44:02 -0000

Hi ,
I can’t open  the doc  .
From: Xuxiaohu []
Sent: Wednesday, March 09, 2016 4:18 AM
To: Tony Przygienda <>om>; David Mozes <>
Cc:; '' <>
Subject: RE: [Bier] problem bier-mpls-encap-sraft

From: BIER [] On Behalf Of Tony Przygienda
Sent: Tuesday, March 01, 2016 1:12 PM
To: David Mozes
Subject: Re: [Bier] problem bier-mpls-encap-sraft


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., rather than interfering  in the definition of the 4-bit of the MPLS payload?

Best regards,

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 ?


--- tony

On Mon, Feb 29, 2016 at 9:02 PM, David Mozes <<>> 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  ?

BIER mailing list<>

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