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

Xuxiaohu <> Fri, 20 March 2015 06:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 211D51B2C52; Thu, 19 Mar 2015 23:57:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.422
X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, 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 Qf3u4KEcMcui; Thu, 19 Mar 2015 23:57:29 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1EAF81B2C53; Thu, 19 Mar 2015 23:57:28 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id BQM11258; Fri, 20 Mar 2015 06:57:27 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 20 Mar 2015 06:57:26 +0000
Received: from ([]) by ([]) with mapi id 14.03.0158.001; Fri, 20 Mar 2015 14:56:05 +0800
From: Xuxiaohu <>
To: Antoni Przygienda <>, Eric C Rosen <>, idr wg <>, "" <>
Thread-Topic: [Bier] [Idr] FW: New Version Notification for draft-xu-idr-bier-extensions-01.txt
Thread-Index: AQHQYasKItkY8wf3SEK3xghRwHT+hp0iGHCAgALZbFA=
Date: Fri, 20 Mar 2015 06:56:06 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Idr] [Bier] FW: New Version Notification for draft-xu-idr-bier-extensions-01.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: Fri, 20 Mar 2015 06:57:31 -0000

Hi Eric and Tony,

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

> -----邮件原件-----
> 发件人: Antoni Przygienda []
> 发送时间: 2015年3月19日 3:23
> 收件人: Eric C Rosen; Xuxiaohu; idr wg;
> 主题: RE: [Bier] [Idr] FW: New Version Notification for
> draft-xu-idr-bier-extensions-01.txt
> >
> > The draft never quite says that if the BIER path attribute is present,
> > the NLRI is treated by BIER as a "BFR-prefix".  Unless I'm
> > misunderstanding something, I think this needs to be said explicitly.
>  [Tony saiz:]  I made the same comment and a larger discussion is whether
> only a single NLRI (BFR-prefix) is allowed in such an update (i.e. update carrying
> BIER attributes).

Will make it clear in the next version.

> > It might be worth mentioning that, when creating a BIER attribute, a
> > BFR needs to include one BIER TLV for every <sub-domain, bsl> pair that it
> supports.
>  [Tony saiz:] I made the same comment. Alternative is to have a single BIER
> attribute per sub-domain in an update to allow e.g. a loopback per sub-domain
> (which does not sound right to me since the architecture seems to imply  a 1-1
> assocation between a BFR prefix and a BIER domain).

Will make it clear in the next version.

> > I wonder (warning, half-baked idea approaching) if the BIER TLV needs
> > something like a "BIER next hop" sub-TLV.  This could be changed to
> > 'self' by every BFR that redistributes the route, but would be left
> > unchanged by non- BFRs. Then you'd always know the next BFR in the path to
> a given BFER.
>  [Tony saiz:]  hmm, yes, given the tunneling in the architecture this is
> something I have to think through as well.

Will consider it in the next version. Another way is to directly tunnel the BIER packet to the BFER. This way has been mentioned in the current version:

   Since the BIER attribute is an optional, transitive BGP path
   attribute, a non-BFR BGP speakers could still advertise the received
   route with a BIER attribute.  This is desirable in the incremental
   deployment scenario where a BGP speaker could tunnel a BIER packet or
   the payload of a BIER packet to a BFER directly if the BGP next-hop
   of the route for that BFER is a non-BFR.

Best regards,
> --- tony