Hi Mankamana, Thank you for the detailed shepherd review. We have addressed comments in the latest version(draft-ietf-bess-evpn-mvpn-seamless-interop-12). Please see the response below.
Thanks Kesavan From: Mankamana Mishra (mankamis) <[email protected]> Date: Tuesday, June 30, 2026 at 12:08 AM To: [email protected] <[email protected]> Cc: BESS <[email protected]> Subject: Shepherd review comment draft-ietf-bess-evpn-mvpn-seamless-interop Authors, As part of shepherd review, please find some comments. Editorial * “When the the source” → “When the source”. * “Singe-Active” → “Single-Active”. * “on-touched” → “untouched”. * “ethernet segment” → “Ethernet Segment”. * “Section 6 and 7” → “Sections 6 and 7”. >>> Addressed all of them in the latest version Minor : * Section 10 SEMG behavior uses several lowercase “should/must” statements where protocol behavior seems required, especially discarding SMET/IGMP from non-DF SEMG and non-SEMG PEs. These should be reviewed for RFC 2119 capitalization. * Missing reference for IEEE802.1Q and unused RFC7348 reference. >>> This is taken care in the latest version Major to consider : * Capability signaling should probably be normative : Section 6 says seamless interop capable PEs SHOULD attach the EVPN Multicast Flags EC with “EVPN/MVPN Seamless Interop Supported” set. For mixed networks, this seems important for safe behavior. Consider whether this should be MUST. >>> It is kept as SHOULD to be on the safer side. * All-active intra-ES tunnel behavior needs tighter normative language :Section 6.1 says traffic received from inter-subnet tunnel “should not” be sent to the Intra-ES subnet tunnel. This is a loop/duplication prevention rule and should likely be MUST NOT. >>> It is also kept as SHOULD not. ( Some implementation may choose to do >>> decap at one side and may enforce the loop prevention/split horizon >>> handling in a different way ) * Security Considerations are too thin : Section 15 only inherits security considerations from RFC7432/RFC6513/RFC6514/RFC9251. Since this draft introduces new interworking behavior, VRI use with EVPN routes, SEMG behavior, and possible traffic attraction, it should mention risks from incorrect/malicious route import, forged MVPN/EVPN routes, state exhaustion, and misconfigured gateways. >>> Added detailed security consideration capturing above points in the latest >>> version. Mankamana
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
