Subject: [Bier] Rev, and re-LC draft-ietf-bier-architecture?

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

All,

It has come to our attention that the architecture draft specifies a
minimum mask length, which in hind-sight is out of scope for an arch draft
and should be part of encapsulation drafts.

draft-ietf-bier-architecture has already progressed through WGLC and
IETF-LC, so a rev now would restart that cycle. We can do them both in
parallel which would only add another two weeks to the publication schedule.

We need to hear from the WG members on which direction to take. Do we move
ahead as is and arbitrarily prevent new encaps w/ tighter limits from being
proposed, or do we rev and resub LC to fix this issue?

Please see the proposed text below in the attached thread.

Thanks
Greg
(Chairs)

---------- Forwarded message ----------
From: IJsbrand Wijnands <[email-masked]>
Date: Tue, Aug 8, 2017 at 8:27 AM
Subject: [Bier] BitStringLengths in draft-ietf-bier-architecture-07
To: "BIER ([email-masked])" <[email-masked]>
Cc: Pierre Pfister <[email-masked]>

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.

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

---

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

Let's not do this change and proceed to issue the drafts that are almost through the process.

We can do with the below change when handling an encapsulation that has the issue. 256 is not that big for multicast (and many argued in the past about bringing this down to 128).  Let's discuss separately how useful an encapsulation that cannot handle 256 is and whether it warrants architecture change. If it does, we can augment the architecture as required at that time.

Andrew

Sent from my iPhone

On Aug 8, 2017, at 4:23 PM, Greg Shepherd <[email-masked]<mailto:[email-masked]>> wrote:

All,

It has come to our attention that the architecture draft specifies a minimum mask length, which in hind-sight is out of scope for an arch draft and should be part of encapsulation drafts.

draft-ietf-bier-architecture has already progressed through WGLC and IETF-LC, so a rev now would restart that cycle. We can do them both in parallel which would only add another two weeks to the publication schedule.

We need to hear from the WG members on which direction to take. Do we move ahead as is and arbitrarily prevent new encaps w/ tighter limits from being proposed, or do we rev and resub LC to fix this issue?

Thanks
Greg
(Chairs)

---------- Forwarded message ----------
From: IJsbrand Wijnands <[email-masked]<mailto:[email-masked]>>
Date: Tue, Aug 8, 2017 at 8:27 AM
Subject: [Bier] BitStringLengths in draft-ietf-bier-architecture-07
To: "BIER ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>
Cc: Pierre Pfister <[email-masked]<mailto:[email-masked]>>

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:

Comments?

Thx,

Ice.

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier

---

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

On Tue, Aug 8, 2017 at 4:12 PM, Dolganow, Andrew (Nokia - SG/Singapore) <
[email-masked]> wrote:

> Let's not do this change and proceed to issue the drafts that are almost
> through the process.=
>

Acknowledged.

> We can do with the below change when handling an encapsulation that has
> the issue. 256 is not that big for multicast (and many argued in the past
> about bringing this down to 128).  Let's discuss separately how useful an
> encapsulation that cannot handle 256 is and whether it warrants
> architecture change.
>

But that's my point. The mask limit shouldn't be part of the architecture
in the first place. Mask size should be in encap drafts only.

Greg

> If it does, we can augment the architecture as required at that time.
>
> Andrew
>
> Sent from my iPhone
>
> On Aug 8, 2017, at 4:23 PM, Greg Shepherd <[email-masked]> wrote:
>
> All,
>
> 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.
>