Re: [Idr] [OPS-DIR] Opsdir early review of draft-ietf-idr-sr-policy-safi-01 (valid -02)

[Susan Hares <[e-mail]>]

4 Issues that were brought up in the OPS-DIR review
on draft-ietf-idr-sr-policy-safi-01need to be addressed:

Link to OPS-DIR Review:
https://mailarchive.ietf.org/arch/msg/ops-dir/JFInEGfu1GpIgTuCTWsNMJbGwp0/

Issue 1: Issue 1: SR Policy traversing RRs
Comment from OPS-DIR:
Nagendra Kumar:
/An SR Policy intended only for the receiver will, in most cases, not
traverse any Route Reflector (RR, [RFC4456])./


Ketan> That is for BGP VPN services. This is a different SAFI.

Nagendra Kumar: Or is this statement only applicable for the PCE-PE scenario?.  Can you clarify the same?

Ketan:  Yes, there is further text in the section that describes the same.
Since this is a BGP spec, the term "controller" is used as opposed to PCE
which is construed by many as a PCEP construct.
Shepherd request:  Would you send the section #?
I've created a github repository for this draft.
https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/

I'll add the answer to Issue 1 for this draft.

Issue 2: Shepherd's comment on section 2.1 based on OPS-DIR Review:
Change requested: Based on the question from Nagrenda, please add some link to section 2.9 in section 2.1 and 4.2.2.
that indicates if two routes of the same (RD, E, C) from different peers choose the active Policy based on
Text in section 2.1:
Current text:/ If BGP has installed into the BGP table two advertisements whose respective
NLRIs have the same color and endpoint, but different distinguishers,
both advertisements are passed to the SRPM as different candidate
paths along with their respective originator information (i.e., ASN
and BGP Router-ID) as described in section 2.4 of [RFC9256]. The ASN
would be the ASN of the origin and the BGP Router-ID is determined in
the following order:

  *   From the Route Origin Community [RFC4360] if present and carrying
an IP Address, or
  *   As the BGP Originator ID [RFC4456] if present, or
  *   As the BGP Router-ID of the peer from which the update was
received as a last resort./
Suggested addition after last line:/
Section 2.9 of [RFC9256] indicates how an Active SR Policy is
selected based on the information passed to the SRPM. /
Text in Section 4.2.2:/
The SRPM applies the rules defined in section 2 of [RFC9256] to
determine whether the SR Policy candidate path is valid and to select
the best candidate path among the valid ones for a given SR Policy./

Suggested addition after last line:/
The best candidate path is denoted as the "active candicate path"
(see section 2.9 of [RFC9256]). /

Issue #3: Error Handling of Binding SID - Shepherd's comment

Nagendra Kumar: What happens if a node receives the SR Policy NLRI with the length field of
the Binding SID Sub-TLV set to 6 and the label value from the reserved range
(0-15 may be)?

Ketan: (KT)  That is handled by the SRPM and outside the scope of BGP. In this
specific case, the specified BSID is not usable/available and the behavior
is covered by section 6.2 of RFC9256.

Shepherd's review:

[RFC9252] in section 6.2 neither confirms nor denies whether the MPLS reserved labels are usable.



2.4.2 needs to be augmented to indicate this point in the paragraph on Binding SID:.

**Addition after the last sentence, if it cannot contain reserved MPLS label values.

     / The Label field is validated by the SRPM, but MUST not contain the reserved MPLS label values (0-15). /

If it can contain the reserved MPLS labels, then this needs to be clearly spelled out.

     / The Label field is validated by the SRPM, but SHOULD not contain the reserved MPLS label values (0-15).

        An implementation MAY have knobs that allow these labels./


Shepherd's comment:
Issue 4: Why does Section 2.4.2 Use alternate way to SRv6 BSID - Shepherd's review



Question:
--> Section 2.4.3 describes the Sub-TLV for SRv6 BSID. Any reason why section 2.4.2 includes a length field and describes another way to represent SRv6 BSID?

KT answer:

KT> Section 2.4.2 specifies the SR BSID sub-TLV that was used for both
SR-MPLS and SRv6. But it was defined during the early stages of SR
evolution and did not cover the SRv6 aspects fully and hence the SRv6 BSID
sub-TLV was introduced in section 2.4.3. For backward compatibility with
existing implementations, the use of SR BSID sub-TLV for SRv6 was retained
(with a reduced functionality).

Shepherd review:
This question will repeatedly arise from implementers or operators.
Please put a short version of this explanation in the text.

I suspect it might be best in the 2.4 section overview prior to 2.4.1.