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

From: "Ogaki, Kenichi" <[email-masked]>
Date: Thu, 07 Feb 2013 08:54:29 +0900

Dear PCErs,

Thanks for your comments, Julien, Ramon and Cyril.

All the comments about editorials were captured into the attached revised draft.
The revised draft is not submitted yet, and the format a little bit changed because the draft was rewriten by using xml template.

Here are the responses to the other comments.

Ramon's comment:
    > * 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.

The words "must" and "should" were removed from basic assumptions.

Cyril's comment:
    > Section 3.2 : it could be useful to state the general requirement after the TDM example

The following general requirement was added:

As described above, PCC should be capable of specifying TE attributes defined in the next section and PCE should compute a path accordingly.

Julien's comment:
    > ----------
    > 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.

Old section 3.1 was removed and the following sentence is added at the end of section 2.1(formerly section 3.2):

Where a GMPLS network is consisting of inter-domain (e.g., inter-AS or inter-area) GMPLS-controlled networks, requirements on the path 
computation follows [RFC5376] and [RFC 4726].

Thanks,
Kenichi

On 1/31/13 2:30 AM, Julien Meuric wrote:
> 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-masked]
>  > https://www.ietf.org/mailman/listinfo/pce
>  >
>  >
>
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>