Re: [Teas] IP Traffic Engineering

"BRUNGARD, DEBORAH A" <db3546@att.com> Fri, 27 September 2019 15:25 UTC

Return-Path: <db3546@att.com>
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 972CD120893; Fri, 27 Sep 2019 08:25:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.498
X-Spam-Level:
X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 M4Gi71dr_FGl; Fri, 27 Sep 2019 08:25:41 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72B7412088C; Fri, 27 Sep 2019 08:25:41 -0700 (PDT)
Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x8RF7NPD004178; Fri, 27 Sep 2019 11:25:38 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0083689.ppops.net-00191d01. with ESMTP id 2v9kfgb9pu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 27 Sep 2019 11:25:15 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x8RFNAIh010716; Fri, 27 Sep 2019 11:23:11 -0400
Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [135.66.87.52]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x8RFN1hG010395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Sep 2019 11:23:04 -0400
Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [127.0.0.1]) by zlp27125.vci.att.com (Service) with ESMTP id E957916A3F0; Fri, 27 Sep 2019 15:23:00 +0000 (GMT)
Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (unknown [130.9.129.149]) by zlp27125.vci.att.com (Service) with ESMTPS id CD13516A3EB; Fri, 27 Sep 2019 15:23:00 +0000 (GMT)
Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.17]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0468.000; Fri, 27 Sep 2019 11:23:00 -0400
From: "BRUNGARD, DEBORAH A" <db3546@att.com>
To: Robert Raszuk <robert@raszuk.net>, Adrian Farrel <adrian@olddog.co.uk>
CC: Lou Berger <lberger@labn.net>, "teas@ietf.org" <teas@ietf.org>, RTGWG <rtgwg@ietf.org>
Thread-Topic: [Teas] IP Traffic Engineering
Thread-Index: AQHVdRt1cNtbGAJMNEaN4dWwLba31ac/laMAgAAFvQCAAACkkA==
Date: Fri, 27 Sep 2019 15:22:59 +0000
Message-ID: <F64C10EAA68C8044B33656FA214632C8A3A4BE1A@MISOUT7MSGUSRDE.ITServices.sbc.com>
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>
In-Reply-To: <CAOj+MMHkG4M5=Ud+RJ0p7oHUjoj9Zi8F4iRhmvbgfsPh35mz3w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.70.199.82]
Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C8A3A4BE1AMISOUT7MSGUSRDE_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-27_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909270141
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/uyt-vOcWERkGo32EOoYa20sxP28>
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:25:47 -0000

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<mailto:robert@raszuk.net>>
Sent: 27 September 2019 11:07
To: Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>; Lou Berger <lberger@labn.net<mailto:lberger@labn.net>>
Cc: RTGWG <rtgwg@ietf.org<mailto:rtgwg@ietf.org>>; teas@ietf.org<mailto: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<mailto: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<mailto:rtgwg-bounces@ietf.org>> On Behalf Of Robert Raszuk
Sent: 27 September 2019 00:07
To: RTGWG <rtgwg@ietf.org<mailto: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=>