[Idr] Re: FW: draft-ietf-idr-sr-policy-safi - RTG-DIR Review - Shepherd's review of Directorate reviews

[Susan Hares <[e-mail]>]

Ketan:

I’ve pulled to the front the few issues remaining from the routing review.  Two issues had partial resolution of the text.
(S2-02 and S2-03).  We can talk about the text changes.

There are 3 questions, I need clarity on so I can write-up the rest of the shepherd’s report.  You can just answer those in your reply email.

Getting so… close.

Thank you, Sue


Section 2 – partial fixes
S2-02: Section 2.4.2, I-Flag – is partially implemented, how about we compromised on
Old text-05: / The flag
         indicates that the CP is to perform the "drop upon invalid"
         behavior when no valid CP is available for this SR Policy.  .
New-text:/ The flag indicates that the SR Candidate Policy (CP) is to perform
the "drop upon invalid" behavior when no valid SCP is available for this SR
Policy. /
 S2-03, Section 2.4.4, Validation of Segment list
Context of request in text:
The components of the explicit SR Candidate Policy path can be validated during the TEA processing for the following:
·         an empty Segment list for an explicit SR Candidate Policy,
·         a Weight SubTLV of zero, and
·         mixtures of SRv6 and SR-MPLS.

As stated, Section 5 of [RFC9256] does not provide a clear reason why the normal checks within BGP are being ignored for an explicit candidate path. If the "explicit path encoded by the Segment List SubTLV" is either an explicit SR candidate Policy path (tunnel), or a dynamic SR candidate Policy path (tunnel), or a composite SR Candidate Policy path, the text needs to state:
1.       what type of segment lists are being passed by BGP,
2.       why an empty segment list is not being checked, an
3.       why a weight SubTLV with a value of zero is accepted for a valid SR Candidate Policy.

My comment: You have only addressed the weight comment and the empty segment list (A+B)
a)       There are three types of segment lists: explicit, dynamic, and composite.

Just to be sure, there are no “BGP update packet” indicators that the paths are only explicit paths.
 This fact means that composite paths must use a different subTLV than the segment list.
(see draft-jiang-idr-sr-policy-composite-path-00 section – segment list is explicit path, and constitute SR-policy is composite path)

All this one needs is confirmation in response email.  (e.g. “Yes – segment list is only for explicit SR Candidate Paths)

b)      Why are you not checking that the Segment list does not mixed SRv6 and SR-MPLS segment types in the same segment list

Section 5 of RF9256 indicates you will not mix SR-MPLS and SR-v6 segment tyeps:
·         For draft-ietf-idr-sr-policy-safi:  It would be easy to check that Segment type A and Segment type B are not included in the same segment list.
·         For the combination of draft-ietf-idr-sr-policy-safi-05 and d draft-ietf-idr-bgp-sr-segtypes-ext-03, you simply could check indicate which category each segment belongs to.

Old-Text change:
   /The following sub-sections specify the sub-TLVs used for Segment
   Types A and B.  The other segment types are specified in
   [I-D.ietf-idr-bgp-sr-segtypes-ext]./

New text:
   /The following sub-sections specify the sub-TLVs used for Segment
   Types A and B.  The other segment types are specified in
   [I-D.ietf-idr-bgp-sr-segtypes-ext].

   Section 6 of [RFC9256] indicates that SRv6 and SR-MPLS segment types
   cannot be mixed in the same segment list. The following segment types
   are SRv6 segment types (A, C, E, F, I, J, and K). The following segment types
   are SR-MPLS segment types (B, D, G, and H). An implementation should
   check whether these types are mixed in the same segment list./


Answers needed for section 4.
Please answer the questions in issues.  I’ll add these to the shepherd’s review

SR04-01 - Section 4.2.1 - Lack of RT for IPv6
   Why is the RT target not needed fro IPv6 NLRI (2/73)?

SR04-02- Section 4.2.2 - Eligibility for Local Use of an SR Policy NLRI
How is -04 text different than Jeffrey’s assertion (a local RT matches one of the advertised RT)

SR04-03- Section 4.2.2 - - WG discussion Questioned
Restated: Are you using configured IBGP sessions rather than RT to reduce the flooding of information?





From: Ketan Talaulikar <[e-mail]>
Sent: Monday, July 22, 2024 3:03 AM
To: Susan Hares <[e-mail]>
Cc: [e-mail]; Keyur Patel <[e-mail]>
Subject: Re: [Idr] FW: draft-ietf-idr-sr-policy-safi - RTG-DIR Review - Shepherd's review of Directorate reviews

Hi Sue, The version 05 posted a short while ago includes the changes as discussed below: https://www.ietf.org/archive/id/draft-ietf-idr-sr-policy-safi-05.html I've incorporated all the suggestions pro
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tL2ZkYzQ3M2FmMTE4MDU2MWUwNTUzZmI1YzMzZDYwZjU0LzE3MjE2MzE4MjUuMjc=#key=b904f5b56109ead401c8fa24f3503a7b>  FAQ<https://www.godaddy.com/help/report-email-with-advanced-email-security-40813>  GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky>

Hi Sue,

The version 05 posted a short while ago includes the changes as discussed below: https://www.ietf.org/archive/id/draft-ietf-idr-sr-policy-safi-05.html<https://shared.outlook.inky.com/link?domain=www.ietf.org&t=h.eJxFzskOwiAUheFXaVjLcKHQ2lVfBRkKsVMAbdT47oobt_fP_XJe6JZmNDQolLLngdLjOEh0xZMtTVQnE-Ld0WipTdoXXAuONuGc8L7N0Txw1j5iJkkoy4xODbpWbXXl-w9M9uoMnOagk8vjap-BmG2h3pq2E9oD9EwqcExK4S_SCGEV87Kl0HFQAnouCe-q6qp6dUWv5TdvnBYd54rVamv9X94fHGpCXA.MEUCIQCFt4fyeNdCrCV351_EO-FsMaJblALgvSKt5y1Qv1jpzgIgLWJMy7oysmSPps2vWFaSabxaFl6oXpWKC_uTIZEO_w8>

I've incorporated all the suggestions provided by you except for a few ones as discussed inline below.

Thanks,
Ketan


On Mon, Jun 3, 2024 at 11:43 AM Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:
Ketan:

Below is my shepherd’s review of the RTG-DIR responses.   Responding on the mail list is fine.   One other option is that we can schedule a 7am PT/ 10am EDT call to work through the issues.  Keyur volunteered to sit on the call to give his perspective.

I’m open at 10am on Tuesday morning (6/4) at 10:00 am – 11:00am  EDT (7:00am PT),  Wednesday (6/5) from 10-11 am EDT (7-8 am PT), or Thursday 9:00 – 10:30am EDT (6-7:30am PT).

Cheers, Sue

=================

RTG-DIR email thread
https://datatracker.ietf.org/doc/review-ietf-idr-sr-policy-safi-01-opsdir-early-nainar-2024-03-04/<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org&t=h.eJxFjstuwyAQRX8lYt0xL2M7WeVXpjDEyA5YA22UVP33lm66PUc6936JD97F5STW1o56kTJgw8boN-IhUYtD4ZsMxUumz0QP6AxSYKgMR9mTf0LFmEBpKEcNiYGQ9ydkTBkZjDIjKAtqlOLtJLY-lan9RrVyy3TWRtYVmeo1h9c6-HKXMfhxthi1XpSbNCnnbHx33towqehGqWejJ6sX4wYz9yr16kYNc_v7fL3dMe091m3o9p98_wCzQ0ti.MEQCIFwjsIWR76HxYDnJROLl_LLCvjmcCiyIAP4f14_6fbiIAiBKy6YRBuUw_CmYJvvWqAHAl5XCK1f2CCsT2F1HEEk2Cw>

Github
https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues<https://shared.outlook.inky.com/link?domain=github.com&t=h.eJxFzksOgyAYBOCrGNZF_EHQuvIqyDs-A5imbXr3FjddzkzyZd7ojAsaKuRzPtJAiAvZn1Ot9pUEky1-OBx0JDpKm_HV_CJOER_7EtQTJ2kDCSmdJqFbheZibSbv0UHDe3EHSpKX0aRx0y9_uVartmPSAvQNF2AazpmduGJMi8bylkBHQTDoKa9pV1RT1NlkueW6fBjdKsNSsLLqsv6bzxfMJUIy.MEUCIQD-Fz46fJ2Kk8iLgIf2w5cx-tIaaR06_oYbTa8arSB30gIgHiMBqL067rn0MgtmNfUJv163ylB_6IpF0icJf8iR5vI>

Open issues from RTG-DIR: Issues 12, 17, 19, 20, 24-27,
Issue 12: https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/14<https://shared.outlook.inky.com/link?domain=github.com&t=h.eJxFzksOgyAYBOCrGNZF_EHQuvIqyDs-A5imbXr3FjddzkzyZd7ojAsaKuRzPtJAiAvZn1Ot9pUEky1-OBx0JDpKm_HV_CJOER_7EtQTJ2kDCSmdJhFo0a1Cc-E2k_fooOG9uAMlycto0rjpl79oq1XbMWkB-oYLMA3nzE5cMaZFY3lLoKMgGPSU17QrqinqbLLccl1ujG6VYSlYWXVZ_83nC26AQsY.MEUCIBb3uUfTm2-wfIenQ_ZR6tFj7wNJi5iygpfbfs4t8GE9AiEAzEY9KPEMMaxuZSmFpDwMIjtfzV8ovhIXQw6trwMjqgw>
Issue 17: https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/19<https://shared.outlook.inky.com/link?domain=github.com&t=h.eJxFzskOwiAYBOBXMZyl9IdCl1NfhbKna4DGqPHdlV48zkzyZd7ojAsabsjnfKSBEBeyP6dK7SsJJlv8cDjoSHSUNuOr-UWcIj72JagnTtIGElI6TSLQo_sNzYXbTN6jg5p3ogdKkpfRpHHTL3_RVqumZdICdDUXYGrOmZ24YkyL2vKGQEtBMOgor2hbVFPU2WS55arcGN0qw1Kwsuqy_pvPF3EtQss.MEQCIF8-i7qTd8egE-HCvjs_mcBl8C8gtwp3ZjlgatlfUhOmAiBwvWcyy_ZVuwBLLY3ClCR-CbFzROyAzdsBElOV1YR6DQ>
Issue 19: https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/21<https://shared.outlook.inky.com/link?domain=github.com&t=h.eJxFzksOgyAYBOCrGNZF_EHQuvIqyDs-A5imbXr3FjddzkzyZd7ojAsaKuRzPtJAiAvZn1Ot9pUEky1-OBx0JDpKm_HV_CJOER_7EtQTJ2kDCSmdJhEK6FahuXCbyXt00PBe3IGS5GU0adz0y1-01artmLQAfcMFmIZzZieuGNOisbwl0FEQDHrKa9oV1RR1NlluuS43RrfKsBSsrLqs_-bzBW1vQsQ.MEYCIQDPX9hQYXyTPw6Nkl9UmGsW2tw_Poffen2Jv7OFnAZj0AIhAJmE3fNMklDth62IMoxHSnU5AfCq7e_3VhTVRYXd1SAm>
Issue 20: https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/22<https://shared.outlook.inky.com/link?domain=github.com&t=h.eJxFzksOgyAYBOCrGNZF_EHQuvIqyDs-A5imbXr3FjddzkzyZd7ojAsaKuRzPtJAiAvZn1Ot9pUEky1-OBx0JDpKm_HV_CJOER_7EtQTJ2kDCSmdJhFK0a1Cc-E2k_fooOG9uAMlycto0rjpl79oq1XbMWkB-oYLMA3nzE5cMaZFY3lLoKMgGPSU17QrqinqbLLccl1ujG6VYSlYWXVZ_83nC234QsU.MEUCIQClfHA03-WHBaFT5fTiSrjxfMtoK2EN6Mo1Kp9Vob3nGwIgFk7T0_bPvOAystcnx4zA2YPyQl9jTjqbHy1VQA8x9Yg>
Issue 24: https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/26<https://shared.outlook.inky.com/link?domain=github.com&t=h.eJxFzksOgyAYBOCrGNZF_EHQuvIqyDs-A5imbXr3FjddzkzyZd7ojAsaKuRzPtJAiAvZn1Ot9pUEky1-OBx0JDpKm_HV_CJOER_7EtQTJ2kDCSmdJhEq0K1Cc-E2k_fooOG9uAMlycto0rjpl79oq1XbMWkB-oYLMA3nzE5cMaZFY3lLoKMgGPSU17QrqinqbLLccl1ujG6VYSlYWXVZ_83nC3AcQsk.MEYCIQDQ7184UCkob-An8Xli2mv5pr9aaTVXks04KyBb1Hh-UAIhAOz_Moiv4CIKMEbfUd-LWQSNz5dJ18Aig9saGY3rQNQ_>
Issue 25: https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/27<https://shared.outlook.inky.com/link?domain=github.com&t=h.eJxFzksOgyAYBOCrGNZFBAStK6-CvKNVA79p2qZ3b7GLLmcm-TIvdKQFDRUKAHseCPERwjHVeruRaMHhu8fRJGKScoDP5htxTnjflqgfOCsXScz5sJmwDl0qNBdutbAlTxvRyytlJAeVbB5X8wwn7YxuO64cpX0jJLWNENxNQnNuZONES2jHqOS0Z6L-qbaoswW1Ql1ujP6m4lKwspqy_pv3B3ClQso.MEQCIFBBV2h2gGneBlKceGmrWyoqOkv4wWkHUMW2DrNhRyN0AiBOwDiAi7mWHocOyGItowdSO7zdLlz9TCDY4ji7pc2JYw>
Issue 26: https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/28<https://shared.outlook.inky.com/link?domain=github.com&t=h.eJxFzksOwiAABNCrNKyl_ArFrnoVyj_9BmiMGu-udONyZpKXeYMzLWBoQCjlyANCPpZwTq3eVxRtcfDhYTQJmaRcgVfzizAneOxL1E-YlYso5nzajKgEtwbMldts2ZMnmEtxJxTloJLN42Ze4aKd0V3PlCNEYi6IxZwzN3HNmBHY8Q6RnhLBiKS8pX1VbVVnW9RW2npj9KuKS8Xqaur6bz5fcS5Cyw.MEQCIAIj9TbjBxEUqgq0bXkdLejGX3GotMdOSs7pd8O--ZxrAiBnfh8IjqWz_7xl2D-vkTklWfocoN6l8ZnDRDXWELeexg>
Issue 27: https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/29<https://shared.outlook.inky.com/link?domain=github.com&t=h.eJxFzskOwiAYBOBXMZylf4FCl1NfhbKna4DGqPHdlV48zkzyZd7ojAsabsjnfKQBwIXsz6lS-wrBZIsfDgcdQUdpM76aX8Qp4mNfgnriJG2AkNJpEtAe3W9oLtxm8h4dqXknekIheRlNGjf98hdttWpaJi0hXc0FMTXnzE5cMaZFbXkDpKVEMNJRXtG2qKaos8lyy1W5MbpVhqVgZdVl_TefL3G3Qsw.MEUCIHEByFbxQPJaj0l9tXIS-9iPKff6UbeFM6KIJ5WtKmguAiEA0FNgRIv-3nTdSIa9B87DvXZI-TIk_0diPekgrGy-mZ8>
Summary of issues:
https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/32<https://shared.outlook.inky.com/link?domain=github.com&t=h.eJxFzksOgyAYBOCrGNZF_EHQuvIqyDs-A5imbXr3FjddzkzyZd7ojAsaKuRzPtJAiAvZn1Ot9pUEky1-OBx0JDpKm_HV_CJOER_7EtQTJ2kDCSmdJhFG0a1Cc-E2k_fooOG9uAMlycto0rjpl79oq1XbMWkB-oYLMA3nzE5cMaZFY3lLoKMgGPSU17QrqinqbLLccl1ujG6VYSlYWXVZ_83nC26CQsY.MEYCIQCJWzd-W0JEz6hFjVQ5iDyqxWQuIKCEZh4Pj1Cry-st6gIhAOdGu2AQoXt9_M9TmzKs7QtrR_9NMs8OMmpzYuhdq-me>

Shepherd's Comments on -04 Section 1 - Based on RTG-DIR
status: Editorial, open
Comments: Intro-1, Intro-2, Intro-3 https://datatracker.ietf.org/doc/review-ietf-idr-sr-policy-safi-01-opsdir-early-nainar-2024-03-04/<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org&t=h.eJxFjstuwyAQRX8lYt0xL2M7WeVXpjDEyA5YA22UVP33lm66PUc6936JD97F5STW1o56kTJgw8boN-IhUYtD4ZsMxUumz0QP6AxSYKgMR9mTf0LFmEBpKEcNiYGQ9ydkTBkZjDIjKAtqlOLtJLY-lan9RrVyy3TWRtYVmeo1h9c6-HKXMfhxthi1XpSbNCnnbHx33towqehGqWejJ6sX4wYz9yr16kYNc_v7fL3dMe091m3o9p98_wCzQ0ti.MEQCIFwjsIWR76HxYDnJROLl_LLCvjmcCiyIAP4f14_6fbiIAiBKy6YRBuUw_CmYJvvWqAHAl5XCK1f2CCsT2F1HEEk2Cw>

SR04-Intro-1
Where: Introduction, paragraph 13
Github: RTG-DIR Issues 4 and 5
Shepherd's editorial preference is noted below but the -04 text is technically correct.

Suggested change: /
Old text:/
An SR Policy intended only for the receiver will, in most cases, not
traverse any Route Reflector (RR, [RFC4456]). /
New text:/
An SR Policy intended only for the receiver will, in most cases, not
traverse any Route Reflector (RR, [RFC4456]). (See Section 4.2.3). /

SR04-Intro-2
Section: Introduction, paragraph 14
original issue: RTG-DIR Issue 6
Status: Editorial, open
old text:/
One or more IPv4 address specific format route target extended
community ([RFC4360]) attached to the SR Policy advertisement and
that indicates the intended headend of such an SR Policy
advertisement./
New text: /
One or more IPv4 address-specific format route target extended
community ([RFC4360]) attached to the SR Candidate Policy advertisement and
that indicates the intended headend of the SR Policy
advertisement./

SR04-Intro-3
**-04 text ** /
The SR Policy SAFI route updates use the Tunnel Encapsulation
Attribute to signal an SR Policy - i.e., a tunnel itself./

**New-text:/
The SR Policy SAFI route updates use the Tunnel Encapsulation
Attribute to signal an SR Policy - which is a tunnel itself/

Shepherd's comments on -04.txt Section 2
S2-01: Section 2.4.2, paragraph 2

github issue: RTG-DIR-Issue-14, github 16
Status: Editorial, clarity of text

Original Text: /
It is RECOMMENDED that the SRv6 Binding
SID sub-TLV defined in Section 2.4.3, that enables the specification
of the SRv6 Endpoint Behavior, be used for signaling of an SRv6
Binding SID for an SR Policy candidate path./

New text:/
It is RECOMMENDED that the SRv6 Binding
SID sub-TLV (defined in Section 2.4.3) be used to signal an SRv6 Binding SID
for an SR Policy candidate path./
KT> Retaining the original text since it explains why the SRv6 BSID sub-TLV is recommended.
S2-02: Section 2.4.2, I-Flag

github issue: RTG-DIR Issue-19
Reasons: Technical, RFC9256, Section 8.2 is confusing, CP undefined

Text:/
- I-Flag: This flag encodes the "Drop Upon Invalid" behavior. It
is used by SRPM as described in section 8.2 in [RFC9256]. The
flag indicates that the CP is to perform the "drop upon
invalid" behavior when no valid CP is available for this SR
Policy. In this situation, the CP with the highest preference
amongst those with the "drop upon invalid" config is made
active to drop traffic steered over the SR Policy.

Text in RFC9256 section 8.2 states:

Specifically, the operator does not want the PW to be routed according to the IGP
shortest path to the PW endpoint.



Technical comment: BGP passes to the SRPM a valid SR Policy Candidate Route a specific behavior (I-Flag). Validation of the SR Policy Candidate Route is based on NLRI and TEA checks. The general concept of the I-Flag is given in RFC9256 in Section 8.2 is reasonable, but matching the BGP-SRPM actions is difficult. (See RTG-DIR comments)

Alternate text:/
- I-Flag: This flag encodes the "Drop Upon Invalid" behavior. It
is used by SRPM as described in section 8.2 in [RFC9256]
to define a specific SR Policy (tunnel) forwarding behavior. The
flag indicates that the SR Candidate Policy (SR-CP) is to perform
the "drop upon invalid" behavior when no valid SR-CP is available for this SR
Policy. In this situation, the SR-CP with the highest preference
amongst those with the "drop upon invalid" config is made
active to drop traffic steered over the SR Policy./

S2-03: Validated (Empty)Segment lists, Section 2.4.4 -

github issue: RTG-DIR Issue-19
status: Technical issue: Validating Segment lists
reason: RFC9256 in section 5.1 indicates that

  *   an empty explicit SR Candidate Policy is invalid if it is "empty", has a weight of zero (0), or mixes SRv6 and SR-MPLS types, and other constraints known in SRPM.
  *   a dynamic SR Candidate Policy is only invalid if the "constraints" AND the optimization object cannot be solved,
  *   a composite SR Candidate Path is a combination of explicit and dynamic.

Text-1:/ The Segment List sub-TLV contains zero or more Segment sub-TLVs and
MAY contain a Weight sub-TLV./

Text-2:/ Validation of an explicit path encoded by the Segment List sub-TLV is
beyond the scope of BGP and performed by the SRPM as described in
section 5 of [RFC9256]./

The components of the explicit SR Candidate Policy path can be validated during the TEA processing for the following:

  *   an empty Segment list for an explicit SR Candidate Policy,
  *   a Weight SubTLV of zero, and
  *   mixtures of SRv6 and SR-MPLS.

As stated, Section 5 of [RFC9256] does not provide a clear reason why the normal checks within BGP are being ignored for an explicit candidate path. If the "explicit path encoded by the Segment List SubTLV" is either an explicit SR candidate Policy path (tunnel), or a dynamic SR candidate Policy path (tunnel), or a composite SR Candidate Policy path, the text needs to state:

  1.  what type of segment lists are being passed by BGP,
  2.  why an empty segment list is not being checked, and
  3.  why a weight SubTLV with a value of zero is accepted for a valid SR Candidate Policy.

Suggested change for weight subTLV check:
Change: Technical, validation of explicit SR Candidate Policy.

Current text:/Weight: 4 octets value indicating the weight associated with a
segment list as described in section 2.11 of [RFC9256]. /

New text:/ Weight: 4 octets value indicating the weight associated with a
segment list as described in section 2.11 of [RFC9256].
A weight value of zero (0) is invalid./

S3-04: Section 2.4.4.2.2,

github issue: RTG-DIR-20, github-22
Why: Editorial, Clarity and grammar

-04-txt: /
The TLV 2 defined for the advertisement of Segment Type B in the
earlier versions of this document has been deprecated to avoid
backward compatibility issues./

new text:/
A Segment Type B subTLV with a SubTLV type value of 2 was defined for the
advertisement of Segment Type B in earlier versions of this document but it
was deprecated to avoid backward compatibility issues./
KT> Rephrased.
S2-05: Section 2.4.4.2.2-2.4.4.2.3, Significance of Flags, V Flag

github issue: RTG-DIR-19
status: Technical issue 1: Validity of SR Candidate Routes

Text:/ V-Flag: This flag, when set, is used by SRPM for "SID
verification" as described in Section 5.1 of [RFC9256]./

The "V-Flag" applies to all segment types. It is important to indicate what type of SR Candidate Policy this can be: explicit, dynamic, composite, or all three.

Again, repeating the comment from S2-03:
Validating an explicit SR Candidate route includes validation of the BGP Tunnel Encaps Attribute (TEA) information for the following things:

  *   Non-empty Segment list
  *   non-zero Weight SubTLV
  *   no mixture of SubTLVs between SR-MPLS and SRv6
(SR-MPLS subTLVs are A, D, G, and H. SRv6 subTLVs are: B, I, J, K, non-specified, C, E, F).

Shepherd's comment:
It seems odd to remove validation of the TEA portion of the BGP passed SR Candidate Policy if it is considered an "explicit" candidate route. If it is "dynamic", then how can interoperability be specified without specifying a base set of policy for creating "dynamic route". The only reference in RFC 9256 on those dynamic consideration is the
[draft-filsfils-spring-sr-policy-considerations-09], an expired Internet-Draft.

Shepherd's comments on Section 3 - No issues from RTG-DIR Mail thread

RTG-DIR Mail thread:
https://mailarchive.ietf.org/arch/msg/ops-dir/JFInEGfu1GpIgTuCTWsNMJbGwp0/<https://shared.outlook.inky.com/link?domain=mailarchive.ietf.org&t=h.eJxFjssOgjAUBX-FdK3cXmoBWZEYJZroysR1oS0QnmmLJhr_XevG7UzO5LzIYnqSBaRxbrYZwCDaXpiqae8qbJXT4WRq8AAGW8M027VsDZwOx3Ff6AWL-Vhfl931Zi_nU1k8ZgpkFZDOJ0flvmOkPI23GIFthFE2H-WzCatpAC2rTcKERkwpj1FRzpkuecWYjKnmG8AkwphhGvEwSnxV-WqnnBjd71te-7c-5q309k_eHz8cQ30.MEUCIB4wO5y_TIQW7TFNHTsxOCVbJy4pqi2LoklR9LdoQINqAiEAiVl4Mlj7GpEIzsf06oh_rSWVjCq1cXAo06TSr8z18zs>



RTG-DIR Review: Issues with Section 4
SR04-01 - Section 4.2.1 - Lack of RT for IPv6

github issue: RTG-DIR Issue-24,

Jeffrey Zhang's question: What about IPv6-address specific RT?
https://mailarchive.ietf.org/arch/msg/rtg-dir/E9qyJKHjRpMTNOAXnJo9jVi0nQg/<https://shared.outlook.inky.com/link?domain=mailarchive.ietf.org&t=h.eJxFjssOATEYRl9Fumb-dqpzW7GQCEGIiG1NL1Mz06FTEsS7Uxvbc_KdfC90cw0qBqjy_tIXAC03DXdlZe4yMtKrqHMaAoC21-C8HgnjYJZfH4vl_Ly7rPbrzfRoF11-PhhstxrQcIDqkLTSf8cEsyzJSQx9xZ3sJ1Y8q6jsWlCiHKeUK0IyzBIiMWNUnVhJqUiwYmMgaUwSSrKYRXEaqjJUa-m59b9vEx3ehliwItg_eX8ARttDig.MEUCIA7xO6CgwECbG7wSys6x2hQRyoTMVfozAzYibI9eYoBrAiEA_8_1hR-Bmx4AVzTUqngZgFFgqSsE_-Yq9Bow7Yl8L2Q>

Shepherd's question:
NLRI specified are: SR Policy IPv4 (1/73) and SR Policy IPv6 (2/73).
Why is the RT target not needed fro IPv6 NLRI (2/73)?

SR04-02 - Section 4.2.2 - Eligibility for Local Use of an SR Policy NLRI

github issue: RTG-DIR Issue-25:

text: / If one or more route targets are present and none matches the local
BGP Identifier, then, while the SR Policy NLRI is valid, it is not
usable on the receiver node./

Discussion:
Jeffrey: As long as the receiver is configured with a local RT that matches one
of the advertised RTs, it should be fine, right? That is how VPN RT
works and I suppose the same can be used here.
Ketan (KT): The semantics are different here.
Shepherd's question: How is the -04 text above different from Jeffrey's assertion?

SR04-03 - Section 4.2.2 - WG discussion Questioned

Status: Simply Reporting the RTG-DIR hit the WG Discussion on RTs
text:/  If one or more route targets are present and none matches the local
BGP Identifier, then, while the SR Policy NLRI is valid, it is not
usable on the receiver node./

Short Summary:
Jeffrey: I think it SHOULD remove the RT that matches its BGP identifier and stop propagating if there are no more RTs left, w/o relying on configuration.
(reference: https://mailarchive.ietf.org/arch/msg/rtg-dir/pzT0P9XId3qV3iCd-mgpZUvul7A/<https://shared.outlook.inky.com/link?domain=mailarchive.ietf.org&t=h.eJxFjrsOgjAYRl-FdBb-llJuE8bJzUGNcav0QsPVUhgwvrvWxfWcfCffCy22Q2WAGuemuQTouem4rRuzyshIp6LRavAA-lmDdToUxsK0nfGpuB0FfV6pOYiw19P9si5dtge0C1Drk4N03zHBLE8LEsPccCvnahBbE9VjD0rUSUa5IiTHLCUSM0bVg9WUihQrlgDJYpJSkscsijNflb7aSscH9_tWaf_Wx7wV3v7J-wNHJ0OL.MEUCIHv0BeJ2F8evycIVxTlJ7Gk2sf_bfM-x5886BlmBq93zAiEAk0f4lCwfPc1EEAOc9uib_KDdXj2n-kBLP2IDHeLFmH8>)

Ketan: I can understand where you are coming from and IIRC this option was
discussed at some point of time during the draft's life as a WG document.
The decision at that point was to keep it as an explicit policy option and
to not create an exception in the base BGP propagation mechanism. The way
it works today is that the BGP Identifier matching is done during "import"
into SRPM that is specific to the BGP SR Policy SAFI.


Shepherd:  Reporting that we hit this discussion in RTG-DIR review.

Shepherd's Review of RTG-DIR Comments on Section 5
S04-Section 5 - Issue-1

Status: Technical, open
Issue: Validation of the Tunnel, see RTG-DIR Issue-12 in github

Suggested text addition to section 5 in the following paragraph.
There are changes to the original paragraph (editorial) and an additional set of text.

Paragraph revised (changed text in bold):/
The validation of the TLVs/sub-TLVs introduced in this document and
defined in their respective sub-sections of Section 2.4 MUST be
performed to determine if they are malformed or invalid. The
validation of the Tunnel Encapsulation Attribute itself and the other
TLVs/sub-TLVs specified in Section 13 of [RFC9012] MUST be done as
described in that document. In case any error is detected, either at
the attribute or its TLV/sub-TLV level, the "treat-as-withdraw"
strategy MUST be applied. This is because an SR Policy update
without a valid Tunnel Encapsulation Attribute (comprised of all
valid TLVs/sub-TLVs) is not usable.

Section 6 of [RFC9012] referred to by section 13 of [RFC9012] does not
apply to a TLV associated with the SR Policy NRLI so the Tunnel
Egress Endpoint does not have to exist in the Tunnel Encapsulation
Attribute with the tunnel type SR Policy. As noted in section 2.3,
the Tunnel Egress Endpoint SubTLV is ignored for tunnel Type SR Policy.
Only the SRPM validates the viability of the tunnel signaled through BGP./

SR04 Section 5 - Issue 2

Status: Technical, Reporting concern, Section 5
github: RTG-DIR Issue 27,
text:/ The validation of the individual fields of the TLVs/sub-TLVs defined
in Section 2.4 are beyond the scope of BGP as they are handled by the
SRPM as described in the individual TLV/sub-TLV sub-sections. A BGP
implementation MUST NOT perform semantic verification of such fields
nor consider the SR Policy update to be invalid or not usable based
on such validation./

Comment from RTG-DIR:
Jeffrey: The above says the validation of those in Section 2.4 may lead to
"treat-as-withdraw" - I assume this is BGP handling. Does that not
conflict with the following paragraph?
Ketan: No, it does not. There is a line between what validation is done by BGP
and what is done by SRPM.

Shepherd: The SRPM doing all the checks – is been questions by RTG-DIR and

OPS-DIR.  The text below will go in my Shepherd’s report under the Directorate reviews:



“The RTG-DIR questions the wisdom of not doing minimal checks (like empty segment list or Weight = 0).

The Concept of MUST NOT goes against the normal sanity checks in SR Routing toward BGP-LS.”



The Shepherd again asks the WG to confirm that this behavior it wishes to approve.

_______________________________________________
Idr mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>