[bess] following-up discussions on draft-liu-bess-srv6-evpn-validation

[[e-mail]]

Dear All,
Thank you for the interest and comments on draft-liu-spring-aggregate-header-limit-problem during the presentation on last week's BESS meeting.
Below are the following-up responses to the comments and discussions around this work.

a) [Comments from Zafar & Ali]    There're two aspects about this work, one is the the base request and reply mechanism(the container) which should be done in 6man/intarea, another is the specific encoding for SRv6 EVPN(the contents) which belongs to BESS.

 [Yao]     Yes, it's better to do this separately. Actually, about the container part, we've already written a separate draft in 6MAN before, draft-liu-6man-icmp-verification, which is more focused on the validation mechanism itself. 
If there's a rough consensus in BESS that a validation request/reply mechanism is needed in IPv6 at least for SRv6 EVPN connectivity check, we can take this work to 6man and intarea. And this is also the initial reason why we presented in BESS. 

To the chairs, I'm not sure if I can say we have a  rough consensus on the requirement now, or some more discussion or work in BESS is required before we go to 6man/intarea to work on the validation message itself.

b) [Comments from Ali]     About the content part, it's better to keep the encoding for different transport (MPLS/SRv6/VXLAN) in one place. RFC9489 already defines all types of sub-TLVs for MPLS EVPN, and the encoding is applicable for SRv6 and VXLAN. One possible way is writing an errata to claim that RFC9489 needs to cover other transport and to update RFC9489 for these transport. 

[Yao] I think this would work, haven't seen any new encoding/format required especially for SRv6 EVPN yet. 
Maybe it's better and faster if the authors of RFC9489 would like to do the errata and update work for RFC9489, so we can use it directly for SRv6 EVPN connectivity check.  

c) [Yao]     This point is related with comments a) and b). 
From my point of view, there might be three parts of the work. Besides the container and the encoding, the third part is mainly about the usecase-specified operation.
Assume that we already have the icmpv6 mechanism and the encoding of the contents from the updated RFC9489, but for a few cases, we still need to know, how this request message should be sent.
For example, RFC9489 specifies the procedure for MPLS inclusive multicast data plane connectivity check in section 4.2, and how to encapsulate and send the request for the ingress replication and P2MP P-Tree scenario for MPLS. But if SRv6 P2MP Trees is used as P-Tunnels for SRv6 EVPN as specified in draft-ietf-bess-mvpn-evpn-sr-p2mp, some description on how the validation request for SRv6 inclusive multicast connectivity check is encapsulated and sent may help the implementation.
Such descriptions may be small paragraphs related with usecases, but there should be a place to put them in.

d) [Comments from Jorge&Ali]     There's no PBB EVPN for SRv6.
[Yao]     Regardless of how this work should be continued, a new version of the draft-liu-bess-srv6-evpn-validation has been uploaded to remove the PBB-EVPN part.

Thanks,
Yao