Hi Jan,
In your letter you wrote:
>
>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.
<Kexin>:I prefer the former that Cyril wrote, since it is more simple. The
latter possibility you described needs extra information in PCE Discovery
advertisement,
and with the newly change of active PCE, this advertisement could
be frequently.
Indeed,to introduce stateful PCEs, extentions to PCE Discovery
(RFC5088,RFC5089) is needed,to advertise the stateful PCEs as you said
above.
However, PCE Discovery advertisement is not needed unless the
location or capability of a PCE is changed.
Best Regards,
Kexin
Jan Medved <[email protected]>
[email protected]
2011-11-09 15:25
收件人
"Margaria, Cyril (NSN - DE/Munich)" <[email protected]>,
"[email protected]"
<[email protected]>, "[email protected]"
<[email protected]>
抄送
主题
Re: [Pce] Comments on draft-crabbe-pce-stateful-pce-01
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
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is
solely property of the sender's organization. This mail communication is
confidential. Recipients named above are obligated to maintain secrecy and are
not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed. If
you have received this email in error please notify the originator of the
message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
