Subject: [Bier] Draft BIER minutes, IETF 97

From: Tim Chown <[email-masked]>
Date: Mon, 14 Nov 2016 08:16:19 +0000

The draft minutes are on the etherpad:

http://etherpad.tools.ietf.org:9000/p/notes-ietf-97-bier?useMonospaceFont=true

Tim

---

From: "Dolganow, Andrew (Nokia - SG)" <[email-masked]>
Date: Mon, 14 Nov 2016 09:00:54 +0000

An extra point I made to capture in the minutes on relaxing 256-bit in architecture draft:

I mentioned I support that and we should not use that to re-open bitstring length for MPLS enacap - no new info was presented to warrant that.

Andrew

Sent from my iPhone

On Nov 14, 2016, at 5:16 PM, Tim Chown <[email-masked]<mailto:[email-masked]>> wrote:

Tim

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

---

From: Tim Chown <[email-masked]>
Date: Mon, 14 Nov 2016 10:24:03 +0000

You can edit the Etherpad...

--
Tim

On 14 Nov 2016, at 09:01, Dolganow, Andrew (Nokia - SG) <[email-masked]<mailto:[email-masked]>> wrote:

Andrew

Sent from my iPhone

Tim

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 14 Nov 2016 10:47:40 -0800

<as individual>

First, I was astonished to see I talked in my sleep ;-)  Or someone else
impersonated me ;-) Pls correct my name to the person that really stated
those things.

2nd, on a more serious note: v6man needs to look @ minimum two other items
I don't see mentioned

a) checksums, especially UDP, implications
b) security architecture, AFAIS AH and so on falls flat on its face when
addresses change in mid-flight and with that the whole IPSEC. And who would
want an arbitrary address talk to your ingress suggesting you want this
thing replicated as BIER.
c) taking the BML out of architecture draft is goodness. It was over
specifying, I agree ...

Rest looks good. I suggested to Ice as well to add to the MPLS/Ether encaps
draft that "you can use the BIFT-IDs and MPLS labels in the same deployment
if you don't want/need new ether encaps type but it's up to you to make
sure the spaces do not overlap"

I do agree with Ice (after some conversations with HW vendors) that pushing
the fields before bit mask is good. Imagine what will happen to your
pipeline processing when the masks become really long in the future
possibly ... Now is the time to make this change.

--- tony

On Mon, Nov 14, 2016 at 12:16 AM, Tim Chown <[email-masked]> wrote:

> [email-masked]

-- 
*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: Tim Chown <[email-masked]>
Date: Mon, 14 Nov 2016 21:30:31 +0000

Hi Tony,

On 14 Nov 2016, at 18:47, Tony Przygienda <[email-masked]<mailto:[email-masked]>> wrote:

<as individual>

First, I was astonished to see I talked in my sleep ;-)  Or someone else impersonated me ;-) Pls correct my name to the person that really stated those things.

Apologies, the person sat in the co-chair seat next to Greg said those things, so I assumed it was you given they didn’t state their name. I think I now know who it was, but rather than get it wrong again I’ve replaced the two instances of your name with XXXX for someone who definitely knows to fill in :)

Just edit it at http://etherpad.tools.ietf.org:9000/p/notes-ietf-97-bier?useMonospaceFont=true.

Best wishes,
Tim

2nd, on a more serious note: v6man needs to look @ minimum two other items I don't see mentioned

a) checksums, especially UDP, implications
b) security architecture, AFAIS AH and so on falls flat on its face when addresses change in mid-flight and with that the whole IPSEC. And who would want an arbitrary address talk to your ingress suggesting you want this thing replicated as BIER.
c) taking the BML out of architecture draft is goodness. It was over specifying, I agree ...

Rest looks good. I suggested to Ice as well to add to the MPLS/Ether encaps draft that "you can use the BIFT-IDs and MPLS labels in the same deployment if you don't want/need new ether encaps type but it's up to you to make sure the spaces do not overlap"

I do agree with Ice (after some conversations with HW vendors) that pushing the fields before bit mask is good. Imagine what will happen to your pipeline processing when the masks become really long in the future possibly ... Now is the time to make this change.

--- tony

On Mon, Nov 14, 2016 at 12:16 AM, Tim Chown <[email-masked]<mailto:[email-masked]>> wrote:
The draft minutes are on the etherpad:

Tim

--
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: "Dolganow, Andrew (Nokia - SG)" <[email-masked]>
Date: Tue, 15 Nov 2016 23:05:16 +0000

To the group and a follow up on the discussion on the BIER header change after some further discussion with Ice.

Keeping the Generic format identical is highly desirable. This can be achieved by making a new non-MPLS header follow the “legacy” MPLS BIER header format (4 octets of the header after the BitString) or modify the header as presented by Ice. Since there seemed to be some agreement already on modifying the header (BitString last, 4 octets that, among others, contain OAM bit BFR-ID, DSCP (if applicable) going that way make sense.

Andrew

On 2016-11-14, 7:24 PM, "Tim Chown" wrote:

--
Tim

Andrew

Sent from my iPhone

Tim

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 16 Nov 2016 02:05:01 +0000

Hi all,

In fact, (https://tools.ietf.org/html/draft-xu-bier-encapsulation-06) had already done these things well. See the following generic BIER format:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Ver  |  BSL  | Resv  |                Entropy                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           BFIR-ID             |       DS      |    Protocol   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         SI        |     Sub-domain    |O| Resv|      TTL      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                BitString  (first 32 bits)                     ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                                                               ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                BitString  (last 32 bits)                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Figure 1: BIER Header Format.

More specifically, 1) the BS field is the last one within the BIER header; 2) the DS field is one byte long vs the 3-bit TOS within the MPLS label entry; 3) SI and Sub-domain could either be encoded directly or implicitly encoded (i.e., through the 20-bit opaque keys which could be looked as MPLS labels if you like ^_^) . 

In addition, the generic bier encapsulation has the following advantages over the to-be-changed MPLS-BIER encapsulation: 1) there is no need to use different Ethertype codes for the direction approach where SI and Sub-domain are explicitly encoded in the packet and the indirection approach where the SI and Sub-domain are not explicitly encoded in the packet respectively. Note that it said in ice's slides that " To prevent MPLS and the BIFT ID from overlapping, we’re leaning towards a new Ethertype for Ethernet encapsulation." 2) The opaque keys are not required to be global. Note that it said in ice's slides that " In the non-MPLS encoding the BIFT ID can be seen as a MPLS global label, and can potentially implemented as such using existing MPLS forwarding logic. This however does not solve the well known problems with global labels (like platform support etc..)". 3) in the generic bier encapsulation, the SI and Sub-domain can be hard encoded in the packet. Although it's said in ice's slides that " The BIFT ID could be carved up by the control plane to encode {BitString Len, Sub-Domain, SetID} explicitly"  It's hard for me to understand how to encode 22-bit information within a 20-bit field:).

Best regards,
Xiaohu

发件人: BIER [[email-masked]] 代表 Dolganow, Andrew (Nokia - SG) [[email-masked]]
发送时间: 2016年11月16日 7:05
收件人: [email-masked]
抄送: Tim Chown
主题: Re: [Bier] Draft BIER minutes, IETF 97

Andrew

-- 
Tim

On 14 Nov 2016, at 09:01, Dolganow, Andrew (Nokia - SG) <[email-masked]> wrote:

Andrew 

Sent from my iPhone

On Nov 14, 2016, at 5:16 PM, Tim Chown <[email-masked]> wrote:

Tim