notes-ietf-87-rtgwg

Agenda: http://tools.ietf.org/agenda/87/agenda-87-status.html

Scribe: Carlos Pignataro

Stacked Tunnels for Source Routing (STATUS) BOF

MONDAY, July 29, 2013
1300-1500 Monday Afternoon Session I

CHAIR(s): Alvaro Retana <aretana@cisco.com>
John Scudder <jgs@juniper.net>

o Administrivia and Introduction 10 minutes
Chairs, Area Directors

Welcome!
We have a full agenda and tight schedule. For comments, please say your name and your comment briefly.
There is also time for open discussion at the end.
See the new abbreviated Note Well <John reads Note Well>.
BTW -- I will be shocked if there are no patents applications for the things we cover today, in fact some disclosures may have already taken place
The goal of this BOF -- source routing has existed as long as networking, but has not been used much. The goal is to answer if we should use it more.
Next level goal is an additional set of questions -- what use cases, which data plane, which assumtions, what management/control architecture we want, and what is a label anyway.

Questions:

John: Anything ADs want to say?
Stewart: No, you said it all.
John: We are 5 minutes ahead.

o Use Case: Performance Engineered LSPs 10 minutes
Rob Shakir

I want to create LSPs in an IP/MPLS infrastructure which are routed away from SPT based on performance constraints.
Today, we have our topology with the IGP and its metrics, and we optimize given whatever we say that metric is. But the issue is what happens when there are different services over this network.
There are specific applications that are performance or delay sensitive -- how do we meet those requirements?
Today, transport networks are good. But more applications require these performance requirements.
Generalizing, these are things I could do with RSVP-TE. BUT, if I start including per-service per-flow LSPs, then the number of LSPs does not scale. The whole network never actually converges (back pressure on the head-ends RSVP-TE).
Midpoint-state is used only for admission control (coloring), so why do we need state in the middle?
Consequently, next approach we discuss is Segment Routing, which removes the constraints of state in the middle of the network.
We would like to reuse existing mechanisms. Extended IGP attributes, and distributed path calculation.
For routing with multiple services, we have PCE and we can use PCE.
We have written this draft (with Vodafone and Telecom Italia) and is pretty key to us.
I would encourage we move forward with this one.

Questions:

Ed Crabbe, Google: Disclosure. I am involved in the SR efforts. I have similar use cases to this. I have large full meshes for a variety of reasons -- service meshes to measure. SR is definitely going to help us with this and I am looking forward to it.
Nitin, Juniper: If there is no state in the middle of the network. You do not account for how much traffic on a path (i.e., transit network is a black box), how do you manage?
Rob: How is that so different from today?
Nitin: Today you have reservations.
Ed: That is not true today.
Nitin: It is better than nothing.
Rob: I do not have that today -- being able to deploy it it would be advantageous to have that information, so I do not know if that is a requirement.
Someone: In SIP we are using SIP addresses for source routing. Looks nice in paper, but in practice nobody uses it in open networks. For the security reason that killed source routing in the IP space.
Rob: The point to me is: this is whithin my operational domain, not cross-domain.

o Use Case: MPLS OAM 10 minutes
Ruediger Geib

This is about SR OAM use case.
The classical approach, you have many monitoring boxes (or the routers themselves), checking if there is connectivity. Smart way of dealing with ECMP also.
If you then use Segment Routing, it simplifies a lot because you only need a single system or router dedicated to this task and you can monitor all your network.
I do not go into details but you will figure out in detail if you work in OAM.
It is scalable and increases availability. But basically you need one and monitor all paths in the network.
We have in DT a prototype connected to our commencial network.
Google I think also working with IP based solution, but I understand pretty much identical appraoch to what I just showed

Questions:

Kireeti Kompella: You have this interesting path that goes in the diagram. So in OAM you check a connection or service to see if it is OK. If you have that path already, why can't you use that same path to test OAM?
Ruediger: You send the result to the source, to then transmit the result to a single router.
Kireeti: So you really want to ping from A to B, but want to start it from a different area.
Ruediger: Yes, exactly.
Kireeti: So telnet is not good enough a protocol that you can telnet and source an OAM?
Ruediger: No, it makes my life hard. We do not run a small network, my NOC needs to be able to use this.
Ed: Kireeti was joking, I guess. This is topological problem. Figure out complete set of paths that are recovering. I know we both published things on this. To be clear, Google is using this in our core. Note SR, but there is significant state in the middle.
Nitin B., Juniper: If you ignore ECMP paths.
Ruediger: We also covered ECMP paths.
Nitin B.: In MPLS, George Swallwo published a draft on remote initiated MPLS Ping.
Ruediger: Any solution should cover ECMP -- it is a MUST. Thank you.
George Swallow: Just a comment, Remote ping is a great tool, but I saw the google paper and I think that is a really really really cool ping. You need that level of sophistication.

o Use Cases: ECMP based loadsharing across disjoint 10 minutes
networks, QoS based explicit routes
Martin Horneffer

Reducing Complexity in the Network Architecture
Comparing MPLS based on RSVP, based on LDP, and Segment Routing.
- RSVP-based: complex to setup, overlay topology
- LDP-based: Issues of having LDP and having it synchronized
- SR (with MPLS labels): Label TLV in an existing IGP -- and that is it. You can have additional complexity for some use cases, but only as much as you need.
First use case: I am working on this project of Disjoint Paths.
- Sigtran traffic in the mobile network requires disjoint paths. We use MPLS FRR for fast re-route.
- The fixed network does not require disjoing paths, it is optimized for efficiency and we use IP FRR.
- What we will do to merge these two networks. Merged, it works, it can provide FRR, but it is not efficient.
- If we could tailor the IGP so that the high-bandwidth traffic takes advantage of ECMP.
Second use case: locations in diffferent continents.
- Routing of Asia-Europ traffic, going through America, which is low latency but very expensive.
- We could send the delay sensitive only traffic that way.
- Today I could set RSVP Tunnels optimized for latency. But this is complex with RSVP and have this overlay topology (as seen from the IGP)
- If you had Segment Routing it would be much easier. I can run the IGP as I do it normally, but optimize the special case only for delay-sensitive traffic.
All those use cases are mentioend in the use case draft.

Questions:

Nitin B.: On slide 6, hypothetically, if someone gave you a solution that gave you no complexity and operation cost savings, would you still do SR?
Martin: I cannot see how that could be done, if should have state in the core. Maybe you can spare the operational guys from manually configuring the Tunnels.
Victor Lopez from Telefonica: We support this because we are using the same use cases. We have a company connected between North America and South America and we are seeing how to use SR for this.
John: I need to cut the mike and remind that we have open discussion at the end.

o Use Case: Fast Reroute 10 minutes
Bruno Decraene

IGP convergence is not fast enough. We are looking for a FRR technology.
Remote LFA completely matches STATUS. We can do it with no protocol extensions but needs dynamically established T-LDP.
Directed LFA is a solution. With Remote LFA you can still find topologies that are not covered.
The applicability is egress or PE node protection. Protects the service node at the end of the LSP. You need a protection node mirroring.
Protocol extensions for FRR on the other hand are required for no T-LDP sessions.
Incremental deployment is interesting. SR FRR is interesting

Questions:

John: Any questions? Going once, twice, gone.

o Use Case: Converged Multi-network Operation 5 minutes
Victor Kuarsingh

We started with a problem statement as an operator would see it. We have multiple networks that do different things and we have services that span networks.
When you look at those networks, they were built with a specific function and we cannot change them.
Services are stuck with those networks.
Not all services require the same thing (e.g., QoS requirements, resiliency)
We need lowest cost path routes. And for this we have to deal with TE.
It is getting pretty complext. As we look at this there is no one solution, which is why we looked at this.
The simple you can make the solution, and reducing how much state you need in your network, that is best.
We are big in programmability -- there is no way to scale to 'N' services spanning multiple networks and manage and provision all of that manually.
As we said, we need support for explicit path. Also FRR, and services that require different traffic treatment.
We have different services, that need to be different
This slide shows examples on how we stack services, domain and paths.
Networks have been optimized for specific things but we have services crossing those diverse networks. We cannot change those, but we need to provide consistency for the service.
We cannot afford to build 3-4 paths for each.
Programming and SDN Interaction. Out operational models will not scale so we need to have programming and with STATUS we have an opportunity to push this to the edge, and there's a lot of advantages of that.
We see a huge simplification. I only had 5 minutes so I went pretty fast.

Questions:

John: John, we will have time to fit you in

Comcast use case for IPv6 SR
Brzozowski, John <John_Brzozowski@cable.comcast.com>

Thank you very much for allowing time.
We want to present a Comcast use case. IPv6 is widely deployed, we have Video, we have a number of services. We have a virtualized infrastructure to delvier content services.
From my point of view, this is why we see SR as a technology for us.
We need to push this into the home.
We feel it is transparent, working across especially our v6 environment and non-SR devices.
We have an incremental approach.
Here is the diagram.

Questions:

Ross Callon, Juniper: I apologize I have not read. It seems you are talking about video networks and networks with a bunch of stuff. In the core you have high bandwidth, so presumably you have ASIC forwarding in the core. IPv6 should work well with MPLS. I've seen some v6 that uses a new v6 header as opposed to MPLS header for forwarding. One issue is that if we define a new header, it will take years to deply that, whereas now IPv6 works with MPLS just fine.
... At the time v6 was being defined, vendors were saying that we needed ASICs, and the v6 people were saying: no, we need RISC processorts. So v6 seems optimized for RISC and not ASICs.
... so what you say makes sense, but you have not talked about what headers will be there on the wire.
... I wonder if you have comments on that.
John Drake: The point you make is that MPLS is very common in core networks
John S: Can you guys put a pin on that and table the discussion for later offline?
Ross: Sure.

o Stacked Tunnels, OSPF/ISIS as Label Distribution 10 minutes
Protocols, and MPLS Architecture
John Drake

Explicitly router tunnels are routing on a path different than the hop-by-hop path.
The other aspect of this is LSP Hierarchy which allows you to stack labels on others.
So you can create a stack of labels to have end to end path set up from the source.
This is frequent in GMPLS -- the label is the same end-to-end, and that is fully compliant with the MPLS Architecture.
RFC3031 says that a multiplicitly of label distribution protocols are OK.
IGP neighbors can talk about LSPs that actually terminate many hops away.
We can use RSVP or LDP to establish segments.
Using the IGP we get nice control scaling. Once we have the local adjacency we can distribute the labels within the area.
Unlike T-LDP we can distribute labels, so it gets rid of Targeted LDP.
Conclussion: We think this is completely consistent with the MPLS Architecture and enhances MPLS.

Questions:

Lou Berger, clarifying questions. Are the labels distributed iwth the IGP to all the area or are they scoped?
John: All area.
Lou: Sounds like a lot fo state.
John: The change of state are one or two properties per link
Lou: Plus TE
John: Already there.
Kireeti: I agree that all you have is in the MPLS Architecture. We just have to change the name from Multiprotocol Label Switching to Multiprotocol Label Stacking.
Someone: Unicast or Multicast?
John: This is unicast, but can extend.

o Advertising MPLS LSPs in the IGP 10 minutes
draft-gredler-isis-label-advertisement
draft-gredler-ospf-label-advertisement
Hannes Gredler

Two types of advertisement:
First: desire for automatic meshing of LSPs. People like the LDP model that you turn it on, track IGP, and at the end you have the full mesh. Transport path tree is computed according to an algorithm (and you can have multiple optimizations). There have been attempts to build transport paths by the IGP with label
I do not want to go into details, but it has been stated many times that label allocation is local significant.
Index to label range is a pointer to where traffic is coming from. So we flip the logic and we use destination.
Slide 6 -- consider we have this network. The local label range is strictly their local choice. It is actually pretty straight forward to compute the SPT then.
Second: the second type of advertisement is explicit route. So we change the next hop as a chain of next hops, and we extend the ERO. For any particular label you an advertise the primary but also backup and detours. The protocol is very clean, we can probably replicate it from OSPF and ISIS.
In June we got together with our friends at Cisco who have this Segment Routing thing coming up and supports similar requirements, so can we merge? So we took the ideas and merged them, We did that both for ISIS and for OSPF as well.
After the draft merge, quick summary is that the protocol semantics are pretty much identical.
There are also some differences:
- We have an MPLS way of doing things, because RFC 3031 provides enough architecture and we do not need a enw architecture.
- There's also the point of reuse. We do not want to introduce dataplane #4 in the internet for costs
That's the end of my talk. Any questions?

Questions:

Stephan, Orange: First, thank you for the merge of the draft. I just have one question: Why do we want to push the index-based allocation of the segments? What benefit you see?
Hannes: MPLS networks have been deployed for a long time. Redefining semantics can be dangerous and damaging. We have seen redefining label-allocation procedures actually does damange to existing protocols.
Stephan: I can see benetif to using network-wide labels. If you are doing netwflow, and if you have domain-wide label then you know the context of that flow.
Hannes: Vendors have a configurable label manager so you can pre-provision identical labels and it is a local procedure.
...I care about interoperability. So if a router does not have this it can still interoperate.
<name>, France Telecom: Global labels are of advantage and I appreciate if you can get there.
Raszuk: On the bashing of IPv6 -- there are a lot of networks that use IPv6, including Data Center, and do not require modification. BGP Vector routing does not require
Hannes: Do not get me wrong, this is not about not supporting IPv6. It is about the v6-specific segment routing instantiation.
Wes George: There is a draft circulating in MPLS right now which talks about what happens with MPLS when you turn off v4. This has to work in IPv6-only networks.
Hannes: There is no fundamental issue.
Jeff Haas, Juniper: With netflow, the current state of the art of using netflow for MPLS is that it is very complex to match the state of forwarding with the actual label value. Domain wide or not you get that.
Hannes: Thank you.

o Segment Routing 10 minutes
draft-filsfils-rtgwg-segment-routing-00
draft-filsfils-rtgwg-segment-routing-use-cases-00
draft-previdi-isis-segment-routing-extensions-00
draft-psenak-ospf-segment-routing-extensions-00
draft-sivabalan-pce-segment-routing-00
draft-francois-rtgwg-segment-routing-frr-00
Clarence Filsfils

Good afternoon, quick update on Segment Routing. Here's the list of folks that contributed to this.
There's been a lot of use cases that have been presented.
At the BOF we do not need to explain the technology. Only one slide. Generality of a segment. It is both intra or inter domain. It is from forwarding but can be abstracted. Not restricted to one instantiation.
We have been working on an agnostic control plane. But there are request for instantiating two data planes: MPLS, and IPv6
Productization: I presented this first time in September 2012, and have commitments after 5-6 months, on MPLS and interest on IPv6
With all the people of the draft (inclusive), we have been meeting once or twice a week.
We've been working until June when we met in Rome, and working together. We merged so that we have a single SR draft.
The next is to write together the MPLS instantiation.
Also drafts on FRR application and one more.
This is the picture in Rome in June, two days of intensive work. In addition to reaching agrements, we quickly wanted to submit ISIS and OSPF draft before we go on vacation. Great week in Rome.
Progress. Thanks to our collegues Hannes from Juniper. The disagreement on IPv6/SR should not be an issue. We have committed our resources to study an IPv6 isntantiaiton of SR, and we will bring this to IETF. The only point we want to underline is that we hear the request and we are funding the request, so we will bring the proposal with operators and members from academia.
Next IETF: One of the questions -- do we need a WG? We believe we do not need it. Many use case with extensions with established protocols and WGs. We would like to have velocity and speed and use the established WGs. If there is a WG created we will support it but ask that overhead is not added.
The use cases are many, the doc is big and we could have added more. Many thanks to all members of the team. You see the different sections of the draft.
Conclusion: I think it's been a great experience of collaboration of operators and vendors. We see many requirements and use cases for this technology. If you look at the applicability to MPLS it is significant to drastically simplifying its deploying but also enable its true functionality.
MPLS brought explicit routing, but 15 years later the deployment is small.
In my opinion if I look at it in a natural viewpoint, it looks obvious the notion of explicit and source routing in IP is needed. We need to take into consideration the impact. We will bring to IETF ror wider review in the next few months.

Questions:

John S: Any questions, comments? If not, Peter you are next.

o Source routing and SDN 10 minutes
draft-ashwood-sdnrg-state-reduction-00
Peter Ashwood-Smith

In S5.2 of the segment routing use cases there is a description of the use of SR for SDN.
We did some similations of SR in exactly this context. We simulated the ideal version of SR, not the MPLS one, but unlikelt there are differences.
We used 36 nodes (OS3E network), the controller in Chicago, and measured the convergence time from packets arrival at the first switch router, and as you can see the green at the top is the SDN hop-by-hop convergence, and the red line is the SR, so 3 times. Very promising results.
Next we took the simulated controller and moved it around to the location of all the switches and looked at the placement, and looked at the standard deviation of the convergence.
The gyellow is the SDN hop-by-hop deviation and the SR is the blue. You can see 86% improvement.
Last thing we did is exploring the network size. We multiplied link delays for various values. What we saw is a 1/R type curve.
If you think about it like a circle, SR works in the circumpherence of the network, but hop-by-hop on the area of the circle. The ration is 1/R.
Larger diameters give more impressive advantages.
We are working on a "protocol oblivious forwarding" for the idealized of source routing for forwarding.
That's it for me. Questions?

Questions:

o Open Discussion 20 minutes

John S: OK, thanks for everyone that spoke up. Now we have questions to answer. I see people going to the mikes already. Now it's your chance.
Ross Callon: If I do not think about the IPv6, what we are basically doing: In 1991 we knew source routing was important, and we came up with RSVP-TE so all nodes in the route need to agree so there's state but packets just flow. Now we are moving state into the packet, so what is the limit? Have people thought about that? Is there some point at which MTU breaks or something breaks? In the MPLS presentation there were 3 labels and you are fine.
John S: Replies encouraged at the mike.
Ed Crabbe: Yes, we thought about that. We have different services with different packet size distribution. We know on a per-service basis what we would use as we move to SR. The gains that we get in terms of control plane. If you have 1000s and 1000s of nodes, then you designed the network poorly.
Victor Kuarsingh: Regarding the IPv6 case. In our position, if the architectural benefits are tehre and simplication can be had, from an operator standpoint I thing there is value in pursuing the v6 option. We need to evaluate the architectureal benefits. For us, it adds simplification. The complexity of config is the issue we need help with.
Clarence: The question is very important. If you look at it theoretically, it fails, you can think of 24 labels. The real gain is by looking at the real operator deployment. If you look at the use cases today, will be used with 2 or 3 labels. For exampel, FRR is proven to be solved with 2 or 3 labels. Then you have performance and add a label. It is rara you need mroe than 3-4 labels. But even say you need 6-7, even in that case it's not issue. The process that drives the instantation of this is a capacity planning process. Modeling the network, the traffic, and the constraints and capabilities of the node. One of the things we learn in the PCE draft is how many labels you can include.
Academically, the worst case is catastrophe if someone puts 26 labels it won't work. But if you look at it from a use case bases, the benefits are huge.
Peter: I agree. Also, we are the IETF, and if need to compress labels we can.
John S: What about the network you modeled?
Peter: Diameter of 5
John: With enough thrust even pigs could fly?
Peter: Even MPLS flies.
Ross Callon: We are here in a working group forming BOFs. There's been a list of 6 WGs, but BFD as well, so 7. So seems to me that we need work to be done here and we need the coordination. There is work which is how you carry in ISIS, and ISIS will look at that. But seems to be there ought to be a Status or SR WG looking at all the pieces.
Kireeti: Yes, it's an old idea, but we do it already, it is called RSVP-TE. It was a joking comment about switching versus stacking. When we saw this there were questions on the label stack and global labels. When we added entropy labels and special purpose labels, people asked about depth of stack. So that question has not been answered. Regarding use cases, one use case makes a alot of sense, not all use cases make sense. Because we have a new technology does not mean need to solve. We need to be very careful in this WG and start with one or two use cases. Last comment, I've seen many presentations about removing complexity. Be very careful: you are not removing complexity, you are moving complexity around.
<applauses>
John S: I echo that.
Operator A: Larger network that can be a problem. You are moving complexity somewhere else.
Ed Crabbe: Working in Google I am biased. I totally agree with moving complexity. But moving complexity into a platform that can handle it better is not necessarily a bad thing.
Erik N.: I think there is commonality around MPLS and some discussion about IPv6. But there was one thing in John's presentation that was more out there taking this to the home. So I am trying to understand the architectural implications. Is it a service provider use case
John: Great question, we would be asking that if this was a charter forming exercise.
Peter: Worked really hard on IPv6. Having source packets can be used in many ways. What about the home. We would be crazy to not let the IETF develop the best tool, and the user can choose. We try to make the best iInternet.
Alia: On the "should it be a BOF or broken out"? There are different pieces. The MPLS piece is well understoof, the IPv6 not so much. It seems like a lot of the architecture and use case drafts are coming at RTGWG, which is used as an incubator. The argument about "is there a WG for Status and protocol pieces on WGs" has evolved into "does architecture go to RTGWG", for doign work we need working groups.
Hannes: To Peter;s comment. What sense does it make to replicate tag-switching semantics into IP just to call it "label free"? That's replicating work. We've done it once.
Peter: Last time I checked we do not have NNIs. We need an architecture.
Hannes: Look at the comcast requirements. At no point they are asking for source routing end-to-end. They are asking for IPv6 end to end.
John S.: Last one.
Peter: On the point of WG or not, seems like a common place seems useful instead of going in many WGs.

o Wrap-up 5 minutes
Chairs, Area Directors

Let's poll the room on some of these stuff, with show of hands.
Do we want to take this work on? Who is for? Like a forest. Who things we shouldn't? No hands <that I could see>. We have the answer on that one.
Next one is: OK, how? Is it a WG or do we have enough WGs thank you very much. And if it's a WG we can ask about its nature.
Eliot: Alia raised another choice about RTGWG.
Stewart: First question is: should there be an explicit WG to work on this. Those who think yes: small number. Those who think not: larger number.
...Where is the architecture: Yes for RTGWG: many hands. Those for no: one/two hands
... one of the chairs.
John S: Do we need an MPLS dataplane?
Stewart: MPLS dataplane. Yes: many hands. No: fewer or none.
... IPv6. yes: medium. no: tiny.
... dataplane other than MPLS:
... undecided: 8 hands.
... who wants a source-routed IP dataplane? tiny number.
John: I think we actually answered the set of questions we can answer in the amount we have.
Stewart: Where are the use cases worked on? Do people want those in RTGWG?
John: We should ask the RTG WG too.
Stewart: The IESG will make that desicion. The particular we talk about has that scope.
Alia: I am concerned that use cases + architecture will be more than "short simple small term" documents.
John: I heard from others that this is hot and needs to move quickly. If you add to existing RTGWG would not mean fast.
Kireeti: The question should -- do we want a single WG? and then ask "existing or new one"? I think the questions were confusing.
Stewart: do you want us to creeate home for architecture and use cases? some charted coming to existence?
Someone: We do not understand.
John S: we are now out of time -- thank you everyone.