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

[Xuxiaohu <[e-mail]>]

Hi Eric and Tony,

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

> -----邮件原件-----
> 发件人: Antoni Przygienda [mailto:[e-mail]]
> 发送时间: 2015年3月19日 3:23
> 收件人: Eric C Rosen; Xuxiaohu; idr wg; [e-mail]
> 主题: 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,
Xiaohu
 
> --- tony