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 <[email protected]> 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 <[email protected]> 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 <[email protected]> On Behalf Of Robert Raszuk >> Sent: Friday, September 27, 2019 6:50 AM >> To: Adrian Farrel <[email protected]> >> Cc: Lou Berger <[email protected]>; [email protected]; RTGWG <[email protected]> >> 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 <[email protected]> >> Sent: 27 September 2019 11:07 >> To: Adrian Farrel <[email protected]>; Lou Berger <[email protected]> >> Cc: RTGWG <[email protected]>; [email protected] >> 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 <[email protected]> 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 <[email protected]> On Behalf Of Robert Raszuk >> Sent: 27 September 2019 00:07 >> To: RTGWG <[email protected]> >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/rtgwg > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
