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
