Re: [Teas] IP Traffic Engineering

[Robert Raszuk <[e-mail]>]

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 <[e-mail]>
wrote:

> 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 <[e-mail]>
> *Sent:* Friday, September 27, 2019 5:53 PM
> *To:* Linda Dunbar <[e-mail]>
> *Cc:* RTGWG <[e-mail]>; [e-mail]
> *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 <[e-mail]>
> 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 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%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>
>
>