Minutes IETF98: idr
minutes-98-idr-02
The information below is for an old version of the document.
| Meeting Minutes | Inter-Domain Routing (idr) WG Snapshot | |
|---|---|---|
| Date and time | 2017-03-31 14:00 | |
| Title | Minutes IETF98: idr | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2017-04-19 |
minutes-98-idr-02
IDR meeting at IETF 98 Chairs: Susan Hares, John Scudder Notes: Ignas Bagdonas (additional notes John Scudder) Jabber: Wes George ----------------------------------------------------------------------------- Agenda 9:00-11:30am 3/31/2017 Room: Zurich G (9:00) Chair's administrivia [9:00-9:05] 0) Agenda bashing and Chair's slides [5 minutes] Updates on Preventing Attribute Squatting [9:05-9:15] Drafts related to the discussion: 1) Additional Reviewers for BGP Registries [Sue Hares] https://datatracker.ietf.org/doc/draft-hares-idr-bgp-registries/ 2) Should we deprecate Atomic Aggregate -is it worth it? [Sue Hares] https://datatracker.ietf.org/doc/draft-hares-deprecate-atomic-aggregate/ Updates on existing drafts [9:15-10:15 am] 1) Making Route Servers Aware of Data Link Failures at IXPs [Randy Bush/Jeff Haas] (10) https://datatracker.ietf.org/doc/draft-ietf-idr-rs-bfd/ 2) Route Leak Prevention using Roles in Update and Open messages [Alexander Azimov/Randy Bush] (10) https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/ 3) Route Leak Detection and Mitigation [Sriram] (10) https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-06 4) Signaling Maximum SID Depth using BGP-LS [Jeff Tantsura] (5) https://datatracker.ietf.org/doc/draft-tantsura-idr-bgp-ls-segment-routing-msd/ 5) BGP Next-Hop Dependent Capabilities [Bruno Decraene] (10) https://tools.ietf.org/html/draft-decraene-idr-next-hop-capability-03 6) BGP Route Refresh Options [Tony Przygienda] (5) https://tools.ietf.org/html/draft-idr-bgp-route-refresh-options-02 7) BGP SR Updates [Acee Lindom] (7) https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-11 https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-04 https://tools.ietf.org/html/draft-previdi-idr-segment-routing-te-policy-05 [3 minute for switching] New Work [10:15-11:30] 1) New definition of ISP Internal EBGP Border using BGP Roles [Alexander Azimov/Randy Bush] (10) https://datatracker.ietf.org/doc/draft-ymbk-idr-isp-border/ 2) BGP Logical Link Discovery Protocol (LLDP) Peer discovery [Acee Lindem] (10) https://datatracker.ietf.org/doc/draft-acee-idr-lldp-peer-discovery/ 3) BGP Signaling of IPv6-Segment-Routing-Based VPN Networks [Gaurav Dawra] (12) https://datatracker.ietf.org/doc/draft-dawra-idr-srv6-vpn/ 4) Compressed BGP Update Message [Tony Przygienda] (10) https://datatracker.ietf.org/doc/draft-przygienda-idr-compressed-updates/ 5) Populate to FIB Action for FlowSpec [Zhengiang Li] (10) https://datatracker.ietf.org/doc/draft-li-idr-flowspec-populate-to-fib/ 6) BGP Neighbor Autodiscovery [Xiaohu Xu] (10) https://tools.ietf.org/html/draft-xu-idr-neighbor-autodiscovery-01 7) Persistent Route Oscillation in BGP Constrained Route Distribution [Jakob Heitz] (10) https://tools.ietf.org/html/draft-idr-bgp-rt-oscillation-01 [3 minutes for switching] 11:30 am ----------------------------------------------------------------------------- Minutes Times given in parentheses are approximate wall-clock times, for reference. 9:00-11:30am 3/31/2017 Room: Zurich G Sue: Meeting starting. Note well applies. John: You have seen the note well many times but this is a reminder on the contribution definition in the IETF. All things you say and present here are covered. It is a boring but important stuff. Chair's administrivia [9:00-9:05] 0) Agenda bashing and Chair's slides [5 minutes] JGS: Agenda review. (9:03) Sue: Extended messages. Randy: As an interested party - I really don't give a damn. John Scudder/wg member: We can do any of them. My own preference is option 3. It is 64K for all messages but do not try too hard for OPEN. At this point we should say perfect is the enemy of good enough. Randy: I have strong opinion on OPEN. If you try to open and you cannot negotiate what options you have to use failing is operationally is not the way to do. Updates on Preventing Attribute Squatting [9:05-9:15] Drafts related to the discussion: 1) Additional Reviewers for BGP Registries [Sue Hares] https://datatracker.ietf.org/doc/draft-hares-idr-bgp-registries/ Sue presenting. (9:08) Acee: It seems that the current allocation policy usually works, there are some cases where it was not used then people ended up with coding attribute code points that were not allocated. (9:08) 2) Should we deprecate Atomic Aggregate -is it worth it? [Sue Hares] https://datatracker.ietf.org/doc/draft-hares-deprecate-atomic-aggregate/ Sue presenting. Sue/wg member: it seems that we need to dig deeper into this problem space. CAIDA may help with the analysis of BGP data with their tooling. Updates on existing drafts [9:15-10:15 am] 1) Making Route Servers Aware of Data Link Failures at IXPs [Randy Bush/Jeff Haas] (10) https://datatracker.ietf.org/doc/draft-ietf-idr-rs-bfd/ (9:12) Jeff Haas presenting. (9:18) Tony Przygienda: Who is dealing with BGP here - is it a client or a server? JH: This is in the IXP (exchange point) environment. Enke Chen: Naive question. Can this be done without changes to route server and changes to BGP spec? The client receives the updates from Rs and can see whether they are reachable. JH: You can learn your next hops from the peers but the other side needs to know that too. It may be asymmetric. Point two - BFD sessions would need to be pre-provisioned, and hysteresis if what you have learnt is better when RS helps you. When something becomes unreachable there may be a backup path and BFD is needed for that path too. Enke: If you have routes from the other client and if you do not advertise that you have no next hop. Job Snijders: If this mechanism would depend on add-path then the RS would not need to know the reachability of the next hops. JH: We have discussed that. We think that route asymmetry case is a problem here. With a RS supporting add-path is not enough - many edge nodes do not support that. You also need to have a consistency of add-paths between a set of RSes. Job: By the time this has running code it may be add-path will be supported too, it is a question which gets deployed first. JH: BFD is used no matter what and we need to know next hops anyway. There seem to be benefits of using this mechanism. Job: Agree. 2) Route Leak Prevention using Roles in Update and Open messages [Alexander Azimov/Randy Bush] (10) https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/ (9:23) Alexander presenting. Randy Bush: I would like to speak against the complex role. The complex role is not common. For years I've argued against Gao-Rexford, Recently Philip ___ did a study showing it only holds for 60%ish of ASes. This doesn't mean complex is common, it means there are some who don't up-pref customers. People doing complex rule are supposed to be smart but they of course are not. Complicating protocols for 1% use cases - I don't know about that. Doug Montgomery: Do I understand your proposal that you have multiple sessions just to find out the role? Alex: Yes. Randy: It is fairly common in cases when people give you global peering and transit. We do two sessions for that. Job: We do that sometimes too. Jakob: What about IPv4 and IPv6 sessions? AL/Qrator:... John S: How many people have read the draft? A few. Sue: Introducing Jie Dong. He is a secretary for IDR. Thank you, Jie. 3) Route Leak Detection and Mitigation [Sriram] (10) https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-06 (9:31) Sriram presenting, Sriram asking the community: is it easy to change to community based? Job: Community would be my preferred choice as that does not depend on software being available. Randy points out we would rely on people typing properly. We've seen that implementors can treat communities as they do attributes, though. Ruediger Volk: In my setup throwing in another community works more smoothly. But, I think that many parties do not have configuration systems that will be easily extended for doing this and rely on manual policy configuration and then a separate attribute comes as a more secure and less easily messed up with. For the benefit of such parties the attribute is a better way to deal with it. Randy: Job, I am a little confused. You are worried abut the attribute that required the deployment of code. But you want a vendor to enforce the use of community value? Doesn't that require new code? Job: They are not mutually exclusive and they move at different timelines. Randy: The goal was for the router to enforce the peer flag. For a router to enforce it will take code change regardless the way it is done. Sriram: it the intra-as... Randy. Not talking about that. Job, do we need to talk offline? Job: Sure. Jakob Heitz: To enforce communities does not require changing route code, could be done in the policy. 4) Signaling Maximum SID Depth using BGP-LS [Jeff Tantsura] (5) https://datatracker.ietf.org/doc/draft-tantsura-idr-bgp-ls-segment-routing-msd/ (9:43) Jeff Tantsura presenting. Jeff: We request IDR Adoption of this draft. JohnS: We will take the adoption request to the list. 6) BGP Route Refresh Options [Tony Przygienda] (5) https://tools.ietf.org/html/draft-idr-bgp-route-refresh-options-02 (Note, out of sequence w.r.t. agenda) (9:47) TonyP presenting, (9:48) Enke: This looks really cute but why do we need to use that many bits? (With respect to wraparound handling.) TonyP: future proofing. Enke: Can you use 4 bytes? (And not handle wraparound.) TonyP: We have been there before. We can agree on 4 bytes and then someone starts generating many refreshes, that may wrap in a couple of years. That said, there's an example and rules in the draft to show it's fixed. 5) BGP Next-Hop Dependent Capabilities [Bruno Decraene] (10) https://tools.ietf.org/html/draft-decraene-idr-next-hop-capability-03 (Note, out of sequence w.r.t. agenda) (9:51) Bruno presenting. Adoption of Draft requested. JohnS: Curious how many people have read the draft? Good. (quite a few hands). 7) BGP SR Updates [Acee Lindem] (7) https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-11 https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-04 https://tools.ietf.org/html/draft-previdi-idr-segment-routing-te-policy-05 (9:57) Acee presenting. Sue: We will keep the WGLC open until we see the last document. Acee: And you may need to extend it to resolve the comments. Sue: On the draft sr-epe, have you completed all of your updates? Acee: Probably yes. I do not know whether Stefano has responded to all the comments. Sue: I would like to close that one. Acee: It would be good to get the tunnel attribute draft being progressed. JohnS: If you know of the implementation that would help. I would like to progress it. Sue: If you have any implementations of that it would be good to update. JohnS: Any questions? Note: adoption request for: draft-previdi-idr-segment-routing-te-policy. New Work [10:15-11:30] 1) New definition of ISP Internal EBGP Border using BGP Roles [Alexander Azimov/Randy Bush] (10) https://datatracker.ietf.org/doc/draft-ymbk-idr-isp-border/ (10:05) Alexander presenting, John Scudder (wg participant): I haven't yet read the draft. You mentioned partial deployment. How can this be deployed partially between two border ASes? Alexander: Both parties need to switch to internal role in the beginning. Change of configuration is needed only on the two edge systems. John Scudder: Imagine I have 10 different places where the ASes touch. How would that work? Do I have to do that everywhere at the same time? Alexander: The traffic will go only via those peering links that already support this extension. John Scudder: I intend to go home and read it, it is an interesting idea. Sue: Please read it and look at the routing leak stuff too. If someone has research time please look at CAIDA data and tools. 2) BGP Logical Link Discovery Protocol (LLDP) Peer discovery [Acee Lindem] (10) https://datatracker.ietf.org/doc/draft-acee-idr-lldp-peer-discovery/ (10:11) Acee presenting. "Currently gauging interest". The question for the WG - is the complexity of this mechanism acceptable? (10:19) TonyP: A couple of points. Generally this is cool. It can have a wider application. The interaction between LLDP and BGP configuration is shaky, needs more thinking through. The information will expire - do you need to tear the session then? It needs to be thought deeper. Do we do away with keepalive? What's the interaction with the FSM? What I see this as being capable of over time to do more sophisticated thing. It could describe whether OPEN message is the old size or new size, it can be a BGP transport description mechanism. It can be applied not only in the DC, it can be used in many more use cases but that requires very careful thinking as it will have a very long life. JeffH: The neighbor discovery hack is likely not a good idea. These things are being done but it causes race conditions. I do like LLDP, and I like the OSPF mechanism. Whether it is LLDP or OSPF, it is not possible to tell "should I even peer with this thing?" Security associations or tags or communities that tell what is the role of the device would be needed. The type of node - whether it is a reflector, or some other function can be described in the capabilities. What to do with the incoming sessions, what to accept? It can be done via BGP wildcarding, but there are security aspects. Acee: autoconfig vs security - I am aware of this problem. JH: You can use roles to validate the .. (10:24) Nikos Triantafillis: My personal dislike - I can have cases where LLDP is not running and I would need to configure LLDP first. I would like to see a Hello mechanism in BGP rather than relying on LLDP. I don't want two mechanisms to do the same thing. For automation this is something that I would not be able to use. Acee: It is someones else's responsibility to provide this presentation. Nikos: Peering relationship provisioning - this can be a useful tool for that. Acee: You would do either hellos or LLDP. (10:25) Robert Raszuk: The host is connected to the switch, and therefore I have no LLDP session and therefore I cannot use it for discovery of BGP sessions for the reflector to host session. Acee: Correct. You have to be on the same L2 network. Enke: I also prefer a BGP based solution for hellos. If we model after LDP, it has UDP discovery followed by TCP session. It seems to be more generic. We could use UDP port 179. Second comment - BGP is very rich in policies, to achieve minimum or zero config policies that are needed would be not possible to achieve. What is the goal - is it for the minimum configuration, or just the neighbor discovery? Do we want to achieve zero configuration? The policy can get very large. Acee: Rather than the volume of the configuration - you still will need configuration for policy anyway - but it allows for a less of difference between full and discovered configuration. You can eliminate a lot of configuration, it's not true ZERO configuration. Enke: This will work well in a homogeneous environment. (10:29) JeffT: LLDP requires that all TLVs need to be in the same 802 frame. Might be good to reach to IEEE for an extension. Acee: If we decide that this is the right thing to do we would rather extend the BGP hello mechanism. JT: You are limited to the size of 802 frame. (10:30) Sue: Please be careful with adding in something to the BGP state machine. In the past things like this were used in the different manner, I would be glad to help you on this. Acee: I think it should be advisory and not modify the FSM -- that would be a layering violation. (10:31) Nikos: If you can abstract that with scripts it is already there. (10:32) Wes: comment in jabber: "Keyur: Ideally if LLDP packets are lost you have a much bigger problem with response to discovery. Having said that we could augment the text to make it a bit more robust. LDP like discovery mechanism is much heavier." "Keyur Patel: @tony - complete agree about this comments about tweaking the transport." "Keyur Patel: @Enke - LDP like discovery mechanism is a lot heavier. The biggest advantage of LLDP is that discovery is decoupled from the protocol (namely BGP) 3) BGP Signaling of IPv6-Segment-Routing-Based VPN Networks [Gaurav Dawra] (12) https://datatracker.ietf.org/doc/draft-dawra-idr-srv6-vpn/ (10:33) Gaurav presenting, (10:36) Jorge Rabadan: This should be discussed in the BESS WG, it's about VPNs. I assume you plan to use the same TLV for EVPN route? Gaurav: yes. Jorge: In IPVPN, EVPN we have 20 or 24 bit VPN identifiers. Why isn't that enough? Have you thought of restricting the SIDs to 24 bits so we can reuse the VPN IDs we already have? Gaurav: The end function is a function of the end node, we are not dictating how many bits to use. Jorge: If you do that you do not need a TLV. Gaurav: For brownfield deployments (ingress PE MPLS-VPN, egress PE SRv6) you may have a mix. Jorge: Even in a hybrid scenario if you use 24 bit SIDs, I don't see why you need a TLV. Gaurav: ... Jorge: You can use the existing MPLS label field. Example, in EVPN we support non-MPLS tunnels and that is good enough, we do not need extra additional information in BGP. Patrice: Suggest Jorge read the programming guide, it explains in detail. Jorge: I did. Patrice: OK, let's sync up after. Wes: jabber: Kamran Raza: MIC:Please take a look @ "srv6 net pgm" document. John Scudder: Before you ask for adoption please trim your author list to just 5 authors. 4) Compressed BGP Update Message [Tony Przygienda] (10) https://datatracker.ietf.org/doc/draft-przygienda-idr-compressed-updates/ (1040) TonyP presenting. (10:55) Randy: Thank you, I am totally convinced now that extended messages need to apply to all types. Nikos: During past Cisco involvement we profiled BGP input and output. It has no problem on input side. Update generation and replication may cause some load. My concern is on the load that this proposal adds. You can have different peers, some can compress and some no, therefore you are breaking them in different update groups and thus making it more expensive. TonyP: My implementation data may contradict your implementation data. If you write your BGP in Python you probably do not want to do that. Nikos: Coming back to the input is the constrained I/O. TonyP: The weakest point in the chain is how you can put it out. JGS: Lines cut. Keep the comment to the point. Tony: It is implementation aspect. Nikos: I do not believe that this is a problem BGP needs to solve. Tony: We have contradicting data. Proof-by-anecdote can go on all day. Keyur: We have an IDR draft for extended messages. If the messages are extended with bigger window size how would this solution stack up considering convergence is paramount for BGP. TonyP: When will all the deployments of extended messages be in place? The world will be a better place when the speed of light is increased. RobertR: IO bottleneck in the virtualized environment applies when you have a very badly designed system. If you are telling that 10s of Gbps is not enough for BGP something is very wrong. Tony: OK, another data point. Jakob: Convergence is affected by FIB download and policy execution and very little with what you are talking about. I have asked someone to do a clear bgp on a VPN sessions with millions of routes. Thet eventually did and took a look at the input queue - that was zero. The RIB download was the problem. TonyP: we have deployments where RIB download does not matter. Stephane Litkowski: Not taking a position on bad/good, just trying to understand. What I see is I have some IO issue, you say we have plenty of cores, but frequency of each core is decreasing each year while we get more cores. Do we need a solution to balance over more cores? Tony: We don't have solution for multiple TCP sessions. Stephane: Why not? Tony: We've tried to spec it... 3 times?... over the last 20 years? We can do it again. Gaurav: Curious whether you have done any analysis of this proof of concept? TonyP: When I presented the data it is of pretty high confidence that it is worth doing. JGS: Thank you. 5) Populate to FIB Action for FlowSpec [Zhengiang Li] (10) https://datatracker.ietf.org/doc/draft-li-idr-flowspec-populate-to-fib/ (11:03) Jie Dong presenting on behalf of Zhengiang. (11:05) RobertR: Flowspec does not prohibit to install wherever you like. You do not need any other bit to indicate this. Put it in whatever database your data model supports. Jeff Haas: I agree with Robert. What makes this a little problematic is ordering. Flowspec has implicit ordering, 5575bis has explicit ordering too. The difference is FIB vs ACL. If you have ordering this may change and complicate your implementation. Jie: For normal flowspec rules there is a requirement for ordering, but here it is similar to normal routes in the RIB. JeffH: If you're controlling your inputs that strongly the need for a bit is not really there. Ruediger Volk: The semantics of F bit means that I really do not care whether the route is used. Is that my correct understanding? Are you expecting that insertion of such rules has an exact subset of routers that will act on it and the other subset wil ignore it? I have problem seeing whether this is a good thing. You either know that all of your devices can do it or you are driving your network into dangerous non-deterministic mode of operation. Jie: Maybe a new capability? 6) BGP Neighbor Autodiscovery [Xiaohu Xu] (10) https://tools.ietf.org/html/draft-xu-idr-neighbor-autodiscovery-01 (11:09) Xiaohu presenting. (11:12) JeffH: All my earlier LLDP comments apply, about roles and so on - these are good ideas. Differences are scoping. This one is somewhere link and subnet scoped. It can get flooded further via another multicast scope. Nikos: How are you using the AS number? Is that your own AS number? In the TLV I would like to see more data on AS numbers with which I am willing to peer. Xiaohu: It contains own AS number. Nikos: If you receive this, does it mean that I am willing to peer with you? Xiaohu: That is a local peering policy decision. Nikos: But anyone who sees your messages will keep trying to peer with you, even if you keep refusing. Keyur: I am not sure if the hello mechanism is needed inside bgp with keepalives there are discovery protocols, lets leverage them and not load BGP up. RobertR: We have exactly the same draft proposed in 2014. I like your transport, UDP/179 is nice to have. My suggestion is to take a look at that draft and reuse it. Enke: AS number is 4 bytes and we are done with that. Get rid of this TLV. Rick Taylor: I like this in principle. How are we going to secure this - I do not want to broadcast my AS number and whom I am willing to peer with. Security in multicast is difficult. JeffT: That's why original draft is link-local. Xiahu: We will consider security considerations. JeffT: The intention of this presentation is to extend the transport. Enke: If you look at LDP - it uses TTL hack (GTSM). Put TTL 254 and check on reception. There are multiple drafts for multiple protocols that do that. JeffH: We have a lot of interest doing discovery. here and for IGPs. It seems that all the authors should be kept in the loop to synchronize. Sue: Should we holds an interim for BGP? Quite a few hands. Action to chairs. 7) Persistent Route Oscillation in BGP Constrained Route Distribution [Jakob Heitz] (10) https://tools.ietf.org/html/draft-idr-bgp-rt-oscillation-01 (11:19) Jakob presenting. JGS: You show on slide 4? that the originator is R1? JeffH: 4684 does kinky things for rewrites. VPN route flooding goes along that path. RobertR: When we wrote RTC RFC we never considered hierarchical RRs. Two solutions - addpaths from top level to lower level. Jie Dong: You can also consider the cluster ID in this scenario. The update could be discarded based on it. Jakob: In this scenario there is no actual cluster. Jie: There is another draft related to RTC problem in the hierarchical and maybe we can consider a common solution? Jakob: I remember that and we talked many years ago. Thise are two separate problems. Jie: That draft suggested some modifications to path selection rules. Jakob: those modifications do not conflict with each other. Enke: If you look at RR spec, it has a text on preferring shorter cluster list. In case of hierarchical reflection you need to follow that recommendation. Jakob: Does not help. JeffH: Normal BGP does not do it, 4684 breaks the rules here. Would have been worth reviewing why 4684 breaks the rules the way it does. JGS: It is always interesting when someone identifies a bug, and that there are a couple of possible solutions. Jakob: This is a solution that we have implemented, we can talk about other solution too. (11:29) JGS: meeting ended.