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

Eric C Rosen <> Wed, 18 March 2015 18:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BBED81A900A; Wed, 18 Mar 2015 11:40:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CrsW4aPdDBNr; Wed, 18 Mar 2015 11:40:54 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fc10::701]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 868CB1A8842; Wed, 18 Mar 2015 11:40:54 -0700 (PDT)
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id; Wed, 18 Mar 2015 18:40:34 +0000
Message-ID: <>
Date: Wed, 18 Mar 2015 14:40:29 -0400
From: Eric C Rosen <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Xuxiaohu <>, idr wg <>, "" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
X-ClientProxiedBy: ( To (
Authentication-Results:; dkim=none (message not signed) header.d=none;
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1093;
X-Microsoft-Antispam-PRVS: <>
X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6049001)(6009001)(86362001)(46102003)(33656002)(42186005)(23746002)(230783001)(59896002)(122386002)(92566002)(80316001)(83506001)(77096005)(2950100001)(77156002)(62966003)(87976001)(65806001)(40100003)(50986999)(66066001)(65956001)(36756003)(2501003)(50466002)(65816999)(76176999)(47776003)(54356999)(64126003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1093; H:[]; FPR:; SPF:None; MLV:sfv; LANG:en;
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:BY1PR0501MB1093; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1093;
X-Forefront-PRVS: 051900244E
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Mar 2015 18:40:34.3980 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1093
Archived-At: <>
Subject: Re: [Idr] 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: Wed, 18 Mar 2015 18:40:56 -0000

Just a couple of comments.

Consider carefully whether you really want the TLVs and sub-TLVs to have 
single-octet type fields.  A two-octet type field could have a FCFS 
allocation policy for at least part of its range, which makes it a lot 
easier to avoid codepoint clash (and a lot easier to deploy stuff 
without getting involved in IETF politics).

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.

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 

I find the following text from section 4 to be somewhat confusing:

    Furthermore, the routable address contained in the NLRI is
    RECOMMENDED to be the one used for establishing BGP sessions.  In
    other words, the routable address is usually used as the BGP nexthop
    address of BGP updates advertised by that BGP speaker.

The text following "in other words" doesn't really seem to be a 
paraphrase of the previous sentence; I'm not sure what you're really 
trying to say here.

I suspect that what you're trying to say is something like: "When BGP 
distributes a route whose NLRI is a BFR-prefix, the next hop SHOULD also 
be a BFR-prefix."

Of course, that leads to the question of what to do when the next hop is 
not a BFR-prefix.  I don't think there's a clear answer in the draft. 
There is some text in section 6 suggesting that one could tunnel 
downstream to the next BIER-capable router on the path, but there's no 
text saying how you would figure out who that is.

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.

We'd also have to take into account the case where a BFR redistributing 
a route supports some but not all of the sub-domains mentioned in the 
BIER attribute.  Probably the BIER next hop sub-TLV would only get 
changed by a given BFR if that BFR is in the sub-domain identified by 
the BIER TLV that contains said sub-TLV.