[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 an opportunity to clarify my position on the WG LC of this
draft. Please find my notes below tagged GIM>>.

Regards,
Greg

On Tue, Aug 13, 2024 at 8:12 PM <[e-mail]> wrote:

> Hi Greg,
>
>
> Thank you for the continued discussion.
>
> Please see inline.
> Original
> *From: *GregMirsky <[e-mail]>
> *To: *肖敏10093570;
> *Cc: *[e-mail] <[e-mail]>;[e-mail] <
> [e-mail]>;[e-mail] <[e-mail]>;
> [e-mail] <
> [e-mail]>;
> *Date: *2024年08月14日 00:00
> *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 Xiao Min,
> I've reviewed the new version. My conclusions of the discussion and
> updates:
>
>    -
>
>    I believe that a protocol specification (or enhancement of a protocol)
>    must enable an implementor to develop operational and interoperable
>    product. I don't see that the current version of the draft reaches to that
>    level in many instances that I pointed out in my review.
>
>    [XM]>>> It seems to me that your major concern is that unless the
>    referenced control protocol extensions for path segment, such as PCEP and
>    BGP extensions, are all published, this document can't be progressed. I've
>    argued that's not necessary and explained the reason. RFCs 9545 and 9256
>    have provided all the information needed to encode the new sub-TLVs defined
>    in this document.
>
> GIM>> The issue of not listing essential references as Normative is one
but notmain of my concerns with this document. I believe that a
specification of a protocol or protocol extension, i.e., the document that
is the basis for an implementation, must explicitly list, document each and
every step of the processing to be implemented by a developer. References
are not sufficient replacement to explicit documentation of the processing
that MUST, SHOULD, or MAY be taken. For example, if value of field Headend
must be validated, I expect the document to explicitly name how that
validation value is obtained, i.e., which field in PCEP or BGP NLRI must be
used. And that goes step by step throughout the process.

>
>    -
>
>    I find that the update regarding the applicability of SR Policy's
>    PSID, SR Candidate Path's PSID, and SR Segment List's PSID sub-TLVs:
>
> When a sub-TLV defined in this document is carried in Reverse-Path Target
> FEC Stack TLV (Type 16) or Reply Path TLV (Type 21), it MUST be sent by an
> endpoint in an echo reply. The headend MUST perform validity checks as
> described above without setting the return code. If any of the validations
> fail, then the headend MUST drop the echo reply and SHOULD log and/or
> report an error.
>
> introduces a new issue. I believe that RFC 7110 defines Return Path TLV to
> be used by the sender of an MPLS LSP echo request, not by the sender of
> echo reply as suggested in the new text.
> [XM]>>> In Section 5.3 of RFC 7110, it says "When sending the echo reply,
> a Reply Path TLV that identifies the return path MUST be carried".
>
>
> In summary, my concerns are not addressed and new issues introduced by the
> latest update. I don't support progressing the draft in its current form.
>
> [XM]>>> Before progressing this document, we could wait for the
> publications of documents describing all kinds of control protocol
> extensions for path segment. But I don't see much value for that wait.
>
GIM>> As I explained above, listing essential documents as Normative
references is not the main of my concerns with this draft.

>
> Cheers,
>
> Xiao Min
>
>
> Regards,
> Greg
>
> On Mon, Aug 12, 2024 at 8:27 PM <[e-mail]> wrote:
>
>> Hi Greg,
>>
>>
>> I've posted a new version of this draft, attempting to address your
>> comments. Link as below.
>>
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-mpls-spring-lsp-ping-path-sid-02
>>
>> Please see inline with [XM-2]>>>.
>> Original
>> *From: *GregMirsky <[e-mail]>
>> *To: *肖敏10093570;
>> *Cc: *[e-mail] <[e-mail]>;[e-mail] <
>> [e-mail]>;[e-mail] <[e-mail]>;
>> [e-mail] <
>> [e-mail]>;
>> *Date: *2024年08月13日 06:18
>> *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 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?
>>
>> [XM-2]>>> Please refer to draft-ietf-idr-sr-policy-path-segment.
>>
>>>
>>>
>>>    -
>>>
>>>    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.
>>
>> [XM-2]>>> Sorry but I don't catch your point. It seems to me Section 4
>> describes the needed PSID FEC validation procedures.
>>
>>
>>
>>>    -
>>>
>>>    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.
>>
>> [XM-2]>>> I believe this document has done its job by referencing the
>> source of information.
>>
>>
>>
>>>    -
>>>
>>>       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.
>>
>> [XM-2]>>> IMHO it's appropriate to have RFC 9545 and RFC 9256 as
>> normative references and have other specific control protocol extensions as
>> informative references, because the specific encodings of control protocols
>> won't affect this document.
>>
>>>
>>>
>>>    -
>>>
>>>    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).
>>
>> [XM-2]>>> Please refer to draft-ietf-pce-sr-path-segment and
>> draft-ietf-idr-sr-policy-path-segment.
>>
>>
>>
>>>    -
>>>
>>>    -
>>>
>>>    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.
>>
>> [XM-2]>>> I checked draft-ietf-mpls-sr-epe-oam which is in RFC editor's
>> queue, and I didn't find any text clarifying how to apply the new sub-TLVs
>> to TLVs 16 and 21. However, I believe it's helpful to the
>> reader/implementer if some clarification text can be added, so a new
>> paragraph was added to the end of Section 4 of this document.
>>
>>
>> Best Regards,
>>
>> Xiao Min
>>
>>>
>>> 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]
>>>>
>>>
>>>
>>
>