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

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

Hello,

A while back Young sent this response and I didn't see any specific questions to
me that were not just rhetorical. So I have been waiting for a new revision.

I have to say that I am not convinced by the discussion of which return codes to
supply when a path can't be found. Maybe, given the explanation, it would be
better to replace "no path found" with "network disconnected" so that
"wavelength not found" means there is a path, but not one that meets the WSON
request. 

But it is still not clear to me how "wavelength not found" is used when there is
a path and there *are* wavelengths available, but some other WSON constraints
cannot be met on that wavelength. Why say "wavelength not found" instead of
"unsupported FEC type"? But what if the there are two paths available each with
one wavelength, but one cannot support the requested FEC type and the other
cannot support the requested modulation type?

Similarly, I'm not convinced by some of the discussion about the PCEP request
having to include the path computation type. But Young's response, although it
starts by disagreeing with my point (the bit I am not convinced by) seems to
come round and end up agreeing with me.


But bottom line is that this was on the list and no-one leapt in to say that
Young's proposed changes are mad, so I was just expecting a new revision so we
can move forward.

OK?

Adrian
> -----Original Message-----
> From: Leeyoung [mailto:[e-mail]]
> Sent: 28 August 2014 21:57
> To: [e-mail]; draft-ietf-pce-wson-routing-
> [e-mail]
> Cc: [e-mail]
> Subject: RE: [Pce] FW: AD review of draft-ietf-pce-wson-routing-wavelength
> 
> Hi Adrian,
> 
> Thanks for providing your timely review and valuable comments/suggestions of
> this draft.
> 
> Please see inline for my comment.
> 
> Regards,
> Young
> 
> -----Original Message-----
> From: Pce [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Wednesday, August 27, 2014 4:14 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [Pce] FW: AD review of draft-ietf-pce-wson-routing-wavelength
> 
> 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.
> >
> 
> [Young] Thanks. Yes. Will change per your clarification.
> 
> > ---
> >
> > 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
> >
> 
> [Young] Added in the first paragraph in Section 2 before the figure:
> 
> "R stands for Routing, WA for Wavelength Assignment, and DWA for Distributed
> Wavelength Assignment."
> 
> > ---
> >
> > 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.
> 
> [YOUNG] The PCC does not know which ones have wavelength conversion
> capability, etc. That is the reason the PCC to inquire PCE of the wavelength
> assignment including some conversion (as the PCE has all these info.). But, I
think
> you are saying this in the next paragraph. Only thing PCC knows that it needs
an
> optical path computation from PCE that comprises not only R (routing), but
also
> WA (wavelength assignment) in most cases. Why then Routing only option? We
> assume that PCC has some prior knowledge about its policy/capability (e.g.,
> distributed WA at each node).
> 
> >
> > 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.
> 
> [Young] Yes. The PCC is passive here. Whatever the PCE sends back, the PCC is
> happy.
> 
> >
> > 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.
> 
> [Young] Absolutely.
> >
> > ---
> >
> > 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.
> >
> [Young] You're correct. Will change. Replaced RFC4003 with RFC 3473 in Section
> 8.2 as well.
> 
> > ---
> >
> > 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)?
> 
> [Young] Good question. The intention here is the former. As each node/pcc
> processes and selects it own label, then the signaling will carry the rest of
the
> labels available for the next hop (minus the one selected), etc.
> >
> > ---
> >
> > 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.
> 
> [Young] It was an illustrative example. I will delete that phrase.
> >
> > 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"?
> 
> [Young] Yah, there is some subtlety here. "No path" available is primarily to
> indicate that the network is disconnected for the requested path for a S-D
pair.
> Of course, this also implies "no wavelength" situation. However, there are
cases
> where there is path (b/w) but it fails to meet wavelength continuity
constraint.
> For instance a node has wavelength x available toward the next hop. But the
next
> hop does not have wavelength x (say it has wavelength y) and it has no
> conversion capability. "No Wavelength" indicates this situation.
> 
> >
> > 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?
> 
> [Young] In general cases, a PCC may not react differently. On the other hand,
I
> can envision in advanced cases where the PCC may react differently for the
case
> of a "No Wavelength" error. Upon receipt of "no wavelength" indicator from the
> PCE, the PCC may trigger a "Re-optimization" request (as explained in Section
3.4)
> of some existing path in an hope to release the conflicted wavelength. But
this
> sounds like a bit wacky. :)
> >
> > ---
> >
> > 3.3
> >
> > For consistency with the terminology in 5440, shouldn't you use
> > "synchronized" instead of "simultaneous"?
> 
> [Young] No problem. We can use "synchronized" in place 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?
> 
> [Young] I am adding a new requirement to be able to specify a bulk "RWA"
> request indication analogous to section 3.1 for a single "RWA" request.
> >
> >    (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?
> 
> [Young] I think the encoding for SVEC can potentially include "WA" portion or
> some other ways to indicate the path result (which is yet to be determined).
But,
> I don't think we are changing SVEC behavior.
> >
> > ---
> >
> > 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.
> 
> [Young] OK. No problem!
> >
> > ---
> >
> > 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?
> 
> [Young] Not able to find a path during reoptimization means there is no
> alternative path available than the current path. Here perhaps I can add some
> phrase to clarify this:
> 
> OLD: In case that the path is not found
> NEW: In case that the new path (i.e., other than the current path) is not
found
> 
> 
> >
> > ---
> >
> > 3.5
> >    or an
> >    policy-based restriction
> >
> > s/an/a/
> >
> [Young] Yes. Thanks.
> 
> > ---
> >
> > 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.
> 
> [Young] Good point. I think it "MUST allow" is what is intended.
> 
> How about:
> 
> Section 3.6
> 
> OLD: A request for two or more paths MUST be able to include an option
> NEW: A request for two or more paths MUST allow the requester to include an
> option
> 
> Section 3.5
> 
> OLD: For any RWA computation type request, the requester (PCC) MAY specify a
> restriction on the wavelengths to be used
> 
> NEW: For any RWA computation type request, the requester (PCC) MUST be
> allowed to specify a restriction on the wavelengths to be used
> >
> > ---
> >
> > s/requestor/requester/
> 
> [Young] OK. Thanks.
> >
> > ---
> >
> > 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.
> 
> [Young] Do you think how the PCC know about the network is in scope of
> discussion in this particular draft? I didn't think so. The PCC can be an NMS
or
> network planner that knows some networks via policy or some other supporting
> systems. Even in the case that the PCC is a node, this knowledge may be
inferred
> from its local database or some other ways. Is this a reasonable assumption?
> 
> >
> > ---
> >
> > 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?
> 
> [Young] Yes, it is not clear as is. How about the following for Section 3.7:
> 
> NEW:
> 
> Signal processing compatibility is an important constraint for optical path
> computation. The signal type for an end-to-end optical path must match at
> source and at destination.
> 
> The PCC MUST be allowed to specify the signal type at the endpoints (i.e., at
> source and at destination). The following signal processing capabilities
should be
> supported at a minimum:
> o	Modulation Type List
> o	FEC Type List
> 
> The PCC MUST also be allowed to state whether transit modification is
acceptable
> for the above signal processing capabilities.
> 
> End of NEW
> >
> > ---
> >
> > 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.?
> >
> [Young] Network Operation Impacts in 8.6 of RFC 5440 deal with primarily PCEP
> speaker sessions and how to limit it in case of operational impacts or of this
> nature. The distribution of optical information you mentioned in a PCEP
context is
> simple adding more info just like other PCEP extensions, isn't it?
> 
> > --
> >
> > 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.)
> 
> [Young] deleted.
> _______________________________________________
> Pce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce