Hi Sasha and Tao, To my understanding, Sasha's question is about the process defined in section 5.11 of RFC 8679. In draft-ietf-rtgwg-srv6-egress-protection, it's the "Step 2b" in Section 3.1.1.
In RFC 8679 section 1, there are also following requirements: " This framework requires that the destination (a CE or site) of a service MUST be dual-homed or have dual paths to an MPLS network, via two MPLS edge routers. " and " The framework is a multi-service and multi-transport framework. It assumes a generic model where each service is comprised of a common set of components, including a service instance, a service label, a service label distribution protocol, and an MPLS transport tunnel. The framework also assumes that the service label is downstream assigned, i.e., assigned by an egress router. Therefore, the framework is generally applicable to most existing and future services. However, there are services with certain modes, where a protector is unable to pre-establish the forwarding state for egress protection, or a PLR is not allowed to reroute traffic to other routers in order to avoid traffic duplication, e.g., the broadcast, multicast, and unknown unicast traffic in Virtual Private LAN Service (VPLS) and Ethernet VPN (EVPN). These cases are left for future study. Services that use upstream-assigned service labels are also out of scope of this document and left for future study. " draft-ietf-rtgwg-srv6-egress-protection has the same requirement and needs to describe it clearly. I have another question to the authors: in section 3.1, how does P1 know it's the PLR? In SRv6, P1 may be several hops away from PEA, P1 doesn't know it is the "penultimate end point" before PEA until it receives an SRv6 data packet. Using the example in Figure 1, a packet from CE1 to CE2 can be delivered using an SRv6 path PE1->P2->PEA. In this case, P2 will be the PLR for PEA. If path PE1->PEA is chosen, PE1 will be the PLR. In other words, you can't decide the PLRs for PEA until you know all the SRv6 paths that terminate at PEA unless all routers with reachability to PEA are considered as possible PLRs. Please correct me if I'm missing something here. Thanks, Yingzhen On Tue, Jul 22, 2025 at 11:19 PM Alexander Vainshtein <Alexander.Vainshtein= [email protected]> wrote: > Dear Tao He, > > Lots of thanks for your response. > > > > I will re-read the draft and provide additional comments/questions if > necessary > > > > Regards, > > Sasha > > > > *From:* 何涛(联通集团本部) <[email protected]> > *Sent:* Tuesday, July 22, 2025 11:05 AM > *To:* Alexander Vainshtein <[email protected]> > *Cc:* rtgwg <[email protected]>; > draft-ietf-rtgwg-srv6-egress-protection.authors < > [email protected]> > *Subject:* [EXTERNAL] Re: [rtgwg] My question about > draft-ietf-rtgwg-srv6-egress-protection-19 > > > > Dear SaSha, > > Thank you for your description and question. > > According to this question: "*Is the draft we are discussing limited > to egress protection of SRv6 SIDs with just the following endpoint > behaviors: End, End.X and End.T?"* > > When the back up node receives the Segment List and handles the > Mirror SID, it following the endpoint behavior "End.M", which different > from the other "End" behavior. And we applied the endpoint behavior > "End.M" in the IANA website. > > Hope I had got in your question, thank you. > > > > > > Best Wishes. > > > =============================================== > Tao He > Next Generation Internet Research Department > > Research Institute > CHINA UNITED NETWORK COMMUNICATIONS CORPORATION LIMITED > > Mobile: +86-18618484923 > E-mail: [email protected] > > > > *From:* Alexander Vainshtein <[email protected]> > > *Date:* 2025-07-22 15:31 > > *To:* 何涛(联通集团本部) <[email protected]> > > *CC:* rtgwg <[email protected]>; > [email protected] > > *Subject:* RE: [EXTERNAL] Re: [rtgwg] My question about > draft-ietf-rtgwg-srv6-egress-protection-19 > > 【本邮件为外部邮件，请注意核实发件人身份，并谨慎处理邮件内容中的链接及附件】 > > Dear Tao He, > > I believe that I have not presented my question in a sufficiently clear > way. > > I will now try to present it differently. > > > > First, some background. > > > > > > Section 4 of RFC 8986 > <https://datatracker.ietf.org/doc/html/rfc8986#section-4> defines 15 > behaviors of SRv6 endpoints that correspond to different types of segments. > > > > This includes both “topology segments” (IP Prefix SID and Adj-SID) that > are common to SR-MPLS and SRv6, and the “service segments” that are > specific to SRv6. > > > > Section 10.2 of the above RFC > <https://datatracker.ietf.org/doc/html/rfc8986#section-10.2> defines a IANA > registry of SRv6 Endpoint behaviors > <https://www.iana.org/assignments/segment-routing/segment-routing.xhtml#srv6-endpoint-behaviors> > . > > > > Table 3 in Section 8.4 of the same RFC > <https://datatracker.ietf.org/doc/html/rfc8986#section-8.4> describes how > SRv6 SIDs of different types can be advertised. > > > > For your convenience, I am coping this table below with the “service SID > types highlighted. > > > > *SRv6 Endpoint Type* > > *IGP* > > *BGP-LS* > > *BGP IP/VPN/EVPN* > > End (PSP, USP, USD) > > X > > X > > End.X (PSP, USP, USD) > > X > > X > > End.T (PSP, USP, USD) > > X > > X > > End.DX6 > > X > > X > > X > > End.DX4 > > X > > X > > X > > End.DT6 > > X > > X > > X > > End.DT4 > > X > > X > > X > > End.DT46 > > X > > X > > X > > End.DX2 > > X > > X > > End.DX2V > > X > > X > > End.DT2U > > X > > X > > End.DT2M > > X > > X > > End.B6.Encaps > > X > > End.B6.Encaps.Red > > X > > End.B6.BM > > > > As you can see, some service SIDs can be signaled only using BGP (with > AFI/SAFI L2VPN/EVPN) while some may be signaled either using BGP with SAFI > 128 or with IGP. > > > > BGP-LS signaling is not related to my question. > > > > RFC 9252 <https://datatracker.ietf.org/doc/html/rfc9252> defines > signaling of all marked types of Service SIDs using MP-BGP. This signaling > advertises SRv6 Service SIDs that are locally instantiated by an egress PEs > of a given service since to appropriate ingress PEs while using Route > Targets-based control of advertisement. > > > > I am not aware of any work that advertises SRv6 Service SIDs in IGP. > > > > With this background, I can now re-formulate my question as following: > > > > *Is the draft we are discussing limited to egress protection of SRv6 SIDs > with just the following endpoint behaviors: End, End.X and End.T?* > > > > Hopefully, these notes will help to understand my question. > > > > Regards, > > Sasha > > > > *From:* 何涛(联通集团本部) <[email protected]> > *Sent:* Tuesday, July 22, 2025 7:07 AM > *To:* Alexander Vainshtein <[email protected]> > *Cc:* rtgwg <[email protected]> > *Subject:* [EXTERNAL] Re: [rtgwg] My question about > draft-ietf-rtgwg-srv6-egress-protection-19 > > > > Hi Vainshtein, > > In this draft, what we propose is a protection scheme for egress nodes. > The egress nodes are located at the edge of the network, and in most > scenarios of the current network, they are within an AS. If we consider the > scheme for remote BGP convergence , the delay would be extremely high，and > it is nonsense in this scheme. Therefore, we did not extend the BGP > protocol. > > > > If you have met the necessary scenario about BGP protocol here, welcome > discussion, thank you! > > =============================================== > > Tao He > Next Generation Internet Research Department > > Research Institute > CHINA UNITED NETWORK COMMUNICATIONS CORPORATION LIMITED > > Mobile: +86-18618484923 > E-mail: [email protected] > > > > *From:* Alexander Vainshtein > <[email protected]> > > *Date:* 2025-07-21 21:37 > > *To:* RTGWG <[email protected]> > > *Subject:* [rtgwg] My question about > draft-ietf-rtgwg-srv6-egress-protection-19 > > 【本邮件为外部邮件，请注意核实发件人身份，并谨慎处理邮件内容中的链接及附件】 > > Hi all, > > I have asked the following question about the SRv6 Path Egress Protection > draft > <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-srv6-egress-protection-19> > at the RTGWG session in Madrid today: Is the draft applicable to > BGP-advertised SRV6 Service SIDs defined in RFC 9252 > <https://datatracker.ietf.org/doc/html/rfc9252>? > > > > My guess (FWIW) that this is not so. This guess is based on the fact that > service SIDs are advertised by BGP while IGP simply is not aware of them > and, therefore, cannot distribute any related information. (Specifically, > router P1 in Figure 1 of the draft does not have to be a BGP speaker and > therefore would not be aware of these SIDs) . > > > > If my guess is correct, then from my POV: > > · The added value of the draft is quite limited > > · The draft should explicitly state to which types of SIDs (mode > SIDs? Adj-SIDs) egress protection is provided. > > > > Regards, > > Sasha > > > > > > *Disclaimer* > > This e-mail together with any attachments may contain information of > Ribbon Communications Inc. and its Affiliates that is confidential and/or > proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without > express permission is strictly prohibited. If you are not the intended > recipient, please notify the sender immediately and then delete all copies, > including any attachments. > > _______________________________________________ > rtgwg mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected]
