Interdomain Routing (IDR) WG TUESDAY, November 10, 2009 1300-1500 Afternoon Session I Orchid East ===================================================== CHAIR(s): Susan Hares (not present) John Scudder Scribe: Russ White AGENDA o Administrivia 15 minutes Chairs - Note Well - Scribe - Blue Sheets - Document Status - Charter o draft-dong-idr-vpn-route-constrain-00 15 minutes Jie Dong o draft-ietf-grow-bgp-graceful-shutdown-requirements-01.txt Bruno Decraene 15 minutes o draft-decraene-idr-rfc4360-clarification-00 15 minutes Pierre Francois o draft-vvds-add-paths-analysis-00.txt 15 minutes Pierre Francois o draft-ietf-idr-advisory-00 15 minutes Tom Scholl o draft-ietf-idr-bgp-bestpath-selection-criteria-00 15 minutes Rajiv Asati Notes: Sue isn't at the IETF Slides one day before the meeting == WG Doc Status Bestpath is new WG doc Optional transitive will do WG last call just after IETF == Charter Update Tony at the mic: Can we not use the word promote, no marketing John from the front: Please send me text Lots of milestones to update Lots of the cluster up in Aug/Sept of next year == Generalized VPN Route Constrain Jie Dong presenting/Huawai Robert Raszuk: Which route on PE is unwanted? Jie Dong: Points out a specific route Robert Raszuk: Then simply use RT constraint based on what the receiver wants to import. We don't have a case of unwanted information today. If you have a case where you have unwanted information. John Scudder: Observation. Your'e assuming there is such a thing as a single v4/v6 vpn? Jie: No. Scudder: An RT defines a VPN. By definition, a v4 van and a v6 van are two different vans, and should be deployed using two different RTs. Jie: This is one example, there are others, such as multicast. JGS: The van definition divides the multicast up into two cases, one where the multicast and unicast vpn's contain the same sites. In the other case, they would contain two sets of sites, but then they would be in two different vpn's. In either case, this case doesn't exist. Jie: There are many other cases than these two. Rajiv Asati: If you assume that the van needs to be defined with the same RT for v6 and v4, then this problem would arise, but if the v4 and v6 vpn's have different RT's, then the problem will not arise. I don't think the assumption is valid. RR: If a customer has both v6 and v4, why wouldn't they want the same routes at all sites? We did think about doing RT constraint on a per AF basis when RT constraint was written. The only gain was a small amount of processor overhead, and good implementations don't suffer from this. I don't think this is a valid concern. Jie: We have differing opinions on this. (??): This make configuration simpler, meaning you don't need to pay attention to your RTs as strongly. RR: The whole point of having the same RT is that the vpn's for a given customer should be congruent. You should have the RT's aligned with the vpn's. Jie: L2vpn and L3VPN--would you use the same RT for this, for two different sets of sites? This would make the configuration more difficult. Rajiv: I thought this was v4 and v6. Jie: You could generalize this to all vpn's, not just for v4/v6. Rajiv: Are you saying you could have the same RT for multiple sites because you have multiple vpn's? If you construct a van that has both v4 and v6 routes being distributed across all sites, it's okay to use the same RT. It depends on the vpn's you want to build. Jie: It is possible to use different RTs. JGS: And I would point out that this solution works in existing implementations. Jie: But that's manual configuration. JGS: Manual configuration is something that's already done. Vijay Gill: This looks more like a deployment issue than an on the wire protocol change issue. JGS: Perhaps we should take this to GROW, if that's the case. == Graceful Shutdown Bruno Decraene == Request for Clarification for RFC4360 Pierre Francois (?) Danny McPherson: Clarifying question: The RFC says the route should not be propagated, not that the community should not be forwarded. PF: I agree. We are trying to figure out if ?? DM: The distinction is that no_export says the route should not be forwarded, not the attribute. Bruno: What's in question is transitivy. JGS: The answer for the errata is that if you can make a case that the RFC is meant to say is what you're describing, then it's an errata. If, however, it's a change to the way the current RFC works, then it needs to be a bis. RR: I don't think any new application is required. Transitiveness is defined in the base BGP spec. If the attribute is not transitive, and it's not recognized, the route isn't sent. What I need is needed here is a new thing, rather than changing the concept of transitiveness. PF: Should we write a draft for transitiveness? RR: No. JGS: What's in the base RFC is for the route, not for a bit in the attribute. Albert/Ericcson: Please present the graceful shut down solution? We've seen the requirement, but not the solution. PF: It's being presented at GROW, not here. Should we present it here? JGS: It's okay if we make this change on the fly. We may have the time. PF: How about we continue the agenda, and if we get to the end and have time, we could do it then. JGS: We'll put it on at the end. The question hinges on if the RFC was underspecified or are there bugs in the implementations, or? PF: We thought it was a bug, but looking at the RFC, it seems like they are in spec. Tony Li: The correct answer is that the implementation is receiving something it doesn't like, it should process it (be liberal in what you receive). It looks like you have a bug here. == Analysis of paths selection modes for Add-Paths PF JGS: have you asked any operators about this? PF: I'd like to get rid of some of these modes first. JGS: You might have a chicken and egg problem. JGS: Can you clarify the modes you have listed? PF: KO/~OK means you have the backup path that is your fast convergence path. Rajiv: Can you clarify the data plane complexity? PF: This is about the number of cycles you need to spend vs the number of cycles you need to spend now to select the set of paths to advertise. RR: Clarification: What do you mean by all paths? What really matters is all paths with different next hops? JGS: Is it correct that what you considering in the graph is "all paths," or all paths with different next hops? PF: The graph needs to be fixed, it should say all paths with different next hops (?). == BGP Bestpath Selection Additional Criteria Rajiv Asati == Graceful Shutdown Bruno Decraene (Rajiv turned the microphone off, there was a bit of delay while we sorted this) RR: I understand why you want to get rid of transient loops? But why should you have support for tunnels between ASBRs, when this isn't normally supported by ISPs? BD: If you want the complete solution, then you need to deal with tunnels. RR: We can do it with no packet loss, if there are no tunnels. RA: Good solution. Would you suggest doing an advisory draft that coulee deb used to resolve this problem as well. BD: RA: But this would allow signaling to allow peers to support it or not (?) BD: With this draft it's automatic. If you want to shut down the whole ASBR, you have to make certain all the peers are shut down. RA: So you already thought about it, etc. BD: Yes. Vijay Gill: Is this a real problem? The cost seems to be high for what we are gaining. BD: Cost/benefit analysis. Is the cost enough for you to do the shutdown, vs the cost of doing something like this? Vijay: We have procedures that prevent the problems associated with this draft. When you want to bring down a session, you do AS Path Prepends until the path is no longer used. We have a script that does this, I'm not certain why we should extend BGP for this. BD: AS Path Prepend doesn't always work. Vijay: The amount of effort doesn't seem to justify the amount of packet loss at the edge of the network. Jared: This seems to be something that could be done by all the vendors, rather than adding something to the protocol. RR: BGP Community. It doesn't need to need to be AS Path Prepend, there are many options here, the idea is just to use any of these and reduce packet loss. Jared: I'd rather see something done on the vendor side to shut down the session. Danny: The advisory way of doing things would seem to be good if an entire session is going down. You could do per prefix, etc, using 1998, etc. I don't know why you can't do this today with existing facilities. PF: The problem is the ASBR will do this, but the session will shut down through a withdraw. I receive an alternate path, and I switch to the alternate path, rather than shutting down the session. If the withdraw gets to a router that does not have an alternate path, it will lose packets. With this method, the withdraw doesn't happen, instead, it allows the other routers to switch, rather than simply dropping packets, because the alternate path is learned throughout the network. Danny: I understand the problem with the withdraw. In practice you're not going to have intimate knowledge about when the alternate path is correctly propagated. PF: The overload doesn't work because it doesn't stop using that router as a next hop. Danny: The overload bit is intra domain. PF: Please send me all the alternate solutions, so I can look at them and add them to the draft. Tony Li: We have customers who are running voip over inter-as links, they don't like to drop packets. There is a lot of motivation for this. It would be really nice to have a cleaner bit of semantics. You can use other policy options, but adding this is very light weight, and gains a lot in policy, it's simpler to implement, and cleaner. PF: Having the community we have been discussing here transported over the iBGP links/session, would this be a clean semantic, as well? General: Yes. PF: If you override Local Pref, it doesn't work, you need to propagate the 1998 community to the iBGP path, so the local routers can do the correct override. JGS: A lot of people need to read and comment on this draft.