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

[[e-mail]]

Hi Jingrong,


Thank you for your respond!


Please find my comments inline below with Sandy>. Hope it help you to understand BIER correctly.


Thanks,


Sandy





原始邮件



发件人：Xiejingrong(Jingrong) <[e-mail]>
收件人：张征00007940;[e-mail] <[e-mail]>;SenthilDhanaraj <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
抄送人：[e-mail] <[e-mail]>;
日 期 ：2020年07月30日 16:51
主 题 ：RE: [Bier] comments on draft-ietf-bier-ipv6-requirements-06






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.


Sandy>: No. In order to achieving BIER forwarding, any type of encapsulation functions can be used, such as MPLS, Ethernet or IPv6. In case the silicon can not recognize BIER Ethernet type (0xAB37), BIER packet can also be encap with MPLS or IPv6 encapsulation, and BIER can also be processed to achieving multicast forwarding. Please find more details in RFC8296.






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 inhttps://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.


Sandy> Again, as I said, I think these description is totally wrong. You should delete them in the bier-ipv6-requirements draft.






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.


Sandy> Again. I don't think a "BIER specific" IPv6 address is needed. 


And as you said, you have so many asumption of "excepted", does it mean you must encapsulate BIER with specific rules. I also don't think it's necessary.





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