Re-send with correct draft alias address. Adrian
> -----Original Message----- > From: Adrian Farrel [mailto:[email protected]] > Sent: 27 August 2014 22:13 > To: '[email protected]' > Cc: '[email protected]' > 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.) _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
