Subject: [Pce] stateful PCE - moving forward & next steps

From: Ramon Casellas <[email-masked]>
Date: Sat, 20 Oct 2012 08:59:53 +0200

Dear PCErs,

We've taken this issue off-list and discussed. A summary of our agreed 
upon next steps follows for WG review:

1/ - We have agreed to merge the applicability portion of the existing 
WG draft (draft-ietf-pce-stateful-pce) with Xian’s presented draft on 
this very same aspect. This new joint/merged draft, temporarily referred 
to as draft-zhang-pce-stateful-pce-app-03, will tentatively be ready for 
IETF86. It will be informational in nature, highlighting the benefits 
and use cases of a stateful PCE. While this split is by no means 
mandatory, it does address some comments raised during WG adoption. 
Selected text and wording from to current framework draft 
draft-ietf-pce-stateful-pce-02 will be moved to the applicability, 
notably in sections 2 and 3.

2/ - draft-ietf-pce-stateful-pce-02 is relatively mature, and a 
significant amount of time has been invested on it. It has been recently 
updated to acknowledge/reflect that PCEP (and consequently any PCEP 
functional extensions) needs to be extended to fully cover GMPLS 
networks in a way similar to how RFC5440 is extended by 
draft-ietf-pce-gmpls. This draft already covers most refined details 
such as protocol procedures & messages, LSP identifiers, LSP descriptive 
names, etc., while leaving technology specific aspects aside.

2.a – it is worth noting that, although draft-zhang-pce-stateful-app 
will surely need to follow regular draft procedures, the chairs 
explicitly agreed to accept the post-split framework as a working group 
document given the acceptance of the original stateful doc.

3/ Since one of the additional comments during the WG adoption poll 
(e.g., by yours truly and others) was that, in its previous form, 
draft-ietf-pce-stateful-pce did not cover GMPLS extensions and could 
limit its applicability in transport networks, specific “solutions” 
documents addressing extensions will be developed. They will be based on 
the framework and will refer to it.

-A consequence of this is that draft "Current Path Computation Element 
(PCE) Protocol Extension for Stateful PCE Usage in GMPLS Networks", aka 
draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt will be rewritten to 
follow the new apps & fwk and will define encodings e.g. at the "message 
level" (such as extended RBNF for a PCRpt message considering 
GMPLS-specific extensions).

-Likewise, for RSVP-TE covering non-GMPLS cases & networks, a new draft 
has just been submitted and will be presented 
(draft-crabbe-pce-stateful-pce-mpls-te-00)

-Within reasonable standard procedures, the GMPLS solutions draft can 
just point at the relevant sections within 
draft-crabbe-pce-stateful-pce-mpls-te-00 and complete where appropriate 
/ necessary.

4/ Other stateful-PCE based applications will be identified in the 
future. Our suggested procedure will consist on extending the basic 
framework document by means of other drafts that complement it and build 
upon the core framework.

Thank you,

Ramon, on behalf of the stateful-PCErs

-- 
Ramon Casellas, Ph.D.
Research Associate - Optical Networking Area -- http://wikiona.cttc.es
CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4
Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain
Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Mon, 22 Oct 2012 02:55:42 +0000

Thank you, Ramon, for summarizing the off-list discussion. 

We, authors of relevant drafts wrt stateful PCE, have had a fruitful discussion. As always, comments to the discussion detailed as below and/or the relevant drafts themselves are more than welcome. 

Regards,

Xian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ramon Casellas
Sent: 2012年10月20日 15:00
To: [email-masked]
Subject: [Pce] stateful PCE - moving forward & next steps

Dear PCErs,

Thank you,

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

---

From: Julien Meuric <[email-masked]>
Date: Thu, 25 Oct 2012 11:39:29 +0200

Hi Ramon, hi contributors from shadow.

We appreciate the effort of all those who are working on this work. It 
will be interesting to discuss the progress during our meeting in 
Atlanta. In the meantime, do not hesitate to share with the WG using the 
mailing list, like your message below.

One 1st comment at this stage: you seem to suggest that the idea is to 
have separate document for MPLS-TE and GMPLS, but you do not give 
rationale. Apart from our history of RFC 5440 + draft-ietf-pce-gmpls 
(even with its scope, the former had a hard time), is there a particular 
reason for this choice? Do you expect much difference between those 2 
kinds of extensions? Also keep in mind that GMPLS includes PSC...

Thank you,

Julien

On 10/20/2012 08:59, Ramon Casellas wrote:
> this very same aspect. This new joint/merged draft, temporarily 
> referred to as draft-zhang-pce-stateful-pce-app-03, will tentatively 
> be ready for IETF86. It will be informational in nature, highlighting 
> the benefits and use cases of a stateful PCE. While this split is by 
> no means mandatory, it does address some comments raised during WG 
> adoption. Selected text and wording from to current framework draft 
> significant amount of time has been invested on it. It has been 
> recently updated to acknowledge/reflect that PCEP (and consequently 
> any PCEP functional extensions) needs to be extended to fully cover 
> GMPLS networks in a way similar to how RFC5440 is extended by 
> such as protocol procedures & messages, LSP identifiers, LSP 
> descriptive names, etc., while leaving technology specific aspects aside.
>
> explicitly agreed to accept the post-split framework as a working 
> group document given the acceptance of the original stateful doc.
>
> documents addressing extensions will be developed. They will be based 
> on the framework and will refer to it.
>
> (PCE) Protocol Extension for Stateful PCE Usage in GMPLS Networks", 
> aka draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt will be rewritten 
> to follow the new apps & fwk and will define encodings e.g. at the 
> "message level" (such as extended RBNF for a PCRpt message considering 
> -Likewise, for RSVP-TE covering non-GMPLS cases & networks, a new 
> draft has just been submitted and will be presented 
> draft-crabbe-pce-stateful-pce-mpls-te-00 and complete where 
> appropriate / necessary.
>
>
> framework document by means of other drafts that complement it and 
> build upon the core framework.
>
>
>
> Thank you,
>

---

From: Ramon Casellas <[email-masked]>
Date: Thu, 25 Oct 2012 20:37:58 +0200

El 25/10/2012 11:39, Julien Meuric escribió:
> (even with its scope, the former had a hard time), is there a 
> particular reason for this choice? Do you expect much difference 
> between those 2 kinds of extensions? Also keep in mind that GMPLS 
> includes PSC...
>
Dear Julien, all

Thanks for the feedback, I understand your point about GMPLS and, if I 
recall correctly, one of the reasons mentioned in previous internal 
discussions was the relative maturity of one (RFC5440) with regard to 
the other (draft-ietf-pce-gmpls).

We can indeed discuss the different alternatives during IETF85, with all 
the involved parties, authors, and the WG.  Although, initially, I had a 
slight preference to integrate GMPLS, (as I mentioned a while ago in my 
review of Ed's earlier drafts), I am fine either way.

Maybe Ed, Jan, Ina, Fatai, Young, Xian or Oscar can comment on this?

Thanks and best regards,
R.

---

From: Edward Crabbe <[email-masked]>
Date: Thu, 25 Oct 2012 11:45:34 -0700

Hey guys;

I'm not sure whether we're discussing the separation of extension drafts or
the framework draft here.  The framework draft will provide mechanisms to
support both extensions.  The extensions are separated because they are
supporting very different use cases and it is significantly cleaner from a
documentation maintenance and organization perspective.

best,
  -ed

On Thu, Oct 25, 2012 at 11:37 AM, Ramon Casellas <[email-masked]>wrote:

>> rationale. Apart from our history of RFC 5440 + draft-ietf-pce-gmpls (even
>> with its scope, the former had a hard time), is there a particular reason
>> for this choice? Do you expect much difference between those 2 kinds of
>> extensions? Also keep in mind that GMPLS includes PSC...
>>
>>  Dear Julien, all
>
> discussions was the relative maturity of one (RFC5440) with regard to the
> other (draft-ietf-pce-gmpls).
>
> ______________________________**_________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/pce<https://www.ietf.org/mailman/listinfo/pce>
>

---

From: Leeyoung <[email-masked]>
Date: Thu, 25 Oct 2012 21:17:50 +0000

Hi Julien

Thanks for providing your useful feedback on the issues of the separation of MPLS-TE version from GMPLS version of the solution draft for the stateful PCE. 
I think the separation was tentatively agreed by the authors of the two separate documents due to the differing interest of the authors who have different implementation needs (one for packet network; the other for transport network). I don't know if this would be a valid reason for the separation, but we are willing to hear from the WG feedback. 

Thanks.
Young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Julien Meuric
Sent: Thursday, October 25, 2012 4:39 AM
To: Ramon Casellas
Cc: [email-masked]
Subject: Re: [Pce] stateful PCE - moving forward & next steps

Thank you,

Julien

On 10/20/2012 08:59, Ramon Casellas wrote:
> WG draft (draft-ietf-pce-stateful-pce) with Xian's presented draft on 
> 2.a - it is worth noting that, although draft-zhang-pce-stateful-app 
> limit its applicability in transport networks, specific "solutions"

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Fri, 26 Oct 2012 01:27:54 +0000

Hi, Dear Julien and all, 

   IMHO, the stateful PCEP protocol extensions for both MPLS and GMPLS have lots in common. So, my understanding is that there should be one extension document. However, the preference of different parties diverges. It would be good if we can hear more from the experts on the list which is a better way to proceed. 

Regards,

Xian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Julien Meuric
Sent: 2012年10月25日 17:39
To: Ramon Casellas
Cc: [email-masked]
Subject: Re: [Pce] stateful PCE - moving forward & next steps

Thank you,

Julien

---

From: Edward Crabbe <[email-masked]>
Date: Thu, 25 Oct 2012 19:05:59 -0700

I completely disagree.  I think it makes a great deal of sense from both
organizational and an implementation perspectives.

As a designer of these protocols, it makes a great deal of sense to
separate different extensions into different documents.  This improves
readability, makes draft revision simpler, decreases overall complexity for
draft readers and just makes great deal of sense from an organizational
perspective.

As a consumer of these protocols, I may want to encourage vendors to
implement one of these features without forcing them to implement both.
(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.)

On Thu, Oct 25, 2012 at 6:27 PM, Zhangxian (Xian) <[email-masked]>wrote:

> Hi, Dear Julien and all,
>
>    IMHO, the stateful PCEP protocol extensions for both MPLS and GMPLS
> have lots in common. So, my understanding is that there should be one
> extension document. However, the preference of different parties diverges.
> It would be good if we can hear more from the experts on the list which is
> a better way to proceed.
>
> Regards,
>
> Xian
>

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 26 Oct 2012 04:39:38 +0000

Hi Ramon and Julien,

Thanks for your useful comments.

I agree with Julien and Ramon.  We of course need to investigate which way is a preference for PCE WG.

I think if it could integrate GMPLS, I would suggest moving to that direction, because GMPLS is generic and covers MPLS as what Julien said.

BTW, we usually prefer to generalize something in a draft/RFC, when it could be generalized. 

More comments from WG are appreciated.

Best Regards

Fatai

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Ramon Casellas
发送时间: 2012年10月26日 2:38
收件人: Julien Meuric
抄送: [email-masked]
主题: Re: [Pce] stateful PCE - moving forward & next steps

Dear Julien, all

Thanks and best regards,
R.

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Fri, 26 Oct 2012 05:29:17 +0000

Hi Fatal,

On 10/25/12 9:39 PM, "Fatai Zhang" <[email-masked]> wrote:

>I think if it could integrate GMPLS, I would suggest moving to that
>direction, because GMPLS is generic and covers MPLS as what Julien said.

Ed in his email gave good reasons why we think that MPLS and GMPLS objects
should be defined in separate drafts. Another reason may be that if in the
future we need to support yet another tunneling technology, the core
protocol & documents do not have to change.

>BTW, we usually prefer to generalize something in a draft/RFC, when it

That's a somewhat generalized point of view ;-)
 
>More comments from WG are appreciated.

Thanks,
Jan

---

From: Oscar González de Dios <[email-masked]>
Date: Fri, 26 Oct 2012 09:15:58 +0000

Dear PCErs,

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

        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.

        Best Regards,

                Óscar

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más 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

---

From: Edward Crabbe <[email-masked]>
Date: Fri, 26 Oct 2012 05:23:27 -0700

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 adds additional work in unnecessarily
implementing both or potentially 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ítica de envío y recepción de correo electrónico en el enlace
> situado más abajo.
> This message is intended exclusively for its addressee. We only send and
> receive email on the basis of the terms set out at:

---

From: Ina Minei <[email-masked]>
Date: Fri, 26 Oct 2012 17:15:51 +0000

Oscar, 

Thank you for reviewing the draft. 

As stated in the abstract, the framework document (draft-ietf-pce-stateful-pce-02) covers both MPLS-TE and GMPLS. The abstract states: "This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS tunnels via PCEP".

The technology-specific extensions will be in separate documents. I strongly believe that there should be different documents for each of the technologies, as this makes it much easier for both implementation and discussions. For example, if an implementation supports just one of the technologies, it is easier to state "supports RFCxxx" than "supports sections y, z, w of RFCyyy". 

Thank you, 

Ina 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Oscar González de Dios
Sent: Friday, October 26, 2012 2:16 AM
To: Jan Medved (jmedved); Fatai Zhang; Ramon Casellas; Julien Meuric
Cc: [email-masked]
Subject: Re: [Pce] 答复: stateful PCE - moving forward & next steps

Dear PCErs,

        Best Regards,

                Óscar

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 27 Oct 2012 16:19:26 +0100

Hello,
 
Speaking as an individual contributor...
 
I like Ed's picture, but I would offer an insert *if* it is possible. Maybe
there is a generic extensions document to be broken out and inserted in the
picture below "core framework draft" and before the fork into the various
targeted extensions drafts.
 
This might be over-cooking the problem because the generic could be included in
the first targeted extensions draft, and those could make reference. However,
consider poor old Ed having to point at a GMPLS-specific document in order to
tell his MPLS-TE vendor what to implement.
 
I appreciate that it is not always possible to consider the generic when there
is only one specific use case. But here we know that there are two in the pipe
so we can at least give some thought to it. 
 
A

From: [email-masked] [mailto:[email-masked]] On Behalf Of Edward
Crabbe
Sent: 26 October 2012 13:23
To: Oscar González de Dios
Cc: [email-masked]
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 

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 adds additional work in unnecessarily implementing
both or potentially 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ítica de envío y recepción de correo electrónico en el enlace situado má
s 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
[email-masked]
https://www.ietf.org/mailman/listinfo/pce

---

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 30 Oct 2012 15:08:55 +0100

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: [email-masked] [mailto:[email-masked]] On Behalf Of ext Edward Crabbe
Sent: Friday, October 26, 2012 2:23 PM
To: Oscar González de Dios
Cc: [email-masked]
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

	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.

 

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