Minutes IETF101: lsr
minutes-101-lsr-00
| Meeting Minutes | Link State Routing (lsr) WG | |
|---|---|---|
| Date and time | 2018-03-21 09:30 | |
| Title | Minutes IETF101: lsr | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2018-03-28 |
minutes-101-lsr-00
IETF LSR WG Meeting Minutes Scribe: Yingzhen Qu (yingzhen.ietf@gmail.com) Time Slot (150m): Wednesday, March 21, 2018 09:30-12:00 GMT o 09:30 - 15m - Intro, Adminastriva, Document Status Presenter: LSR Chairs (Christian Hopps, Acee Lindem) o 09:45 - 5m - YANG Model Update Presenter: Yingzhen Qu Document: https://datatracker.ietf.org/doc/draft-ietf-isis-yang-isis-cfg/ Document: https://datatracker.ietf.org/doc/draft-ietf-ospf-yang/ Acee: Will start design team meeting on IS-IS Yingzhen: Need YANG doctor review for IS-IS Chris: Why didn't we change BFD in IS-IS YANG at the same time? Need to push IS-IS document faster - make IS-IS draft equal priority. Would like to see it complete before next IETF o 09:50 - 10m - OSPF Reverse Metric Presenter: Ketan Talaulikar Document: https://datatracker.ietf.org/doc/draft-ketant-ospf-reverse-metric/ Chris: Use case 1 can be done simpler. For example, if a router is connected to fiber and the receiving signal is bad, it can tell it's neighbor by sending neighbor a high metric. Ketan: yes Shraddha: Use case 1 you have to use two parts metric, right? Ketan: yes, in the next slide. Himanshu Shah: How do you do revert metric to original? Though TLV? Ketan: yes. Acee: how many read the draft? We will discuss it on the list. o 10:00 - 10m - IS-IS Extensions to Support Routing over IPv6 Dataplane Presenter: Les Ginsberg Document: https://datatracker.ietf.org/doc/draft-bashandy-isis-srv6-extensions/ Les: Ask for WG adoption. Chris: How many read draft? How many want it not to be WG doc (none)? So no one didn't want to. Acee: The SID size is 128 bits? Les: There are potential uses for shorter lengths, not decided yet. Acee: It's not installed in the routing table for forwarding, right? Les: You use it in packet. but in SRv6, one SID may cover reachability for other sids. o 10:10 - 15m - IS-IS TE Attributes & OSPFv2 Link TE Attribute Reuse Presenter: Les Ginsberg Document: https://datatracker.ietf.org/doc/draft-ietf-isis-te-app Document: https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse Les: Request early allocation of code points. Acee: Strong objection? (NO). We will take it to ADs. At least for OSPF, it's for existing RFC. o 10:25 - 10m - 5306 bis Presenter: Les Ginsberg Chris: Why? What if it gets busy and not restarting? Les: The danger is the neighbor thinks you're restarting. it's supposed to be for a limited time period, 3 mins or 5 mins.. Uma: It's good to write the difference at the beginning. Chris: Why don't we require a change section for all the BIS drafts? Les: I don't remember if I included a change section. Traditionally we put in the appendix. (Post meeting: Checked document - it does not have a change section. Will add it in the next revision). Uma: I have comments on database sync, I'll post it on the LSR list. Chris: have you considered GR without using protocol? Les: This is not to promote GR. If you're using the cool way (i.e., internal redundancy), then you don't need this. Chris: if you continue to send hellos, it should be ok. Les: yes, you can. But there is ack required. Acee: Does ISIS not terminate helper mode when topology changes? Les: We currently don't know on the neighbor if GR is in progress. ISIS doesn't do it, local decision. OSPF terminates GR when topology changes. OSPF ties to Grace-LSA, so you know. Acee: If you know you're restarting, you may abdicate DR. ISIS can do it similarly as OSPF. Les: potential disruption, small amount 10:35 - 5m - draft-ietf-ospf-ospfv3-segment-routing-extensions Presenter: Peter Psenak Document: https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-segment-routing-extensions/ Peter: Ready for WG LC. Acee: Did we do early allocation? Let's take one more pass because OSPFv3 Extended-LSA will soon be published. Peter: Yes. need to change the conflict resolution ref. Acee: I'll do a review. Will find a shepherd. 10:40 - 5m - OSPF LLS Extensions for Local Interface ID Advertisement Presenter: Peter Psenak Document: https://datatracker.ietf.org/doc/draft-ietf-ospf-lls-interface-id/ Acee: How many read this? Anybody think it's not ready? We'll take it to list for sure. Peter: this is simple. Acee: probably LC before ospfv3 SR. o 10:45 - 15m - ISIS Segment Routing Flexible Algorithm Presenter: Peter Psenak Document: https://datatracker.ietf.org/doc/draft-hegdeppsenak-isis-sr-flex-algo/ Peter: One implementation. Would like to ask for WG adoption, may merge into one draft with OSPF Flex Algorithm. Andrew Dolganow: It's not SR, it's IGP. There are use cases talked beyond SR. Have we decided to work on flex algo here? Peter: We use SR as forwarding plane. I agree we can make it more independent. SR related because we're using SIDs. It belongs here because it's IGP computation. Acee: We agree. Tony Przygendia: Echo Andrews's comments. To justify this work, it may affect lots of technologies, it needs to clearly split off SR. Peter: We can talk about how to do it. Uma Chunduri: It has to be not for SR only. One topology could have multiple SPFs, multiple algorithms should separate them. Andrew: Going foward, are we going to have merged docs? Guidance would be nice. Alvaro Retana: Less docs will be better especially there are lots of commonalities. Need to clearly specify the difference. Vendors should conform to RFC. When it makes sense, would like to see less drafts. Chris: We do have ITU connection with ISIS. Tony P: You can have a framework doc, and OSPF and ISIS. Replicating text is not necessary. Chris: We can look at joint things when applicable, actual protocol functions need separate documents. Acee: Granularities are different. ISIS has one LSP. OSPF has more dynamics. Need to be considered when make a decision. Is this a big concern? we'll take it to the list. This one could be a good one to combine. Andrew: Conformance issue with one document for 2 protocols. Mikal Abrahamsson: I would like it to be done. Jeff Tantsura: Separate sessions in RFCs for conformance. Clean separations in subsections. Acee: Encourage to read early. Let's make sure people are happy. Wesley George: It's good practice to do it. The other is what you do 99.9% of time, there might be times wrong to do it. o 11:00 - 10m - Usage of Non Shortest Path Forwarding (NSPF) Ids in IS-IS Presenter: Uma Chunduri Document: https://datatracker.ietf.org/doc/draft-ct-isis-nspfid-for-sr-paths/ Acee: Did you say this going to be advertised by egress? The binding SID is not owned by egress node. Uma: It's not like binding Sid. An option is to have any node advertise. Acee: This is a disconnection between the egress node and the node asserting this. Andrew: This is a problem with too many labels, agreed. This is still shortest path with constraints. I'm concerned by putting this into IGP signaling. this can be solved by binding labels. Once you make an exception, it's opening a pandora's box. Uma: Between labels, it's still shortest path. Overall, all segments together it's non shortest path. Andrew: You still compute shortest path on intermediate links. There is no difference in computing Shortest Path. I agree too many labels is a problem. Kiretti Kompella: You just reinvented RSVP-TE. Uma: It's an SR path. Cengiz Alaettinoglu: There are hundred thousands of this. It has scalability issues. Uma: Same as SR. Cengiz: How many paths are you going to have? if links fail, What this means for IGP flooding? In a single SP, this is beautiful. Uma: This is to reduce labels. Peter: We had sort of this originally in ISIS, and we removed it. Are you adding it back? Uma: I don't know why you removed it? I have use cases for this. Peter: Does flex-algorithm help in this case? Acee: This can resolved by using flex algo. You can have a constraint on the path to compute MSD. Uma: If you have a way, I'd like to see it. Andrew: SRv6 is hard, not the reason to hack IGP, not the reason to not use binding SID, to say it's non-shortest path. Acee: We'll take it to the LSR list. o 11:10 - 5m - Avoiding Traffic Black-Holes for Route Aggregation in IS-IS Presenter: Zhe Chen Document: https://datatracker.ietf.org/doc/draft-chen-isis-black-hole-avoid/ Les: This was brought up a couple of IETFs ago. If you never learn the reachability, how to you advertise negative reachability? Zhe: This should work together with Naiming's work. This makes the recovery quicker. Andrew: I'm trying to understand what's the intent of the draft. There are more than one solution, there is one of them. Does it need to be standardized? Les: Just to emphasize. If you never learn from the leaf node, how could you ever advertise negative reachability? Zhe: After the link failure, we can let the leaf know about the failure. Chris Hopps: is this related to the work done by Naiming? You need to convince Naiming, if it's needed, work together. Zhe: Thanks for the suggestion. Les: We're open to discussion. We have a different solution to this problem. Acee: And it covers wider range of problems than this one. Zhe: It works but with latency. Xiaohu Xu: echo Les' comments. If spine3 doesn't know the routes to leaf4, how can it advertise default route? o 11:15 - 10m - Flooding Reduction Presenter: Huaimo Chen Document: https://datatracker.ietf.org/doc/draft-cc-ospf-flooding-reduction/ Document: https://datatracker.ietf.org/doc/draft-cc-isis-flooding-reduction/ Acee: If someone else originated an LSA, it's flooded according to the flooding too, right? Huaimo: Yes Acee: You need to revise your fall back. It won't work if your flood topology is a triangle. You need more leverage on fallback. Huaimo: We'll consider more detail. Kireeti: If there is fallback, probably still not work. If the topology is calculated differently. Chris: Is the tree in a central place? Kireeti: No, it's calculated, so no unique tree. Huaimo: This needs to be improved. Current version may not cover everything. Xiaohu: I agree with Acee. It has chicken and egg issue. If link fails, it depends on the original flooding mechanism. You need another flood on reconvereged flooding too. Huaimo: Let's go through one case to prove it. Xiaohu: If you need to reconverge on a link down, you need original flooding. Acee: You flood back to the node that sent it, and it's not going to reflooded. Chris: We have topologies that do not work. Running out of time. Andrew: You need better design. This is a simple topology and people see problems. Stephane Litkowski: Each router is calculating topology differently, how can you guarantee they're all synchronize? We're not able to sync LFA. Acee: DC flooding optimizations. Lots of solutions proposed, we're not going to standardize all of them. Lot's of them depend on implementations. Let's take it to the LSR list. o 11:25 - 20m - An Architecture for Dynamic Flooding on Dense Graphs Presenter: Tony Li Document: https://datatracker.ietf.org/doc/draft-li-dynamic-flooding/ Document: https://datatracker.ietf.org/doc/draft-li-dynamic-flooding-isis/ Acee: Did you mean 90% reduction? Tony Li: Yes. The diameters of the parameters. 4000 links down to 400 links. Acee: what are the N and M? Tony: N spines, M leaves. Kireeti: As the topology grows, you want n**2 leaves. For DCs, you don't see n**2 that much. It doesn't have to be diameter of 4. Tony: you may have deeper topology, not strict leave-spine. I didn't think about it. Xiaohu: What's the drawback? Tony: We have to add extra information into the database that needs to be flooded. It's a trade off. Xiaohu: BGP-SPF and RIFT are to achieve faster convergence, how about your proposal? Tony: This might be faster than collapsing. Acee: your flooding is faster, considering doing 64 ECMP. Kireeti: I don't know how you do the mapping from index to sysID. you need the list of flooding topologies. How do you do it in ISIS? Tony: You order the list of sysIDs with assigned indexes. Kireeti: But if you have 256 nodes? Tony: This is only one TLV. Les: I like this. you laid out the architecture, what about the transitions? Tony: I don't see transition as a problem. If there are overlaps, it should be ok to flood both topologies. Chris: You flood on the union of two? Tony: Yes Les: The flooding is calculated, what if you get different area leader? Tony: If one leader dies, it has to be flooded. If there is a new leader, it will flood topology. You may want to purge the old leader's topology. Danger is you may have to flood on both floodig topologies. Acee: Your connection is bi-directional, how to flood between computing? What if someone is isolated? Tony: If there are two topology changes, it's up to the area leader. Acee: What about new Adjs? Tony: You want to flood ASAP, but you want to limit the scope. Alvaro: All those failures, as Tony said those are old problems. How to optimize flooding? We have 3 existing OSPF MANET RFCs. In mobile network where error happens a lot, it works pretty well. The difference it's very distributed, each node calculate what's the optimal to get out? Every hop figures out the best way. Nice work, it's too complicated. There are other solutions to look at. Cengiz: During the topology change, do they know? Do you send CSNP? Tony: Didn't mention CSNP much. It's sent normally on all links. Chris: Yes, it's sent on all links. Kireeti: I like the general idea. But have one area leader is good and bad. If you can have everyone determinate it the same thing so you don't send it out, it will be good so you can adapt to it if something fails. Tony: Agree. Acee: What Tony proposed works very well in dense stable network. Kireeti: Need to set higher goals. Tony: It's more important to work than being perfect. Kireeti: If you fall back, it will be bad. Tony: If something breaks, you need to flood the update about the flooding topology. Not going back to old flooding topology. It's up to the area leader to recompute. Acee: Need to think more about this. What if someone is totally isolated, you accept longer convergence time? Kireeti: All spines single connected may have security issue. Tony: If customer is fine with it, I'm ok. WG adoption? Chris: It's a bit early, let's take it on the list. Acee: I haven't read the updated version yet. Meeting Close - Talk to everyone on the LSR List.