Hi Ramon, Thanks for your comments. Please see inline for my response.
Regards, Young -----Original Message----- From: Pce [mailto:[email protected]] On Behalf Of Ramon Casellas Sent: Tuesday, February 25, 2014 4:13 AM To: [email protected] Subject: Re: [Pce] WG Last Call of draft-ietf-pce-wson-routing-wavelength-10 El 03/02/2014 18:03, Julien Meuric escribió: > Hi all. > > Since many of you are going to dedicate some time to IETF matters over > the upcoming days, here comes some homework. > This message ignites a 2-week WG last call on > draft-ietf-pce-wson-routing-wavelength-10. It will end on Monday, > February 17, 11:59 PM (UTC-12). Dear all, A (late) short, fast review of the document below. Feel free to accept/discard at your discretion R. General Comments: * In general, requirements are stated in terms of messages (e.g. PCReq and PCRep) rather than in terms of PCEP requests and responses. IMHO, given that PCReq messages contain svec lists, lists of requests, etc. I would suggest the requirements using the request/response RBNF constructs. For example: OLD The PCReq Message MUST include the path computation type. NEW A PCEP request [for a lighpath within a PCReq message] MUST include the path computation type. YOUNG>> OK. Cyril has a similar request, so I will change with not mentioning protocol specific words. Section 2.1.1 ========================== I would move the first bullet "1" out of 2.1.1 which is focused on RWA. Requirement "1" is to specify R or RWA Section 2.1.1 then focuses on RWA YOUNG>> Routing only is a part of RWA computation type (as strange as it sounds). OLD When the PCReq Message is RWA path computation type, the PCReq Message MUST further ... NEW When the request is a RWA path computation type, the request MUST further include ... YOUNG>> OK. - (ii) Non-Explicit labels in the form of Label Sets (This will allow Distributed WA at a node level where each node would select the wavelength from the Label Sets) I am not sure of what Non-Explicit implies here. Maybe change to "a set of recommended labels"... YOUNG>> Yes. I am confused here. If the path computation type is RWA, the Distributed WA does not apply, does it? YOUNG>> RWA := {R&WA, R+WA, R+DWA}. RWA is an overarching term here, not R&WA only. A new requirement could be added: is a requirement that when the R path computation type is selected the PCE MAY provide a Label Set ? NEW 2.b In case of a R computation type, the response MAY provide [Non-Explicit ?] labels in the form of Label Sets. This will allow Distributed WA at a node level where each node would select the wavelength from the Label Sets. YOUNG>> Not sure if this makes sense. The request is R only, then why would PCE returns with Wavelength? OLD 3. The PCRep Message MUST include the route, wavelengths assigned to the route and indication of which wavelength assignment option has been applied (ELC or Label Sets). NEW 3. In case of a RWA computation type, the response MUST include the wavelength(s) assigned to the route and an indication of which label assignment option has been applied (ELC or Label Sets). Rationale: the route is implicit by RFC5440 YOUNG>> OK. OLD 4. In the case where a valid path is not found, the PCRep Message MUST include why the path is not found (e.g., no route, wavelength not found, optical quality check failed, etc.) NEW 4. In the case where a valid path is not found, the reponse MUST include why the path is not found (e.g., no route, wavelength not found, optical quality check failed, etc.) YOUNG>> OK. Section 2.1.2 ============= [Q] Is the possibliity of requesting R bulk requests not a requirement? or is it assumed that existing mechanisms are enough? YOUNG>> Existing mechanism is only for R. Here we are talking about R+WA. Section 2.1.3 ============== OLD 1. For a re-optimization request, the PCReq Message MUST provide the path to be re-optimized and include the following options NEW 1. For a re-optimization request, the request MUST provide both the route and current wavelength to be re-optimized and MAY include the following options: a. b. [c is implicit by not including options] YOUNG>> Yes, but including option C is a bit more clearer, isn't it? Section 2.1.4 ============== OLD For any PCReq Message that is associated with a request for wavelength assignment the requester (PCC) MUST be able to specify a restriction on the wavelengths to be used. Note that the requestor (PCC) is NOT required to furnish any range restrictions. NEW? For any RWA computation type request, the requester (PCC) MAY specify a restriction on the wavelengths to be used. Rationale: "MUST be able but is NOT required" YOUNG>> Yes. OK. Section 2.1.5 =============== OLD The PCReq Message May include specific operator's policy information for WA (E.g., random assignment, descending order, ascending order, etc.) NEW A RWA computation type request MAY include the requestor preference for WA (E.g., random assignment, descending order, ascending order, etc.). A response SHOULD follow the requestor preference unless operator's policy. Rationale: Change wording? YOUNG>> OK. OLD The PCReq Message SHOULD be able to request, when requesting a 1+1 connection (e.g. link disjoint paths), that both paths use the same wavelength. -> It is not clear to me how to request a 1+1 connection. I think this is an important requirement in itself. In general, what are the requirements regarding protection in PCEP? what about other protection types? YOUNG>> I agree. I will change per Cyril's comment. See my response to Cyril, if that would satisfy you. OLD The PCReq Message SHOULD be able to request, when performing 3R, that wavelength may change or not NEW In a network with wavelength conversion capabilities (e.g. sparse 3R regenerators), a request SHOULD be able to indicate whether a single, contiguous wavelength should be allocated or not. In other words, the requesting PCC SHOULD be able to constrain the wavelength continuity even if wavelength conversion is available. Rationale: the initial requirement is a bit vague. I am not sure if the intent of he requirement is that? YOUNG>> YES, thanks. Section 2.1.6 =============== OLD The PCReq Message MUST be able to specify restrictions for signal compatibility either on the endpoint or any given link. The following signal processing capability should be supported at a minimum: "A request MUST be able to ..." YOUNG>> OK. s/on the endpoint/on the endpoints ? s/capability/capabilities ? YOUNG>> OK. Notes: Not sure about the "any given link". It may be good to be more verbose on this requirement. Relationship with IRO? YOUNG>> What I meant to say was signal processing capabilities can apply both to endpoints and links on the path. Section 3 =============== 3. Manageability Considerations Nothing is said regarding session parameters on a PCE: o Policy regarding WA algorithms: first-fit, random... o Whether to use Explicit Label Control or not ... YOUNG>> Not sure if this is needed. If so, please suggest some texts. Final comments =============== - Nothing is said about bidirectional LSPs. It seems that being able to compute a bi-directional LSP with the additional constraint of having the same upstream and downtream wavelength would be IMHO a requirement. YOUNG>> It is assumed bidirectional LSPs. _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
