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

"Adrian Farrel" <adrian@olddog.co.uk> Sat, 25 March 2017 19:22 UTC

Return-Path: <adrian@olddog.co.uk>
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 1D4B7127071 for <teas@ietfa.amsl.com>; Sat, 25 Mar 2017 12:22:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 tG8yrwlc_2Nb for <teas@ietfa.amsl.com>; Sat, 25 Mar 2017 12:22:56 -0700 (PDT)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E928126DEE for <teas@ietf.org>; Sat, 25 Mar 2017 12:22:55 -0700 (PDT)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2PJMsVP019182; Sat, 25 Mar 2017 19:22:54 GMT
Received: from 950129200 ([63.88.116.178]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2PJMlBD019143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Mar 2017 19:22:51 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'Scharf, Michael (Nokia - DE/Stuttgart)'" <michael.scharf@nokia.com>
Cc: teas@ietf.org
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> <037901d2a4cd$773eeff0$65bccfd0$@olddog.co.uk> <AM5PR0701MB2547EF7B1D8F76109E7C1D7C93310@AM5PR0701MB2547.eurprd07.prod.outlook.com>
In-Reply-To: <AM5PR0701MB2547EF7B1D8F76109E7C1D7C93310@AM5PR0701MB2547.eurprd07.prod.outlook.com>
Date: Sat, 25 Mar 2017 19:22:48 -0000
Message-ID: <048101d2a59d$3421bb00$9c653100$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKb0aL8/sX5JdHERCal49mBbvQK1wJ8NEHxAuh0PDUB7BZyVQHLy1MnAihZsBefuW9zkA==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22966.002
X-TM-AS-Result: No--16.260-10.0-31-10
X-imss-scan-details: No--16.260-10.0-31-10
X-TMASE-MatchedRID: QfHZjzml1E9Rn39sim9+cAgKAWhuC2ojEtdrY/Wb3fO3wsXu/BJrkGJr 9a6TwZ2jsd1IBMpcqUDkdXOpRBCtidux1f2eHThjutvHF25zoU+QW82QXmgoYCBQRBOQhaJiUZ2 pr44sMejE+nTdM2Xui1/zzryQSmeZtw/o4J9vD+ZGypC5CVFOH6CjvIRDW3XLi2g8XzxCDfsz+z kqltke7K9fCkezxy4fWLB2uYKWMtxYXTxImR5ZvK+dYEguu4aVxQ7dj5rD+RtXPwnnY5XL5KM2w wuSd3QV4vM1YF6AJbZcLc3sLtjOt+TCMddcL/gjkGUtrowrXLg=
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/GOupt31v5wWL28qfKTyoOkTga4Q>
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: Sat, 25 Mar 2017 19:22:58 -0000

Thanks Michael,

I don't agree with all the points you make, but thanks for the advice on
designing network protocols. I guess I am learning all the time.

With regard to...

> > An architecture does not typically try to constrain solutions, but I
wouldn't
> > think it harmful to include a note on "Guidance for Solution Developers"
that
> > could touch *lightly* on these points at least by pointing them out, but not
> > necessarily directing how they are handled.
> 
> Indeed, albeit I believe some discussion on the potential challenges of PCEP
> extensions could also be homed in Section 4 or 6.
> 
> > Michael ends by asking about manageability impact. I find that difficult to
> > answer. This is a management architecture. It is all about management. So
> > the impact is that the management of the network would change.
> >
> > I confess that Section 6 seemed light when I wrote it. But what to add? What
> > would you like to see covered in addition?
> 
> The impact on interoperability of existing PCEP implementations and a
discussion
> how to ensure this interoperability in future might fit in here, no?

Great.
We'll wait for your text.

Thanks,
Adrian