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

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 27 Aug 2014 22:14:13 +0100

Re-send with correct draft alias address.

Adrian

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: 27 August 2014 22:13
> To: [email-masked]'
> Cc: [email-masked]'
> 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.)

---

From: Leeyoung <[email-masked]>
Date: Thu, 28 Aug 2014 20:57:25 +0000

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:[email-masked]] On Behalf Of Adrian Farrel
Sent: Wednesday, August 27, 2014 4:14 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Pce] FW: AD review of draft-ietf-pce-wson-routing-wavelength

Adrian

> 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

[Young] Thanks. Yes. Will change per your clarification. 

> 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." 

> 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). 

> 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. 
> ELC is section 5 of RFC 3473.
[Young] You're correct. Will change. Replaced RFC4003 with RFC 3473 in Section 8.2 as well.

> 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. 
> There is no explanation of "optical quality check" in this document.

[Young] It was an illustrative example. I will delete that phrase. 
> 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. 

> 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. :)
> "synchronized" instead of "simultaneous"?

[Young] No problem. We can use "synchronized" in place of "simultaneous." 
> 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. 

> 
> 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.  
>    ...even when the request asked for the path or the wavelength to

[Young] OK. No problem!
> Isn't the current path always a legitimate reply to a reoptimization 

[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

> s/an/a/
[Young] Yes. Thanks.

> 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 

[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. 
> it isn't clear to me how the PCC is about to know about the network in 

[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? 

> 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  
> 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? 

[Young] deleted.
_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce