[Pce] FW: AD review of draft-ietf-pce-wson-routing-wavelength

["Adrian Farrel" <[e-mail]>]

Re-send with correct draft alias address.

Adrian

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: 27 August 2014 22:13
> To: '[e-mail]'
> Cc: '[e-mail]'
> Subject: AD review of draft-ietf-pce-wson-routing-wavelength
> 
> Hi authors,
> 
> I have done my usual AD review of your document in response to the
> publication request from the working group. The purpose of my review is
> to iron out any issues in the document and make sure I can support it
> through IETF last call and IESG evaluation.
> 
> Many of my comments below are editorial, but a lot of them are questions
> of clarification or intended function. I would like to discuss these
> with you and the working group before update the draft.
> 
> Thanks for the work,
> Adrian
> 
> ===
> 
> Abstract
>    Requirements for optical impairments will be
>    addressed in a separate document.
> I guess you mean
>    Requirements for PCEP extensions in support of optical impairments
>    will be addressed in a separate document.
> 
> ---
> 
> A couple of abbreviations are used without expansion...
> WA
> DWA
> 
> I think an intro para in section 2 to break out the terminology of
> R, WA, and DWA
> 
> ---
> 
> 3.1
>    A PCEP request MUST include the path computation type.
> 
> I don't understand how a PCC knows whether it needs to know the
> wavelength or not. Suppose the PCC is an ingress: how does it know
> whether the network comprises all nodes that cannot perform wavelength
> conversion, all nodes with limited wavelength conversion, all nodes
> with full wavelength conversion abilities, or some mixture.  In the
> case of the mixture, the choice of path will determine whether the
> wavelength must be known or not.
> 
> In fact, isn't it the PCE that knows whether or not to supply the
> wavelength based on its knowledge of the network capabilities and
> possibly based on the path it chose? The PCC, on the other hand, is
> always happy to have the labels supplied in the ERO, or not.
> 
> Furthermore, depending on the hops in the selected path, the wavelength
> assignment may come from the PCE for some hops (path segments) and may
> be distributed for other hops. It doesn't seem to be as black and white
> in the dimensions you have painted, but I would suggest that this does
> not matter because you can push the whole problem to PCE without PCC
> having to make any choice.
> 
> ---
> 
> 3.2
>    (i)    Explicit Label Control (ELC) [RFC4003]
> 
> Is this the right reference? It doesn't look like it to me!
> ELC is section 5 of RFC 3473.
> 
> ---
> 
> 3.2
>    (ii)   A set of recommended labels. The PCC can select the
>           label based on local policy.
> 
> Are you talking about a set of suggested labels for each hop?
> Or a set of potential e2e labels to use (from which the PCC
> can select just one to use)?
> 
> ---
> 
> 3.2
>    (c)   In the case where a valid path is not found, the response MUST
>       include why the path is not found (e.g., no path, wavelength not
>       found, optical quality check failed, etc.)
> 
> There is no explanation of "optical quality check" in this document.
> 
> I am concerned that "no path found" and "wavelength not found" are
> artefacts of the implementation of RWA. Certainly, in the case of R+WA
> you might fail to find a path before asking for a wavelength, but even
> in that case, can you be sure that there is no path available because
> the network is disconnected or because all of the bandwidth (i.e. all
> of the labels) on some of the links has been used? In that case, how
> can you choose between "no path" and "no wavelength"?
> 
> In more general cases, the failure to compute a path is simply the
> failure to find a path that meets the constraints. This sort of failure
> is no different to the general PCE computation failures - you can't
> simply state which single constraint caused the computation failure even
> if you know that relaxing one of the constraints would have allowed you
> to find a path because relaxing some other constraint(s) might also have
> resulted in a path being found.
> 
> But anyway, how do you anticipate a PCC will react differently to these
> two different return codes? Can a PCC do anything different in the two
> cases? Can it vary the request? Can it trigger something in the network?
> 
> ---
> 
> 3.3
> 
> For consistency with the terminology in 5440, shouldn't you use
> "synchronized" instead of "simultaneous"?
> 
> ---
> 
> 3.3
> 
>    (a)   A PCEP request MUST be able to specify an option for bulk RWA
>       path request. Bulk path request is an ability to request a number
>       of simultaneous RWA path requests.
> 
> Are you adding a requirement here, or are you saying that any solution
> must not break existing function? If the latter, why are you singling
> out this specific function as being special to not break?
> 
>    (b)   The PCEP response MUST include the path and the assigned
>       wavelength assigned for each RWA path request specified in the
>       original bulk request.
> 
> Are you changing SVEC behavior here? Are you making any change to
> 5440 and 6007?
> 
> ---
> 
> 3.4
>    2. The corresponding response to the re-optimized request MUST
>       provide the re-optimized path and wavelengths.
> 
> I think you should add:
> 
>    ...even when the request asked for the path or the wavelength to
>    remain unchanged.
> 
> ---
> 
> 3.4
>    3. In case that the path is not found, the response MUST include why
>       the path is not found (e.g., no path, wavelength not found, both
>       path and wavelength not found, etc.)
> 
> Interesting. Not only do my comments from 3.2 (c) apply, but I have to
> wonder what it means to be unable to find a path during reoptimization.
> Isn't the current path always a legitimate reply to a reoptimization
> request?
> 
> ---
> 
> 3.5
>    or an
>    policy-based restriction
> 
> s/an/a/
> 
> ---
> 
> Your use of RFC 2119 words is somewhat inconsistent. Sometimes you are
> setting expectations for the protocol solution
> 
>    Section 3.6
>    A request for two or more paths MUST be able to include an option
> 
> and sometimes you are saying what an implementation might do
> 
>    Section 3.5
>    For any RWA computation type request, the requester (PCC) MAY
>    specify a restriction on the wavelengths to be used
> 
> While I can derive a protocol requirement from the second type of usage
> of 2119 language, I think I end up with something ambiguous. For
> example, in the quoted text it is possible to interpret:
> 
>    - The solution MUST allow the requester to specify a restriction
>   or
>    - The solution MAY allow the requester to specify a restriction
> 
> I think you need to be clearer.
> 
> ---
> 
> s/requestor/requester/
> 
> ---
> 
> 3.6
>    In a network with wavelength conversion capabilities (e.g. sparse 3R
>    regenerators), a request SHOULD be able to indicate whether a
>    single, continuous wavelength should be allocated or not. In other
>    words, the requesting PCC SHOULD be able to specify the precedence
>    of wavelength continuity even if wavelength conversion is available.
> 
> I don't object to the PCC being able to have input on this issue, but
> it isn't clear to me how the PCC is about to know about the network in
> this way.
> 
> ---
> 
> 3.7
> 
> I believe this requirement, but not how it is worded. Isn't the actual
> requirement to allow the PCC to specify the signal type at source, at
> destination, and state whether transit modification is acceptable?
> 
> Maybe this section is also lacking a little background information?
> 
> ---
> 
> 4.6
> 
>    Mechanisms defined in this document do not imply any new network
>    operation requirements in addition to those already listed in
>    section 8.6 of [RFC5440].
> 
> Are you sure? Are there no assumptions about the distribution of
> wavelength availability information, and wavelength conversion ability,
> etc.?
> 
> --
> 
> I think you have an excess of boilerplate at the end of your draft.
> You can safely  delete everything after the Authors' Addresses. (I
> suspect your Word template thing is out of date.)