Wednesday, March 29, 2017 9:00-11:30 Wednesday Morning Session; Vevey 1/2 RTG rtgwg Routing Area Working Group Chairs: Jeff Tantsura, Chris Bowers 1) 09:00-09:10 - WG Status Update Jeff Tantsura, Chris Bowers 10 minutes Jeff Tantsura, Chris Bowers 10 minutes CB: Note well applies. What you said here and contribute on the mailing list have certain implications, please understand them. CB: there are general procedures in the WG that we use to poll the authors for the IPR, we do that at the WG adoption as we ll as at the WGLC. Yingzhen Qu: My first IETF participation was two years ago in this group, and I'm honored to get this opportunity to serve the community. Thanks. JT: Agenda review. Charter reminder. New RFC 8102. Document status. Encouraging to do shepherding work, there is a number of drafts that need shepherd write-up. 2) 09:10-09:30 - draft-wbl-rtgwg-baseline-switch-model/ draft-wbl-rtgwg-yang-ci-profile-bkgd David Black 20 minutes device profile is needed. yang is good descriptive language. translated into redfish. profile: a collection of models. family of profiles from ietf and industry. from management point of view, you want something common. Roll data centers by adding racks. redfish: why a new interface? single common interface. DMTF: many organizations are contributing. server management. Swordfish: storage and resource management. map the yang into CSDL. transfer yang list into redfish. embed router/switch at the root of the schema. redfish json. yang ->csdl->json David presenting. David: not wearing a TSV hat, this is to introduce a new work. Joe White presenting, Redfish for network element management. Rob Shakir: How lossy is your mapping to the JSON schema? Joe: It is basically lossless. For CDSL it is completely lossless. We have no way to interpret YANG extensions and we turn them to CSDL annotations. JSON schema is derived from the CSDL. John Leung: CSDL is far more rich. We decided to map YANG to a rich CSDL language. Rob: Do you have a spec of how that schema for that mapping looks? John: Yes. The reason why we have two schemas is JSON schema is not standard. Jeff T: Would be useful if you sent the pointers to the resources to mailing list. A: there are examples online. (link?) snip example: interface.yang to csdl then to json. mechanic mapping. one to one relationship. aiming complete yang structure reuse. container become objects, leaves become properties. [discussion] CB: what is the comparison of restonf and netconf? The end result seems to be similar, would be good to discuss. odata seems to be richer. You see that YANG model is a good way to start. John: restconf and netwconf are perfectly good. This approach is meant to be a part of overall converged infrastructure management. Storage and compute people have way more systems that we do. If the infrastructure is managed one way, how do we add network management to that? RC and NC are good ways but different, and that increases the number of management ways in the industry. Leung: There are multiple redfish implementations in the industry. Compute is almost done, storage is on its way. It seemed for us to leverage the expertise of the ietf for the networking part. GTT have a greenfish working group which covers more than compute and storage only. Alia: I am happy to see this work. A couple of questions: As you are looking at the yang models, are there features or challenges that you see when integrating into your work? JohnL: Some of them are not done, having RFCs would help. Yang in itself has a few challenges in itself when you map it but that is solvable. Mostly the set of models is incomplete and there is a lot of drafts, 100 drafts and a third of them are real RFCs if you look now. We should redo that survey again. Alia: I am extremely well aware that we have a number of models that are still in progress. One of the challenges to encourage which models to progress rapidly is selecting a set that is useful. But that set may lack one or tow that are required. Knowing what you need from the models would be good. Many of those models represent a good common abstraction from multiple implementations and use cases. It may be that it is the case that you have in this context. John: That would be a really good discussion to have. I appreciate your point, there is no criticism in what we said here. Writing such models is challenging. We started writing a full switch schema from scratch, abandoned later but learned a lot from that. Alia: Thank you for bringing this work. JT: Yang is yang, when you must and augment when you can. Having running code is very valuable. Please share your findings on the mailing list. CB: We use rtgwg as a way of introducing new work into RTG area. Is the general idea of those document to be in the rtgwg? David Black: Yes. Most underlying yang models that we need are already here. CB: Just making it explicit that we are targeting it to be here. Kun Xiang from Huawei: This work has some resources, like restful API??? I would like to point to ONOS project that can generate restful API from model. I want to know the difference between redfish and ONOS approach. CB: LetÕs take this offline. They produce REST API but they use a richer schema that covers servers too. John: There are several ways to do the job. It is a way to coordinate servers and storage. If I have core router environment it may not be applicable there. There is a split in a way how you manage systems, there are many ways to orchestrate and control, and this is one of the ways that matches with compute and storage. CB cutting the line of discussions. 3) 09:30-09:40 - draft-ietf-rtgwg-enterprise-pa-multihoming Jen Linkova 10 minutes update of the draft. multihome: first send to correct isp. 2nd what address hosts want to use. changes: standard->informational. questsions/comments? [discussion] CB: As a coauthor. We wrote this as we got a request from v6ops but we did not have a good framework in RTG to understand the overall end to end context. The problem has been floating around for 15 years. There are other documents in RTG both here and in IGP WGs that work on the source address routing portion of this work. We should not necessarily progress this immediately as we need to get a feedback. This is my opinion as a coauthor and not as a chair. We need to incorporate the issues that may come up in those groups. Robert R: You said this is applicable to the enterprises that do not have their own address pace. Should we be encouraging enterprises to get their own address space? Jen: Some enterprises would like that, but it would inflate the routing table. I am not certain whether a coffee shop should have a /48. You also assume that they will run BGP, but there are small enterprises that do not run BGP but want to have multihoming. Robert R: Not each coffee shop has a /48. I am not saying that it is a bad idea. JenL: You still want to have a local ingress, and you want to use the providerÕs space. Joel Jaeggli: The distinction between the entity embedded in the other prefix - it is irrelevant how small the prefix is, whether it is embedded in another entity. Jeff Haas: If you have an internet wide use case. You have more than one address space internal to your enterprise and you would want the users of the host to use the appropriate address space. Jen: Controlling the internal address space is simpler. Jeff Haas: You are bringing NAT next to the host. JT: We will stop here. 4) 09:40-09:50 - draft-kapoor-rtgwg-dynamic-multipath-routing Sanjiv Kapoor 10 minutes no questions [discussion] JT: Any questions. Thank you for sharing the results here, it is a valuable research on throughput growth, would be good to see at the next IETF if you have more data and results. 5) 09:50-10:00 - draft-esale-mpls-ldp-node-frr Kireeti Kompella 10 minutes Kireeti presenting. Kireeti: I am not here because I want to be here but because you made me to come here. :-) Acee: Is this really just a description of a technique commonly known as RSVP-TE over LDP? Kireeti: No. It's for protecting LDP RSVP-TE. There will be a picture soon. [discussion] CB: Is this informational or standard? Kireeti: I think this should be BCP. There is no new standard here. CB: So either informational or BGP, whatever. BCP has a higher layer of connotation. Alia: One of the reasons that this draft is better suited for rtgwg is because of the interaction between the components in the context of LFA and other FRR mechanisms, that's the kind of expertise in RTGWG that the draft will get noticed here. Kireeti: This is the background why we do RSVP/LDP protection. JT: It is a new draft to this WG, would be good that operators as consumers of this technology read and comment. 6) 10:00-10:30 - RTG-DT-YANG-Arch YANG drafts updates and discussion RTG-DT-YANG-Arch team 30 minutes Lou presenting, JT: Lou, could you also present the either decision from netmod wg? Benoit is in the room. Lou: if you're referring to topic two, it's not finalized yet. JT: yes. Lou: Both LNE and NI models are gated by schema mount. There will be planned virtual interim on logical elements representation. If you are interested in VRF etc. please attend because it's going to impact you. Lou: is the routing area common yang types model ready for LC? JT: All the common types from IGPs and IDR are there. Updating of the common types model. Lou: a few drafts are referring this document, it soon will become a gating document. is it ready for LC? The authors feel it's ready, we'd like to hear comments from the WG and the chairs. JT: To my understanding all the relevant comments from other wgs have been addressed. we'd request yang doctor review. It seems that it is ready for wglc. Transition strategy to the data store. CB: It would be useful to spend 3 to 5 minutes on the history of revised data stores, is it reasonable? Lou: We have spent lot of time on it. As that said, you're the chair. CB: Proceed as you see it fit on this. JT: There are no requirements to change the existing models, it applies only to the new models. Xufeng presenting on the revised data stores. Rob: If we are going to do this, we will end up replicating the containers. Why would you want to do that. It's duplicate effort. This is a nice solution, I like it, but I do not really understand how this is a migration and not an alternative solution? Xufeng: when revised data store is available, this (state container) won't be necessary. it doesn't hurt anything, but.. Rob: Why do I need to support the revised data stores at all? If you look at the solution that we proposed years ago, it has the containers with the state. This does not seem to be a transition strategy, that's the point I want to make. ItÕs an alternate solution. Chris Hopps: The next slide may answer that. Xufeng presenting. Lou: I think Rob's question was on the value of the revised data store. It is a fair point. From my view we want to be able to represent information from the configuration standpoint and retrieve operational information what happened operationally in a clean way by minimizing the amount of redundant schema. That's what revised data store provide us to do. Lou: The intent is to derive the benefit in how we design and build the schema. Yes you can question whether revised data srtore approach is the right approach which is a consensus coming out of netmod. Supposing that we are moving to the revised datastores, what do we do in the interim? Wait for everything to be done? Freeze everything, I hope not. What is the best way to get there? We don't want to stop working while revised datastore is being defined. JT: This is a dialogue, all stakeholders please be open to communication. Shall we support other options? WeÕre listening. Alia: The milestone for revised datastores is very soon, it takes large amount of work for the changes, and the requirements are changing. Can we set a target when revised data stores are coming. Knowing that changes are coming has problems, too. Rob: You are blocking implementing vrfs in schema mount. It does not work in yang1. I am confused by the ietf that you are inventing more features. Two years ago we presented our models how it could work. Revised datastores are not coming tomorrow, it's definitely not coming tomorrow, and the amount of code that needs to be written to support this is nontrivial. Lou: I think Rob you're arguing you want one of the transition approach, the one with config together with operation state. We have a couple of options top include the state, option 1, 2 and 3 can do that. All of those approaches do what you say, just a different way. Number 4 is interesting - there are a lot of models that do not care what the intended vs operational state is, and the ambiguity there is ok. Between now and the time we have revised datastore, you don't have the operation state, but it doesn't matter because you don't care about those cases. In other cases. The question for wg is what of those options we need to adopt as the convention of RTG area. we're not saying don't do anything, we're asking which convention we're going to use and implement. Which convention do you like? Rob: with config and op state? Chris: so Rob, when you objected earlier, your argument is don't switch to a new version because it just looks like an old one. So let's pick one that look like yours so you don't have to change it. Rob: how many hours have we spent on talking on this? Yong Lee from Huawei: Xufeng, I have one clarification question. When we augment TE data model using the revised data store, what's the impact? we have many models augmenting other models, what is the impact? Xufeng: that's why we're here. Last week we were told to do split tree, so the impact is big. If we do the way as shown here, we need to rewrite the models, that will be a big impact. That's why we added other options. Since yesterday this approach is dropped. so don't worry about that, any other options we don't have to do this, we're fine now. Lou: Xufeng, if you were to pick, which way is the right to go? Xufeng: Number 3. Jeff Haas: The reason that we are having this debate over and over again is that there is no single solution. In some certain circumstance, some solution works better. If you have operational state that is segregated anyway you do not need a separate state, and where the configuration is aligned you may need it. There are several ways to structure things. Jeff T: my proposal is to finish the presentations, and we can do discussion later. Acee: There are a number of people writing tools for YANG and there are different opinions on which of those before the revised datastores are better representing their views. There may be diametrically opposed requirements and views. Lou: as a DT we want to come with one proposed solution for the interim with Routing area. Chris Hopps: I have seen only one person coming up with a different opinion. I'd like to see different opinions. We have operators driving this, BT and Openconfig. If there are people that have different opinions they need to start expressing their opinions. Benoit: What is the conclusion here? JT: There are options and we need to get feedback that are best and supported by the majority. Benoit: later or Today? JT: Today they are presented, decision will come later. Benoit: when will it be done? JT: we'll work it in our WG. Alex Clemm: We are facing the same issue with topology models. Based on the discussion we had yesterday, we'd like to go to the revised datastore. JT: The end goal of this discussion to come with a single solution. Hopefully Rob also could be happy with it. CB: as more point of view, we'd make recommendation of a single solution, not mandatory. If someone feels differently then more power to them, Alia: I agree on having the strict rules that ignores the details of the technology is not productive, on the other hand if you let every programmer use their own preferred language, you don't have things interoperate. I prefer to hear - letting engineers pick what they like does not work, If we are able to come to a recommendation that if there are models that do not want to follow the common approach we'd like to see that rational behind. CB: 90% of people do not care what the direction is, just want one direction. For the other 10%, we can deal with that. Lou: The thing to avoid - models depending on each other, if they end up making different choices they will not be able to align. At the last ietf we tried to do it across models across the while ietf, we couldn't do it, so let's do it in Routing area. If we do fail to come up with a single solution, maybe for start for topology models we say that we do this, for routing and signaling we do other thing. At lease we have some consistency with our type model. JT: Lines cut. Xufeng resenting LNE example. 7) 10:30-10:35 - gRPC - draft-talwar-rtgwg-grpc-use-cases 8) 10:35-10:50 - gNMI - draft-openconfig-rtgwg-gnmi-spec Anees Shaikh JT: The following presentations are for information only. Thanks for sharing. CB: We use rtgwg for new work and for informing on the work appearing that is related to rtgwg but not directly there. the draft we are talking here we are not considering for adopting here. Anees presenting: [discussion] Eric Voit: I like what is going on with grpc, also gnmi. It has a lot of functions that are simpler to do over netwcong or restconf. How do we get the work on subscriptions in the netconf to work with grpc? Alia: We know that there are different ecosystems that interested in using YANG for interoperability. It is not a trivial possibility to document in a standard stream and reference it. We are talking about it. Benoit: I agree with you that in the end it is about the modelling and the protocol - you may have different ones. If this for information only, or you would have any interest in the ietf? or is it only in github? We are changing the charter in the netconf. Anees: I see netconf changing the charter to accommodate other network management protocols. This mighrt fit the bill, however we haven't define gnmi as only carrying Yang, at this time we do not have an intention to standardize gnmi in the ietf. There is openness, but from the openconfig perspective and our personal perspective we need much more operational experience with it. ItÕs pretty new, we need lots of experience. We have a bit of time before we consider for standardization. JT: Cutting the lines. EV: I would like to see that we can get a group in the ietf to work on this. Can we get a list of experts on grpc and netmod come together and discuss? JT: There is such interest and this is the intention. 9) 10:50-11:30 - Open Config - what's done/ experiences; what's working, what's not so; how do we work together - open mic Rob Shakir 40 minutes Alia: We have routing yang coordination mailing list that it falling into disuse, which would be a good use of the list to discuss this and also implementation aspects. Rob: We have published BGP model that is widely implemented now. Also the policy model is progressing. We would like to progress those in the IETF if IETF would be interested in progressing them. we're also observing some of the discussions happened, like the config and op state issue. extra library dependency we'd like to avoid. Benoit: Thank you for this. You mentioned few key aspects that models need to work together. Alia is right that if it is not consistent then it will not work. If the metric is the number of models published it is wrong. The metadata of the models is becoming more and more relevant, the catalog work is important on revising the models. It is not feasible to get the model right from the start, we will need to have revisions. JT: Thank you for the comments. We are taking them seriously and intend to work together. ------------------------------------------------------------------ Thursday, March 30, 2017 15:20-17:20 Thursday Afternoon Session II; Zurich E/F RTG rtgwg Routing Area Working Group Chairs: Jeff Tantsura, Chris Bowers WG Status Web Page: http://tools.ietf.org/wg/rtgwg/ JT: Meeting about to start. Note well applies. 1) 15:20-15:30 - update on drafts: draft-ietf-rtgwg-backoff-algo/ draft-ietf-rtgwg-spf-uloop-pb-statement Bruno Decraene 10 minutes Bruno presenting. [preentation] Asking for a LC on thise two documents. [discussion] Les: Curious if you had an opportunity to do test on the forwarding planes that are significantly different? Bruno: There is no default value proposed in the draft, it is network sand implementation specific. Les: It seems that the solution that you delivered here has the most of benefit when you have multiple events i a short amount of time. Bruno: Not necessary. Starting from the first event we need the same delay. Les: most of the analysis that I am aware of - the largest contributor is the control plane. Bruno: We are not trying to make control plane faster. If you want every router to wait for the same time you need a single standardized algorithm. Les: Topology changes in a relatively short time means that some platforms may still be reacting to the first change when the second one arrives. Bruno: It is implementation dependent, in some we consider the first one and take into account others. Uma: How are we taking care of propagation delay? Bruno: Yes and no. No, because the updates are received at the different time and that initial delay is not available. We use the number of events, back off algorithm can be used too. It is implementation specific. We have tried to accommodate for propagation delay, the initial delay to receive the first change. Uma: For RIB delay I do not care too much, incremental changes are there. For multitopology environment this will be important. CB: Please take to the list. Uma: It would be good to cover these cases in the document. JT: We feel that the document is getting ready for the LC. CB: I am the coauthor so I am explicitly recusing myself from the discussion. 2) 15:30-15:40 - update on drafts: draft-zheng-opsawg-network-ai-usecases/ draft-li-rtgwg-network-ai-arch Zheng Yi/Li Zhenbin 10 minutes Dhruv presenting. [presentation] [discussion] Greg Mirsky. Telemetry is being discussed in many different venues. Telemetry would not give you per flow information. How can you map the aggregate telemetry data to per flow data? You may have different classes of service in the network, and in order to find which flow causes the problem - how would you find it? Dhruv: There are various techniques, measurement end to end, for delay the path telemetry os suitable. Greg: It seems that we have a case of terminology. Telemetry is the export of the data if you do not have direct consumer of that data. This is performance, measurement, letÕs use the right terminology. Dhruv: This is information that is sent out from the device, CB: one minute. JT: thank you. It is a good overview of what industry has been doing for a while. There should be a more tangible content for next presentations. Acee: Standardizing use cases may drive standardizing the telemetry aspects. 3) 15:40-15:50 - draft-li-rtgwg-sdni-seamless-mpls-mbh Lu Kai/Li Zhenbin 10 minutes Robin presenting. [discussion] JT: Thank you. JT: a comment related on network slicing - resource allocation will be controlled by either the core side, or radio side. It would be interesting to see how they are allocated, not necessary only why. 4) 15:50-16:00 - draft-templin-atn-bgp Fred Templin 10 minutes Fred presenting. [discussion] Acee: You are using future tense. Is this in the operation? Fred: No, will be by 2020. JeffH: BGP uses TCP, TCP deals with QoS and other transport related things. How does that work? Fred: Transport is reliable ground based network?? JH: ... CB: Are they running BMMP? Routing show before? Fred: Yes. ------------------------------------------------------------------------------------- Alvaro/AD: We have a charter for this WG. One of the things is to evaluate new work in this are, the work that does not necessary fir into other WGs. This WG is for evaluation on what should happen to that work - bof, another wg, nothing, etc. Routing in the DC started a couple of IETFs ago. There was an interim in January where some of the things to be discussed to day were discussed there, with a motivation on why it needs to be done. We do not want to spend a lot of time coma ring whether one is better than the other, but whether there is interest in the IETF to develop something and use what potentially can come out of this. Stewart: This work needs to be a study of a larger scale, which is signaling IGPs. There are 5g networks that are building IGP network of massive scale, there are other areas than DC,. Alvaro: This is an important information. Chairs need to take into account potential other users and synergies. This needs to be resolved in the WG first and then reported to RTG area. JT: There is a lot of commonality network DC and mobility use cases. CB: Can you also specify there this work is being done, could you provide any links? Shawn: There may be a different thought process required for the requirements of the DC specific aspects. maybe there needs to be a dedicated charter that is operator driven that focuses on the DC aspects, interop. Stewart: I know that this is a demand from people doing 5g, I do not know of any organization that is doing this. Alvaro: We likely can tweak existing or future protocol based on requirements. First we need to have the requirements, otherwise it is difficult ot work on something tangible. Possible outcomes - yes, we might do a new WG. That WG needs to have a charter. That could be one of the potential outputs. Another output - if we focus on solution X, that could be worked in a specific WG. This is the second time that we are having this conversation, even thought that this is the function of this WG, we do not need to exercise that much. It is about having the right solutions for developing such solutions. The question whether we have enough people in RTG and IETF to review all possible solutions. Stephen: There is an order or magnitude more hosts in the network and that might be a starting point. We need to think about the incoherent operation of ten systems, it work well as long as it is coherent. We designed things 35 years ago and now we have much better understanding on many aspects, Alvaro: Chairs need to coordinate this and come with an answer. ------------------------------------------------------------------------------------------------------ 5) 16:00-16:10 - ISIS in Spine-Leaf - draft-shen-isis-spine-leaf-ext Naiming Shen 10 minutes Naiming presernting. [discussion] Shawn: Do you have any fragmented or disjoint CLOS topology in your slides? Naiming: No. Shawn: If spine loses connection to one of the edges, does it stop sending to everybody? Naiming: We will cover that in other slides. Shawn: Sending default in the fragmented topology - you either have all the routes, or miss some, as you cannot have a default any more. JT: 2 minutes. CB: We have used the question time. 6) 16:10-16:20 - BGP SPF - draft-keyupate-idr-bgp-spf Acee Lindem 10 minutes Acee presenting. [discussion] RobertR: In modern DCs compute nodes are L3 devices, and I am running routing to compute nodes. How in this model am I supposed to advertise reachability? Acee: Do compute nodes have full set of routes? RR: They advertise a set of routes, or could advertise a default. Acee: They do not need to be part of SPF underlay that would be a form of service. RR: They can be part of overlay but do not need, solutions like Calico are attractive just because of that. Acee: Running dynamic routing protocols just to inject to the flat network - yes you can do that as well. It would be like a route redistribution in igp. Uma: One of the changes is to flag the SPF run? Acee: Yes, just to determine that you have the up to date versions. Uma: This is the fundamental change to BGP, maybe you may want to use a different port? for some address you are using bestpath, for others you do not. Acee: You deluxe base don AFI./SAFI value. Uma: RussÕs proposal is very modest, maybe you need a different port. Acee: We separate by address family. IgorG: Trying to understand =- the difference between traditional CLSO architecture, are you trying to minimize the amount of sessions from each node and converge faster - is that the only advantage compared to traditional BGP full mesh? Acee: Yes. There are other too. You need to be able to do fast rehashing of your ECMPs in your CLOS topology. BGP SPF is targeted to DC topology, later it can be applicable to other deployments too. Microlooop avoidance is still a consideration even in CLOSW. Igor: If you design it correctly it is not a problem, there are two ways to design it, one that has this problem, the other that does not. JT: Would be good to provide the pointers,. Igor: It seems that you are trying to solve a problem that does not exist. I cannot tell you the exact topology but may show the device utilization., JT:L Would be good that the author group comes with a solution proposal. 7) 16:20-16:40 - Open Fabric - draft-white-openfabric Russ White 20 minutes Russ presenting. [discussion] IgorG: This works for CLOS topology only. RussL: It has to be 5 stage. Draft talks about 3 stage and you need to specifically configure it. Igor: Many of us have done such topologies since 2011. Tor topology. Russ: I am not certain whether butterfly type of topologies would not work. Igor: I am not certain whether we need to solve yesterdayÕs problems tomorrow. Russ; Hypercube topologies - that is interesting, letÕs talk offline, RR: I have the same question as to Acee - how do you advertise dynamic reachability to servers in this case? Russ: I will run dynamic reachability to the servers. RR: Would be good to have uniform end to end story. Uma: I like the part where you do the reroute. Minor comment - what you do if you have parallel adjacencies? Russ: Valid comment. Igor: There is a chipset modification that was required to use the alternate forwarding modes, but now when that modification is about to ship it is possible to do that. In my CLOS design it is not multi tier, it is multiple dimensions. Use it, then have a clos of closes. Russ: many years back we did a PoD design using hypercube. Shawn: in addition to what Igor said, it makes sense for us to have a topology in each layer. Russ: We do not aggregate, we want full routes. 8) 16:40-17:00 - RIFT - draft-przygienda-rift Tony P. 20 minutes TonyP presentimg. [discussion] CB: 4 minutes left. CB: Alia has asked me for 5 minutes to conclude and provide the next discussions steps on YANG discussion. 9) 17:00-17:20 - Routing in DC - open mic 20 minutes CB: 4 minutes on DC discussion. Igor: This is cool work. You mentioned that noone does the same level connectivity - that is false. TonyP: I said vast majority does not, it is my data set. Igor: Some people do, short or long lived. There may be topology change cases that requires it. Tony: I do support leaf to leaf. Igor: You mentioned everyone goes up. That is not the case. Tony: That is a misunderstanding. Igor: We are talking about close that we started using in 2011, many of us are looking into next things, esoteric topologies that eventually will ship. Dragonfly as an example. Tony: As long as we know what those topologies are then we can try to make it work. Igor: By the time this is standardized, coded, and deployed we already may be on the other topology. CB: Would you be willing contribute to the requirements document? We would appreciate your input. Not necessary debate on the list but to guide out evaluation process. Ifor: That would be my requirements. JT: That would be very valuable. Based on your requirements people can base how other people may base their design on. Tony: I worked towards what the pain point are, and 100% of pain points are with fat trees. JT: Igor, please share the information. Igor: This seems to be an odd problem. BGP works today, not certain whether that will work tomorrow, but we should not optimize for yesterday. CB: Please specifically describe what you need. JT: Please also ring in hardware people. DY/Yandex: it is more about routing in the DC - would be interested to start a group on the requirements and topologies, hierarchical boxes now becoming inexpensive it looks that a need for topologies that are not clos is coming down, you can do 95% of use cases with 2 or 3 spine layer fabric. JT: request to you - please document the requirements. ------------ Alia: A quick update on context on YANG, One of the questions we had was how should we handle operational state. We have several options for recommendations. We need to nail down the detaisls for some recommendations. This conversation should go on the rtg-yang-coord as well as rtgwg. We have recommendation on having state and config trees, and that is what we do not think how models should look like going forward. We have separate -state and -config trees, that is not the direction. WeÕre not going to block existing work, but we'd like to see them being enchanced. we're going to send out details later today with details. We talked about the old train, we end up with duplicated data. Two trains are coming - train 1: you can sprinkle containers with config true/false noses through the tree. Train 1 means we can write code today. We need implementation experience and see the interactions. Train 2 has the revised datastore dependency. That is the future. We are looking into definitions defined in 2-3 months, but it will be 9 months before it is stable. Operational state is the longer horizon. Some models do not have dependency on the operational data. If your model does not depend on operational data you can go directly to train 2. None of this is you must do it, some of this is we're learning experience. We will get more discussions on the mailing list. Questions? CHopps: Transceiver power example - if I set it up somewhere, it is not necessary that it is the actual value is the same, I will read it from the actual value. Kent: 6871bis will be updated. It will be sent to netmod and ccd here. Alia: we put all this together quick. WeÕll look at phrases we want to use to clarify. Xufeng: for train 1, Deprecation is obvious but destructive, we need to put a new revision of the model. We have two other options mentioned yesterday. State containers would be less disruptive. Alia: I think we are looking into containers for deprecation- one of the tricks with this is that we need to have implementation experience. CB: Taking offline. Session is closed. Alia: If there is concern let's talk. JT: Xufeng presented 4 considerations yesterday on how to proceed, please take a look. Thanks you and see you in Prague.