Re: [Teas] IP Traffic Engineering
Aijun Wang <wangaijun@tsinghua.org.cn> Fri, 27 September 2019 23:00 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 D3D6F1207FF; Fri, 27 Sep 2019 16:00:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.797
X-Spam-Level:
X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 jhyRQVFiZ-FY; Fri, 27 Sep 2019 16:00:10 -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 E4ADA120071; Fri, 27 Sep 2019 16:00:09 -0700 (PDT)
Received: from [240.0.0.1] (unknown [3.9.186.152]) by m176115.mail.qiye.163.com (Hmail) with ESMTPA id 3A5516613F6; Sat, 28 Sep 2019 07:00:01 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-5C493BD1-395D-4028-B25A-E102C63EF005"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Sat, 28 Sep 2019 06:59:55 +0800
Message-Id: <844C3D4C-E74B-4D09-AACD-A0FBFABE5B1C@tsinghua.org.cn>
References: <CAOj+MMHaO1xCBaKvRsAL5mDNNTtwUvgVsYPKD2d=SHDx3n+Atw@mail.gmail.com>
Cc: "BRUNGARD, DEBORAH A" <db3546@att.com>, Adrian Farrel <adrian@olddog.co.uk>, "teas@ietf.org" <teas@ietf.org>, RTGWG <rtgwg@ietf.org>
In-Reply-To: <CAOj+MMHaO1xCBaKvRsAL5mDNNTtwUvgVsYPKD2d=SHDx3n+Atw@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: iPhone Mail (17A577)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZTlVKSkpCQkJCQ0NOTk5CSllXWShZQU pMS0tKN1dZLVlBSVdZCQ4XHghZQVk1NCk2OjckKS43PlkG
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Njo6Hjo6IjlOCQFDCyseLTIf TwtPCx9VSlVKTk1CTUlOSUtDSENMVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlIVUJVSkNNVUpOSVlXWQgBWUFISU5LSDcG
X-HM-Tid: 0a6d74f3da599373kuws3a5516613f6
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/C_bCcMT7eh9sUQrXsx2hMojQPpo>
Subject: Re: [Teas] IP Traffic Engineering
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
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, 27 Sep 2019 23:00:14 -0000
Hi, Robert: As Deborah mentioned, we have studied the TE requirements in Native IP network for some time. Besides the scenarios and simulation results that described in https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/ We also provided the solution draft in https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/ and the corresponding PCEP extension draft https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/ The above solutions can also accomplish the aims that you mentioned in your draft. I have also read your draft in general and will review it detail in following days. Anyway, I am glad to know that TE in Native IP requirements become more aware to more people. Aijun Wang China Telecom > On Sep 27, 2019, at 23:36, Robert Raszuk <robert@raszuk.net> wrote: > > > Hi Deborah, > > Thank you for assuring me of the TEAS perspective. As I mentioned to Adrian and Lou I am more then happy to redirect the draft to TEAS and can rename the title in no time. The only question is that would TEAS also have room to work on solution which goes beyond just path steering in IP networks but also takes on providing extra sauce on top which would be embedded functions and value add processing instructions to the combined architecture ? > > I do not see why not just trying to make sure there will not be need to split into different documents as it would rather be a bit tough. > > Many thx for great guidance ! > Robert. > > >> On Fri, Sep 27, 2019 at 5:25 PM BRUNGARD, DEBORAH A <db3546@att.com> wrote: >> Hi Robert, >> >> >> >> As Adrian says, charters are not written in stone, they can only reflect what was known at the time of writing. And there is a “re-charter” option😊 >> >> >> >> On TE for IP, TEAS has already started work (initiated by operators – really interesting that you also find this work of value for IP). The document was already IETF Last Called and is scheduled for next week’s telechat (if any last comments, please let me know): >> >> https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/ >> >> >> >> And TEAS has a solution document on-going. While the work is more focused on PCE, the use case is the same (above document link) as you say in your document: >> >> “Another category of global networking which can significantly benefit >> >> from standards based IP TE solution is unified model of path >> >> engineering for Software Defined Wide Area Networks (SDWANs). One of >> >> the basic operational principles in selected SDWANs is point to point >> >> underlay selection based on the applied SLA characteristics. Adding >> >> ability to traffic engineer such underlay flows allows to bypass >> >> under performing underlay default paths or congestion points >> >> occurring even few autonomous systems away.” >> >> >> >> On passing the “laugh test”, TEAS has already given it the go-ahead. As the shepherd writeup says, though, there was a low interest level. If you read some of the other AD reviews coming in for the telechat, they are questioning it too. Your draft definitely supports there are more operators seeing the need. >> >> TEAS is the home for generic TE architecture work on new capabilities, then the group works with other protocol owning groups for extensions needed. This is why the current IP TE work is on-going in TEAS, then when PCE extensions are identified, it will work with PCE. Your draft is very timely for being able to develop a generic architecture. >> >> >> >> You are not homeless, you have a home😊 >> >> Deborah >> >> >> >> >> >> From: Teas <teas-bounces@ietf.org> On Behalf Of Robert Raszuk >> Sent: Friday, September 27, 2019 6:50 AM >> To: Adrian Farrel <adrian@olddog.co.uk> >> Cc: Lou Berger <lberger@labn.net>; teas@ietf.org; RTGWG <rtgwg@ietf.org> >> Subject: Re: [Teas] IP Traffic Engineering >> >> >> >> Hey Adrian, >> >> >> >> Frankly, the more people look at an idea, the better. >> >> >> >> Of course .. this is IMHO the biggest IETF value. To share idea and get feedback then if passes laugh test find a WG home for it. >> >> >> >> In fact I am already a bit shocked to get so many on list and off list mails so short after submission. I was hoping I only contribute one little piece to big jigsaw TE+NP puzzle but it sounds like I hit Bonshō :) >> >> >> >> And now you mention BESS .... >> >> >> >> Many thx, >> Robert. >> >> >> >> >> >> It is only once we start to progress the work that we need to find a ‘home’ so that we only have to follow one list to have a discussion. >> >> >> >> Wrt the TEAS charter: mia culpa.. But don’t read it as “MUST NOT coordinate on other things” only as “MUST coordinate on at least this thing”. >> >> >> >> BTW There is some BESS work on communicating “path and function” that is aligned with a generic form of SFC. >> >> >> >> Cheers, >> >> Adrian >> >> >> >> From: Robert Raszuk <robert@raszuk.net> >> Sent: 27 September 2019 11:07 >> To: Adrian Farrel <adrian@olddog.co.uk>; Lou Berger <lberger@labn.net> >> Cc: RTGWG <rtgwg@ietf.org>; teas@ietf.org >> Subject: Re: IP Traffic Engineering >> >> >> >> Hi Adrian and Lou, >> >> >> >> Many thx for your suggestion. >> >> >> >> Reading charter of TEAS it does seems like a good fit for the IP TE part. What is however not in the TEAS charter is concept of network functions which is the second part of the solution natively embedded in the proposed architecture from day one (IP TE+NP part). >> >> >> >> I think I will not hurt anyone to submit it to TEAS. I guess we can keep -00 also in RTGWG for now. >> >> >> >> I guess it will be up to chairs and ADs of those two working groups to decide which one should "own" this type of hybrid work. >> >> >> >> Btw looking at TEAS charter I found a bit artificial scoped coordination with IDR limited to BGP-LS. >> >> >> >> "- With the IDR WG on the use of BGP-LS in TE environments." >> >> >> >> In my specific case I do plan to use other BGP extensions as possible alternatives to distribute the path+function information around. But I am not defining any new extensions (only reusing as is draft-ietf-idr-segment-routing-te-policy) so this is not a stopper for me. >> >> >> >> Many thx, >> >> Robert. >> >> >> >> >> >> On Fri, Sep 27, 2019 at 9:09 AM Adrian Farrel <adrian@olddog.co.uk> wrote: >> >> Hi Robert, >> >> >> >> It’s an interesting draft. >> >> >> >> Did you know there is a working group chartered to work on IP Traffic Engineering Architecture? It’s TEAS. >> >> >> >> Thanks, >> >> Adrian >> >> >> >> From: rtgwg <rtgwg-bounces@ietf.org> On Behalf Of Robert Raszuk >> Sent: 27 September 2019 00:07 >> To: RTGWG <rtgwg@ietf.org> >> Subject: IP Traffic Engineering >> >> >> >> Dear RTGWG, >> >> >> >> I just submitted a document where I present new perspective on traffic engineering for IP networks. As the scope of the new architecture and deployment target does not fit any other working group I decided to submit it to RTGWG. >> >> >> >> Comments, opinions, contribution - very welcome ! >> >> >> >> Kind regards, >> >> Robert. >> >> >> >> - - - >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> >> Title : IP Traffic Engineering Architecture with Network Programming >> Author : Robert Raszuk >> Filename : draft-raszuk-rtgwg-ip-te-np-00.txt >> Pages : 22 >> Date : 2019-09-26 >> >> Abstract: >> This document describes a control plane based IP Traffic Engineering >> Architecture where path information is kept in the control plane by >> selected nodes instead of being inserted into each packet on ingress >> of an administrative domain. The described proposal is also fully >> compatible with the concept of network programming. >> >> It is positioned as a complimentary technique to native SRv6 and can >> be used when there are concerns with increased packet size due to >> depth of SID stack, possible concerns regarding exceeding MTU or more >> strict simplicity requirements typically seen in number of enterprise >> networks. The proposed solution is applicable to both IPv4 or IPv6 >> based networks. >> >> As an additional added value, detection of end to end path liveness >> as well as dynamic path selection based on real time path quality is >> integrated from day one in the design. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-raszuk-rtgwg-ip-te-np/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-raszuk-rtgwg-ip-te-np-00 >> https://datatracker.ietf.org/doc/html/draft-raszuk-rtgwg-ip-te-np-00 >> >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg >
- Re: [Teas] IP Traffic Engineering Robert Raszuk
- Re: [Teas] IP Traffic Engineering Adrian Farrel
- Re: [Teas] IP Traffic Engineering Robert Raszuk
- Re: [Teas] IP Traffic Engineering BRUNGARD, DEBORAH A
- Re: [Teas] IP Traffic Engineering Robert Raszuk
- Re: [Teas] IP Traffic Engineering Robert Raszuk
- Re: [Teas] IP Traffic Engineering Aijun Wang
- Re: [Teas] IP Traffic Engineering Robert Raszuk
- Re: [Teas] IP Traffic Engineering Linda Dunbar
- Re: [Teas] IP Traffic Engineering Robert Raszuk
- Re: [Teas] IP Traffic Engineering Robert Raszuk