Hi Yingzhen,
Lots of thanks for your email.
Please see some comments/questions inline below.
"The preultimate node will first detect the interface down and trigger the PLR
behavior."
Can you please elaborate how this is done? Is this the same as "the IGP
converges" and "the mirroring protection behavior should be triggered"?
If the repair, switching to the backup path, can only happen after IGP
converges, the value of this repair seems to be limited.
In an SRv6 network, nodes typically run the BFD protocol to quickly detect link
failures. In this scenario, when the penultimate hop node P1 detects a failure
with the egress node PEA or its connected interface, BFD will quickly notify
P1, enabling it to respond promptly. Moreover, due to the use of "the mirroring
protection" function, P1 will have a backup path prepared before the failure
occurs. Therefore, when the failure happens, there is no need to wait for the
completion of IGP convergence.
Also for "Any node can be a PLR without distinction.", theoretically any node
can be penultimate end node, does it mean all routers should calculate backup
paths?
Although any node can act as a PLR, not every node needs to calculate a backup
path. In practical deployment, nodes directly connected to the egress node are
usually chosen as PLRs because these nodes can quickly detect failures and
perform repairs. Other nodes can also serve as PLRs, but their failure
detection speed will be relatively slower, hence their priority for calculating
backup paths will be lower.
If the repair only happens after IGP converges, why not just switch from the
ingress router?
According the
Based on the above description, the repair based on the "mirror id tlv" occurs
before IGP convergence.
Thanks！
Tao
===============================================
Tao He
Next Generation Internet Research Department
Research Institute
CHINA UNITED NETWORK COMMUNICATIONS CORPORATION LIMITED
Mobile: +86-18618484923
E-mail: [email protected]
From: Yingzhen Qu
Date: 2025-09-13 05:36
To: 何涛(联通集团本部)
CC: rtgwg; draft-ietf-rtgwg-srv6-egress-protection.authors; Alexander.Vainshtein
Subject: Re: [rtgwg] Re: My question about
draft-ietf-rtgwg-srv6-egress-protection-19
【本邮件为外部邮件，请注意核实发件人身份，并谨慎处理邮件内容中的链接及附件】
Hi Tao,
Thanks for the reply.
"The preultimate node will first detect the interface down and trigger the PLR
behavior."
Can you please elaborate how this is done? Is this the same as "the IGP
converges" and "the mirroring protection behavior should be triggered"?
If the repair, switching to the backup path, can only happen after IGP
converges, the value of this repair seems to be limited.
Also for "Any node can be a PLR without distinction.", theoretically any node
can be penultimate end node, does it mean all routers should calculate backup
paths? If the repair only happens after IGP converges, why not just switch from
the ingress router?
Thanks,
Yingzhen
On Fri, Sep 12, 2025 at 2:07 AM 何涛(联通集团本部) <[email protected]> wrote:
Hi Yingzhen,
Any node can be a PLR without distinction. When the egress node fails,
this path will not be deleted from the network yet. The preultimate node will
first detect the interface down and trigger the PLR behavior. Subsequently, as
the IGP converges, the egress node's Locator becomes unreachable. At the
sametime, the mirroring protection behavior should be triggered. Finally, the
VPN route converges, and the protection is completed.
Thanks！
Tao
===============================================
Tao He
Next Generation Internet Research Department
Research Institute
CHINA UNITED NETWORK COMMUNICATIONS CORPORATION LIMITED
Mobile: +86-18618484923
E-mail: [email protected]
From: Yingzhen Qu
Date: 2025-09-12 05:55
To: Alexander Vainshtein
CC: 何涛(联通集团本部); rtgwg; draft-ietf-rtgwg-srv6-egress-protection.authors
Subject: Re: [rtgwg] Re: [EXTERNAL] Re: My question about
draft-ietf-rtgwg-srv6-egress-protection-19
【本邮件为外部邮件，请注意核实发件人身份，并谨慎处理邮件内容中的链接及附件】
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
<[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
Date: 2025-07-22 15:31
To: 何涛(联通集团本部)
CC: rtgwg; [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 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 defines a IANA registry of SRv6 Endpoint
behaviors.
Table 3 in Section 8.4 of the same RFC 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 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
Date: 2025-07-21 21:37
To: RTGWG
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
at the RTGWG session in Madrid today: Is the draft applicable to BGP-advertised
SRV6 Service SIDs defined in RFC 9252?
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]
