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 9D0DD1209A9 for ; Fri, 27 Sep 2019 15:52:51 -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 HRXy0wEZ2OTc for ; Fri, 27 Sep 2019 15:52:48 -0700 (PDT) Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) (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 CF23812080D for ; Fri, 27 Sep 2019 15:52:47 -0700 (PDT) Received: by mail-qt1-x843.google.com with SMTP id u40so9278880qth.11 for ; Fri, 27 Sep 2019 15:52:47 -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=683Lo3CJCKUbEwKXJWLEhWIDIEFWc4du2Yo3oLPlOnY=; b=Spamcr9WkMWC74qkXFjzZV1GFxdG5AMg2YDlTAWvv8Zk3KRQACMnweVShYZ5tOnTSI xDmYQZ1XYO0/LEf9V0+IJ+QKrG2j+m5xlQvoD268NeErErpJSUv46xdZljob8R3fFxly NUxx9fp/q17xldaimiSO5J5iLaDlzFM0FtGeqIZiVXkhLzHiAYTOGZxGKzG5m8QbA61X bPjmX47rZNm/QMb+QaeeYP/3BW8VxT2dwBureoIkwreLOyeKrLu8amFRKSqz0SPonFiA tls6vHMnJZa+jIGyj2rxMyzty+k2q+55oA7uvlu86TsggGsnsMx5wUjZlsLYjMuFUVWV V0mA== 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=683Lo3CJCKUbEwKXJWLEhWIDIEFWc4du2Yo3oLPlOnY=; b=sC/KBNo64QnjAQT3SIGWvz348r9DustmHEBFeuiY4Kj+Sbr9pcr0RbCagXgP+6PErP YRuBfuN8g7SYQtf7H5i3wy5OTW+EYid7iKSQN45nM2RDeMV2wHmLfHqiL5jpuFkhhlJC eLcP8eMDlvNaOWFF2MmpLNMowSmVo+5Smqei4iZ3bpKtorjVaaogak1kp4Ce+dFGYMjp NOznASDN+WJbynByAU86xx7xT5W+hVIvDw+dMRaGMhML0RkHFtyJNI1uRPKptw8oGwe2 X2RG0lmJXMhFoMcjrI1lQERC5J8ck0l9LTuoh9Hvt82NF699Bwzhs1DTizc+NOxnUVKr u0NQ== X-Gm-Message-State: APjAAAWvPa9gowpNOQ7AJEj3+7KlUucqw/0C1PXNzzJH3uz2YwwzpEPp pcY5CkpLhGYi5kpq+99HHocjXmivtqxV3KY7NBhREw== X-Google-Smtp-Source: APXvYqy90K2kBun99V8iuhl4RQpAHLOfPi+hwfp6CuMykfhUvVFYanhpdUd/YD4J2VDqWqdAHE+PTFTFI1Qj29WZkyo= X-Received: by 2002:a0c:9082:: with SMTP id p2mr10385074qvp.197.1569624766625; Fri, 27 Sep 2019 15:52:46 -0700 (PDT) MIME-Version: 1.0 References: <156953754350.31990.16627132446644830194@ietfa.amsl.com> In-Reply-To: From: Robert Raszuk Date: Sat, 28 Sep 2019 00:52:38 +0200 Message-ID: To: Linda Dunbar Cc: RTGWG , teas@ietf.org Content-Type: multipart/alternative; boundary="000000000000a54f8d059390be60" 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 22:52:52 -0000 --000000000000a54f8d059390be60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Linda, Thank you for reading the proposal. Organizationally per recommendation from AD and chairs we will be moving this work to TEAS hence I am cc-ing that group. As to your first question - P nodes are non participating nodes only running plain IP routing. Imagine those are ISPs between my anchor nodes - no PCE can talk to them. But this does not change the core of your question. You are essentially asking - can I do the same using MPLS swapping + IP encap on SE nodes. Well technically you can - but the main motivation of this proposal is to minimize per packet overhead. And if you can simply do IP lookup why to throw away peeling the packet with nice bits which can contain more then needed information and get to next encapsulated here MPLS stack ? Even if you look at processing chain of operations many more cycles in the data pipeline is needed to strip the header, process lookup on mpls label then apply new mapping then match new mapping to another encapsulation IP header, apply new IP header etc ... I do not see much rationale doing such maneuvers. I think while MPLS as service demux is great idea I would not invest too much in any solutions which relay on using MPLS as a transport. For section 7 the answer is it depends. Some functions local to the midpoints for sure can be triggered by control plane. However some functions may be common to all packets (for example let's timestamp the packet at each TE midpoint) so it makes sense to have an architecture which allows to embed such function. On a similar note VPN demux values known on VPN ingress should be applied there and not carried in TE control plane if for nothing else then for avoiding TE control plane unnecessary grow. Many thx for asking, Robert. On Sat, Sep 28, 2019 at 12:22 AM Linda Dunbar wrote: > Robert, > > > > Interesting proposal, especially on the Active Path Probing allowing > minimum path quality metrics to be specified for data plane. > > > > Can I use MPLS over IP solution + PCE to achieve what you show in Figure = 1? > > e.g. for T2 Path: PCE can instruct the proper switching on P2 for the > path, and instruct the PE1 for the proper MPLS label, then the PE1 > encapsulate the MPLS packet in IP packet (which can traverse the plain IP > network to P2); P2 does the MPLS label swapping and switching instructed = by > the controller, and encapsulate the MPLS packet in the new label assigned > by P2 in another IP packet to PE2. > > > > For Section 7 Network Programming, you propose adding the information > about the selected function to packet. If intermediate nodes can get > instruction from the controller, why not letting the controller inform th= e > list of functions for the packets at the specific nodes instead carried b= y > the packets? > > > > Linda Dunbar > > > > *From:* rtgwg *On Behalf Of * Robert Raszuk > *Sent:* Thursday, September 26, 2019 6:07 PM > *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 > > > --000000000000a54f8d059390be60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Linda,

Thank you for reading the pro= posal. Organizationally per recommendation from AD and chairs we will be mo= ving this work to TEAS hence I am cc-ing that group.=C2=A0

As to your first=C2=A0question - P nodes are non participating nod= es only running plain IP routing. Imagine those are ISPs between my anchor = nodes - no PCE can talk to them. But this does not change the core of your = question.=C2=A0

You are essentially asking - can I= do the same using MPLS swapping=C2=A0+ IP encap on SE nodes. Well technica= lly you can - but the main motivation of this proposal is to minimize per p= acket overhead. And if you can simply do IP lookup why to throw away peelin= g the packet with nice bits which can contain more then needed information = and get to next encapsulated here MPLS stack ?=C2=A0

Even if you look at processing chain of operations many more cycles in t= he data pipeline is needed to strip the header, process lookup on mpls labe= l then apply new mapping then match new mapping to another encapsulation IP= header, apply new IP header etc ... I do not see much rationale doing such= maneuvers. I think while MPLS as service demux is great idea I would not i= nvest too much in any solutions which relay on using MPLS as a transport.= =C2=A0

For section 7 the answer is it depends. Som= e functions local to the midpoints for sure can be triggered by control pla= ne. However some functions may be common to all packets (for example let= 9;s timestamp the packet at each TE midpoint) so it makes sense to have an = architecture which allows to embed such function. On a similar note VPN dem= ux values known on VPN ingress should be applied there and not carried in T= E control plane if for nothing else then for avoiding TE control plane unne= cessary grow.=C2=A0

Many thx for asking,
Robert.


On Sat, Sep 28, 2019 at 12:22 AM Linda Dunbar= <linda.dunbar@futurewei.c= om> wrote:

Robert,

=C2=A0

Interesting proposal, especially on the Active Path = Probing allowing minimum path quality metrics to be specified for data plan= e.

=C2=A0

Can I use MPLS over IP solution + PCE to achieve wha= t you show in Figure 1?

e.g. for T2 Path: PCE can instruct the proper switch= ing on P2 for the path, and instruct the PE1 for the proper MPLS label, the= n the PE1 encapsulate the MPLS packet in IP packet (which can traverse the = plain IP network to P2); P2 does the MPLS label swapping and switching instructed by the controller, and encaps= ulate the MPLS packet in the new label assigned by P2 in another IP packet = to PE2.

=C2=A0

For Section 7 Network Programming, you propose addin= g the information about the selected function to packet. If intermediate no= des can get instruction from the controller, why not letting the controller= inform the list of functions for the packets at the specific nodes instead carried by the packets? <= u>

=C2=A0

Linda Dunbar

=C2=A0

From: rtgwg <rtgwg-bounces@ietf.org> On Behalf = Of Robert Raszuk
Sent: Thursday, September 26, 2019 6:07 PM
To: RTGWG <rt= gwg@ietf.org>
Subject: IP Traffic Engineering

=C2=A0

Dear=C2=A0RTGWG,

=C2=A0

I just submitted a document where I present new pers= pective on traffic engineering for IP networks. As the scope of the new arc= hitecture and deployment target does not fit any other working group I deci= ded 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-Drafts director= ies.


=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 Network Programming
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Robe= rt Raszuk
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ras= zuk-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 plane based IP Traffic Engin= eering
=C2=A0 =C2=A0Architecture where path information is kept in the control pla= ne by
=C2=A0 =C2=A0selected nodes instead of being inserted into each packet on i= ngress
=C2=A0 =C2=A0of an administrative domain.=C2=A0 The described proposal is a= lso fully
=C2=A0 =C2=A0compatible with the concept of network programming.

=C2=A0 =C2=A0It is positioned as a complimentary technique to native SRv6 a= nd 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 exceeding MTU = or more
=C2=A0 =C2=A0strict simplicity requirements typically seen in number of ent= erprise
=C2=A0 =C2=A0networks.=C2=A0 The proposed solution is applicable to both IP= v4 or IPv6
=C2=A0 =C2=A0based networks.

=C2=A0 =C2=A0As an additional added value, detection of end to end path liv= eness
=C2=A0 =C2=A0as well as dynamic path selection based on real time path qual= ity is
=C2=A0 =C2=A0integrated 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

--000000000000a54f8d059390be60--