Re: [Teas] CCDR scenarios, simulation and suggestions

"Aijun Wang" <wangaijun@tsinghua.org.cn> Thu, 20 July 2017 06:17 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
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 6492D12EA74 for <teas@ietfa.amsl.com>; Wed, 19 Jul 2017 23:17:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.775
X-Spam-Level:
X-Spam-Status: No, score=-0.775 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=1.125, SPF_PASS=-0.001] 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 izYVo3tSPcld for <teas@ietfa.amsl.com>; Wed, 19 Jul 2017 23:17:35 -0700 (PDT)
Received: from m176115.mail.qiye.163.com (m176115.mail.qiye.163.com [59.111.176.115]) by ietfa.amsl.com (Postfix) with ESMTP id EA430124217 for <teas@ietf.org>; Wed, 19 Jul 2017 23:17:34 -0700 (PDT)
Received: from WangajPC (unknown [219.142.69.78]) by m176115.mail.qiye.163.com (Hmail) with ESMTPA id 9CB826612DF; Thu, 20 Jul 2017 14:17:31 +0800 (CST)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: julien.meuric@orange.com, michael.scharf@nokia.com, db3546@att.com
Cc: 'TEAS WG' <teas@ietf.org>, 'LuHuang' <hlisname@yahoo.com>
References: <005301d2f16a$c34d5be0$49e813a0$@bri@chinatelecom.cn>
In-Reply-To: <005301d2f16a$c34d5be0$49e813a0$@bri@chinatelecom.cn>
Date: Thu, 20 Jul 2017 14:17:28 +0800
Message-ID: <000601d3011f$dd49c690$97dd53b0$@org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01D30162.EB6D0690"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdLxasJh2iVWKQJsQPmuFVBT/C1CnwPrgXrw
Content-Language: zh-cn
X-HM-Spam-Status: e1kIGBQJHllBS1VLV1koWUFKTEtLSjdXWS1ZQUlXWQkOFx4IWUFZMjUtOj cyP0FLVUtZBg++
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Mj46KQw4LDorHwEyDRNPPDJC PQpPChdVSlVKTktLTkhKT05JS0tLVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxDWVdZCAFZQUpDQk9ONwY+
X-HM-Tid: 0a5d5ea4e7a99373kuws9cb826612df
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/Q5MphTpoBGiMho9KbfyaJ_astDU>
Subject: Re: [Teas] CCDR scenarios, simulation and suggestions
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: Thu, 20 Jul 2017 06:17:37 -0000

Hi, Julien, Michael and Deborah:

 

Thanks for your comments on Mr.Huang Lu’s presentation(CCDR Presentation
Material
<https://www.ietf.org/proceedings/99/slides/slides-99-teas-sessa-13-ccdr-cen
trally-control-dynamic-routing-scenario-simulation-and-suggestion-01.pdf> )
about the CCDR on Tuesday Morning’s TEAS session.

The presentation illustrates the traffic engineering scenarios that we
encountered in our native IP network.

Traditional solutions to these scenarios are to apply MPLS technologies
within the whole network and using RSVP-TE or SR-TE to steer the traffic.
These technologies are valid but they either increase the network/device
complexity or we must using the different solutions to cope with the
intra-domain/inter-domain traffic engineering requirements.

 

Based on the above situation and the development of SDN concept/related
technologies, we want to let the SDN controller do the most complex
algorithm, let it instruct the devices for the optimal action, thus to
alleviate the burden of the underlay network devices, reduce the complexity
of synchronous signaling between them.

 

The key idea of the draft PCE in Native IP network is to let the PCE/SDN
controller instructs the devices on the optimal path via PCEP and keep the
default path calculated by the normal IGP/BGP protocol. We think such
solution has more network controllability in global view and thus easy to
accomplish the complex TE requirements in one unified solution.

 

We are also eager to hear more opinions or suggestions on this topic to
solve the problem that we encountered.

 

 

Best Regards.

 

Aijun Wang

Network R&D and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

 

发件人: Teas [mailto:teas-bounces@ietf.org] 代表 Aijun Wang
发送时间: 2017年6月30日 14:33
收件人: 'TEAS WG'
主题: [Teas] CCDR scenarios, simulation and suggestions

 

Hi,All:

 

We have uploaded the draft about CCDR scenarios, simulation and suggestions
at https://tools.ietf.org/html/draft-wang-teas-ccdr-00. 

Below is the brief introduction to it, wish to hear more valuable comments
on it. We will also prepare to introduce it at the coming IETF meeting in
Prague.

 

 

Abstract

 

   This document describes the scenarios, simulation and suggestions

   for the "Centrally Control Dynamic Routing (CCDR)" architecture,

   which integrates the merit of traditional distributed protocols

   (IGP/BGP), and the power of centrally control technologies (PCE/SDN)

   to provide one feasible traffic engineering solution in various

   complex scenarios for the service provider.

 

   Traditional MPLS-TE solution is mainly used in static network

   planning scenario and is difficult to meet the QoS assurance

   requirements in real-time traffic network. With the emerge of SDN

   concept and related technologies, it is possible to simplify the

   complexity of distributed control protocol, utilize the global view

   of network condition, give more efficient solution for traffic

   engineering in various complex scenarios.

 

 

Best Regards.

 

Aijun Wang

Network R&D and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.