Hi Changwang,
Thank you for the detailed reviews. All five points have been addressed in
the new version. Our detailed responses are below.
1) Management configuration section and YANG -- agreed and added.
The draft now contains a new Section 8 "Management and
Configuration
Considerations" (configurable items on the protector, consistency
checks
against the IGP database, scale and flooding impact, operational
state,
access control, and the relationship to locator configuration) and
a YANG
module "ietf-srv6-mirror-sid" in the Yang Data Model, with the
corresponding registration in Section 9.4.
To avoid duplicating normative text across documents,
mechanism-level
operational guidance (protector selection and consolidation,
per-service
forwarding behavior acquisition, retention at the PLR,
applicability
limits) remains in draft-ietf-rtgwg-srv6-egress-protection, and
this
document only references it.
2) BGP-LS extensions -- agreed and added.
A new Section 7 "BGP-LS Considerations" describes how the Mirror
SID is
carried by the existing BGP-LS SRv6 SID information (RFC 9514), and
defines a new BGP-LS TLV, "SRv6 Mirror SID Protected Locators"
(TBD3),
carried as a sub-TLV of the SRv6 SID Information TLV. The
corresponding
code point request is in Section 9.3.
3) IS-IS Protected Locators sub-TLV exceeding 255 -- clarified.
Section 4.2 now states the size limits explicitly (a single
sub-sub-TLV
cannot exceed 255 octets; within one SRv6 End SID sub-TLV at most
234 octets remain for sub-sub-TLVs) and specifies the overflow
behavior:
the Protected Locators sub-sub-TLV is not fragmented; instead the
protector MUST advertise the same Mirror SID in more than one SRv6
End SID
sub-TLV, each carrying exactly one Protected Locators sub-sub-TLV,
and a
receiver MUST merge the locators from all such sub-TLVs. Silent
truncation
is prohibited. Section 5.2 gives the corresponding OSPFv3 rules,
where the
binding constraints are the LSA length (65535 octets) and the link
MTU,
as OSPFv3 does not define fragmentation/reassembly of a single LSA.
4) Sections 4.1 and 5.1 -- revised.
Since this document no longer defines a new sub-TLV, the section
titles
were changed to "IS-IS/OSPFv3 Advertisement of the Mirror SID in
the
SRv6 End SID sub-TLV", and the field descriptions were updated so
that
they are described as the fields of the reused SRv6 End SID
sub-TLV.
5) "The SRv6 End SID sub-TLV MUST be ignored if the endpoint behavior is
not 74" -- corrected.
You are right: the SRv6 End SID sub-TLV is shared by all
endpoint behaviors,
so it must not be ignored merely because of one behavior
value. The text now
says that a sub-TLV whose Endpoint Behavior is not 74 is
simply not a
Mirror SID advertisement and MUST be processed as a
normal
SRv6 End SID advertisement as defined in RFC 9352/9513; the
"ignore" constraint is placed on the Protected Locators
sub-(sub-)TLV,
which is only meaningful when the Endpoint Behavior of the parent
sub-TLV
is 74.
Thanks again for the careful review. Please let us know if anything
else needs clarification.
Best Regards,
Tao He
------------------ Original ------------------
From: "linchangwang"<[email protected]>;
Date: Fri, Sep 11, 2026 02:51 PM
To: "Acee Lindem"<[email protected]>; "lsr"<[email protected]>;
Cc: "rtgwg"<[email protected]>;
"draft-he-lsr-srv6-mirror-sid-igp"<[email protected]>;
Subject: [Lsr] Re: WG Adoption for "IGP Encoding for SRv6 Mirror SID in
Egress Protection" - draft-he-lsr-srv6-mirror-sid-igp-encoding-01
Hi WG,
Support its adoption.
Some comments are as follows:
1. It is recommended to add a management configuration section and include
YANG. Additionally, configuration considerations should be added in the
management section.
2. For the TLVs expanded in this document, it is recommended to add
corresponding BGP-LS extensions.
3. Regarding the handling of the ISIS Protected Locators sub-TLV when it
exceeds 255, it is recommended to clarify this in the document. If TLV
fragmentation is supported, it should also be described.
4. Currently, only the Protected Locators sub-TLV has been added. It is
recommended to revise the descriptions in Sections 4.1 and 5.1 accordingly.
5. Since the IS-IS SRv6 Mirror SID TLV has not been added, and the SRv6 End SID
sub-TLV is reused instead, the following description is incorrect:
"The SRv6 End SID sub-TLV MUST be ignored if the endpoint behavior is not
74." The behavior of the parent TLV should be specified in the Protected
Locators sub-sub-TLV.
Thanks,
Changwang
发件人: Acee Lindem <[email protected]>
发送时间: 2026年8月31日 23:37
收件人: lsr <[email protected]>
抄送: rtgwg <[email protected]>;
[email protected]
主题: [Lsr] WG Adoption for "IGP Encoding for SRv6 Mirror SID in Egress
Protection" - draft-he-lsr-srv6-mirror-sid-igp-encoding-01
LSR WG,
For some time now, the RTGWG has been working on the working group document
SRv6 Path Egress Protection - "draft-ietf-rtgwg-srv6-egress-protection-25".
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-srv6-egress-protection/
Recently, the IGP encodings for this SRv6 egress protection have been split out
into a separate LSR draft, "IGP Encoding for SRv6 Mirror SID in Egress
Protection" - draft-he-lsr-srv6-mirror-sid-igp-encoding-01.
https://datatracker.ietf.org/doc/draft-he-lsr-srv6-mirror-sid-igp-encoding/
We now intend to adopt this IGP encoding document "IGP Encoding for SRv6 Mirror
SID in Egress Protection" - draft-he-lsr-srv6-mirror-sid-igp-encoding-01, as an
LSR WG document so the RTGWG document can be progressed.
Please indicate your support or objection to adoption to this list by Tuesday,
September 15th, 2026.
Thanks,
Acee
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出的个人或群组。
禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。
如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from New H3C,
which is intended only for the person or entity whose address is listed above.
Any use of the information contained herein in any way (including, but not
limited to, total or partial disclosure, reproduction, or dissemination) by
persons other than the intended recipient(s) is prohibited.
If you receive this e-mail in error, please notify the sender by phone or email
immediately and delete it!
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
