[Bier] Proposed mods for architecture draft

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

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.