Hi,
I support the publication of draft. It provides a clear guidance on how to
fulfill the private line service requirements leveraging (most of) the
existing tools.
And below are the comments after reading the draft.
Best Regards,
Yao
Comment a
6.1 Unprotected
When using BGP, a BGP-LS update with a SR Policy Candidate Path NLRI is
sent from the endpoint to the centralized controller having
C flag set to 1 to indicate the candidate path was provisioned by the
controller
A flag set to 1 to indicate the candidate path is active and carrying
traffic
[Yao] There're a few TLVs in the SR Policy Candidate Path NLRI having the flag
field. It's more precise to point out which TLV is it.
For the context, the C flag and A flag mentioned above belongs to SR Candidate
Path State TLV, and would be "C-Flag" and "A-Flag".
similar comments for other sections when mentioning the flags fields in BGP-LS
update with a SR Policy Candidate Path NLRI.
Comment b
5.3. Maximum Segment Depth
"A Segment Routed path defined by a segment list is constrained by maximum
segment depth (MSD), which is the maximum number of segments a router can
impose onto a packet."
[Yao] There're many types of MSDs
(https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-msd-types),
to be more precise, it is the "Base MPLS Imposition MSD"(for MPLS) and "SRH
Max H.encaps"(for SRv6) that represents the maximum number of segments a router
can impose onto a packet.
And MSD is short for "Maximum SID Depth" instead of "Maximum Segment Depth".
Comment c
Same with the comment from Himanshu in
https://mailarchive.ietf.org/arch/msg/spring/e8Gt3_oy6Y8yoI2mJ5W8WBXlh0A/.
Some guidance would be helpful on how to operate after one segment list has
been failed when a CP with multiple segment lists is used for traffic
transmition.
comment d
5.1. Policy Creation when using PCEP
Both nodes A and Z act as PCC and delegate path computation to the PCE using
PCEP with the extensions defined in [RFC8664] and the procedure described in
Section 5.7.1 of [RFC8231].
[YAO] [RFC8664] is referenced here for SR-MPLS when creating Policy using PCEP.
But [RFC9603] should be added for SRv6.
comment e
The use of the term "endpoint" in this document may cause some misunderstanding.
"endpoint" has two meanings, one is the destination of the SR policy in
RFC9256, another is the endpoint of the protocol (PCEP/BGP) connections (e.g,
the node communicates with the controller, the headend of the SR Policy). And
this document uses both as shown below. It would be better to distinguish these
two types of "endpoint" literally.
Section 3
"When using PCEP as the communication protocol on the endpoints, the
centralized entity is a stateful PCE defined in [RFC8231]."
------endpoint meaning 2
Section 5.1
"Considering the scenario illustrated in Figure 1 a CS-SR policy between A
and Z is configured both on A (with Z as endpoint) and Z (with A as endpoint)."
------endpoint meaning 1
Section 5.2
"The endpoints A and Z report the SR-policy states back to the centralized
controller via BGP-LS using the extension defined in
[I-D.ietf-idr-bgp-ls-sr-policy]."
------endpoint meaning 2
Comment f
The documents listed for reference should be updated to the lastest status,
such as
1) draft-ietf-idr-segment-routing-te-policy has been replaced by
draft-ietf-idr-sr-policy-safi
2) draft-ietf-lsr-ospfv3-srv6-extensions ----> RFC9513
3) draft-ietf-lsr-isis-srv6-extensions ----> RFC9352
4) draft-ietf-spring-segment-routing-policy--->RFC9256
Original
From: JoelHalpern <j...@joelhalpern.com>
To: SPRING WG List <spring@ietf.org>;
Date: 2025年02月06日 23:51
Subject: [spring] Extending WG last call for draft-ietf-spring-cs-sr-policy
My thanks to the non-editorial participants who have spoken up in
support of this draft. While we have not seen any objections, support
still is a bit less than the the chairs feel can be called WG support.
Given that recent notes from participants, rather than declaring failure
we are going to give this till then end of next week (i.e. end of day on
Feb 14, 2025) for additional folks to speak up in support. Or, if you
missed this and have concerns, please raise those.
I also want to thank the supporters for being explicit about why they
are supporting publication. It is quite helpful to the chairs.
Yours,
Joel
_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
