Re: [Teas] A New I-D on PCE as a central controller

"Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com> Thu, 12 May 2016 11:43 UTC

Return-Path: <michael.scharf@nokia.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 AE79712D95C for <teas@ietfa.amsl.com>; Thu, 12 May 2016 04:43:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 7dMEtudaijCf for <teas@ietfa.amsl.com>; Thu, 12 May 2016 04:43:01 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C44212D66A for <teas@ietf.org>; Thu, 12 May 2016 04:43:01 -0700 (PDT)
Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 879ABC9936092; Thu, 12 May 2016 11:42:57 +0000 (GMT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4CBgxN7006300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 May 2016 11:42:59 GMT
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u4CBfaup016007 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 May 2016 13:42:57 +0200
Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 12 May 2016 13:41:14 +0200
From: "Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] A New I-D on PCE as a central controller
Thread-Index: AdGnosEWtnZGzgfkR5SQqz0Nm22cLQEn1m5Q
Date: Thu, 12 May 2016 11:41:13 +0000
Message-ID: <655C07320163294895BBADA28372AF5D48846127@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References: <0c6c01d1a7a2$f1a24860$d4e6d920$@olddog.co.uk>
In-Reply-To: <0c6c01d1a7a2$f1a24860$d4e6d920$@olddog.co.uk>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.41]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/teas/nsIVaRY1_7qZuHANwYn-vME6Yo8>
Subject: Re: [Teas] A New I-D on PCE as a central controller
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 12 May 2016 11:43:04 -0000

When reading about uses cases such as L3VPN service delivery in "Section 3.2.3", what is the author's view on the line of demarcation between NETCONF and PCEP?

Thanks

Michael


-----Original Message-----
From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of EXT Adrian Farrel
Sent: Friday, May 06, 2016 4:24 PM
To: teas@ietf.org
Subject: [Teas] A New I-D on PCE as a central controller

Hi,

The idea of a "PCE-based central controller" has been bouncing around between PCE and TEAS for a bit. There have been plenty of use cases proposed and some protocol extension work.

In Buenos Aires a group of us got together to try to work out where all this was going and how to structure the work to get more progress especially on the bits that some people are very keen to advance quickly.

The result is this architecture document which we are targeting at TEAS.
Originally intended to be very short and simple it has already grown a bit, but it is still a manageable read. Our idea is that the different use cases will result in a variety of distinct protocol extensions to PCEP that can be handled in separate documents in the PCE working group . This will allow different people to support different use cases and work on them at their own speed.

Discussion is encouraged.

Adrian (per pro "the team")

> -----Original Message-----
> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of 
> internet-drafts@ietf.org
> Sent: 06 May 2016 15:16
> To: i-d-announce@ietf.org
> Subject: I-D Action: draft-zhao-teas-pce-control-function-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> 
> 
>         Title           : An Architecture for Use of PCE and PCEP in a Network
with Central
> Control
>         Authors         : Adrian Farrel
>                           Quintin Zhao
>                           Robin Li
>                           Chao Zhou
> 	Filename        : draft-zhao-teas-pce-control-function-00.txt
> 	Pages           : 21
> 	Date            : 2016-05-06
> 
> Abstract:
>    The Path Computation Element (PCE) has become established as a core
>    component of Software Defined Networking (SDN) systems.  It can
>    compute optimal paths for traffic across a network for any definition
>    of "optimal" and can also monitor changes in resource availability
>    and traffic demands to update the paths.
> 
>    Conventionally, the PCE has been used to derive paths for MPLS Label
>    Switched Paths (LSPs).  These paths are supplied using the Path
>    Computation Element Communication Protocol (PCEP) to the head end of
>    the LSP for signaling in the MPLS network.
> 
>    SDN has a far broader applicability than just signaled MPLS traffic
>    engineered networks, and the PCE may be used to determine paths in a
>    wide range of use cases including static LSPs, segment routing,
>    service function chaining (SFC), and indeed any form of routed or
>    switched network.  It is, therefore reasonable to consider PCEP as a
>    general southbound control protocol for use in these environments to
>    allow the PCE to be fully enabled as a central controller.
> 
>    This document briefly introduces the architecture for PCE as a
>    central controller, examines the motivations and applicability for
>    PCEP as a southbound interface, and introduces the implications for
>    the protocol.  This document does not describe the use cases in
>    detail and does not define protocol extensions: that work is left for
>    other documents.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-zhao-teas-pce-control-function/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-zhao-teas-pce-control-function-00
> 
> 
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas