Subject: Re: [Pce] Comments on draft-zhang-pce-pcep-stateful-pce-gmpls:

From: "Zhangxian (Xian)" <[email-masked]>
Date: Mon, 4 Mar 2013 21:58:29 +0000

Hi, Cyril, 
   
    Thank you for the comments, I believe that our updated draft (URL: http://tools.ietf.org/html/draft-zhang-pce-pcep-stateful-pce-gmpls-02) can answer most of your questions listed below. Please see my detailed reply inline.

    I would also like to take this opportunity, requesting experts in the PCE working group review this draft and any comments are appreciated. Thank you.

    The major updates of this draft are: 

1) split it into two drafts, the other one, focusing on explanation of how stateful PCE can support time-based scheduling, is available in http://tools.ietf.org/html/draft-zhang-pce-stateful-time-based-scheduling-00; This new draft focuses on explaining the requirements and models available to support time-based scheduling, as well as additional objects needed in PCEP. 
2) Update on extensions/procedure explanation of stateful PCE usage in GMPLS networks; 

Regards,

Xian
________________________________________
发件人: [email-masked] [[email-masked]] 代表 Margaria, Cyril (NSN - DE/Munich) [[email-masked]]
发送时间: 2013年2月21日 19:44
到: [email-masked]; [email-masked]
主题: [Pce] Comments on draft-zhang-pce-pcep-stateful-pce-gmpls:

Hi PCEers

I did not see any reply on my previous comments I repost them with separate threads, as the initial one were big
1.      Section 2.2.1 : this is not only useful for stateful, but also for stateless, this should be integrated to draft-ietf-pce-inter-layer-ext
[Xian]: point taken. the authors of draft-ietf-pce-inter-layer-ext has agreed to put in that draft and we only cite it in this draft.

2.      Section 2.3 : is this GMPLS specific or stateful specific?
[Xian]: It is GMPLS specific (please see the updated version). 

3.      Section 2.4 : IMHO this should not be necessary, the generic part should describe how  to deal with non-supported objects,
[Xian]: Sorry, i do not follow your quesiton here. This section is GMPLS specific and it does not describe how to deal with non-supported object.

4.      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.,
[Xian]: We are focusing on the technical points to support stateful PCE usage in GMPLS networks, it may work for MPLS-TE as well. If agreed, I have no issue moving this to where they are agreed to be.

5.      Section 2.6 : how is this GMPLS-specific? This should be another set of extensions maybe.
[Xian]: Indeed, they deserve a separate draft so we did that.

My understanding is that the required extension to support an *active* stateful PCE for GMPLS network is contained in section 2.4, which indicates the following:

   o GENERALIZED BANDWIDTH -> Object, optional in the GMPLS extensions BTW
   o PROTECTION ATTRIBUTE -> this should be LSPA PROTECTION-ATTRIBUTE TLV --> This is already supported by draft-crabbe-pce-stateful-pce-mpls-te-00
   o Extended Objects to support the inclusion of label sub-object
      - RP
     - IRO
     - XRO
 --> Those are not specific to GMPLS

So the only missing object to support active stateful GMPLS PCE is an optional GENERALIZED-BANDWIDTH, this does not seem a big requirement.
I would rather see one solution for passive stateful and one for active stateful than a mix of passive and active, plus 3 similar RSVP-TE solutions.

[Xian]: This draft intends to show the necessity to cover GMPLS in stateful PCEP extensions, since we believe draft-ietf-pce-gmpls-pcep-extensions cannot cover that (due to the introduction of path update and path report functions, please see our update for the details). As for how the PCEP extension draft(s) should be organized, I am pretty flexible and open to suggestions, :-).

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

---

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Sun, 10 Mar 2013 19:32:53 +0000

Hi, Xian, PCEers

> 
> I did not see any reply on my previous comments I repost them with
> separate threads, as the initial one were big
> 1.      Section 2.2.1 : this is not only useful for stateful, but also
> for stateless, this should be integrated to draft-ietf-pce-inter-layer-
> ext
> [Xian]: point taken. the authors of draft-ietf-pce-inter-layer-ext has
> agreed to put in that draft and we only cite it in this draft.
> 

I was referring to the paragraph about LSP state synchronization and multi-domain networks.
The multi-domain aspect is not GMPLS specific, it should be addressed IMHO in the framework/extension part.

> 
> 3.      Section 2.4 : IMHO this should not be necessary, the generic
> part should describe how  to deal with non-supported objects,
> [Xian]: Sorry, i do not follow your quesiton here. This section is
> GMPLS specific and it does not describe how to deal with non-supported
> object.

If the generic part was simply accepting the PCEP <path> protocol grammar (Which you are re-defining here) and how to deal with non-supported objects (Similar to RFC5440)this would not be needed.

More specifically I think there is actually few things to add:
 - <path> is already described in RFC5440 and extensions, do you intend to redefine this also for PCREp?
 - GENERALIZED-ENDPOINTS is covered by the MPLS-TE (as the ENDPOINTS object is supported) 
 - PROTECTION_ATTRIBUTE TLV is also covered by the MPLS-TE (LSPA object is supported) 
 - ERROR_SPEC : would'nt it be  better and future proof to define one TLV containing any RSVP ERROR SPEC object, similar to the ERO 

> 
> 4.      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.,
> [Xian]: We are focusing on the technical points to support stateful PCE
> usage in GMPLS networks, it may work for MPLS-TE as well. If agreed, I
> have no issue moving this to where they are agreed to be.

It would be interesting to hear from other document editors here.

> My understanding is that the required extension to support an *active*
> stateful PCE for GMPLS network is contained in section 2.4, which
> indicates the following:
> 
>    o PROTECTION ATTRIBUTE -> this should be LSPA PROTECTION-ATTRIBUTE
> TLV --> This is already supported by draft-crabbe-pce-stateful-pce-
> mpls-te-00
> So the only missing object to support active stateful GMPLS PCE is an
> optional GENERALIZED-BANDWIDTH, this does not seem a big requirement.
> I would rather see one solution for passive stateful and one for active
> stateful than a mix of passive and active, plus 3 similar RSVP-TE
> solutions.
> 
> [Xian]: This draft intends to show the necessity to cover GMPLS in
> stateful PCEP extensions, since we believe draft-ietf-pce-gmpls-pcep-
> extensions cannot cover that (due to the introduction of path update
> and path report functions, please see our update for the details). As
> for how the PCEP extension draft(s) should be organized, I am pretty
> flexible and open to suggestions, :-).

;-)