Hi Cyril, Thanks a lot for the comments, please see inline.
/Jan On 11/8/11 7:07 AM, "Margaria, Cyril (NSN - DE/Munich)" <[email protected]> wrote: >Hi, > >I find this document very interesting, >Please find my few comments below: > >Section 2. > Regarding Restoration and Path Protection : Wording is not aligned >with GMPLS (RFC4427) : protection here seems used for pre-planned >restoration and restoration for dynamic source reroute. >In addition its not clear why the term "global" is used. We used terminology proposed for MPLS Traffic Engineering in "Network Recovery: Protection and Restoration of Optical, SONET SDH, IP, and MPLS". WE chose it because it contains a precise description of protection use cases that we think should be covered by stateful PCEP. Do you think we should rather align the terminology with rfc4427? > >Section 3.1.3. : > > I do not think the document should restrict the set of parameters to >consider, the set of parameters should be IMHO be negotiated and should >depend on local policy (at PCC or PCE level) Agreed. We will need to introduce capability / parameter negotiation into the document. > >You state that the PCEP extension propose a common state representation, >but it seems that its currently signaled or not signaled. > >Section 5.1 >In the PCEP protocol (defined in [RFC5440]), LSP state and operation are >under the control of the PCC, the received attributes from the PCE are >subject to PCC local policy. >The extensions defined in this document do not change this behavior. Yes. We'll add this text to the document. > >Section 5.4. > - Mechanism from RFC3623 could be used in the OPEN sequence in order >not to do a full resynchronization if the state on PCC did not change >(and the PCE did keep the previous state) Hmmm, that's a good idea. We should discuss in more detail. >- LSP delegation : I think its obvious, but the delegation is stopped if >the PCEP session is closed. Correct. We'll add this to the document too. > >Section 5.5. and section 5.5.4. > >You require that the PCC is aware of the PCE role (active/backup) one >another solution could be to allow the PCC to tell all the PCEs that he >want to have the LSP state delegated, >The first one to send an update wins, That's a possibility. The PCC would then revoke LSP delegation from the other PCE. Another possibility would be to advertise the preferred active PCE in IS-IS or OSPF. We should define extensions to RFCs 5088 and 5089 for advertising of stateful PCEs; additional PCE attributes, such as preferred active PCE, could be advertised at the same time. > > It stated that only one PCE may have control of an LSP, but I do think >that the following should be allowed : >- PCC or PCE requesting LSP state delegation : several delegation to >several PCE MAY be accepted You're right that the protocol itself should not restrict LSP delegation to a single PCE - that should be under control of an operator-defined policy. I think most of the time the policy should be defined such that an LSP is delegated to a single PCE. But, point taken. We'll update the text. >- Upon reception of a PCUpd with delegate=1, the PCC MUST send a PCRpt, >Delegate=0 to the other PCE If a PCE attempts to update an LSP that is not delegated to it, the PCC MUST send back a PCErr with a TBD error code. > >The background of that is that the PCE is redundant and the architecture >chosen use one PCEP session per PCE instance, one instance is active at a >time. Yes, that's the most common use case. > >Section 5.6.1. >I think that the following mechanism should be added : > Prior to the PCReq the PCC send a PCRpt for the LSP with state pending >(no path then) > Upon the PCReq the PCE can already consider the resources used. > >This would allow a PCC to cover the case where it intend to establish the >LSP after getting the PCRep (so the resources computed will be marked as >pending in the PCE already) or signal it later. Ah, I see what you mean. I like it :-) > >Section 5.6.2. > You state that the PCC MUST NOT send a path computation for a delegated >PCE, but section 5.1 indicate that the LSP state is owned by the PCC, so >for example the PCC MAY delegate the setup/holding priority to the PCC >but not the protection behavior (for example if the behavior is not >supported by the PCE), in which can the PCC need to send path computation >request. Hm, we did not think of partial delegation. For simplicity, we would like to keep it all-or-nothing, unless there are compelling reasons to do something more powerful (and complex). WE should discuss, though, it's an interesting idea. The statement about LSP state ownership is related to the fact that the PCC can revoke the delegation at any time. It can decide whether to delegate or not, and to whom to delegate. Also, the PCC has to cleanup the LSP state if the connection to the PCE is terminated. But the assumption was that once an LSP is delegated, the PCE has full control of the LSP, > >Section 5.7. > The protection control by PCE MAY be desired, but I do not think it's >a must. ( I do think about GMPLS where FRR might not be supported at all) > I do not think that the document should mandate a minimum set of >behavior from the PCE. This might be subject to another document. Agreed on all points. Protection requires its own document. We had to put some info into this document in order to be able to define the PCRpt and PCUpd messages. > >Section 6.1. > One motivation you mentioned on the list was to allow different objects >than the PCEP one, however you are using the one from PCEP (I would >suggest to take into account >draft-ietf-pce-gmpls-pcep-extensions and RFC6006 in that case) > > >- backup-path-list: in case p2mp is used this could be a problem >- Missing PPRO for backup LSPs >- Missing association between LSPs (one case mentioned is 2 >unidirectional LSPs, the other case are rfc4872 and rfc4873 for instance) > >For a given LSP there is several path, but there is no statement >indicating if the resources on those path are : >- Reserved : i.e signaled >- Shared :reserved and shared between LSPs (for instance as in RFC4872) >- "Planned" : not signaled, only exist in the PCC. > >The provisioning state of the LSP is only state in the O bit of the LSP, >but the state pending up down are not clearly identified. Good points. > > >Section 6.2. > Third paragraph : the paragraph state the LSP State report instead of >LSP Update, moreover the primary (and backup) path are optional . >The statement "If the LSP specified the Update Request is already up, >it will be torn down and re-signaled." Indicate that the PCC must use >break-before-make, which is contradicting with the next sentence. I do >think this should be configurable, similarly with GCO. Yes, good point. > >I do also think that GCO could be leverage by the PCE to indicate to the >PCC which LSP he could re-optimize, it could be done for example by >Indicate in the PCUpd that a set of LSP could be reoptimized using GCO >(and providing the GC object). This can be independent of the Delegation >for those LSPs, and would be an application of bullet 3 of section >3.1.2.6. Yes. Good point. > >Section 7.2. >PROTECTION-ATTRIBUTE TLV from draft-ietf-pce-gmpls-pcep-extensions could >also be considered to report the protection and signaling state. >In order to fulfill the objective "Allow a PCE to specify protection / >restoration settings for all LSPs that have been delegated to it." I >think that the following is necessary to be added : >- ASSOCIATION >- PROTECTION-ATTRIBUTE in LSPA > > >Section 7.2.2. > - The tunnel sender id is missing (There is no guarantee that one >PCC is managing only one node) Hm, ok. But then we also need to somehow add the sender id to the PCUpd messages too. > - From Tunnel ID you seem to imply that what is considered by the state >full PCE is more a call than just an LSP. As association can be between >LSPs having difference session and sender template (RFC4873), I do think >that this simplification may cause problem. > >Looking forward to discussing this in Taipei. Really looking forward to talking to you too. > > >Mit freundlichen Grüßen / Best Regards >Cyril Margaria > >Nokia Siemens Networks GmbH & Co. KG >NWS DWDM RD >St.Martin-Str. 76 >D-81541 München >Germany >mailto:[email protected] >Phone: +49-89-5159-16934 >Fax: +49-89-5159-44-16934 >---------------------------------------------------------------- >Nokia Siemens Networks GmbH & Co. KG >Sitz der Gesellschaft: München / Registered office: Munich >Registergericht: München / Commercial registry: Munich, HRA 88537 >WEEE-Reg.-Nr.: DE 52984304 >Persönlich haftende Gesellschafterin / General Partner: Nokia Siemens >Networks Management GmbH >Geschäftsleitung / Board of Directors: Dr. Hermann Rodler, Lydia Sommer, >Olaf Horsthemke >Vorsitzender des Aufsichtsrats / Chairman of supervisory board: Herbert >Merz >Sitz der Gesellschaft: München / Registered office: Munich >Registergericht: München / Commercial registry: Munich, HRB 163416 > > >_______________________________________________ >Pce mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
