[Idr] draft-ietf-idr-sr-te-policy-attr-00

[Susan Hares <[e-mail]>]

Yao, Shaofu, and Gyan:

Thank you for your hard work on draft-ietf-idr-sr-te-policy-attr-0.txt

Below you will find a shepherd review of draft-ietf-idr-sr-te-policy-attr-00.txt.

Just a warning, we will be discussing the preliminary allocations during
IDR interim on September 9th, 2024.

It appears that we have Segment lists (L, M, N, O) clashing with the
Path Segment, Reserve Path segment, Metric, and Segment List Identifier.
I think I should reassign Path Segment, Reserve Path segment, Metric,
and Segment List Identifier to a different TLV range (30+).

Let me know what you think about this change.
As part of the status for the September 9th, 2024 meeting,
Please let me know:


  1.  Are you planning any technical changes to this draft?
  2.  Do you have implementations?
  3.  Are you ready for WG LC?

Cheerily, Sue Hares


Shepherd report for draft-ietf-idr-sr-te-policy-attr

Status: WG draft
implementations: unknown
allocation status: preliminary (upcoming issue)
WG LC status: unknown


Technical:
Issue-1: Section 3.1, SR Algorithm text, A-Flag setting

old text:/
   SR Algorithm: 1 octet specifying SR Algorithm as described in
   Section 3.1.1 of [RFC8402]) when A-Flag as defined in
   [I-D.ietf-idr-bgp-sr-segtypes-ext] is present.  SR Algorithm is used
   by SRPM as described in Section 4 of [RFC9256]).  When A-Flag is not
   encoded, this field SHOULD be set to zero on transmission and MUST be
   ignored on receipt./
New text:/
   SR Algorithm: 1 octet specifying SR Algorithm as described in
   Section 3.1.1 of [RFC8402]) when A-Flag as defined in
   [I-D.ietf-idr-bgp-sr-segtypes-ext] is present.  SR Algorithm is used
   by SRPM as described in Section 4 of [RFC9256]).  When A-Flag is not
   set, this field SHOULD be set to zero on transmission and MUST be
   ignored on receipt./

Issue-2, Section 3.2, SR algorithm text, A-Flag setting.

Make the same chnage as in section 3.1

Issue-3, Section 3.3, SR algorithm text, A-Flag setting.

Make the same chnage as in section 3.1

Issue-3, Section 3.4, SR algorithm text, A-Flag setting.

Make the same chnage as in section 3.1



Editorial:

NIT-1, SEction 1, paragraph 2, sentence 1

Old text:
  [I-D.ietf-idr-sr-policy-safi] specifies the way to use BGP to
   distribute one or more of the candidate paths of an SR Policy to the
   headend of that policy.

New text:/
  [I-D.ietf-idr-sr-policy-safi] specifies the way to use BGP to
   distribute information about one or more of the candidate paths of an SR Policy to the
   headend of that policy. /


NIT-2: setion 1, paragraph 5, sentence 1
old text:/
[I-D.ietf-lsr-algorithm-related-adjacency-sid] complements that,
   besides the SR-MPLS prefix SID, the algorithm can be also included as
   part of an SR-MPLS Adjacency-SID advertisement, in scenarios where
   multiple algorithm share the same link resource. /

new text:/
[I-D.ietf-lsr-algorithm-related-adjacency-sid] comments that,
   besides the SR-MPLS prefix SID, the algorithm can be also included as
   part of an SR-MPLS Adjacency-SID advertisement in scenarios where
   multiple algorithm share the same link resource. /


 NIT-3: SEction 3.1, sentence 1, editorial
 Old text:/
    This type allows for identification of an Adjacency SID or BGP Peer
   Adjacency SID (as defined in [RFC8402] ) SR-MPLS label for point-to-
   point links including IP unnumbered links/

 first suggestion:/
     This type allows for identification of an Adjacency SID or BGP Peer
   Adjacency SID (as defined in [RFC8402] ) as an SR-MPLS label for point-to-
   point links including IP unnumbered links/

   comment; Are you trying to use an SR-MPLS label as an Adjacency SID or
   a BGP Peer Adjaency SID or something else?  Please reword the sentence.