Minutes IETF103: rtgwg
minutes-103-rtgwg-00
| Meeting Minutes | Routing Area Working Group (rtgwg) WG | |
|---|---|---|
| Date and time | 2018-11-08 02:00 | |
| Title | Minutes IETF103: rtgwg | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2018-11-29 |
minutes-103-rtgwg-00
RTGWG IETF103 RTGWG IETF 103 Agenda 16:10-18:10 Monday Afternoon session II Chitlada 3 RTGWG draft update: Chris and Jeff 20min Jeff: welcome to Bangkok. Note Well. IPR disclosure. RIB YANG Data Model draft-acee-rtgwg-yang-rib-extend Yingzhen Qu 5 mins Jeff: How many people have read draft? A few people respond... Jeff: Please read. A YANG Data Model for Routing Policy Management draft-ietf-rtgwg-policy-model Yingzhen Qu 5 mins Acee: Keyur requested to encapsulate lists in containers so they can be retrieved with a single NETCONF or RESTCONF operation. Yingzhen: Will provide in the next revison. Sue Hares: Please ask when they plan WG last call? Acee: Well before BGP YANG. Jeff T: As soon as possible, please review. Sue: BGP YANG model is waiting on this draft for WG last call. Architecture for Use of BGP as Central Controller draft-cth-rtgwg-bgp-control Huaimo Chen 10 min Chris B: based on the title, I thought it was related with BGP SR TE. Huaimo: slide 3 shows the block how to set up SR TE path. We can have a request, because BGP already has SR information and SID info, and controller can compute the path, then allocate SIDs along the path. Chris B: there are methods being standardized to pass the information from a BGP controller to an ingress node, is this using those methods? It might be better to make some clarifications in the document. Huaimo: if there are existing solutions, well use them. Jeff: you dont have references. Please add more details what youre trying to do. Huaimo: Yes. Greg: are you suggesting BGP to implement constrained SPF? Huaimo: yes. Why not? Greg: I just want you to say it. Huaimo: BGP already has those info. Its easy to have CSPF to calculate traffic engineering path. Tony Li: BGP is not a dump truck. I dont want to go to that. Let me ask you a different question. Whats the difference between this and PCEP? Huaimo: PCEP is another protocol. It may increase your network cost. BGP is already a core protocol, we can reduce number of protocols. you dont need to install controllers. Just like SR, customers are happy. We can reduce protocol number. Tony: customers may not be happy if youÕre folding more stuff into one protocol. All your complexities become one big monster. Jeff: please add more details into the draft. Automatic discovery and configuration of network fabric in Massive Scale Data Centers draft-heitz-idr-msdc-fabric-autoconf-00 Jakob Heitz 20 min Chris B: is the network endpoint table on the controller or device? Jacob: on controller. The controller learns all the links, its a link state table. Chris: so it use the info to calculate SRv6 path. does switch has similar function? Jacob: device knows how to get to the controller. Controller gets to the device using SR. Chris: so it uses the ADJ sid. Jacob: yes. Sam A: what exactly are you standardizing here? Jacob: I need a couple of things in DHCP to make the DHCP piece work. Sam: I didnt see those in the doc. Jacob: will do. Sam: what if the controller doesnt know a device got added? Jacob: each device will be DHCP relay agent. If a device see router advertisement, if a router requires an address and sees the RA with M bit set, it will start the DPCH solicit. Sam: if the controller doesnt know how to reach the router? Jacob: the controller knows how to reach a DHCP relay agent. Sam: the assumption is that the controller always can reach an agent. Jacob: the controller will always know how to reach a relay agent to which the new device is connected. BGP ensures connectivity to the controller as long as there are links. If a device is becoming total isolated, its not working. Sam: Lets talk offline. Tony Li: I like it. Will it be simpler to enable routing incrementally as you went? Jacob: slide 5. The yellow guy doesnt know how to reach DUT because each device knows only its immediately connected. Im doing this for scalability. You could run ISIS, but it doesnt scale. Tony: isnt MSDC gonna run some kind of routing? Jacob: thats the draft I presented at IDR interim. BGP aggregated routing in IDR with RFC 7xxx. Tony: why not deploy that incrementally with messing with SR? Jacob: are you saying putting the aggregated address in the beginning? Before controller gets certain information, it doesnt know which router its talking to. Tony: wouldnt it be better if the controller has some knowledge ahead of time? Jacob: that would be nice. But it doesnt have to. Igor: can you tell us which MSDC doesnt have a topology defined ahead of time? we run datacenter. We have a controller that does something similar to this out of band. we predefine the topology, wire plan, etc. we dont need auto discovery, why do we need this? We have controller which can do everything. We dont let device auto config themselves. Acee: you said topology plan, do you use aggregated route? Igor: yes. We predefine those things, we have a plan. Controller will verify whether topology plan matches reality. Stick to the plan. Jacob: how does controller communicate with device? Through management port? Igor: controller connects to devices in band and out of band. The initial configuration is done using out of band, that means in band doesnt need to be up. If you were to do in band only, you would basically connect device one, then everything connected to the next ring. It doesnt need a whole new protocol to do this. Is there customer asking for it? It seems a wrong way to configure the network. Jacob: Id like to talk to you offline. basically you dont need to configure any position dependent info, you can take a device out then put it back. Igor: in MSDC, you have wire plan and topology plan, MAC matches sys ID. Jacob: what if you put a different switch into that slot? Igor: the switch wont come up because it doesnt match the configuration. Again we design how things are, and its better be that way. Jacob: as long as its the same kind of switch, your controller can figure it out and make it work. Igor: again this is unlikely. This is not how its done. You will be doing power management etc, you cant randomize things. Controllers are supposed to program according to the plan. Jacob: I can replace one switch with the same kind, not randomized. Igor: switch needs to installed to the place according to the plan. Jeff: this is a discussion that can go forever. Acee: I can see what youre saying. It makes things easy. Are you saying we got wrong requirement? Igor: yes. Its not random. You can do in band only. Jacob: I hear what you say. I can make changes. Lets talk offline. Jeff: if this work continues, it belongs to RTGWG, not IDR. Jacob: it does belong to IDR. I have the name in IDR. Jeff: no. The file name doesnt matter. Jacob: where do you think it belong? Jeff: here. Architecture for Control and User Plane Separation on BNG draft-wadhwa-rtgwg-bng-cups-protocol-requirements draft-wadhwa-rtgwg-bng-cups Sanjay Wadhwa 15 mins Chris B: Im not sure were tasked to pick a protocol. We were asked by BBF to focus on these drafts and their first liaison. Sanjay: the subsequent liaison says that we will have some BNG changes expected. Chris: in the subsequent liaison its clear that they have yet to perform a feasibility study. until were told otherwise, theyre not asking us to pick a protocol. Sanjay: thats why were calling it a candidate. NingZong: PFCP is owned by 3GPP. are you asking IETF to do 3GPP extension? Sanjay: it has a number of different cases. Once our goal is not to reinvent. We want the BNG to be able to handle multi access. Ning: what you want IETF to do here? Protocol extension? Sanjay: correct. 3GPP is not going to looked at fixed BNG. We want to use a single protocol. We can extend those ideas here in IETF. Ning: so you want to extend 3GPP protocol and see if it can be applied here? Sanjay: Mobile IP is defined here and used in 3GPP. Jason BBF liaison manager: pretty much what Sanjay is saying is true. Theres work on fixed only architecture detailed in TR 384, thats liaised in March. Whats subsequently liaised is the work from the wireless wireline convergence group. The BBF has not consolidated the proposal. were trying to come up with a unified set of protocol that can deal with the whole thing. BBF needs to sort out first. Jeff: time frame? Jason: the next meeting is December. Georgios: the end liaison has been sent from BBF to IETF. The main goal of the liaison is to starting requirement to identify whether to separate user and control plane. What is clear is we like to focus on fix mobile convergence, meaning companies interested in this will have wait until 2021 Sanjay: 3GPP, theyre not looking at fixed BNG. Andrew: we want to have a convergence of fixed and mobile. We dont want to have three protocols. In stead of 2021, were looking at 2030. Chris: running out of time. lets move on to the next presentation. Architecture for Control Plane and User Plane Separated BNG: Update on cuspdt drafts draft-cuspdt-rtgwg-cusp-requirements draft-cuspdt-rtgwg-cu-separation-bng-architecture draft-cuspdt-rtgwg-cu-separation-infor-model draft-cuspdt-rtgwg-cu-separation-yang-model Donald Eastlake 15 min Dave: from BFF liaison manager point of view, sending an liaison will be good. If nothing else it will get some clarity back from BBF. ZhongQiang Li from China mobile: what we need is the BNG for fixed network. weve already done some tests in our fixed network. They can satisfy requirements. I think IETF should focus on fixed network on user plane and control plane separation for BNG. Wed like to work with Nokia to develop the architecture on FMC. Wim from Nokia: I think its good to send the liaison. I believe if we rush too fast into the fixed network we have a lost opportunity to solve the FMC use case. I recommend we speed up the work together in BBF on FMC. So next IETF we can get requirements in and then see which protocol is the best. We should not come up with two different protocols. Donald: I disagree. The completion of these documents which ere already in use would have any significant effect on the timing of subsequent efforts. Wim: its up to BBF to decide. Donald: I dont think doing what Im suggesting will actually significantly affect the subsequent efforts. Andrew: I second what Wim said on sending the liaison. I also dont like pseudo rush here. Trying to say this is done is premature. The amount of changes in software will be big.There is fundamental issues in protocol. We need to take time to work on it. Donald: I didnt claim these drafts are in final form. There is work need to be done for editorial changes and completeness. Andrew: its not editorial change, from open flow to new protocol, I can show you this is even worse than open flow. Georgios: there are carriers wanting to have a solution now. requirements for fixed network is very different. Not possible to have the same solution. What I have to say the timeline, if we want to have a common solution, for fixed network it will be complicated, time line will be after release 17, 2021. Carrier wants to have a solution now instead of waiting for 3GPP. Sanjay: we presented here is multi access BNG. When you looked convergence as a whole, its different. Whats presented here only works on Ethernet access BNG, not addressing the multi access part. Ningzong: the fist liaison: I think its valid. The 2nd is to get more information, not a replacement. I see the 1st one real requirement. Were not against sending a liaison, but not to say were gonna have a unified protocol. Were not against FMC case either. Chris: cutting the line. Dave Allan: carriers wanted to support existing stuff, which meant we were going to end up with a platform that would terminate access protocols as PPPoE, hence the concern I raised in Montreal which is we have the opportunity to have many protocols support the same using facing functionality, and this was part of the motivation for the second liaison. Wolfgang from DT: I just wanted to second the notion that fixed mobile convergence is not as straightforward as many people like to believe. There are products that arent there in the mobile world like access. Geogis: whats the conclusion? Jeff T: the conclusion is there is no convergence yet. We see space for both groups to continue working. Hopefully there will be clarities by next IETF. 9:00-11:00 Thursday Morning session I Chitlada 3 SD-WAN cloud interconnect problem statement and gap analysis draft-dm-net2cloud-problem-statement draft-dm-net2cloud-gap-analysis Linda Dunbar 20 min Dino: your comment about ONUG, so yes they want to come to the IETF for solutions. and a lot of people have done a lot of hard work to make that happen, however if the IETF comes up with too complex of salu they're gonna go elsewhere, or the vendors are just going to do it themselves. so you have to be able to articulate extremely clearly to these users what the solution is gonna be. Linda: yes. Lou B: on the gap analysis at the last meeting, we talked about RFC 5566 having provided some possible capabilities and solutions. did you take a look at that? Linda: I took that out. I was told that was obsoleted and we shouldn't use it as a reference, so we took it out. we do want the controller to be aware of all the possible transport networks. some are underlay and some are overlay, they're different from tunnel. tunnel is end to end, and this is talking about particular segment. Lou: The encaps SAFI certainly could support segments. it's it doesn't know about the application, it just does about tunnels. so how I use it as your call. I was involved with deprecating that. in fact I advocated it since we were the only who implemented it, and thought it was too complex. but that was because there was no use case, and if you think your use case can be solved by something we've worked on before, it's better to use an existing solution than to go through the process of defining something new. so I encourage you to look at that and if it meets your use case, use it. if it doesn't, you know maybe look at what we ended up replacing it with, which was just the way everyone effectively used it because it's a lot easier which is the encap attribute figure out how to extend that or use that. Linda: I'm glad you gave this comments.I've been puzzled by this, and people told me not to fight. Lou: we updated it based on implementation experience. the experience is that we could use it in two different ways, and one of them we found to be overly complex for our use cases, and given that there were two ways and one was overly complex, we went with the one that was simpler. now this is a different use case okay. Linda: so for 5512, i want to separate between tunnels and the transport. so in SD-WAN we're talking about transport. the tunnel can be between CPE 1 and CPE 3, but the traversing can go through different networks. so that part even 5512 is not coming that, so that can be extended. we can talk about that offline. It'll be great if you can join the work. Lou: yes, that will be great. 5512 you can actually support stacking of tunnels. it allows you to do that, and it sounds that's what you're doing here. maybe I'm misunderstanding. so we can talk offline. Linda: I will talk to you afterwards. Wim: the two gaps which you identified so far it's mainly about IPSec tunnel establishment and the not traversal, are those the two main caps? Linda: there could be more. I'm looking for more feedbacks. There are comments that this particular part wasn't described very well, we will get more feedback on that. Wim: there are way more gaps than you identified. we don't necessary reinvent. the IPsec process, still use IKE to do the process. I believe there could be some extensions which are useful but I'm not sure a new SAFI is the right way to go. there are other areas, like load balancing, that's another area not so easy to address. Linda: for IKE we had that more than our discussion in i2ns working group yesterday. so for the IKE itself the content we don't change, but how do we set it up. so in i2ns there are three cases. the first case is controlled or facilitated configuration, because for Ike has lots of configuration. second case which has lots controversial is actually controller for the CPE which is low cost, low power. they don't want to deal with or communicating with so many peers, so they depend on the controller to help them to do a key propagation. That created lots of issues. Third case, and Dave is in the room as well, so he proposed a third case is controller facilitate IKE. so controller facility IKE means for me I don't have to talk to everybody I just send it to my controller, my controller determine who do I send to, and then we need established the key. Wim: I think we agree that there is a problem to be solved. I think it's semantics on how to do it. I think it's where we need to have more discussions. Linda: Thank you so much. Keyur: I just wanted to remind you basically you and I had conversation. it is RFC 5566 that we are updating and ensuring that it goes over tunneling encaps. as an author of a tunneling encaps I'm updating both RFCs. so I just wanted to let you know that work is going on, happy to work with you and cover this. Linda: that will be great, thank you. so there is more reason to make it a WG draft. Jeff T: I think when you have BGP, when you have a hammer, everything looks like a nail. we really need to find right boundaries between management plain interruptions versus control interruptions. you shouldn't be doing everything bgp just because BGP is there. Linda: for us, we want something simple. more problems when scale up. everybody is using BGP. just like IPv4, people say don't use IPv4, we have IPv6. But because it's there, we just add something and make it work. They want to deploy it as fast as possible, as simple as possible. Jeff T: we try to decide from architecture prospective. Linda: this is really an example solution. we need to show the problem, the gap, and example solution. Chris: if this is to become WG document, will you be open to suggestions? Linda: yes. Also the solution can be in other WG. Here is to identify the problem, gap, and stimulate other people to work on it. Keyur: if you're looking for solution outside of BGP, there was a draft expired that was a generic solution. when you can't fight, join them. Dino: there is a lisp crypto draft, negotiate keys without key management systems. Linda: LISP was proposed as an alternative solution. Dino: glad you mentioned it. Chris: any other comments? Jeff: how many read the drafts? pretty good. I think Routing WG will take the work and continue to work on it. Chris B: this is in the broad scope of RTGWG. is there anyone who think we shouldn't be working on this? (none) ok. thanks. Jeff: please keep it sync with data model progress. SD-WAN service model draft-sun-opsawg-sdwan-service-mode Bo Wu 10 min Linda: ONUG SD-Wan part abandoned the efforts. ONUG tried to catch the enterprises need, and they had interwork group. it takes long time to do interpretability. They found out enterprise today is more about portability. they've moved to security. they have defined APIs, and they may bring it to IETF. We should work with them. Jeff: it would be good to get Yang help? would you be able to reach Steve? Bo: yes. I'll ask Linda for help. Chris: this draft was presented at OPS. at this point, you want feedback from this group, we started efforts in SD-WAN, we will have continuing efforts. Just to provide some contexts, the work won't be adopted here, but it's related with our initiative. Jeff: please make sure different levels of Yang models are interoperable. Explicit Topology Marking using RFC 8377 Donald Eastlake 5 min Network monitoring protocol and neighbor state monitoring draft-gu-network-monitoring-protocol draft-xu-rtgwg-monitoring-neighbor-state Yunan Gu and Robin (Zhenbin) Li 15 min Chris B: the side meeting consensus means we don't need new protocols to do it. The project name, network monitoring protocols, sounds like we need new protocols. I was thinking network operators represented aren't at IETF. it might be useful to define use cases, a subset of data what's needed to troubleshoot. A mide-size operators won't look at thousands of YANG, so they can also benefit from the subset of data. Jeff T: GRPC and YANG push are there, data consumptions are how you model it and Yang helps. how do you relate events, so this is interesting space to work on. there's a lot of stuff out there that you didn't mention, I don't want us to reinvent the wheel. we need to focus on what needs to be solved rather than reiterating what has already been solved. so you mentioned some tools but didnt mention some others I think we need to look wider what's available in the industry, what open-config is doing, what has been done in IGP and BGP working groups, where we define data model that also provide operational stage. Rob S: I have some experience in this area. we've been working on this for a bunch of time I think the observation that we don't need another protocol is key. we've kind of defined some transports as Jeff said, we've been working on GRPC with a way to be able to have model data that doesn't need to be modeled in yang. I think that this moving towards a single solution is the right thing. there's two bits of work that I think the worth commenting on, one is what set of data do we need. I think it's an interesting problem to go and say okay what are the things that we can export, how to get it out of the device, what's the encoding is needed. we've done a bunch of work. there are shipping implementations of LSDB streaming. for example, over GRPC. we've kind of started to solve some of these problem spaces, where they're not traditional monitoring data sets. I think you'll find the largest implementations. they're widely adopted, have some roadmap to getting a decent amount of the operational state we currently collect already. there's to me a problem space, around what additional data haven't we identified. I think some of that was what the point you were raising. basically, what instrumentation do we need in an implementation to be able to debug it. I would encourage a conversation with operators rather than a specification operator, because I would say that the expertise for operating. the other area that I think is interesting is this medium operator problem. I have a software engineering team and we're writing implementations. we have a bunch of resource to put on this. other operators maybe don't have the same expertise. the challenge there is that I don't think blueprints are the right thing. it's got to be running code. we need to get this kind of modern telemetry data at the stage of like mrtg, I can download a bunch of tutorials online that tell me how to get the things set up and have it go from data collection to graphing. right now, we've done a lot of work in the device facing bit. we've open source test frameworks around the data from the device. I think there's then the next layer up and so Yahoo oath recently open source panop sees which is their kind of next layer up. I think we should concentrate as an industry of getting this stack kind of stood up, and show how easy to adopt this stuff for those operators. that will make things go quicker. it's not necessarily standards documents or deployment documents. Jeff T: I don't always agree with Rob, but this one, yes. So it doesn't make sense to reiterate the things that have been solved. Let's focus on things that are not solved. Rob: did you agree with me or not? Jeff T: yes, I did. Robin: thanks for comments. We'll continue the work. Thanks for your help. Jeff T: please work with operators, not to reinvent new protocol. Robin: streaming telemetry can be a protocol, not new protocol. How libyang, libnetconf, sysrepo, pyang are used in FRRouting Dean Bogdanovic 20 min Rob S: we've done some other work in this area. just to add to the collective open source, we have a library that does from yang to Python and class bindings. we'll do a similar set of functionalities here. we also have written a library that's also open source. and in open-config it's called YGOT. that library also does yang to protobuf, which then gives you a bunch of other language bindings. it doesn't have the same validation, but at least lets you start dealing with the schema. we've been using these with various other implementations. Jeff T: a buff to YANG ? Rob S: YANG to proto, not the other around. we don't take a proto and generate yang from it but we'll take a YANG model and generate a set of protobuf messages from it. Jeff: would you please send the info to the list? Rob: yes. Michael A: we're looking into NMDA. we consider that like a suite. Jeff T: they're publicly available tutorial how to bring them together and make it work. Michale A: yes, so sysrepo.org has everything. there are docker images and everything you can play with. We have Ubuntu packages. if it's not good, I'd like feedback. Thank you. David Dai: who will maintain the open source? how can user share experience? Dean: there is a community maintaining it. There is not a ready product. there is a difference between system product and open source. If you want to use it in open source in your product, you will contribute back to the community. This is where open source is valuable to kick-start certain things to be used by other people, and then through their commercial success they would give back to the open source community. David: everybody can do it? Dean: yes, and the question is if there is a critical mass of people and companies that have joint interest in supporting something like this. and based on the few last years, there is increasing interest and support for that. so this is just to raise the awareness in how it's been done and how his system been built. is it the system for production deployment? No, it's an example. but can they use those libraries to build a production ready system? Yes. Lou: one thing that Dean didn't say is that for most of what was talked about here is there up on github. anyone can go fork the repo, all the projects take pull requests. I'm a maintainer on FRR. we take pull requests from anyone all the time. when FRR was doing this particular work, I found a bunch of problems with live yang, and the person doing the work sent pull requests, and those folks accepted it. so it's sort of the normal today's open source process is being followed. Michael A: so we use this for managing both services and the home gateway for instance, I'm responsible for. there are other vendors that are using this in shipping products, as far as I've been told. because they needed to make their device manageable, so they took this and implement that. they were doing their own support for it, and it's not as much difference from Cisco or anyone else you know. Taking a bunch of tools and putting it in their products and then they sell support towards the end customer. There are part of people involving development this that are consultants that I can direct you to them and if you want to get new features implemented, they can help you with that. we're developing a healthy community around all these different projects that are tied together in creating something that is useful as a whole. Chris: So some clarifications. The first part of your presentation talked about using open-source to do Network management as a network operator, this is more how you used open source in FRR the internals of a router, there's a distinction. Dean: in the beginning I said I will give you overview of the open-source tools that you can use in building a system, and then used FRR as an example how to use them. because I could have just left it, here's the overview of them, but this gives you an additional way how they were used in an open-source implementation. you can go in there and take a look by yourself how it was exactly implemented. Chris: most of them will be using them to monitor networks. Michael: we were for instance in the process of packaging up the plug-ins that you use with sysrepo, but to implement the IETF interfaces an IETF IP and IETF systems model. so we use those standardized models, it talks to the kernel, it talks to the open wrt configuration subsystem. Then you can configure this open wrt box. you can also take sysrepo in the same plugin and for the stuff that it talks to the kernel net link interface, you can run this on a server as well and you can change the IP address of the server interface or whatever. you didn't mention much about the plugins that you also need here, but this is what implements the model. you load the model, you load the plug-in, and now you can use the model that then runs the code in the plug-in that actually does something. Dean: there're guidelines how to develop plugins. I forgot to mention that each one of these daemons has its own plugin that is being used to connect to a different centralized management daemon. If you want to use a another one, you can develop that plugin by yourself and just use it there. Jeff T: if you're interested in FRR, there is tutorial. Robin: this is very useful. Open daylight also has some tools. you introduced this tool because it can satisfy because of this requirement of implementing plug-ins, correct? Dean: open daylight is a controller, it's at different layer. if you're writing new applications, and you want your applications to be managed by open daylight these are the tools to help you. essentially they're complementary. Michael A: this makes the device manageable, not to manage the device. This was written in C, but the plug ins can be in different languages. Rob: we have implementations on tooling. Last year at ONUG, we had presentations, and there were examples. we have a few different projects working on this. Jeff T: can you make it available to the list? Rob: I just sent an email, will add to it. Jeff: will you be able to make a presentation with more details at next IETF? Michael: sure. Lou: one comment following up on what the Dean was talking about. this is can be used by others in their products, that's interesting for the IETF. I think it's really interesting that this can serve as a reference of an early implementation for emerging work that we're doing here, and it can really inform our work. for example, we were talking offline about how to support different versions based on what's going on in NETMOD with versioning. Having the hands-on experience can really help us make sure that what we're doing here works and help identifying any shortcomings in our specifications. Dean: I wanted to raise support for the same comment from Lou. I heard that from some other areas that they are having in their draft development process that they are having what they called release drafts, where they are looking together with the open source community to making sure that the draft has been forwarded is implementable. what is good, what is bad, and use it as a corrective action. this process that was done by the community was very helpful to validate some of the concepts and get some feedback in this whole draft development process. Jeff T: Thanks everybody, and we'll see you in Prague.