Re: [Teas] IP Traffic Engineering

[Robert Raszuk <[e-mail]>]

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

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