OSPF WG - IETF88 Chairs: Abhay Roy and Acee Lindem Scribe: Alia Atlas (akatlas@gmail.com) During administrivia, discussion on draft-ietf-ospf-ospfv3-autoconfig Stewart Bryant: What do you do if you can't resolve on that (which router has been up longest)? Acee: Then you go to the actual hardware footprint. Les Ginsberg: I know we haven't written this, but we did agree that there would be some minimal interval, but... Acee: It's easier if it's absolute... Les: Review after discussion Stewart: Well worth spending time and maing it clear. Acee: draft-ietf-ospf-te-metric-extensions new draft expected soon. Alia Atlas: Yes, it will have the link bandwidth added in. =========================== OSPFv3 LSA Extendability: David Lamparter: First a clarification - you never mix the old and new in the calculations? Acee: In the mixed mode degraded, you would mix them. The routers that were supporting the new mode would use the new ones, but they might have links to routers that don't. Peter Psenak: During the calculation, you only use one or the other - never both. Acee: We can discuss this on the list. We might want to take this mode out. You need to use both of them in the mixed mode - otherwise no point. David: Using the old and new style together or use both but then need to force down to mixed mode degraded as soon as a new router comes in. George Swallow: It seems like a malicious sender could mix and send different metrics to cause loops. I haven't thought it all through yet. Acee: We'll talk about it on the list. It may be that the mixed mode doesn't make sense. You would have to use the new one if it existed and, as a fallback, use the old. Peter Psenak: Which one do you want to get rid of? Acee: The middle - advertise both old and new and use the new if available. At least I'll clarify it. David: Currently we're not advertising the entire area and ... should be able to detect misconfiguration. Acee: You know your direct adjacencies and whether they support it or are in the wrong mode. I want to provide backward compatibility but without providing all this complexity. People love them from a protocol compatibility but not from a deployment. Lot of complexity to carry forever. =========== OSPF and OSPFv3 Segment Routing Drafts: Robin (Zhenbin Li): Before we discuss about the extension of the IGP for segment routing, we should understand the purpose of IGP for segment routing. You propose two extended attributes to the prefixes. Do you think that the ERO is a prefix? Do you think the fast-reroute are also a prefix? Peter: In the current draft, these are bound to a prefix. Robin: I don't think so. If you only think this is a single extended link, perhaps. But you say this is a prefix. Acee: These are good comments, but I think you are questioning the basic segment routing architecture - but this is protocol extensions. Peter: If you are questioning the architecture, you should be questioning it in SPRING. Hannes Gredler: Of course, we may have been confused, but there is one thing and both Peter and I come from the BGP-LS where we put in good focus on the namespace. We focused on what should go to a node, to a link, and to a path. Andrew Logan: Let's discuss architecture where the architecture is. This is discussing how to fulfill this. Andrew Li: There are inconsistencies between the ISIS and OSPF extensions. The traffic SSD can be global or index... Peter: Bug in presentation - same in drafts Andrew Li: Extensions are separated from reachability, but not in the ISIS draft. Peter: We have no choice. Andrew Li: Propose to use a separate TLV to support reachability. Peter: But then you should be talking about this in ISIS. Protocols can be different in doing an architecture. Andrew Li: I know - it's protocol-specific but better to provide similar features. Last comment, extension includes address family. Are you going to use AF to advertise IPv6 prefix? Peter: Don't need it now but in the future you could. More useful in the future. Huaimo Chen: Why don't you just use existing LSAs (opague). Acee: I can answer that. A looong time ago we were going to extend OSPFv3 and leave OSPFv2 alone due to the deployment. This augments the base. Because we're not touching the base route computation, we don't have the same concerns that we have with OSPFv3. So, we can introduce the segment routing LSAs and not have the backwards compatibility with the base. Acee: OSPFv2 is from 1992 and is fixed format. Huaimo: but.. Acee: As WG chair, I like this way of extending OSPFv2. For OSPFv3, we're more open and can evaluate what makes sense. Huaimo: But we could add it in the TE opaque. Acee: but those are for TE Peter: but that implies the link is to be used for TE. It is defined as a TE topology element. If you advertise it and don't want it to be in the TE topology, you can't do it. Also, TE advertises links not prefixes. Huaimo Chen: I think it is more efficient. Acee: Backwards compatibility is more important than efficiency. Peter: We'd have to redefine the opaque LSA - it's strictly bound to the TE with lots of deployment. Acee: Right, and it comes with lots of link attributes and those aren't needed. Robin Li: Think it is better to be able to use a label stack instead of a label. Today is enough, but for future. Peter: You can put multiple TLVs for multiple stacks. Hannes: right - so let's just repeat the sub-TLV. Hannes: Do we really want to discuss overhead and bit saving on a 100Gig link. Lou Berger: If you want to pass a label stack in the TLV, you can already by changing the length. Different technologies have different sized labels. Acee: We're getting a lot of things using the router information. I'm going to respin that draft so that it can be multi-instance. For things like the node tags. I'm probably going to do that anyway over Christmas. Some LSAs are born great and some have greatness thrust upon them. =========== OSPF Two-Part Metric: Acee: In the past, we've taken things like this and made them experimental when they've applied to this specific radio environment. That could also give you more freedom too. Jeffrey Zhang: I am open to that, especially since you reminded me of the compatibility issue. However, this is not a big change to the general concept (we’re just adding a cost to the network vertex in the topology graph), and the compatibility issue can be resolved by using a flag bit in the Network LSA’s Option field instead of a new Link Type. Acee: This problem could also be solved using a P2MP interface type. Jeffrey Zhang: If anything changes, then everyone has to update their LSA. I think this is a really useful optimization - especially in some networks. =========== Architecture for Centralized IGP Control: Acee: Is there one instance of the IGP in the controller or in the clients? How many instances of the IGP are there? Robin Li: In my view, there are two. One between the controller and one between the clients. Acee: Oh, they're running IGP too. So you're doing SDN using IGP flooding? Lou Berger: A little confused by what you're talking about. I'm now more confused. If everyone else understands, (nope) - ok, so Acee, your... Ok - we flood state via the IGP. Huaimo Chen: Lou: So your IGP gives you your control plane topology?? Stewart Bryant: Is the plan that you're running the IGP so that the IGP controller can reach the clients? And then you're using a different protocol to George Swallow: It sounds to me like you're trying to do what I2RS is doing... Maybe this work belongs over there?? Acee: Maybe it does? We didn't come to an understanding in rtgwg so I was trying to clarify. I just learned this. It's using an IGP to establish the network topology and to flood information beyond the routes. Robin Li: You know we have the PCE for controller but also the IGP can be used. Robert Raszuk: Can I use the existing IGP for the client? Lou Berger: Is the info carried in the IGP completely different or... Robin Li: Please read my draft for clarity. George Swallow: What about BGP-LS? It's taking the link-state and passing it up. Robin Li: I'm just using IGP to collect the local area topology information. I want to use the one protocol. Acee: This isn't really a use-case. You are assuming it is a selected solution and describing how to improve it. Yi: So, it seems to me that you are using IGP as a message pass. Robin: No, no, not command - just flooding state information. Yi: Do you require them to be one hop adjacent? So you are going to require the IGP controller to be one hop away from all the clients? Robin: You can use tunnels. Yi: ... Acee: I think we are going to run out of time with the details of this. What we need to do is discuss why you'd want to do this rather than the details of it. Acee: It wouldn't work that way unless you had a stub area for each client, but that's different... Acee: The OSPF transport instance could solve this problem although it is in no way associated with an OSPF controller. Acee: But this isn't really different from what we have today, is it? Rob Shakir: But the listening to the topology from the IGP is something we don't need any extensions today. I've got it in my network today. So what work are you needing? Acee: Speaking as WG chair, this doesn't belong here. This is use of the IGP not affecting the IGP. I think the discussion we had here is useful. There's a lot of existing things. To get further, it's really necessary to show differentiation and need. Rob Shakir: I'd really encourage a problem statement. This feels like solution. Chris Bowers: It'd be really useful to retitle it as something like "Use-Cases for IGP listening" because we all spent the first 10 minutes trying to understand where the control is. Acee: Thanks, because that still wasn't clear. ================= SPF Extensions for MPLS Green TE: Alia Atlas: We talked about it in rtgwg a couple IETFs ago and consensus was that even the requirements and need the research in RRG. Robert Raszuk: probing into what would be sent for a link... Acee: (cutting off Robert) I was in the rtgwg marathon session and agree that it needs research and problem statements. ================= Topology Transparent Zone (TTZ) drafts Acee: One comment before we go on. Most of the IP RAN networks that I've seen look like hub-and-spoke and not like this with an internal part that can be hidden. Huaimo: We generalized a bit. Stewart: How many OSPF nodes? Huaimo: That's a good question. Acee: But one node can support millions of subscribers - at least ours can. Acee: Please show how it works specifically for IP RAN. Huaimo: For example, in China Mobile, there's 3 levels and then when they grow the network, they split the network. I think that TTZ provides an option to resolve the issues from splitting the network. Acee: Getting more discussion on the list. Speaking as a WG member, I'm not convinced this accomplish the stated goals. Robert Raszuk: I have seen similar problems handled by splitting into multiple ASs. What's the problem with using BGP to interconnect? Huaimo: This is different. Some providers have just one area. Then there's large growth and they have to split areas. We still have one area backbone and then the non-backbone has to connect to the backbone so there's significant architectural change. Acee: (WG chair hat off) That usecase was presented before. I'm not convinced that TTZ solves the problem. If it were the same people, it would have taken them the same year. If you have something on paper, it can always look better. If you had a real story - have prototyped and shown it. Huaimo: Maybe we can show with prototyping to showcase TTZ. Acee: I could be more convinced. Huaimo: With multiple areas, routes have to determine which ABRs to go through or you can use PCE to compute the paths. So, with TTZ from source to dest is easy. Peter : You are trying to present a case where a network got into a problem and needs to solve it. This seems like a design issue. Huaimo Chen: That's a good question. Better if they had a crystal ball and could see the future. Some things they can see 10 years ago but some things not. We also have real providers in China. Acee: Now that would convince me - if you brought a provider who implemented TTZ and found it solved this problem, but I don't think you'll find it. Stewart: Has it been built and deployed? Huaimo: No. Robert: What about areas? Huaimo: Multiple areas can work, but then you have interruptions but then more configurations. Robert: So, instead of splitting areas, you'd like to see areas acting like bubbles and popping independently? Huaimo: it's the right model. Acee: We'll discuss it on the list - and I'll explain why I don't think it will solve the issues. ============ Bonus slide: OSPFv2 Security Extension