Actually, we don't need the extended community even in the case of tunnel segmentation, because the C-multicast route used for explicit tracking purposes should not be sent to the UMH but to the local upstream segmentation point (and the next hop of the route would not change so it can be used to identify the leaf PE).
Additionally, if the UMH route is used to advertise the PTA info, then the segmentation points need to update that info, which is not desired since they're just unicast routes not MVPN routes. The existing x-PMSI route procedures work very well with tunnel segmentation. Juniper Business Use Only -----Original Message----- From: Jeffrey (Zhaohui) Zhang Sent: Friday, November 10, 2023 2:30 PM To: Chensiyu (Susie) <chensiyu27=40huawei....@dmarc.ietf.org>; 'BESS' <bess@ietf.org> Subject: Comments about https://datatracker.ietf.org/doc/html/draft-duan-bess-simplified-mvpn-for-bier-and-ir-00 Hi Siyu, To follow up my comments in the BESS session, it is indeed good to optimize provider tunnel procedures based on PMSI/Leaf AD route in the case of IR/BIER, but there are alternatives. Essentially, draft-duan replaces the PMSI/Leaf AD routes with the following: - Announce the PTA info in the UMH routes instead of PMSI routes - Use a new route type, which is a variant of C-Multicast route instead Leaf route, for leaf tracking purposes For leaf tracking purposes, an alternative is also proposed in https://datatracker.ietf.org/doc/html/draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-01#section-1.2.1. Notice that the (C-*,C-G-BIDIR) C-Multicast routes from different PEs all have their own RDs so Route Reflectors (RRs) will reflect every one of them, and they already serve explicit tracking purpose (the BGP Next Hop identifies the originator of the route in non- segmentation case) - there is no need to use Leaf A-D routes triggered by the LIR bit in S-PMSI A-D routes. In case of RSVP-TE P2MP tunnel, the S-PMSI A-D routes are still needed to announce the tunnel but the LIR bit does not need to be set. In case of IR/BIER, there is no need for S-PMSI A-D routes at all. Although that is in the context of the MVPN-RPL Method of C-BIDIR support, the same idea can be used in general: instead of using the UMH's RD, each leaf PE just uses its own RD. While in RFC6514 the UMH's RD is used, that is for exactly the opposite purpose - the RRs only need to re-advertise a single C-Multicast route to the UMH while here we want each C-Multicast route to reach the UMH for leaf tracking purposes. This method does not need a new route type - just use the leaf PE's own RD and attach an extended community to identify the leaf PE (the extended community is only needed in case of tunnel segmentation). To announce the PTA, we don't need to attach the PTA (info) to the UMH routes (which could be a lot). A single I-PMSI or (*,*) S-PMSI can be used, or additional S-PMSI routes can also be used when more granularity is needed (e.g., some flows use some sub-domains while some other flows use some other subdomains). Thanks. Jeffrey _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
