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.
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)
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.
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)
- LSP delegation : I think its obvious, but the delegation is stopped if the
PCEP session is closed.
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,
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
- Upon reception of a PCUpd with delegate=1, the PCC MUST send a PCRpt,
Delegate=0 to the other PCE
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.
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.
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.
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.
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.
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.
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.
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)
- 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.
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
