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
_______________________________________________
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org
