Re: [Bier] comments on draft-ietf-bier-ipv6-requirements-06

["Xiejingrong (Jingrong)" <[e-mail]>]

Hi Sandy,
Thanks for your comments.
Let me share my understanding on your points, and hope it helps your understanding.

For comment-1, do you mean the mixed usage of “BIERin6 encapsulation” and “BIER-ETH encapsulation” ?  I am not sure, but I think it would be great help and contribution to the requirement clarification if you could provide the text.

For comment-2, Your opinion that “if packet need frag, it won't be executed in BFR”, is also my general understanding, and Section 4.2.4 also has this text as general requirement as “Support Fragmentation” claim (note 4.2.4 is optional).
There have been some comments in BIER WG that per-hop reassembly/re-fragmentation is also a case, and even have some advantage of using existing protocol stack in HOMENET case, so this feature is included in this section.
(been a long time, the comments may be found in https://mailarchive.ietf.org/arch/browse/static/bier/2020-03/).
If you have better text to include both of the above view, it would be appreciated to kindly and patiently provided  that text and contribute to the requirements.

For comment-3,
Regarding the possible EH combination, the “BIER specific” IPv6 address semantics is used for this.
There is an “expected EH” assumption in the IPv6 address semantics, and if the EH combination is not the “expected” one, then it is discarded in fast path and so a walk of the EH chain is not needed.
Section 3.2 of <draft-xie-bier-ipv6-encapsulation-08> has a detailed description including pseudo-code example.

Regarding the Fragment EH, as the <draft-xie-bier-ipv6-encapsulation-08> section 4 describes below:
   The procedures applies normally if a bit corresponding to the self
   bfr-id is set in the BitString field of the BIERv6 Option Data of the
   BIERv6 packet.  The node is considered to be an Egress BFR (BFER) in  //and BFER will do the BIER overlay procedure.
   this case.

   The Fragment Header, AH Header or ESP Header, if exists after the  //And only in this stage, the FH/AH/ESP is processed.
   BIER options header, can be processed on BFER only as part of the  //Before this stage, the BFR only need to process the DoH that preceding these EHs.
   multicast flow overlay process.


Regards,
Jingrong

From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, July 29, 2020 4:13 PM
To: [e-mail]; Xiejingrong (Jingrong) <[e-mail]>; Senthil Dhanaraj <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: [Bier] comments on draft-ietf-bier-ipv6-requirements-06


Hi authors,

I have some comments for this draft.



1. In section 2 problem statement, only the situation across non-BFR node (if I understand right, you mean BIER incapable node) is mentioned.

In fact, some nodes just don't recognize BIER Ethernet type, but can also do BIER forwarding according to BIER header. This situation should also be included.



2. In section 3.1,

"Reassembly/Re-fragmentation of a packet has to be executed on each

   BFR in such case."

I think the description of "reassembly/re-fragmentation function" is wrong.

If some packet needs to be fragmented, BFIR does the fragment, and the fragmented packet is BIER payload, it won't be executed in BFR.

And the same with IPSEC ESP. The ESP is also the BIER payload, and the intermediate BFRs will not see it and execute it.



3. In section 3.2,

IPv6 extension header is described here. We know there are many IPv6 extension headers, the EHs encapsulation way may be different according to vendor's implementation and operator's deployment.

And further, there are many options defined in HBH and DOH. In this situation, if BIER header is encoded in any of them, how to locate the BIER header and guarantee the fast forwarding?

If two or more extension header existed, how do we know there is a BIER header existed which must be used for forwarding?

If fragment EH is also carried in the packet, how do we know it need or needn't to be executed?

Thanks,

Sandy