Re: [Bier] Proposed mods for architecture draft

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

Based on the comments from Ice and Tony, I propose to begin Section 2 
with the following text:

----------

    Each BFR MUST be assigned a single "BFR-Prefix" for each sub-domain
    to which it belongs.  A BFR's BFR-Prefix MUST be an IP address
    (either IPv4 or IPv6) of the BFR.  It is RECOMMENDED that the
    BFR-prefix be a loopback address of the BFR.

    If a BFR belongs to more than one sub-domain, it may (though it need
    not) have a different BFR-prefix in each sub-domain.

    All BFR-Prefixes used within a given sub-domain MUST belong to the
    same address family (either IPv4 or IPv6).

    The BFR-prefix of a given BFR in a given sub-domain MUST be routable
    in that sub-domain.  Whether a particular BFR-Prefix is routable in a
    given sub-domain depends on the "routing underlay" associated with
    that sub-domain.  The notion of "routing underlay" is described in
    Section 4.1.

    A "BFR Identifier" (BFR-id) is a number in the range [1,65535].
    Within a given sub-domain, every BFR that may need to function as a
    BFIR or BFER MUST have a single BFR-id, which identifies it uniquely
    within that sub-domain.  A BFR that does not need to function as a
    BFIR or BFER in a given sub-domain does not need to have a BFR-id in
    that sub-domain.

    The value 0 is not a legal BFR-id.

-----------

We thus retain the requirements that in a given sub-domain, (a) a BFR 
has one BFR-Prefix, (b) a BFR-id maps to a single BFR-Prefix, and (c) a 
BFR-Prefix maps to at most one BFR-id.  But we eliminate the unnecessary 
requirement that a BFR has the same BFR-Prefix in all sub-domains.

I was wondering whether we really want to require that all BFR-Prefixes 
in a given sub-domain be of the same address family.  It might be enough 
to require only that all such prefixes are routable in the routing 
underlay of that sub-domain.  However, restricting a sub-domain to a 
single AF is probably a good simplifying assumption.  (It will be nice 
if the overlay signaling doesn't have to deal with multiple address 
families in a single sub-domain.)

It's been pointed out that this prevents a set of BFERs from having a 
shared anycast address as an additional BFR-Prefix.  I am not too 
bothered by this as the use of anycast addresses by multicast receivers 
doesn't seem too crucial, and allowing that would count as a "new feature".

Objections?



On related issues ...

Taking a quick look at the OSPF and ISIS drafts, I think it would be a 
good idea if each draft had a sentence saying precisely where the 
BFR-Prefix appears in the advertisements.

The MVPN draft needs a modification to require that the "Originating 
Router's IP Address" field of the Leaf A-D route NLRI be set to the 
originating router's BFR-Prefix in the sub-domain on which it intends to 
receive the packets.  I don't know if there is a similar issue for other 
overlay signaling drafts.