Subject: Re: [Bier] BitStringLengths in draft-ietf-bier-architecture-07

From: Greg Shepherd <[email-masked]>
Date: Tue, 12 Sep 2017 09:55:16 -0700

We need to move on these issues. My read from the thread is the majority of
the objections to removing the text specifically stating 256bit minimum
mask support, was primarily around stalling the publishing process. The
others I can sum up as being concerns for ensuring interoperability.

Alia has confirmed that the process will only be another two week call in
parallel. We've already burned far more than that discussing it.

Interoperability is a valid concern, as is "architecture should not
overspecify a technology".
So, I propose removing the 256 bit minimum bit length from the arch doc,
and adding text that states a BIER domain/set/area must have a
single mask length, and a single encapsulation.

Please comment on the above.

An Operational section has been approved by Benoit, who opened the discuss,
and it too will be added to the arch draft.

Cheers,
Greg
(Chairs)

On Wed, Aug 9, 2017 at 3:13 PM, Tony Przygienda <[email-masked]> wrote:

>
>
> On Wed, Aug 9, 2017 at 11:36 AM, IJsbrand Wijnands <[email-masked]> wrote:
>
>> Tony,
>>
>> > 1. As a matter of principle yes, one of my usual pony horses,
>> "architecture should not overspecify a technology" and that applies here.
>> the architecture doc would be better served without that clause.
>>
>> Great, lets change it!
>>
>> > 3. Removing the restriction must not, IMO, result in a complete new WG
>> LC and IESG review albeit Greg has to write a new Ops section which will
>> probably make both prudent nevertheless
>>
>> We’ve been working on this architecture for a few years now, and this
>> document is the MAIN architecture for BIER. If we discovered an mistake
>> before its published as RFC, lets fix it now. If WG LC and IESG will add a
>> 4 month delay, who cares?
>>
>>
> OK, I go along with your arguments.
>
> Alia, how much of LC do we have to rerun after the section is removed from
> arch + ops added & section is added to encaps doc?
>
> But do not forget the 2) !
>
> --- tony
>
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier
>
>

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 12 Sep 2017 16:00:57 -0400

Greg> My read from the thread is the majority of the objections to 
removing the text specifically stating 256bit minimum mask support, was 
primarily around stalling the publishing process.

My primary concern is the introduction of last minute changes (after the 
reviews have been done) that might introduce mistakes, might be poorly 
thought out, or might have  unintended side-effects.   After all, no one 
is going to do the sort of review that determines whether a mistake has 
been added or an inconsistency introduced.

Greg> We need to move on these issues.

Generally if one is concerned about moving a document quickly, one 
doesn't propose last minute changes that are not necessary.

Greg> So, I propose removing the 256 bit minimum bit length from the 
arch doc, and adding text that states a BIER domain/set/area must have a 
single mask length, and a single encapsulation.

There is already extensive material (e.g., section 6.10) about handling 
the case where a BIER domain is using more than one BSL. This is 
necessary, at the very least, to handle the scenario where one is 
transitioning from one BSL to another.  This is not material that we can 
just strike out at the last minute.  There would also need to be some 
changes to section 3.

I see no grounds for adding a requirement that a BIER domain support 
only a single encapsulation.

Assuming the WG wants to make a change here (which I think is unwise), I 
would propose the following.

Section 3 has the following two paragraphs:

Every BFIR MUST be capable of being provisioned with an Imposition
   BitStringLength of 256.  Every BFR and BFER MUST be capable of being
   provisioned with a Disposition BitStringLength of 256.

   Particular BIER encapsulation types MAY allow other BitStringLengths
   to be OPTIONALLY supported.  For example, when using either of the
   encapsulations specified in [MPLS_BIER_ENCAPS], a BFR may be capable
   of being provisioned to use any or all of the following
   BitStringLengths as Imposition BitStringLengths and as Disposition
   BitStringLengths: 64, 128, 256, 512, 1024, 2048, and 4096.

We could replace that with the following:

When a BIER encapsulation is specified, the specification MUST define a
  default BitStringLength for the encapsulation.  Every BFIR supporting
  that encapsulation MUST be capable of being provisioned with that default
  BitStringLength as its Imposition BitStringLength.  Every BFR and BFER
  supporting that encapsulation MUST be capable of being provisioned with
  that default BitStringLength as a Disposition BitStringLength.

  The specification of a BIER encapsulation MAY also allow other 
BitStringLengths.

We'd also have to add something near the beginning of section 6.10 ("Use 
of Different BitStringLengths within a Domain") saying that the 
procedures of that section apply only when the same encapsulation is 
used throughout the domain, and that a discussion of the use of 
"multiple encapsulations AND multiple BitStringLengths" in a single 
domain is outside the scope of the document.

Section 6.10.1 defines a "Fallback Disposition BitStringLength" (F) and 
says:

It is RECOMMENDED that the value of F be 256.

We would need to change that to something like:

It is RECOMMENDED that the value of F be the default BitStringLength for 
the encapsulation being used.

But I really think we'd be better served leaving everything as is, given 
that the material is complex and was discussed and agreed upon some time 
ago.  Then if someone proposes an encapsulation that can't handle 256 
bits, the authors of that proposal can be tasked with taking the time to 
figure out just what in the architecture has to change.  If Greg's 
suggestion is really that we reopen the discussion that led to section 
6.10, I would say that is certainly inappropriate at this stage in the 
life cycle of the document.

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 12 Sep 2017 13:20:30 -0700

On Tue, Sep 12, 2017 at 1:00 PM, Eric C Rosen <[email-masked]> wrote:

> thought out, or might have  unintended side-effects.   After all, no one is
> going to do the sort of review that determines whether a mistake has been
> added or an inconsistency introduced.
>

It's a paragraph at most. You underestimate the WG. :)

> Generally if one is concerned about moving a document quickly, one doesn't
> propose last minute changes that are not necessary.
>

Generally, there is more than one concern that drives decisions.

> Greg> So, I propose removing the 256 bit minimum bit length from the arch
> doc, and adding text that states a BIER domain/set/area must have a single
> mask length, and a single encapsulation.
>
> the case where a BIER domain is using more than one BSL. This is necessary,
> at the very least, to handle the scenario where one is transitioning from
> one BSL to another.  This is not material that we can just strike out at
> the last minute.  There would also need to be some changes to section 3.
>

Nobody is proposing striking the entire text of this section. The proposal
is just to remove the restriction of 256bit minimum length.

> I see no grounds for adding a requirement that a BIER domain support only
> a single encapsulation.
>

Neither do I. Thanks for your input.

>  The specification of a BIER encapsulation MAY also allow other

That looks great, thanks.

> of Different BitStringLengths within a Domain") saying that the procedures
> of that section apply only when the same encapsulation is used throughout
> the domain, and that a discussion of the use of "multiple encapsulations
> AND multiple BitStringLengths" in a single domain is outside the scope of
> the document.
>

Also looks great, thanks.

> ago.  Then if someone proposes an encapsulation that can't handle 256 bits,
> the authors of that proposal can be tasked with taking the time to figure
> out just what in the architecture has to change.  If Greg's suggestion is
> really that we reopen the discussion that led to section 6.10, I would say
> that is certainly inappropriate at this stage in the life cycle of the
> document.
>

Your objection is noted, again.

Thanks,
Greg