Subject: [Pce] I-D Action: draft-ietf-pce-pcep-stateful-pce-gmpls-09.txt

From: [email-masked]
Date: Wed, 05 Dec 2018 07:24:58 -0800

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/

---

From: Leeyoung <[email-masked]>
Date: Wed, 5 Dec 2018 17:21:23 +0000

Hi,

Just to revive the expired WG draft. Sorry that we slipped this one. 

Best regards,
Young

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, December 5, 2018 9:25 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Pce] I-D Action: draft-ietf-pce-pcep-stateful-pce-gmpls-09.txt

Abstract:

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.

_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 5 Dec 2018 18:16:37 -0000

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-masked]> On Behalf Of Leeyoung
Sent: 05 December 2018 17:21
To: [email-masked]
Subject: Re: [Pce] I-D Action: draft-ietf-pce-pcep-stateful-pce-gmpls-09.txt

Hi,

Best regards,
Young

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, December 5, 2018 9:25 AM
To: [email-masked]
Cc: [email-masked]
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:

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