Re: [Teas] Status update on <draft-ietf-teas-pce-central-control>
Gert Grammel <ggrammel@juniper.net> Fri, 24 March 2017 21:54 UTC
Return-Path: <ggrammel@juniper.net>
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 9DBE81299AC for <teas@ietfa.amsl.com>; Fri, 24 Mar 2017 14:54:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
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 efCyks_UzBwj for <teas@ietfa.amsl.com>; Fri, 24 Mar 2017 14:54:06 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0092.outbound.protection.outlook.com [104.47.33.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1D6412894E for <teas@ietf.org>; Fri, 24 Mar 2017 14:54:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=V5RENUmy+/cuffPnMXHkt66ht8JpagGUw8ICbSYNXy4=; b=QWyRg/BNAvDdlIel1RPovlrvaS+e1vqylSa1huy0SG72GfYPZsszYCt25FV0u90HHYi0l9TH6KxUkSXG7bfmscx/2Qn4lIPv4zOoOYOx5l8laopztvtv46tAo1lXa0Gn5cvCrAhGrB6TwQe6Z8GjUfp95UfpAWfE6VPX1ihaYS0=
Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1611.namprd05.prod.outlook.com (10.161.162.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Fri, 24 Mar 2017 21:54:03 +0000
Received: from CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) by CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) with mapi id 15.01.0991.018; Fri, 24 Mar 2017 21:54:03 +0000
From: Gert Grammel <ggrammel@juniper.net>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, Dieter Beller <dieter.beller@nokia.com>, "Scharf, Michael (Nokia - DE/Stuttgart)" <michael.scharf@nokia.com>, "Doolan, Paul (Coriant - US/Irving)" <paul.doolan@coriant.com>, Igor Bryskin <igor.bryskin@huawei.com>, Lou Berger <lberger@labn.net>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] Status update on <draft-ietf-teas-pce-central-control>
Thread-Index: AdKjAAxgpaATNu2BRR+7y0nIAf0k8AAQSTEAAFDVA4AAB62yAAAAv1UAAACc6IAABQuLLwALEt7H
Date: Fri, 24 Mar 2017 21:54:03 +0000
Message-ID: <CY1PR0501MB1609A310889D8D1731B0805CCE3E0@CY1PR0501MB1609.namprd05.prod.outlook.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>, <0C72C38E7EBC34499E8A9E7DD0078639098DB5A5@SJCEML702-CHM.china.huawei.com>, <AM2PR04MB0897E205C1A3DE513018BE80F83E0@AM2PR04MB0897.eurprd04.prod.outlook.com>
In-Reply-To: <AM2PR04MB0897E205C1A3DE513018BE80F83E0@AM2PR04MB0897.eurprd04.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: olddog.co.uk; dkim=none (message not signed) header.d=none;olddog.co.uk; dmarc=none action=none header.from=juniper.net;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [132.245.71.5]
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1611; 7:F0ewnOxc/ju76YMzYiV5gWOpY1Ife4AxHttbtKB/InEGsocuZouM4mitQb3kjrnjBEN36KtAhQulLIaK8tN1lca9+Rtr5gJMMPuIPWip1z8j3XfZHis44HaRz/TNjZapVMiW2gcQBL80RIH2FiH9x1H9oYc/TqQgurztf2SdLhhD7KecPAmllQRLj1e1PoKpqUMZ2+rd4gCxRX5p4hsECKdGqyMkH+g9hWtLvCvV2675koPJOcS3hNy9UYY7xpz0G9xEBX4pZUVbjxJGjAkknmycQZueIh5h5BOyHjLSHWiLC7YLQambIIU2yRxC1oZXjCnd7G3bHd526W4id8RQ/g==
x-ms-office365-filtering-correlation-id: f15e436e-8f1c-4b7f-f87c-08d47300496c
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:CY1PR0501MB1611;
x-microsoft-antispam-prvs: <CY1PR0501MB161170CD606B6D9AA0F9E94DCE3E0@CY1PR0501MB1611.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(131327999870524)(50582790962513)(82608151540597)(51653755401839)(81439100147899);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:CY1PR0501MB1611; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1611;
x-forefront-prvs: 0256C18696
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39860400002)(39840400002)(39450400003)(39850400002)(85664002)(13464003)(377454003)(24454002)(37854004)(2900100001)(6306002)(8676002)(3660700001)(81166006)(54896002)(93886004)(99286003)(8936002)(66066001)(53936002)(2501003)(551934003)(2950100002)(55016002)(229853002)(6116002)(8666007)(77096006)(606005)(86362001)(9686003)(6506006)(230783001)(25786009)(53546009)(102836003)(6436002)(3846002)(5660300001)(3280700002)(76176999)(122556002)(236005)(54356999)(189998001)(2906002)(7736002)(19627405001)(305945005)(50986999)(7906003)(74316002)(15650500001)(33656002)(38730400002)(6246003)(7696004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1611; H:CY1PR0501MB1609.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR0501MB1609A310889D8D1731B0805CCE3E0CY1PR0501MB1609_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2017 21:54:03.2563 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1611
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/UjGDGhD8N35WypPLSiHO9q0sDsU>
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 21:54:10 -0000
Whether GMPLS is "realistically interoperable" is certainly worth to debate. By doing so however we have to keep in mind that GMPLS is a control plane for a non-IP data plane. When CCAMP set out to work on GMPLS for WDM (WSON) we might have had asked how many of interoperable (non proprietary) DWDM implementations do exist. How much leverage you can have from an interoperable control plane when the photons have a hard time to find their way between different vendors? Fortunately the IP data plane is in a better shape as this email will certainly travel through dozens of vendor domains and a handful of carrier domains, each potentially structured in a few operational domains. In other words, lgor's statement that GMPLS is not field proven (using a different term here) to interoperate looks correct. The question is now what's next: 1) screw the whole thing since the world doesn't need a standard for protocols that do not interoperate. 2) fix whatever is needed to interoperate (and this requires data plane interoperate too) 3) accept the facts and muddle through by pretending interoperability would be feasible and adding vendor specific loopholes to decrease the probability we'll ever get there. Perhaps a discussion worth to have together with CCAMP. Gert Get Outlook for iOS<https://aka.ms/o0ukef> _____________________________ From: Doolan, Paul (Coriant - US/Irving) <paul.doolan@coriant.com<mailto:paul.doolan@coriant.com>> Sent: Friday, March 24, 2017 9:38 AM Subject: Re: [Teas] Status update on <draft-ietf-teas-pce-central-control> To: <teas@ietf.org<mailto:teas@ietf.org>>, Igor Bryskin <igor.bryskin@huawei.com<mailto:igor.bryskin@huawei.com>>, Dieter Beller <dieter.beller@nokia.com<mailto:dieter.beller@nokia.com>>, Scharf, Michael (Nokia - DE/Stuttgart) <michael.scharf@nokia.com<mailto:michael.scharf@nokia.com>>, <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>, Lou Berger <lberger@labn.net<mailto:lberger@labn.net>> Hi Dieter, you might want to start by Googling "huawei gmpls interoperability". Just a thought. cheers, pd ________________________________ From: Teas <teas-bounces@ietf.org<mailto:teas-bounces@ietf.org>> on behalf of Igor Bryskin <Igor.Bryskin@huawei.com<mailto:Igor.Bryskin@huawei.com>> Sent: Friday, March 24, 2017 10:12 AM To: Dieter Beller; Scharf, Michael (Nokia - DE/Stuttgart); 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> 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<mailto:adrian@olddog.co.uk>; teas@ietf.org<mailto: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)