Hi Sasha,
Thank you for your thoughtful consideration.
Analysis:
We re‑checked the –20 version draft. The information used for egress
protection is not introducing each VPN’s SID for service into the IGP.
Instead, the backup egress (PEB) advertises—via IGP—a Mirror SID together with
a list of the protected egress’s locators, i.e., the protection relationship
<PEB, PEA, Mirror SID>. The PLR only needs this to compute the repair list
toward PEB and encapsulate with End.M (Mirror SID) for reroute on failure. The
per‑service forwarding behavior (e.g., VPN SIDs) can be learned by PEB via BGP
SRv6 service distribution (RFC 9252) or local configuration and programmed into
the PEA context table identified by the Mirror SID. Therefore, the IGP does not
flood per‑VPN service SIDs.
Furthermore, for a given (PEB, PEA) pair, a single Mirror SID typically
suffices, and that Mirror SID TLV can carry multiple protected locators,
covering multiple services anchored on the egress. This is fundamentally
different—and far more scalable—than per‑VPN/per‑SID flooding.
However, it would be too absolute to claim there is no IGP scalability
impact at all. The Mirror SID and the list of protected locators are still
flooded within the IGP domain (the example explicitly says every node in the SR
domain receives the LS). In topologies with a large number of protection
relationships (many distinct (PEB, PEA) pairs and many protected locators per
pair), there will still be incremental LSA/LSP size and some convergence
overhead—much smaller than per‑VPN flooding. The IS‑IS/OSPFv3 encodings also
define minimum TLV sizes, which underscores that the overhead exists but is
bounded and manageable.
Possible Solution:
1)Scope control: Keep Mirror SID advertisements within the necessary IGP
area/level (IS‑IS L1/L2 level, OSPFv3 areas) to avoid unnecessary domain‑wide
flooding.
2)Group protection: For the same (PEB, PEA) pair, aggregate multiple protected
locators under one Mirror SID wherever possible.
3)Minimize protection pairs: Prefer a single primary PEB per PEA in a given
domain; add additional PEBs only when required.
4)Control/data‑plane separation: Let IGP carry only the protection
relationship; continue to use BGP (RFC 9252) for service prefix distribution
and forwarding behaviors.
Conclusion:
The original worry—“IGP must flood a large number of per‑VPN service SIDs,
hence poor scalability”—does not apply under the –20 version design. What the
IGP carries is the protection relationship (Mirror SID + protected locators),
not every service SID. However, as the number of (PEB, PEA) relationships
grows, there is still a bounded incremental IGP cost. Following the practices
above keeps scale and convergence within acceptable limits.
Best regards,
Tao He
===============================================
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
Date: 2025-11-05 19:52
To: [email protected]
CC: rtgwg; [email protected]
Subject: [rtgwg] 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) – 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.
_______________________________________________
rtgwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
