Subject: IP Traffic Engineering

From: Robert Raszuk <[email-masked]>
Date: Fri, 27 Sep 2019 01:06:44 +0200

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

---

From: Lou Berger <[email-masked]>
Date: Thu, 26 Sep 2019 20:10:10 -0400

I suspect this is in the scope of the TE Architecture ... (TEAS) WG...

On 9/26/2019 7:06 PM, Robert Raszuk wrote:
> deployment target does not fit any other working group I decided to 
> submit it to RTGWG.
>
>         Title           : IP Traffic Engineering Architecture with 
> Network Programming
>         Author          : Robert Raszuk
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 26 Sep 2019 20:21:26 -0400

Or maybe PCE WG

Sent from my iPhone

> On Sep 26, 2019, at 8:10 PM, Lou Berger <[email-masked]> wrote:
> 
>> 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. 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> 
>> 
>>         Title           : IP Traffic Engineering Architecture with Network Programming
>>         Author          : Robert Raszuk

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 27 Sep 2019 08:09:16 +0100

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 <[email-masked]> On Behalf Of Robert Raszuk
Sent: 27 September 2019 00:07
To: RTGWG <[email-masked]>
Subject: IP Traffic Engineering

Dear RTGWG,

Kind regards,

Robert. 

- - - 

Abstract:

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 27 Sep 2019 12:07:21 +0200

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 <[email-masked]> wrote:

> *From:* rtgwg <[email-masked]> *On Behalf Of *Robert Raszuk
> *Sent:* 27 September 2019 00:07
> *To:* RTGWG <[email-masked]>
> *Subject:* IP Traffic Engineering
>
>
>
> Dear RTGWG,
>
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 27 Sep 2019 11:29:10 +0100

Hey Robert,

Frankly, the more people look at an idea, the better.

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 <[email-masked]> 
Sent: 27 September 2019 11:07
To: Adrian Farrel <[email-masked]>; Lou Berger <[email-masked]>
Cc: RTGWG <[email-masked]>; [email-masked]
Subject: Re: IP Traffic Engineering

Hi Adrian and Lou,

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. 

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 <[email-masked] <mailto:[email-masked]> > wrote:

Hi Robert,

Thanks,

Adrian

From: rtgwg <[email-masked] <mailto:[email-masked]> > On Behalf Of Robert Raszuk
Sent: 27 September 2019 00:07
To: RTGWG <[email-masked] <mailto:[email-masked]> >
Subject: IP Traffic Engineering

Dear RTGWG,

Kind regards,

Robert. 

- - - 

Abstract:

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 27 Sep 2019 12:49:42 +0200

Hey Adrian,

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”.
>
>
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* 27 September 2019 11:07
> *To:* Adrian Farrel <[email-masked]>; Lou Berger <[email-masked]>
> *Cc:* RTGWG <[email-masked]>; [email-masked]
> *Subject:* Re: IP Traffic Engineering
>
>
>
> Hi Adrian and Lou,
>
>
>
> not defining any new extensions (only reusing as is draft-ietf-idr-segment-routing-te-policy)

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Fri, 27 Sep 2019 15:22:59 +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 <[email-masked]> On Behalf Of Robert Raszuk
Sent: Friday, September 27, 2019 6:50 AM
To: Adrian Farrel <[email-masked]>
Cc: Lou Berger <[email-masked]>; [email-masked]; RTGWG <[email-masked]>
Subject: Re: [Teas] IP Traffic Engineering

Hey Adrian,

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ō :)

Many thx,
Robert.

Cheers,
Adrian

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: 27 September 2019 11:07
To: Adrian Farrel <[email-masked]<mailto:[email-masked]>>; Lou Berger <[email-masked]<mailto:[email-masked]>>
Cc: RTGWG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: IP Traffic Engineering

Hi Adrian and Lou,

Many thx,
Robert.

On Fri, Sep 27, 2019 at 9:09 AM Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Thanks,
Adrian

From: rtgwg <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk
Sent: 27 September 2019 00:07
To: RTGWG <[email-masked]<mailto:[email-masked]>>
Subject: IP Traffic Engineering

Dear RTGWG,

Kind regards,
Robert.

- - -

Abstract:

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

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 27 Sep 2019 17:35:38 +0200

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 <[email-masked]> 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):
>
> 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:
>
> 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.
>
>
>
> *From:* Teas <[email-masked]> *On Behalf Of * Robert Raszuk
> *Sent:* Friday, September 27, 2019 6:50 AM
> *To:* Adrian Farrel <[email-masked]>
> *Cc:* Lou Berger <[email-masked]>; [email-masked]; RTGWG <[email-masked]>
> *Subject:* Re: [Teas] IP Traffic Engineering
>
>
>
> Hey Adrian,
>
>
>
> <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=>
>
> <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://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=>
>

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 27 Sep 2019 22:22:31 +0000

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 the list of functions for the packets at the specific nodes instead carried by the packets?

Linda Dunbar

From: rtgwg <[email-masked]> On Behalf Of Robert Raszuk
Sent: Thursday, September 26, 2019 6:07 PM
To: RTGWG <[email-masked]>
Subject: IP Traffic Engineering

Dear RTGWG,

Kind regards,
Robert.

- - -

Abstract:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-raszuk-rtgwg-ip-te-np/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-raszuk-rtgwg-ip-te-np%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C256e22588531436f98c208d742d63f1c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637051360284126163&sdata=4iFawd0kmgkI%2BNSfbIBWQfxfeSRyp8o6%2BFsEH5RnvtU%3D&reserved=0>

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-raszuk-rtgwg-ip-te-np-00<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-raszuk-rtgwg-ip-te-np-00&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C256e22588531436f98c208d742d63f1c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637051360284126163&sdata=pt%2FDC6LOEWdUojw7xtL18ssLslnPi9RMf7MGbr5gm7E%3D&reserved=0>
https://datatracker.ietf.org/doc/html/draft-raszuk-rtgwg-ip-te-np-00<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-raszuk-rtgwg-ip-te-np-00&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C256e22588531436f98c208d742d63f1c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637051360284136155&sdata=yne9u0y4hiOIsDrjiuPusmEUMBg8d9ICp7HozovzXFA%3D&reserved=0>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 28 Sep 2019 00:52:38 +0200

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 <[email-masked]>
wrote:

> Robert,
>
>
>
> Interesting proposal, especially on the Active Path Probing allowing
> minimum path quality metrics to be specified for data plane.
>
>
>
> 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 the
> list of functions for the packets at the specific nodes instead carried by
> the packets?
>
>
>
> Linda Dunbar
>
>
>
> *From:* rtgwg <[email-masked]> *On Behalf Of * Robert Raszuk
> *Sent:* Thursday, September 26, 2019 6:07 PM
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-raszuk-rtgwg-ip-te-np%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C256e22588531436f98c208d742d63f1c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637051360284126163&sdata=4iFawd0kmgkI%2BNSfbIBWQfxfeSRyp8o6%2BFsEH5RnvtU%3D&reserved=0>
>
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-raszuk-rtgwg-ip-te-np-00&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C256e22588531436f98c208d742d63f1c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637051360284126163&sdata=pt%2FDC6LOEWdUojw7xtL18ssLslnPi9RMf7MGbr5gm7E%3D&reserved=0>
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-raszuk-rtgwg-ip-te-np-00&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C256e22588531436f98c208d742d63f1c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637051360284136155&sdata=yne9u0y4hiOIsDrjiuPusmEUMBg8d9ICp7HozovzXFA%3D&reserved=0>
>
>

---

From: Aijun Wang <[email-masked]>
Date: Sat, 28 Sep 2019 06:59:55 +0800

Hi, Robert:

As Deborah mentioned, we have studied the TE requirements in Native IP network for some time.
Besides the scenarios and simulation results that described in 
https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/
We also provided the solution draft in https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/  and the corresponding PCEP extension draft 
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/

The above solutions can also accomplish the aims that you mentioned in your draft.

I have also read your draft in general and will review it detail in following days. Anyway, I am glad to know that TE in Native IP requirements become more aware to more people. 

Aijun Wang
China Telecom

> On Sep 27, 2019, at 23:36, Robert Raszuk <[email-masked]> wrote:
> 
> 
> 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. 
> 
>> 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”.
>> 
>>  
>>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 28 Sep 2019 01:27:00 +0200

Hello Aijun,

Thank you for sharing your work in this space.

I need to carefully read your documents as I was not aware of their
existence. The the last draft you shared a pointer to (PCE in Native IP
Network) I actually see few similarities to my previous idea described few
years ago by Keyur and myself in
https://tools.ietf.org/html/draft-patel-raszuk-bgp-vector-routing-07

We were not sure if there is need for such model as clearly such design is
destination only and is limited to single administration domain.

The new document's (IP Traffic Engineering Architecture with Network
Programming) has much broader applicability target.

Many thanks for sharing and your comments,
Robert

On Sat, Sep 28, 2019 at 1:00 AM Aijun Wang <[email-masked]>
wrote:

> We also provided the solution draft in
> https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/
> <https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/> and the
> corresponding PCEP extension draft
> I have also read your draft in general and will review it detail in
> following days. Anyway, I am glad to know that TE in Native IP requirements
> become more aware to more people.
>
> Aijun Wang
> China Telecom
>
> 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 ?
>
>> *Cc:* Lou Berger <[email-masked]>; [email-masked]; RTGWG <[email-masked]
>> >
>> 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”.
>>
>>
>>

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 27 Sep 2019 23:47:13 +0000

Robert,

Thanks for the quick reply.
Do you mean that P2 in Figure 1 can switch and swap labels carried by the IP header (for the T2 Path_A2)  based on the instruction from the controller ?

My question is only to check if it is possible utilizing existing features on routers.

If P2 can be upgraded to support swapping bits in IP header, then more new features can be enabled (in addition to yours).

Linda

From: Robert Raszuk <[email-masked]>
Sent: Friday, September 27, 2019 5:53 PM
To: Linda Dunbar <[email-masked]>
Cc: RTGWG <[email-masked]>; [email-masked]
Subject: Re: IP Traffic Engineering

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 <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Linda Dunbar

Dear RTGWG,

Kind regards,
Robert.

- - -

Abstract:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-raszuk-rtgwg-ip-te-np/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-raszuk-rtgwg-ip-te-np%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C02ff3b0165bc4f7fdddd08d7439d6ae9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637052215698214872&sdata=rVQaZc1YQFAmmrODfzEpraJToztMiI1vCu8%2B0aBnh%2BQ%3D&reserved=0>

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-raszuk-rtgwg-ip-te-np-00<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-raszuk-rtgwg-ip-te-np-00&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C02ff3b0165bc4f7fdddd08d7439d6ae9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637052215698224875&sdata=9VNG6OhnlJVQUuwz6JlfJek%2F5MDd3SAVVodLUIXagmg%3D&reserved=0>
https://datatracker.ietf.org/doc/html/draft-raszuk-rtgwg-ip-te-np-00<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-raszuk-rtgwg-ip-te-np-00&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C02ff3b0165bc4f7fdddd08d7439d6ae9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637052215698234871&sdata=KsxSjEST0DHGRBvV2fDIgxa5s3euuEzf7kXnkpP%2FYD0%3D&reserved=0>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 28 Sep 2019 01:58:48 +0200

Hi Linda,

As I mentioned P routers are outside of my control.

Imagine SRC_NET is NY, DST-NET is SF and P routers are random ISPs in
between East and West Coast. SEs are TE midpoints in AWS.

That is one deployment scenario which I want to support in the proposed IP
TE architecture. I understand that you would like to perhaps reuse paradigm
of label swapping but I see no room for MPLS transport here at all. After
all IP src+dst lookup is already a requirement for at least IPv6 based
forwarding.

Many thx,
R.

On Sat, Sep 28, 2019 at 1:47 AM Linda Dunbar <[email-masked]>
wrote:

> Do you mean that P2 in Figure 1 can switch and swap labels carried by the
> IP header (for the T2 Path_A2)  based on the instruction from the
> controller ?
>
>
>
> If P2 can be upgraded to support swapping bits in IP header, then more new
> features can be enabled (in addition to yours).
>
>
>
> Linda
>
>
>
> *Sent:* Friday, September 27, 2019 5:53 PM
> *To:* Linda Dunbar <[email-masked]>
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-raszuk-rtgwg-ip-te-np%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C02ff3b0165bc4f7fdddd08d7439d6ae9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637052215698214872&sdata=rVQaZc1YQFAmmrODfzEpraJToztMiI1vCu8%2B0aBnh%2BQ%3D&reserved=0>
>
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-raszuk-rtgwg-ip-te-np-00&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C02ff3b0165bc4f7fdddd08d7439d6ae9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637052215698224875&sdata=9VNG6OhnlJVQUuwz6JlfJek%2F5MDd3SAVVodLUIXagmg%3D&reserved=0>
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-raszuk-rtgwg-ip-te-np-00&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C02ff3b0165bc4f7fdddd08d7439d6ae9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637052215698234871&sdata=KsxSjEST0DHGRBvV2fDIgxa5s3euuEzf7kXnkpP%2FYD0%3D&reserved=0>
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 28 Sep 2019 02:21:31 +0200

Hi Linda,

It just occurred to me how you could interpret Figure 1. Apologies I will
fix it in next version.

The "ADMINISTRATIVE DOMAIN" there should really be called "IP TE DOMAIN"
created with encapsulated packets between Segment Endpoints (TE midpoints).
So my IP TE+NP is build as an overlay over chains of ISPs.

Is it not one AS in the traditional sense. Underlay is just wild Internet
where each P can be a different underlay administrative domain or even more
then one domain.

Of course the proposal easily works also in the basic case of real single
AS, but my objective was to design something which can be deployed globally
as well as locally.

Hope this clarifies your doubt.

Sorry for the confusion,
Robert.

On Sat, Sep 28, 2019 at 1:58 AM Robert Raszuk <[email-masked]> wrote:

>> If P2 can be upgraded to support swapping bits in IP header, then more
>> new features can be enabled (in addition to yours).
>>
>>
>>
>> Linda
>>
>>
>>
>> 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.
>>
>>
>>