(just small update – dropped some copy pasted statements from my response as I finally responded with inline comments)
Regards, Samuel From: Samuel Sidor (ssidor) <ssidor=40cisco....@dmarc.ietf.org> Sent: Tuesday, February 14, 2023 1:27 PM To: Dhruv Dhody <d...@dhruvdhody.com> Cc: pce-chairs <pce-cha...@ietf.org>; Samuel Sidor (ssidor) <ssi...@cisco.com>; pce@ietf.org Subject: RE: LSP identifiers TLV optional for SR in RFC8664 Hi Dhruv, Thanks a lot, for your comments. Please see inline <S>. Regards, Samuel From: Dhruv Dhody <d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>> Sent: Tuesday, February 14, 2023 12:29 PM To: Samuel Sidor (ssidor) <ssi...@cisco.com<mailto:ssi...@cisco.com>> Cc: pce-chairs <pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>>; Samuel Sidor (ssidor) <ssidor=40cisco....@dmarc.ietf.org<mailto:ssidor=40cisco....@dmarc.ietf.org>>; pce@ietf.org<mailto:pce@ietf.org> Subject: Re: LSP identifiers TLV optional for SR in RFC8664 Hi Samuel, The feeling at the time was to get away from the RSVP-TE-thinking for SR (and allow SR paths to be set up with minimal information needed). If I recall correctly, the "MAY" was the "compromise" struck at the time to allow SR paths to be set up without it but when use cases require these the LSP-IDENTIFIER-TLV can be included. <S> Problem here is that there are still many cases, when endpoints belong into category of “minimal information”, but at least I have context now – I was not able to find any discussion in mail archive about it. On Tue, Feb 14, 2023 at 3:02 PM Samuel Sidor (ssidor) <ssi...@cisco.com<mailto:ssi...@cisco.com>> wrote: Hi PCE-chairs, Since there is no reasonable explanation provided in the mailing list – does that mean that RFC is “broken” and we need Errata to fix it? E.g. by making LSP identifiers TLV mandatory? Errata would not be the right approach. See https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/ If the WG wants an explicit statement we would need to add this in an existing WG document or propose a new one. <S> Reason for proposing Errata was because I personally considered it as a “bug” in that RFC and statement above is specifically describing it for such purpose: “Errata are meant to fix "bugs" in the specification and should not be used to change what the community meant when it approved the RFC. Here are some things to consider when submitting an errata report:” Thanks, Samuel From: Pce <pce-boun...@ietf.org<mailto:pce-boun...@ietf.org>> On Behalf Of Samuel Sidor (ssidor) Sent: Thursday, February 9, 2023 1:29 PM To: pce@ietf.org<mailto:pce@ietf.org> Subject: [Pce] LSP identifiers TLV optional for SR in RFC8664 Hi PCE WG, RFC8664 marked LSP identifiers TLV as optional: “The LSP-IDENTIFIERS TLV MAY be present for the above PST type.” https://www.rfc-editor.org/rfc/rfc8664.html#name-the-rp-srp-object But I don’t see any clarification in that RFC, how SR policy endpoints/LSP-ID (may be needed for MBB) or any other field from that TLV is supposed to be encoded in PCRpt message. I can imagine that SR policy endpoints can be retrieved from SR policy association (https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp#section-5.1), but that draft is still not supported by many implementations and it is not mentioned as MUST in RFC8664. Specifically about endpoints, for PCC configured SR path you have it via local configuration and for the PCE-initiated, END-POINTS object could also be optionally included in PCInitiate message. <S> For PCC configured – we have it in local configuration on headend/PCC, but PCE does not have it in case of delegation of path-computation to PCE and that is the important part (since we are talking about messages in PCEP). Consider for example LSP delegated in down state (empty ERO included) , in such case, it may be impossible to derive destination address. Also policy source address does not have to be same as PCEP peer address, so that can be missing as well. In case of PCE initiated, again same thing – if I have multiple PCEs in the network, then PCE, which hasn’t created that policy will not see END-POINTS object included in original PCinitiate message, so sending report messages from PCC to other PCEs is useless without having another synchronization mechanism between PCEs. So now it seems to be completely valid based on RFC8664 to send PCRpt with no LSP identifiers and no SR Policy association => with missing endpoints. Is that intentional or am I missing any statement from RFC, which is clarifying it? IMHO It is intentional. See para 4 at https://www.rfc-editor.org/rfc/rfc8281.html#section-5.3 about endpoints (and it is valid for SR as well). <S> That section seems to be related to the endpoints of PCE initiated LSPs only. I would expect at least similar explanation for PCRpt in RFC8664. It seems very dangerous to relax previously defined restrictions without describing what should happen if it is not satisfied. Such approach is always opening doors to various interpretation/implementations by different vendors & problems with interoperability. I see following options - - Do Nothing - Clarify "when" the LSP-IDENTIFIER-TLV MUST be included (could be in the operational clarification draft) <S> Seems reasonable to me. - Update the text in RFC8664 to make LSP-IDENTIFIER-TLV "MUST" for SR Path type <S> What about changing it to MUST in RFC8664 + relaxing it in pce-segment-routing-policy-cp if policy association is included? Thanks! Dhruv (as a WG participant) I found some older discussion in mail archive: https://mailarchive.ietf.org/arch/msg/pce/rGVwtH6u3eUCMbRyR-gV1Cv2zDU/ Where almost similar topic was discussed and where it was requested to make it mandatory, but there were a few mails exchanged with no conclusion. One more comment – even statement about LSP-identifiers in RFC8664 seems to be mentioned in wrong section - dedicated for RP/SRP object, which was never used for LSP identifiers TLV (that is supposed to be included in LSP object). Thanks, Samuel
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
