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

[Ketan Talaulikar <[e-mail]>]

Hi Sue,

Thanks for your guidance through the shepherd review.

Thanks,
Ketan


On Fri, Jul 26, 2024 at 2:06 PM Susan Hares <[e-mail]> wrote:

> Version -06 resolves all the RTG-DIR, OPS-DIR, and SEC-DIR comments.
>
>
>
> Thank you for your hard work,
>
> Sue
>
>
>
> *From:* Ketan Talaulikar <[e-mail]>
> *Sent:* Friday, July 26, 2024 3:59 PM
> *To:* Susan Hares <[e-mail]>
> *Subject:* Re: [Idr] FW: draft-ietf-idr-sr-policy-safi - RTG-DIR Review -
> Shepherd's review of Directorate reviews
>
>
>
>
>
> Hi Sue,
>
> I didn't add because each segment type definition specifies if it is
> SR-MPLS or SRv6. With current text the base spec will cover all future
> segment types just like RFC9256 does.
>
> Please let me know if you think otherwise.
>
> Thanks,
> Ketan
>
>
>
> On Fri, 26 Jul, 2024, 12:42 pm Susan Hares, <[e-mail]> wrote:
>
> Ketan:
>
>
>
> *Change to existing text:/*
>
> As specified in section 5.1 of  [RFC9256], a mix of SR-MPLS and SRv6
> segments make the segment-list invalid./
>
>
>
> Good rephrasing of the text, but you did not include the identification of
> the segment types in the list.
>
>
>
> Add after this text:/
>
> The following segments described in Section 4 of [RFC9252] and listed
> above are SR-MPLS segments: Types A,  D, E,  F, G, and H.
>
> The following segments described in Section 4 of [RFC9252] and listed
> above are SRv6 segments: Types B, C, I, J, and K. /
>
>
>
> The answers to the questions are fine. I will add the information from the
> questions to shepherd’s report.
>
>
>
> Sue
>
>
>
>
>
> *From:* Ketan Talaulikar <[e-mail]>
> *Sent:* Friday, July 26, 2024 2:06 PM
> *To:* Susan Hares <[e-mail]>
> *Subject:* Re: [Idr] FW: draft-ietf-idr-sr-policy-safi - RTG-DIR Review -
> Shepherd's review of Directorate reviews
>
>
>
>
>
> Hi Sue,
>
>
>
> We can meet to discuss f2 and I can clarify further.
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Fri, Jul 26, 2024 at 11:03 AM Ketan Talaulikar <[e-mail]>
> wrote:
>
> Hi Sue,
>
>
>
> Please check inline below for responses. An update with the changes as
> discussed below has been posted:
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi-06
>
>
>
> On Thu, Jul 25, 2024 at 3:55 PM Susan Hares <[e-mail]> wrote:
>
> 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. /
>
> KT> Fixed - with slightly different text.
>
>
>
>  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.
>
>
>
> KT> The context is that the controller has done the path computation and
> is sending the computed path (i.e. computed segment list) down to the
> router. In that sense, they are only explicit paths - however in the
> broader SR Policy architecture context (controller + routers) they could be
> explicit paths (provided by operator) or dynamic paths (computed by
> controller). We have the following text in section 2.4.4 and also clarified
> the same in the introduction.
>
>
>
> The Segment List sub-TLV encodes a single explicit path towards the
> endpoint as described in section 5.1 of [RFC9256
> <https://www.ietf.org/archive/id/draft-ietf-idr-sr-policy-safi-05.html#RFC9256>
> ].
>
>
>
>
>
>  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)
>
>
>
> KT> Yes, composite paths are outside the scope of this document. Added
> text to clarify that in the introduction.
>
>
>
>   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./
>
>
>
> KT> I've clarified this, with different text.
>
>
>
>   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)?
>
>
>
> KT> The RT identifies the BGP Router via its BGP Identifier (i.e. BGP
> Router-ID) which is always modeled as an IPv4 address even for IPv6
> deployments.
>
>
>
>   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)
>
>
>
> KT> To clarify the local router's BGP Identifier matches one of the RTs on
> the route. Please let me know if I've misunderstood your point.
>
>
>
>   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?
>
>
>
> KT> Yes, most deployment designs that I am aware of use direct iBGP
> sessions from the controller to the BGP routers.
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
>
>
> *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 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]> 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/
>
>
>
> Github
>
> https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues
>
>
>
> 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
>
> Issue 17:
> https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/19
>
> Issue 19:
> https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/21
>
> Issue 20:
> https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/22
>
> Issue 24:
> https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/26
>
> Issue 25:
> https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/27
>
> Issue 26:
> https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/28
>
> Issue 27:
> https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/29
>
> Summary of issues:
>
> https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/32
>
>
>
> *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/
>
>
>
> *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/
>
>
> 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/
>
> *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/
> )
>
> *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]
> To unsubscribe send an email to [e-mail]
>
>