Hi authors, Unless I am mistaken, there was never a response to my review back in December. Did it get lost (I see it in the list archive)?
Plans? Thanks, Adrian -----Original Message----- From: Adrian Farrel <[email protected]> Sent: 05 December 2018 18:17 To: 'Leeyoung' <[email protected]>; '[email protected]' <[email protected]> Subject: RE: [Pce] I-D Action: draft-ietf-pce-pcep-stateful-pce-gmpls-09.txt While I'm on a roll reviewing PCE documents, and while Young is being active, I just had a look at his new revision on this draft. Glad that it is alive again because we seem to have a number of documents that relate to it. Only a few comments, but I think tidying these gets us close to "done". Thanks, Adrian === You should move "Conventions used in this document" down to become Section 2 and replace it with the new text... The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. That requires you to make an addition to the normative references for RFC 8174. --- 2. OLD For Passive Stateful PCE where PCReq/PCRep messages are used to convey path computation instruction. As GMPLS-technology specific Objects/TLVs are defined in [PCEP-GMPLS], this document just points to the work in [PCEP-GMPLS] and add only the stateful PCE aspect only if applicable. NEW For Passive Stateful PCEs, PCReq/PCRep messages are used to convey path computation instructions. GMPLS-technology specific Objects and TLVs are defined in [PCEP-GMPLS], so this document just points at that work and only adds the stateful PCE aspects where applicable. END --- 4.2 You have "ERO object" and "RRO object". That would be EROO and RROO? I think that if you expand the terms on first use, then the use of the abbreviations will be easier. In the same section you have IRO and XRO which you should expand. --- 4.2 needs a reference to RFC 5511. I suggest... OLD To be more specific, the <attribute-list> is updated as follows: NEW To be more specific, the <attribute-list> is updated as follows using the notation of [RFC5511]: END Obviously, you need to add that to the references section as well. --- At the end of 4.2 you have Moreover, if the status of the protecting LSP changes from non-operational to operational, this SHOULD to be synchronized to the stateful PCE using a PCRpt message. Reviewers are likely to ask "under what circumstances can an implementation vary this procedure and why?" You may also get asked about the use of the passive voice in this sentence. Who should synchonise it to the stateful PCE? --- The final sentence of 4.3 says... Note this MAY also be applicable to packet networks. I think probably s/MAY also be/is also/ --- 4.3.2 You rightly say... X bit and Attribute fields are defined in [RFC5521]. So you can safely (should) delete ... X bit: indicates whether the exclusion is mandatory (X=1) and MUST be accommodated, or desired (X=0) and SHOULD be accommodated. .... and ... Attributes: indicates how the exclusion object is to be interpreted. Currently, Interface (Attributes = 0), Node (Attributes =1) and SRLG (Attributes =2) are defined in [RFC5521] and this document does not define new values. --- 4.3.2 s/a LSP/an LSP/ --- 4.3.2 s/exclude it from the/exclude from the/ --- I'm trying to reconcile 4.3.3 with 5.3. The problems are: - 5.3 "new registry" but I think the registry already exists - 5.3 (correctly) says that the new bit position is TBD allowing IANA to make the best selection, but Figure 3 shows a specific position for the B-bit I would replace the text in the two sections as follows... 4.3.3 OLD The format of the SRP object is defined in [RFC8231] and included here for easy reference with the addition of the new B flag. This SRP object is used in PCUpd and PCInit messages for GMPLS. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |B|R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRP-ID-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: The SRP Object Format A new flag is defined to indicate a bidirectional co-routed LSP setup operation initiated by the PCE: B (Bidirectional LSP -- 1 bit): If set to 0, it indicates a request to create a uni-directional LSP. If set to 1, it indicates a request to create a bidirectional co-routed LSP. NEW The format of the SRP object is defined in [RFC8231]. The object is used in PCUpd and PCInit messages for GMPLS. This document defines a new flag to be carried in the Flags field of the SRP object. This flag indicates a bidirectional co-routed LSP setup operation initiated by the PCE as follows: B (Bidirectional LSP -- 1 bit): If set to 0, it indicates a request to create a uni-directional LSP. If set to 1, it indicates a request to create a bidirectional co-routed LSP. The bit position is TBD5 as assigned by IANA (see Section 5.3) END 5.3 OLD IANA has created a new subregistry, named "SRP Object Flag Field", within the "Path Computation Element Protocol (PCEP) Numbers" registry, to manage the Flag field of the SRP object. New values are to be assigned by Standards Action [RFC8126]. Each bit is tracked with the following qualities: bit number (counting from bit 0 as the most significant bit), description, and defining RFC. The following values are defined in this document: Bit Description Reference --- ---------------------------- ---------- TDB Bi-directional co-routed LSP [This.I-D] NEW IANA maintains a subregistry, named the "SRP Object Flag Field", within the "Path Computation Element Protocol (PCEP) Numbers" registry, to manage the Flag field of the SRP object. IANA is requested to make an assignment from this registry as follows: Bit Description Reference --- ---------------------------- ---------- TDB5 Bi-directional co-routed LSP [This.I-D] END --- Section 5 has IANA is requested to allocate new Types for the TLV/Object defined in this document. I think you should delete that text. It doesn't seem to belong to this document. --- 6. s/presented in the next sections./presented in the next section./ -----Original Message----- From: Pce <[email protected]> On Behalf Of Leeyoung Sent: 05 December 2018 17:21 To: [email protected] Subject: Re: [Pce] I-D Action: draft-ietf-pce-pcep-stateful-pce-gmpls-09.txt Hi, Just to revive the expired WG draft. Sorry that we slipped this one. Best regards, Young -----Original Message----- From: Pce [mailto:[email protected]] On Behalf Of [email protected] Sent: Wednesday, December 5, 2018 9:25 AM To: [email protected] Cc: [email protected] Subject: [Pce] I-D Action: draft-ietf-pce-pcep-stateful-pce-gmpls-09.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 : Path Computation Element (PCE) Protocol Extensions for Stateful PCE Usage in GMPLS-controlled Networks Authors : Xian Zhang Young Lee Fatai Zhang Ramon Casellas Oscar Gonzalez de Dios Zafar Ali Filename : draft-ietf-pce-pcep-stateful-pce-gmpls-09.txt Pages : 15 Date : 2018-12-05 Abstract: The Path Computation Element (PCE) facilitates Traffic Engineering (TE) based path calculation in large, multi-domain, multi-region, or multi-layer networks. The PCE communication Protocol (PCEP) has been extended to support stateful PCE functions where the PCE retains information about the paths already present in the network, but those extensions are technology-agnostic. This memo provides extensions required for PCEP so as to enable the usage of a stateful PCE capability in GMPLS-controlled networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-stateful-pce-gmpls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-pcep-stateful-pce-gmpls-09 https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-stateful-pce-gmpls -09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-stateful-pce-gmpls-09 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 [email protected] https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
