IETF-88 spring meeting minutes
Source Packet Routing in Networking WG (spring)
IETF 88 (Vancouver) Agenda
=====================================================
CHAIR(s): John Scudder <jgs@juniper.net>
Alvaro Retana <aretana@cisco.com>
MONDAY, November 4, 2013
1450-1720 Afternoon Session II
Regency B
Meeting starts at 14:51 local time
o Administrivia
Chairs 20 minutes
- Note Well
- Scribe
- Blue Sheets
- Charter Review
- Alvaro: This is the first time that we meet, this is Alvaro and John.
- … Carlos is here taking notes. Always here the NOTE WELL. Make sure you know that by participating in the IETF to agree to the IETF process, you understand that meetings are being recorded, et al.
- … Blue sheets are going around. First agenda bashing and then charter review…
- … We have a very full agenda. Any changes you;d want to propose?
- Someone shouts: move charter to the end.
- Alvaro: The agenda matches the order in the charter, so first we have use cases. Ida will join Stefano, that’s the only change. We might not get to all the items on the second part of the agenda. Other items? No, great.
- … This is the charter, which has been discussed *a lot*. It went to the IESG, external review, etc. If you have comments please make them but at this time that might be comments for clarification.
- … second part of the charter, from the IESG review, for every data plane we need to have a security analysis. This is important for every piece of work that comes in
- John: And to re-emphasize, it’s important that that happens early on and not late.
- Alvaro: Page 3 of the charter, says that any modifications or extensions need to be done in the WG responsible for that protocol. We will send requirements but protocol work will happen in other working groups.
- … keep that in mind as we develop solutions and where solution work should go. Note the text at the bottom are the charter items. We will talk about requirements, who owns the data plane will talk about the solution.
- … and the last page of the charter lists the Milestones. This should march the charter items. I do not think anyone should have issues with the dates, but please speak up.
- Thomas Narten makes a motion to have people shift-sit-left so that people standing up can sit down.
- John pleads for people to raise their hands if they are next to an empty sit.
o Segment Routing Use Cases
http://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-use-cases
Stefano Previdi and Ida Leung 15 minutes
- Stefano: Presenting the SR use case draft, that we’ve been doing for the last 4 months. We are splitting the content in separate drafts, and thus we have the following docs that have been or will be submitted very soon.
- … We have SR/LDP interop, OAM from Rudigher, and three to be published.
- … this is the list of authors, which is growing given these documents.
- … Next slide — those are the sections in the generic use case draft, in 5-10 minutes I cannot go into details. We will take time in explaining the main use cases, like TE.
- … Next slide: The main use case is efficient transport of MPLS services, shorter path, and keeping the ECMP awareness even for explicit routing. The ability of running explicit routing without extra signaling (no LDP, no RSVP), and if you run MPLS with IPv6, you do not need to wait for LDPv6
- ...The real operator problem to solve is CoS-based TE, for Asia to Europe go to the US, but for a different traffic take a different path based on delay.
- …the alternative was multiple TE tunnels, but the advantage of SR is that identifiers from Asia domain will attract traffic to Asia, and from there it would flow to Europe. Solving a problem sensible to operators.
- … Next Ida will present.
- Ida: I am Ida from Rogers. We have cable TV and internet business, and we have individual lab to deliver each. Wireless only from Wireless access point. Cable only from Cable access point.
- … Now, I actually have more service from one network cost to another domain. That’s my problem statement. Different networks, all have their IGP, and I need to find a way to keep my traffic cost low. Moving to 10G, 100G, I need to find a way how to stop expanding.
- … Some traffic I also want on explicit paths. Even in the lab, it is way too complicated to deploy and operation to maintain. I need a solution, something simple.
- … I need something like myself, simple and straightforward. One mechanism to fulfill all the requirements.
- … I am excited for SPRING because it helped me find a solution to this.
- … the first use case is typical, I have an Internet exit point. I need to provision from my Dual Plane Network to my Single Plane Network, and SPRING provides me that mechanism. Now I actually can build more NNI and control which NNI to go from my dual plane to my single plane network.
- … I can actually stop growing these (dual plane) WAN links. I do not need to continue to build here, and I can save money. Ultimatelly will not have dual plane, my big dream is to not have the dual plane network.
- … this other slide is more about Server (slide 5). Some of my traffic I do not want them to follow my IGP metric. Now SPTING can give me an answer to that.
- … this are my two use cases. I do not build a network from one vendor. I need all vendors to bring SPRING.
- Questions:
- Stewart: IP, MPLS, or both?
- Ida: First, MPLS. Second, IPv6, I also have my usage.
o Performance Engineered LSPs using the Segment Routing Data-Plane
http://tools.ietf.org/html/draft-shakir-rtgwg-sr-performance-engineered-lsps
Rob Shakir 10 minutes
- Rob: I am Rob from BT, this is traffic engineering with constraints. Essentially IGP metrics are one method to delver traffic, but we have other traffic that has other constraints. We have an overlay network, this provides connectivity for. So, we try to meet those constraints in our existing network core without building a new network, which would be inefficient.
- … we see an increase of things that need guarantees, broadcast services for example.
- … in the draft we try to explain two modes: the first one is Head-end based calculation, like colors on the IGP, using the existing cSPF.
- … one of the reasons why we like this, is that routing is based on affinity, we are not updating any state on the network. There’s no clear requirements.
- … (slide 4) however, we also thing there is a requirement to support centralized computation. Global optimization we can go for. This using a PCE, using PCEP, in the future might be generalized using I2RS type of work.
- … this introduces more requirements like topology discovery.
- … (slide 5) the other bit we are trying to cover on this draft is taking advantage of ECMPs, and explicit protection mechanisms. With a segment we can control that behavior. Covering things like how we do IPFRR. We might consolidate a use-case drafts, some things in this drafts should fall out.
- … this draft should cover these requirements on per flow basis.
- … question, comments, rotten fruit?
- Questions:
- Ed Crabbe, speaking for Lucy Young: What granularity flow are you describing?
- Rob: DSCP based, particular markings, particular FECs, classes. Very flexible.
- Ed: Which is really feedback for the PCE WG.
- Alvaro: This is very important to discuss, because it is the first item, use cases. Are there any concerns with use cases?
- <silence>
- Alvaro: Stefano said you will split into smaller drafts.
- Stefano: In fact, we already splited the content of the use case draft. What you will see is additional drafts with other use cases.
- Rob: Yes.
- John: Are you guys ready to ask for WG draft?
- Stefano: Is there risk on asking?
- John: No risk, this is the first item.
- Stefano: I’ve no reason not to ask, so I will ask.
- John: We will take it to the list, as always. If you have concerns, express them.
o Segment Routing Architecture
http://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing
Stefano Previdi 15 minutes
- Stefano: OK, now talking about the Segment Routing Architecture. 10-15 mins?
- … this is the architecture, it is the 2nd version, 3rd version but 2nd incarnation of that draft.
- … this is the list of use cases, and protocol extensions. Those protocol extensions will be presented in their respective working groups.
- … The SR architecture aims to support multiple use cases, some of which can be grouped together on a per-dataplane or a functionality. It is not required by the architecture to support all these parts.
- … SR is about segments, and a segment can represent a service, context, locator, etc. The identifiers are taken either from a local or global space.
- … SR can be used in a fully-distributed fashion, or optimization. It supports the different flavors of the architecture.
- … data planes, we support of course the MPLS DP as-is, we expect no changes from MPLS in the past 15-18 years.
- … IPv6 we do require some extensions, which already exist, consistent with RFC 2460. We have some work to do here still, but today too early and we will publish something by next IETF.
- … in regards to implementations, we have some implementations and soon we will publish an interoperability report. The feedback we get from use and troubleshooting is great.
- … what is Segment Routing about? This picture (slide 6) explains everything. Every node has a global identifier. If you put label 72 on a packet, the packet will reach node C. So if you put 72, 78, 65, the node will go C, O, Z. Nothing really new in the MPLS data plane.
- … so, again, from an architecture perspective, we talk about these operations: push, pop, swap.
- … we have a different between local segments and global segments. The local has significance in the context of the node advertising the segment. Typically it is an adjacency with a node. It needs to be known only by the node.
- … global segment has global significance. This is what the architecture specifies, we do support local label spaces from a global index. Even if different MPLS platforms support different label spaces, we can advertise an index.
- … we said this many many times, the key advantage of SR is the lack of state in the network. The amount of traffic or explicit path will not generate state in the network.
- … We define in the architecture three types of segments, or two and a half. The first one is a prefix, global. One type of prefix is a node segment. It has the semantic of being node identifier. And then you have the adjacency segment, which is a link between two nodes.
- … in the case of a node segment, the new sub-TLV called segment identifier in OSPF or ISIS, any node can push the label and the packet will reach the destination in the shortest path.
- … the adjacency segment, those have local significance. Only understood by the router that originates them. Allows to define any explicit path along the network.
- … in this case (slide 14) we might want to advertise more than one identifier per adjacency. We can use this for link bundles.
- … this is an example of mixing identifiers. My packet will travel shortest path to C, then to the link to O, then the shortest path from O to Z. This can be done also not using the adjacency label. Does the same thing with labels representing only nodes.
- … the use of adj. identifier is useful, but most cases you can do the same with node identifier.
- … we made these extensions to OSPF and IS-IS. Again, absolutely no changes to the data plan itself.
- … we started talking about service segments, it is premature to talk about them. When you build the stack of labels to put on the packet, you may also want to enforce a specific service chain. No changes to the architecture.
- … OK, questions?
- Questions:
- Anoop from Dell: Inone of the slides you said you have implementation, is that MPLS, IPv6, or both
- Stefano: We have both, but IPv6 we may want to continue some architectural work.
- Anoop: so you are using the existing source routing for IPv6?
- Stefano: Yes, extension heareds.
- Stewart Bryant AD: You made a reference to the Type 0 routing header in RFC2460, and that was the mechanism that gave the ADs a lot of headache. It would be useful to pull that out and socialize it with Int-Area ADs to know if we are on the right track or not.
- Stefano: Sure.
- Xhenbin from Huawei: Two comments. First, in practice, many vendors implemented MPLS label stacks with a limitation on stack size, on hardware. Second, for segment routing, we need to keep forwarding mechanism for MPLS Multicast. This is a challenge and adds complexity.
- Stefano: Let me ask the second one first. Dino is there, for multicast it will be complex. Regarding the label stack, yes, if you want to express a path by using one label per hop, that could be a problem for some implementations.
- … but you can see most cases are solved with a limited number of labels. Label stack has not been raised as an issue.
- Xhenbin: Maybe node segment and link segment. From the Seamless MPLS architecture, in this architecture there are more links and more nodes.
- Stefano: It’s not the number of links, it is the complexity you have on the explicit path.
- Xhenbin: My concern is scalability, limit usage.
- Stefano: I do not think so, at all.
- Xhenbin: You will have to calculate label stack carefully.
- Dino: To quote Dave Katz, take any simple problem, and will be hard with multicast. But it does not need to be. I’d recumbent tunneling and pushing the multicast to edges.
- Stefano: Yes
- Someone: You have different size advertisements.
- Stefano: In ISIS advertising a size of bits is complicated.
- Someone: TTL will be useful.
- Stefano: That is in the data plane. This is in the control plane.
- Someone: The other comment was the length of the stack. For the load balancing case and entropy label will be hard.
- John: More on EL later.
- Ahmed from Cisco: The label size is not an issue.
- Ed Crabbe: obviously I support the effort, but I do think that the length of label stack is actually an issue in LERs. Your milage will vary, it is a fact, you will have to do the analysis.
- Stefano: Yes, we are confident based on our analysis. But good point.
- Rob: Since the label stack keeps coming back, maybe we need to put a draft with anonymized data from operators.
- Ed: Again, it depends on your topology but you need to do that analysis.
- John S, as individual: It is great to present data about existing networks, but today’s networks are not tomorrow’s, so we should do that analysis as well.
- Dino: General comment about SR. The idea could be good, I do not know if it will be good. The fact that you need to make so many protocol changes… can you do this without so many changes?
- Stefano: We have to agree on “so many”, we have 3 sub-TLVs.
- Dino: The fact that you have a single TLV, means everyone needs to upgrade their routers. And if you have these changes now, you will have a lot more.
- Stefano: Just to assure you we have implementations, it addresses valid use cases.
- Robert R: Response to Dino: There is one draft with Keyur, we are defining BGP Vector router, one change, control plane independent of IGP extensions.
- Xhenbin: Regarding service chain, you have more changes. Analyze top of the label stack. Service header will be kept in the forwarding. So maybe we have to do different. See the service label firstly. That would be changes to the MPLS data plane. You have to remove top of label for forwarding then make process based on the service label.
- Stefano: No, sorry. I think you got it wrong, but let’s wait on the service chain draft. It’s difficult to discuss.
o Supporting Source/Explicitly Routed Tunnels via Stacked LSPs
http://tools.ietf.org/html/draft-gredler-spring-mpls
Hannes Gredler 10 minutes
- Hannes: Hi, I am Hannes. I want to pick on Dino’s comment that less is better. Yakov, Luay, Sri, and me have put some thoughts on how much architecture we need. We want to reuse the MPLS architecture as is, do we need all this architecture?
- … can it be that for achieving explicit routing we could use existing architectural documents, specifically RFC 3031.
- … we have a set of definitions in there that can be used for Segment Routing. Explicitly Routed is any tunnel that deviates from IGP. At the time of writing the draft, that was RSVP-TE or CR-LDP.
- … the question is can we establish explicitly routed tunnels without the core router signaling?
- … we think the answer is Yes. Essentially here each label in the stack represents an egress point.
- … furthermore, one of the things that RFC 3031 talks about is how to learn the label state. Existing protocols need a directed session, otherwise it is not possible to have label state. With the IGP flooding machinery we can reach nodes not directly adjacent.
- … how does this work? Today we have more segments. The middle segment here can be an explicit path brought up by RSVP, or it could be a stacked together LSP brought by the IGP extensions that Stefano and others are proposing.
- … we have here 3 segments. LDP, RSVP, and RSVP. In fact, if one really wants to describe an explicit route, it just needs to track the dependency of ingress-egress pairs. If there is one that matches the constraints, use it. Before we used to have a cSPF machinery, put all the requirements, and comes back with a result. Here, skips the last step and looks into the IGP or RSVP database finding snippets.
- … if we draw a comparison, and try to translate, here’s the rosetta stone for that: segment is nothing but an MPLS label adversed by intermediate point. segment list is MPLS segment stack, and advertising in OSPF/ISIS is using that as segment distribution.
- … in summary, we do not think that there is a need for further architectural documents to describe segment stacking. We want to use segment stacking to build segments using the existing architecture
- Questions:
- Greg M.: I think the second buller is not correct, special purpose label do not respond to segment.
- Hannes: It can be a service.
- Greg: No, OAM.
- John: Are you saying that every label stack is not a label list?
- Greg: No, not every element.
- Peter L: How do this apply if my labels are IPv6 labels, do you have more slides?
- Hannes: This is about label stacking for the MPLS data plane. It is not about how to introduce source routing for IPv6.
- Stefano: In segment routing a segment can also identify an OAM instruction, or any instruction. Just for the analogy. Here the idea looks like an improvement because you improve scalability, but why don’t you go to the next level and get rid of RSVP in the core?
- Hannes: It does not need to be RSVP only.
- Ed: Sorry, I am not really sure I agree with that. Getting rid of RSVP in the core has a lot of benefits.
- Hannes: OK, but my question is getting rid of RSVP also imply getting rig of explicit router paths. RSVP is an example
- Ed: I was addressing your verbatim.
- Dino: If you already have labels in the IGP, you do not need them in the RSVP, why extra protocol? That was Stefano’s point.
- Hannes: The proposed protocol extensions are not a full stop replacement of RSVP or LDP. They are a partial replacement, at least we see a shift of functionality.
- Stefano: No, but let’s not argue. In this case you reduce state from the core but you do not remove it. My comment is that you need to remove state from the core.
- Himanshu Shah, Ciena: You mention Traffic Engineering.
- Hannes; No, I mentioned Explicit Routing.
- Himanshu: OK, how does a router know that a set of nodes have become extremely congested?
- Hannes: Rob had mentioned that he will build on extended IGP metrics. Allows to inject into the TE control plane.
- Jeff Haas: It is worth pointing out that you could get rid of RSVP, or LDP, etc. RSVP does more things than just CPU cycles, and in some cases you need to have these things interoperate.
- Ed: Yes, you could replace RSVP, and PCE extensions, or alternate with BGP single label + Flowspec.
- Hannes: Is the topic if we can replace RSVP?
- Ed: It was your statement.
- Hannes: For centralized, yes, for distributed no.
- Rob: The point about can you remove RSVP. You have engineering demands, something has to keep state. It does not matter to me if it is in RSVP or a controller. My point is that we do not deploy RSVP because we cannot make it scale. TE requirements are not about scale. If you can do that in a stateless case, you would do that.
- John: Hannes talk is not about replacing RSVP.
- Hannes: Happy to talk about it later on.
- Ron Bonica: There are two conversations. One is in this minimal architectural framework versus the bigger architecture docs, the second is about replace RSVP. I want to talk about the former, which architecture is better. We should run the use cases through the architectures, and see if both pass, then we can invoke the smaller.
- Wim H.: If you look at the SR architecture document form Stefano, there are things not in RFC 3031. Node segment IDs representing multiple nodes. 3031 you have limited scope on node. Some things are not represented in 3031.
- Rob: Response for Rob. To me this is not a replacement. To me, this is the part of the MPLS part of the SR architecture.
- Hannes; Exactly, can we get away from the architecture in MPLS. We put the diligence of lawyers figuring out what’s defined and what’s not.
- Ron B: It may be that there are concepts that are not in 3031, but the question is whether you need those to address the use cases we hard today.
- John: Thanks everybody.
o Segment Routing Fast Reroute
http://tools.ietf.org/html/draft-francois-sr-frr
Bruno Decraene 10 minutes
- Bruno: Presenting the Fast ReRoute Use case. This was presented in Berlin.
- … this use case already documented in a draft.
- … SR is directly applicable to these: first to remove LFA, get rid of t-LDP session. An extension is directed LFA.
- … now going further. SR can use any number of nodes. What we are proposing now is FR from PLR to destination.
- … First step is to compute the post convergence path, regular SPF, not new topology.
- … So step two is to find the closest Q-node. There are four algorithms in the draft depending on link protection or node protection, or per next-hop of per-prefix.
- … P node is the node that we want to reach. First we need to compute three SPT. SPT new. I use the green color for the new topology, and red for the old topology.
- … we need to compute RDnew, which is the distance from old. FDold is SDold minus SFold. How can we get SD and SF? From SPT old.
- … now, RDnew, it is SDnew minus SRnew, because by design we enforce the new shortest path.
- … now we know that it will use F to reach D. We will compare the shortest path. We are going to compare the path via F is FD. So if RDnew, R isn’t going to use F.
- … the shortest list of segments to reach Q. P zero. We compute again, recurse, we call it P1, and so on. In most cases in our simulations we get 99% of cases.
- … so we call it topology independent FRR. Provides 100% coverage for link and node protection. If your metric is based on delay, it is the shortest delay path. Best path per IGP metrics. And typically provisioned with enough capacity.
- … it is policy friendly by default.
- … Sorry we missed the deadline.
- … So now, how much is this solution applicable? Directly applicable to Node Segments (SR), MPLS/LDP, and IP/IGP FECs.
- … for SR adjacency segments is more complex. We cannot protect the adjacency because it is one per segment. We push F in order to enforce a route to F. We have two solutions. Directly applicable to people using TE.
- … Questions?
- … it is a bit “math”.
- Questions:
- Alvaro: Anyone? questions, comments?
- Hannes: LFA, remote LFA, this seems like approaching light speed, the closer you get, the more exponential the number of energy you need to put. One suggestion: if the link is going down and queuing that constrain the cSFF and pushing the label stack.
- Bruno: That’s exactly for node protection. But we are not enforcing, we are using the new path.
- Hannes: So that’s for node protection?
- Bruno: Yes, exactly.
o Segment Routing MPLS and SR/LDP Interoperability
http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-mpls
http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-ldp-interop
Stefano Previdi 10 minutes
- Stefano: I am back. This is SR with MPLS. We took it out from the architecture to have the architecture completely data plane agnostic.
- … Segment in MPLS dataplane is a label. Obviously there is interop between SR and LDP/RSVP, documented is the LDP one.
- … the improvement of SR over MPLS is the ability to do ECMP. And obviously no state in the core.
- … the operations are PUSH, POP, SWAP, and we have equivalents.
- … So LDP and RS interop, here’s a nice example. You can see from the advertisement from right to left, you can see the LDP advertisement goes into the LDP neighbor, and we use a functionality from SR introduced to IGP which is called a mapping label. So a node can add on behalf of nodes that do not support SR. So all routers will learn the mapping between F and label. And the SR/LDP capable nodes will translate with LDP label. It is just a ammeter of constructing the right label in the FIB.
- … which means that the introduction of SR into an MPLS network is smooth, you do not need a forklift upgrade.
- Questions?
=====
- Alvaro: That concludes the first half, going into the second half.
- … for the remaining presentation we would not fit them all, but please cut your presentation by a minute.
o Signaling Entropy Label Capability Using Interior Gateway Protocols
http://tools.ietf.org/html/draft-xu-mpls-el-capability-signaling-igp
Xiaohu Xu 5 minutes
- Xiaohu: It’s about signaling EL using IGP.
- … a new TLV in the opaque LSA will advertise the RI, and a new sub-TLV is defined.
- … thanks
- Questions:
- Ed: I question its utility. If you add a new sub-TLV you already have. If you do it with PCE, you have by PCE nego. So why?
- Xiaohu: This is to advertise EL capability.
- Ed: But, why?
- Someone from Juniper: It is different to handle EL as egress versus transit. Need to distinguish those two capabilities.
- … there was also a discussion on label size, you probably need to advefsize that.
- Xiaohu: How many labels has been discussed but we decided we want to advertise the issue in the next draft, and we can come back.
- Rob: I do not understand why signal. If nodes can hash, then they do hash.
- Xiaohu: The segment routing use of label stack.
- Rob: Fine, but the LSR can only look four labels deep, so you build a different stack?
- Greg: You cannot do it in one lookup.
- Alvaro: Great discussions, although we cannot hear it. Keep in mind that extensions for things that already exist are not done here. It’s good to socialize.
o Entropy labels for source routed stacked tunnels
http://tools.ietf.org/html/draft-kini-mpls-entropy-label-src-stacked-tunnels
Kireeti Kompella 10 minutes
- Kireeti: Did I actually signed up for this?
- … so, umm, ah. so, uhmm.
- … RFC 6790 says use EL for load balancing. Because in the middle of the network you do not have context of what’s going on. So you add an EL to the Tunnel Label. Then the transit LSR should use this label stack for LB.
- … what happens with SR or SPRING or STATUS is that you have very deep label stacks, and you want to try to put an entropy label in there… some people say you do not need to use EL with SR. But you still do, for a couple of reasons. You have LAGs.
- … so we looked at three ways of doing this. Single EL for the entire stack. You have this ELI/EL really deep in the stack that you might not be able to use.
- … another way to do it is the idea from 6790, which is every tunnel adds EL/ELI. You might not want to do that.
- … the last one we did is adding ELI/EL after, so then you re-use after the pop, by pushing under the next tunnel.
- … that magical operation might be difficult for some hardware, but that’s a detail.
- … Another is at “readable stack depths”. To do this, you have to know how many labels each LSR can process, so I think that’s what was being mumbled in the previous presentation.
- … so there are other work related to EL. The first question is: do we want good load balancing with segment routing. And if you do, how do you want to it? None of the methods here are really ideal. So I think that answering the first question is important. If we do, we need to pick the least of all evils.
- Questions:
- John: Does anyone want to speak in favor of *not* using entropy? Then we can see which one.
- Stewart: Is there any danger of misinterpreting labels for a router?
- Kireeti: We have ELI
- Stewart: What does a router do if it does not understand ELI?
- Kireeti: Drops the packet.
- Sam Aldrin: How are you going to ensure the explicit path?
- Kireeti: So, it’s not an explicit path as people has said many times. You have node labels where you can get from a point to a point far away. Or you can have a adjacency labels. You can use the entropy label in either of these cases.
- … if these are the exact set of links and none have LAGs, then in that case EL is not interesting.
- Sam: You can figure out how to go from point A to point B.
- Kireeti: Yes, that’s why it should not be called explicit path.
- Ed: It’s a loose sourced explicit path.
- … I have a comment here. We are talking about intermediate nodes, maybe older hardware that cannot use EL. Versus older HW that cannot understand EL. How do you negotiate?
- Kireeti: We would guess it, we do not have a context to know if the last label is an PW label, or a VPN label with IPv4 directly below, or others. We used to guess it, sometimes get it right, sometimes not.
- Ed: I am not against. Probably good idea, probably necessary, but you are not solving the whole problem. Unless you are finding out depth in the stack advertised, you are not solving the whole problem.
- Kireeti: Moving it closer to the top, means it is associated to the tunnel. But now with SR, it is not so accessible.
- Wim H.: I believe EL is required, the question is how in the architecture get to a solution.
- … the worst case I’ve seen is 8-9 labels, excluding entropy.
- … I’d like to understand which of the 3 proposals you suggest. My preference is the 1st one you presented. Needs more feedback on if it is possible of feasible. How do we choose?
- John: Let me propose that Entropy is not a bold-on, it is a key architectural element that needs to be covered in the architecture document. There;s a proposal on the table and interested parties.
- Ed: Tangential comment — people are very optimistic on the number of labels that can be pushed. I heard 10, and I won’t throw numbers but seems like high.
- Kireeti: There are 3 proposals. People are talking about optimizing the label stack. If you reasonable expect to push 5 labels, maybe you can push 7, then you can use this.
- … John asked the question about whether we care about Entropy but then answered that it is fundamental.
- John: We need to answer that on the list.
- Mark Townsley: If we are taking EL more fundamentally into the SR architecture, might we get rid of the ELI?
- Kireeti: No.
- Mark: Think harder. We might be able to.
- John: The charter says do not tinkle with existing databases.
- Ross C.: I will take my comment to the list.
o Analysis of the Overhead of Source Routing in SP Networks
http://tools.ietf.org/html/draft-ashwood-sdnrg-state-reduction
Peter Ashwook-Smith 5 minutes
- Peter: Kireeti gave me a good segway to this meeting.
- … rather than had waving about what we heard in Berlin, I asked for data. Four SPs replied and gave me 7 links.
- … I was able to compute BW increase and overhead, and produced a little plot.
- … this is a worst case, which might not be a case, but it gives you an upper bound.
- … I won;t go over all diagrams, but the two upper most charts are more interesting. 40% of packets are under 100 bytes, but that’s less than 5% of the total bandwidth. Most of the links have these characteristics. One of the links which is a mobile backhaul with PW has much smaller packets.
- … if you take this data and extrapolate, these are the curves you get. The 12 byte overhead, it would impose 2-3 % overhead, and max 6%.
- … obviously this is small amount of data, but better than handwaving. Hopefully people find it useful.
- Questions:
- Ed C: This is useful. I’m glad you are doing it. My issue is my sample size.
- Peter: I look forward to your addition to the sample.
- Ed: It is dependent upon time, etc, etc,.
- Peter: Yes, one is very coarse, one is very granular. And if another SP wants to contribute we will use it anonymously.
o Usecases of MPLS Global Label
http://tools.ietf.org/html/draft-li-mpls-global-label-usecases
A Framework of MPLS Global Label
http://tools.ietf.org/html/draft-li-mpls-global-label-framework
TBD 10 minutes
- Zhenbin: First is global label. Three uses: First Identification of the location, second, identification of the service, and third, identification of the Network
- … For the identification of the location, we have VPLS multicast over MP2MP LSPs, segment based EVPN, and MPLS OAM for LDP LSPs.
- … For the identification of the service, local protection of PE node.
- … and for the identification of the Network, MPLS network virtualization mechanisms based on MPLS Global Label
o Framework of Network Virtualization Based on MPLS Global Label
http://tools.ietf.org/html/draft-li-mpls-network-virtualization-framework
TBD 10 minutes
- Zhenbin: Here we introduce the framework.
- … What label should be used for MPLS Global Label? Two options, use the traditional MPLS label range, of resolving conflicts between global and existing label range, proposing a mega label.
- … this is the control plane mechanism. Here’s the steps. It is better to be allocation from a central control point. The controller can share MPLS global label range for all nodes.
- … it can send the label request to the controller, then the global label mapping message is received and installed.
- … there are different applications. The first one is BGP-based, the second one is IGP-based, and the third one is PCE-based.
o Advertising Global Labels Using IGP
http://tools.ietf.org/html/draft-xu-rtgwg-global-label-adv
Xiaohu Xu 10 minutes
- Alvaro: You have 4 minutes…
- Zhenbin: Next. Background, Virtual Operators want to use virtual network to deploy services. They do not want to know the details of the physical network. Based on this we have this doc.
- … here we implement the MPLS virtual network. This is the physical network operator. There is an IGP controller and IGP client. There’s a central IGP controller. And there are virtual network operators that can have virtual network topologies.
- … here we can see an example. The MPLS Global label identifies the topology. You do not see the details of the underlying network.
- … We have this draft in ISIS, and we ant this solution for failure solutions.
- … we propose these attributes for a virtual link.
- … this is the forwarding in the virtual network. We have the virtual link, virtual node, and virtual topology.
- … We want to build the global label for muti-topology FIB.
o Wrap:
- Alvaro: We have one more presentation.
- People shouting: We saw this one already.
- Alvaro: Actually, don;t leave…
- … there seems to be consensus that we can leave now.