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

[Eric C Rosen <[e-mail]>]

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.