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

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

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) <[e-mail]>
Sent: Thursday, March 4, 2021 10:52 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>; Michael McBride <[e-mail]>; [e-mail]; BIER WG <[e-mail]>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

[External Email. Be cautious of content]

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.

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


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.

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

Hi Zhe,

Please see zzh2> below.

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

[External Email. Be cautious of content]

Hi Jeffrey,

Zzh> This is incorrect. IPv6 header is not required before the BIER header.

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 ?

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.

Zzh> This is just another option of supporting fragmentation.

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

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:[e-mail]]
Sent: Tuesday, March 2, 2021 10:49 AM
To: zhangzhe (M) <[e-mail]<mailto:[e-mail]>>; Michael McBride <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; BIER WG <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Zhe,

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

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

[External Email. Be cautious of content]

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.

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.

The other is to use a Fragment header after BIER header to avoid intermediate BFR to do the assembly and re-fragment,

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

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:[e-mail]] On Behalf Of Michael McBride
Sent: Friday, February 26, 2021 2:15 PM
To: [e-mail]<mailto:[e-mail]>; BIER WG <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Greg Shepherd
Sent: Thursday, February 25, 2021 8:37 AM
To: BIER WG <[e-mail]<mailto:[e-mail]>>
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!VKB3yHu_QZ4fBfMiI4-3Zo-ypqKyMPWun_fQPiGpd7rlsAQxIqHX-chKmgUuIy2u$>

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

Thanks,
Shep
(Chairs)


Juniper Business Use Only


Juniper Business Use Only


Juniper Business Use Only