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

From: Xuxiaohu <[email-masked]>
Date: Thu, 5 Mar 2015 03:51:39 +0000

Hi all,

The updated version has been submitted. 

Any further comments are welcome.

Best regards,
Xiaohu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, March 05, 2015 11:47 AM
> To: Mach Chen; Xuxiaohu; Tony Przygienda; Xuxiaohu; IJsbrand Wijnands; Keyur
> Patel; Antoni Przygienda; Keyur Patel; IJsbrand Wijnands; Mach Chen
> Subject: New Version Notification for draft-xu-idr-bier-extensions-01.txt
> 
> 
> A new version of I-D, draft-xu-idr-bier-extensions-01.txt
> has been successfully submitted by Xiaohu Xu and posted to the IETF repository.
> 
> Name:		draft-xu-idr-bier-extensions
> Revision:	01
> Title:		BGP Extensions for BIER
> Document date:	2015-03-03
> Group:		Individual Submission
> Pages:		7
> URL:
> http://www.ietf.org/internet-drafts/draft-xu-idr-bier-extensions-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-xu-idr-bier-extensions/
> Htmlized:       http://tools.ietf.org/html/draft-xu-idr-bier-extensions-01
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-xu-idr-bier-extensions-01
> 
> 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
>    environment for efficient delivery of Broadcast, Unknown-unicast and
>    Multicast (BUM) traffic while eliminating the need for maintaining a
>    huge amount of multicast state in the underlay.  This document
>    describes BGP extensions for advertising the BIER-specific
>    information.  These extensions 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 tools.ietf.org.
> 
> The IETF Secretariat

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 18 Mar 2015 14:40:29 -0400

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

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.

---

From: Antoni Przygienda <[email-masked]>
Date: Wed, 18 Mar 2015 19:22:59 +0000

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

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

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

--- tony

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 20 Mar 2015 06:56:06 +0000

Hi Eric and Tony,

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

> -----邮件原件-----
> 发件人: Antoni Przygienda [mailto:[email-masked]]
> 发送时间: 2015年3月19日 3:23
> 收件人: Eric C Rosen; Xuxiaohu; idr wg; [email-masked]
> 主题: RE: [Bier] [Idr] FW: New Version Notification for
> draft-xu-idr-bier-extensions-01.txt
> 
> >
>  [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.

> > 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,
Xiaohu