Re: [Bier] ipv6 requirements draft call for action

Hi
As an author of one listed solution document, I'd like to post the suggestions about the WG's ipv6 requirements draft from my view.

4.2.  Hop by hop DA modification
[xjr1] This section could conclude to allow the change of DA modification, since there have been many discussions in ietf104, ietf103 and even longer before on the list, that bypassing a Non-BIER routers is part of the BIER architecture (RFC8279). Seems like all the below drafts tend to use unicast destination address and will do Hop-by-hop DA modification or multiple-hop DA modification when bypassing Non-BIER routers.

[xjr2] Also I think this section could be more clear to add a requirement/recommendation: Solutions do not require Hop-by-hop SA modification is preferred, because keeping the SA is beneficial for fast-path forwarding (req 4.9 in this doc), is beneficial for get notice from BFIR for function like BIER PING and TRACE and MTU notification, is beneficial for identifying an MVPN instance to get rid of more encapsulation like Service Label like MPLS VPN Label or VNI in the SRv6 network (as philosophy of SRv6 mentioned in 4.3 of this doc), and is beneficial for SA filtering (req 4.6 in this doc). 

[xjr3] according to the above [xjr2], the title of section 4.2 could be changed accordingly to "Hop by hop DA or SA modification", or the title of section 4.4 could be changed accordingly to "SA field requirement" and the above [xjr2] moved to section 4.4.

4.3.  L4 Inspection
[xjr4] This section need more explanation as there have been some arguments on the list what is L4. Here are some points for reference:
(1) In Fragmentation, BIER is payload, and will be fragmented..  (BIER-header + payload-1-to-1xxx bytes) in one packet, and (payload-1xxx-to-2xxx) in another packet.
Thus, when BFR B receive a packet from BFR A, BFR B has to assembly the fragmented packets before sending to BFR C and BFR D.
(2) In AH, BIER is payload, and will be seen as immutable for Integrity Check Value (ICV) calculation. 
Thus, when BFR B receive a packet with AH ICV from BFR A, BFR B has to do the AH verification before sending to BFR C and BFR D.
(3) In SRH, BIER is payload, and will be reached only after the SRH is processed.
Thus, when BFR B receive a packet with SRH from BFR A, BFR B has to process the SRH first, and then the Upper-layer BIER header at last.

[xjr5] Also, there could be more explanation on why SRH is need to be integrated here for two reasons, one is that the solution is target to work well in SRv6 networks as a use case in section 3.4 of this doc, one is that both the 2nd and 4th of the following document both agree to consider SRH integration. 

4.7.  BIER architecture support
[xjr6] add explanation about Bypassing Non-BIER routers and L2 switches as part of the BIRE architecture to be supported as mandatory requirement.

5.  Solutions Evaluation
[xjr7] This section could add some text to remind that each solution should declare its compliance with this document before the detailed evaluation of each proposal, since this document is the production of WG after more than 60 minutes thorough discussion on ietf103, ietf104 based on the work of past 5 years! Also the key problems of each proposal that don't meet the requirements could be made clear for further discussions on the list. 

Thanks
Jingrong

-----Original Message-----
From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Mike McBride
Sent: Friday, August 09, 2019 6:54 AM
To: BIER WG <bier@ietf.org>
Subject: [Bier] ipv6 requirements draft call for action

Hello all,

Just a reminder to please, especially if you are authoring one of the below solutions drafts, contribute to our wg's ipv6 requirements draft (draft-ietf-bier-ipv6-requirements). Authors and contributors are wide open. We intend to progress this quickly so we can start adopting/progressing the solutions documents. Without additional feedback we will give it our best shot to properly justify each solution. We are shooting to get this "done" by Singapore.

Here are the solutions drafts referenced in the draft:

pfister-bier-over-ipv6
xie-bier-ipv6-encapsulation
xu-bier-encapsulation
zhang-bier-bierin6

thank you!
mike

_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ietf.org/mailman/listinfo/bier