Re: [Teas] IP Traffic Engineering

[Robert Raszuk <[e-mail]>]

Hello Aijun,

Thank you for sharing your work in this space.

I need to carefully read your documents as I was not aware of their
existence. The the last draft you shared a pointer to (PCE in Native IP
Network) I actually see few similarities to my previous idea described few
years ago by Keyur and myself in
https://tools.ietf.org/html/draft-patel-raszuk-bgp-vector-routing-07

We were not sure if there is need for such model as clearly such design is
destination only and is limited to single administration domain.

The new document's (IP Traffic Engineering Architecture with Network
Programming) has much broader applicability target.

Many thanks for sharing and your comments,
Robert


On Sat, Sep 28, 2019 at 1:00 AM Aijun Wang <[e-mail]>
wrote:

> 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/
> <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 <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]> *On Behalf Of * Robert Raszuk
>> *Sent:* Friday, September 27, 2019 6:50 AM
>> *To:* Adrian Farrel <[e-mail]>
>> *Cc:* Lou Berger <[e-mail]>; [e-mail]; RTGWG <[e-mail]
>> >
>> *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 <[e-mail]>
>> *Sent:* 27 September 2019 11:07
>> *To:* Adrian Farrel <[e-mail]>; Lou Berger <[e-mail]>
>> *Cc:* RTGWG <[e-mail]>; [e-mail]
>> *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 <[e-mail]>
>> 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 <[e-mail]> *On Behalf Of *Robert Raszuk
>> *Sent:* 27 September 2019 00:07
>> *To:* RTGWG <[e-mail]>
>> *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/
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Draszuk-2Drtgwg-2Dip-2Dte-2Dnp_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=lad5nqudPn8cjWjXN8H_1-iSEuM3ejnmrKjVaDDFHvY&s=C1y2163-wALgzLiZn9ncS7yZteGjbovwTv9s6IoF6G8&e=>
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-raszuk-rtgwg-ip-te-np-00
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Draszuk-2Drtgwg-2Dip-2Dte-2Dnp-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=lad5nqudPn8cjWjXN8H_1-iSEuM3ejnmrKjVaDDFHvY&s=G4drAa3ssiNyaS60hzNSfO1IszxqLRU1JQ7lsZAw4NU&e=>
>> https://datatracker.ietf.org/doc/html/draft-raszuk-rtgwg-ip-te-np-00
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Draszuk-2Drtgwg-2Dip-2Dte-2Dnp-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=lad5nqudPn8cjWjXN8H_1-iSEuM3ejnmrKjVaDDFHvY&s=vwIMACbKg4d5xXOhr9zr4qA4jrmj223fdZrAs02mFCs&e=>
>>
>> _______________________________________________
>> rtgwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtgwg
>>
> _______________________________________________
> rtgwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtgwg
>
>