[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,
I will quote the IESG Statement: Normative and Informative References
<https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-normative-and-informative-references-20060419/#:~:text=Within%20an%20RFC%2C%20references%20to,the%20technology%20in%20the%20RFC.>
:

Within an RFC, references to other documents fall into two general
categories: "normative" and "informative". Normative references specify
documents that must be read to understand or implement the technology in
the new RFC, or whose technology must be present for the technology in the
new RFC to work. An informative reference is not normative; rather, it only
provides additional information. For example, an informative reference
might provide background or historical information. Informative references
are not required to implement the technology in the RFC.

Note 1: Even references that are relevant only for optional features must
be classified as normative if they meet the above conditions for normative
references.

I believe that PCE and BGP documents referenced in the relationship to the
validation process must be normative, not informative, even if that will
cause dependency and may delay the publication of this draft.

Furthermore, I believe that there exist a fundamental problem with BGP SR
Policy as explained in my discussion with Yao Liu
<https://mailarchive.ietf.org/arch/msg/mpls/sOk9r3FkcSF6zvIw4Gv-znJ3OGo/>.
I believe that cases when an endpoint of an BGP SR Policy are not
informaed of the BGP SR Policy must be discussed by the MPLS and IDR WGs
and reflected in this draft accordingly.

Regards,
Greg

On Tue, Aug 20, 2024 at 7:02 PM <[e-mail]> wrote:

> Hi Greg,
>
>
> Glad to know Quan's responses satisfactorily answer your questions. Thanks
> to Quan!
>
> Now it seems your concern goes back to that you think PCEP and BGP specs
> must be listed as normative references.
>
> I disagree with that and I'd like to repeat the reasons as below.
>
> * This is an LSP Ping document and introducing PCEP and BGP encoding
> details is overspecified.
>
> * RFC 9256 and 9545 provide enough basis to this document, how the
> necessary fields are encoded in PCEP and BGP won't affect how the
> interoperable LSP Ping works.
>
> * Waiting for the publications of PCEP and BGP specs won't bring much
> value to this document.
>
>
> Best Regards,
>
> Xiao Min
> Original
> *From: *GregMirsky <[e-mail]>
> *To: *熊泉00091065;
> *Cc: *[e-mail] <[e-mail]>;[e-mail] <
> [e-mail]>;[e-mail] <
> [e-mail]>;
> *Date: *2024年08月21日 06:14
> *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 Quan,
> thank you for your patience and the detailed response, it is clear to me
> now how the PCE configures an SR Policy at its headend and endpoint.
> Considering that in-depth understanding of PCE is critical for producing an
> interoperable implementation of this draft, I strongly believe that RFC
> 8697, draft-ietf-pce-segment-routing-policy-cp,
> and draft-ietf-pce-sr-path-segment must be listed as the Normative
> references.
>
> Regards,
> Greg
>
> On Tue, Aug 20, 2024 at 1:39 AM <[e-mail]> wrote:
>
>>
>> Hi Greg,
>>
>>
>> From my view, as shown in figure 3,4 and 5 draft-ietf-pce-sr-path-segment
>> <https://datatracker.ietf.org/doc/draft-ietf-pce-sr-path-segment/>, the
>> PCE will send PCInitiate message to Egress PCC. And the  PCInitiate message
>> will not only include the PATH-SEGMENT TLV in the LSP object, but also
>> carry the association object. As specified in RFC8697 section 6.3.1 [1],
>> the PCInitiate message is as following shown.
>>
>>
>> <PCE-initiated-lsp-instantiation> ::= <SRP>                                       <LSP>                                       [<END-POINTS>]                                       <ERO>                                       [<association-list>]                                       [<attribute-list>]
>> Where:
>> <association-list> ::= <ASSOCIATION> [<association-list>]
>>
>> [1]
>> <https://www.rfc-editor.org/rfc/rfc8697.html#name-stateful-pcep-messages>
>> https://www.rfc-editor.org/rfc/rfc8697.html#name-stateful-pcep-messages
>>
>>
>> From this message, the LSP object will include PATH-SEGMENT TLV and the
>> ASSOCIATION object which is related to the SR policy will carry the
>> assication source (headend).
>>
>> Hope that will help! Thanks!
>>
>>
>> Best,
>>
>> Quan
>>
>>
>>
>> *From: *GregMirsky <[e-mail]>
>> *To: *熊泉00091065;
>> *Cc: *[e-mail] <[e-mail]>;[e-mail] <
>> [e-mail]>;[e-mail] <
>> [e-mail]>;
>> *Date: *2024年08月20日 11:39
>> *Subject: **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)*
>> Hi Quan,
>> thank you for clarifying that to me. I hope that you can help me in
>> understanding how the ASSOCIATION object of SR Policy type is related to
>> figures 3, 4, and 5 draft-ietf-pce-sr-path-segment
>> <https://datatracker.ietf.org/doc/draft-ietf-pce-sr-path-segment/>.
>> AFAICS, only flow of PATH-SEGMENT TLV from PCEP to PCC in both headend and
>> endpoint of the SR Policy is reflected in these figures. At which phase the
>> ASSOCIATION object is communicated to the endpoint?
>>
>> Regards,
>> Greg
>>
>> On Mon, Aug 19, 2024 at 7:59 PM <[e-mail]> wrote:
>>
>>> Hi Greg,
>>>
>>>
>>> Thanks for your questions!
>>>
>>>
>>> The identity of the SR Policy's Headend has been proposed in
>>> the PCE-related specifications. As per
>>> draft-ietf-pce-segment-routing-policy-cp section 4.1 [1], the headend is
>>> encoded in the 'Association Source' field in the ASSOCIATION object. The
>>> color and endpoint are encoded as part of the Extended Association ID TLV.
>>>
>>>
>>> [1]
>>> https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-17.html#name-association-parameters
>>>
>>>
>>> Thanks,
>>>
>>> Quan
>>>
>>>
>>>
>>>
>>>
>>> [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]> Mon, 19 August 2024 23:32 UTCShow
>>> header <https://mailarchive.ietf.org/arch/browse/mpls/#>
>>>
>>> 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.    - 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?    - 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?  I hope that I made my concern more evident now. I welcome your comments and questions.   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]>
>>>
>>>
>>>    -
>>>
>>>    [mpls] Working Group Last Call on draft-xp-mpls-s…
>>>    <https://mailarchive.ietf.org/arch/msg/mpls/m8JQNhCgDBY-H00-QyVynL0xQlA/>  Tarek
>>>    Saad
>>>    -
>>>
>>>    [mpls] Re: Working Group Last Call on draft-xp-mp…
>>>    <https://mailarchive.ietf.org/arch/msg/mpls/Ff_fzOQftAUJE1OCOo9MfOuC8Ss/>  Greg
>>>    Mirsky
>>>    -
>>>
>>>    [mpls] Working Group Last Call for draft-ietf-mpl…
>>>    <https://mailarchive.ietf.org/arch/msg/mpls/p2PCHcqHFUoxgzHjEwXryCKxDbA/>  Tarek
>>>    Saad
>>>    -
>>>
>>>    [mpls] Re: Working Group Last Call for draft-ietf…
>>>    <https://mailarchive.ietf.org/arch/msg/mpls/DK8cuGulr1TrlASamaglObTmbg8/>  Greg
>>>    Mirsky
>>>    -
>>>
>>>    [mpls] Re: Working Group Last Call for draft-ietf…
>>>    <https://mailarchive.ietf.org/arch/msg/mpls/F8T-os4HjPjp-1NGNSJBolEXPoc/>
>>>      xiao.min2
>>>    -
>>>
>>>    [mpls] Re: Working Group Last Call for draft-ietf…
>>>    <https://mailarchive.ietf.org/arch/msg/mpls/8Tl8qbEQKpOlX-c1_wKJZ4HkqEo/>  Greg
>>>    Mirsky
>>>    -
>>>
>>>    [mpls] Re: Working Group Last Call for draft-ietf…
>>>    <https://mailarchive.ietf.org/arch/msg/mpls/yd4wenJ-KjeCa240cQ2VsEA5G4k/>
>>>      xiao.min2
>>>    -
>>>
>>>    [mpls] Re: Working Group Last Call for draft-ietf…
>>>    <https://mailarchive.ietf.org/arch/msg/mpls/yXlc5ISwgAW02oekDr9-ZWanJ64/>  Greg
>>>    Mirsky
>>>    -
>>>
>>>    [mpls] Re: Working Group Last Call for draft-ietf…
>>>    <https://mailarchive.ietf.org/arch/msg/mpls/qeTEZYtA6LJCRUxE_h-6IMGRz_E/>
>>>      xiao.min2
>>>    -
>>>
>>>    [mpls] Re: Working Group Last Call for draft-ietf…
>>>    <https://mailarchive.ietf.org/arch/msg/mpls/NTttA8bnUMI4cKSWtPFaZImWl5M/>  Greg
>>>    Mirsky
>>>    -
>>>
>>>    [mpls] Re: Working Group Last Call for draft-ietf…
>>>    <https://mailarchive.ietf.org/arch/msg/mpls/SucCkKTNej4mc3SxCDkkr0oFm_c/>
>>>      xiao.min2
>>>    -
>>>
>>>    [mpls] Re: Working Group Last Call for draft-ietf…
>>>    <https://mailarchive.ietf.org/arch/msg/mpls/709_ilwfE6y1N6nmjUnjF247tP4/>
>>>      xiao.min2
>>>    -
>>>
>>>    [mpls] Re: Working Group Last Call for draft-ietf…
>>>    <https://mailarchive.ietf.org/arch/msg/mpls/lIvQv4arUk3NYY5kKOno_NV7w_g/>
>>>      peng.shaofu
>>>    -
>>>
>>>    [mpls] Re: Working Group Last Call for draft-ietf…
>>>    <https://mailarchive.ietf.org/arch/msg/mpls/8DxWMSU9ijaGNKboey9eIoilgF8/>  Rakesh
>>>    Gandhi
>>>    -
>>>
>>>    [mpls] Re: Working Group Last Call for draft-ietf…
>>>    <https://mailarchive.ietf.org/arch/msg/mpls/FPJ-e6_mgFmLqhEHIn-Qgz11k9A/>  Liyan
>>>    Gong
>>>    -
>>>
>>>    [mpls] Re: Working Group Last Call for draft-ietf…
>>>    <https://mailarchive.ietf.org/arch/msg/mpls/8ARNsP7UrjxIpBpwpR_OgbbalGI/>  Greg
>>>    Mirsky
>>>    -
>>>
>>>    [mpls] Re: Working Group Last Call for draft-ietf…
>>>    <https://mailarchive.ietf.org/arch/msg/mpls/PsDO75uvugDPLWClOT5Qk3Tb8Kw/>  Greg
>>>    Mirsky
>>>    -
>>>
>>>    [mpls] Re: Working Group Last Call on draft-xp-mp…
>>>    <https://mailarchive.ietf.org/arch/msg/mpls/31q68-_0N7hOOBa0ErNOSSQfn7M/>
>>>      高星(联通集团本部)
>>>
>>>
>>>
>>
>