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 protected]> 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 <[email protected]> > *Sent:* Friday, September 27, 2019 5:53 PM > *To:* Linda Dunbar <[email protected]> > *Cc:* RTGWG <[email protected]>; [email protected] > *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 protected]> > 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 <[email protected]> *On Behalf Of *Robert Raszuk > *Sent:* Thursday, September 26, 2019 6:07 PM > *To:* RTGWG <[email protected]> > *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> > >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
