Subject: Re: [Pce] Comments on draft-ietf-pce-stateful-pce-02

From: Ina Minei <[email-masked]>
Date: Fri, 22 Mar 2013 22:20:26 +0000

Cyril, 

Thank you for the detailed comments. Posting here for the benefit of the list. 

These issues were discussed in a series of in-person meetings at the ietf, and comments incorporated in version 03 of the draft. Answers inline below marked ### for the list. A few open items remain and will be addressed in the future, they are marked "###open".

Thank you,

Ina 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Margaria, Cyril (NSN - DE/Munich)
Sent: Thursday, February 21, 2013 3:44 AM
To: [email-masked]; [email-masked]
Subject: [Pce] Comments on draft-ietf-pce-stateful-pce-02

Hi stateful-framework-solution authors.

I did not see any reply on my previous comments I repost them, with additional comments

I do have the following (few) comments on the documents so far:
1.       (Editorial) : Section 2 Terminology :
a.      The passive stateful does not use delegation, the active does. It would be more clear to simply state this.
b.      Delegation : maybe also indicate that those LSPs are named delegated LSPs.
### Done

c.      Delegation timeout : This is part of the delegation procedure, this could be removed from the terminology
### This is an important concept, so was kept in the terminology.

d.      LSP state report : applicable to Both passive and active?, the Passive definition could indicate that
e.      LSP Update Request : for delegated LSP only,
f.      LSP priority : Adding the reference to the RFC defining those values would be useful
### done for all

g.      MPLS TE Global Default Restoration : This is a use-case specific term, it would be more clear to separate it from the generic stateful terms (After another paragraph). In addition this can also apply to GMPLS.
2.      I think making the separation between the generic stateful requirement and extensions and the "MPLS-TE/GMPLS/Others" part is  a good idea, this should also be reflected in section 2 by separating the generic terminology from the MPLS-TE specific one.
### While we understand the rationale, prefer to keep in one section at this point.

3.      Section 3:  the title "Motivation and Objectives for Stateful PCE"  would fit more the objectives of the draft.
4.      Section 3.1 :
OLD:
   In the following sections, several use cases are described, showcasing scenarios that benefit from the deployment of a stateful PCE.
  The scenarios are specific to MPLS TE deployments, but the  extensions described in this document apply to GMPLS tunnels as well.
NEW :
   In the following sections, several use cases are described, showcasing scenarios that benefit from the deployment of a stateful PCE.
  Some of the scenarios are focused on MPLS TE deployments, but may also apply to GMPLS tunnels as well.
5.      Section 3.1.1 :
      OLD:
      In the traffic
         engineering system provided by [RFC3630], [RFC5305], and [RFC3209]
         information about network resources utilization is only available as
         total reserved capacity by traffic class on a per interface basis;
         individual LSP state is available only locally on each LER for it's
         own LSPs.  In most cases, this makes good sense, as distribution and
         retention of total LSP state for all LERs within in the network would
         be prohibitively costly.
      NEW :
         In the traffic
         engineering system provided by [RFC3630], [RFC5305], and [RFC3209]
         information about network resources utilization is only available as
         aggregated capacity by traffic class on a per interface basis;
         individual LSP state may be  available only locally on each LER/LSP for it's
         own LSPs.  In most cases, this makes good sense, as distribution and
         retention of total LSP state for all LERs/LSRs within in the network would
         be prohibitively costly.
6.      Second paragraph : Another use case would be the GMPLS restoration.
7.      Section 3.1.2. : MPLS TE control plane -> control plane, this is not MPLS TE specific.
8.      New section proposed 3.1.2.6. Pre-planned sharing :
Shared-mesh restoration defined in [RFC4872] is a restoration mechanism which allow sharing of protection resource for risk-disjoint working path. The sharing decision is a local decision as the head node does not know what are the resources used for shared protection and which SRLGs are protected by them. The local decision may be also influenced by the order of the TE-LSP setup. A stateful PCE with this information in its LSP state database will be able to:
      o Optimize the sharing of protection resources
      o Allow  LSP maintenance operation to have fewer impact on protection resources
      o Allow to reoptimze the protection resource
9.      New section proposed 3.1.2.7. Discrete resource path constrained allocation
Some networks are using discrete resources which are constrained by other TE-LSPs or switching capabilities. Typical use case is limited label switching capabilities (label stack-depth, HW constraints, physical constraint). Path computation in such type of network require a more complete resource and TE-LSP view in order to compute valid path. A stateful PCE can use the TE-LSP to provide better optimization and reduce blocking. In addition IGP  information is  not required to carry extended resource usage.
10.     The document draft-zhang-pce-stateful-pce-app-02 has some other generic, GMPLS and technology specific use cases, which could be added, I would expect the authors of this draft to indicate this as comment to the WG draft,
### All the above will be discussed as part of the applicability doc

11.     Section 5.2 : PCRpt : It could be useful to use the PCEP response attribute, in the LSP status report : the path with attribute-list is reported (So when referring to RFC5440 section 6, this would cover the different extensions). This would also apply to the PCUpd
###open 

12.     Section 5.4 : which messages are allowed during State synchronization? Is it allowed to have PCReq/Notify for instance?
###Yes (but will operate on partial state)

13.     Section 5.7 : too MPLS-TE specific, a GMPLS stateful PCE will not be compliant. This should be in the protocol-specific part.
### Removed

14.     Section 5.6.2 : What happens if the update is not acceptable? A PCErr may be returned.  (In section 8.4 a new error similar to type 20 value 1 could be used)
### may close session. Further error processing still open

15.     Section 5.6.2 : the statement "A PCC MUST NOT send to any PCE a Path Computation Request for a  delegated LSP." Is contradicting the PCC control, the PCC may not fully delegate all aspects to the PCE, this seems too strong for me.
### Can request computation only after revoking the delegation

16.     Section 6.1. and Section 6.2  : path-list is confusing, you indicate its technology-specific, however its defined  in RFC5440 section 6.5, I would suggest :
      <state-report> ::= <LSP>[<path-report-list>] where <path- report -list>::=<path-report>[<path-report-list>] and <path-report> ::= <end-point-path-pair-list> or <path> [<technology-specific-path>
### done

17.     Section 6.2 : proposed additional text :
"If the PCUpd cannot be satisfied (PCC overload, unsupported object or TLV), the PCC MUST respond with an PCErr message" .
This in combination with draft-ietf-pce-enhanced-errors would allow a proper and generic handling. Some processing rules defined in other document in the PCReq processing would also apply for the PCUpd. In addition new error code should be allocated, if the LSP identifiers cannot be supported by the PCC, this should turn into specific errors.
### done

18.     Section 7.1.1  : The delegation and state timeout are mentioned in the document, it could be useful to also negotiate those (or others) as part of the STATEFUL-PCE-CAPABILITY object :
a.      DELEGATION-TIMEOUT : In this document only set by the PCC, could be used by
b.      RESTART-TIMEOUT : indication by the PCEP Peer for session reconnection time (node restart time for instance), may be used by the Peer to adjust its timeout.
### The delegation timeout is a box-local value. The restart-timeout is a good idea if the deployment model is one where a _single_ pce is used, or no backup pce is used, or the restart time is not deterministic, but not in the general case. More on the delegation timeout and processing following pce failure in the next version of the draft.

19.     Section 7.2.1 : CLI can be removed, it is not necessary. In addition "If the operator does not  specify an unique symbolic name for a path, the PCC MUST auto-generate one"  (change is "an unique"),
###done

20.     Section 7.2.1 : Why not add this TLV to the LSPA (and mandate LSPA), it would fit better in LSPA
%%% It is in lspa as well. This is necessary for multi-path

21.     Section 7.2.2 : This support explicitly RSVP Class type 6, but you are missing RSVP Ctype 3 and 4, In addition Class type 169 (USER_ERROR_SPEC, as defined in RFC5284) is not supported. In addition I would like to suggest to have on TLV type for ERROR spec (covering RSVP ERROR_SPEC and USER_ERROR_SPEC), containing the RSVP objects
###open - error reporting will be updated in version 04

22.      Section 9.1. : the statement "A PCC implementation which allows concurrent connections to multiple  PCEs SHOULD allow the operator to group the PCEs by administrative  domains" seems a more general requirement that could be used in other cases. Is it meaningful to add this in the MIB document?
### please follow up with mib authors

23.     I think that draft-farrkingel-pce-abno-architecture-02 provides a good model, and the stateful PCE models presented in this document should use the architectural components and interfaces of the document. I found the section 1.1  particularly applicable.
###will evaluate for future version

Mit freundlichen Grüßen / Best Regards
Cyril Margaria

Nokia Siemens Networks Optical GmbH
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 Optical GmbH
Geschäftsleitung / Board of Directors: Gero Neumeier, Dr. Rolf Nauerz Sitz der Gesellschaft: München / Registered office: Munich
Registergericht: München / Commercial registry: Munich, HRB 197143

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