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