Re: [Bier] Proposed mods for architecture draft

[Tony Przygienda <[e-mail]>]

Eric, I'm for it with few clarifying nits:

1. "Each BFR MUST be assigned *a BIER domain-wide unique* "BFR-Prefix". A
*<deleted>* BFR-Prefix MUST be
   *a) *an IP *prefix *(*one and only one *of either IPv4 or IPv6) of the
BFR *and *
*  b) MUST come from** the same AF for all BFRs in the BIER domain* and
  c) MUST be routable within the BIER domain.

<deleted> Situations in which *those assumptions*
   does not hold are outside the scope of this document.

"

2. "This document assumes that, within a sub-domain, the mapping between
   BFR-id and BFR-Prefix is one-to-one.  Situations in which that
   assumption does not hold are outside the scope of this document."

   is strictly speaking a tautology of the previous two paragraphs.


This allows BTW a clean future flexibility where we can declare two BIER
domains overlapping same physical topology, one being IPv4-prefix carrying
and another IPv6-prefix carrying and for controllers one possibly without
even a routing underlay or in other terms BIER domains distinguished by
different signaling types ...

 --- tony


On Tue, Jun 20, 2017 at 12:54 PM, Eric C Rosen <[e-mail]> wrote:

> We need to remember that we have begun the process of moving the initial
> set of standards to RFC status.  Thus, this is not a good time to be adding
> features.  It is also not a good time to be changing the assumptions we've
> been working with for the past few years.  So I want to take a fairly
> conservative approach to making changes.
>
> With that in mind, I would like to propose replacing the first two
> paragraphs of section 2 with the following four paragraphs:
>
> --------
>
> 2.  The BFR Identifier and BFR-Prefix
>
>    Each BFR MUST be assigned a "BFR-Prefix".  A BFR's BFR-Prefix MUST be
>    an IP address (either IPv4 or IPv6) of the BFR, and MUST be routable
>    within the BIER domain.  It is RECOMMENDED that the BFR-prefix be a
>    loopback address of the BFR.  Note that a BFR in a given BIER domain
>    has the same BFR-prefix in all the sub-domains of that BIER domain.
>
>    This document assumes that, within a domain, the mapping between BFR
>    and BFR-Prefix is one-to-one.  Situations in which that assumption
>    does not hold are outside the scope of this document.
>
>    A "BFR Identifier" (BFR-id) is a number in the range [1,65535].  In a
>    given BIER sub-domain, each BFR-Prefix is associated with a number
>    from this range.  If it is known that a given BFR will never need to
>    function as a BFER or BFIR in a given sub-domain, then it is not
>    necessary to assign a BFR-id for that sub-domain to that BFR.
>
>    This document assumes that, within a sub-domain, the mapping between
>    BFR-id and BFR-Prefix is one-to-one.  Situations in which that
>    assumption does not hold are outside the scope of this document.
>
> --------
>
> This maintains the same assumptions we've worked with for the past several
> years, but leaves it open for future documents to consider whether it makes
> sense to loosen some of the assumptions.
>
> Comments?
>
> I think this is the only area of controversy that has come up recently.
>
> I don't think we want to consider now what all the possible implications
> might be of changing the assumptions, so I think our only two alternatives
> are (a) leave the text as is, or (b) something like I've suggested above.
>
> We certainly do not want to design a v4-to-v6 transition scheme before
> advancing the document, and I'm at all sure that there will be a "one size
> fits all" solution.
>
> The other LC comments are more straightforward:
>
> - Make the document more even-handed between the MPLS and non-MPLS
> encapsulations (which required textual changes in about half a dozen
> places),
>
> - Add a few remarks about the decapsulation procedure,
>
> - RECOMMEND a BitStringLength fallback value of 256,
>
> - Fix a bug in the F-BM values in some of the examples.
>
> These are fixed in the XML source, but I don't want to post a new rev
> until we have some consensus on how to deal with the one area of
> controversy.
>
>
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier
>



-- 
*We’ve heard that a million monkeys at a million keyboards could produce
the complete works of Shakespeare; now, thanks to the Internet, we know
that is not true.*
—Robert Wilensky