RE: IP Traffic Engineering

[Linda Dunbar <[e-mail]>]

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 <[e-mail]> On Behalf Of Robert Raszuk
Sent: Thursday, September 26, 2019 6:07 PM
To: RTGWG <[e-mail]>
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://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>