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