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

Xuxiaohu <> Tue, 17 February 2015 03:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 747421A8953; Mon, 16 Feb 2015 19:08:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ux67wckMjm5h; Mon, 16 Feb 2015 19:08:55 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E7E811A86DE; Mon, 16 Feb 2015 19:08:53 -0800 (PST)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id BSS24979; Tue, 17 Feb 2015 03:08:52 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 17 Feb 2015 03:08:51 +0000
Received: from ([]) by ([]) with mapi id 14.03.0158.001; Tue, 17 Feb 2015 11:08:44 +0800
From: Xuxiaohu <>
To: Antoni Przygienda <>, "" <>, idr wg <>
Thread-Topic: [Bier] FW: New Version Notification for draft-xu-idr-bier-extensions-00.txt
Thread-Index: AQHQSlZlMR85vC1xX0KsHdMGHaa/oZz0Gozg
Date: Tue, 17 Feb 2015 03:08:44 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083098C8NKGEML512MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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:08:58 -0000

Hi Tony,

Thanks a lot for your valuable comments and suggestion. Please see my response inline.

From: Antoni Przygienda []
Sent: Tuesday, February 17, 2015 10:07 AM
To: Xuxiaohu;; idr wg
Subject: RE: [Bier] FW: New Version Notification for draft-xu-idr-bier-extensions-00.txt

<hat type="individual cat contributor">

Xuxiaohu, thanks for the work.

multiple things:

  The BFR-ID TLV is encoded as follows:



      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.

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.

   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.

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.

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

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.

Best regards,




--- tony

> -----Original Message-----

> From: BIER [] On Behalf Of Xuxiaohu

> Sent: Monday, February 16, 2015 5:31 PM

> To:<>; idr wg

> Subject: [Bier] FW: New Version Notification for draft-xu-idr-bier-extensions-

> 00.txt


> Hi all,


> Any comments are welcome.


> Best regards,

> Xiaohu


> > -----Original Message-----

> > From:<> []

> > Sent: Tuesday, February 17, 2015 9:26 AM

> > To: Mach Chen; Xuxiaohu; Xuxiaohu; IJsbrand Wijnands; Keyur Patel;

> > Keyur Patel; IJsbrand Wijnands; Mach Chen

> > Subject: New Version Notification for

> > draft-xu-idr-bier-extensions-00.txt

> >

> >

> > A new version of I-D, draft-xu-idr-bier-extensions-00.txt

> > has been successfully submitted by Xiaohu Xu and posted to the IETF

> repository.

> >

> > Name:                          draft-xu-idr-bier-extensions

> > Revision:       00

> > Title:                             BGP Extensions for BIER

> > Document date:         2015-02-16

> > Group:                          Individual Submission

> > Pages:                           7

> > URL:

> >

> > Status:

> > Htmlized:

> >

> >

> > Abstract:

> >    Bit Index Explicit Replication (BIER) is a new multicast forwarding

> >    architecture which doesn't require an explicit tree-building protocol

> >    and doesn't require intermediate routers to maintain any multicast

> >    state.  BIER is applicable in a multi-tenant data center network

> >    envioronment for efficient delivery of Broadcast, Unknown-unicast and

> >    Multicast (BUM) traffic while eliminating the need for maitaining a

> >    huge amount of multicast state in an underlay.  This document

> >    describes BGP extensions for advertising the BIER-specific

> >    information.  These extesnions are applicable in those multi-tenant

> >    data centers where BGP instead of IGP is deployed as an underlay for

> >    network reachability advertisement.  These extensions may also be

> >    applicable in other scenarios.

> >

> >

> >

> >

> > Please note that it may take a couple of minutes from the time of

> > submission until the htmlized version and diff are available at

> >

> > The IETF Secretariat


> _______________________________________________

> BIER mailing list