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

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 8 Aug 2017 17:27:32 +0200

Hi Folks,

Pierre brought to my attention that the length of the BitString in the BIER header (as documented in draft-ietf-bier-architecture-07) is a property of the type of encapsulation, not necessarily the architecture. I agree with that POV. The architecture should be flexible and not restrict alternative BitString lengths that we may want to come up with in the future.

I’m very happy with the encodings as how we defined them for MPLS and non-MPLS encodings in draft-ietf-bier-mpls-encapsulation-07, I don’t want to change this.

What I would suggest is to move text below from the architecture to the encapsulation draft:

"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.”

Comments?

Thx,

Ice.

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 8 Aug 2017 12:00:17 -0700

That would apply to both MPLS and ether encaps. Correct?

--- tony

On Tue, Aug 8, 2017 at 8:27 AM, IJsbrand Wijnands <[email-masked]> wrote:

> Hi Folks,
>
> Pierre brought to my attention that the length of the BitString in the
> BIER header (as documented in draft-ietf-bier-architecture-07) is a
> property of the type of encapsulation, not necessarily the architecture. I
> agree with that POV. The architecture should be flexible and not restrict
> alternative BitString lengths that we may want to come up with in the
> future.
>
> I’m very happy with the encodings as how we defined them for MPLS and
> non-MPLS encodings in draft-ietf-bier-mpls-encapsulation-07, I don’t want
> to change this.
>
> _______________________________________________
> BIER mailing list
> [email-masked]
> 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

---

From: "IJsbrand Wijnands (iwijnand)" <[email-masked]>
Date: Tue, 8 Aug 2017 19:34:53 +0000

Correct! So nothing really changes for MPLS and ether encaps.

Sent from my iPhone

On 8 Aug 2017, at 21:01, Tony Przygienda <[email-masked]<mailto:[email-masked]>> wrote:

--- tony

On Tue, Aug 8, 2017 at 8:27 AM, IJsbrand Wijnands <[email-masked]<mailto:[email-masked]>> wrote:
Hi Folks,

I'm very happy with the encodings as how we defined them for MPLS and non-MPLS encodings in draft-ietf-bier-mpls-encapsulation-07, I don't want to change this.

"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."

Comments?

Thx,

Ice.

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
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

---

From: Alia Atlas <[email-masked]>
Date: Tue, 8 Aug 2017 16:00:44 -0400

Ice,

It's rather a bit late for this - unless it is a truly critical change.
The draft has completed WGLC and IETF LC and gone through
the IESG where it has just one main issue to handle.

I would like to understand whether there is WG consensus to
bring the draft back to the WG to deal with this.  Yes, it could
be a fairly fast process - with the repeated WGLC and IETF LC at the
same time - and then back to the IESG.

Regards,
Alia

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 8 Aug 2017 13:18:57 -0700

I believe specifying encap requirements in the arch draft was miss-placed.
But it didn't seem so until we had an encapsulation proposal that could not
support the arch specified req of 256bits.

I believe it is worth the rev, re-LC. I'll send out an email solicitation
to the list.

Greg

On Tue, Aug 8, 2017 at 1:00 PM, Alia Atlas <[email-masked]> wrote:

>> non-MPLS encodings in draft-ietf-bier-mpls-encapsulation-07, I don’t
>> want to change this.
>>

---

From: Alia Atlas <[email-masked]>
Date: Tue, 8 Aug 2017 16:21:12 -0400

> I believe it is worth the rev, re-LC. I'll send out an email solicitation

I can see how it is problematic for some of the proposals around an IPv6
encapsulation.
On the other hand, it is also making a statement about what a reasonable
trade-off is for
size of multicast traffic receivers.

Let's see what the WG thinks.

Regards,
Alia

Greg

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 8 Aug 2017 17:44:11 -0400

Given that the architecture is almost through IESG review, I think we 
should leave it as is.

If some encapsulation is proposed that cannot handle a minimum bitstring 
length of 256, the specification of that encapsulation can always update 
the architecture.

On 8/8/2017 4:00 PM, Alia Atlas wrote:
> On Tue, Aug 8, 2017 at 11:27 AM, IJsbrand Wijnands <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Folks,
>
>     Pierre brought to my attention that the length of the BitString in
>     the BIER header (as documented in draft-ietf-bier-architecture-07)
>     is a property of the type of encapsulation, not necessarily the
>     architecture. I agree with that POV. The architecture should be
>     flexible and not restrict alternative BitString lengths that we
>     may want to come up with in the future.
>
>     I’m very happy with the encodings as how we defined them for MPLS
>     and non-MPLS encodings in draft-ietf-bier-mpls-encapsulation-07, I
>     don’t want to change this.
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/bier>
>
>
>
>

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 8 Aug 2017 15:01:39 -0700

Inline:

> Given that the architecture is almost through IESG review, I think we
As Alia pointed out, it's not a big deal to correct it now. We can do WG
and IETF LC in parallel. The arch doc needs additional text under
operations anyway.

> length of 256, the specification of that encapsulation can always update
I'd rather not kick this down the road.

Greg

> BIER mailing [email-masked]://www.ietf.org/mailman/listinfo/bier
>
>
>

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Tue, 8 Aug 2017 23:05:50 +0000

I agree with Eric. We should just leave this as is and deal with a change when a change is proposed by other encapsulation.

Andrew

Sent from my iPhone

On Aug 8, 2017, at 5:44 PM, Eric C Rosen <[email-masked]<mailto:[email-masked]>> wrote:

Given that the architecture is almost through IESG review, I think we should leave it as is.

If some encapsulation is proposed that cannot handle a minimum bitstring length of 256, the specification of that encapsulation can always update the architecture.

Regards,
Alia

On Tue, Aug 8, 2017 at 11:27 AM, IJsbrand Wijnands <[email-masked]<mailto:[email-masked]>> wrote:
Hi Folks,

Comments?

Thx,

Ice.

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 9 Aug 2017 01:32:13 +0000

+1.

My 2 cents, the architecture draft should point of the minimum useful bitStringLenght, any exception to this can be noted in the encapsulation drafts.

Regards

Hooman

From: BIER [mailto:[email-masked]] On Behalf Of Dolganow, Andrew (Nokia - SG/Singapore)
Sent: Tuesday, August 08, 2017 7:06 PM
To: Eric C Rosen <[email-masked]>
Cc: Pierre Pfister <[email-masked]>; BIER ([email-masked]) <[email-masked]>; IJsbrand Wijnands <[email-masked]>
Subject: Re: [Bier] BitStringLengths in draft-ietf-bier-architecture-07

Andrew

Sent from my iPhone

Regards,
Alia

Comments?

Thx,

Ice.

BIER mailing list

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 9 Aug 2017 08:42:50 +0200

Although it is true that any further document could update the architecture RFC if necessary, from my (short) past experience that's not what I have seen happen. Architecture documents tend to take holy proportions, where every line and every word becomes subject to interpretation as if written by some all wise men.

A different encap with a shorter bitstring length would work.
The IPv6 encap was one proposed idea, but I can imagine the IoT world will benefit from some efficient and simple multicast technology too. 
On links that can only fit a few bytes of payload, I don't see how a 256bits minimum would be practical.

I think that text has to be either removed, or modified.

- Pierre

> Le 8 août 2017 à 23:44, Eric C Rosen <[email-masked]> a écrit :
> 
>> On Tue, Aug 8, 2017 at 11:27 AM, IJsbrand Wijnands <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi Folks,
>> 
>> https://www.ietf.org/mailman/listinfo/bier <https://www.ietf.org/mailman/listinfo/bier>
>> 
>> 
>> 
>> https://www.ietf.org/mailman/listinfo/bier <https://www.ietf.org/mailman/listinfo/bier>
>

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 9 Aug 2017 11:24:46 +0200

Hooman,

> My 2 cents, the architecture draft should point of the minimum useful bitStringLenght, any exception to this can be noted in the encapsulation drafts.

Which length is useful totally depends on the use-case. Take uncompressed video, having a BitString of 16 would already be useful!

I feel like I’m proxying for Tony P. ;), but the architecture document should not put unnecessary restrictions on future deployments and use-cases.

BTW, the main reason to mandate the MUST support for a BitStringLength of 256 is interoperability, not because we determined this was the minimum useful length.

Thx,

Ice.

> On Aug 8, 2017, at 5:44 PM, Eric C Rosen <[email-masked]> wrote:
>

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 9 Aug 2017 09:20:05 -0700

On Wed, Aug 9, 2017 at 2:24 AM, IJsbrand Wijnands <[email-masked]> wrote:

> Hooman,
>
> My 2 cents, the architecture draft should point of the minimum useful
> bitStringLenght, any exception to this can be noted in the
> encapsulation drafts.
>
>
> Which length is useful totally depends on the use-case. Take uncompressed
> video, having a BitString of 16 would already be useful!
>
> I feel like I’m proxying for Tony P. ;), but the architecture document
> should not put unnecessary restrictions on future deployments and use-cases.
>

I was sitting on the sidelines thinking about it but you forced my hand so
beautifully here ;-)  (and it's nice to see you mastering Captatio
benevolentiae <https://en.wikipedia.org/wiki/Captatio_benevolentiae> ;-) ;-)

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.

Having said that ;-)  [observe the Dissoi logoi
<https://en.wikipedia.org/wiki/Dissoi_logoi> turn ;-) ;-)

2. People who think this is the license to use DIFFSERV bits to run BIER
(or any other layering/architectural violation where a couple of "spare
bits" can be found) do have to consider that layering (or architectural
violations in other realms under such license) exhibit a terrible price
over time in terms of sustainability of IP technology in longer term.
Architectural violations are easy to argue for as "efficiencies" but those
efficiencies exhort mostly a very high technical debt couple years down the
road.
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
4. Adding the section to MPSL/Ether encaps is prudent to ensure
interoperability of the technology. Given the section passed the
architectural review I think it's unnecessary to LC MPLS/Ether encaps again
but the 2 weeks make no difference (being a wise man I am I still
procastrinated on my shepherd write-down).

QED ;-)

>
> BTW, the main reason to mandate the MUST support for a BitStringLength of
> 256 is interoperability, not because we determined this was the minimum
> useful length.
>
>
Yes

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 9 Aug 2017 20:23:31 +0200

I tried to browse through the 82 occurances of "encapsulat" in
the arch spec and i could not find a statement that a domain or
subdomain MUST use a single encapsulation. There is mentioning
of future different encapsulation options. 

Aka: I don't think its an architectural improvement to move the
bistring length definition out of the arch into an encap without
discussing this issue in the arch. Something like: 

- Different encapsulations in a single domain/subdomain are VERBOTEN
- Go figure out yourself how to make multiple encaps work
  in a single domain, consider bitstring length compatibility for
  example. We don't know yet. Good luck!
- Different encapsulations in a subdomain are permitted, and
  bitstring length interoperability is always possible because
  the architecture specifies 256 as mandatory.

Afaik, just quick browse. There may be a sentence covering this problem
already in the arch that i missed.

If in doubt, and there can be no WG satisfactory text for this, i 
think Erics suggestion to solve the issue later is fine too. The
Update process is really no pain at all and can be used whenever
a new encap is to be standardized. Especially because i am also
sure that the proposed change would not make upgrades of asics to
future encaps easier.

And to comply with TPs style.
The BIER arch certainly matches the following principles as it is:

  https://en.wikipedia.org/wiki/Principle_of_good_enough
  https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
  https://en.wikipedia.org/wiki/Bert_Lance#.22If_it_ain.27t_broke.2C_don.27t_fix_it..22
  https://en.wikipedia.org/wiki/Minimum_viable_product

Cheers
    Toerless

On Wed, Aug 09, 2017 at 09:20:05AM -0700, Tony Przygienda wrote:
> > I feel like I???m proxying for Tony P. ;), but the architecture document

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 9 Aug 2017 20:36:34 +0200

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?

BTW, I loved you’re references :-)

Thx,

Ice.

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 9 Aug 2017 15:13:45 -0700

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
> 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