Re: [Teas] IP Traffic Engineering

Robert Raszuk <robert@raszuk.net> Fri, 27 September 2019 15:35 UTC

Return-Path: <robert@raszuk.net>
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 676071208D3 for <teas@ietfa.amsl.com>; Fri, 27 Sep 2019 08:35:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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, HTTPS_HTTP_MISMATCH=0.1, 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 bsA1-43Ty1ZG for <teas@ietfa.amsl.com>; Fri, 27 Sep 2019 08:35:54 -0700 (PDT)
Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) (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 89CDE1208D7 for <teas@ietf.org>; Fri, 27 Sep 2019 08:35:54 -0700 (PDT)
Received: by mail-qk1-x743.google.com with SMTP id f16so2290009qkl.9 for <teas@ietf.org>; Fri, 27 Sep 2019 08:35:54 -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=uGe03EduAyJtox9KMUYCfV9rs9qsm3b48ZrWlvlPgaA=; b=Aom9Q6yTkx+jvFw3cqE+f4l7LfE88nXJu1JO2s3WLGhzcFzDeBxdMXZttGym5H1fQE dXxv2kRz9Ei+07BJbP4v4CQp7mVXG7ckg54SAs1dnZ/F9CpFMK2i5PelutFiAKn0NspC q3KsBImPGbqYeNexsnuzNnQvA2y3wEyXmuRqE6vFboB4kXHrtCTBVqO1OTSgkTww+Wei t56lPEJ4FOz0RaXU9ARb9A1SbpQXtAXO1IBGwvUfPPNn+RPFi3eeaNcl7dzdDO49OFJC M/IbIPPeifbAhmULwJ2C0ybnaclp/Mzme7/uUERJp1OFel3O2tHz69newfZf40zNrmsA UjHg==
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=uGe03EduAyJtox9KMUYCfV9rs9qsm3b48ZrWlvlPgaA=; b=MsTlJvjiI89FnaLCoSK1z3RLa5H4WGLEe4N/QOSRUCfbzzsaKLjJxaqM0eBi8KAOAW 2tDHiGsQCW6rh18Y54n9PG6VD4Y7CkxYl0oNeWAA6DwwvJuMaS3/bedR3MJW2UTrtWtg ON13qSloZ5q2l4KThCtVF7huwrwPvdcbIiPHFx3bfNNNahkmHzFEfg/Gy85ycQ3yEdG3 rqiPvKQVyzp6aZNsjJp/B6i6wnDzIsTAq4ZFG9J5PBKGwl8ApvLoRkv6eAZ1PNpyDA40 uoAfdtW2Lb2HCtpU4dZ0jdc4H3SGsM8OG2+01PlzRKaMwKav5iK+lsVjC6BzqLUtI1wn XSXQ==
X-Gm-Message-State: APjAAAWmf6dBoIBKwAybBfc83UKz5vNohhhipq2Y2Xy4943ehyNllKwX 7Cgcj8AwjQmbFf7J785Bop69HUoN7Xtz5w2N4WdebA==
X-Google-Smtp-Source: APXvYqwH3G2FhLQRW2rp8SQLQ7kB140E9XWchirPHhYX8bXr8rWisSmMKQCq1V9lc1mXX0gEkf2QwpFd/+hGcSRvKw0=
X-Received: by 2002:a37:a7c5:: with SMTP id q188mr4954607qke.445.1569598553319; Fri, 27 Sep 2019 08:35:53 -0700 (PDT)
MIME-Version: 1.0
References: <156953754350.31990.16627132446644830194@ietfa.amsl.com> <CAOj+MMEEn9uGH-qjapYw2guxnipcYE0u-3PH6wWPECiCQDhXiQ@mail.gmail.com> <01cd01d57502$81302c60$83908520$@olddog.co.uk> <CAOj+MMEMrCkPwP7M0QJqxMm90m3a+iMsN9b_dDAWA8UKx6_zzg@mail.gmail.com> <001901d5751e$679cb6d0$36d62470$@olddog.co.uk> <CAOj+MMHkG4M5=Ud+RJ0p7oHUjoj9Zi8F4iRhmvbgfsPh35mz3w@mail.gmail.com> <F64C10EAA68C8044B33656FA214632C8A3A4BE1A@MISOUT7MSGUSRDE.ITServices.sbc.com>
In-Reply-To: <F64C10EAA68C8044B33656FA214632C8A3A4BE1A@MISOUT7MSGUSRDE.ITServices.sbc.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 27 Sep 2019 17:35:38 +0200
Message-ID: <CAOj+MMHaO1xCBaKvRsAL5mDNNTtwUvgVsYPKD2d=SHDx3n+Atw@mail.gmail.com>
To: "BRUNGARD, DEBORAH A" <db3546@att.com>
Cc: Adrian Farrel <adrian@olddog.co.uk>, "teas@ietf.org" <teas@ietf.org>, RTGWG <rtgwg@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000036021905938aa46d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/Ud1tgwY39uOPxonAdtZK4R-ntF4>
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 <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Sep 2019 15:36:00 -0000

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 <db3546@att.com> 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 <teas-bounces@ietf.org> *On Behalf Of * Robert Raszuk
> *Sent:* Friday, September 27, 2019 6:50 AM
> *To:* Adrian Farrel <adrian@olddog.co.uk>
> *Cc:* Lou Berger <lberger@labn.net>; teas@ietf.org; RTGWG <rtgwg@ietf.org>
> *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 <robert@raszuk.net>
> *Sent:* 27 September 2019 11:07
> *To:* Adrian Farrel <adrian@olddog.co.uk>; Lou Berger <lberger@labn.net>
> *Cc:* RTGWG <rtgwg@ietf.org>; 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 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 <adrian@olddog.co.uk> 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 <rtgwg-bounces@ietf.org> *On Behalf Of *Robert Raszuk
> *Sent:* 27 September 2019 00:07
> *To:* RTGWG <rtgwg@ietf.org>
> *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
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
>