Hi Cyril,

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



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)" <cyril.marga...@nsn.com>
To: "ext Fatai Zhang" <zhangfa...@huawei.com>
Cc: <pce@ietf.org>; <sures...@huawei.com>
Sent: Thursday, January 07, 2010 9:09 PM
Subject: RE: [Pce] New draft: draft-margaria-pce-gmpls-pcep-extensions-00



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.

[Fatai]: Agree with you. We can just identify network type (e.g., SDH or 
WDM...) through Switching 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?

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

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 

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

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.

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

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.

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

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

Thanks, 
Cyril Margaria 



> ----- Original Message ----- 
> From: ext Fatai Zhang [mailto:zhangfa...@huawei.com] 
> Sent: Wednesday, January 06, 2010 2:34 AM
> To: Margaria, Cyril (NSN - DE/Munich)
> Cc: pce@ietf.org; sures...@huawei.com
> Subject: Re: [Pce] New draft: draft-margaria-pce-gmpls-pcep-extensions-00
>
>
> 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)" <cyril.marga...@nsn.com>
> > To: <pce@ietf.org>
> > Sent: Tuesday, January 05, 2010 5:44 PM
> > Subject: [Pce] New draft: draft-margaria-pce-gmpls-pcep-extensions-00
> > 
> > 
> > 
> > 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:cyril.marga...@nsn.com
> > 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
> > 
> > _______________________________________________
> > Pce mailing list
> > Pce@ietf.org
> > https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Reply via email to