Re: [Idr] [Bier] FW: New Version Notification for draft-xu-idr-bier-extensions-00.txt

Antoni Przygienda <> Tue, 17 February 2015 03:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A7AC11A00FE; Mon, 16 Feb 2015 19:24:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.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] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UfaPwSowm5ev; Mon, 16 Feb 2015 19:24:36 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 88CC21A0162; Mon, 16 Feb 2015 19:24:36 -0800 (PST)
X-AuditID: c618062d-f79376d000000ceb-df-54e26089acb2
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 7E.F0.03307.98062E45; Mon, 16 Feb 2015 22:26:34 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0210.002; Mon, 16 Feb 2015 22:24:33 -0500
From: Antoni Przygienda <>
To: Xuxiaohu <>, "" <>, idr wg <>
Thread-Topic: [Bier] FW: New Version Notification for draft-xu-idr-bier-extensions-00.txt
Thread-Index: AQHQSlCq3k5gpZgciU2QvKfhI3xxk5z0DcqggAADj/CAAGvqAP//ru+g
Date: Tue, 17 Feb 2015 03:24:32 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_2E4BB27CAB87BF43B4207C0E55860F1825C259eusaamb103ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyuXSPn25XwqMQg+ULuS2WztjDZPHq9jMm i63nVzE6MHu0HHnL6rFkyU+mAKYoLpuU1JzMstQifbsErowjkz6wF0w4w1hxcLtPA+P7rYxd jBwcEgImErv2JXQxcgKZYhIX7q1n62Lk4hASOMIo8fhYFzOEs5xRYtnMrWwgVWwCFhKXvz1l BmkWEYiR+DiRCyQsLBAlcfz4T0YQW0QgWmLV281QtptEX/tudhCbRUBVYuW3drAxvALeEt++ 3mQBsYUEHjNKfJliDWJzCoRJLPjxhAnEZgQ66PupNWA2s4C4xK0n85kgDhWQWLLnPDOELSrx 8vE/VghbSWLS0nOsEPX5EhOX/2SF2CUocXLmE5YJjCKzkIyahaRsFpIyiLiOxILdn9ggbG2J ZQtfM8PYZw48ZkIWX8DIvoqRo7Q4tSw33chgEyMwjo5JsOnuYNzz0vIQowAHoxIPr4HdoxAh 1sSy4srcQ4zSHCxK4ryLHhwMERJITyxJzU5NLUgtii8qzUktPsTIxMEp1cC4I0yjLs+jKWnB Stf6XSqxd/6bTT3a+Xld2y/3cy8OCSx8v89vy/OGu+fnLbR94uPKmq/+zUBsgp+y/9Y0nqRi K71G6dMXdDImfqn9Pl3AMcH2gSz3RItOn3f7dpq/Lt0bvNyGyXzb3dNSalUvT25P//9O5Umv XsC+WMemIlv1Z89Lfwkt7lusxFKckWioxVxUnAgA01GCXYQCAAA=
Archived-At: <>
Subject: Re: [Idr] [Bier] FW: New Version Notification for draft-xu-idr-bier-extensions-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Feb 2015 03:24:39 -0000


      Value: contains a two-octet BFR-ID.

I am missing here the indication of subdomain-id since without that, the BFR-ID will easily collide within the BIER domain advertising the BGP info @ the edge.

[Xiaohu] Thanks for point it out. Will fix it in the next version.

[Tony said] ack

The BSL TLV is encoded as follows:



      Value: contains a one-octet BSL which indicates the length of the

      Bitstring in 4-octets.

Is this encoded equivalent to MPLS draft ? Indicate so and indicate WHICH bits are used and which are reserved. If not, indicate how e.g.  33 as bitstring length should be treated if e.g. the ensuing encaps cannot deal with it ?

[Xiaohu] IMHO, it'd better to specify the legal BSL values in the BIER arch draft which should be independent of specific BIER encapsulations.

[Tony said]  agreed, that's a heads-up for Ice to put it into the architecture draft me thinks. It's hanging in the MPLS draft right now. Given how widely it's referenced, it should be moved up me thinks.

   The BIER MPLS Encapsualtion TLV is encoded as follows:



      Value: contains a one-octet Label Range Size field indicating the

      size of the label range, and a 3-octect Label Rang Base field

      where the 20 rightmost bits represent the first label in the label


indicate that the other bits are reserved/must be ignored/send 0

Generally, it is considered de rigeur to make nice pictures of those TLVs to make the documents more readable. I suggest doing so.

[Xiaohu] Thanks for the above suggestions. Will fix them in the next version.

[Tony said] ack

Another question here is what happens when multiple eBPG edges of an AD advertise this attribute. Is the preference driven by MED [or another attribute?] based e.g. on the IGP distance within AD to the BFR ?

[Xiaohu] I think so.

[Tony said] ack, I suggest to put it into lead-in section (Special considerations, requireements, assumptions, something ?)

Is the expectation that each BGP router advertising this is BFR itself ? Or has capabilities to unicast tunnel into the BIER domain ?

[Xiaohu]Since the BIER attribute is an optional, transitive BGP path attribute, it should support the scenario where a BGP speaker is allowed to tunnel a BIER packet or the payload of a BIER packet to the BFER directly if the BGP next-hop is a non-BFR. Furthermore, it should support as well the scenario where a BGP speaker is allowed to tunnel a BIER packet to the BGP next-hop if these two BGP peers are not directly connected (e.g., multi-hop EBGP) .

[Tony said] [Tony said] Yes, I suggest a small section stating this and explaining this.

Overall, this seems to imply somewhat that BIER domain is aligned with the whole IGP domain (and not areas) and e.g. two OSPF areas cannot be two BIER domains.  This is an interesting architectural question that wasn't brought up yet ?

[Xiaohu] In this doc, it's assumed that a BIER domain is aligned with the whole network consist of multiple ASes.

[Tony said] Let's spell it out and have a discussion @ next BOF/WG [whatever we become when we've grown up to have a charter ;-) ]  I think it will be a very relevant architectural decision at this point in time and possibly influence all IGP drafts. What speaks against BIER domain aligned with AD is scalabilty, what speaks for it is simplicity.

--- tony