[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)

[[e-mail]]

Hi Joel,

Thanks for your remind!

Since the path segment may be configured with SR Policy through PCEP, as a co-author of draft-ietf-pce-sr-path-segment, I suggest to add some texts in this draft to clarify the process and information related to the Association and SR Policy.

What is your thoughts?Thanks!

Best Regards,
Quan



Original


From: JoelHalpern <[e-mail]>
To: 熊泉00091065;[e-mail] <[e-mail]>;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2024年08月20日 22:16
Subject: Re: [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)

Should the draft be clearer about what control messages the tail will have received in each case, and which field from those messages it will compare with the fields defined in this draft?  For example, this email says that it needs to look at the PCE Association information.  How was the reader to realize that?
Yours,
Joel
On 8/20/2024 4:39 AM, [e-mail] wrote:
 



Hi Greg,
 
From my view, as shown in figure 3,4 and 5 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 
 
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
 
 
 




 _______________________________________________ mpls mailing list -- [e-mail] To unsubscribe send an email to [e-mail] 


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. 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
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…  Tarek Saad

[mpls] Re: Working Group Last Call on draft-xp-mp…  Greg Mirsky

[mpls] Working Group Last Call for draft-ietf-mpl…  Tarek Saad

[mpls] Re: Working Group Last Call for draft-ietf…  Greg Mirsky

[mpls] Re: Working Group Last Call for draft-ietf…  xiao.min2

[mpls] Re: Working Group Last Call for draft-ietf…  Greg Mirsky

[mpls] Re: Working Group Last Call for draft-ietf…  xiao.min2

[mpls] Re: Working Group Last Call for draft-ietf…  Greg Mirsky

[mpls] Re: Working Group Last Call for draft-ietf…  xiao.min2

[mpls] Re: Working Group Last Call for draft-ietf…  Greg Mirsky

[mpls] Re: Working Group Last Call for draft-ietf…  xiao.min2

[mpls] Re: Working Group Last Call for draft-ietf…  xiao.min2

[mpls] Re: Working Group Last Call for draft-ietf…  peng.shaofu

[mpls] Re: Working Group Last Call for draft-ietf…  Rakesh Gandhi

[mpls] Re: Working Group Last Call for draft-ietf…  Liyan Gong

[mpls] Re: Working Group Last Call for draft-ietf…  Greg Mirsky

[mpls] Re: Working Group Last Call for draft-ietf…  Greg Mirsky

[mpls] Re: Working Group Last Call on draft-xp-mp…  高星(联通集团本部)