Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18822120805 for ; Fri, 27 Sep 2019 03:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdYCs_jc0Rqn for ; Fri, 27 Sep 2019 03:49:52 -0700 (PDT) Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F17C6120800 for ; Fri, 27 Sep 2019 03:49:51 -0700 (PDT) Received: by mail-qk1-x744.google.com with SMTP id z67so1491776qkb.12 for ; Fri, 27 Sep 2019 03:49:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+ORiFVxWxthM7HpCr8b814lbNIUpRUbrlBNvvYcwMyk=; b=N1UnxBS6qjJSpLXYNLw6M3+uPPT21DQrloHXUSUbbW1QQiUHVx78EHQGtdUn6A6/Jm R9gqQVsyuBgx5FTg3tcCMh9XcXYMa5zlbEFYFDXv+RjL0+fYXdOjf7nrSM0hgzsKizu2 o1kqFPvgtyD/p+rAuC0V+ie2VO90bm56u6hHD9Dp/v/s3mcd2cz0Klp+ivHJsYx91o1K lZm3biI3mXdGLQmH6Fq8Of0Prz9kddorPP4doZczpigtT6z7bcE954jKqE2k9cb3haKM yrSZXsVCrvgHv1Si0oj105nNWKQYz0kayeZE1qDxy5ELazlz79xYv0OcY3A+xEPdIidE zUag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+ORiFVxWxthM7HpCr8b814lbNIUpRUbrlBNvvYcwMyk=; b=ibk6y5wGa6UutUAC26g3YZn1DSEyRBYi9ux+wdH/hAxOOlgFRrrAdMiGr59YF/Wfxi pVGK6eoRfEQP0xV5NEGe+BVT24PHkAaqE6HhBeyfHmWinsAyXS6PcXrWP5P2FeAqxhPb gQzucspi9D4QzeGn2OYPAoSqi1NJKlDv59OluThjcXswo0mAPKkSBqCgiRrwYj+HWXxi 8ZGQGZPH16cGNMYpo0mpBI9RDa5pbjh/5I7RT8fwEiSy3TeElEPHGPdNG2STTeL4+je9 R5nCjkG/yTSWdEv8IrTGKcucrc899KoYio7wce3k9q4GgU4HSBSvZDB8vIuL3p4SdeLN JNDA== X-Gm-Message-State: APjAAAWibVVdV5IT+YbkV5ksjvbtAD0qgKZGLn1dKj6RPougdDMX0VDm U7yCzKBquG2u+t7/MALCbpnN5Ze61V+vAbMCZATUfA== X-Google-Smtp-Source: APXvYqwJDFpcvS9U7L04ZUtJuNokHNnmojlL3rC9D0kPDLLXzXerJqY0OFlp6SwCSke0PGssfIHKFgdL0A01sn2IfRQ= X-Received: by 2002:a37:8547:: with SMTP id h68mr3668252qkd.219.1569581390942; Fri, 27 Sep 2019 03:49:50 -0700 (PDT) MIME-Version: 1.0 References: <156953754350.31990.16627132446644830194@ietfa.amsl.com> <01cd01d57502$81302c60$83908520$@olddog.co.uk> <001901d5751e$679cb6d0$36d62470$@olddog.co.uk> In-Reply-To: <001901d5751e$679cb6d0$36d62470$@olddog.co.uk> From: Robert Raszuk Date: Fri, 27 Sep 2019 12:49:42 +0200 Message-ID: To: Adrian Farrel Cc: Lou Berger , RTGWG , teas@ietf.org Content-Type: multipart/alternative; boundary="00000000000040e8b1059386a59b" Archived-At: Subject: Re: [Teas] IP Traffic Engineering X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2019 10:49:56 -0000 --00000000000040e8b1059386a59b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=C5=8D :) And now you mention BESS .... Many thx, Robert. > It is only once we start to progress the work that we need to find a > =E2=80=98home=E2=80=99 so that we only have to follow one list to have a = discussion. > > > > Wrt the TEAS charter: mia culpa. But don=E2=80=99t read it as =E2=80=9CMU= ST NOT coordinate > on other things=E2=80=9D only as =E2=80=9CMUST coordinate on at least thi= s thing=E2=80=9D. > > > > BTW There is some BESS work on communicating =E2=80=9Cpath and function= =E2=80=9D that is > aligned with a generic form of SFC. > > > > Cheers, > > Adrian > > > > *From:* Robert Raszuk > *Sent:* 27 September 2019 11:07 > *To:* Adrian Farrel ; Lou Berger > *Cc:* RTGWG ; teas@ietf.org > *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 propose= d > 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-segmen= t-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 wrote= : > > Hi Robert, > > > > It=E2=80=99s an interesting draft. > > > > Did you know there is a working group chartered to work on IP Traffic > Engineering Architecture? It=E2=80=99s TEAS. > > > > Thanks, > > Adrian > > > > *From:* rtgwg *On Behalf Of *Robert Raszuk > *Sent:* 27 September 2019 00:07 > *To:* RTGWG > *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 submi= t > 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 Networ= k > 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 > > --00000000000040e8b1059386a59b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 tes= t find a WG home for it.=C2=A0

In fact I am alread= y a bit shocked to get so many on list and off list mails so short after su= bmission. I was hoping I only contribute one little piece to big jigsaw TE+= NP puzzle but it sounds like I hit Bonsh=C5=8D :)

= And now you mention BESS ....=C2=A0

Many thx,
R= obert.

=C2=A0

<= p class=3D"MsoNormal">=C2=A0It is only once we start to= progress the work that we need to find a =E2=80=98home=E2=80=99 so that we= only have to follow one list to have a discussion.

=C2=A0

Wrt th= e TEAS charter: mia culpa. But don=E2=80=99t read it as =E2=80=9CMUST NOT c= oordinate on other things=E2=80=9D only as =E2=80=9CMUST coordinate on at l= east this thing=E2=80=9D.

=C2=A0

BTW There i= s some BESS work on communicating =E2=80=9Cpath and function=E2=80=9D that = is aligned with a generic form of SFC.

=C2=A0

Cheers,

Adrian

=C2=A0=

From: Robert Raszuk <robert@raszuk.net>
Sent: 27 September 2019 11= :07
To: Adrian Farrel <adrian@olddog.co.uk>; Lou Berger <lberger@labn.net>
Cc:= RTGWG <rtgwg@ie= tf.org>; teas@iet= f.org
Subject: Re: IP Traffic Engineering

=C2=A0

Hi Adrian=C2=A0and Lou,

<= u>=C2=A0

Many thx for your = suggestion.=C2=A0

=C2=A0

Reading charter of TEAS= it does seems like a good fit for the IP TE part. What is however not in t= he 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).=C2=A0

=C2=A0

I think I wi= ll not hurt anyone to submit it to TEAS. I guess we can keep -00 also in RT= GWG for now.=C2=A0

=C2=A0

I guess it will be up = to chairs and ADs of those two working groups to decide which one should &q= uot;own" this type of hybrid work.=C2=A0

<= p class=3D"MsoNormal">=C2=A0

Btw looking at TEAS charter I found a bit artificial scoped coordinati= on with IDR limited to BGP-LS.=C2=A0

=C2=A0

=C2=A0

In my specific case I do plan to= use other BGP extensions as possible alternatives to distribute the path+f= unction information around. But I am not defining any new extensions (only = reusing as is=C2=A0draft-ietf-idr-segment-routing-te-policy) so this= is not a stopper for me.=C2=A0

=C2=A0

Many thx,=

Robert.

=C2=A0

=C2=A0

On Fri, Sep 27, 2019 at 9:09 AM Adrian Farrel <adrian@olddog.co.uk> wrote:=

Hi= Robert,

=C2=A0

It=E2=80=99s an interesting draft.

=C2=A0

Did you= know there is a working group chartered to work on IP Traffic Engineering = Architecture? It=E2=80=99s TEAS.

= =C2=A0

Thanks,

Adrian

=C2=A0

From:= rtgwg <rtgwg-bounces@ietf.org> On Behalf Of Rob= ert Raszuk
Sent: 27 September 2019 00:07
To: RTGWG <= rtgwg@ietf.org><= br>Subject: IP Traffic Engineering

=C2=A0

Dea= r=C2=A0RTGWG,

=C2=A0<= /u>

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 o= ther working group I decided to submit it to RTGWG.=C2=A0

=

=C2=A0

Comments, opinions, contribution - very welcome !

=C2=A0

Kind regards,

Robert.=C2=A0

=C2=A0

- - -=C2=A0=


A New Internet-Draft is available from the on-line Internet-Draft= s directories.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0: IP Traffic Engineering Architecture with Netwo= rk Programming
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 : Robert Raszuk
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0= =C2=A0 =C2=A0 =C2=A0 : draft-raszuk-rtgwg-ip-te-np-00.txt
=C2=A0 =C2=A0= =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 22
=C2=A0= =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2019-= 09-26

Abstract:
=C2=A0 =C2=A0This document describes a control pl= ane based IP Traffic Engineering
=C2=A0 =C2=A0Architecture where path in= formation is kept in the control plane by
=C2=A0 =C2=A0selected nodes in= stead of being inserted into each packet on ingress
=C2=A0 =C2=A0of an a= dministrative domain.=C2=A0 The described proposal is also fully
=C2=A0 = =C2=A0compatible with the concept of network programming.

=C2=A0 =C2= =A0It is positioned as a complimentary technique to native SRv6 and can
= =C2=A0 =C2=A0be used when there are concerns with increased packet size due= to
=C2=A0 =C2=A0depth of SID stack, possible concerns regarding exceedi= ng MTU or more
=C2=A0 =C2=A0strict simplicity requirements typically see= n in number of enterprise
=C2=A0 =C2=A0networks.=C2=A0 The proposed solu= tion is applicable to both IPv4 or IPv6
=C2=A0 =C2=A0based networks.
=
=C2=A0 =C2=A0As an additional added value, detection of end to end path= liveness
=C2=A0 =C2=A0as well as dynamic path selection based on real t= ime path quality is
=C2=A0 =C2=A0integrated from day one in the design.<= br>

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:
h= ttps://tools.ietf.org/html/draft-raszuk-rtgwg-ip-te-np-00
https://datatracker.ietf.org/doc/html/draft-raszuk-rtgwg-ip-t= e-np-00

--00000000000040e8b1059386a59b--