Subject: [Pce] Last Call of draft-ietf-pce-gmpls-aps-req-06

From: Julien Meuric <[email-masked]>
Date: Tue, 15 Jan 2013 18:34:26 +0100

Hi all and best wishes for 2013.

This e-mail starts a WG last call on draft-ietf-pce-gmpls-aps-req-06. 
Please send your comments to the PCE. You may review the document in 
front of the corresponding extension I-D, which should be last called soon.

This WG LC will end on Wednesday January 30, noon UTC.

Regards,

JP & Julien

P.S.: An IPR was disclosed on this I-D in August 2012 
(https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-ietf-pce-gmpls-aps-req).

---

From: Ramon Casellas <[email-masked]>
Date: Mon, 21 Jan 2013 17:05:59 +0100

Dear all,

Some random nits and comments after a fast read:

* Several paragraphs (incl. Section 4.1) refer to an expired:
    [CSPF]  T. Otani, et al, "Considering Generalized Multiprotocol
              Label Switching Traffic Engineering Attributes During Path
              Computation", draft-otani-ccamp-gmpls-cspf-constraints-
              07.txt, Feb., 2008.

* I am not sure of the implications of Section 3.2
- are must, should etc. MUST / SHOULD as per rfc2119?. In my humble 
opinion it could help understanding since, as of now, the basic 
assumptions could seem to imply that a PCE will not reply a e.g. strict 
ERO with different regions/layers as long as they are ok within the 
GMPLS hierarchy, although the paragraph below seems to allow otherwise.

* Decouple requirements from solutions? the draft cites PCEP-EXT (a 
solutions document) to refer to requirements. PCEP-EXT  refers to:
    [PCEP-EXT] C.Margaria,et al, "PCEP extensions for GMPLS",draft-ietf-
              pce-gmpls-PCEP-EXTs, in progress.
(incorrect reference btw)

* May need to be updated:

    [PCE-WSON-REQ] Y.Lee, et al,"PCEP Requirements for WSON Routing and
              Wavelength Assignment",draft-ietf-pce-wson-routing-
              wavelength, in progress.

* Would be nice to reflect Danielle et al. work on OTN post RFC4328

    [OSPF-G709] D.Ceccarelli,et al,"Traffic Engineering Extensions to
              OSPF for Generalized MPLS(GMPLS) Control of Evolving G.709
              OTN Networks", in progress.

    [RSVP-TE-G709] Fatai Zhang,et al,"Generalized Multi-Protocol Label
              Switching(GMPLS) Signaling Extensions for the evolving
              G.709 Optical Transport Network Control", in progress.

thanks
R.

---

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 28 Jan 2013 12:49:12 +0100

Dear all, 

Some minor comments from my side:
 
Section 3.2 : it could be useful to state the general requirement after the TDM example
Section 4.1 : editorial : The solution document is not a source of reqs.
Some nits : 
The references also need some editing, the html version from tools.ietf.org seems not to process them correctly.

Best regards / Mit freundlichen Grüßen
Cyril Margaria

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Julien Meuric
> Sent: Tuesday, January 15, 2013 6:34 PM
> To: [email-masked]
> Subject: [Pce] Last Call of draft-ietf-pce-gmpls-aps-req-06
> 
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: Julien Meuric <[email-masked]>
Date: Wed, 30 Jan 2013 18:25:48 +0100

Hi all.

This WG LC has ended. I will send my review soon. Authors, please 
address and/or discuss the comments received to build a proper update.

Thanks,

Julien

---

From: Julien Meuric <[email-masked]>
Date: Wed, 30 Jan 2013 18:30:37 +0100

Hi.

Authors of draft-ietf-pce-gmpls-aps-req, here is my review of your I-D, 
as a chair.

As a general comment, in the context of PCE, I tend to prefer the word 
"path" to the word "route", but the I-D seems consistent in that use, so 
no change look necessary there.

----------
Abstract
-----
- s/effort of PCE WG/effort of the PCE WG/
- [Wrong expansion or right hyphen? :-) ] s/Multi-protocol/Multiprotocol/
- RFC 2119 is referenced there, and again in section 2. I do not see 
these keywords used in the document: either the I-D needs a deep update 
to make an efficient use of them, or the RFC 2119 reference should be 
(double) dropped.
----------
Section 1
-----
- s/effort of PCE WG/effort of the PCE WG/
- s/in GMPLS networks/in GMPLS-controlled networks/
- s/and (non-packet switch capable) GMPLS networks/and GMPLS-controlled 
networks/  [Why excluding PSC?]
- s/complements these documents/complements these RFCs/ [repetition]
- s/definition of series of PCE related protocols/definition of 
PCE-related protocols/
- s/Constraint based/Constraint-based/
- s/is more stringent/is usually more stringent/
- The reference to [CSPF] should be removed here.
- s/[RFC3471, RFC3473]/[RFC3473]/  [The latter already references the 
former.]
- s/SRLG, and/SRLGs and/
- s/for the end points/of the end points/
----------
Section 2
-----
To be dropped? (See above.)
----------
Section 3.1
-----
I am not sure that section is in the scope of the document. Instead, it 
feels rather related to RFC 4927 and RFC 5376.
----------
Section 3.2
-----
- To emphasize Ramon's comment:
* the first sentence, which refers to [CSPF], looks useless and could be 
dropped;
* the full sentence from "[CSPF] indicates" to "created LSP." could be 
dropped also.
- Here again, there is no reason to exclude PSC (which is a typical use 
case of asymmetric bandwidth from section 3.4).
- s/The non-packet GMPLS networks/GMPLS-controlled networks/
- s/These GMPLS networks/These GMPLS-controlled networks/
- s/applying PCE to non-packet networks, for example/applying PCE to, 
for example/
- s/TDM(SDH)/TDM (SDH)/  [twice]
----------
Section 4
-----
The sentence duplicates the section title.
----------
Section 4.1
-----
- s/Requirements of Path/Requirements on Path/
- s/in GMPLS networks/in GMPLS-controlled networks/
- s/appropriately according to tables in [CSPF] once a PCC/appropriately 
once a PCC/
- As mentioned by Ramon and Cyril, [PCEP-EXT] should not be referenced 
in the corresponding requirement document.
- s/[ PCE-WSON-REQ]/[PCE-WSON-REQ]/
- s/control(ELC),the /control, the/
- s/as follows: [RFC5440]/as follows:/
- In (1), among switching capabilities, EVPL is missing (RFC6004).
- s/Technology specific/Technology-specific/
- s/such as wavelength label as defined in [RFC6205], or labels defined 
in [RFC4606], [RFC6060] or [RFC6002]/such as defined in [RFC4606], 
[RFC6060], [RFC6002] or [RFC6205]/
- The wording of (13) is not consistent with the previous ones. Proposed 
text: "Support of label restrictions in the requests/responses, 
similarly to RSVP-TE." (A reference may be useful.)
----------
Section 4.2
-----
- s/Requirements of Path/Requirements on Path/
- I got lost with the first sentence. I would drop it and start the 
paragraph by: "As described above, a PCE should compute..."
- s/Concatenation path computation/Path computation with concatenation/
- s/case of concatenation path computation/case of path computation 
involving concatenation/
- s/compute the path which satisfies the specified concatenation 
constraints./compute a path accordingly./
- s/For contiguous concatenation path computation/For path computation 
involving contiguous concatenation/
- s/the routes of each member signal must be co-routed and/a single 
route is required and/
- s/For virtual concatenation path computation/For path computation 
involving virtual concatenation/
- s/and maybe there are/and there may be/
- s/case that/case where/
- s/doesn't/does not/
- s/the label/the exact label(s)/
- s/the route and label assignment computation procedure/the route 
computation and label assignment procedures/
- I would drop "but is only one instance of it", which is redundant with 
the phrase "typical case".
- s/in GMPLS networks/, in GMPLS-controlled networks,/
- s/selection constraint/selection constraints/
- s/the labels or set of label/the label or set of labels/
- The sentence about PCEReq should be removed ("Reply" section).
- s/should be capable of indicating which one is working or protection 
route./should allow to distinguish the working (nominal) and the 
protection routes./
----------
Section 4.3
-----
- s/PCE related/PCE-related/
- s/referred to accommodate/referred to so as to accommodate/
----------
Section 5
-----
- s/PCE extensions/PCEP extensions/
----------
Section 8
-----
The reference section deserves an update: evolving documents, comments 
addressed in this I-D, missing spaces after commas, authors' first names 
and surnames in various orders...
----------

Best regards,

Julien

Le 15/01/2013 18:34, Julien Meuric a écrit :
 > This e-mail starts a WG last call on
 > draft-ietf-pce-gmpls-aps-req-06. Please send your comments to the
 > PCE. You may review the document in front of the corresponding
 > extension I-D, which should be last called soon.
 >
> Pce mailing list [email-masked]