Re: IP Traffic Engineering

[Robert Raszuk <[e-mail]>]

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/
>
> 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
>
>