search

ietf-wg-idr / draft-ietf-idr-sr-policy-safi

Repository for draft-ietf-idr-sr-policy-safi Issues
0 stars 0 forks source link

OPS-DIR Review Issues for -01 text #1

Open suehares opened 3 months ago

suehares commented 3 months ago

OPS-DIR Review:

https://mailarchive.ietf.org/arch/msg/ops-dir/JFInEGfu1GpIgTuCTWsNMJbGwp0/ author: Nagendra Kumar

OPS-DIR: Issue 1, Introduction

An SR Policy intended only for the receiver will, in most cases, not traverse any Route Reflector (RR, [RFC4456]).

Nagendra: Normally, it is expected to have BGP session between the PEs and the RRs. The above statement appears to give an impression that - in addition to the PE-RR session(s), does this machinery require additional/adhoc sessions between the PEs?. Or is this statement only applicable for the PCE-PE scenario?. Can you clarify the same?

OPS-DIR - Issue 2: Section 2.1, Multiple Candidate paths with same RD,

Text (Section 2.1, next to last paragraph) / It has to be noted that if several candidate paths of the same SR Policy (endpoint, color) are signaled via BGP to a headend, then it is RECOMMENDED that each NLRI uses a different distinguisher. 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].

Nagendra: What happens when the BGP receives several candidate paths for the <Color,Endpoint> but with the same distinguisher?. Will it override or the preference sub-TLV will handle it?. I was looking into the related drafts/RFCs but I am not sure if this is handled properly and would like to add here to clarify as required.

OPS-DIR Issue 3: Error Handling, Section 5

--> 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)?

OPS-DIR Issue 4: Why does Section 2.4.2 Use alternate way to SRv6 BSID

--> 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?

suehares commented 3 months ago

Issue 1: SR Policy traversing RRs

An SR Policy intended only for the receiver will, in most cases, not traverse any Route Reflector (RR, [RFC4456]).

Nagendra Nainar: Normally, it is expected to have BGP session between the PEs and the RRs. The above statement appears to give an impression that - in addition to the PE-RR session(s), does this machinery require additional/adhoc sessions between the PEs?.

Ketan (KT): That is for BGP VPN services. This is a different SAFI.

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

Ketan (KT): 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's comment: The Term controller needs to be defined or referenced in a document. RFC9256 section 4 indicates a provisioning controller.

Ketan's response to shepherd

https://mailarchive.ietf.org/arch/msg/idr/JKl-r64I-cVSg9UltovTnbLlm4w/ Ketan: I do not have a reference for the word controller and I am not sure how that term can be defined in a suitable way in this document. The draft has the following text in the Introduction section that, I believe, gives an appropriate and sufficient context for this document. Please suggest text if you feel otherwise.

Typically, a controller defines the set of policies and advertises them to policy headend routers (typically ingress routers). These policy advertisements use the BGP extensions defined in this document.

Shepherd's suggested text: Controller: A controller, in a computing context, is a hardware device or a software program that manages or directs the flow of data between two entities.

BGP Controller: An Route Reflector (RR) [RFC4456] which has a function of controlling BGP routes sent between RR (BGP) and client BGP speakers.

Provisioning BGP controller: Per [RFC9256], that BGP Controller (RR) whose additional application helps provision the Segment Routing (SR).

suehares commented 3 months ago

Issue 2: Multiple Candidate paths with same RD

Original mail: https://mailarchive.ietf.org/arch/msg/ops-dir/JFInEGfu1GpIgTuCTWsNMJbGwp0/

Original comment: It has to be noted that if several candidate paths of the same SR Policy (endpoint, color) are signaled via BGP to a headend, then it is RECOMMENDED that each NLRI uses a different distinguisher. 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].

Nagendra: What happens when the BGP receives several candidate paths for the <Color, Endpoint> but with the same distinguisher?. Will it override or the preference sub-TLV will handle it?. I was looking into the related drafts/RFCs but I am not sure if this is handled properly and would like to add here to clarify as required.

Ketan's response

https://mailarchive.ietf.org/arch/msg/ops-dir/mQPvJKgE5vJZ9gOV-QpBB94DNvM/

Ketan (KT): This is covered in RFC9256 in section 2 and more specifically the tiebreaker in section 2.9.

Shepherd: If same preference, then test higher value of protocol origin, (if config) existing path, lower originator, higher discriminator. For two BGP routes,
route 1: protocol origin: BGP, existing path, originator-1, RD:10 route 2: protocol origin: BGP, not-existing path, originator-1, RD:20 How does the network operator avoid conflict in paths of Existing path (configured) is set differently in different nodes within AS?

Nagendra's response to Ketan's comment:

(Nagendra-2): Thanks. I think I read RFC9256 before crafting my previous query and re-read the highlighted section again. I am not sure if that clarifies (or if I am confused) :).

Section 2.9 appears to discuss the tie breaker from SRPM point of view between different paths received from heterogeneous sources/protocols (BGP, PCEP, manual, etc).

As per Section 2.4 of RFC9256, When BGP is the signaling protocol, BGP will provide ASN-ID and Node-ID for the candidate paths. Once the candidates paths are with the BGP process, this draft suggests the below:

It has to be noted that if several candidate paths of the same SR Policy (endpoint, color) are signaled via BGP to a headend, then it is RECOMMENDED that each NLRI uses a different distinguisher.

Ketan's response to Nagendra's 2nd respond

Ketan (KT-2): There is no such assumption - it is simply the recommendation of how things should be done when the desire is to signal multiple CPs (say for fallback from one to the other) from the same controller via BGP.

(Nagendra-2): (continued) The above statement (from sender perspective) is followed by the processing procedure (receiver perspective) details when receiving multiple candidate paths with different distinguishers.

Ketan's response to this question: Ketan (KT-2) In this case, these are two paths for the same "route" - i.e., it is the same CP being signaled (perhaps two copies being received via two RRs). And so in this case BGP will run its bestpath and send only that bestpath to SRPM. This is covered in section 4.2.

Shepherd: How is this covered in section 4.2 of this draft? Text I found:

4.2. Reception of an SR Policy NLRI

/ On reception of an SR Policy NLRI, a BGP speaker first determines if it is valid as described in Section 4.2.1 and then performs the decision process for selection of the best route (Section 9.1 of [RFC4271]). The key difference from the base BGP decision process is that BGP does not download the selected best routes of SR Policy SAFI into the forwarding and instead considers them "usable" for passing on to the SRPM for further processing as described in Section 4.2.2. The selected best route is "propagated" (Section 9.1.3 of [RFC4271]) as described in Section 4.2.3 irrespective of its "usability" by the local router./

Considered this question closed.

suehares commented 3 months ago

Issue 2: Multiple Candidate paths with same RD - Shepherd's review

Change requested: Based on the question from Nagrenda, please add a sentence to 2.1 and 2.4 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:

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:/ The best candidate path is denoted as the "active candicate path" (see section 2.9 of [RFC9256]). /

Ketan response to shepherd's comment

KT> This text has already been updated on suggested lines in the last update. Please refer: https://www.ietf.org/archive/id/draft-ietf-idr-sr-policy-safi-04.html#section-4.2.2

Sue-2: Are you referring to this text: New text:/ 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 active candidate path for a given SR Policy./

Sue-2: OK, my suggestion was a clarification on this text. You may reject the suggestion. I will note it in github and shepherd’s report.

This issue is closed. Change was only editorial.

suehares commented 3 months ago

Issue 3: Error Handling - Shepherd's review

--> 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)?

KT response

https://mailarchive.ietf.org/arch/msg/ops-dir/mQPvJKgE5vJZ9gOV-QpBB94DNvM/

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 comment:

[RFC9252] 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:

Current text:/

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). Implementation MAY have knobs which allow these labels./

KT Ack. Will update in the next version once we close your first comment above. https://mailarchive.ietf.org/arch/msg/idr/JKl-r64I-cVSg9UltovTnbLlm4w/

suehares commented 3 months ago

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's Comment:

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.

Note: This was added to the -04.txt. Shepherd closes this portion of the issue.

suehares commented 2 months ago

Comments to be posted to Directorate review:

OPS-DIR-01: OPS-DIR: Issue 1, Introduction, Use of RR Shepherd's comment: github reference: OPS-DIR Review for -01.txt The Term controller needs to be defined or referenced in a document. RFC9256 section 4 indicates a provisioning controller. The definitions of RR, controllers, and provisioning controllers needs to be clear.

OPS-DIR-02: OPS-DIR: Issue 2, Section 4.2, Multiple Candidate paths with same RD

Issue 2: Multiple Candidate paths with same RD - Shepherd's review

Change requested: Based on the question from Nagrenda, please add a sentence to 2.1 and 2.4 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:

Suggested addition after the 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:/ The best candidate path is denoted as the "active candidate path" (see section 2.9 of [RFC9256]). /

OPS-DIR Issue 3: Error Handling - Shepherd's review

Nagendra: 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)?

KT response: https://mailarchive.ietf.org/arch/msg/ops-dir/mQPvJKgE5vJZ9gOV-QpBB94DNvM/

Ketan: 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 comment: [RFC9252] 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:

Current text:/ Binding SID: If the length is 2, then no Binding SID is present. If the length is 6 then the Binding SID is encoded in 4 octets using the format below. Traffic Class (TC), S, and TTL (Total of 12 bits) are RESERVED and MUST be set to zero and MUST be ignored./ Addition after last sentence: / 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 which allow these labels./

suehares commented 1 month ago

Status of OPS-DIR Open: 1) OPS-DIR 01 - Shepherd gives open text, awaiting Ketan's response 2) OPS-DIR 03 - Open awaiting change

Closed: OPS-DIR-02, OPS-DIr-04

suehares commented 1 month ago

-05-txt status Shepherd:

Check has these changes for OPS-DIR-01 and OPS-DIR-03

OPS-DIR-03 changes. OPS-DIR-01 will be added to shepherd's report.

suehares commented 1 month ago

Note: All issues in the OPS-DIR have been resolved, but this issue is left open for ease of reference for AD.