Re: [RTG-DIR] Rtgdir early review of draft-ietf-idr-sr-policy-safi-00

Ketan Talaulikar <ketant.ietf@gmail.com> Sat, 27 April 2024 09:28 UTC

Return-Path: <ketant.ietf@gmail.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1468DC14F61F; Sat, 27 Apr 2024 02:28:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwyaolAzdrnU; Sat, 27 Apr 2024 02:28:33 -0700 (PDT)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61C57C14F60A; Sat, 27 Apr 2024 02:28:33 -0700 (PDT)
Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-a55b3d57277so355796266b.2; Sat, 27 Apr 2024 02:28:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714210112; x=1714814912; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vhUaIEak3CCWAqENYznKEX8iM+zWpe59a6FtD06nDhA=; b=nYx449V41QxgbgUeddzpq1z/MshvjNXYCXVNc1n1Gnam/OHQEsQLj1icjuDSbbDdcq 8rXJKkonJ524Y05DZDkbVkU233vaCZGJzuO0wer+2GkmThBvY18gcVEr81JMYbZbk8m/ NT+7iljk1wfkWk0S0LGXesmx+5OpEm4iDUx1raKHjk7WCsUTClLMVnhk7tMk2KmZz9G1 tKWDkywz79FPth9GXoAdhwOY7Wl3tgiEaJK48GcTIzivPfPygyZsoJChOerxE3TNcI5T 17hmLWyXAT71U/N/9YL9NJisIs1Hd8XTOzEUShu0ZX2UQOuyFJ4xE55RrW7bL7ZEQP5c 19+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714210112; x=1714814912; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vhUaIEak3CCWAqENYznKEX8iM+zWpe59a6FtD06nDhA=; b=ZbSwL30kaZWlwlEqpQBR87e1SQkiHBdQIREUHiulGNWfHBG7WVTFXj5sLwclZ/QqrP o3/uiJZ46MA6Clni04SrsSNo/VRvtFh4yvLAOFSI+Z9NlFYEZOdOwsg7AgUmFEVTgUk5 sue0vnhCofwkVutgIYJ7wpKT/IOkIPSgTgdt7eFWR4iKJoJLu/ZbXreh0Xjm7WiIO5Hl s/HRgLhsJVCliwG5wKImWngZAsMBJAFhluWdoZ2MfLvHAkd0E3Skg4POy9iFsTCTWEPP 0Zyt6TxF4QK5tF5JsFZnBIRdBerY+DXvJRdzQ1clUkbXbLuy5uB8591eYi/shPrYQOK4 07IA==
X-Forwarded-Encrypted: i=1; AJvYcCX1nqeVA8q91DvwKqt/odg/OhDyD3ajXMzhljxXeLn6mr2/jfi2g6fqjRuHVPGqnTeRC0jOuuAe9I8pKrY/XOxlwKZtjt4+ylt8IMPmk0lo4prP2WYkXrzry24yn4AFg3t03aqQGWZybQ==
X-Gm-Message-State: AOJu0YzRAlOYxmfcaZsnqvvQ63cEgsBvmdmu1D5CHwRwzNnVFaOEpKUw 8HQJjS4qAVoZRBETnZqg49Tn2U8moAWI7fVRh/oKu1jqrecywL3dHZPARW8p5v9DzjRXYMtzRdP beB39t5VsgAM+XHKJboY1vjrc7Q4=
X-Google-Smtp-Source: AGHT+IHYCsZMd/np7+WodRrIofbhftn8mtuwrFzqyao5XIhDu02oURA2DWEbDetpbA/lNZ+0GEMWexpA0mLvEoGftLA=
X-Received: by 2002:a17:906:3102:b0:a58:9707:6857 with SMTP id 2-20020a170906310200b00a5897076857mr3336250ejx.12.1714210111324; Sat, 27 Apr 2024 02:28:31 -0700 (PDT)
MIME-Version: 1.0
References: <170926285323.21559.2544259526462856240@ietfa.amsl.com> <CAH6gdPztdv-pXF1KyfJyYuWHX4ivpXG5UDDr1+H+oC3vBgmB+Q@mail.gmail.com> <IA1PR05MB9550EE86ABE42D271774A620D4232@IA1PR05MB9550.namprd05.prod.outlook.com> <CAH6gdPxeVMPSk=S9UOmo0bcqDNKUXo1jR8yNOFVyHJXTrW60FA@mail.gmail.com> <CAH6gdPxtMnz5C5tqU92UaUuCFSib0cyt1A7Hmb+vMQCzJHFLvQ@mail.gmail.com>
In-Reply-To: <CAH6gdPxtMnz5C5tqU92UaUuCFSib0cyt1A7Hmb+vMQCzJHFLvQ@mail.gmail.com>
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Sat, 27 Apr 2024 14:58:20 +0530
Message-ID: <CAH6gdPw+ZtfNio2aPj7MBEP-LNW=K=rOyqL1f70G+i3DOxLP1w@mail.gmail.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-idr-sr-policy-safi.all@ietf.org" <draft-ietf-idr-sr-policy-safi.all@ietf.org>, "idr@ietf.org" <idr@ietf.org>, Susan Hares <shares@ndzh.com>
Content-Type: multipart/alternative; boundary="000000000000c189e9061710a43a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/Rjoan0CdgUMp-jQ1A-nOjiP-pr0>
Subject: Re: [RTG-DIR] Rtgdir early review of draft-ietf-idr-sr-policy-safi-00
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Apr 2024 09:28:38 -0000

Hi Jeffrey,

A gentle reminder on this one - could you please respond?

Thanks,
Ketan


On Sat, Mar 16, 2024 at 8:45 PM Ketan Talaulikar <ketant.ietf@gmail.com>
wrote:

> Hi Jeffrey,
>
> An update has been posted which includes some of the changes that we've
> discussed on this thread.
>
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi-02
>
> Please let us know if there are any outstanding comments that remain to be
> addressed.
>
> Thanks,
> Ketan
>
>
> On Mon, Mar 4, 2024 at 9:37 PM Ketan Talaulikar <ketant.ietf@gmail.com>
> wrote:
>
>> Hi Jeffrey,
>>
>> Thanks for your quick response and feedback on this draft. Please check
>> inline below for responses with KT2.
>>
>>
>> On Mon, Mar 4, 2024 at 8:16 PM Jeffrey (Zhaohui) Zhang <
>> zzhang@juniper.net> wrote:
>>
>>> Hi Ketan,
>>>
>>>
>>>
>>> I was finishing up this email before seeing your email about the posted
>>> version. I have not had a chance to go through the changes, but to get my
>>> questions to you quicker, let me send this (even though some may have been
>>> answered by the updated version).
>>>
>>>
>>>
>>> Please see a few points below. I trimmed the text to focus on those.
>>>
>>>
>>>
>>>
>>>
>>>
>>>    An SR Policy intended only for the receiver will, in most cases, not
>>>    traverse any Route Reflector (RR, [RFC4456]).
>>>
>>> Is the above paragraph correct/needed. I suppose in most cases
>>> they will traverse RR after all - whether it is from a controller or
>>> an egress PE.
>>>
>>>
>>>
>>> KT> It is needed. RR is not required and not used in many deployments
>>> that I know of. It is a direct peering from controller to router.
>>>
>>>
>>>
>>> Zzh> OK if you say the most BGP deployment is not through RR 😊
>>>
>>>
>>>
>>> How is further propagation prevented after the headend is reached?
>>>
>>>
>>>
>>> KT> This is covered in section 4.2.3
>>>
>>>
>>>
>>> Zzh> I think a little more text is needed (more below).
>>>
>>>
>>>
>>>    *  One or more IPv4 address format route target extended community
>>>       ([RFC4360]) attached to the SR Policy advertisement and that
>>>       indicates the intended headend of such an SR Policy advertisement.
>>>
>>> and IPv6? s/format/specific/?
>>>
>>>
>>>
>>> KT> Fixed. Use of IPv6 specific RT is not specified in this document.
>>>
>>> Zzh> I see that it’s based on BGP Identifier which is 4-octet only so
>>> that’s reasonable.
>>>
>>>
>>>    It is important to note that any BGP speaker receiving a BGP message
>>>    with an SR Policy NLRI, will process it only if the NLRI is among the
>>>
>>> There are a lot of "processing" before it is deemed "among the bet
>>> paths",
>>> right? Do you mean the "SRPM" will process it only if the NLRI is among
>>> the best paths?
>>>
>>>
>>>
>>> KT> Yes and Yes.
>>>
>>> Zzh> I see that the document intentionally distinguishes between BGP and
>>> SRPM. So the above distinction is necessary.
>>>
>>>
>>>
>>> 2.3.  Applicability of Tunnel Encapsulation Attribute Sub-TLVs
>>>
>>>    The Tunnel Egress Endpoint and Color sub-TLVs, as defined in
>>>    [RFC9012], may also be present in the SR Policy encodings.
>>>
>>> Why do we say the above given the following paragraph? They seem to
>>> be contractive.
>>>
>>>
>>>
>>> KT> There is no contradiction. We don't want the attribute to be
>>> considered malformed due to the presence of those sub-TLVs.
>>>
>>> Zzh> It seems that the above paragraph can be removed – the following
>>> paragraph alone is enough.
>>>
>>
>> KT2> Ack - removed for the next update.
>>
>>
>>>
>>>    The Tunnel Egress Endpoint and Color Sub-TLVs of the Tunnel
>>>    Encapsulation Attribute are not used for SR Policy encodings and
>>>    therefore their value is irrelevant in the context of the SR Policy
>>>    SAFI NLRI.  If present, the Tunnel Egress Endpoint sub-TLV and the
>>>    Color sub-TLV MUST be ignored by the BGP speaker and MAY be removed
>>>    from the Tunnel Encapsulation Attribute during propagation.
>>>
>>>
>>>
>>>
>>>
>>>
>>>    When the Binding SID sub-TLV is used to signal an SRv6 SID, the
>>>    choice of its SRv6 Endpoint Behavior [RFC8986] to be instantiated is
>>>    left to the headend node.  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.
>>>
>>> Is there a choice here? Shouldn't the behavior be that traffic with that
>>> Binding SID is steered into this policy?
>>>
>>>
>>>
>>> KT> What is meant by SRv6 Endpoint behavior is specified in RFC8986 -
>>> e.g., End.B6.Encaps, End.B6.Encaps.Red, and others could be defined in the
>>> future.
>>>
>>>
>>>
>>> Zzh> Now I see that the first “Binding SID sub-TLV” in the above
>>> paragraph is not the “SRv6 Binding SID sub-TLV” but the one that can be
>>> used for both MPLS and SRv6 (I missed that). Then the paragraph makes sense.
>>>
>>> Zzh> It helps if the paragraph moves down to after “If the length is 18
>>> then the Binding SID contains a 16-octet SRv6 SID” and changes to the
>>> following:
>>>
>>
>> KT2> We put it up front so it is more clear - putting it at the end may
>> result in it being missed. This is an editorial thing and I prefer keeping
>> it as is.
>>
>>
>>>
>>>
>>> … in this case, the
>>>    choice of its SRv6 Endpoint Behavior to be instantiated, e.g., between
>>>
>>> End.B6.Encaps, End.B6.Encaps.Red [RFC8986], is
>>>    left to the headend node.  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.
>>>
>>>
>>>
>>>
>>>
>>>    *  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.
>>>
>>>         0                   1                   2                   3
>>>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>        |          Label                        | TC  |S|       TTL     |
>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>
>>>     Figure 6: Binding SID Label Encoding
>>>
>>>       If the length is 18 then the Binding SID contains a 16-octet SRv6
>>>       SID.
>>>
>>>
>>>
>>>
>>>
>>> 2.4.4.2.2.  Segment Type B
>>>
>>>    The Type B Segment Sub-TLV encodes a single SRv6 SID.  The format is
>>>    as follows:
>>>
>>>     0                   1                   2                   3
>>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>    |     Type      |   Length      |     Flags     |   RESERVED    |
>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>    //                       SRv6 SID (16 octets)                  //
>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>    //     SRv6 Endpoint Behavior and SID Structure (optional)     //
>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>
>>>    *  Flags: 1 octet of flags as defined in Section 2.4.4.2.3.
>>>
>>>    *  SRv6 SID: 16 octets of IPv6 address.
>>>
>>>    *  SRv6 Endpoint Behavior and SID Structure: Optional, as defined in
>>>       Section 2.4.4.2.4.
>>>
>>> When this is part of a segment list, what is the significance of the
>>> Flags and
>>> SRv6 Endpoint Behavior and SID Structure?
>>>
>>>
>>>
>>> KT> Please refer to sections 2.4.4.2.3 and 2.4.4.2.4 - will elaborate on
>>> your further comments on those sections.
>>>
>>>
>>>
>>>
>>>    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.
>>>
>>> Why would deprecating them avoid backward compatibility issues?
>>> If there are implementations/deployments based on earlier versions,
>>> deprecating them won't help.
>>> If there are no implementations/deployments based on earlier versions,
>>> there is no backward compatibility issue.
>>>
>>>
>>> Perhaps just remove "to avoid ..."?
>>>
>>>
>>>
>>> KT> The WG was polled in this matter. While there were no
>>> implementations from "known" vendors represented at the IETF, we cannot
>>> rule out something being out there.
>>>
>>>
>>>
>>> Zzh> I mean that “deprecating them” would not address the backward
>>> compatibility issue after all if there is implementation out there already
>>> based on the old version?
>>>
>>
>> KT2> The backward compatibility part was why we didn't change those TLV
>> formats and used new code-points.
>>
>>
>>>
>>>
>>>
>>> 2.4.4.2.3.  Segment Flags
>>>
>>>    The Segment Types sub-TLVs described above may contain the following
>>>    flags in the "Flags" field defined in Section 6.8:
>>>
>>>     0 1 2 3 4 5 6 7
>>>    +-+-+-+-+-+-+-+-+
>>>    |V|   |B|       |
>>>    +-+-+-+-+-+-+-+-+
>>>
>>>    Figure 22: Segment Flags
>>>
>>>    where:
>>>
>>>       V-Flag: This flag, when set, is used by SRPM for "SID
>>>       verification" as described in Section 5.1 of [RFC9256].
>>>
>>> I have trouble understanding the V-Flag. How is the headend supposed to
>>> verify
>>> the BSID or any segment in the segment list?
>>>
>>>
>>>
>>> KT> Please refer to section 5.1 of the RFC9256.
>>>
>>>
>>>
>>>
>>> 2.4.5.  Explicit NULL Label Policy Sub-TLV
>>>
>>>    To steer an unlabeled IP packet into an SR policy, it is necessary to
>>>    create a label stack for that packet, and push one or more labels
>>>    onto that stack.
>>>
>>> Do you mean SR-mpls policy?
>>> Perhaps remove ", and push one or more labels onto that stack"?
>>> Perhaps changes "Explicit NULL Label Policy" to
>>> "Explicit NULL Label Behavior"? The word "policy" here gets tangled
>>> with "SR Policy".
>>>
>>>
>>>
>>> KT> This is related to SR Policy with the SR-MPLS data plane.
>>>
>>>
>>>
>>>
>>>
>>>
>>> When should the BGP update stops being propagated if RT is used?
>>> Never? or should a matching RT be removed by each matching receiver
>>> and then the propagation stops when there is no RT left?
>>>
>>>
>>>
>>> KT> Yes, it can do that using local configuration. See the next
>>> paragraph.
>>>
>>>
>>>
>>>
>>>    By default, a BGP node receiving an SR Policy NLRI SHOULD NOT remove
>>>    route target extended community before propagation.  An
>>>    implementation MAY provide support for configuration to filter and/or
>>>    remove route target extended community before propagation.
>>>
>>> Isn't the above applicable to any AFI/SAFI? Why do we need to specify
>>> that?
>>>
>>>
>>>
>>> KT> It goes with the previous paragraph - hence required to clarify.
>>>
>>>
>>>
>>> Zzh> 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.
>>>
>>
>> KT2> 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.
>>
>>
>>>
>>>
>>>
>>> 5.  Error Handling and Fault Management
>>>
>>>    A BGP Speaker MUST perform the following syntactic validation of the
>>>    SR Policy NLRI to determine if it is malformed.  This includes the
>>>    validation of the length of each NLRI and the total length of the
>>>    MP_REACH_NLRI and MP_UNREACH_NLRI attributes.  It also includes the
>>>    validation of the consistency of the NLRI length with the AFI and the
>>>    endpoint address as specified in Section 2.1.
>>>
>>>    When the error determined allows for the router to skip the malformed
>>>    NLRI(s) and continue the processing of the rest of the update
>>>    message, then it MUST handle such malformed NLRIs as 'Treat-as-
>>>    withdraw'.  In other cases, where the error in the NLRI encoding
>>>    results in the inability to process the BGP update message (e.g.
>>>    length related encoding errors), then the router SHOULD handle such
>>>    malformed NLRIs as 'AFI/SAFI disable' when other AFI/SAFI besides SR
>>>    Policy are being advertised over the same session.  Alternately, the
>>>    router MUST perform 'session reset' when the session is only being
>>>    used for SR Policy or when it 'AFI/SAFI disable' action is not
>>>    possible.
>>>
>>> Is the above generic BGP handling?
>>>
>>>
>>>
>>> KT> Yes, per RFC7606 this needs to be defined for new SAFIs.
>>>
>>>
>>>
>>>
>>>    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 of any error 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 (comprising of all
>>>    valid TLVs/sub-TLVs) is not usable.
>>>
>>> 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?
>>>
>>>
>>>
>>> KT> No, it does not. There is a line between what validation is done by
>>> BGP and what is done by SRPM.
>>>
>>> Zzh> My understanding is that “treat-as-withdraw” is BGP handling (BGP
>>> tells SRPM the route is withdrawn) – that’s why I thought that there was a
>>> conflict.
>>>
>>> Zzh> Are you saying that it is ok for BGP not to treat it as withdrawal
>>> but for SRPM to treat it as withdrawal (due to the validation in Section
>>> 2.4)?
>>>
>>
>> KT2> SRPM does not have the concept of "treat it as withdraw". It does
>> have the concept of "invalid CP or SL" as specified in RFC9256 and that is
>> how it would handle such semantic errors.
>>
>> Thanks,
>> Ketan
>>
>>
>>> Zzh> Thanks.
>>>
>>> Zzh> Jeffrey
>>>
>>>
>>>
>>>
>>>    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.
>>>
>>>
>>>
>>> Juniper Business Use Only
>>>
>>