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 :
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).
>
>
>
>
>
>
_______________________________________________
Pce mailing list [email protected]
> https://www.ietf.org/mailman/listinfo/pce
>
>
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
