[rtgwg] Re: Scalability issues in draft-ietf-rtgwg-srv6-egress-protection?

["何涛(联通集团本部)" <[e-mail]>]

Hi Sasha,
     First of all,  I would like to sincerely thank you for the questions you raised regarding this draft.
     Based on your reply, we have revisited the solution in the draft under the scenario you provided. In the scenario you mentioned, i.e., the random multiple-homing PE scenario, PE3 protects PE2's VRF1 and PE4 protects PE2's VRF2. In this case, PE3 and PE4 need to send two different LSPs to P1. As the number of nodes protecting PE2 increases, and the number of VRFs increases (i.e., PEn protecting PE2's VRFn), there will be at least N LSP floods. This logic is correct.
       But we think, in typical network configurations, we usually adopt a regular deployment approach. That is, when PE3 protects PE2, the different VRFs are generally on both PE3 and PE2. In other words, most of the different CEs are dual-homed to both PE3 and PE2. In this case, only one <PE3-locator, PE2-locator, Mirror ID> is loaded onto the LSP and sent to P1. For the previously mentioned random multiple-homing scenario, we still need to protect it using the <PE3-vrf-SID, PE2-vrf-SID, Mirror ID> method, but this situation is not common.
        Therefore, in the real-world application, we can ensure that there will not be a large-scale LSP flood by configuration. Thus, the solution proposed in the draft is practical.
        Whether there are any omissions in my reply?   I sincerely look forward to your response. Thank you!
===============================================
Tao He
Next Generation Internet Research Department
Research Institute
CHINA UNITED NETWORK COMMUNICATIONS CORPORATION LIMITED
Mobile: [phone]
E-mail: [e-mail]
 
·¢¼þÈË£º Alexander Vainshtein
·¢ËÍʱ¼ä£º 2025-11-08 16:04
ÊÕ¼þÈË£º ºÎÌÎ(ÁªÍ¨¼¯Íű¾²¿); Huzhibo
³­ËÍ£º draft-ietf-rtgwg-srv6-egress-protection; rtgwg; lsr
Ö÷Ì⣺ Re: [EXTERNAL] Re: RE: Scalability issues in draft-ietf-rtgwg-srv6-egress-protection?
¡¾±¾ÓʼþΪÍⲿÓʼþ£¬Çë×¢ÒâºËʵ·¢¼þÈËÉí·Ý£¬²¢½÷É÷´¦ÀíÓʼþÄÚÈÝÖеÄÁ´½Ó¼°¸½¼þ¡¿
Hi Tao He,
I have found your response dated 20-Sep-25 in mail mailbox.
My sincere apologies for missing it then.

In your response you have proposed advertising in IGP service instance-specific information required for protection - copying from your response:

In this scenario, the P router receives two pieces of information: <PE3, PE2-vrf1, Mirror ID1> and <PE4, PE2-vrf2, Mirror ID2>.

This indeed would address the problem of protection in the scenarios in which different service instances in the same primary egress PE are protected by different backup PEs -  but this would also potentially result in the scalability issue I have raised in the original email of this tread: each backup PE in the IGP domain would advertise this information for each service instance for which it acts as the backup PE (potentially thousands of instances), and IGP would flood this information to all the routers that participate in the corresponding IGP instance. 

Just to remind you, your original response to the scalability issue has been that backup PE does not advertise service instance-specific information.

It seems that your response from 20-Sep-25 and your response from 06-Nov-25 are mutually contradictive.

My 2c,
Sasha
 

Get Outlook for Android



From: ºÎÌÎ(ÁªÍ¨¼¯Íű¾²¿) <[e-mail]>
Sent: Friday, November 7, 2025 3:25:25 AM
To: Alexander Vainshtein <[e-mail]>; Huzhibo <huzhibo=[e-mail]>
Cc: draft-ietf-rtgwg-srv6-egress-protection <[e-mail]>; rtgwg <[e-mail]>; lsr <[e-mail]>
Subject: [EXTERNAL] Re: RE: Scalability issues in draft-ietf-rtgwg-srv6-egress-protection?

Hi Sasha:
      Thanks  for your reply again very much.
      I had sent your an email to reply  the scenario  on 20th September 2025,   you can check the mailbox,  and I paste the screenshot  below. 
If the reply was not clear, please tell me,  I am pleasure to expand it deeply, thank you.





===============================================
Tao He
Next Generation Internet Research Department
Research Institute
CHINA UNITED NETWORK COMMUNICATIONS CORPORATION LIMITED
Mobile: [phone]
E-mail: [e-mail]
 
From: Alexander Vainshtein
Date: 2025-11-06 17:13
To: Huzhibo; ºÎÌÎ(ÁªÍ¨¼¯Íű¾²¿)
CC: [e-mail]; rtgwg; [e-mail]
Subject: RE: Scalability issues in draft-ietf-rtgwg-srv6-egress-protection?
¡¾±¾ÓʼþΪÍⲿÓʼþ£¬Çë×¢ÒâºËʵ·¢¼þÈËÉí·Ý£¬²¢½÷É÷´¦ÀíÓʼþÄÚÈÝÖеÄÁ´½Ó¼°¸½¼þ¡¿
Dear all,
Responding to two similar answers I have received to my email.
 
I fully agree that the draft, as written,  does not require advertisement of VPN-specific SIDs.
But this is only possible because the draft implicitly assumes that all protected VPN services instantiated in a given primary egress PE are protected by the same backup egress PE.
To the best of my understanding, this assumption is not explicitly stated anywhere in the draft, even if Figure 1 in Section 3.1 (copied below for your convenience) of the draft is aligned with this assumption: CE-2 and CE-3are dual-homed to the same (Primary, Backup) pair of egress PEs.
 
 
 
            *******  *******SIDa
        [PE1]-----[P1]-----[PEA]---[CE2]    PEA Egress
        / |        |&        | \   /        PEB Backup Egress
       /  |        |&        |  \ /         CEx Customer Edge
  [CE1]   |        |&        |   X          Px  Non-Provider Edge
       \  |        |&        |  / \         *** SR Path
        \ |        |& &&&&&  | /   \        &&& Backup Path
        [PE2]-----[P2]-----[PEB]---[CE3]
                        Mirror SID
 
On 16-Sep-25 I have send you an email  with a simple example in which the highlighted implicit assumption is broken. Unfortunately, until now I have not received any responses to this email, so I resend my example now:
 
The network diagram fort the example is embedded below..
 
 
 
 
In this diagram there are 2 different IP-VPN service instances running on top of SRv6:
The "yellow" service is instantiated in PE-1, PE-2 and PE-3
CE-1-23 is dual-homed to PE-2 and PE-3
PE-2 Primary and PE-3 is backup (Protector)
The "blue" service is instantiated in PE-1, PE-2 and PE-4
CE-2-24 is dual-homed to PE-2 and PE-4
PE-2 is Primary and PE-4 is backup (Protector)
Both services use the best effort paths, so that the packets sent by PE-1 carry only SRv6 SIDs allocated by PE2 for the "yellow" and "blue" service instances respectively. These SIDs carry include the same Locator part (The locator of PE2) but different functions.
SRv6 service SIDs are locally allocated and advertised using MP-BGP
The P router:
Is on the shortest IGP path from PE1 to PE2
Is aware of thePE2 locator and of its penultimate role for this locator
Is directly connected to PE2 so that it detects failure of PE2 as the failure of the corresponding link
Is not a BGP speaker so that it is not aware of the service SIDs allocated by PE2 (not required in the draft)
When PE2 fails, an egress protection mechanism (if it is implemented in the P router) must differentiate between the "yellow" and "blue" packets:
The former should be re-routed to PE3 with the appropriate "mirror" SID
The latter should be re-routed to PE-4 with the appropriate "mirror" SID.
 
I do not see how egress protection against PE2 failure  could be achieved by the mechanism defined in the draft in the above scenario.
In order to provide such protection, the PLR MUST be aware of each specific "service" SID advertised by Primary PE
If such awareness is provided by IGP, this can results in the scale issue I have mentioned.
 
What, if anything, do I miss?
 
For the reference, RFC 8679 provides an answer for this scenario.
 
Hopefully, these notes clarify
 
Regards,
Sasha
 
From: Huzhibo <huzhibo=[e-mail]>
Sent: Thursday, November 6, 2025 3:11 AM
To: Alexander Vainshtein <[e-mail]>; [e-mail]
Cc: rtgwg <[e-mail]>; [e-mail]
Subject: [EXTERNAL] RE: Scalability issues in draft-ietf-rtgwg-srv6-egress-protection?
 
Hi Sasha:
 
This document does not introduce the status of each VPN into the IGP; instead, it introduces the status of VPN protection groups. For a pair of PEs, regardless of how many multi-homed VPNs there are, only one Mirror SID will be advertised. Therefore, this will not cause scalability issues for the IGP
 
Thanks
 
Zhibo
 
From: Alexander Vainshtein [mailto:Alexander.Vainshtein=[e-mail]]
Sent: Wednesday, November 5, 2025 7:53 PM
To: [e-mail]
Cc: rtgwg <[e-mail]>; [e-mail]
Subject: [Lsr] Scalability issues in draft-ietf-rtgwg-srv6-egress-protection?
 
Hi all,
I have looked up the -20 revision of the draft, and I see that it explicitly mentions (e.g., in Section 3.1.1 in Section ) protection for SRv6 "service" SIDs as defined in RFC 9252.
 
It I my understanding that the information about protection provided for such SIDs is distributed within the IGP domain by an appropriate link-state IGP (IS-IS or OSPF) ¨C at least, no other way of distributing such relationships to the potential PLR is not defined in the draft.
 
From my POV this raises a serious scalability concern about the proposed solution, since, potentially, a huge amount of information would be flooded by IGP to all the nodes in the IGP domain. This consideration is not relevant about "topological" SIDs since these are part of the topology natively learned and advertised by any link-state IGP.  In particular, IGP convergence times may be seriously affected due to the need to redistribute this information.
 
But "service" SIDs are normally distributed only to the PEs that participate in the service, and their number may exceed the number of links and nodes in the given IGP domain by an order of magnitude.
 
For comparison, RFC 8679 explicitly requires a session of the service label distribution protocol between the PLR and the protected egress PE, and RFC 8104 describes in detail how (targeted) LDP can be used to distribute this information in the case of PW-based services.
 
Hopefully these notes will be useful.
 
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.