Re: [Bier] Proposed mods for architecture draft

[IJsbrand Wijnands <[e-mail]>]

Eric, WG,

Sub-domains are signalled independently and operate independently of each other. I think that the text "Note that a BFR in a given BIER domain has the same BFR-prefix in all the sub-domains of that BIER domain.” is an textual restriction, but not a restriction in the architecture as how we defined it.

Based on Alia’s comment and the discussion we just had, I see no problem to allow different sub-domain’s on a given BFR to be associated with a different BFR-prefix.

I agree we don’t want to add new features to the architecture draft at this stage, but in this case, the feature is already there, we’re just restricting it by the current text.

Thx,

Ice.

> On 20 Jun 2017, at 21:54, 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