[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 Yao,
thank you for pointing that helpful text in draft-ietf-idr-sr-policy-safi
to me. It seems to me that the current form of the BGP draft doesn't ensure
that the extension of LSP ping defined
in draft-ietf-mpls-spring-lsp-ping-path-sid will perform its intended
function for a BGP SR Policy. Particularly, in the case when an SR Policy
is distributed by the SR Policy Controller, draft-ietf-idr-sr-policy-safi
appears ambiguous on whether the controller is required to distribute
policy to the endpoint as well as to the headend of that policy. Also, it
would be helpful to use normative language in the description of cases that
use a Route Reflector.
And because the in-depth understanding of draft-ietf-idr-sr-policy-safi is
critical for implementing draft-ietf-mpls-spring-lsp-ping-path-sid, the BGP
drafts must be used as Normative references.

Regards,
Greg

On Mon, Aug 19, 2024 at 9:36 PM <[e-mail]> wrote:

> Hi Greg,
>
>
> If the question is how the "headend" information is carried in the BGP
> signaling, accordingly to
> <https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi>
> <https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi>
> <https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi>
> <https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi>
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi
> section 1, there're several cases:
>
> 1）Typically, a SR Policy Controller defines the set of policies and
> advertises them to policy headend routers, such an advertisement may be
> sent on a BGP session to that headend. So the BGP peer address indicates
> the headend in this case.
>
> 2) Alternatively, a router (i.e., a BGP egress router) advertises SR
> Policies representing paths to itself. In this case, it is possible to send
> the policy to each headend over a BGP session to that headend.  The
> headend is still indicated by the  BGP peer address in this case.
>
> 3) In some situations, it is undesirable for a controller or BGP egress
> router to have a BGP session to each policy headend. To make this possible,
> an attribute needs to be attached to the advertisement that enables a BGP
> speaker to determine whether it is intended to be a headend for the
> advertised policy. This is done by attaching one or more Route Target
> Extended Communities to the advertisement. So the route target extended
> community indicates the headend in this case.
>
>
> Yao
>
>
> Original
> *From: *GregMirsky <[e-mail]>
> *To: *肖敏10093570;
> *Cc: *[e-mail] <[e-mail]>;[e-mail] <
> [e-mail]>;[e-mail] <
> [e-mail]>;
> *Date: *2024年08月20日 11:42
> *Subject: **[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)*
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Hi Xiao Min,
> yes, Quan's information is helpful but the relationship between the
> ASSOCIATION object of the SR Policy and flow charts in
> https://datatracker.ietf.org/doc/draft-ietf-pce-sr-path-segment/ is not
> yet clear to me. I hope that we Quan will clarify that. In the meantime,
> perhaps you can clarify the scenario when the source of the SR Policy is
> BGP.
>
> Regards,
> Greg
>
> On Mon, Aug 19, 2024 at 8:17 PM <[e-mail]> wrote:
>
>> Hi Greg,
>>
>>
>> Thanks for the further clarification on your concern.
>>
>> Please see inline.
>> 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月20日 07:32
>> *Subject: **[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)*
>> _______________________________________________
>> mpls mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>> Dear All,
>>
>> I paused to arrange my concerns about the draft and put them in front of
>> you more clearly. Below is what it came to:
>>
>>    -
>>
>>    The purpose of Target FEC Stack TLV in LSP echo request, as I
>>    understand it, is to verify consistency between the data plane and the
>>    control plane view of the data plane. That is why the sender of an echo
>>    request with Target FEC Stack TLV includes a sub-TLV that, from the
>>    sender's perspective, sufficiently represents the control plane information
>>    associated with the verifiable label.
>>
>>    [XM]>>> Yes, that's correct.
>>
>>    -
>>
>>    If the above is correct, I move to the next point. All sub-TLVs in
>>    the Target FEC Stack TLV must be validated. The validation process is
>>    sub-TLV-specific. This draft defines the validation process, using PCEP as
>>    an example, as follows:
>>
>> *  Validate that the signaled headend, color, end-point,
>>
>> originator ASN, originator address, and discriminator
>>
>> defined in [I-D.ietf-pce-segment-routing-policy-cp]
>>
>> and [I-D.ietf-pce-sr-path-segment], for the PSID,
>>
>> matches with the corresponding fields in the received
>>
>> SR Candidate Path's PSID sub-TLV.
>>
>> Now, my question: What is meant as validation of Headend?
>>
>>    -
>>
>>    The reason for my question above is that I cannot find that the
>>    identity of the Headend is included in PCEP constructs defined for the
>>    configuration of an SR Policy. Am I missing something in PCE-related
>>    specifications, or must they be enhanced to convey the identity of the SR
>>    Policy's Headend?
>>
>>    [XM]>>> As PCEP expert Quan has responded to you, there is *Headend*
>>    included in PCEP for SR Policy.
>>    -
>>
>>    There's a possible way to use information already available in the
>>    IP-encapsulated echo request message and source IP address. Personally, I
>>    would consider such a check a security measure rather than validation, but
>>    how would validation work if no IP/UDP encapsulation of the echo request is
>>    used?
>>
>>    [XM]>>> Considering there is *Headend* included in PCEP for SR
>>    Policy, the information in the header of echo request is not needed.
>>
>> I hope that I made my concern more evident now. I welcome your comments
>> and questions.
>>
>> [XM]>>> Yes, your concern is more evident to me. Hope the responses can
>> resolve your concern. :-)
>>
>>
>> Cheers,
>>
>> Xiao Min
>>
>>
>> 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]
>>>
>>
>>
>