Subject: [Pce] Comments on draft-crabbe-pce-stateful-pce-01

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 8 Nov 2011 16:07:26 +0100

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-masked]
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

---

From: Jan Medved <[email-masked]>
Date: Tue, 8 Nov 2011 23:25:22 -0800

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-masked]> wrote:

>   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.

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.

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.

>the PCEP session is closed.

Correct. We'll add this to the document too.

>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,

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.
 
>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.

>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.

>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
>-	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 :
>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 

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.
>

Really looking forward to talking to you too.

>_______________________________________________
>Pce mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pce

---

From: [email-masked]
Date: Thu, 10 Nov 2011 12:57:07 +0800

Hi Jan,

<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-masked]> 
  [email-masked]
2011-11-09 15:25

收件人
"Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>, 
"[email-masked]" 
<[email-masked]>, "[email-masked]" 
<[email-masked]>
抄送

主题
Re: [Pce] Comments on draft-crabbe-pce-stateful-pce-01

Hi Cyril,

/Jan

 
>-               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

 

Good points.

Yes, good point.

Yes. Good point.

--------------------------------------------------------
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.