Re: [Teas] Status update on <draft-ietf-teas-pce-central-control>
Igor Bryskin <Igor.Bryskin@huawei.com> Fri, 24 March 2017 14:12 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 6C490129B94 for <teas@ietfa.amsl.com>; Fri, 24 Mar 2017 07:12:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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, T_KAM_HTML_FONT_INVALID=0.01] 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 jMwKLfxThhBP for <teas@ietfa.amsl.com>; Fri, 24 Mar 2017 07:12:47 -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 EA39E131461 for <teas@ietf.org>; Fri, 24 Mar 2017 07:12:46 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DDK81008; Fri, 24 Mar 2017 14:12:44 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 24 Mar 2017 14:12:41 +0000
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.233]) by SJCEML703-CHM.china.huawei.com ([169.254.5.195]) with mapi id 14.03.0235.001; Fri, 24 Mar 2017 07:12:32 -0700
From: Igor Bryskin <Igor.Bryskin@huawei.com>
To: Dieter Beller <Dieter.Beller@nokia.com>, "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+7y0nIAf0k8AAe9EkAAFIrOYAACONUwP//8ZsAgABzyKA=
Date: Fri, 24 Mar 2017 14:12:31 +0000
Message-ID: <0C72C38E7EBC34499E8A9E7DD0078639098DB5A5@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> <0C72C38E7EBC34499E8A9E7DD0078639098DB446@SJCEML702-CHM.china.huawei.com> <855b7c52-2e30-2a1f-dd0d-64a845ba583c@nokia.com>
In-Reply-To: <855b7c52-2e30-2a1f-dd0d-64a845ba583c@nokia.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: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD0078639098DB5A5SJCEML702CHMchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.58D5295C.017F, 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/bV2wOPuv6Z66_9OiZs0gy-IMnfc>
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 14:12:50 -0000
Dieter, Note that I said "realistically speaking". To be meaningful your email should contain examples of deployed multi-vendor (3 or more vendor) solutions interoping via GMPLS, as well GMPLS interoperability test events (rather than demos) starting from the most recent one. Cheers, Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Dieter Beller Sent: Friday, March 24, 2017 9:55 AM To: Igor Bryskin; Scharf, Michael (Nokia - DE/Stuttgart); Lou Berger; adrian@olddog.co.uk; teas@ietf.org Subject: Re: [Teas] Status update on <draft-ietf-teas-pce-central-control> Hi Igor, all, stating that GMPLS is "uninteroperable" is not correct! GMPLS interoperability across vendor domains has been demonstrated multiple times with different participating vendors. Thanks, Dieter On 24.03.2017 14:33, Igor Bryskin wrote: 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<mailto:adrian@olddog.co.uk>; teas@ietf.org<mailto: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<mailto:adrian@olddog.co.uk>; teas@ietf.org<mailto: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<mailto:Teas@ietf.org> https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list Teas@ietf.org<mailto:Teas@ietf.org> https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list Teas@ietf.org<mailto:Teas@ietf.org> https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list Teas@ietf.org<mailto:Teas@ietf.org> htt
- [Teas] Status update on <draft-ietf-teas-pce-cent… Adrian Farrel
- Re: [Teas] Status update on <draft-ietf-teas-pce-… Lou Berger
- Re: [Teas] Status update on <draft-ietf-teas-pce-… Scharf, Michael (Nokia - DE/Stuttgart)
- Re: [Teas] Status update on <draft-ietf-teas-pce-… Igor Bryskin
- Re: [Teas] Status update on <draft-ietf-teas-pce-… Lou Berger
- Re: [Teas] Status update on <draft-ietf-teas-pce-… Dieter Beller
- Re: [Teas] Status update on <draft-ietf-teas-pce-… Igor Bryskin
- Re: [Teas] Status update on <draft-ietf-teas-pce-… Doolan, Paul (Coriant - US/Irving)
- Re: [Teas] Status update on <draft-ietf-teas-pce-… Adrian Farrel
- Re: [Teas] Status update on <draft-ietf-teas-pce-… Igor Bryskin
- Re: [Teas] Status update on <draft-ietf-teas-pce-… Gert Grammel
- Re: [Teas] Status update on <draft-ietf-teas-pce-… Igor Bryskin
- Re: [Teas] Status update on <draft-ietf-teas-pce-… Gert Grammel
- Re: [Teas] Status update on <draft-ietf-teas-pce-… Scharf, Michael (Nokia - DE/Stuttgart)
- Re: [Teas] Status update on <draft-ietf-teas-pce-… Adrian Farrel
- Re: [Teas] Status update on <draft-ietf-teas-pce-… Scharf, Michael (Nokia - DE/Stuttgart)