Hi Cyril, Thanks for providing your comment. Please see inline for my response.
Regards, Young From: Pce [mailto:[email protected]] On Behalf Of Cyril Margaria Sent: Tuesday, February 25, 2014 7:04 AM To: Julien Meuric Cc: [email protected] Subject: Re: [Pce] WG Last Call of draft-ietf-pce-wson-routing-wavelength-10 Hi PCErs, I have a few comments on the document: Section 1.1 : Strange indentation YOUNG>> I will look into that. indentation: ============ The indentation of the following section is not consistent: Section 1.1 Section 2.1 Section 2.1.1 Section 3.1 Section 3.2 ... YOUNG>> I will look into that. Section 2.1.1 ============= Is there a requierement for RWA-capable PCE discovery? IGP-based discovery is addressed in section 3.5, but OPEN extension could also be covered. A PCC expecting RWA-capable PCE will only be able to detect a non RWA capable upon request. It is likely that request are not very frequent in WSON networks, so a misconfiguration may be discovered quite late. OPEN extension would allow a faster detection. YOUNG>> PCE discovery is not a requirement, but can be considered as an option. What is OPEN extension? I can add if you want the reference info in Section 3.5. In WSON environment, RWA-capable PCE discovery can be configured instead of depending on discovery mechanisms, IMHO. Req 2) : I believe ii) is not only for D-RWA, but also covers RWA. OLD: (i) Explicit Label Control (ELC) [RFC4003] (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) NEW: (i) Explicit Label Control (ELC) [RFC4003]. (ii) Non-Explicit labels in the form of Label Sets. The PCC can select the label based on local policy. Note that option ii) may also be used in R+WA or DWA. YOUNG>> Agree. Will change. Section 2.1.2 ============= Is it possible to mix in a bulk request, R and RWA requests? YOUNG>> Not sure what the mixed bulk requests achieve. GCO [RFC 5557] addresses the bulk request for R. 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. NEW For a RWA request, the request MUST be able to specify an option for a restriction on the wavelengths to be used. The requester MAY use this option to restrict the assigned wavelenght for Explict Label or Label Sets. YOUNG>> accepted. -- This is more in line with the rest of the document. The req being on the protocol, not involving the PCC is better. OLD Note that the requestor (PCC) is NOT required to furnish any range restrictions. This restriction is to be interpreted by the PCE as a constraint on the tuning ability of the origination laser transmitter. NEW Note that the requestor is NOT required to furnish any range restrictions. This restriction may for example come from the tuning ability of a laser transmitter, any optical element, or an policy based restriction. YOUNG>> How about the following: Note that the requestor (e.g., PCC) is NOT required to furnish any range restrictions. This restriction may for example come from the tuning ability of a laser transmitter, any optical element, or an policy based restriction. -- The PCE should not interpret the restriction, just apply it. Section 2.1.5 ============= in "The PCReq Message May include specific operator's policy", do you mean MAY? YOUNG>> Yes. The section could be renamed "Wavelength assignement policy constraints" YOUNG>> Good suggestion, Will change. The explicit label versus Label set could also fit in this section, or section 2.1.1 req 2 should refer to this section. YOUNG>> In Section 2.1.1, req 2 will refer to Section 2.1.5 for this requirement. 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. NEW A request for 2 or more path MUST be able to specify an option constraining the path to have the same wavelength(s) assigned. YOUNG>> NEW: A request for 2 or more path (e.g., 1+1 link disjoint paths) MUST be able to specify an option constraining the path to have the same wavelength(s) assigned. -- Computing a 1+1 path is one use case, but this may apply for other protection type. This can be achieved by removing the protection aspect. YOUNG>> I put as an example in the above suggestion. Section 2.1.6 ============= NEW o OIC list YOUNG>> I think OIC is a solution for signal compatibility for FEC and Modulation. As a requirement, I think the current text is fine. -- draft-ietf-ccamp-rwa-info-21 defines the concept of OIC, PCEP should be able to transport the same kind of info YOUNG>> Agree, as a solution, but not as a requirement. Best regards, Cyril On 18 February 2014 17:28, Julien Meuric <[email protected]<mailto:[email protected]>> wrote: Hi all. This last call has ended. We have not seen many reviews. The chairs' will come soon. JP & Julien Feb. 03, 2014 - Julien Meuric: 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). Thanks, JP & Julien _______________________________________________ Pce mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/pce
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
