IETF-104 Wednesday 11:20am LSR WG Session 1 1) Administrivia - 5 minutes - Blue sheets - Scribe/jabber - Jabber room: lsr@jabber.ietf.org 2) WG Status Update - 10 minutes - Acee/Chris Acee: We’ve been waiting for the update of H-bit support doc. Padma: The authors agree to update the doc this week. 3) Update to LSR Dynamic Flooding - 15 minutes - Tony Li https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/ Dave Allen: Do you have diameter of the flooding topology relative to the original graph? Tony: Implementation specific, we do have a diameter constraint in ours. Acee: You wouldn’t want to do anything on the LAN, you don’t want to change that. Would it be algorithm specific? Why do you need to put all? Tony: The question is whether or not we specify LAB in the flooding topology? 4) Update to IS-IS Spine-Leaf Extensions - 10 minutes - Les Ginsberg https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-spine-leaf-ext Les presenting. Chirs H: You had leaf-leaf support long time ago. there seemed to be looping options, did you see it and address it? Les: Yes. I'll talk about it more. Chris H: The earlier version seemed to have some loops with metrics and default is this no longer the case? Les: We never talked about overload before, that probably will address the problem -- need to double check. Acee: I haven't read the update. the overload bit, the leaf still connected will set the overload bit. Les: This is not meant to be dynamic. Acee: Understand now. I thought it would change dynamically. Acee: I'd advice everyone to read it. this is a big change. Acee: One reason we adopted it was it was meant to be for data center and simple. I hope it doesn't get too complicated. (11:54) 5) Update IS-IS Invalid TLV - 10 minutes - Les Ginsberg - https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-invalid-tlv Les: Ready for WG adoption. Chris H: Anybody in the room disagree? None. We'll ask this on the list, seems obvious though. (Target: 12:05 Actual 12:00) 6) Update to IS-IS SRv6 - 10 minutes - Peter Psenak - https://datatracker.ietf.org/doc/draft-bashandy-isis-srv6-extensions Peter: Wwe think it's ready for WG adoption. Acee: Gow many read the draft? How many are following SPRING about the adoption of SRv6? We'll do the adoption call right after SPRING. (Target: 12:15 Actual 12:02) 7) OSPFv3 BIER Extensions - 10 minutes - Peter Psenak - https://datatracker.ietf.org/doc/draft-psenak-bier-ospfv3-extensions/ Acee: Consistent with doing OSPFv2 and IS-IS extensions also being in BIER. Peter: The adoption call should happen in BIER. Acee: Ut was agreed when BIER was chartered. People deploy OSPFv3 network will need it. Les: So no adoption call here. Peter: Right, not here. (Target: 12:25 Actual: 12:05) 8) OSPF Admin Tags - 10 minutes - Peter Psenak - https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-admin-tags Les: Did we make a conscious decision not to support 64bit tag? Acee: I put a explanation in appendix. Les: Just want to make sure. Stephane L: What's your use case? Peter: I don't have a use case. Stephane: We have sufficient mechanisms. Acee: Did this draft long time ago. I agree with you. (Target: 12:35 Actual 12:11) 9) OSPF Reverse Metric - 10 minutes - Ketan Talaulikar - https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-reverse-metric Ketan: Looking for WG adoption. Acee: How many read the draft? A few. Acee: We will discuss it on the list about the use case. I know it's related with l2vpn, so you don't know the underlay characteristics. Ketan: Yes. Chris H: Anyone object to adopting this? None. (Target: 12:45 Actual: 12:16) 10) OSPF BFD Strict Mode - 10 minutes - Ketan Talaulikar - https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-bfd-strict-mode Chris H: You found incompatibility? Ketan: Yes. Chris H: Is it functionally broken? Ketan: To make it work, both routers need to have explicit configurations. in LAN, there might be inconsistencies. It becomes difficult to figure out. Chris H: You may want to add in appendix the problem description. Ketan: It's not currently in the draft. Chirs H: It's interesting to describe the interoperability issue and how this solutions interacts with them and fixes them. Ketan: Looking for inputs from other implementations and get feedback. Acee: If you get a hello, and it doesn't have the B set. you don't look at BFD. Ketan: Yes. We will need more feedback. (Target: 12:55 Actual 12:27) 11) Updates to Flooding Reduction - 10 minutes - Huaimo Chen - https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/ Acee: I don't think FTC requires scheduler synchronization like SPF because you don't nee to update RIB or FIB, it's internal. Peter: Agree with Acee. You don't need scheduler. Huaimo: It's better to have it. So we have better control. Chris H: I don't like this either. We have got along just fine without specifying timer backoff values, I don't think this is needed. Sue: Two things. One of the deployment of IGP is in IP RAN, some links transceiver get browned out unexpectedly. That's why some of these problems are important. IGP is used to signal this kind of thing for convergence. I suspect only simulation done to look at IGP convergence. Acee: Does it support the mechanism like scheduler? Sue: No. Mine is straight into the problem. There are two groups doing solutions. Mine is theoretical research of not having consistency. It's a common problem. Sue: 2nd question is for Acee. Most open source, whether you should have a scheduler or not, your code has a scheduler when to run it. Acee: He's talking about distributed algorithm. My opinion is the best scheduler is not to have one. The problem is what you do during the transition period. Sue: If you have no scheduler, you may get into problem. Chris H: I was saying this should be not standardized. It's implementation thing. It should not be on the wire. Huaimo: This is not on the wire. It's a TLV. Chris H: If you're standardizing what to use, then that's on the wire. Huaimo: It's an optional TLV. Sue: You put into jitter to avoid synchronization. I don't see this being discussed in Tony's draft. Why? Chris: It's interesting to talk about. If we want to be agile, we don't want to specify it. Sue: We had the problem in the past. Are we going to get into the same problem? Like FRR, they talk about single link failure. Huaimo: I'd like to request WG adoption. Chris H: Chair comment. My expectation with your draft is it should be a standardized distributed algorithm, but it looks like that's now in your appendix. This is talking about more generic flooding thing. I like your FT-bit, this is valuable, but this should go into the generic doc. Why is it specific to yours? Huaimo: For distributed algorithm, every node will compute FT. Chris H: The generic draft is supposed to signaling flooding topology info centralized or distributed. This was supposed to be for a concrete distributed algorithm. Tony's work is a framework, going forward he will need to have algorithms standardized. This should not be just in your algorithm, it's a general useful thing. Acee: You want it to be consistent in both centralized and distributed way. That's why it's general applicable. Huaimo: This is more about distributed algorithm. Chris H: We want the draft adopted to talk about central and distributed. Originally, I was talking about move distributed out of the thing, but that's not where we landed. We landed with a framework, then we were going to have distributed algorithms that were standardized outside of that. When we first talked about in the list, we started from centralized and distributed. That's where the confusion starts. But now the work we adopted covers signaling both cases. The FT bits should go into the general one. Huaimo: You asked us to remove the centralized one. Chris H: Are you disagreeing with the process? It's not Tony's document anymore. it's LSR WG doc, people get credit working on it. We don't want to have two docs. I thought we all agreed on it, we should take it offline. Chris H: for example, if you think your scheduler is needed, it should go into the doc we adopted because it's a generic thing. If your algorithm requres this scheduler specifically, then it should be in your draft. Aijun Wang: I think the WG doc is for centralized solution. but for deployment, the distributed one might be more useful. There are overlaps. I think it's not fair to put it into the WG doc. We should provide different solutions. Chris H: Did you say unfair? We're talking about standards. Aijun Wang: The original distributed solution was from Huaimo's draft, not Tony's. Chris H: We want to separate the signaling and the algorithms. You think we should separate signaling? This is against WG consensus. Aijun Wang: There is overlap. I'm not saying we should go back. We should do different solutions. The current WG doc is for centralized algorithm. Chris H: We should take it offline. Nobody saying no to any of the stuff, I'm just saying it's in the wrong place because we already have a document for signaling. Huaimo: in your request for adoption, you said tony's draft was for centralized solution. Chris H: I said that was a mistake. That's not where we agreed to at the end. Tony had sent an email at some point saying I think we're looking at this wrong, and I said yes, and most people agreed. Tony reframed it as this one is about signaling, and the other ones are about algorithm. I misspoke originally. Huaimo: The adoption was based on your statement. Chris H: It doesn't matter. we should follow the consensus. I understand you're not happy. Huaimo: Happy is not the word to describe my feeling. We've been working hard on it. Chris H: Now we're back to credit. If some of your work showing up in a doc without your name, you can complain. Huaimo: It's hard to get something new into a doc adopted? Chris H: So you're saying is that you think it's too hard to get any new work into the WG doc. This is IETF process, let's take it off line. Acee: We're in a circular discussion. Are there technical discussions? Les: Co-author on the draft adopted. Regarding the FT bit, operationally it overlaps with how we signal temporary flooding. If we decide this is a good idea, we need to decide how to signal it to get both out of it. That's why it needs to be in the same document. Huaimo: These are two different things. Tony Li: The way to make progress in IETF is to send ideas to the list and discuss it. I have no objection to your idea, let's talk about it. Huaimo: Regarding the discussion, I remember it might be Robert that made a suggestion once that the centralized one send a signal to distributed one, the distributed should take over. I don't remember details. Sue: I'd suggest to take it offline. Acee: Let's discuss the scheduler and FT bit separately. Acee: Please read the drafts. I'd recommend you read Sue's draft. The packet slicing draft will be presented, but should belong to TEAS. Chris H: Please take a look at ethpad and make sure your comments are there. Thursday Meeting Target: 16:10 Actual: 16:17 12) OSPFv3 Extended LSA YANG Model - 10 minutes - Acee Lindem - https://datatracker.ietf.org/doc/draft-acee-lsr-ospfv3-extended-lsa-yang/ Chris H: Do we have this is ISIS? Acee: No, ISIS is always TLV based. this is specific to OSPF. Chris H: So, WG procedure-wise, should we require future TLVs to also augment models? Acee: At some point, you can batch them. It could be painful to do one at a time. Jeff Hass: For things you know you should specify them. Chris H: What happens if it's done through augmentation? Yingzhen: This would lead to many tiny modules but easy to keep track of. If we do batching, might be harder to keep track of all features. The WG needs to make a decision. Chris H: Not sure it's worth worrying about, maybe. Jeff Hass: Same issue we have in the BGP. Acee: We didn't really agree with what the base. We did take SR out. Jeff H: Don't make modules so small. Add in all the state you can at the time. Better use examples. Acee: We'll put in examples. Chris H: What happens to the "unknown tlv" nodes when they become "known" through augmentation? Acee: I know what should happen but we should document. Chris H: Let's take it offline. This is a NETMOD/YANG question, and I'm not sure it has been answered yet. Target: 16:20 Actual 16:30 13) Packet Network Slicing using Segment Routing - 10 Minutes - Ran Chen - https://datatracker.ietf.org/doc/draft-peng-lsr-network-slicing/ Acee: This has lots of touching points of many WGs. This is leveraging the intra domain, flex-algo, this is different from VPN+ is that it's using data plane by using different algo. Ran: The advantage of this solution is it's easy to achieve inter domain. Acee: This might be the last time that this is presented in LSR. Jie: The mechanism is overall in line with VPN+. This is more SR focus, maybe you can take a look at our solution in SPRING. You introduced new identifier, maybe something existing with extension can be reused. Acee: This is the question for TEAS. Ran: This is more general solution. I'll do the presentation at TEAS and collect feedback. I know your VPN+ draft, but it's complicated for inter-domain case. Jie: You mentioned to use SR policy. But SR policy is initiated from the headend. How do you use this info in the transit node? Ran: I’ll update the draft to clarify. Acee: The proposal was to add to OSPF and IS-IS information. Vishnu: You’ve presented in TEAS. Please take it to the list. Sandy: This doesn’t conflict with multi-domain. This API is easier for inter-domain case. Target: 16:30 Actual: 16:40 16) IPRAN Grid Ring Topologies Flooding Use Case - 15 Minutes - Sue Hares - https://datatracker.ietf.org/doc/draft-hares-lsr-grid-ring-convergence/ Uma: This is IPRAN topology, but 5G RAN is all L2 network. Sue: This is not 5G. Acee: You talked about ring, then you show GRID. Sue: All those rings are hang off those Grids. Uma: You should add l2 into it. Sue: Want to join the effort? Uma: Yes. What about FRR for multi failures? Sue: You may want to have fast convergence before FRR. Uma: If you separate FRR, there are other cases that may benefit, like multiple failure handling. Acee: This is a good topic to take to the list. Sue: Yes. We'd like to continue the discussion. Target: 16:45 Actual: 16:55 14) Hierarchial IS-IS - 10 Minutes - Tony Li - https://datatracker.ietf.org/doc/draft-li-hierarchical-isis/ Chris H: You have to specify how you do areas. How to you interact and divide? Tony: There is no obvious way. The obvious way is through configuration. one comment from Les and Paul is nobody knows what SAP hey? They suggested area identifier, and we will discuss once we have a proposal. xx: what's the reason not to use BGP? Tony: BGP is meant to interconnect domains. We're trying to scale up ISIS within one AS. BGP is not meant for one domain. Acee: Any other considerations for backward compatible? Tony: There should not be interoperability issue. We've fixed bugs, no more inter PDUs. Tony P: Is there going to be a lessons learned session at next IETF? Acee: It looks like simple extension, but it's not. Chris H: I can do another 4 hour. Tony P: I'll prepare for it. Rajiv Asati: Thinking about the problems I've run into, this rings a bell. With hundreds of routers, scale becomes an issue. it's nice to extend level 1 across hundreds of routers. Tony: There are upper bounds in one area. used to be 1000 in 90s. So the idea is to scale up, to bump up the isis limitation. Rajiv: It makes sense to scale up with reasonable convergence. Acee: How many read drafts? about half. How many would like to have multiple levels? How many operators? Tony: I'll ask for WG adoption after next revision. Chris: Have you done simulations? Tony: No. Chris H: I'm curious about adjs on LAN at every level. Tony: I don't think there is a problem because there are going to be separate PDUs on every level. Target: 16:55 15) IS-IS Area Abstraction - 20 Minutes - Tony Li - https://www.ietf.org/id/draft-li-lsr-isis-area-abstraction/ Acee: Why not full mesh tunnel? Tony: Flooding issue. Huaimo: We had TTZ drafts on the same topic. We had several options, group several nodes, or full mesh. we need to have a discussion. Tony: Please hold it in 3 slides. Cengiz: Ysually networks are hierarchical. I like your first proposal. This is also about scale? re they competing? Tony: I like both. They're different tools. Cengiz: Maybe your first proposal is good enough for 20 years. What about topology? Tony: This is intentionally topo agnostic. Rafal: Can it be anything other than isis? Tony: Yes, similar mechanisms can be used in ospf. Rafal: Us there interactions between levels? Tony: Yes, there are some. You have to level 1 to distribute info. Acee: You need send L2 info over L1. Jeff H: What happens if you partition? Tony: You're right. IGP don't like area partitions. There have been solutions for that. I'm not trying to cover it. David: I did look at similar ideas several years ago. Acee: OSPF does have primitive version of the virtual link. IS-IS is simpler because it has only one level-2 area. David: I know the idea works. But did you see how much you save? I'm not convinced at reducing flooding is worth the extra hassle. Acee: From ospf experience with virtual links, you could have leaded the L2 prefixes into L1 then use routing. That will handle partition. David: That's what I did with partition. Tony： tTe problem we have if we keep carrying on, level 2 will explode. David: if you start hiding level 2, are you expecting it become arbitrarily large? Tony: Yes. David: I'd like to see how much it saves before I'm convinced. Tony: We already have uses cases that gave up IGP. we go real scale problem. David: This is large change. Have you considered level 3 and up and leave level 1 and 2 as it is? Tony: I'm not scared of changing this in level 2. John Scudder: This is fun. not sure whether it's useful, but definitely fun. Each level is modeled as a router. What if partition happens, then it will become two routers. So there will be area leaders. Is there something along that line or TBD? Tony: It's TBD. It's better to have a tunnel rather than 2 routers. John: How do you flood across? Tony: Flooding through area leader is the key. John: So I'm just not exposing it? Tony: Yes. Difference between TTZ Tony : We should combine. Let's talk offline. Tony P: Is TTZ an RFC? Tony L: No, it's still a draft. Chris H: In OSPF, TTZ is experimental RFC. Tony P: One difference. They don't try to make an area look like on router, that needs to be resolved. Rajiv: The square box don't need to communicate with others? Tony: The square boxes are L1 routers, and they don't have visibility outside of their own area for communications. Those things do exist. Rajiv: Only circles have reachability? Tony: The reachability is still there. It's about what's in the database. Tony P: TTZ was to carve out something that's not area boundary and made it hard to do anything else. If you leak prefix, you could make it work. Alvaro: I'm one of the authors of TTZ draft. The right thing to do is to work on this together. Let's talk it offline. Peter: Virtual link is mentioned. It was meant to fix a bad network design. Tony: Yes, we are trying to fix the hierarchy that was not optimal. This might not be the perfect solution, but we're trying to get somewhere. Acee: I didn't understand all the details until today. Tony: If I understated something, I apologize and please comment. Sue: I thought the writing was easy and clear. Chris H: From a chair stand point. we decided not to do TTZ. I'd be interested to know what changed. Why do we need it now? Tony: I'm interested in this because of a real customer issue. Acee: The area borders are the L1L2 routers, but you only see them as L2 routers. Tony: Happy to add clarifications about the one big router. Cengiz: SPs typically don’t like complicated stuff. I like the multiple level solution. This is one is more complicated and implementations will be buggy. We need feedback from SPs. Chris H: Did you have an example in the draft? Tony: Yes. It has to be more general. Robert: If L1 has only default routes, it works well only when L1 is stub, not transit. What about suboptimal in L1? Tony: Yes, but that’s orthogonal. Acee: Isn’t that a network design issue? Tony: Yes. Rajiv: What’s your scale result? In terms of nodes. Tony: that customer wants the entire world. John: This can happen recursively? Tony: Yes. Acee: Please have a discussion with Huaimo and Alvaro. Chris H: Please send in your requests for IETF 105 early. thanks.