Monday, July 20, 2015 09:00 - 11:30 Morning session I Chairs: Jeff Tantsura, Chris Bowers Scribe: Ignas Bagdonas ibagdona@gmail.com 1) 09:00-09:10 - WG Status Update Jeff Tantsura, Chris Bowers 10 minutes Jeff Tantsura: Status update. Acee: We got protocol extensions for advertising protocol extension parameters - will that go to last call soon? Jeff: Yes. Acee: Will get some more people to look at that in OSPF. 2) 09:10-09:20 - draft-liu-rtgwg-ipipv4-tunnel-yang Helen Chen 10 minutes Helen presenting. [presentation] This is YANG model for IP to IP tunnels. Relationship to other models. It is an independent tree, linking to other models of interfaces and routing. Overview of model structure. Augmented with a leaf to indicate the actual operational parameter showing the type of the tunnel. Next steps: we plan to work with authors of both drafts and merge them. [discussion] Acee: I noticed the concept of binding interface where you bind on the RFC 7223 interface list. That seems to make an assumption that interface itself is going to be a tunnel. Shouldn't they be parallel instead of binding to the interface list? Acee: The other thing is an example of referencing the routing instance from the tunnel, and there are different ways of doing that. Helen: The binding interface - I do not agree whether ietf-interfaces is about physical interfaces, that may be more than that. Benoit: Yesterday during YANG editing session we were reviewing one tunnel draft. Do you want to have a typedef to define a tunnel type? Helen: Probably you are talking about this document. We will take care of it in the next version, I agree it should be a typedef. I do not know whether it is the right way to do as it makes configuration more difficult. Helen: This structure will end up allowing to do that. Jeff Tantsura: Good to see this being discussed on the list. Alia: Tunnel work belongs to intarea mailing list. Stephane Litkowski: It would be better to augment the current tunnel document than trying to create this binding interface. Helen: Will look at that. Chris Bowers: Question to Alia - it would be useful for people to know where to bring the work in the first place, is it here or is it in INT-area? Alia: IP in IP tunnels belong to INT area. Checked with Brian to confirm that. This is about the coordination. 3) 09:20-09:30 - draft-chen-rtgwg-key-table-yang Helen Chen 10 minutes Helen presenting. [presentation] [discussion] Acee: This model still augments the key chain model? Helen: No. Acee: I still think it would be better if it does. This will allow to attach policies in a similar way as we do with ACL, routing policy. Versus the security database model where the database is the center of the universe and everyone has to query that. There will also be a difference in adoption - one will be tens of thousands, the other will be just on paper. Helen: I guess you can map them one to the other. Key chain is restricted to a small set of routers as it is designed for IGPs. Acee: No. It is a generic policy that you can attach to any protocol. Helen: But it does not have what other protocols will need Acee: I agree that some things will need to move to key chains. I do not agree that because if you allow all the details of the security policy, that it will permeate better. Acee: In key database model you start with security, and everything is derived from there. In the chain model, it is a policy in places where it is needed. Jeff Haas: There was KARP work that was trying to provide a unified security model. The intent in RFC 7210 is not necessary what the user will have to interact directly. How are you expecting people to interact with it? Joel Halpern: When we did RFC 7210, it was an abstract model. There were questions on how to enable automatic key management. At that time it seemed good to base that model on the key tables. KARP work itself was that it will get the model as this one. Jeff Haas: I agree, it has a flexibility to do that, but writing a model to interact with it, there may be cases that require splitting the configuration elements into RFC 7210 full table and then fragments. Uma Chunduri: Thanks for doing the work on mapping analysis. What is your conclusion about the mapping? Do both have to exist, both have to match? What is you conclusion? Helen: I think only one needs to exist, both can exist, but one is needed. Jeff Tantsura: Please take to the list for further discussions. Acee: Please bring your key tables implementation to the list. 4) 09:30-09:40 - draft-liu-rtgwg-yang-rip Xufeng Liu 10 minutes Xufeng presenting. [presentation] [discussion] Acee: You asked me for comments, apologies for not getting back. I think it is good to use keychain for this too. Xufeng: We are using the same thing as OSPF does. Jeff Haas: Wearing my BFD chair hat. BFD WG thinks that they have model that can be used by other groups, my sense is that you can use it, and provide feedback if something is missing. RIP might not be the sexy thing to do, but it can be seen as a simple testing ground for trying new functionality. Acee: I see your draft still uses the inline method? Xufeng: We use the group. Acee: That seems to be different from the OSPF then. Jeff Tantsura: From my perspective this is one of the most complete drafts, and we are getting closer to a WG adoption. 5) 09:40-09:50 - draft-acee-rtg-yang-key-chain Yingzhen Qu 10 minutes Yingzhen presenting. [presentation] [discussion] Acee: We should add attachment point to our operational state, where the policies are actually used. In my first implementation of policies that would be easy to get, not sure about the three implementations that I have now with Cisco. Maybe use an opaque string for attachment policy as opposed to break the hierarchy that is in the key table? Another thing - if you are going to put key derivation into the chain, that will be difficult, and not clear whether anyone will use it. Maybe leave it until then? Yingzhen: There will be discussion about operational state in this meeting, so we expect to have the answer then. Acee: Some key people have not come to Prague, so that will likely not happen here Jeff Haas: For all of our drafts we need to decide on structuring the things. Try to visualize how the CLI at the least will use it. To get a minimum amount of related information. It is possible to put a large amount of information, and then correlate it. Yingzhen: We tried to provide all the necessary operational state already. Jeff Tantsura: Who has read the draft? Who think that it is ready for adoption? Please take to the list. Jeff Tantsura: Has your comment been addressed: Joel Halpern: Yes. 6) 9:50 - 10:00 - draft-shaikh-rtgwg-policy-model Ina Minei 10 minutes Ina presenting. [presentation] [discussion] Jeff Haas: I have read BGP model, reviewed the policy model too. I believe that this draft is the most mature draft in terms of structure. I would urge WG to pay attention to what is BGP specific, some things are tricky to do, as an example extended communities. Ina: Jeff, question for you - which WG should be used for that? Jeff Haas: Many routing implementations use BGP policy for their plumbing. BGP must have those things, many other components need it too. Someone will need to coordinate the BGP policy model as seen here with a routing config model in netmod. Jeff Tantsura: Agree with Jeff's comment. Stephane Litkowski: This is a good work. You are trying to define IGP actions, but you define nothing about BGP. What is the boundary, what should we do about IGP policy extensions? Where do we do IGP extensions - here, or somewhere else? Ina: That is a good point. Stephane: The usage of tagging - for me a tag is a local construct, it is not an IGP action, maybe it would be good to extend it. Ina: Ok. Acee: I like the fact that we split the BGP part from generic policy part. Apply construct seems to be a good idea to use BGP policy and apply it via the attachment point. Jeff Tantsura: Who has read the document Who think it is ready for WG adoption? Really encourage to read it, it is what operators use. 7) 10:00 - 10:10 - draft-li-rtgwg-utunnel-yang Zhenbin Li 10 minutes Zhenbin presenting. [presentation] [discussion] Jeff Haas: You seem to provide a very generic framework to define tunnels. We saw IP in IP tunnels presented already, MPLS and TEAS will have their own models for their tunnels. Do you see this more of a framework of the tunnels, or more from an operational perspective? Zhenbin: We focus on tunnel group and to apply that to multiple tunnels for management purposes. Jeff Haas: It seems that you are focusing on one use case only, and my recommendation would be to take a look at a broader set of use cases and make it more generic. There is a lot of activity in work on YANG for tunnel management, LIME is trying to do some work on tunnels too, it seems you are taking an aggressive piece of work to do. Ron Bonica: You are trying to abstract elements from different types of tunnels and then abstract them. Does that belong to RTG or INT area? There is a mix of forwarding and signaling elements here. Did you try talking to tunnel design team? Ron: The thing that you call the tunnel policy - that seems to be routing policy in fact? Will ?/NTT?: Different tunnels have different technologies and attributes. Is it necessary to abstract them so much instead of having separate models for each tunnel type? Zhenbin: The attributes for tunnels are simple, and therefore we propose to abstract them. Also we focus on operational side of tunnels too. 8) 10:10 - 11:30 - Routing YANG DT draft-rtgyangdt-rtgwg-device-model 80 minutes Lou Berger presenting. [presentation] There is a wiki. Work is done on github. Overview of the overall structure. Reasonings behind why certain things are done in a particular way. Zhengbin: A VM based device is still a device. Also L2VPN and L3VPN is a service, why do we refer to L3VPN as a logical network element? Acee: Think of it along the lines that a VPN is more than just a VRF. Loa: Different implementations will do things in different ways. Dean: Physical element provides you data plane separation, logical elements provide separation of management. You can have default logical element that can be instantiated multiple times. Andrew Dolganow/ALU: is it possible to share the logical and physical entities together? Lou: I think that depends on the implementation. Erik Nordmark: Container vs VM - in the end both can be shared, that is a different way of implementing things. Loa: if you are in a containerized environment, the difference is in what host sees. Within container it is easier to see other entities than in VMs. Jason Stern/ALU. I am struggling with the logical element concept and how to put that into model. Do we really need to put logical element instance into the data model? The second thing about the physical devices - that may end up as needing to define model for every single device, that may be a scalability issue. Maybe keep it outside of the scope of the model, and maybe have multiple different NETCONF sessions that provide a different context for different logical elements? QoS is also outside - what to do in order to refer to them? DNS policy is another example. Loa: I would like to go through those point by point. Liu Bing/Huawei: The network instances represented by VLAN - I think network instances should include VSI too. Loa: We haven't gotten into detailed conversations yet. Jeff Tantsura: Would be good to give possibility for authors to continue with the slides before discussion. Acee presenting. Lada: There is one substantial problem with this approach - ietf-interfaces is designed to be a top level container, and you have it shown as a second level. Do you intent to change RFC 7223 for this? Maybe YANG mount or graph would be an option that could solve this? This was one option considered for YANG 1.1 but was abandoned. Acee: We didn't really constrain ourselves where things are today. In the design team we tried to align the existing work to this meta model. Lada: I think it was Andy Bierman who proposed feature like root. Then there was any-data which is not as useful. Chris Bowers: Previous questioner had a comment of 90% of uses of this would be getting to default routing element and default routing instance - maybe it would be better to make it easily accessible from the top level? Acee: We thought that there are multiple use cases for that. There is more functionality than we show here. Chris Hopps: Adding complexity for the common use case is annoying, but there is another aspect too of having to add lots of complexity to support the different functionality. Zhengbin: Regarding network instances - example L3VPN, VSI belongs to one the same instance, or to other? Acee: That depends on the implementation. Zhengbin: You have RIB in your model? Does that include MAC RIB too? Acee: This will be answered in following slides. Igor Bryskin: In your opinion, is I2RS agent associated with network instance, or network element? Acee: Instance Dean: The agent is running on the virtual network element, and you run agent per virtual element, or per device - that is management separation. Igor: But that is not what Acee said. Loa Andersson: IS-IS and OSPF can be used for TE, is that covered in the corresponding models? Lou Berger: IS-IS individual draft includes TE, Loa's question was for the WG drafts. Acee: True, I only looked ad a subset of drafts. Lou: We need to clarify how each policy element will be used. Lou: Addressing Robin's comment - I thought we had it in the drafts, we talked about it, and now checked and it is not there. That is coming in the later revision. Chris Hopps: An example of copying routes from unicast RIB to multicast RIB. Jeff Haas: There can also be metaprotocols for copying RIBs, other things. Dean: A comment on role based access. NETCONF has NACM, and that should be used. [discussion] Chris Bowers: How logical network elements and network instances would look in the case of PE peering with CE using OSPF and then running over RSVP-TE tunnels? Where is the hierarchy defined, how it would look like? Lou: CE will have single logical element and single instance. PE in the context of that single CE will have a logical network element. Then per VRF each of the instances that contain the CE. Chris: Where is IS-IS and RSVP come into picture? Lou: You would have a special instance that represents the core. That is a good walkthrough example that we should do in the draft. Jeff Haas: I think this aligns well with what a lot of people do. Having been a victim of MIB wars, there are a lot of things organizationally great but not necessary get mapped well into mapping into the tree. Jeff Haas: MIB-2 tree was an attempt to structure that, but in the end of the day people were just getting node points without caring much where you will end up in the tree. Similar risk is with YANG now. A lot of these things are structured naturally, but many of them (an example of mythical /device) may not. Chris Hopps: One of the goals was not for CLI, but for automation. Lou: Have some sort of inventory. Jeff Haas: The problem where things start to break is in handling different revisions of models. Components need to be revised, and then the hierarchy starts to break. Benoit: As an OPS AD: This is really good work. Jeff Tantsura: We can have additional 15 minutes on Wednesday for discussion. Wrap Up ------------------------------------------------------------------------------------------------------------------------------------ Wednesday, July 22, 2015 09:00 - 11:30 Morning session I Chairs: Jeff Tantsura, Chris Bowers Scribe: Acee Lindem acee@cisco.com 1) Update on MRT work draft-ietf-rtgwg-mrt-frr-algorithm draft-ietf-rtgwg-mrt-frr-architecture draft-bowers-rtgwg-mrt-applicability-to-8021qca Chris Bowers * See slides Loa Andersson: The LDP MRT draft is in MPLS WG. Do you think the algorithm draft is mature enough to progress the LDP draft. Chris: Expect to progress the architecture and algorithm drafts in next couple months. Loa: Please inform the MPLS WG when this happens so we can progress the LDP MRT draft. 2) Source/Dest Routing draft-lamparter-rtgwg-dst-src-routing David Lamparter * See slides Chris Bowers: Homenet needs this but it is not within their charter. Routing WG will call for adoption in the next couple weeks. Jeff Tantsura: Need to have a deterministic method for recursive route look up. David: I plan to cover the recursive lookup case. 3) VRRP BFD detection draft-nitish-vrrp-bfd Nitish Gupta * See slides Santosh Easale: How do you insure VRRP backups are in a consistent state? Nitish: Must fallback on VRRP advertisements. Jeff Haas: You are limited by the VRRP rate for convergence. Santosh: Need to document how this is handled. 4) BFD for P2MP VRRP User Case draft-mirsky-bfd-p2mp-vrrpuse-case Greg Mirsky * See slides Jeff Haas: VRRP gaining traction in data center. BFD should follow the data plane path it is protecting. Greg: Agressive timers in VRRP will expose you to problems with multicast. Jeff: Explore using VRRP/BFD with link-local multicast. May want to merge the draft. Greg: Good suggestion. Could do better with IPv6 since it includes link-local scope. 5) UDP Overlay Transport for NSH draft-kumar-sfc-nsh-udp-transport Larry Kreeger * See slides Alia Atlas: Complexity of draft is around how it is going to interact with the security considerations. Have been talking to SFC chairs. The draft is probably better in the SFC WG. Jeff Tantsura: So SFC will update charter to allow this? Alia: Yes - if necessary this is what wil be done. 6) Microloop Problem/SPF Backoff draft-ietf-rtgwg-backoff-algo Bruno Decraene * See slides Jeff Tantsura: Document updates are a significant improvement. 7) Virtual Multi-Instance draft-hegde-rtgwg-virtual-multi-instance Shraddha Hegde * See slides Greg Mirsky: Propose to be applicable to IS-IS and OSPF? Why can't you use NBMA to reduce flooding? Acee: NBMA doesn't reduce the amount of flooding. Operators don't want thousands of areas. Shraddha: Configuation is zero-touch and areas per remote would not work for IS-IS. Les Ginsberg: What do you want the IETF to standardize? There are conceptually similar solutions? Shraddha: Procedures are necessary on border routers. Default behavior needs to be standardized. Pushpais Sarker: Border readers need to agree on behaviors. Jeff Haas: Operational practices needed to solve this problem. Similar to GROW for BGP. Allows multi-vendor environments. Uma Chunduri: Need to describe hub behavior. IS-IS has flooding scope RFC. This is required? Shraddha: Yes. Alia: Both hubs need to advertise the links between them. How do you identify the hubs in this topology? Could be done with vitual areas as opposed to be virtual instances. Les: Believes there are existing solutions using this technique. Nothing to be standardized. Acee: Declares knowledge of IPR on similar technique to do the isolation in IGPs rather than with a separate instance. http://www.google.com/patents/US20140010117 Jeff: Go to IGPs for review. 8) IGP bandwidth-based metric draft-spallagatti-rtgwg-bandwidth-based-metric Santosh P K * See slides. Chris: Why is there a list of bandwidth prefernces in the draft? Santosh: Just a choice - open to suggestions. Uma: Not needed in draft - internal detail of implementation. Jeff Tantsura: Would like to see discussion of this on the list. 9) Routing YANG DT draft-rtgyangdt-rtgwg-device-model Lou/Acee Lou Berger, Acee Lindem, and Chris Hopps reviewed design team next step slides. Disagreement expressed among DT members on opstate discussion in netmod. Jeff Haas: Summarized tradeoffs for where to place operational state in yang model. Advice to DT and Yang models is to put both config and operational state in models. Expect to have to change the placement of information after openconfig and netmod come to an agreement, but don’t let that hold up the basic work to address use cases. Igor Bryskin: Asked Acee for clarification on his opinion on openconfig opstate proposal in netmod. 10) Encapsulation Considerations design team update draft-ietf-rtgwg-dt-encap Erik Nordmark * See slides. Jeff Haas: Are the OAM packets privacy impacting? Erik: Why is this a problem? Jeff: End user cannot tell the mechanisms being used to monitor your tunnels. Erik: Think I understand but don't have an answer. Will need to think about it. David Black: If you use UDP source port for entropy, then your packets are not reversible. These are transport issues. Erik: Changes path but doesn't blackhole the traffic. David: There are potential issues. Greg Mirsky: You need to support in-band OAM. MPLS has this. Erik: This has come up in other contexts. David: ECN congestion text is MPLS specific. Need pointer to Transport area document. Jeff Tantsura: New protocols and encaps need to read this. Especially within SFC and NVO3 WGs. Would like Alia to talk to transport area. Alia: Need to send Transport Area an E-mail indicating that it has been adopted and another when it is submitted for publication. Lou Berger, Acee Lindem, and Chris Hopps reviewed design team next step slides: Disagreement expressed among DT members on opstate discussion in netmod. Jeff Haas (Juniper) summarized tradeoffs for where to place operational state in yang model. Advice to DT and Yang models is to put both config and operational state in models. Expect to have to change the placement of information after openconfig and netmod come to an agreement, but don’t let that hold up the basic work to address use cases. Igor Bryskin (Adva) asked Acee for clarification on his opinion on openconfig opstate proposal in netmod.