Subject: Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 1 Mar 2021 17:09:40 +0000

Hi,

As one of the most active members during the last round discussions, here are my summary of that round:

1.           BIERin6 is to apply the existing generic solution to IPv6 networks, with a clean layered architecture. All that is needed are code points for outer header to indicate the payload is BIER. In case of IPv6 tunneling (single hop or multi-hop), that's a code point for IP "next header".
2.           It does satisfy all requirements listed in the requirements draft, including supporting SRv6 based services.
3.           With the above considerations, it is ready for WG adoption on standards track, and should not be tied with other solutions (which may progress on their own paces).

Jeffrey

From: BIER <[email-masked]> On Behalf Of Adrian Farrel
Sent: Friday, February 26, 2021 7:20 AM
To: 'BIER WG' <[email-masked]>
Subject: Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6

[External Email. Be cautious of content]

Since Mike invoked me, I'll make my adoption comments in response to his mail.

Looking back at the list, I saw a couple of +1s to my suggestion, and a mumble from an author of draft-zhang-bier-bierin6 about Experimental not being fair.

I'm surprised to see this adoption poll without first resolving the debate about precedence of I-Ds and not even an announcement from the chairs about a plan for how the two I-Ds will be progressed. Adoption, IMHO, is not about whether a draft is technically ready, but about how the WG wants to address a topic. I don't think we have resolved that question, and so I think an adoption poll on one draft only appears to be prejudging that debate.

So I would like us to suspend this adoption poll and sort ourselves out first.

Thanks,
Adrian

From: BIER <[email-masked]<mailto:[email-masked]>> On Behalf Of Michael McBride
Sent: 26 February 2021 06:15
To: [email-masked]<mailto:[email-masked]>; BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Oppose.

We are unfortunately no where near consensus on this topic including this draft. We'll likely see that during this adoption call.

Adrian's suggestion for consensus remains the best I've heard: simultaneously call to adopt both solutions as experimental.

mike

From: BIER <[email-masked]<mailto:[email-masked]>> On Behalf Of Greg Shepherd
Sent: Thursday, February 25, 2021 8:37 AM
To: BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Thank you all for the active discussion that brought us to consensus. This draft now addresses all of the points of discussion for the solution.

https://datatracker.ietf.org/doc/draft-zhang-bier-bierin6/<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-zhang-bier-bierin6*2F&data=04*7C01*7Cmichael.mcbride*40futurewei.com*7C7aecd20ae06a4b6a300a08d8d9aba70d*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637498678569221968*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=IV22zVnPbym*2FJTZljh*2FLGNUqxFp4zZKJWcHBTx9a*2BPY*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!WeDec9lGpXytkNpw_WwJqpx4vYi-yYQIN7cs9yaiwfhbiousyC9FLrZDn8rrhQCn$>

Please reply to this thread with your support/opposition of WG adoption of the draft.

Thanks,
Shep
(Chairs)

Juniper Business Use Only

---

From: duanfanghong <[email-masked]>
Date: Tue, 2 Mar 2021 01:23:15 +0000

Hi,

I see this document proposes 2 options for MVPN/EVPN.
One is using the destination address to carry the ID of an MVPN/EVPN, but this means that every BFR have to be aware of the MVPN/EVPN instance, introducing state of MVPN/EVPN service and forwarding overhead in transit BFR nodes.
The other is to use an IPv6 address after a BIER header and before the customer IP packet, however it proposes a new Proto value and new process in forwarding plane.
I think both of the options have obvious defects, and thus I do not support the adoption.

Thanks !
Fanghong Duan

From: BIER [mailto:[email-masked]] On Behalf Of Greg Shepherd
Sent: Friday, February 26, 2021 12:37 AM
To: BIER WG <[email-masked]>
Subject: [Bier] Call For Adoption: draft-zhang-bier-bierin6

https://datatracker.ietf.org/doc/draft-zhang-bier-bierin6/

Thanks,
Shep
(Chairs)

---

From: "zhangzhe (M)" <[email-masked]>
Date: Tue, 2 Mar 2021 01:36:54 +0000

I agree with mike and oppose the adoption of this draft.

For example, this document proposes 2 options for the fragmentation in BIERin6 in section 2.
One is using an IPv6 header before BIER header, but this will enforce every BFR to assembly and re-fragment a packet.
The other is to use a Fragment header after BIER header to avoid intermediate BFR to do the assembly and re-fragment,
however I don't think it is a mature and accepted solution to support this draft to be adopted.

Thank you.
Zhe Zhang

From: BIER [mailto:[email-masked]] On Behalf Of Michael McBride
Sent: Friday, February 26, 2021 2:15 PM
To: [email-masked]; BIER WG <[email-masked]>
Subject: Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Oppose.

mike

https://datatracker.ietf.org/doc/draft-zhang-bier-bierin6/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-zhang-bier-bierin6%2F&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C7aecd20ae06a4b6a300a08d8d9aba70d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637498678569221968%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IV22zVnPbym%2FJTZljh%2FLGNUqxFp4zZKJWcHBTx9a%2BPY%3D&reserved=0>

Thanks,
Shep
(Chairs)

---

From: <[email-masked]>
Date: Tue, 2 Mar 2021 09:49:35 +0800 (CST)

Hi Fanghong, 

You misunderstand the update of BIERin6, please find my comments with Sandy> below.

Thanks,

Sandy

原始邮件

发件人：duanfanghong
收件人：[email-masked];BIER WG;
日 期 ：2021年03月02日 09:23
主 题 ：Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6

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

Hi,

Sandy> No. BFR needs not to know MVPN/EVPN instance. Only BFIR and BFER need to know it. 

Sandy> As I said, only BFIR and BFER need to process the new proto value, it doesn't make affection on the intermediate forwarding plane.

Thanks !

Fanghong Duan

 

 

 

 

 

Thanks,

Shep

(Chairs)

---

From: <[email-masked]>
Date: Tue, 2 Mar 2021 10:18:10 +0800 (CST)

Hi Zhe, 

Just response to your comments about fragmentation. 

If you read the BIERin6 draft more carefully, you may find that the fragmentation description is in section 1.2 and not in section 2. 

The first option is treat the IPv6 fragmentation packet as BIER payload, the BFR needs not to do the assembling work. 

Only BFIR and BFER needs to do the fragmentation and assembling work. This function is mature and practicable. 

The second option provides a novel way for fragmentation, not only for BIER. 

The working group draft takes time to be mature, the GTF function as well. 

Thanks,

Sandy

原始邮件

发件人：zhangzhe(M)
收件人：Michael McBride;[email-masked];BIER WG;
日 期 ：2021年03月02日 09:37
主 题 ：Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6

 

however I don’t think it is a mature and accepted solution to support this draft to be adopted.

Thank you.

Zhe Zhang

 

Oppose.

We are unfortunately no where near consensus on this topic including this draft. We’ll likely see that during this adoption call.

Adrian’s suggestion for consensus remains the best I’ve heard: simultaneously call to adopt both solutions as experimental.

mike

From: BIER <[email-masked]> On Behalf Of Greg Shepherd
 Sent: Thursday, February 25, 2021 8:37 AM
 To: BIER WG <[email-masked]>
 Subject: [Bier] Call For Adoption: draft-zhang-bier-bierin6

 

 

 

Thanks,

Shep

(Chairs)

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 2 Mar 2021 02:31:32 +0000

Hi Fanghong,

Please see zzh> below.

From: BIER <[email-masked]> On Behalf Of duanfanghong
Sent: Monday, March 1, 2021 8:23 PM
To: [email-masked]; BIER WG <[email-masked]>
Subject: Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi,

Zzh> This is not true. In this option, IPv6 is payload and is only exposed at the BFER. We have talked this in the last round of discussion.

Zzh> BIERv6, with its companion MVPN/EVPN solution, also requires new process in forwarding plane.

I think both of the options have obvious defects,

Zzh> Please see above.
Zzh> Thanks.
Zzh> Jeffrey

and thus I do not support the adoption.

Thanks !
Fanghong Duan

https://datatracker.ietf.org/doc/draft-zhang-bier-bierin6/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-zhang-bier-bierin6/__;!!NEt6yMaO-gk!Wz3exwJN85TEXwRgTI9gEwvjszwONVImICqBRh9GKk0mHtpLuzDK9Nf4DnO7hYbt$>

Thanks,
Shep
(Chairs)

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 2 Mar 2021 02:49:22 +0000

Hi Zhe,

Unfortunately, you (and Fanghong in the other email) are objecting w/o first understanding the solution.
Please see zzh> below.

From: BIER <[email-masked]> On Behalf Of zhangzhe (M)
Sent: Monday, March 1, 2021 8:37 PM
To: Michael McBride <[email-masked]>; [email-masked]; BIER WG <[email-masked]>
Subject: Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Zzh> This is incorrect. IPv6 header is not required before the BIER header.
Zzh> Once the IPv6 based fragmentation is done by the BFIR, each fragment is treated as independent BIER payload, and only gets reassembled by the BFERs.

Zzh> This is just another option of supporting fragmentation. It is similar to IPv6 based fragmentation but made generic (that can be applied to BIER/MPLS or even Ethernet if it is desired). It avoids a large IPv6 header. If people don't think it's mature enough, IPv6 based fragmentation can be used.
Zzh> Also keep in mind that fragmentation is just an optional requirement.
Zzh>
Zzh> Thanks.
Zzh> Jeffrey

Thank you.
Zhe Zhang

Oppose.

mike

https://datatracker.ietf.org/doc/draft-zhang-bier-bierin6/<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-zhang-bier-bierin6*2F&data=04*7C01*7Cmichael.mcbride*40futurewei.com*7C7aecd20ae06a4b6a300a08d8d9aba70d*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637498678569221968*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=IV22zVnPbym*2FJTZljh*2FLGNUqxFp4zZKJWcHBTx9a*2BPY*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!VKB3yHu_QZ4fBfMiI4-3Zo-ypqKyMPWun_fQPiGpd7rlsAQxIqHX-chKmgUuIy2u$>

Thanks,
Shep
(Chairs)

---

From: duanfanghong <[email-masked]>
Date: Tue, 2 Mar 2021 11:45:44 +0000

Hi Jeffrey and Sandy,

o In option 1, do you mean that, an entire IPv6 header is added between BIER header and the customer multicast packet with a BIER Proto value 6 used?

  Consider non-BFR case like this:
  A(bfr) ---- B(nonbfr) ---- C(nonbfr) ---- D(nonbfr) ---- E(bfr)
  You need an IPv6 Header + BIER Header + IPv6 Header + customer multicast packet encapsulation ?

  Here are some further questions about the inner IPv6 header : 1) what does "multicast locator"  mean? 2) what is the source address of the inner IPv6 address?

o In option 2, do you mean that, an IPv6 address is added between the BIER header and the customer multicast packet with a BIER Proto value TBD used?

  So an IPv6 address is floating in a place outside of any IPv6 header? I don't think it's reasonable.

Thank you

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Tuesday, March 2, 2021 10:32 AM
To: duanfanghong <[email-masked]>; [email-masked]; BIER WG <[email-masked]>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Fanghong,

Please see zzh> below.

From: BIER <[email-masked]<mailto:[email-masked]>> On Behalf Of duanfanghong
Sent: Monday, March 1, 2021 8:23 PM
To: [email-masked]<mailto:[email-masked]>; BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi,

Zzh> Please see above.
Zzh> Thanks.
Zzh> Jeffrey

Thanks !
Fanghong Duan

Thanks,
Shep
(Chairs)

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 3 Mar 2021 01:20:01 +0000

Hi Fanghong,

Please see zzh2> below.

From: duanfanghong <[email-masked]>
Sent: Tuesday, March 2, 2021 6:46 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]; BIER WG <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Jeffrey and Sandy,

Zzh2> This was discussed in the last round.
Zzh2> If both IPv6 based fragmentation and tunneling are needed, then indeed two IPv6 headers are used in the cleanly layered architecture.
Zzh2> I pointed out that when IPv6 is used for everything everywhere, then you don’t get to complain about the additional overhead. For comparison, with BIERv6, you’re using the IPv6 header even between directly connected neighbors where a simple l2 header is enough; with BIERv6, if FRR is used in the network, my understanding is you’ll also have two IPv6 headers – one pushed by the BFIR and the other pushed by the PLR.
Zzh2> If one really cares about reducing the overhead, then doing fragmentation/ESP without requiring IPv6 but in a layer independent way is a better solution and that still achieves clean layering.

Zzh2> A multicast locator is similar to unicast locator but the difference is that multiple nodes can receive traffic addressed to that <locator + func/arg>.
Zzh2> The inner address is the BFIR’s address, since it is the node that imposes that inner IPv6 header.

Zzh2> Yes.

Zzh2> Why not? We only need the IPv6 address for service delimiting and don’t need anything else provided by a full IPv6 header. In fact, only the func/arg part is needed so a 32-bit value is practically enough; though for theoretical flexibility provided by variable length of func/arg bits, the entire IPv6 address is used.
Zzh2> Jeffrey

Thank you

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Tuesday, March 2, 2021 10:32 AM
To: duanfanghong <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Fanghong,

Please see zzh> below.

Hi,

Zzh> Please see above.
Zzh> Thanks.
Zzh> Jeffrey

Thanks !
Fanghong Duan

Thanks,
Shep
(Chairs)

---

From: duanfanghong <[email-masked]>
Date: Wed, 3 Mar 2021 13:44:37 +0000

Hi Jeffrey

Overhead of encapsulation is a concern but we can talk about it later. Please see my comments  with ‘Dfh>’ below.

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Wednesday, March 3, 2021 9:20 AM
To: duanfanghong <[email-masked]>; [email-masked]; BIER WG <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Fanghong,

Please see zzh2> below.

From: duanfanghong <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, March 2, 2021 6:46 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; BIER WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Jeffrey and Sandy,

Zzh2> A multicast locator is similar to unicast locator but the difference is that multiple nodes can receive traffic addressed to that <locator + func/arg>.
Dfh> Still don’t understand “similar to unicast locator”, and “multiple nodes can receive traffic addressed to that <locator + func/arg>”.
Is it something like “Replication SID” in <draft-ietf-pim-sr-p2mp-policy>?
Or can you please give an example of a multicast locator showing the locator and func/arg part?

Zzh2> Yes.

Zzh2> Why not? We only need the IPv6 address for service delimiting and don’t need anything else provided by a full IPv6 header. In fact, only the func/arg part is needed so a 32-bit value is practically enough; though for theoretical flexibility provided by variable length of func/arg bits, the entire IPv6 address is used.
Dfh> So I understand the “IPv6 address” is used outside of any IPv6 header, making “IPv6 address” like an MPLS Label.
Could more IPv6 addresses be directed stacked just like MPLS Label stack ?

Zzh2> Jeffrey

Thank you

Hi Fanghong,

Please see zzh> below.

Hi,

Zzh> Please see above.
Zzh> Thanks.
Zzh> Jeffrey

Thanks !
Fanghong Duan

Thanks,
Shep
(Chairs)

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 3 Mar 2021 19:53:33 +0000

Hi Fanghong,

Please see zzh3> below.

From: duanfanghong <[email-masked]>
Sent: Wednesday, March 3, 2021 8:45 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]; BIER WG <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Jeffrey

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Wednesday, March 3, 2021 9:20 AM
To: duanfanghong <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; BIER WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Fanghong,

Please see zzh2> below.

Hi Jeffrey and Sandy,

Zz3> It’s different from the “replication sid”. Per RFC 8986:

   This document defines an SRv6 SID as consisting of LOC:FUNCT:ARG,
   where a locator (LOC) is encoded in the L most significant bits of
   the SID, followed by F bits of function (FUNCT) and A bits of
   arguments (ARG).  L, the locator length, is flexible, and an operator
   is free to use the locator length of their choice.  F and A may be
   any value as long as L+F+A <= 128.  When L+F+A is less than 128, then
   the remaining bits of the SID MUST be zero.

Zzh3> If the LOC part is from the multicast address space (https://tools.ietf.org/html/rfc4291#section-2.7), then it is a “multicast locator”, and the FUNCT:ARG part can be used for service delimiting, just like how unicast is done for VPNs. Obviously, we don’t need to setup multicast trees for those addresses on the transit nodes (because BIER is doing the distribution), but the BFERs have corresponding FIB entries with END.DT4/6/2M forwarding behaviors.

Zzh2> Yes.

Zzh2> Why not? We only need the IPv6 address for service delimiting and don’t need anything else provided by a full IPv6 header. In fact, only the func/arg part is needed so a 32-bit value is practically enough; though for theoretical flexibility provided by variable length of func/arg bits, the entire IPv6 address is used.
Dfh> So I understand the “IPv6 address” is used outside of any IPv6 header, making “IPv6 address” like an MPLS Label.
Could more IPv6 addresses be directed stacked just like MPLS Label stack ?
Zzh3> I don’t see that it needs to stacked and there is no plan to do so. For example, for EVPN BUM with MPLS forwarding plane, a label stack (of two) are used to identify the bridge domain and source Ethernet Segment together, but with SRv6, they are identified with FUNC+ARG in a single SID.
Zzh3> Thanks.
Zzh3> Jeffrey

Zzh2> Jeffrey

Thank you

Hi Fanghong,

Please see zzh> below.

Hi,

Zzh> Please see above.
Zzh> Thanks.
Zzh> Jeffrey

Thanks !
Fanghong Duan

Thanks,
Shep
(Chairs)

---

From: "zhangzhe (M)" <[email-masked]>
Date: Thu, 4 Mar 2021 02:40:23 +0000

Hi Jeffrey,

A----B-----C, both links have a smaller MTU than needed for a packet.

B received two fragments of a BIERin6 packet from A, how would it forward to C ?

Zzh> This is just another option of supporting fragmentation.

If there is nothing wrong with the other option, why is this option needed ?

>From an implementation view, add another option means add an implementation for interoperability.

Thank you.
Zhe Zhang

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Tuesday, March 2, 2021 10:49 AM
To: zhangzhe (M) <[email-masked]>; Michael McBride <[email-masked]>; [email-masked]; BIER WG <[email-masked]>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Zhe,

From: BIER <[email-masked]<mailto:[email-masked]>> On Behalf Of zhangzhe (M)
Sent: Monday, March 1, 2021 8:37 PM
To: Michael McBride <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Thank you.
Zhe Zhang

Oppose.

mike

Thanks,
Shep
(Chairs)

---

From: duanfanghong <[email-masked]>
Date: Thu, 4 Mar 2021 08:30:09 +0000

Hi Jeffrey,

Zzh3> If the LOC part is from the multicast address space (https://tools.ietf.org/html/rfc4291#section-2.7), then it is a “multicast locator”, and the FUNCT:ARG part can be used for service delimiting, just like how unicast is done for VPNs.

So I understand the “multicast locator” you are saying is using the multicast address (rfc4291 section-2.7).
SPRING working group have just discussed about this:
https://mailarchive.ietf.org/arch/msg/spring/QadqCj31BgJCLicfUONQEviLno8/
“If so, it really does not conform to SRv6 data plane.”

I think this is a big change and should be discussed in SPRING working group.

Zzh3> I don’t see that it needs to stacked and there is no plan to do so.

Do you also use the “multicast locator” here ?

Anyway, it is a bigger change than above, with consenquences we can’t easily imagine.

I don’t think it is reasonable, far more an implementation concern I have already raised about forwarding plane or control plane.

Thank you.

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Thursday, March 4, 2021 3:54 AM
To: duanfanghong <[email-masked]>; [email-masked]; BIER WG <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Fanghong,

Please see zzh3> below.

Hi Jeffrey

Hi Fanghong,

Please see zzh2> below.

Hi Jeffrey and Sandy,

Zzh2> Yes.

Zzh2> Jeffrey

Thank you

Hi Fanghong,

Please see zzh> below.

Hi,

Zzh> Please see above.
Zzh> Thanks.
Zzh> Jeffrey

Thanks !
Fanghong Duan

Thanks,
Shep
(Chairs)

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Thu, 4 Mar 2021 09:44:52 +0000

Hi WG,

I oppose WG adoption of draft-zhang-bier-bierin6.
The updated content in section 1.2 (“BIERin6 does support SRv6 based overlay services…”) violates the existing SRv6 network programing mechanism defined in RFC 8986.

Best
Xuesong

Thanks,
Shep
(Chairs)

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 4 Mar 2021 12:40:06 +0000

Hi Zhe,

Please see zzh2> below.

From: zhangzhe (M) <[email-masked]>
Sent: Wednesday, March 3, 2021 9:40 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; Michael McBride <[email-masked]>; [email-masked]; BIER WG <[email-masked]>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Jeffrey,

Zzh2> The BFIR does the fragmentation, resulting in fragments in IPv6 headers and the BFERs will do the reassembly. This is just like BIERv6.
Zzh2> The difference is that with BIERin6, those IPv6 fragments are BIER payloads and the transit BFRs don't even look at the IPv6 header.

Zzh2> Using IPv6 for fragmentation is expensive. If an operator cares about it, and if the devices support Generic Fragmentation (that is applicable to BIER, MPLS, and any other layers), then that is a better option for those who cares about the IPv6 overhead.

>From an implementation view, add another option means add an implementation for interoperability.

Zzh2> As explained above, it is an optimization for those who cares. If they don't care, they can use the IPv6 based fragmentation.
Zzh2> Jeffrey

Thank you.
Zhe Zhang

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Tuesday, March 2, 2021 10:49 AM
To: zhangzhe (M) <[email-masked]<mailto:[email-masked]>>; Michael McBride <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Zhe,

Thank you.
Zhe Zhang

Oppose.

mike

Thanks,
Shep
(Chairs)

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 4 Mar 2021 13:38:10 +0000

Hi Fanghong,

Please see zzh4> below.

From: duanfanghong <[email-masked]>
Sent: Thursday, March 4, 2021 3:30 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]; BIER WG <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Jeffrey,

Zzh3> If the LOC part is from the multicast address space (https://tools.ietf.org/html/rfc4291#section-2.7<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc4291*section-2.7__;Iw!!NEt6yMaO-gk!XuRKefVwgXHpwRWQ8vfv5SIRfJYRqTUe3hCpEay8Bp3Y7a2hpKmVhexs-LUAcH5W$>), then it is a “multicast locator”, and the FUNCT:ARG part can be used for service delimiting, just like how unicast is done for VPNs.

Zzh4> To be exact, “multicast locator” is the LOC part of a multicast address, and the ‘LOC:FUNC:ARG’ concept is introduced in
SPRING working group have just discussed about this:
https://mailarchive.ietf.org/arch/msg/spring/QadqCj31BgJCLicfUONQEviLno8/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/QadqCj31BgJCLicfUONQEviLno8/__;!!NEt6yMaO-gk!XuRKefVwgXHpwRWQ8vfv5SIRfJYRqTUe3hCpEay8Bp3Y7a2hpKmVhexs-O6puE97$>
“If so, it really does not conform to SRv6 data plane.”

Zzh4> I am copying Rishabh, who made that comment. I am pretty sure the two are different things.

Zzh4> To be exact, a multicast address with the LOC:FUNC:ARG semantics.

Zzh4> Please see above.
Zzh4> Jeffrey

Thank you.

Hi Fanghong,

Please see zzh3> below.

Hi Jeffrey

Hi Fanghong,

Please see zzh2> below.

Hi Jeffrey and Sandy,

Zzh3> If the LOC part is from the multicast address space (https://tools.ietf.org/html/rfc4291#section-2.7<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc4291*section-2.7__;Iw!!NEt6yMaO-gk!XuRKefVwgXHpwRWQ8vfv5SIRfJYRqTUe3hCpEay8Bp3Y7a2hpKmVhexs-LUAcH5W$>), then it is a “multicast locator”, and the FUNCT:ARG part can be used for service delimiting, just like how unicast is done for VPNs. Obviously, we don’t need to setup multicast trees for those addresses on the transit nodes (because BIER is doing the distribution), but the BFERs have corresponding FIB entries with END.DT4/6/2M forwarding behaviors.

Zzh2> Yes.

Zzh2> Jeffrey

Thank you

Hi Fanghong,

Please see zzh> below.

Hi,

Zzh> Please see above.
Zzh> Thanks.
Zzh> Jeffrey

Thanks !
Fanghong Duan

Thanks,
Shep
(Chairs)

---

From: Stig Venaas <[email-masked]>
Date: Thu, 4 Mar 2021 10:00:29 -0800

Hi

I support adoption. It is a simple and useful solution.

Regards,
Stig

---

From: "zhangzhe (M)" <[email-masked]>
Date: Fri, 5 Mar 2021 03:52:17 +0000

Hi Jeffrey,

That is incorrect.
BIERv6 doesn't need an assembly and re-fragment  procedure in the transit B node.
But for BIERin6, an assembly and re-fragment  procedure is needed in the transit B node. (even when A----B----C are directed connected).
Because for BIERin6,  there is a BIER header in the first fragmented packet,  but there is no BIER header in the second fragmented packet and it can't be forwarded until it is assembly and re-fragmented.

Besides, this behavior, to assembly and re-fragment on transit BFR,  also *violates* the procedures defined in RFC8296 section 3 (quote below):
{ If the appropriate action is to fragment the packet, then the procedures of this section are applied, in sequence, to each fragment.
...... When an intermediate BFR is processing a received non-MPLS BIER packet, the BFR infers the BSL from the BIFT-id. The BFR then follows the forwarding procedures of [RFC8279]. }

This behavior, to assembly and re-fragment on transit BFR, also makes the "BIER-MTU" concept and the related drafts [1][2] meaningless.
[1] https://tools.ietf.org/html/draft-ietf-bier-path-mtu-discovery-09
[2] https://tools.ietf.org/html/draft-ietf-bier-mtud-00

Operators care about the cost, and also care about the Generic Fragmentation because it is still in its very early stage with many concerns.

Thank you

Zhe Zhang

From: BIER [mailto:[email-masked]] On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Thursday, March 4, 2021 8:40 PM
To: zhangzhe (M) <[email-masked]>; Michael McBride <[email-masked]>; [email-masked]; BIER WG <[email-masked]>
Subject: Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Zhe,

Please see zzh2> below.

From: zhangzhe (M) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, March 3, 2021 9:40 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; Michael McBride <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Jeffrey,

Thank you.
Zhe Zhang

Hi Zhe,

Thank you.
Zhe Zhang

Oppose.

mike

Thanks,
Shep
(Chairs)

---

From: <[email-masked]>
Date: Fri, 5 Mar 2021 13:41:02 +0800 (CST)

Dear chair and WG,

I support adoption.

The scheme described in this document looks simple and beautiful, and can be well used in the interworking of various networks, and simplify the forwarding process of BIER multicast packets. It is benefit when multiple BFR NBRs have different capabilities, suggested by this document, only a single BIER payload format itself is needed and embedded in different outer encodings, instead of defining different BIER payload format for each BFR NBR with different capabilities (otherwise it would be a disaster for the forwarding chip). So that this document well inherits the layering idea of BIER architecture.

Regards,

PSF

原始邮件

发件人：GregShepherd
收件人：BIER WG;
日 期 ：2021年02月26日 00:37
主 题 ：[Bier] Call For Adoption: draft-zhang-bier-bierin6

Thanks,
Shep
(Chairs)

---

From: duanfanghong <[email-masked]>
Date: Fri, 5 Mar 2021 11:12:04 +0000

Hi Jeffrey,

Zzh4> To be exact, a multicast address with the LOC:FUNC:ARG semantics.
That’s a false use of SRv6 LOC:FUNC:ARG semantics.
Please find “FIB” and “FIB lookup” in RFC8986.
When a multicast address is used, it is no longer a “FIB lookup” and the SRv6-capability carved in a router is no longer available.

This is really outside the scope of current SRv6, and should be discussed in SPRING working group (or maybe with PIM working group jointly).

Note, besides this SRv6 misuse, there are still overhead concerns in both of the two opinions.

Thank you.

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Thursday, March 4, 2021 9:38 PM
To: duanfanghong <[email-masked]>; [email-masked]; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Rishabh Parekh (riparekh) <[email-masked]>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Fanghong,

Please see zzh4> below.

Hi Jeffrey,

Zzh4> Please see above.
Zzh4> Jeffrey

Thank you.

Hi Fanghong,

Please see zzh3> below.

Hi Jeffrey

Hi Fanghong,

Please see zzh2> below.

Hi Jeffrey and Sandy,

Zzh2> Yes.

Zzh2> Jeffrey

Thank you

Hi Fanghong,

Please see zzh> below.

Hi,

Zzh> Please see above.
Zzh> Thanks.
Zzh> Jeffrey

Thanks !
Fanghong Duan

Thanks,
Shep
(Chairs)

---

From: "Rishabh Parekh (riparekh)" <[email-masked]>
Date: Fri, 5 Mar 2021 18:24:52 +0000

Fanghong,

In that SPRING thread, when considering the SID compression schemes, an evaluation metric was proposed to consider if a compression scheme is able to support a multicast address as the last segment (after uncompressing) of a segment list. My comment that encoding a multicast address in the segment list does not conform to SRv6 data plane (therefore that evaluation metric is not really valid and rather we should consider the ability to support a Replication SID as defined in draft-ietf-spring-replication-segment).

Clearly that is a totally different context (about segment list). Here in this BIER thread the “multicast” locator is used to designate a group of nodes because a single replicated packed reaches that group (of BFERs). Moreover, this locator is NOT used to make any forwarding decision – just the FUNC and possible ARG portion is used to derive the service context. IMO, I don’t think this is a violation of SRv6 data plane.

-Rishabh

From: duanfanghong <[email-masked]>
Sent: Friday, March 05, 2021 3:12 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Rishabh Parekh (riparekh) <[email-masked]>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Jeffrey,

Thank you.

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Thursday, March 4, 2021 9:38 PM
To: duanfanghong <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; BIER WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Rishabh Parekh (riparekh) <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Fanghong,

Please see zzh4> below.

Hi Jeffrey,

Zzh4> Please see above.
Zzh4> Jeffrey

Thank you.

Hi Fanghong,

Please see zzh3> below.

Hi Jeffrey

Hi Fanghong,

Please see zzh2> below.

Hi Jeffrey and Sandy,

Zzh2> Yes.

Zzh2> Jeffrey

Thank you

Hi Fanghong,

Please see zzh> below.

Hi,

Zzh> Please see above.
Zzh> Thanks.
Zzh> Jeffrey

Thanks !
Fanghong Duan

Thanks,
Shep
(Chairs)

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 5 Mar 2021 19:44:42 +0000

Hi Zhe,

You are still misunderstanding BIERin6.

BFIR does the fragmentation, resulting in individual IPv6 packets. For each IPv6 packet, a BIER header is imposed, and it is forwarded independently w/o reassembly by BFRs.

The above exactly conforms to the text you quoted: If the appropriate action is to fragment the packet, then the procedures of this section are applied, in sequence, to each fragment

Jeffrey

From: zhangzhe (M) <[email-masked]>
Sent: Thursday, March 4, 2021 10:52 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; Michael McBride <[email-masked]>; [email-masked]; BIER WG <[email-masked]>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Jeffrey,

That is incorrect.

This behavior, to assembly and re-fragment on transit BFR, also makes the "BIER-MTU" concept and the related drafts [1][2] meaningless.
[1] https://tools.ietf.org/html/draft-ietf-bier-path-mtu-discovery-09<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-bier-path-mtu-discovery-09__;!!NEt6yMaO-gk!RKqm56SqVQRtk1VpDeQAZxyDvVhN623_ZfKoIOa0qKR20ui48bbKYK-XN6oWzQ60$>
[2] https://tools.ietf.org/html/draft-ietf-bier-mtud-00<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-bier-mtud-00__;!!NEt6yMaO-gk!RKqm56SqVQRtk1VpDeQAZxyDvVhN623_ZfKoIOa0qKR20ui48bbKYK-XN7OXcxgU$>

Thank you

Zhe Zhang

Hi Zhe,

Please see zzh2> below.

Hi Jeffrey,

Thank you.
Zhe Zhang

Hi Zhe,

Thank you.
Zhe Zhang

Oppose.

mike

Thanks,
Shep
(Chairs)

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 5 Mar 2021 19:52:54 +0000

Hi Fanghong,

Please refer me to the exact text in RFC 8986 that this is violating.

What I see is:

   FIB:  Forwarding Information Base.  A FIB lookup is a lookup in the
      forwarding table.

The FIB entries can include both unicast and multicast addresses. A multicast address entry could also have the following behaviors (as non-exhaustive examples; others could also apply) just like a unicast one:

     4.6.  End.DT6: Decapsulation and Specific IPv6 Table Lookup

     4.7.  End.DT4: Decapsulation and Specific IPv4 Table Lookup

     4.8.  End.DT46: Decapsulation and Specific IP Table Lookup

     4.9.  End.DX2: Decapsulation and L2 Cross-Connect

     4.10. End.DX2V: Decapsulation and VLAN L2 Table Lookup

     4.11. End.DT2U: Decapsulation and Unicast MAC L2 Table Lookup

     4.12. End.DT2M: Decapsulation and L2 Table Flooding

Jeffrey

From: duanfanghong <[email-masked]>
Sent: Friday, March 5, 2021 6:12 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]; BIER WG <[email-masked]>; [email-masked] <[email-masked]>; Rishabh Parekh (riparekh) <[email-masked]>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Jeffrey,

Thank you.

Hi Fanghong,

Please see zzh4> below.

Hi Jeffrey,

Zzh4> Please see above.
Zzh4> Jeffrey

Thank you.

Hi Fanghong,

Please see zzh3> below.

Hi Jeffrey

Hi Fanghong,

Please see zzh2> below.

Hi Jeffrey and Sandy,

Zzh2> Yes.

Zzh2> Jeffrey

Thank you

Hi Fanghong,

Please see zzh> below.

Hi,

Zzh> Please see above.
Zzh> Thanks.
Zzh> Jeffrey

Thanks !
Fanghong Duan

Thanks,
Shep
(Chairs)

---

From: Greg Shepherd <[email-masked]>
Date: Sun, 7 Mar 2021 08:39:05 -0800

Thank you to all the authors, participants in the discussion contributing
technical arguments, and to everyone who commented and voted. Special
thanks to Jeffrey for keeping the technical discussions honest and
productive.

The call to adopt has passed. Comments to the list regarding the vote, this
draft and others below. The votes are as follows:

Name Yes No
[email-masked] x
[email-masked] x
[email-masked] x
[email-masked] x
[email-masked] x
[email-masked] x
[email-masked] x
[email-masked] x
[email-masked] x
[email-masked] x
[email-masked] x
[email-masked] x
[email-masked] x
[email-masked] x
[email-masked] x
[email-masked] x
[email-masked] x
[email-masked] x
[email-masked] x
[email-masked] x
---------------------------------------------------
TOTAL: 12 8

This work is supported under the BIER WG charter:

<>
7) BIER in IPv6 : A mechanism to use BIER natively in IPv6 may be
standardized if coordinated with the 6MAN WG and with understood
applicability.
</>

The call for adoption of draft-zhang-bier-bierin6 drew another round of
comments and comparisons to draft-xie-bier-ipv6-encapsulation, so I will
address the comments and comparisons here.

*Technical Summary*

Summary of BIERin6:

   - Existing generic BIER-non-MPLS solution – BIER packets transported
   over L2 links or any tunnels (including IPv6 tunnels) between two BFRs.
   - IPv6 tunnels for BIER transport is typically multi-hop, either for
   getting over BIER incapable routers or for FRR purposes.
   - One-hop IPv6 tunnels can be optionally used between directly connected
   BFRs if L2 cannot indicate next header is BIER (either due to lack of code
   points or because existing hw cannot handle a new code point)
   - Clean layered, standards-based, generic architecture: BIER payload,
   BIER, and BIER transport are completely independent.
      - BIER layer does not care what transport is used. BIER packets are
      payloads of L2 or tunnels (e.g. IPv6 “next header” is BIER).
      - BIER layer does not care what payload it is carrying
   - Supports all requirements w/o any new procedures:
      - BIER is L2.5, like MPLS, and has no fragmentation requirement as
      part of the BIER architecture. Network fragmentation of UDP
packets is not
      recommended.
         - RFC8085 UDP Usage Guidelines, Section 3.2 - "..an application
         SHOULD NOT send UDP datagrams that result in IP packets that
         exceed the Maximum Transmission Unit (MTU) along the path to the
         destination.  Consequently, an application SHOULD either use the
         path MTU information provided by the IP layer or implement Path
         MTU Discovery (PMTUD) itself [RFC1191][RFC1981] [RFC4821] to
         determine whether the path to a destination will support its
         desired message size without fragmentation."
         - Optional fragmentation/ESP between BFIR/BFER, if needed, can be
         achieved by first imposing IPv6 header for fragmentation/ESP and then
         imposing BIER header.

      - SRv6 based services over BIER can be achieved by imposing a BIER
      header after imposing IPv6 header used for SRv6 service.
      - In both cases, IPv6 (for the purpose of fragmentation/ESP/service)
      is treated as BIER payload, but that is different from the IPv6 used for
      tunneling between BFRs.
   - Reason for standardization
      - Need code point for BIER as “IPv6 next header” (for IPv6
      tunneling). The same code point is also “IP Protocol” if IPv4
tunneling is
      used in an IPv4 non-MPLS network.
      - Given the long-time debate on BIERin6 vs. BIERv6, it is critical to
      have a standard RFC to document this generic BIER-non-MPLS solution for
      IPv6 networks.

Summary of BIERv6:

   - BIER and IPv6 tightly coupled for BIER/lower layer:
      - BIER header as option in IPv6 DOH
      - IPv6 encapsulation from BFIR to BFER. IPv6 is used even between
      directly connected BFRs
   - Service over BIER tightly coupled with SRv6 (protocol/layer
   dependency)
      - But with different SRv6 behavior – Source address instead of DA is
      used on BFER for service delimiting, which has its own complications

*Conclusion:*A cleanly layered, standards-based, generic solution
(draft-zhang-bier-bierin6) vs. a solution that creates a BIER
protocol dependency with IPv6/SRv6 but with changes in SRv6 service
handling (draft-xie-bier-ipv6-encapsulation)

*Some additional comments about the drafts, the WG process, and the impact
to the existing BIER Standards-Track(ST) Architecture:*

>From rev0 of draft-xie-bier-ipv6-encapsulation, it was explained to the
authors that the encoding and encapsulation are completely separate tools
and need to be addressed as such. There are numerous IETF ST
encapsulation tools available, and any proposed new encapsulation will
require justification - ie, some use-case that cannot be solved any other
way, or some unique value offered by a new proposal. No unique use-case has
been adequately described.  It has been pointed out countless times that
the name of the draft is misleading and should be changed to more
accurately describe/represent the intent of the draft, ie - encoding.
Despite numerous requests, the name has remained, and the text of the draft
continues to obfuscate the distinction:

draft-xie-bier-ipv6-encapsulation, 1, Introduction:

This document proposes a BIER IPv6 *encapsulation* for Non-MPLS IPv6
   Networks, defining a method to carry the standard Non-MPLS BIER
   header (as defined in [RFC8296]) in the native IPv6 header.  A new
   IPv6 Option type - BIER Option is defined to *encode* the standard Non-
   MPLS BIER header and this newly defined BIER Option is carried under
   the Destination Options header of the native IPv6 Header [RFC8200].

After rev 1 or 2 it may be assumed there is some remaining confusion,
miscommunication, or misunderstanding. But after rev10 without the authors
addressing the issue, it can only be concluded that the obfuscation is
intentional, and the authors are unwilling to listen to technical feedback
from the WG.

The BIER WG began as experimental because the work required fundamental
changes to the Internet architecture by defining a new forwarding plane,
which includes a BIER encoding header and associated BIER architecture.
This encoding has now been adopted as ST. Any additional encoding methods
would only serve to errode the standards work of the BIER WG and
potentially undo the past 8 years of work. This high bar that was set by
the IAB and our AD (Alia Atlas), at the time. The bar will not be
lowered. An encapsulation method as described in draft-zhang-bier-bierin6
is in no way experimental in that it uses the ST BIER encoding and existing
methods and registries.

Any new encoding and/or forwarding plane must face the same level of
scrutiny. To date, the authors of draft-xie-bier-ipv6-encapsulation have
failed to offer any compelling, unique use-case where a new encoding is
required. As a further complication, the proposal creates a dependency
between SRv6 and BIER. Protocol dependencies have come and gone in the
IETF, and in every case I've found, they have proven to be crippling at
best, if not outright monumental failures. Any proposal which requires
changes to the forwarding plane, protocol dependencies, and potential
erosion of the BIER Architecture and established ST work has an even higher
bar to clear. The authors to date, have shown no intention to address these
concerns with clear technical reasoning.

- Shep
(Chairs)

On Thu, Feb 25, 2021 at 8:37 AM Greg Shepherd <[email-masked]> wrote:

> Thank you all for the active discussion that brought us to consensus. This
> draft now addresses all of the points of discussion for the solution.
>

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 8 Mar 2021 07:32:04 -0800

Apparently my email filters are less than perfect. Stig pointed out that he
voted on March 4th but his vote wasn't in the tally. I confirmed receipt of
his vote and have updated the count as below. Will the authors please
update the draft name w/ the WG convention and Charis will accept. Thanks.

Name Yes No
[email-masked] x
[email-masked] x
[email-masked] x
[email-masked] x
[email-masked] x
[email-masked] x
TOTAL: 13 8

Thanks,
Shep
(Chairs)

On Sun, Mar 7, 2021 at 8:39 AM Greg Shepherd <gj
[email-masked]> wrote:

> The call to adopt has passed. Comments to the list regarding the vote,
> this draft and others below. The votes are as follows:
>
> Name Yes No
> [email-masked] x
> [email-masked] x
> [email-masked] x
> [email-masked] x
> [email-masked] x
>    - One-hop IPv6 tunnels can be optionally used between directly
>    connected BFRs if L2 cannot indicate next header is BIER (either due to
>    lack of code points or because existing hw cannot handle a new code point)
>       part of the BIER architecture. Network fragmentation of UDP packets is not
>       recommended.
>          - Optional fragmentation/ESP between BFIR/BFER, if needed, can
>          be achieved by first imposing IPv6 header for fragmentation/ESP and then
>          imposing BIER header.
>
>       - In both cases, IPv6 (for the purpose of
>       fragmentation/ESP/service) is treated as BIER payload, but that is
>       different from the IPv6 used for tunneling between BFRs.
>       tunneling). The same code point is also “IP Protocol” if IPv4 tunneling is
>       - Given the long-time debate on BIERin6 vs. BIERv6, it is critical
>       to have a standard RFC to document this generic BIER-non-MPLS solution for
>       IPv6 networks.
>
>
>
> Summary of BIERv6:
>
>
>
>       - But with different SRv6 behavior – Source address instead of DA
>       is used on BFER for service delimiting, which has its own complications
>
>
>
>> Thank you all for the active discussion that brought us to consensus.
>> This draft now addresses all of the points of discussion for the solution.
>>

---

From: Michael McBride <[email-masked]>
Date: Mon, 8 Mar 2021 16:34:30 +0000

We don't vote in the ietf. Chairs have the right to determine consensus as they see fit. And that can be appealed.

It's very unfortunate the bier wg didn't follow the excellent advice Ron Bonica gave this morning to spring wrt to compression solutions "If we let all proposals progress, we can let the marketplace decide. After all, the operators know what they want." Indeed.

mike

From: BIER <[email-masked]> On Behalf Of Greg Shepherd
Sent: Monday, March 08, 2021 7:32 AM
To: BIER WG <[email-masked]>
Subject: Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Apparently my email filters are less than perfect. Stig pointed out that he voted on March 4th but his vote wasn't in the tally. I confirmed receipt of his vote and have updated the count as below. Will the authors please update the draft name w/ the WG convention and Charis will accept. Thanks.

Name
Yes
No
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
---------------------------------------------------
TOTAL:
13
8

Thanks,
Shep
(Chairs)

On Sun, Mar 7, 2021 at 8:39 AM Greg Shepherd <gj
[email-masked]<mailto:[email-masked]>> wrote:
Thank you to all the authors, participants in the discussion contributing technical arguments, and to everyone who commented and voted. Special thanks to Jeffrey for keeping the technical discussions honest and productive.

The call to adopt has passed. Comments to the list regarding the vote, this draft and others below. The votes are as follows:

Name
Yes
No
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
[email-masked]<mailto:[email-masked]>
x
---------------------------------------------------
TOTAL:
12
8

<>

The call for adoption of draft-zhang-bier-bierin6 drew another round of comments and comparisons to draft-xie-bier-ipv6-encapsulation, so I will address the comments and comparisons here.

Technical Summary
Summary of BIERin6:

*        Existing generic BIER-non-MPLS solution - BIER packets transported over L2 links or any tunnels (including IPv6 tunnels) between two BFRs.
*        IPv6 tunnels for BIER transport is typically multi-hop, either for getting over BIER incapable routers or for FRR purposes.
*        One-hop IPv6 tunnels can be optionally used between directly connected BFRs if L2 cannot indicate next header is BIER (either due to lack of code points or because existing hw cannot handle a new code point)
*        Clean layered, standards-based, generic architecture: BIER payload, BIER, and BIER transport are completely independent.
o   BIER layer does not care what transport is used. BIER packets are payloads of L2 or tunnels (e.g. IPv6 "next header" is BIER).
o   BIER layer does not care what payload it is carrying
*        Supports all requirements w/o any new procedures:
o   BIER is L2.5, like MPLS, and has no fragmentation requirement as part of the BIER architecture. Network fragmentation of UDP packets is not recommended.
*        RFC8085 UDP Usage Guidelines, Section 3.2 - "..an application SHOULD NOT send UDP datagrams that result in IP packets that exceed the Maximum Transmission Unit (MTU) along the path to the destination.  Consequently, an application SHOULD either use the path MTU information provided by the IP layer or implement Path MTU Discovery (PMTUD) itself [RFC1191][RFC1981] [RFC4821] to determine whether the path to a destination will support its desired message size without fragmentation."
*        Optional fragmentation/ESP between BFIR/BFER, if needed, can be achieved by first imposing IPv6 header for fragmentation/ESP and then imposing BIER header.

o   SRv6 based services over BIER can be achieved by imposing a BIER header after imposing IPv6 header used for SRv6 service.
o   In both cases, IPv6 (for the purpose of fragmentation/ESP/service) is treated as BIER payload, but that is different from the IPv6 used for tunneling between BFRs.
*        Reason for standardization
o   Need code point for BIER as "IPv6 next header" (for IPv6 tunneling). The same code point is also "IP Protocol" if IPv4 tunneling is used in an IPv4 non-MPLS network.
o   Given the long-time debate on BIERin6 vs. BIERv6, it is critical to have a standard RFC to document this generic BIER-non-MPLS solution for IPv6 networks.

Summary of BIERv6:

*        BIER and IPv6 tightly coupled for BIER/lower layer:
o   BIER header as option in IPv6 DOH
o   IPv6 encapsulation from BFIR to BFER. IPv6 is used even between directly connected BFRs
*        Service over BIER tightly coupled with SRv6 (protocol/layer dependency)
o   But with different SRv6 behavior - Source address instead of DA is used on BFER for service delimiting, which has its own complications

Conclusion:A cleanly layered, standards-based, generic solution (draft-zhang-bier-bierin6) vs. a solution that creates a BIER protocol dependency with IPv6/SRv6 but with changes in SRv6 service handling (draft-xie-bier-ipv6-encapsulation)

Some additional comments about the drafts, the WG process, and the impact to the existing BIER Standards-Track(ST) Architecture:

>From rev0 of draft-xie-bier-ipv6-encapsulation, it was explained to the authors that the encoding and encapsulation are completely separate tools and need to be addressed as such. There are numerous IETF ST encapsulation tools available, and any proposed new encapsulation will require justification - ie, some use-case that cannot be solved any other way, or some unique value offered by a new proposal. No unique use-case has been adequately described.  It has been pointed out countless times that the name of the draft is misleading and should be changed to more accurately describe/represent the intent of the draft, ie - encoding. Despite numerous requests, the name has remained, and the text of the draft continues to obfuscate the distinction:

This document proposes a BIER IPv6 encapsulation for Non-MPLS IPv6

   IPv6 Option type - BIER Option is defined to encode the standard Non-

   the Destination Options header of the native IPv6 Header [RFC8200].
After rev 1 or 2 it may be assumed there is some remaining confusion, miscommunication, or misunderstanding. But after rev10 without the authors addressing the issue, it can only be concluded that the obfuscation is intentional, and the authors are unwilling to listen to technical feedback from the WG.

The BIER WG began as experimental because the work required fundamental changes to the Internet architecture by defining a new forwarding plane, which includes a BIER encoding header and associated BIER architecture. This encoding has now been adopted as ST. Any additional encoding methods would only serve to errode the standards work of the BIER WG and potentially undo the past 8 years of work. This high bar that was set by the IAB and our AD (Alia Atlas), at the time. The bar will not be lowered. An encapsulation method as described in draft-zhang-bier-bierin6 is in no way experimental in that it uses the ST BIER encoding and existing methods and registries.

Any new encoding and/or forwarding plane must face the same level of scrutiny. To date, the authors of draft-xie-bier-ipv6-encapsulation have failed to offer any compelling, unique use-case where a new encoding is required. As a further complication, the proposal creates a dependency between SRv6 and BIER. Protocol dependencies have come and gone in the IETF, and in every case I've found, they have proven to be crippling at best, if not outright monumental failures. Any proposal which requires changes to the forwarding plane, protocol dependencies, and potential erosion of the BIER Architecture and established ST work has an even higher bar to clear. The authors to date, have shown no intention to address these concerns with clear technical reasoning.

- Shep
(Chairs)

On Thu, Feb 25, 2021 at 8:37 AM Greg Shepherd <[email-masked]<mailto:[email-masked]>> wrote:
Thank you all for the active discussion that brought us to consensus. This draft now addresses all of the points of discussion for the solution.

https://datatracker.ietf.org/doc/draft-zhang-bier-bierin6/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-zhang-bier-bierin6%2F&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C9dc520b7947c490dbd0508d8e2474645%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637508143049443350%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GYLZGyJ%2BpDDDPqa%2FfvEN7cu7%2BlGrsdqBk4MK3mEQaJk%3D&reserved=0>

Thanks,
Shep
(Chairs)