Routing Area WG Minutes (First Session) TUESDAY, March 24, 2015 - 17:30 - 18:30 Afternoon Session III Chairs: Jeff Tantsura, Chris Bowers Scribe: Acee Lindem - acee@cisco.com 1) 17:30-17:40 - WG Status Update - Jeff Tantsura, Chris Bowers Jeff: Welcome Chris Bowers as Co-chair and congrats to Alvaro as the new Routing AD See slides. Stewart Bryant: Remote LFA is now in AUTH48 edit state. 2) 17:40-17:50 - Maximumly Redundant Tree Update - Chris Bowers draft-bowers-rtgwg-mrt-applicability-to-8021qca draft-ietf-rtgwg-mrt-frr-algorithm status of the 3 non-RTGWG MRT-related drafts See slides. Stewart Bryant: In bridge environment, how do you do loop-free recovery after failure. Chris: Loop-free recovery mechanism is describe in 802.1qca. Janos Frakas: The loop-prevention mechanism is RPF checking in 802.1qca. Stewart: Process has to be normal, failure, MRT recovery, and recoverge such that there are no loops. What is policy to prevent loops? Chris: There is a mechanism in 802.1qca involving hashing topologies updates and delaying path change until they are sync'ed. Janos: You can choose digest solution or waiting long enough before moving back to converged path. Chris: Solution is optional, once you get new PDUs, advertise a digest value. Only reconverge when everyone has the same digest values. Stewart: Some traffic in base topology and other traffic in red or blue topology? Janos: Failure-unaffected traffic goes on shortest path. 3) 17:50-18:30 - Encap Considerations Design Team - Erik Nordmark draft-rtg-dt-encap See slides. David Black: End-point traffic can attack the underlay. Erik: Absolutely - question is how to handle this is a challenge? Fred Templin: Does entropy work with UDP through NATs. Erik: Not part of the focus for the ENCAP use cases considered. David Black: Useful text in existing drafts on NATs and punching uni-directional pinholes through NATs. Stewart Bryant: What you really need is an instruction field rather than a next protocol field for new ENCAPs. We don't want to miss this opportunity. Erik: Not clear. David Black: Lots of considerations with encaps make this generality dangerous. Erik: Must consider middleboxes. Stewart: Encap actions could be cast in stone for all new encaps. David: We're not going to agree here. Fred Templin: May want to look at Areo draft for how fragmentation could be handled. David Black: For OAM, transport folks could use something to check the amount of traffic ingressing and egressing the tunnel to detect problems. Stewart: Layering of MTU can't be 2 levels below Encap layer. OAM needs to be confined to encap level - No layer leakage. Erik: Nothing in the document indicates leakage. David: May want OAM service on encap to see if ingress traffic and egress traffic are consistent. Stewart: OAM is scoped only to a single layer. Erik: Slide is asking if there should be a common OAM. George Swallow: ITU has concept of pushing notifications to the layer above. David: Recommends emphatically that RFC 6936 be applied. Erik: Very few strong recommendation - references to other traffic. Stewart: Majority of traffic is not protected by checksum through most of its life. This should be optional. David Black: MPLS has characteristics of underlay. Overlay protocols run over much less reliable and well managed underlays as well. Stewart: Don't design for worse case for encaps used in environments where they are not needed. Tom Herbert: Data centers are not always well provisioned and managed. We cannot leave the cases where they are not out of the design. Erik: Mechanisms must be available to solve these problems even if they are optional. Rudiger Volk: May get by without checksum but we should not assume that there are no errors. Tom Herbert: Incidence of checksum error in the well-provisioned and managed Google network is non-zero. Need the checksum mechanisms to be available. Jeff Tantsura: Present to every WG impacted (NVO3, BIER, SFC). Draft will be hosted in RTG WG. Acee Lindem: Although I have only scanned, I believe the presentation and work are excellent. It took me through years of network debugging. The work should be accepted and proceed. Tony Prygienda: Agrees it is excellent work and should be presented BIER. Loa Andersson: What mailing list for discussion? Jeff: Should have separate mailing list like YANG? Alia Atlas: Assume the discussion would happen here rather than a new list. Could be some cross posting if necessary. Routing Area WG Minutes (Second Session) THURSDAY, March 26, 2015 13:00 - 15:00 Afternoon Session I Venetian RTG rtgwg Routing Area Working Group WG Chairs: Jeff Tantsura, Chris Bowers Scribe: - Ignas Bagdonas - ibagdona@gmail.com WG Status Web Page: http://tools.ietf.org/wg/rtgwg/ Jeff Tantsura: We are starting the meeting. 1) 13:00-13:10 - SPF delay algorithm - Problem statement: draft-litkowski-rtgwg-spf-uloop-pb-statement - Spec: draft-decraene-rtgwg-backoff-algo Bruno Decraene 10 minutes Bruno: [presentation] http://www.ietf.org/proceedings/92/slides/slides-92-rtgwg-2.pdf This was discussed previously, good feedback, would like to ask for adoption as a WG item. [discussion] Eric Osborne/Level3: this algorithm is similar to what exists today and has the same problem as existing ones - it does not differentiate between different failures. Because you have so much events and activities happening at the same time in different places, would be good to have some mechanism to differentiate. Bruno: Yes. Bruno: What matters is the FIB update speed. Stefano Previdi/Cisco: would be good to distinguish different events that affect the whole network coming from everywhere and events that come from a single node. Bruno: yes. Acee Lindem/Cisco: that is the reason why would you have those timers configurable. The consequence of optimality is that you have to configure it manually. Bruno: True. We need to have different values in the document. That will depend on the conditions and how it changes. Jeff: who has read the draft? [how many hands?] Jeff: who thinks it would be a good idea to proceed with the adoption? [how many hands?] 2) 13:10-13:20 - draft-psarkar-rtgwg-multihomed-prefix-lfa Pushpasis Sarkar 10 minutes Pushpasis: [presentation] http://www.ietf.org/proceedings/92/slides/slides-92-rtgwg-7.pptx [discussion] Jeff Tantsura: we are discussing how this is going to update RFC5286 Will discuss on the mailing list. 3) 13:20-13:30 - draft-spallagatti-rtgwg-bandwidth-based-metric Santosh P K 10 minutes Santosh: [presentation] http://www.ietf.org/proceedings/92/slides/slides-92-rtgwg-5.pptx Only the problem statement is discussed due to lack of time. The other part in the draft talks about FRR. [discussion] Ahmed Bashandy/Cisco: this seems to me as an internal operation of the router. Drafts is positioned as standard, maybe it should be informational instead? Santosh: ok. Robin Li/Huawei: why not use traffic engineering here? This design seems too fragile and algorithm specific? Santosh: we are doing it without MPLS here. Hannes Gredler/Juniper: the customer that is requesting this gets an alergic reaction when it sees MPLS related TLVs. Robin: metric can be specified by the user and not automatically derived. Sequencing? [???] Jeff Tantsura: please take to the list. Eric Osborne: you may want to look at the IGP variance. I cannot predict what the metrics will be ahead of time. RŸdiger Volk: sometimes alergy prevents bad health happening. I am not as radical as some people up north. The idea that metrics are hand configured does not always work in large networks. Simulations could be used to fitting expected load and variations taken into account. Sriganesh Kini/Ericsson: there are many studies on what problems could be caused by changing bandwidth. Santosh: we are changing metric and not bandwidth. If the link if flapping frequently, it can be instable. Santosh: this is similar to what happens in bundles - if link is flapping, you will be facing the similar issues. Sriganesh: you should recommend the values and timers to avoid instability? Sriganesh: is this when a link goes down only, or when the link is too much loaded? Santosh: link down and degrade, not due to dynamic bandwidth changes. Santosh: link degrade as in optical domain. Pushpasis Sarkar/Juniper: we derive metric from bandwidth, flood a new metric, and hope that other nodes will pick it in time and not cause the loop. Jeff Tantsura: please take the discussion to the list. I would like to see comments from the operators. 4) 13:30-13:40 - draft-shaikh-rtgwg-policy-model Rob Shakir 10 minutes Rob: [presentation] http://www.ietf.org/proceedings/92/slides/slides-92-rtgwg-9.pdf Presenting on behalf of Openconfig group. [discussion] Sriganesh Kini/Ericsson: this draft states that it is based on best practices. What is that precisely? Rob: I do not know whether there are any plans to write a draft that covers best policies of policy. Anees Shaikh/Google: I have added that text. That is based on what is currently used and maintainable from the operators perspective. Rob: maybe we should tweak the wording to a little less loaded terms. Jeff: we are still discussing on who is doing what. In this particular case you see abstracted BGP policy that is done in IDR. Rob: the policy actions in the BGP model are not really adding anything, not certain whether IDR would have to comment much on that. The approach taken is to use a component and not standardize the actual policy component structures. Alia Atlas: I talked to WG chairs on how to handle the interaction between the models. That is not going to scale. There are two concerns: some models are coming from Openconfig and that does not fit in IETF structure. And that is fine. We will say that this is the primary working group and we will review it, and if fits operational architecture - you get it. Alia: Second part - common subgrouping will likely make as a second draft, and have a separate use case for that. WG chairs can negotiate and discuss which WG is the primary group and go for it. For BGP model, there are a lot of uses and that is the primary group is IDR. Rob: to clarify - on the left side is the model, on the right side is the policy model. The important part is the reusable components here. It is not clear to me whether if it says BGP policy, it should go to IDR group. Stephane Litkowski/Orange: I completely agree. We need cross policy framework. BGP is the major protocol but that is not all. We need a consistent framework Alia: to get the consistency of the model it helps to have the whole model in the working group. But if we pull everything into RTGWG it will explode, and only people interested in YANG will show up. We are trying to find a way of how to manage. Options - try to split the load and find a primary WG. I do not want to put it into something that will fail. Sue Hares: I like the architecture that you have. Chair hat off - it makes sense to have the generic policy with BGP specific policy. With chair hat on - we are working on it. Rob: I am not saying that it must share with IDR. Acee: speaking as a reviewer - it would be good to split pieces and not keep into single one, especially vendor specific. 5) 13:40-13:50 - draft-acee-rtg-yang-key-chain Acee Lindem 10 minutes Acee: [presentation] http://www.ietf.org/proceedings/92/slides/slides-92-rtgwg-10.ppt [discussion] Erik Nordmark/Arista: things are asynchronous. Do you want to have a status of key rollover? To verify that both devices have received the set of new keys before we move to using them. Acee: that is a good idea. Joel Halpern/Ericsson: there is an agreed informational model that has been reviewed by the security groups. If you are going to throw it out you need to acknowledge that and list the differences. That model is key tables. Acee: we are not going to throw anything out. Joel: you need to revisit the security. Acee: who has a keytable implementation? Please raise your hands? (one?) I find that hard to believe. Acee: this is the immediate solution. There may be a solution in a distant future where keytables are uses. This can be used today. Acee: I do not believe anyone wants to manage the network that way. David Lamparter: [missed]. Uma Chunduri/Ericsson: I was at the keytable discussions at the time of it becoming the RFC. Is it more practical? Even without security concerns? Acee: why don't you send to the list of what you can do with keytables what you cannot do here? Acee: 20 years of deployment experience is how it is used here. [?]/ALU: Does the module define only a groping, and not actual key chains? Acee: we do, yes. [?]/ALU: when you use leafref in the grouping, it will work, but not outside. You need to be careful where you define it. Acee: we have a global list of chains, and reference it in OSPF and ISIS lists. Jeff Haas/Juniper: are you aware of any implementations that can use only a subset of components defined in your model? You may need more flexibility than you have currently. Acee: all the people that contributed do not support all the algorithms in all the platforms. That is a hard problem. You are defining a policy that cannot be reused in all the places. But that is not stopping people from using it today. Jeff: please continue the discussion on the list. 6) 13:50-14:00 - draft-yan-rtgwg-routing-policy-yang Gang Yan 10 minutes Gang: [presentation] http://www.ietf.org/proceedings/92/slides/slides-92-rtgwg-12.pptx [discussion] Acee Lindem/Cisco: This is a good reflection of existing policy model that a lot of vendors use. It would work from that standpoint. But based on the Rob's presentation there is going to be another model that is not going to be exactly the same. Where do you see it fit this legacy model fit? Gang: we are comparing those models. There also needs to be some implementations to compare them. Gang: Also NETCONF is a bit difficult for operators. NETCONF is object oriented, third party NMS have difficulties understanding this process. We need to discuss this in the design team and find a way how to integrate with the NMS. Acee: I think yours is much easier to implement. But I do not think that it is the final that we will end up with. Jeff: please discuss on the list. Sue Hares: we really need the tunnel policy. As well as in IDR and I2RS. Jeff: this should be reviewed in both groups. Sue: we need the YANG design team that works for both. We need for BGP, for I2RS filters, and other components too. Gang: please review our draft. Right now too many discussions about the architecture but it is also important to see on what is implementable and how it is implemented. Jeff: that is why it is important to discuss not only here but broader. Rob Shakir: that is exactly what the group is dong - we are looking at the existing configs and taking things from there. 7) 14:00-14:10 - draft-li-rtgwg-tunnel-policy-yang Shunwan Zhuang 10 minutes Robin Li: [presentation] http://www.ietf.org/proceedings/92/slides/slides-92-rtgwg-0.pptx [discussion] Jeff Tantsura: thank you. 8) 14:10-14:20 - draft-wu-rtgwg-flowspec-cfg Eric Wu 10 minutes Eric Wu: [presentation] http://www.ietf.org/proceedings/92/slides/slides-92-rtgwg-1.pdf [discussion] Acee Lindem/Cisco: I was involved in the discussion on the list and we did not come to the conclusion to use float32 as a base type in YANG, even in 1.1. Acee: I think it was not a good idea to use floating point in RSVP, but that is water under the bridge. We will have to find a way to use that in YANG. Jeff Haas/Juniper: BGP flowspec rule ordering is important. In your model it does not seem related to that, it is just a list order. Eric: Flowspec is not message encoding, and the order follower here is the 12 types based on the specification. Jeff Haas: if you are trying to impose firewall rule ordering in your model you may not be able to encode it on the wire. Eric: will respond on the list. Robert Raszuk. RFC5575 uses automatic validation. If you detach Flowspec from generic BGP, how will you do validation? Eric: did not think of it yet. Will discuss on the list. Stephane Litkowski/Orange: is it only for creating static routes, for injecting into the network? If you are trying to build a model for something like PBR, then it is not Flowspec. Stephane: Another point - you are redefining filters and actions - thos should be reused in a more generic way. Sue Hares: we need filter based policy in the new filter based ribs for I2RS. I would encourage if it is the filter based approach please continue. If it is Flowspec, we will likely have at some place that a generic Flowspec model will be defined at some point in time. Jeff: please initiate the discussion on the list. 9) 14:20-14:30 - draft-liu-rtgwg-yang-vrrp Xufeng Liu 10 minutes Xufeng: [presentation] http://www.ietf.org/proceedings/92/slides/slides-92-rtgwg-4.pptx [discussion] Jeff: how many people have read the document? [number of hands?] Anees Shaikh/Google: the IPv6 VVRP configuration you also need link local address specified. Have I missed it? Xufeng: we have that. Anees: I did not see interface tracking? Is that not in scope for this model? Xufeng: we tried to cover standard features. That can be included via augmentation. Aness: this is a common feature used in operations. Reshad Rahman/Cisco: if you are clearing the stats and another entity is polling at the same time, what could happen? That was brought to the list previously. Xufeng: please bring to the list again. 10) 14:30-14:45 - draft-ietf-netmod-routing-cfg Acee, Lada 15 minutes Lada: [presentation] http://www.ietf.org/proceedings/92/slides/slides-92-rtgwg-11.pdf [discussion] Acee Lindem/Cisco: I think we really resolved all issues and I started the thread on the routing design team list. I hope we can get recommendations from that list. Also ask Openconfig and vendors. Lada: this document is really very late and we would like to finish it as soon as possible. Benoit recommended to really take a close look and iron out the problems before rushing. Benoit Claise: this is a fundamental YANG model and there are many consumers. It will stay in some state, likely ad review, for a long time. It would be a mistake to just rush an RFC here. Acee: we would have to add the complex nexthops and other parts that were removed from here. We may even augment it with another draft. Lada: we tried to make sure that these augments are possible. Jeff: it is also good that Netmod WG reached the agreement and we can continue forward. 11) 14:45-15:00 - draft-openconfig-mpls-consolidated-model Eric, Josh 15 minutes Ina Minei presenting: [presentation] http://www.ietf.org/proceedings/92/slides/slides-92-rtgwg-3.pdf Robin Li: a comment - there may be state that does not belong to TE and non-TE part? What is static? Ina: Static here means that you are defining at each hop what is the label action. [discussion] Hannes Gredler/Juniper: what is the reason that the BGP-LU was not on the list? Ina: it will be in the later version. Robin Li: what about MPLS-TP? Ina: MPLS-TP is not currently covered in the document. We are trying to cover the use cases that we have, and TP was not one of them. Eric Osborne: we worked in parallel and [..missed..] Sriganesh Kini/Ericsson: a point on terminology: TE vs static. Maybe you could say explicitly routed LSP? Ina: Will consider. Wrap Up: Jeff, Chris Jeff Tantsura: thank you. See you all in Prague.