Hi Dhruv, Thanks again for your feedback. Document update has been posted: https://tools.ietf.org/rfcdiff?url2=draft-stone-pce-local-protection-enforcement-02.txt
Thanks Andrew On 2020-07-27, 9:33 AM, "Dhruv Dhody" <[email protected]> wrote: Hi Andrew, From my point of view, to mark "updates RFC", you need to - - Update the metadata (https://tools.ietf.org/html/rfc7322#section-4.1.4) - Mention that you are updating the RFC 5440 in your abstract/introduction - Clarify what text is being updated in RFC 5440 and provide the updated text - Backward compatibility One easy reference would be to look at the recent RFC 8786 that updates RFC 8231. Not sure about a process document that describes these. I remember there was another individual draft to clarify on what it means to update an RFC and have more descriptive tags - update/amend/extend an RFC but we could ignore that for now :) Dhruv On Mon, Jul 27, 2020 at 6:17 PM Stone, Andrew (Nokia - CA/Ottawa) <[email protected]> wrote: > > Hi Dhruv, > > Thanks for the feedback. > > The documents aim is extending new functionality, with also adding additional language to implementation behaviour of the existing flag so I suppose it would be an update to RFC5440. Are there other differences to make, other than xml meta data in the document to indicate it updates RFC5440? (if there's a link that describes that is required that you can point me to that would be appreciated). > > Regarding backwards compatibility, good point: the doc includes PCC backwards compatibility comments in section 5 but does indeed not discuss PCE backwards compatibility. From my point of view, I don't see a capability exchange being required. I see support of 'L' flag being an independent interop clarification and 'E' flag being similar to adding another kind of 'constraint' to a path. I don't think would require a capability exchange to inform the PCC whether or not pce supports a given constraint type. I think the important thing is an existing pce would not error out if it did receive 'E' flag set, and fortunately RFC5440 has that covered with 'Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt.' I'll add a remark in the document that comments on this. > > Thanks again, > Andrew > > On 2020-07-26, 8:06 AM, "Dhruv Dhody" <[email protected]> wrote: > > Hi Andrew, > > Do you think an update to RFC 5440 is required (with meta-data set in > the document header)? > Based on the description of the flag field it feels like an update > would be needed - > > o L flag: As defined in [RFC5440] and further updated by this > document. When set, protection is desired. When not set, > protection is not desired. The enforcement of the protection is > identified via the E-Flag. > > > BTW, thanks for section 4 it helps! > > Maybe add an explicit backward compatibility section. Consider a PCC > that supports your extension, and sets the E flag to 1 and a PCE that > does not support your extension will ignore it and behave as before > and thus not enforce local protection, and there would be no way for > the PCC to know about it! Not sure if we need some sort of capability > exchange here? > > Thanks! > Dhruv > > On Fri, Mar 6, 2020 at 10:45 PM Stone, Andrew (Nokia - CA/Ottawa) > <[email protected]> wrote: > > > > Hi PCE WG, > > > > This draft was updated to include the following: > > > > - Draft renamed to reflect this is for "local" protection enforcement (used to be called path-protection) > > - new co author > > - Added more text regarding the various use cases / why a user may want these options > > - Added text discussing situations of no preference / "no not care" > > > > Thanks > > Andrew > > > > > > > > On 2020-03-02, 11:32 AM, "[email protected]" <[email protected]> wrote: > > > > > > A new version of I-D, draft-stone-pce-local-protection-enforcement-00.txt > > has been successfully submitted by Andrew Stone and posted to the > > IETF repository. > > > > Name: draft-stone-pce-local-protection-enforcement > > Revision: 00 > > Title: Local Protection Enforcement in PCEP > > Document date: 2020-03-02 > > Group: Individual Submission > > Pages: 8 > > URL: https://www.ietf.org/internet-drafts/draft-stone-pce-local-protection-enforcement-00.txt > > Status: https://datatracker.ietf.org/doc/draft-stone-pce-local-protection-enforcement/ > > Htmlized: https://tools.ietf.org/html/draft-stone-pce-local-protection-enforcement-00 > > Htmlized: https://datatracker.ietf.org/doc/html/draft-stone-pce-local-protection-enforcement > > > > > > Abstract: > > This document aims to clarify existing usage of the local protection > > desired bit signalled in Path Computation Element Protocol (PCEP). > > This document also introduces a new flag for signalling protection > > strictness in PCEP. > > > > > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > > > > > > > _______________________________________________ > > Pce mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
