Routing Area Open Meeting (rtgarea) IETF 94 (Yokohama) Agenda Monday, November 2nd, 15:20-16:40 Chairs: Jeff Tantsura, Chris Bower Scribe: Acee Lindem (acee@cisco.com) WG Status Web Page: http://tools.ietf.org/wg/rtgwg/ 1) WG Status Update (See slides) Jeff Tantsura, Chris Bowers 2) BGP Flow-Spec Indirection-ID Redirect (See slides) draft-vandevelde-idr-flowspec-path-redirect Gunter Van de Velde Robin Li: How is the Indirection ID allocated? Gunter: Depends on the usecase. Robin: What is the usecase. Keyur Patel: Envision multiple hetrogeneous forwarding planes. Provides a tunnel abstraction layer through the Indirection ID. Robin: Indirection ID configured on controller? Gunter: It can be manual config or orchestrated. Robin: Has concerns with deployment? Segment Routing tunnel provisioning has been proposed in SPRING WG. Alia Atlas (No hats): Indirection ID - Is this exactly the same as the Nexthop ID defined in I2RS RIB model. Should be aligned with this model as it solves the same problem. Wim Henderick: This can be more than jsut the nexthop. Keyur: The Indirection ID may not be ephemeral like I2RS Nexthop ID. Jeff (No hats): Seems to be a Policy ID rather than an Indirection ID. We need to work across WGs to define routing policies. 3) BGP Prefix-Independent Convergence (See Slides) draft-bashandy-rtgwg-bgp-pic Ahmed Bashandy Tony Przygienda: Interesting work but what track? Ahmed: Written as informational. Jeff: Should be informational. Need to add more use cases to the draft. Tony: Definitely a good document to educate service providers. Ahmed: BGP multipath is a bigger discussion and did not want to get into it in this level of complexity in this document. 4) Microloop Avoidance Segment Routing draft-hegde-rtgwg-microloop-avoidance-using-spring Pushpais Sarker Anil Kumar: Why does it loop since the backup is an LFA? Pushpasis: The micro-loop is post convergence. Tony: How would trigger cut-over to SR tunnel? Acee Lindem: How do you avoid microloops when the nodes return to the routed path? Pushais: It works. Jeff: Service Provider - would you be willing to deploy something like this? Bruno Decraene: Yes we need a solution for microloops avoidance, otherwise negates the benefits of IPFRR. Jeff: We all agree we need a solution. The question is at what cost? I would really like you read the draft and see if it’s applicable and be willing to deploy something like that. Acee: I now see that this will work since after the convergence delay since there is no loop for either the tunnel to PLR path or post convergence path. 5) Segment Routing MRT draft-agv-rtgwg-spring-segment-routing-mrt Anil Kumar S N Chris Bowers: Have some comments to share offline. 6) YANG Key-Chain Model draft-acee-rtg-yang-key-chain Yingzhen Qu Jeff: Will be presented in Security Open Meeting. Acee: New features are the result of discussions with Brian Weis. Dan Bogdanovic: Lifetime will be in reusable type. Acee: Needs to meet our requirements for a key lifetime. Yingzhen: Will look at incorporating model. 7) RIB Extensions draft-acee-rtgwg-yang-rib-extend Yingzhen Qu Jeff Haas (I2RS Chair): I2RS Model models have a lot of overlapp. Please talk to the authors for alignment. Dean: Look at device meta-model. Jeff: Augment with weight. Dean: RIB Model - Make it less layer 3 specific. Yingzhen: We will work to align all the RIB models THURSDAY, November 5, 2015 1520-1720 Afternoon Session II Room 304 RTG rtgwg Routing Area Working Group WG Chairs: Jeff Tantsura, Chris Bowers WG Status Web Page: http://tools.ietf.org/wg/rtgwg/ 1) draft-liu-rtgwg-yang-vrrp (See Slides) Xufeng Liu Jeff: How many have read? Jeff: Please review the model. VRRP is deployed all over. 2) draft-liang-rtgwg-staticrt-yang-cfg Gang Yan Jeff Haas: Lots of existing work. Sue: I2RS model covers all this - why are you not looking at this model? Jeff: Please look at existing work in this area. 3) OpenConfig models (See slides) Anees Shaikh -- draft-ietf-rtgwg-policy-model -- draft-openconfig-rtgwg-local-routing Jeff Haas: Why is this not extending ietf-cfg? Alia Atlas: Please look at the I2RS RIB model. It covers policy. Anees Shaikh: Where does it this overlapp? Sue Hares: Can help with I2RS RIB model. Alia: It has what is needed. Rob Shaikh: OpenConfig is focused on the operational models SPs use for managing their networks. Anees: We have looked at the RIB model. Robin Li: Need clarification on I2RS models? Anees: Can not answer that question. Derek Yeung: Question on policy - where is the instance identification in the policy model? Rob: Doesn't support this yet. Do we generically do it or do we do it in protocols using the polies? Jeff Tantsura: Needs to add more notifications when a route goes away. Anees: Continuing to modify model. -- draft-openconfig-rtgwg-network-instance Rob Shakir Jeff Haas: Both models have context. Rob: Goal would be to support both of them. Jeff: Default become difficult. Rob: Defaults are not specified. Jeff: Does it make sense to have two models for slice of routes and operational route table. Acee: Can we do this with one model for a device? Rob: It will be very difficult to align a complex device with ietf-routing? OpenConfig needs to get this out there and get experience. Alia: We know there is complexity and we need experience in deployments. Maybe we should target different ranges of functions. Rob: Maybe we can provide some use cases. Kireeti Kopella: Very supportive of this work. You say you aren't asking for adoption but in essence you are. Are you asking the IETF to throw away what has been done so far? Alia: It is possible that some models are applicable in areas and not others. The IETF is where we come together and ask for consensus. Kireeti: Potentially we should throw away the IETF models? Maybe you should provide a vendor neutral model? Rob: This is a usable set of functions. 4) 16:05-16:25 - unified tunnel model discussion -- draft-li-rtgwg-utunnel-yang -- draft-li-rtgwg-tunnel-policy-yang -- draft-wwz-netmod-yang-tunnel-cfg -- draft-zheng-intarea-gre-yang -- draft-liu-intarea-gre-tunnel-yang -- draft-liu-intarea-ipipv4-tunnel-yang Zhenbin Li Jeff Haas: Unification is needed? Have you presented in INT area and SEC area? David Black: What is an IP tunnel? Robin: Tunnel with IP encapsulation. David: An IP tunnel is defined by having an IP header? Go to the INT Area. Is there an IP endpoint at ingress? Many tunnels with UDP tunnel in the shim. Jeff: Take other questions to the list. 5) 16:25 - 16:35 - draft-chen-rtgwg-resource-management-yang Xia Chen Acee: There is overlap with the SR YANG model. Xia: Does cover all the usage of labels. Robin: There are requirements for management of resources that span multiple WGs. Will send mail to the RTGWG list. Dean Bogdanovic: Is this for resources on the device or in the network? There are many ways to view this. Lou Berger: There is already work in MPLS and TEAS for label management. 6) 16:35 - 16:50 - draft-mwnpkazcap-rtgwg-common-oam Greg Mirsky Yuji: How does this relate to the LIME WG? Greg: The charter of the LIME is data model. This is about creating protocol instruments? Alia Atlas: This is protocol work and belongs here in Routing. Tony Prygienda: For technology to be successful, OAM is critical. It won't be easy and support this work. Greg: Come to BIER to discuss OAM mechanism resulting from recommendations of the DT. Chris Bowers: Overlap of LIME is not just YANG model. They are also chartered to do an OAM architecture. Alia: The right thing to do is to get the design team going on the OAM work for the different encapsulations. I'll discuss where to do it with Beniot. 7) 16:50-17:00 - draft-nitish-vrrp-bfd Greg Mirsky 8) 17:00 - 17:20 - Routing YANG DT update draft-rtgyangdt-rtgwg-device-model Acee Lindem Robin Li: this work of consolidating the models is important. Would like to clarify the network instance part, and service related aspects - QoS, etc, and how that maps to the network instance? Acee: [...]. This is on a logical element level, and then you bind that to the logical instance context, as it needs to have address, interface, etc defined. have you looked into the draft? Robin: not the latest. Alia: this is good work. Eventually there will need to be things other than routing. Trying to define all is a large job. We need to get some consensus on how to integrate other things from operations side into this. Acee: the logical network changes define the amount of work in structuring the model, how to augment it, Lou: we are discussing that with people outisde RTG already, that has been discussed in netmod. There are some things happening in parallel. There is a big issue how long we wait for the right answer vs the current answer. Chris Hopps/DT: we discussed that in netmod, and they think that we should not have everything underneath. There is an ed to have things that just work, but that will reuqirem changes. Lou: we will likely end up doing two parts at once and see which works; Dean: if you have one device and separate management domains ...... Lou: last 4 speakerts were DT memebers JeffH: I am not a DT memeber. Issue with openconfig - community based view of teh system. In SNMP there is a problem of addressing the instance. Second problem - there are SNMP systems that have multiple FIBs?? and relaying between them is tricky? [???] Acee: proprietary community strings ... JeffH: Would suggest to have individual moudules and make those multi-instance Lou: we should have a long discussion on that, JeffH: you may need something much lighter for that. You will have a view of the networkm a view of interfaces, a view of BGP, etc, Acee: that does not exist today? Alia: two things - 1. it feels that there is a lot of concern on structure. Loa: we need what I call sun? ? Alia: getting perfect organizational structure will be infeasible. Contention between different models not being able to reference other models? Differentiate models per device class. Alia: 2nd point. This is important for operators. You may nit be happy about reviewing YANG, but please contribute. Dean: DT is heavy on vendors and extremely light on operators. Lou: is you are an operator and you acer about it , wou would like to hear about this. There are many constrains, this is not greenfield design. There are tradeoffs between havig somethign soon vs having it perfect. Major point - how we satisfy both the LNEs and .... . We will continue documenting the LNE approach. Also we would like to get an answer that addresses ChrisB: operator wants to make a comment, we are out of time. Ruediger: looking at the many dioscussions that we had in this sesion I see some indications for part of the community is still learning the technology. For operators, they are more of the leading edge? than on the trailing? A bit more of consideration that can be adapted as we are learning would be adequate than saying 'speak now and close your mouth forever later'. Lou: the approach of solving the problem without the beaytoiful stricture would be definitely good. JeffT: out of time, ending session.