Re: [Pce] 答复: stateful PCE - moving forward & next steps

["Margaria, Cyril (NSN - DE/Munich)" <[e-mail]>]

Hi, 

 

I do support the objective of separating the generic extensions and protocol specific ones. I would be however careful rushing MPLS-TE only extensions only to find out that there is a significant overlap with the GMPLS/.. other one which would fit in the generic extensions.

 

I have quickly reviewed the related documents an have some (but not too much) comments, see below.

I think the current set of documents could benefits from a rebalancing (I agree with Adrian on that)  one could be : 

      applicability draft        

                           |                          

              |
     core framework draft
              | 

      core extensions

              + 

              |\____ time-based scheduling          
              | \___ PCE-initiated LSP
             /|          +
   other____/ |          |\___ other     
              |          |
           RSVP-TE    RSVP-TE

              |          +

             / \         |\__ MPLS-TE  
  GMPLS ____/   \        \__ GMPLS

                 MPLS           
                             

 

The current situation as I read it (I may have forgotten some of them)

·         draft-ietf-pce-stateful-pce                                 : covering applicability, framework, core extensions, generic RSVP extensions

·         draft-crabbe-pce-stateful-pce-mpls-te        : covering generic RSVP extension, 

·         draft-crabbe-pce-stateful-pce-protection  : covering generic RSVP extension,MPLS-TE extensions

·         draft-crabbe-pce-pce-initiated-lsp                : covering generic, RSVP, but restricted to MPLS objects

·         draft-zhang-pce-pcep-stateful-pce-gmpls : covering core extensions, time based scheduling, GMPLS, WSON, inter-layer

·         draft-zhang-pce-stateful-pce-app                 :  covering applicability, framework, 

 

There could be some improvement 

 

 

Regarding the individual documents:

 

On draft-ietf-pce-stateful-pce-02:

 

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.

c.       Delegation timeout : This is part of the delegation procedure, this could be removed from 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

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. 

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,

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

12.   Section 5.4 : which messages are allowed during State synchronization? Is it allowed to have PCReq/Notify for instance? 

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

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)

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.

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>

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

18.   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”),

19.   Section 7.2.1 : Why not add this TLV to the LSPA (and mandate LSPA), it would fit better in LSPA

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

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





draft-crabbe-pce-stateful-pce-mpls-te-00,

1.       Section 4.1 : here the elements collide with RFC5440, but if you mean that update in <path> from draft-ietf-pce-gmpls-pcep-extensions is automatically supported, its fine for me ;-) 

2.       Section 4.1/section 4.2 : you indicate that the report may contains a path descriptor for the primary and one or more the backup path(s),  I support the middle should be the primary one, correct? This diverge from the RFC5440 where there is no role associated to the path list, I would suggest to use the  PROTECTION-ATTRIBUTE defined in draft-ietf-pce-gmpls-pcep-extensions-07, in addition this seems more or less generic.

3.       Section 5.1 : this is also quite generic, in draft-ietf-pce-stateful-pce RSVP error spec is considered  generic material  but here LSP identifier as MPLS-TE specific. I would then rather expect “RSVP” specific extensions but not MPLS RSVP-TE and GMPLS RSVP-TE (a “GMPLS” document can also make use of the LSP Identifier). 

4.       In general its seems you want to say “ use draft-ietf-pce-stateful-pce” and only implement RFC5440 objects, but change some of its semantic, this is a mix of different things which are not very coherent. Having the generic part defining the behavior on non-supported objects (P2MP, GMPLS, inter-layer ..etc) could help focusing the “technology” specific to be better scoped.

5.       Section 5.3. LSP Update Error Code TLV : why is it MPLS-TE specific?

 

draft-crabbe-pce-stateful-pce-protection-00:

1.       Section 3.1 : Why not reuse the draft-ietf-pce-gmpls-pcep-extensions  PROTECTION_ATTRIBUTE ? the local protection can be seen as the seg. Flags  from RFC4873 , this would also cover the Section 4.1

2.       Section 4.1 : wrong figure title

3.       Section 4.1 : the S flag semantic would collide with draft-ietf-pce-gmpls-pcep-extensions  PROTECTION_ATTRIBUTE object S bit,,

4.       Section 4.3 : does this indicate for a given LSP what is the bypass LSP node, is this expecting one bypass tunnel ? why  not associated the tunnels (one could make use of RFC4872 association or create a list of associated LSP-ID, possibly with role/flags??)

5.       Section 4.4 : One another more generic possibility would be to have an association list with role or making use of the association object,

 

 

draft-crabbe-pce-pce-initiated-lsp-00: 

1.       Section 5.1 : reusing the PCEP common RBNF with <path>, <attribute-list> , …etc would be more clear and more generic, I do prefer solid error handling procedure than defining one procedure and object set per document

2.       Section 5.1 : this is RFC5440 specific and not considering other RFCs or draft in progress

3.       Section 6.2.1 : see comment #17 of draft-ietf-pce-stateful-pce, if the initation is supported the DELEGATION-TIMEOUT field could be used to the same effect (in E->C) 

 

 

draft-zhang-pce-pcep-stateful-pce-gmpls:

1.       Section 2.2.1 : this is not only usefull for stateful, but also for stateless, this should be integrated to draft-ietf-pce-inter-layer-ext

2.       Section 2.4 : IMHO this should not be necessary, the generic part should describe how  to deal with non-supported objects, 

3.       Section 2.5 : This seems generic, I would expect a new section in the WG document describing this generic procedure, it does not match the scope of this document.,

4.       Section 2.6 : how is this GMPLS-specific? This should be another set of extensions maybe.

 

 

Best regards / Mit freundlichen Grüßen

Cyril Margaria

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of ext Edward Crabbe
Sent: Friday, October 26, 2012 2:23 PM
To: Oscar González de Dios
Cc: [e-mail]
Subject: Re: [Pce]答复: stateful PCE - moving forward & next steps

 

Oscar;

 

Comments in-line;

	In the case of current Working Group stateful PCE solution (draft-ietf-pce-stateful-pce-02), the focus is mainly on the new functions to be supported: Capability Negotiation, State Synchronization, LSP State Report , LSP Control Delegation, LSP Update Request, etc All these set of functions are independent whether it is a MPLS-TE or a GMPLS tunnel. Thus, I don't see why the scope should be limited to MPLS-TE.

 

Thank you very much for being specific about which draft you are referring to! The framework draft, draft-ietf-pce-stateful-pce-02,is obviously NOT limited to MPLS-TE. This draft is intended to support extensions for MPLS-TE, GMPLS and other potential extensions going forward. This has been the case from the beginning. Please see my previous email about the /framework/ draft supporting MPLS-TE & GMPLS as well as the several off list discussions we've had regarding same. An (re)illustration of the proposed document set relationships is included below:

 

applicability draft 

| 

|
core framework draft 
|
|
/|\
____/ | \____ 
/ | \
/ | RSVP-TE 
/ |
/ |
GMPLS | 

|
other extensions

 

note that this is *not* a timeseries. :P

 

	Would those functions be different in GMPLS and needed separate messages and objects, I would agree in separating the solution. For example, in the current draft, there are very few objects which are MPLS-TE specific.

 

That is intentional. Again, you are referring to the framework draft, which was intended to support both from the beginning. 

AFAIK we are discussing the separate extension drafts. If we are NOT discussing the separate extensions draft then we are in violent agreement: the framework should, and does support both. 

	I have gone through the document several times to see the points which could be different in GMPLS, and I could not find them (maybe I miss something here, so If you think the number of specific MPLS-TE /GMPLS objects will be significant, please give the examples). All the new messages apply for both MPLS-TE and GMPLS, without the need of any change.

 

Yes, this was deliberate. Please see my previous email in the thread regarding extension vs framework.

 

 

	
	For other applications of the stateful PCE, GMPLS and MPLS-TE may go in separate documents if there are many differences between them, and the documents are cleaner with separate extensions.

	
	"(in fact this is the case for Google; as a company we do not care about GMPLS, we /do/ very much care about MPLS-TE.) "

	Sorry, Ed, but the argument of a specific company position of what cares or not is by no means acceptable. Please, limit the arguments to technical and not political.

 

 

Oh, I agree that the specific google instance has no bearing here; this isn't a political argument and is true no matter what company we're talking about, vendor or customer. The longer form of the argument is as follows:

 

If you combine the *extension* drafts, you end up with both features being glommed together in one spec. If a specific vendor is in one market or the other and does not require the full spec, OR a specific customer has need of only one of the two and is pushing a vendor to implement it, combining the two into a single draft either addsadditionalwork inunnecessarily implementing both orpotentially increases the difficulty for the implementor in disentangling the two and claiming RFC compliance. Having separate *extension* drafts inherently provides the split that exists the two markets in reality. 

 

best,

 

-ed

 

 

 

	________________________________
	
	Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra polí´©ca de enví¯ y recepció® ¤e correo electró®©£o en el enlace situado má³ abajo.
	This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
	http://www.tid.es/ES/PAGINAS/disclaimer.aspx

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