[Pce] New I-D on PCE as a central controller

"Adrian Farrel" <adrian@olddog.co.uk> Fri, 06 May 2016 14:24 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA4712D61A for <pce@ietfa.amsl.com>; Fri, 6 May 2016 07:24:20 -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 GEkbGnohYPc4 for <pce@ietfa.amsl.com>; Fri, 6 May 2016 07:24:11 -0700 (PDT)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12D8912D60C for <pce@ietf.org>; Fri, 6 May 2016 07:24:10 -0700 (PDT)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u46EO8wn026489 for <pce@ietf.org>; Fri, 6 May 2016 15:24:08 +0100
Received: from 950129200 ([92.207.169.18]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u46EO67U026419 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <pce@ietf.org>; Fri, 6 May 2016 15:24:07 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'pce' <pce@ietf.org>
Date: Fri, 06 May 2016 15:24:02 +0100
Message-ID: <0c6501d1a7a2$f0e3da60$d2ab8f20$@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: AdGnou5lkpvZs91WRT2/Mf9DvaufmA==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22304.007
X-TM-AS-Result: No--22.896-10.0-31-10
X-imss-scan-details: No--22.896-10.0-31-10
X-TMASE-MatchedRID: IGdrTCYEWhFeqtHp15N9U1Pjo7D4SFg4QKuv8uQBDjr4JyR+b5tvoLuT SmkziLGEBA19C356nKoMo1U+ogv8V+QhIU5adD4PCFaAixm5eU9u/Xr6CKXiN7VhTD1Udgq8h3r xJ1Zk0E+ORNZGXn3P5ii6NtUf2AxdoqesYRoqSFkpa6LJktEjgLd2noO4P7rALraGNlLRahj2Rn Xgb9sKtMoLbse3mfomPYoc3x1xFgT3gr9T3KhP3gizXxlOHX34lnrMq7Sriu2dI/DikZ1UPN0HA AkfLxBxpmXcRoqbQErw6BX+s8AV64sN38OKtvda4bl1FkKDELczc8FC0MEwT0dMZyBoWgnkODUm 4pNxtIo2gANXtj6BAQNDWy0eadEVvQD12XFqHNMI8o+oRtTdk6APS3vFyaW62PljLKYGMfrdO1I Vye3Jy2epEVNLV6e/ECTq1hdYNfG4EooHfudG2oDqq/69HfgsD2lsxv9ktobM7zpEspqG//NvmS aCnjTlsBb3Q0HEUXwFnwbZRaSvqQzyMxeMEX6wOX/V8P8ail3InWAWA4yE6bazRqvlkBL0q7rFU cuGp/G8QIu4z6HhEH7cGd19dSFd
Archived-At: <http://mailarchive.ietf.org/arch/msg/pce/OXVqlE4CjOGdi21a7zkHns8uvd0>
Subject: [Pce] New I-D on PCE as a central controller
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 May 2016 14:24:21 -0000

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 (architecture discussion on the TEAS list, I think)

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