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

"Margaria, Cyril (NSN - DE/Munich)" <cyril.margaria@nsn.com> Sun, 10 March 2013 19:33 UTC

Return-Path: <cyril.margaria@nsn.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3508921F88F7 for <pce@ietfa.amsl.com>; Sun, 10 Mar 2013 12:33:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V42muI0-b5IU for <pce@ietfa.amsl.com>; Sun, 10 Mar 2013 12:33:03 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA9821F8610 for <pce@ietf.org>; Sun, 10 Mar 2013 12:33:02 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r2AJWsYC005168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 10 Mar 2013 20:32:54 +0100
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r2AJWs2I022605 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 10 Mar 2013 20:32:54 +0100
Received: from DEMUMBX006.nsn-intra.net ([169.254.6.244]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.02.0328.009; Sun, 10 Mar 2013 20:32:54 +0100
From: "Margaria, Cyril (NSN - DE/Munich)" <cyril.margaria@nsn.com>
To: "ext Zhangxian (Xian)" <zhang.xian@huawei.com>, "pce@ietf.org" <pce@ietf.org>
Thread-Topic: Comments on draft-zhang-pce-pcep-stateful-pce-gmpls:
Thread-Index: Ac4QKMHpsICkLcwmRuqMJNJGNQMmqAI7gahFASrbIsA=
Date: Sun, 10 Mar 2013 19:32:53 +0000
Message-ID: <8DC6547C806B644F998A0566E79E15920F7DB5A1@DEMUMBX006.nsn-intra.net>
References: <8DC6547C806B644F998A0566E79E15920F7CFCDA@DEMUMBX006.nsn-intra.net> <C636AF2FA540124E9B9ACB5A6BECCE6B13993A3A@szxeml535-mbx.china.huawei.com>
In-Reply-To: <C636AF2FA540124E9B9ACB5A6BECCE6B13993A3A@szxeml535-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.122]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 6044
X-purgate-ID: 151667::1362943975-00003B04-FAF3BFB1/0-0/0-0
Subject: Re: [Pce] Comments on draft-zhang-pce-pcep-stateful-pce-gmpls:
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pce>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Mar 2013 19:33:04 -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.
> 
> 2.      Section 2.3 : is this GMPLS specific or stateful specific?
> [Xian]: It is GMPLS specific (please see the updated version).

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.

> 
> 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:cyril.margaria@nsn.com
> 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
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce