Re: [Teas] Status update on <draft-ietf-teas-pce-central-control>

Igor Bryskin <Igor.Bryskin@huawei.com> Fri, 24 March 2017 13:33 UTC

Return-Path: <Igor.Bryskin@huawei.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D69F1296CC for <teas@ietfa.amsl.com>; Fri, 24 Mar 2017 06:33:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level:
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okvoAGOjfB3S for <teas@ietfa.amsl.com>; Fri, 24 Mar 2017 06:33:49 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 797E41296CF for <teas@ietf.org>; Fri, 24 Mar 2017 06:33:48 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DDK75669; Fri, 24 Mar 2017 13:33:47 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 24 Mar 2017 13:33:46 +0000
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.233]) by SJCEML701-CHM.china.huawei.com ([169.254.3.8]) with mapi id 14.03.0235.001; Fri, 24 Mar 2017 06:33:34 -0700
From: Igor Bryskin <Igor.Bryskin@huawei.com>
To: "Scharf, Michael (Nokia - DE/Stuttgart)" <michael.scharf@nokia.com>, Lou Berger <lberger@labn.net>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] Status update on <draft-ietf-teas-pce-central-control>
Thread-Index: AdKjAAxgpaATNu2BRR+7y0nIAf0k8AAe9EkAAFIrOYAACONUwA==
Date: Fri, 24 Mar 2017 13:33:34 +0000
Message-ID: <0C72C38E7EBC34499E8A9E7DD0078639098DB446@SJCEML702-CHM.china.huawei.com>
References: <092c01d2a304$19ca7120$4d5f5360$@olddog.co.uk> <30c7bedf-3866-e824-147d-d3344c02a8dd@labn.net> <AM5PR0701MB2547C9EBEDB6492C05D46697933E0@AM5PR0701MB2547.eurprd07.prod.outlook.com>
In-Reply-To: <AM5PR0701MB2547C9EBEDB6492C05D46697933E0@AM5PR0701MB2547.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.254.254]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.58D5203B.0061, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.233, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: efd4eb41dc537b78b75425a698952c4b
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/Qu9c7Nih65m5ZO_WJ_m8XHfWjU4>
Subject: Re: [Teas] Status update on <draft-ietf-teas-pce-central-control>
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Mar 2017 13:33:51 -0000

Thanks Michael,

I have similar concerns. If there is a need for proprietary PCEP extensions to accommodate vendor specific semantics, how we will not end up with the same issues that have made GMPLS RSVP-TE/OSPF-TE, realistically speaking, uninteroperable? In other words, would you agree that applied to circuit switched technologies, PCEP has exact same probability for interoperability success as GMPLS? Note that for IP/MPLS networks there is no (or at least much less) potential PCEP interop problems, but IP/MPLS control plane has proved to be interoperable as well.

Igor     

-----Original Message-----
From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE/Stuttgart)
Sent: Friday, March 24, 2017 6:32 AM
To: Lou Berger; adrian@olddog.co.uk; teas@ietf.org
Subject: Re: [Teas] Status update on <draft-ietf-teas-pce-central-control>

We have already discussed "lively" the speculative statements in certain sections of this document.

To me, examples such as section 3.1.4 (and others) ...

   It may be the case that additional technology-
   specific parameters are needed to configure the NEs and these
   parameters will need to be carried in the PCEP messages

... continue to somehow contradict the expectation in Section 4 that extensions will be generic:

   The only work expected to be needed is small extensions
   to carry additional or specific information elements for the
   individual use cases.  Where possible, consistent with the general
   principles of how protocols are extended, any additions to the
   protocol should be made in a generic way such that they are open to
   use in a range of applications.

Having said this, maybe one could add some thoughts on increased PCEP protocol complexity (e.g., would it possible that the small PCEP extensions would require transaction and rollback support?), impact on running PCEP code, as well as implications on interoperability testing between implementations? This might partly be speculation, but manageability impact doesn't seem entirely unrealistic for some of the use cases considered in the document.

Thanks

Michael


> -----Original Message-----
> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger
> Sent: Mittwoch, 22. März 2017 20:19
> To: adrian@olddog.co.uk; teas@ietf.org
> Subject: Re: [Teas] Status update on <draft-ietf-teas-pce-central-control>
> 
> WG,
> 
>     This is the 2nd (or 3rd) time the authors are stating that the document is
> ready to LC  since it was adopted ~6months ago - without there being any
> substantive discussion on the document within the WG and only a minor
> update in December.  It's a little hard for us (chairs) to know if silence is due
> to complete agreement with the document or simply apathy.  From the
> message below, the authors clearly think it's the former.  If you are *not* an
> author of this document and are willing to share your opinion on this
> document, please do so -- preferably on the list, but unicast to the chairs is
> also acceptable.  We will also ask for feedback on the draft during the status
> portion of the meeting.
> 
> Thank you,
> 
> Lou (and Pavan)
> 
> 
> On 3/22/2017 8:01 AM, Adrian Farrel wrote:
> > Hi,
> >
> > As requested, here is the status of this I-D.
> >
> > - Not on the agenda in Chicago
> >
> > - New revision posted in December
> >    - Fixed nits after re-review by several authors
> >
> > - The authors have repeatedly pointed out to the chairs that the
> >    document is complete and ready to move forward.
> >    - At this stage, the chairs are blocking progress
> >
> > - Related work...
> >    - Use cases document has been adopted in TEAS
> >       draft-ietf-teas-pcecc-use-cases
> >
> > Adrian
> >
> >
> > _______________________________________________
> > Teas mailing list
> > Teas@ietf.org
> > https://www.ietf.org/mailman/listinfo/teas
> >
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas