Subject: [Pce] New draft: draft-margaria-pce-gmpls-pcep-extensions-00

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 5 Jan 2010 10:44:30 +0100

Dear PCEers,

We have just submitted a new drat on "PCEP extensions for GMPLS". 
The draft specifies optional extensions to the PCEP protocol to comply with the GMPLS requirements for PCEP. These extensions may be also applicable in the WSON context.
We urge you to review the draft and provide your valuable comments. 
The draft can be found at http://www.ietf.org/internet-drafts/draft-margaria-pce-gmpls-pcep-extensions-00.txt 

Thanks and best regards,
Cyril Margaria

Nokia Siemens Networks GmbH & Co. KG
Broadband Connectivity Solutions
St.Martin-Str. 76
D-81541 München
Germany
mailto:[email-masked]
Phone: +49-89-5159-16934
Fax:   +49-89-636-40288
---------------------------------------------------------------- 
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: Lydia Sommer, Olaf Horsthemke
Vorsitzender des Aufsichtsrats / Chairman of supervisory board: Lauri Kivinen
Sitz der Gesellschaft: München / Registered office: Munich
Registergericht: München / Commercial registry: Munich, HRB 163416

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 06 Jan 2010 09:34:04 +0800

Hi Cyril,

What a coincidence to see your draft after we just submited our draft (draft-zhang-pce-pcep-extensions-for-sdh-00.txt) [draft-zhang-pcep-ext].

Great minds think alike.  Happy to see that happened.

Hope you can spare some time to review [draft-zhang-pcep-ext]. We are looking forward to discussing more with you.

We also invite all the experts from PCE WG to review  [draft-zhang-pcep-ext].

Thanks
 
Fatai
 
Advanced Technology Department
Wireline Networking Business Unit
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935

----- Original Message ----- 
From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, January 05, 2010 5:44 PM
Subject: [Pce] New draft: draft-margaria-pce-gmpls-pcep-extensions-00

Dear PCEers,

Thanks and best regards,
Cyril Margaria

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

---

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 7 Jan 2010 14:09:41 +0100

Hi Fatai, 

I am also happy to see work going in this direction. 
I have some questions and remarks on your draft.

Section "4.1. RP Object Extension"
The NT field is specifying for which kind of network the request is. 
I think the information on the type on network could also be represented by SWITCH-LAYER object from draft-ietf-pce-inter-layer-ext.
This information seems also redundant with the encoding and switching type provided in the "4.1.1. Requested GMPLS Label Information".
Its also not clear to me what is the processing of this field, especially in the case of multilayer network type.

Regarding "4.1.1. Requested GMPLS Label Information", its stated that this object is used if the resources required are requested using generalized label. Is this to be used in a PCReq or PCRep? To which generalized labels does this subtlv-refers to, I can see label in the ERO and the other route object, but those may represent a multi-layer route, where the generalized labels might have different encodings. Which labels are meant here?

in case a multilayer request is considered and a generalied label is used, the PCEP may carry labels for several layers, so only considering the first "Requested GMPLS Label Information " subtlv may not be sufficient, on the other hand its 

For the Qos section, the section 4.4.1 does not allow different forward/reverse Traffic spec as in RFC5467, and its not clear how to distnguish the old QoS from the new Qos in case of reoptimization requests.

In "4.4.2. LSP Protection Information TLV", I think reusing the RFC4872 and RFC3471 LSP flags and Link flags would be more in line with RSVP-TE signaling. 
In this section its not clear on how to use the Protection information, some fields seems to go in the direction of a statefull PCE (Segment Recovery, Associated LSP ID), however its not clear how those fields are to be used and processed, for instance the associated LSP id can be used only if the LSP ids are known to the PCE.

I am looking forward to discuss those two draft with you.

Thanks, 
Cyril Margaria 

> From: ext Fatai Zhang [mailto:[email-masked]] 
> Sent: Wednesday, January 06, 2010 2:34 AM
> To: Margaria, Cyril (NSN - DE/Munich)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Pce] New draft: draft-margaria-pce-gmpls-pcep-extensions-00
>
>
> Hi Cyril,
>

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 08 Jan 2010 15:27:08 +0800

Hi Cyril,

Thanks for your valuable comments. Please see the in-line response.

Thanks
 
Fatai

----- Original Message ----- 
From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
To: "ext Fatai Zhang" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, January 07, 2010 9:09 PM
Subject: RE: [Pce] New draft: draft-margaria-pce-gmpls-pcep-extensions-00

Hi Fatai, 

[Fatai]: Agree with you. We can just identify network type (e.g., SDH or WDM...) through Switching Type.

[Fatai]: It is used in PCReq and it refers to SDH layer.

[Fatai]: We have not considered multi-layered scenario. If Mutli-layer should be considered, we can re-use the extensions defined in [PCE-MLN-Ext].

[Fatai]: Our draft is for SDH networks. We know usually there is no this case for asymmetric bandwidth bidirectional LSP in SDH networks(i.e., bidirectional LSP is considered with same QoS on both directions). Of cource, if we need to cover the requirements in RFC5467, I think we can just add [Upstream-Bandwidth] to identify asymmetric bandwidth. Reoptimization is already captured in RFC5440.

[Fatai]: We can reference the protection object defined in RFC4872 or RFC4873, but we can not simply copy the object defined in RFC4872 or RFC4873 (i.e., some fields should be removed and add some new fields additionally). We will check the object again and remove Associated LSP ID.

Thanks, 
Cyril Margaria