Re: [Bier] Proposed mods for architecture draft

[Alia Atlas <[e-mail]>]

This discussion and the proposed text satisfy my concerns.

Thanks,
Alia

On Wed, Jun 21, 2017 at 11:13 AM, Eric C Rosen <[e-mail]> wrote:

> 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.
>
>
>
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier
>