Tuesday, March 26, 2019 9:00-11:00 Tuesday Morning Session; Congress Hall 1 RTG rtgwg Routing Area Working Group Chairs: Jeff Tantsura, Chris Bowers WG Status Web Page: http://tools.ietf.org/wg/rtgwg/ 1) 09:00-09:10 - WG Status Update Jeff Tantsura, Chris Bowers 10 minutes 2) 09:10-09:30 - draft-ietf-rtgwg-atn-bgp & draft-templin-rtgwg-scalable-bgp Fred Templin 20 minutes Chris B: you had some experimental data? Can you provide some details? Fred: 100 packets/s through BGP, then withdraw a route. We saw packets drop, that’s how we found the problem. Jeff: can you have an appendix to describe this problem? Fred: good suggestion, we can do it. 3) 09:30-09:50 - draft-wu-model-driven-management-virtualization Qin Wu 20 minutes Greg: are you aware of the work at MEF, service, orchestration etc? Qin: yes. these are similar to service models at IETF. Greg: there are models from IETF defined from SPs pointer of view, like L3VPN. MEF defines from Subscribers point of view, like UNI. What you’re describing here is what MEF is already doing. Qin: there are service models defined from different angle. For example, L3vpn also considered customer’s point of view. We’re compliant with those models. There is no conflict, but we do need to collaborate. Greg: there are models, carrier ethernet, defined to order services. MEF UNI model is being published, and there are service OAM, testing etc. I’d suggest be careful with duplicate work. Qin: we’re aware of those. We’re take it offline and cooperate with other SDOs. Greg: speaking of work cycle and orchestration, IETF is behind. I’d encourage you to look at MEF etc. like service OAM, or testing model. Qin: MEF models are more carrier specific. At IETF, you can leverage YANG push etc. Greg: I’m just suggesting to look at what MEF is doing. Rob Wilton: For Greg, at MEF, are they referencing IETF model for device? Greg: work on L3 is being developed, they do have carrier ethernet, that’s L2. Again it’s not L3. It’s better we take it offline. MEF has a good lead on that. Qin: we may leverage the work there. At IETF, it’s better we have some thing to reference to help developer and service providers. It’s important to map MEF service model to IETF device model. We’re engaged with MEF already. Charles: I’m active at MEF. there are overlaps, even conflicts between MEF and IETF. There are service models at MEF, which are different from IETF. It starts from MEF, then switch to some propriety model, or some model being defined in MEF. We’d like to use some models defined in IETF. Yong Lee: I’m an active participant at MEF. I don’t see any conflicts between MEF and what Qin is doing here. MEF has different ideas, they don’t always use YANG models. Definitely within in IETF, we have security build in. I disagree with what Greg said. Rob: I have sympathy with what you said in terms IETF has lots of models from different WGs. Having some informational model to make some suggestions will certainly help. This is useful. Mapping service model from other SDOs with IETF is also useful. Qin: That’s one of our motivations. we’d like to provide reference for customers. This draft is trying to inspire some discussions to see whether new work is needed. Rob: I have Yang Package draft in NETMOD might be helpful. How to package things together. That’s another way to solve the problem. Another way is through tags, which is being WG last called. There are different ways to solve this problem. Qin: Yang Catalog is also related. We did some work in Hackthon. We do need additional input to make people aware of it. Jeff T: I disagree with Greg. MEF models don’t provide enough details. Chongfeng: most models are not widely used in SPs. This draft may help for carriers. I support this work. Ignas: thanks for raising this. you brought up a lot of pain points. But on the other hand, you’re proposing to add another layer of models to solve the problem, that will not happen. it’s not realistic to define a set of service model for all interconnected products. it’s not practical as different customers have different requirements. About the quality of the models, that’s problematic area. We do have technology model, but they implement the same function not necessarily in workable way . This is area need to be addressed first. Thank you for the work. Stephane L: there are no implementations. Plus we don’t have enough models to make it work. IETF is slow. We don’t have enough people working on it. Qin: we can start from LNE model. Stephane: there are OC models ready to be used, whether to use IETF is in question. Qin: if IETF can catch up, it is more promising. 4) 09:50-10:00 - draft-li-rtgwg-tunnel-policy-yang Donald Eastlake 10 minutes Rob: is this a device or service model? Donald: service. Tarek Saad: there are some work done in TEAS. What are you trying to define here? Donald: select tunnels. Vishnu: TEAS this afternoon. xx: in TEAS there is work on how to map service on tunnels, it seems overlap. Jeff Hass: please consider changing the name to be less generic. Dhruv: this sounds more like device model. Other work at TEAS is service level. Lou Berger: if your focus in tunnels, you may want to come TEAS. If your focus is VPN, then BESS. Either way you need to know the work at TEAS. Jeff T: please look at TEAS, and know what should be done. 5) 10:00-10:10 - draft-ietf-rtgwg-arp-yang-model Rob Wilton 10 minutes Jeff Hass: I have some thoughts based on SNMP. If you really have to separate internal subsystems that can have distinct discontinuities, that makes sense. YANG is more towards a cohesive view, you’re now putting in a hint to the system that some pieces of a tree could have completely different idea of counters. That’s tricky. Rob: After the router is rebooted which is one standard discontinuity time. Clear statistics is what I’m worrying about. Maybe we shouldn’t allow it in YANG. Jeff: I don’t think it’s wrong ideas, but it’s tricky. We should discuss it in NETMOD. Jeff H: This is something a platform needs to decide. You chose a default, which might be wrong for some platforms. Rob: they have a choice to deviate. If every one is different, you have to leave it vague. Jeff H: you may want to put a comment in the module for deviation. Jeff T: would we start Yang doctor review after resolving these issues? Rob: yes. 6) 10:10-10:20 - draft-mirsky-rtgwg-oam-identify Greg Mirsky 10 minutes Jeff T: please ask people to participate on the list. Greg: will do. 7) 10:20-10:35 - draft-ietf-rtgwg-segment-routing-ti-lfa Stephane Litkowski  15 minutes Stewart: I’m afraid we’re losing the unconditional correctness. Fundamentally you should repair in the topology you work in. Stephane: I agree. Jeff T: support single algorithm within a calculation. Chris B: for option one about local policy, please spell out an example for that may cause loop, and how to avoid it. Stephane: yes. each flex-algo will have a strict version, we’ll double the algorithms. Stewart: you need to operate in a topology in terms of path and repair path. Peter P: we don’t need this strict algorithm for every flex-algo. Jeff T: are you suggesting a more generic way to do it? Peter P: no. the LFA should be calculated within a single algorithm. 8) 10:35-10:50 - draft-wood-rtgwg-sdwan-ose-yang Bo Wu/Steve Wood 15 minutes Wim: I think this is good work in general. Are you going to L2 or L3 example? What do you prefer to use? Bo: we don’t touch it. it depends on the domain to decide L2 or L3. Wim: it’s good to leverage the ONET work. Steve: are you talking about between the gateways? Wim: it’s not only about interconnections, also end to end connection. Steve: it’s about how to stitch those things. Wim: we can take it offline. I hope we can make it a reference model for SD-Wan service. Chris B: let’s discuss it offline. Wrap Up Jeff, Chris --------------------------------------------------------------- Friday, March 29, 2019 10:50-12:50 Friday Morning session II ; Grand Ballroom RTG rtgwg Routing Area Working Group Chairs: Jeff Tantsura, Chris Bowers WG Status Web Page: http://tools.ietf.org/wg/rtgwg/ 1) 10:50-11:10 - draft-homma-slice-provision-models Shunsuke Homma 20 minutes Greg: how this work is related with MEF? Because MEF has a slicing project, matching what you’re trying to do. Shunsuke: Slicing is not just for 5G. Greg: have you looked at what they’re doing? Shunsuke: I’m trying to provide a protocol for customer. Greg: it’s better to check other SDOs before starting. It’s better to send a liaison for review. This work has been done in MEF already. Jeff T: procedure wise we’ll send a liaison if we decide to do the work. Now it’s just a personal draft. Greg: I’d suggest to review work done in MEF. Jeff T: it will be good if you review other SDOs work. Shunsuke: I think we need to unify. Robin: In TEAS, there are some slicing work that need to be aligned. Shunsuke: we’re trying to clarify the relationships. Robin: I just made a suggestion. Jeff T: there are other work going on. 2) 11:10-11:30 - draft-ietf-rtgwg-net2cloud-gap-analysis & draft-ietf-rtgwg-net2cloud-problem-statement Linda Dunbar 20 minutes Sue: I’d like to put a spin. There is time for deployment. Some feedbacks are needed. Linda: thank you. Chris: what’s the focus of these two documents? Gap analysis is focusing on connecting SDWAN to cloud, to make it standard? Is it accurate. Linda: yes Chris: the title is a bit misleading. Linda: we call it network to data center, because it’s the main drive in market. It’s different from the original SDWAN, in ONOG now, the main idea is to reach cloud from anywhere. I call it network to cloud, to emphasize it’s not just to connect branch offices. Chris: some examples are not about connect to cloud. Just to look at the title, it’s not clear. Linda: we’ll add a session to clarify. Jeff: it would be good if you put more solid example. How to connect from to cloud, so readers can easily figure out what this document is about. 3) 11:30-11:40 - draft-hu-rtgwg-srv6-egress-protection Huaimo Chen 10 minutes Greg: I recall we had similar discussion on RSVP TE. It would be good to have a strong use case. You’re changing SR now to create a transition state. Huaimo: we can add some reference regarding the 1st point. For the 2nd, it’s to add more function. Greg: we need to discuss whether we need it. Huaimo: this is from a customer. Greg: there are other solutions for this, why make it more complicated? The simplicity for SR is broken here, you’re going back to RSVP TE. Huaimo: the states here are much less compared to RSVP TE. Greg: you also need to monitor your backup path. You’re creating new state and complexity. We need to discuss whether this is needed? Huaimo: I don’t think it’s complicate. Either we monitor or compute backup path, we need to do it either way. Greg: if you’re advocating compute from upstream, it can be done by controller. Again we need to discuss whether it’s needed. Jeff: Greg, please send your statement to the list for discussion. Peter: On the contrary, I think this is interesting problem to solve. However you solution only works if you have the same VRFs on the PEs which may not be true. 2nd the synchronization is needed between the PEs. I agree with the problem statement, but the solution is not complete, more work needs to be done. Huaimo: we’ll enhance. Jie: I think this is good idea to solve the problem. We’re not introducing per path state. xx: PE1 already have two paths to CE. these are resolved already. Jie: this is for local protection, not end to end. Greg: how do you detect the failure? Huaimo: PE1 will detect. Greg: no. You can’t distinguish node failure from link failure. You don’t know what failed in a tunnel. Huaimo: we have detailed discussion in the draft. Chris B: good discussion. this is a problem needs to be solved. Stewart: regular FRR can fix it. It will take two failures for FRR not working for this problem. Himanshu: if you’re doing BGP PIC, it will switch PE4. This has a limited scope. There are other solutions too. Jeff: lots of work done in this area. Please review those and start a discussion on the list. 4) 11:40-11:50 - draft-li-6man-ipv6-sfc-ifit Zhenbin Li 10 minutes Joel: It’s on the wire. We have multiple encapsulations, making another one doesn’t help. The point of SFC is to provide a common transport, this were brought up in SPRING, it supposed to work with all encapsulation, so we don’t have N**2 issue. Creating SRv6 encapsulation for this, we need to think about it. Shuping: we’ll consider your comments later. Robin: is there any draft about SFC in IPv6? Joel H: SFC is not about specific data plane. we’ve done one in MPLS. If we can do similar thing, we can do SFC in SRv6 or IPv6. Jeff H: you’re introducing recomputing at every hop at line rate. It’s something to consider. Shuping: for the meta to be inserted, it’s only to write. If we want to add ioam, it has to be inserted somewhere. Greg: if you add something in the packet, you need to recalculate the checksum. Put them in the packet has limitations, like integrity. Shuping: that belongs to IPPM. Greg: are you doing protection? Then you have extra work. There are other proposals. Cheng Li: the problem mentioned by Greg is not unique, it applicable to all iOAM. Greg: are you proposing solution or problem? Cheng Li: solution. Greg: you’re introducing problem. Shuping: security of the data , or risks introduced by these data are different. We have solutions. Greg: please think about the problem. Jeff T: this really belongs to IPPM 5) 11:50-12:05 - draft-ietf-rtgwg-yang-rib-extend & draft-ietf-rtgwg-policy-model Yingzhen Qu 15 minutes Ignas: this is because importing modules from other SDO. Let’s discuss it offline. 6) 12:05:12:15 - draft-chen-npm-use-cases Yunan Gu 10 minutes Jeff T: the use case is needed. You’re gathering op state, how do you establish your intension? Let’s discuss offline. Acee: you have a proposal to collect all info in IGP while we’re trying to reduce flooding. Chris B: that’s from customer case. Acee: like BMP for isis. It’s going to increase the overhead. This has a different application range other than data center. Jeff H: you may injecting data into the network through IGP, which might be bad. 7) 12:15:12:30 - draft-nslag-mpls-deprecate-md5 Andy Malis 15 minutes Jeff H: TCP AO is finally starting seeing deployment. It protects half of your story. Andy: it’s still better than MD5. Alvaro: this one has some history. If TCP AO referred, use TCP IO. Andy: perhaps we can do better. Eric Gray: it seems AO is a TCP thing. What additional support you need to do? Andy: it’s implementation issue. Eric: I’m just curious what extra work need to be done. Jeff H: maybe you can consider IPsec, although it’s not my favorite. You can use both of them there. The challenge is that security people want you to use it. In routing, it’s a chicken egg issue. You spend some effort, you can get IPsec work there. Andy: oppose we use TCP AO, what do you suggest about crypto algorithm for LDP? Especially for low end router. Jeff H: I don’t have specific experience with these algorithms. Security people tend to suggest something heavy. The requirement for routing might be different, you want something enough to cover your need. We don’t want something overkill. You want something strong enough to provide reasonable protection. For example, key roll over may help. Stewart: how often do we need to spin a key so security people will be happen? Jeff H: hmd5 was suggested. Hamashu: I’m glad you bring it up. What’s your goal? Andy: does anyone care? Using Md5? Stewart: are they using it for checksum? Or security? Andy: we don’t know. Jeff T: MD5 is deployed. It’s difficult to get operators to do something different. Wrap Up: Jeff, Chris