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: 何涛(联通集团本部) <he...@chinaunicom.cn>
Sent: Tuesday, July 22, 2025 11:05 AM
To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>
Cc: rtgwg <rtgwg@ietf.org>; draft-ietf-rtgwg-srv6-egress-protection.authors
<draft-ietf-rtgwg-srv6-egress-protection.auth...@ietf.org>
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: he...@chinaunicom.cn<mailto:he...@chinaunicom.cn>
From: Alexander Vainshtein<mailto:alexander.vainsht...@rbbn.com>
Date: 2025-07-22 15:31
To: 何涛(联通集团本部)<mailto:he...@chinaunicom.cn>
CC: rtgwg<mailto:rtgwg@ietf.org>;
draft-ietf-rtgwg-srv6-egress-protection.auth...@ietf.org<mailto:draft-ietf-rtgwg-srv6-egress-protection.auth...@ietf.org>
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: 何涛(联通集团本部) <he...@chinaunicom.cn<mailto:he...@chinaunicom.cn>>
Sent: Tuesday, July 22, 2025 7:07 AM
To: Alexander Vainshtein
<alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>>
Cc: rtgwg <rtgwg@ietf.org<mailto:rtgwg@ietf.org>>
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: he...@chinaunicom.cn<mailto:he...@chinaunicom.cn>
From: Alexander
Vainshtein<mailto:Alexander.Vainshtein=40rbbn....@dmarc.ietf.org>
Date: 2025-07-21 21:37
To: RTGWG<mailto:rtgwg@ietf.org>
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 -- rtgwg@ietf.org
To unsubscribe send an email to rtgwg-le...@ietf.org
