Re: [Pce] FW: New Version Notification for draft-stone-pce-local-protection-enforcement-00.txt

["Stone, Andrew (Nokia - CA/Ottawa)" <[e-mail]>]

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" <[e-mail]> 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)
    <[e-mail]> 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, "[e-mail]" <[e-mail]> 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
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/pce