Minutes for RTGWG at IETF-95
minutes-95-rtgwg-4
| Meeting Minutes | Routing Area Working Group (rtgwg) WG | |
|---|---|---|
| Date and time | 2016-04-08 13:00 | |
| Title | Minutes for RTGWG at IETF-95 | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2016-05-17 |
minutes-95-rtgwg-4
Routing WG Minutes THURSDAY, April 7, 2016 10:00-12:30 Morning session I Room Buen Ayre C Routing Area Working Group WG Chairs: Jeff Tantsura, Chris Bowers 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 Chris: Refer to RTGWG Wiki https://trac.tools.ietf.org/wg/rtgwg/trac/wiki Send Email to Chairs for questions Chris: Looking for WG participants who want to be document shepherds. Acee: Where are the MRT documents? Chris: Approved by IESG and in process of being published. Acee: What about our SPF delay drafts? Chris: Covered in slides in context of uloop-prevention. Acee Lindem/Cisco: in OSPF we have MRT document relevant to MRT - I did not see MRT document on the status? Chris: They are approved and are in AUTH48. 2) Discussion of multi-homing for provider-assigned IPv6 addresses for enterprise networks as well as HOMENET - See slides Fred Baker 2a) Presentation by Fred Baker on background and motivation from v6ops 2b) Working group discussion of dest/source routing for PA multi-homing Geoff Huston: Isn't this the discussion of SHIM6? Developed mechanisms to map source addresses - never deployed. Geoff Huston: A lot of ISPs do not do BCP 38 due to these problems. "Between Rock and Hard Place" - SHIM6 will not be put in all stacks. BCP 38 not universially deployed. David Lamparter: Believes BCP 38 is deployed due to personal experience. Ole Troan: Agrees that BCP 38 is deployed. Adrian Farrel: What happens when there is a failure of one ISP router? Fred: Need to use the the other ISP router. Adrian: Wouldn't it better than to push the problem back to host and solve all use cases? Could use tunnels. Fred: Too much complexity with tunnels. Peter Lothberg: Different solutions to this problem. Everything is going be mobile. Need to separate "who" from "where". David Lamparter: Making a policy decision to make PA addresses more usable. Supporting non-default destinations from ISP with PA addresses has an implication. Do we require PI for this? Eric Osborne: More general problem - different quantities of bandwidth for multi-homed enterprises. Requirements seem to loosen BCP 38 restrictions. Fred: Would need need to have cooperation with ISP. Juliusz Chroboczek: How do you get the packets? How do we choose the egress router? mTCP does probe paths. Eric Vyncke: EU Research to tell host what source to use. Jeff: Can you present this research at the next meeting? Chris: Discussion prior to next meeting could happen on the list. Fred: We should provide a solution. Chris: Agrees that we need a solution that addresses use cases. Need to separate routing from source address selection. Fred: "Happy Eyeballs" can solve source selection problem by trying them all. Fred: Will add this to use cases section in existing draft. Fred: How "Happy Eyeballs" solves the problem? Poll using all source addresses and use one that works. Chris: Use cases will dictate the solution and if we can solve 95% with a simpler solution we'd get the simpler solution first. Alvaro: Would like to see a solution that solves the whole problem of routing and source solution. Fred: Sounds like an ICMP-like problem. David: Strongly would appreciate feedback on the existing RTG WG source/dest routing draft. Geoff: Entire conversation is replay of SHIM6 WG life. What gained traction was making the hosts smarter. However, ISPs did not want hosts to get involved in routing policy. Go back and read SHIM6 conversation and understand why that failed. Jeff: Geoff can you present at the next meeting and summarize the previous discussion? Geoff: Yes Alia Atlas: We need to have this discussion before IETF 96. Need to keep the interest and energy going on the list. 3) Update on draft-ietf-rtgwg-uloop-delay - See slides. Bruno Decraene JeffT: Who has read? Bruno: Draft has been updated this week and is ready for WG last call. Took some time to complete while waiting for implementations. JeffT: Everyone should read and comment. Really great work and collaboration among vendors. 4) Update on draft-psarkar-rtgwg-multihomed-prefix-lfa - See slides. Uma Chunduri Jeff: How many have read? Room: A few JeffT: Will poll the list for document progression. 5) Initial progress report from Overlay OAM design team - See slides. Overlay OAM design team - Greg Mirsky presenting. Yuji Tochio:Which layer does the overlay OAM belong to? server, client, or both? Greg: Both Yuji: how many layers are there in the overlay layer? Greg: In-scope Overlays are BIER, NVO3, and SFC. Yuji: How many layers in OAM? Greg: IP and IP/MPLS plus overlay in scope. Scope is only 3 layers. Shahram Davari: Does each layer have its own OAM and is there communication between layers? Greg: Yes - there are alerts between layers. Shahram: Is service activation in scope? Greg: Performance measurement could trigger service activation. Eric Osborne: Would encourage terms appropriate for encapsulations. Greg: Scope is limited to 3 new encapsulations (NVO3, BIER, and SFC). Erik Nordmark: What is the concern? Erik: Terminology of SONET is feared. Adrian: Terminology for design team should include the role - "OAM for overlay Encapsulations" Adrian: Should overlay and underlay OAM be in scope? Greg: Our work is scoped to OAM Overlay. Alia: Correlation between layers should be in the scope. Thinks this is an important. Greg: Charter explains that correlation may be applicable to other networks. Alia: Think about ways to go through the layers when required and how to do that in a meanful fashion. Take to list. Shahram: Traceroute would a example. Carlos now presenting OAM Gap Analysis... See Slides Carlos Pignataro: Goals is to use existing tools. Sue Hares: Please add TRILL. Greg: TRILL is not in scope since it is connection-oriented. Sue: Need to re-look at TRILL. Will take this offline. Mach Chen is now presenting "BFD and SFC". Carlos: E2E in SFC is defined by ingress classifiers. Service functions themselves are completely out of scope. Different frames of thought? Acee: I believe you should not include service functions as you will lose commonality between encaps. David Mozes is now presenting "In-band Telemetry" - See slides Rick Taylor: Sender and receiver need to cooperate. Have you looked at scenario where the receiver is passive such as BFD loopback? Greg: Scope limited to data plane. Carlos: Seamless BFD is something you should look at. Greg is now wrapping up... - Document Needs review and comments - Ready for proceeding to protocol work. 6) draft-lapukhov-dataplane-probe-00 - See slides. Petr Lapukhov Carlos: Did you consider passive monitoring? Petr: We got active monitoring to work and stuck with it. Carlos: Traceroute? Petr: Often traceroute is broken in some implementations. Settled on using our home-grown UDP probing with telemetry. Carlos: Some risk of magic number collisions. Petr: Collisions are very rare. Carlos: Passive monitoring can solve these problems. Pat Thaler: Even if there is low probabilty, the consequence of sequence number matching customer traffic is bad. Petr: Have not seen a problem with collisions. Rick Taylor: I have security concerns? Is this a single security domain? Petr: Would be problem in cloud - not in Facebook since it is isolated. Plan to work on Security in future version of the document. Greg Mirsky: IPv6 extension header cannot be viewed as a passive method since it changes length. Carlos: Sequence number collision and lack of security makes for an interesting attack vector. Petr: Matching of UDP 5-tuple somewhat avoids this problem. Shahram: Lots of complex information collected - how is it analyzed? Petr: Can be received quite fast. Asynchronous pipelines filter and analyze the data as it is received. David Mozes: How do know the end-device will loopback the packet? Petr: There is a receiver on end-devices to handle probes. David: How would you MPLS? Petr: Use segment routing to take IP routed path. Some problems with this encap and MPLS. Carlos: TLVs are not necessarily fast with lots of probes - have you considered other approachs? David Lamparter: Disagrees that TLVs are inefficient. Petr: Silicon will support TLVs and TLVs provide more flexibilty. Carlos: Consider hybrid approach with fixed fields and TLVs for optional fields. Petr: Could do this - we can consider. Need something that works. Jeff: Draft is interesting and need to share with IETF community independent of where this work proceeds. Meeting ended. Friday, April 8, 2016 10:00-12:00 Morning session I Room Atlantico C Routing Area Working Group WG Chairs: Jeff Tantsura, Chris Bowers WG Status Web Page: http://tools.ietf.org/wg/rtgwg/ Jeff Tantsura starting the meeting. 1) 10:05-10:10 draft-ietf-rtgwg-yang-key-chain Acee Lindem 5 min Acee presenting. Jeff Haas: I haven’t seen anything in the draft to cover empty authentication. Should there be an explicit option for empty? Is that needed? Acee: I did think about that. This would be the use case of graceful move from no authentication to authentication. JeffH: The specific use case is for BFD turning authentication on. In terms of 'I support the authentication and there is nothing there at this time. Chris Hopps: Have the security folks reviewed the document for side channel aspect? Acee: Are you talking about key encryption? Chris: passing the encrypted key via side channel. Acee: It was reviewed by Brian Weiss. Chris: SSH might be an option. Acee: It is a feature to use the key encrypting key, as noone does that today. JeffT: Do you think there are any other unresolved questions? Chris Bowers: Does that create problems with later updates? Acee: It is only the operational state, should be no problems. It is similar to current key chain usability as done today. This would allow to get strings used as keychains. It is only the operational state, it is not applying to the key chain. 2) 10:10-10:20 draft-ietf-netmod-routing-cfg Acee Lindem 10 min Acee presenting. Xufeng Liu: it was mentioned that the operational state was not consistent with the current netmod structure mount option, and also not consistent with openconfig. Do you have a preference how this would look like? Acee: My preference os to have an agreement on how we are going to structure YANG models. routing state and routing config at the moment is on the top level. Xufeng: ... Acee: This will probably change. There is a protocol list, and all the protocols will be split at the top with config and state. But we need to get an agreement on that first. 3) 10:20-10:25 draft-acee-rtgwg-yang-rib-extend Acee Lindem 5 min Acee presenting. Sue Hares/Huawei: Is this independent from I2RS ephemeral? Are you progressing towards I2RS model? Acee: for the RIB there are things that never will put filter based things in. Sue: I am interested in I2RS RIB, not the filter based RIB. What do you want to do with both of them - progress both, align, anything else? Acee: I would prefer to align. Jeff Haas: I echo what Sue said. I2RS RIB has much more configuration that this. Once the ephemeral gets through netconf, this will be more useful. Also the common extensions could be looked at. There could be RIB components that are augmented by the operational state. Maybe a separate document describing common overlapping protocols and their interaction would be good to have. Acee: We have thought about that. I would prefer thos document to go into IETF routing base. Me and Lada we need to agree on this for now. From the I2RS perspective .... We do not agree with the tunnel configuration. Labels are not a part of a base RIB. JeffH: Augmentations are an option to go here. There are overlaps in multiple places, example of metrics for ISIS and OSPF. Acee: for the local RIB, this is only an operational state, and there is no direct intersect with the protocol model. Chris Bowers: cutting the lines. Lou Berger: Picking on the comment that you do not agree on something - you are talking about a WG document. If the authors disagree it is not for the authrs to decide, it is for the WG to do so. Acee: I got that from JeffH too, those things are simple and should go into the base routing model. JeffT: Please could authors work with the I2RS too. Acee: It does not cover all what could be in the carrier class router. 4) 10:25-10:35 draft-hares-rtgwg-fb-rib Sue Hares 10 min Sue presenting. Acee Lindem/Cisco: This is interesting. We have multiple ways of doing things. How does this relate to ACL model in netmod that is going to completion? Sue: It is not to be used for packet filters. You cannot make ACLs into this model as there is extra stuff there. Tom Herbert/Facebook: You might be interested in some work that we are pursuing, IPPM filters and their match actions. Also P4 and other approaches could fit here. Sue: Yes, that is a possibility. Acee Lindem: A good way to position for this to include classification pus action plus some debugging stuff. The ACL are just a classification. Sue: Yes, you can use ACL for the classification match. JeffT: What about operational state? Sue: We will add operational state later. Chris Hopps via meetecho: What will come up first - protocols or filtering? Sue: Both. Flowspec will be first, and then the routing will continue. Chris Hopps: this is a very specific use. Are there any other uses for it? Sue: If your question whether there could be more filters to be added then I do not know. We designed I2RS to be able to add ephemeral at any point that you want. 5) 10:35-11:20 - Routing Area YANG Architecture design team and draft-rtgyangdt-rtgwg-device-model Routing Area YANG Architecture design team 45 min Lou Berger presenting. Michael Abrahamsson: Would like this experiment to stop. Chris Bowers: I would like to continue. Alia Atlas: This is a good experiment and not a joke. Lou Berger: My point is about repeating the company names. Juliusz Chroboczek: in this jabber session we have a good scribe who spells the names. Lou presented a set of recommendations. Lou: Did I present this clearly? Chris Bowers: seems so. Acee Lindem: We are trying to work on this, not just between the IETFs. The DT meets every two weeks. Lou: Solutions authors are also regularly meeting. Sue Hares: We have separate models in I2RS that are waiting on operational. How should we progress. Lou: By Berlin there will be a netmod wg document that describes the solution. That is the target. If that does not happen we will see what to say there. In netmod AD spoke on how schema mount and opstate are two issues that are blocking many works. Xufeng Liu: For derived state we have sevral options. There is openconfig that is very different from current approach. Lou: This falls into what I have mentioned earlier. Netmod needs to come with a recommendation. Another option for those actively working on this is to describe the problem in detail in netmod wg. Specifically what issues that they would have with one or another approach. Would suggest you to take this to nedmod saying that I have these models, and there will be those consequences. Jeff Tantsura: .... Lou: We do not have an agreement in DT on a derived state. DT has been focusing on the first two problems. JeffT: Should we wait for Berlin? Lou: we need to aggressively discuss this on the list even today. Help the DT and the WG to identify the areas that are important. Based on the DT work the netmod has agreed to take on more work. Acee: that is 6807bis document. Lou: It may be a possibility of a separate document if the list gets too long. Chris Hopps via meetecho: I think the derived state is the last remaining obstacle for the opstate. We hope to have an answer by Berlin. Alia Atlas: The ones that are writing the models should not think that we are blocking them. It is about the overall model system. Jeff Haas: It seems that you are trying to associate the models here. We have YANG catalog that might make some sense here. Lou: This is what I meant with a metadata solution. The reason why it is important to make these groupings is to identify the class of functions that apply to specific model, especially if a new one shows up later, whereas otherwise you would have that mapping hardcoded. I personally do not have a strong opinion. The DT still does not have a solution. JeffH: it is possible to create an XPath that says give me a list of all those models. Lou: Yes, that could be possible. Whether metadata based approach gives something equivalent we still do not know. This is a logical structure. We are working with netmod to see what is the right solution. Chris Hopps via meetecho: I see this as a feature to be able to do a wildcards. That could pull all the protocols (routing-*-name) that you even did not know they existed. Lou: the metadata was covered in netmod session earlier. Chris Hopps: there are strong opinions outside of routing area that do not like this approach. They would like to see all the models adding at the common root. Acee Lindem: the challenge of the DT seems to have a normative .... and all the models augmenting all those categories. Having all of it independent has a lot of advantages. Sue: I2RS policy RIB - where does it fit? Lou: this highlights the issue with the models like this. The metadata solution could be an option, and DT may come to a ddiferent solution than the netmod group. Dhanendra Jain/Cisco: Routing model may have elements associated with the element si n the context of VRF. Keeping routing separate from routing instance gives a way to associate such elements. Lou: yes there are cases where you need to associate parent to clilfd nodes. Logical network element is fully recursive. Lou: the model is complex, and for someone who is not involved with it all the time might be not so clear. Chris Bowers: please make a decision whether describing the whole model or split it and then describe parts - up to you. 6) 11:20-11:50 – Identifier Locator Addressing Tom Herbert draft-herbert-nvo3-ila draft-herbert-ila-messages draft-lapukhov-ila-deployment draft-lapukhov-bgp-ila-afi 30 min Tom Herbert presenting. Chris Bowers: why the IDs are not predictable? I the DC environment it is typically organized. Tom: This is related to MAC address predictability. Also the internet does not know the identifier part in the ILA. This is a rather conservative approach. Michael Abrahamsson: When you say that it is integrated in linux 4.1 - is that in the mainline kernel? Tom: yes. Linda Dunbar/Huawei: there is some relevant work being done in ?armd? The result is rfc 7506? that defines an experimental mechanism on address resolution. Tom: ILNP is 2012. Linda: This is 2013. Also TRILL has a control plane and a smart end not that has a similar solution. Tom: TRILL has a similar problem - identifiers are not hierarchical. That results in host routes. Dino Farinacci: You do not translate source addresses in the packet? Tom: Yes. Dino: then the traceroiute will be returned to the original source and not the translated one? Tom: That is a good question for ICMP. ICMP message will be generated on the addresses as they are. Some node in the middle of the network will have to flip the address back to the source. When the packet reaches back to the source it will need ot be translated. If we need ICMO error for connection handling, then it will need to be translated. ICMO is a pain. Dino: If ICMP sender could translate, it would be able to originate the correct source then. Tom: We are sending through the network that does not understand ILA. ILNP likely would have that same problem. Michael Abrahamsson: BCP38 defines anti-spoofing. The first node keeps the source address that was someones else. Tom: One issue with ILNP is address moves. Michael: This needs to be brought up somewhere. Tom: In the DC context this is not relevant, in other use cases this may be relevant. Dino: If you need a control plane - use what LISP did. JeffT we welcome discussion in the group on all of this. 5) 11:50-12:00 – Currently unallocated Meeting ended.