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

Lou Berger <lberger@labn.net> Fri, 24 March 2017 13:43 UTC

Return-Path: <lberger@labn.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 3162D129B3C for <teas@ietfa.amsl.com>; Fri, 24 Mar 2017 06:43:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 puEXLIw3O1Em for <teas@ietfa.amsl.com>; Fri, 24 Mar 2017 06:43:57 -0700 (PDT)
Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5607D1296EA for <teas@ietf.org>; Fri, 24 Mar 2017 06:43:57 -0700 (PDT)
Received: from [::1] (port=60955) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.86_1) (envelope-from <lberger@labn.net>) id 1crPVU-0002cr-CU; Fri, 24 Mar 2017 16:43:56 +0300
To: Igor Bryskin <Igor.Bryskin@huawei.com>, "Scharf, Michael (Nokia - DE/Stuttgart)" <michael.scharf@nokia.com>, "teas@ietf.org" <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>
Cc: "adrian@olddog.co.uk" <adrian@olddog.co.uk>
From: Lou Berger <lberger@labn.net>
Message-ID: <ed434b55-dda5-aa5c-ee48-fac5811a859a@labn.net>
Date: Fri, 24 Mar 2017 09:43:54 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <0C72C38E7EBC34499E8A9E7DD0078639098DB446@SJCEML702-CHM.china.huawei.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com
X-Authenticated-Sender: newdragon.webhostserver.biz: lberger@blabn.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/DZHOPJFrSKY44ckXFNIASuMeZt4>
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:43:59 -0000

Thank you both for the additional input - would either of you care to
propose some specific text changes to address your comments/concerns?

Thanks,

Lou


On 3/24/2017 9:33 AM, 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; 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
>
>