Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-path-protection-10: (with DISCUSS and COMMENT)
Hi Mahendra, Thanks for the links. What's in the diff generally looks good; I think we may still need to have a bit more discussion here about items (1) and (4) (for the latter, I'm not sure if the plan is still to update the table to list everything or just leave it to the body text). Also, with respect to (7), I think there was at least one place in the text where we mention that the source, destination, and tunnel ID must match where we don't also mention the protection type matching. Maybe it's sufficiently less important that we don't need to mention it everywhere, but I'll mention it just in case. Thanks, Ben On Sun, Sep 22, 2019 at 09:06:24PM +0530, Mahend Negi wrote: > Hi Ben/Dhruv, > > Thanks for the review and clarification. Comments are incorporated in the > working copy (links below). > > Working copy: > https://github.com/mahendnegi/ietf/blob/master/pce/path-protection/iesg/draft-ietf-pce-stateful-path-protection-11.txt > Diff: > https://github.com/mahendnegi/ietf/commit/c51efb2b025d545e066b9b13de6d84de48d1a03c > > Please do share your opinion. > > Thanks, > Mahendra > > > On Fri, Sep 20, 2019 at 2:33 AM Benjamin Kaduk wrote: > > > Hi Dhruv, > > > > On Wed, Sep 18, 2019 at 11:45:23AM +0530, Dhruv Dhody wrote: > > > Hi Ben, > > > > > > Thanks for your review, let me start the discussion and the authors > > > can interject as needed. > > > > Thanks; it's a great start. > > > > > On Wed, Sep 18, 2019 at 5:14 AM Benjamin Kaduk via Datatracker > > > wrote: > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > draft-ietf-pce-stateful-path-protection-10: Discuss > > > > > > > > When responding, please keep the subject line intact and reply to all > > > > email addresses included in the To and CC lines. (Feel free to cut this > > > > introductory paragraph, however.) > > > > > > > > > > > > Please refer to > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > > > https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-path-protection/ > > > > > > > > > > > > > > > > -- > > > > DISCUSS: > > > > -- > > > > > > > > (1) draft-ietf-pce-association-group notes that "PCEP extensions that > > define > > > > a new association type should clarify the relationship between the SVEC > > > > object and the association type, if any". Where do we do so for the > > > > path protection association type? > > > > > > > > > > This is discussed in > > > > > https://tools.ietf.org/html/draft-ietf-pce-association-diversity-10#section-5.3 > > , > > > where it is more relevant. This draft includes the relationship with > > > diversity association in Section 5. > > > > A naive reading of the linked section would be that it applies only to the > > "Disjointness Association Type" defined in that document. I'm not in a > > position to claim that the reasoning in that document does not apply to > > this one, but I think we should make a more clear link between the Path > > Protection ASsociation Type and the discussion in that document. > > > > > > (2) Section 3.2 says: > > > > > > > > Protection Type (PT): 6 bits - This field is as defined in > > > > Section 14.1 of [RFC4872] to indicate the LSP protection type in > > > > use. > > > > > > > > There doesn't seem to be a registry created by RFC 4872 to track these > > > > PT values, so I assume that the way to allocate a new value is > > > > "standards-track RFC that Updates: RFC 4872". Is that also the way to > > > > allocate new PT values for PPAG usage? How would someone updating RFC > > > > 4872 to allocate a new type know to consider/document whether it > > applies > > > > for PPAG usage? > > > > > > > > > > That's true. Maybe we can add this text - "Any type already defined or > > > that could be defined in the future for use in the RSVP-TE PROTECTION > > > object is acceptable in this TLV unless explicitly stated otherwise." > > > > To be honest, that's probably good enough in practice, since it seems > > somewhat unlikely that the last bit is ever going to get allocated (though, > > I guess technically the field could be converted to an integer instead of > > flags). I do still have to wonder how the reader would know *where* it > > would be stated otherwise, and how the author of a document defining a new > > type would know to consider our use case as well as the RFC 4872 use case. > > > > > > (3) In Section 4.3: > > > > > > > >A PCE can create/update working and protection LSPs independently. > > > >As specified in [I-D.ietf-pce-association-group], Association Groups > > > >can be created by both the PCE and the PCC. Further, a PCE can > > > > > > > > The requirement that source,
[Pce] Publication has been requested for draft-farrel-pce-stateful-flags-02
Hariharan Ananthakrishnan has requested publication of draft-farrel-pce-stateful-flags-02 as Proposed Standard on behalf of the PCE working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-farrel-pce-stateful-flags/ ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] I-D Action: draft-farrel-pce-stateful-flags-02.txt
New revision to ask IANA to add this document as a reference in the appropriate registry (as suggested by Hari). -Original Message- From: Pce On Behalf Of internet-dra...@ietf.org Sent: 23 September 2019 11:42 To: i-d-annou...@ietf.org Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-farrel-pce-stateful-flags-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : Updated Rules for Processing Stateful PCE Request Parameters Flags Author : Adrian Farrel Filename: draft-farrel-pce-stateful-flags-02.txt Pages : 6 Date: 2019-09-23 Abstract: Extensions to the Path Computation Element communications Protocol (PCEP) to support stateful Path Computation Elements (PCEs) are defined in RFC 8231. One of the extensions is the Stateful PCE Request Parameters (SRP) object. That object includes a Flags field that is a set of 32 bit flags, and RFC 8281 defines an IANA registry for tracking assigned flags. However, RFC 8231 does not explain how an implementation should set unassigned flags in transmitted messages, nor how an implementation should process unassigned, unknown, or unsupported flags in received messages. This document updates RFC 8231 by defining the correct behaviors. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-farrel-pce-stateful-flags/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-farrel-pce-stateful-flags-02 https://datatracker.ietf.org/doc/html/draft-farrel-pce-stateful-flags-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-farrel-pce-stateful-flags-02 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] I-D Action: draft-farrel-pce-stateful-flags-02.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : Updated Rules for Processing Stateful PCE Request Parameters Flags Author : Adrian Farrel Filename: draft-farrel-pce-stateful-flags-02.txt Pages : 6 Date: 2019-09-23 Abstract: Extensions to the Path Computation Element communications Protocol (PCEP) to support stateful Path Computation Elements (PCEs) are defined in RFC 8231. One of the extensions is the Stateful PCE Request Parameters (SRP) object. That object includes a Flags field that is a set of 32 bit flags, and RFC 8281 defines an IANA registry for tracking assigned flags. However, RFC 8231 does not explain how an implementation should set unassigned flags in transmitted messages, nor how an implementation should process unassigned, unknown, or unsupported flags in received messages. This document updates RFC 8231 by defining the correct behaviors. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-farrel-pce-stateful-flags/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-farrel-pce-stateful-flags-02 https://datatracker.ietf.org/doc/html/draft-farrel-pce-stateful-flags-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-farrel-pce-stateful-flags-02 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Shepherd Review of draft-farrel-pce-stateful-flags-01
Hi, IMHO, including the new reference in the registry could be valuable and makes no harm. And now that the text is written, why leaving it out? Thanks Hari and Adrian, Julien On 22/09/2019 22:16, Adrian Farrel wrote: > Hi, > > I’m willing to be guided here. > > I don’t think the new draft makes any changes to how a code point seen in in > the wild should be interpreted. > And the “updates” relationship will be in place. > > But if people think it is valuable we could have… > > IANA maintains a registry called the “Path Computation Element Protocol > (PCEP) Numbers” registry with a subregistry called " SRP Object Flag Field". > IANA is requested to update the Reference in that subregistry to include a > reference to this document in addition to [RFC8281]. > > Best, > Adrian > >> This document is well written and clear. Thanks for the update. Please find >> below >> my comments on draft-farrel-pce-stateful-flags-01. >> >> OLD: >> 8. IANA Considerations >> This document makes no requests for IANA action >> >> NEW: >> The current IANA for this object has reference to "RFC8281" >> (https://www.iana.org/ >> assignments/pcep/pcep.xhtml#srp-object-flag-field) Dont we want that refer >> to this >> new draft since we have updated the text ? > ___ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
