Hey Robert,
Frankly, the more people look at an idea, the better. 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] <mailto:[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] <mailto:[email protected]> > On Behalf Of Robert Raszuk Sent: 27 September 2019 00:07 To: RTGWG <[email protected] <mailto:[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
