[mpls] Re: Working Group Last Call for draft-ietf-mpls-spring-lsp-ping-path-sid (was Re: Working Group Last Call on draft-xp-mpls-spring-lsp-ping-path-sid)

[Greg Mirsky <[e-mail]>]

Hi Xiao Min,
thank you for your response. Please find my follow-up notes below tagged
GIM>>.

Regards,
Greg

On Mon, Aug 12, 2024 at 2:21 AM <[e-mail]> wrote:

> Hi Greg,
>
>
> Thanks for your review and thoughtful comments.
>
> Please see inline with [XM]>>>.
> Original
> *From: *GregMirsky <[e-mail]>
> *To: *Tarek Saad <[e-mail]>;
> *Cc: *[e-mail] <[e-mail]>;MPLS Working Chairs <
> [e-mail]>;[e-mail] <
> [e-mail]>;
> *Date: *2024年08月09日 08:40
> *Subject: **Re: [mpls] Working Group Last Call for
> draft-ietf-mpls-spring-lsp-ping-path-sid (was Re: Working Group Last Call
> on draft-xp-mpls-spring-lsp-ping-path-sid)*
>
> Hi Tarek,
>
> I read the current version of the draft, and I have a number of questions
> for the authors and the WG. Please kindly consider my notes below as WG LC
> comments:
>
>    -
>
>    LSP Ping is intended to verify consistency between the data and
>    control planes at the destination node. Unlike IP/MPLS, SR-MPLS doesn't
>    create a state related to an SR Policy on the egress LSR. If so, what
>    problem can be solved using the extensions proposed in this draft to the
>    Target FEC Stack TLV?
>
>    [XM]>>> For MPLS Path Segment Identifier defined in RFC 9545, the
>    egress LSR needs to create a state, please refer to Figure 3, 4, 5, and 6
>    of draft-ietf-pce-sr-path-segment.
>
> GIM>> Thank you for clarifying the case when PSID is distributed using
PCEP. What is the case with the BGP SR Policy?

>
>
>    -
>
>    From reading Section 4, it appears that the context of PSID is derived
>    from the sub-TLV's. Does that mean the same PSID value may be used as SR
>    Policy's PSID, Candidate Path's PSID, and Segment List's PSID? If that is
>    not the case, should the egress LSR be aware of the context of the received
>    PSID without the assistance of the PSID FEC sub-TLV?
>
>    [XM]>>> No, that's not the case. The egress LSR uses the PSID FEC
>    sub-TLV to perform validation, before that, the egress LSR is aware of the
>    context of the received PSID.
>
> GIM>> That is not how the validation of the new sub-TLV is described in
Section 4. If the SR Policy's, SR Candidate Path's, and SR Segment List's
PSIDs are all unique, then the egress must verify that the received PSID
label and the new sub-TLV are in sync with the view in the egress' control
plane.

>
>    -
>
>    The intention of the validation is to ensure that the ingress LSR and
>    the egress LSR have the same understanding.
>
>
>
>    -
>
>    SR Policy's PSID sub-TLV validation is described as follows:
>
> +  Validate that the signaled or provisioned headend, color
>
> and end-point for the PSID, matches with the
>
> corresponding fields in the received SR Policy's PSID
>
> sub-TLV.
>
>    -
>
>
>    -
>
>       Can you give an example of signaled SR Policy PSID's Headend,
>       Color, and Endpoint values? Which document defines such a signaling
>       mechanism?
>
>       [XM]>>> Please refer to draft-ietf-pce-sr-path-segment.
>
> GIM>> I don't think that is how the document can be published. The
document must clearly describe the source of information used to validate
new sub-TLV.

>
>    -
>
>       This step appears underdeveloped, which may cause interoperability
>       issues between implementations.
>
>       [XM]>>> Note that draft-ietf-pce-sr-path-segment is not a normative
>       reference. RFC 9545 and RFC 9256 provide the necessary context on the
>       relationship between PSID and SR Policy.
>
> GIM>> If that is the case, please map fields in this sub-TLV to RFC 9545
and 9256. Otherwise, make draft-ietf-pce-sr-path-segment Normative (as well
as all documents referenced in Section 4 as essential to the validation
processing) and map these fields to IEs defined in draft-ietf-pce-sr-path-
segment.

>
>
>    -
>
>    Can you clarify how the endpoint of the SR Policy validates the
>    Headend if the value of the Protocol-Origin field is either PCE or BGP SR
>    Policy?
>
>    [XM]>>> As said above, the endpoint has a state of the PSID. It knows
>    the mapping between the PSID and the headend.
>
> GIM>> AFAICS, draft-ietf-pce-segment-routing-policy-cp does not identify
Headend but only Endpoint. Similarly, SR Policy defined in BGP doesn't
identify the Headend. (Note that I-D.ietf-idr-segment-routing-te-policy is
outdated and the draft has been replaced).

>
>    -
>
>    -
>
>    The new sub-TLVs are attributed to the "Sub-TLVs for TLV Types 1, 16,
>    and 21" registry in the IANA Consideration section. However, the document
>    specifies using new sub-TLVs only for TLV Type 1 (Target FEC Stack). It
>    appears that the new sub-TLVs are left underspecified for TLVs 16
>    (Reverse-path Target FEC Stack) and 21 (Reply Path).
>
>    [XM]>>> Good catch. After thinking about it, I believe the new
>    sub-TLVs can also be carried in TLVs 16 and 21 of echo reply when the echo
>    reply carries PSID. In this case, considering the PSID FEC validation is
>    almost the same to what's specified in Section 4, I propose to add some
>    clarification text to Section 4 stating that the PSID FEC validation also
>    applies to TLVs 16 and 21 of echo reply, does that make sense?
>
> GIM>> I believe the WG must discuss this because it could impact TLVs 16
and 21.

>
> Cheers,
>
> Xiao Min
>
>
> Although LSP Ping is developed by the MPLS WG, the proposed new
> enhancements are clearly related to SR-MPLS. I cannot recall this proposal
> being vetted by the SPRING WG. It seems that in the spirit of cooperation
> of the Routing Area, comments from the experts in the SPRING WG would be
> welcomed.
>
>
>
> Regards,
>
> Greg
>
> On Tue, Aug 6, 2024 at 10:13 AM Tarek Saad <[e-mail]> wrote:
>
>> Hi WG,
>>
>>
>>
>> I am correcting a mistake to reference to the WG adopted draft (as
>> opposed to the individual draft for the same document). Sorry for the
>> confusion.
>>
>>
>>
>> Regards,
>>
>> Tarek
>>
>>
>>
>> *From: *Tarek Saad <[e-mail]>
>>
>> *Date: *Tuesday, August 6, 2024 at 9:53 AM
>> *To: *[e-mail] <[e-mail]>
>> *Cc: *MPLS Working Chairs <[e-mail]>,
>> [e-mail] <
>> [e-mail]>
>> *Subject: *Working Group Last Call on
>> draft-xp-mpls-spring-lsp-ping-path-sid
>>
>> Dear WG,
>>
>>
>>
>> This email starts a two-week working group last call for
>> draft-ietf-mpls-spring-lsp-ping-path-sid
>> <https://datatracker.ietf.org/doc/draft-ietf-mpls-spring-lsp-ping-path-sid/>
>> .
>>
>>
>>
>> Please indicate your support or concern for this draft. If you are
>> opposed to the progression of the draft to RFC, please articulate your
>> concern. If you support it, please indicate that you have read the latest
>> version, and it is ready for publication in your opinion. As always, review
>> comments and nits are most welcome.
>>
>>
>>
>> Please send your comments to the mpls wg mailing list ([e-mail])
>>
>> If necessary, comments may be sent unidirectional to the WG chairs.
>>
>>
>>
>> Note, currently there are no IPR disclosures
>> <https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-xp-mpls-spring-lsp-ping-path-sid>
>> against this document.
>>
>>
>>
>> This poll runs until August 20, 2024.
>>
>>
>>
>> Thank you,
>>
>> Tarek (for the MPLS WG co-chairs)
>>
>>
>> _______________________________________________
>> mpls mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>
>