IDR - IETF 85, Atlanta Chairs: Sue Hares, John Scudder Notes: John Scudder Jabber Scribe: Gregorio Manzano Time stamps are approximate and are relative to audio file Audio: http://www.ietf.org/audio/ietf85/ietf85-grandballroomc-20121106-0900-am1.mp3 Slides: https://datatracker.ietf.org/meeting/85/materials.html ===================================================== Interdomain Routing (IDR) WG TUESDAY, November 6, 2012 0900-1130 Morning Session I Grand Ballroom C ===================================================== CHAIR(s): Susan Hares John Scudder o Administrivia Chairs 10 minutes - Note Well - Scribe - Blue Sheets - Document Status o Making BGP filtering an habit: Impact on policies draft-cardona-filtering-threats-00 Pierre Francois 10 minutes o Distribution of MPLS Traffic Engineering (TE) LSP State using BGP draft-dong-idr-te-lsp-distribution-00 Jie Dong 10 minutes o North-Bound Distribution of Link-State and TE Information using BGP draft-ietf-idr-ls-distribution-01 Hannes Gredler 5 minutes o Considerations for Route Reflection and EBGP draft-scudder-idr-ebgp-rr-02 John Scudder 10 minutes o Transitive BGP Graceful Restart draft-zhang-idr-transitive-gr-01 Alvaro Retana 10 minutes o Service Advertisement using BGP draft-keyupate-bgp-services-00 Jan Medved 10 minutes o BGP Remote-Next-Hop draft-vandevelde-idr-remote-next-hop Gunter Van de Velde 5 minutes o Authenticating L3VPN Origination Signaling draft-ymbk-l3vpn-origination-00 Arjun Sreekantiah 15 minutes o Scalable BGP FRR Protection against Edge Node Failure draft-bashandy-bgp-edge-node-frr-03 BGP FRR Protection against Edge Node Failure Using Vector Labels draft-bashandy-bgp-frr-vector-label-00 BGP FRR Protection against Edge Node Failure Using Table Mirroring draft-bashandy-bgp-frr-mirror-table-00 Ahmed Bashandy 15 minutes Speaker shuffling time 10 minutes Total 1 hour 50 minutes ===================================================== Meeting begins ~ 00:07:00 Administrivia, chairs report - Errata in review 00:09:00 - Jeff Haas: MIB status. Probably at point where MIB Doctor would be good, but mostly we are stuck at needing implementations. - Sue: Yes, if you have a MIB implementation, please talk to Jeff or one of the chairs. - Reminder about implementation requirement. Please let the chairs know! A formal implementation report is generally not required. ---- 00:11:00 o Making BGP filtering an habit: Impact on policies draft-cardona-filtering-threats-00 Pierre Francois - Local filtering of overlapping prefixes can do harm to neighbors. (Audio discontinuity at about 00:16:30 was when the mic got unplugged. Meeting stopped until mic was reconnected, so nothing lost.) - Informational draft. Work may be a useful contribution as both a warning about how the BGP standard works, but also for operational BGP issues. So, not sure which group to proceed in. 00:30:45 - Jeff Haas: GROW has a document by Russ White and others regarding overlapping routes. - Pierre: It's related. - Jeff: As with theirs, there is no guarantee that a more-specific is connected to its aggregate, especially with IPv4 runout. So, filtering more-specifics automatically can be hazardous. - Pierre: That's exactly the point, yes. - Jeff: Taking this to GROW, perhaps collapsing into their draft, is useful. Contributes taxonomy about how routing system is actually used. - Pierre: Operators understand this stuff less well than you expect! 00:32:50 - Alvaro Retana: I'm co-author with Russ of the draft Jeff mentioned. One of the beauties of BGP is that every AS has the right to do their own policy. What's bad for one is good for someone else. That said, I agree the other draft should explain both potential bad as well as good. This came up recently at LACNOG too. Our intent with our draft isn't for everyone to filter everything everywhere. Our intent is that you do it in a controlled fashion. - Pierre: I acknowledge the need for filtering. The problem is that automatically distinguishing between what is, and isn't, safe to filter is difficult. 00:34:20 - Ruediger Volk: Explicit documentation of counter-intuitive policy interactions is useful. I wonder about other situations where there are overlapping policies. It would be nice if I had a policy language predicate that let me write policies that say "this is actually a more specific to some aggregate I have around..." - Pierre: A filter me...? - Ruediger: I could use a more-specific in a particular way if I know I have an aggregate. - Pierre: Aren't you expecting people to play nice? - Ruediger: If we could make decisions based on the dynamic knowledge that a super/subnet exists... - Pierre: I agree, but there won't be incentives for... - Ruediger: If I'm missing the tools for expressing stuff, I can't do a lot. I have the gut feeling that such a predicate would work against a stable system, because there would be feedback loops in the policies. 00:37:20 - Ruediger: After figuring out what CAN be done without creating an unstable system, looking at what help that presents for creating better policies would be worthwhile. I'm quite sure there are... - Pierre: Shouldn't Pedro update his draft, standardizing tags? - Sue: In the early days of the Internet we had policies that did what you said, in route servers. - Ruediger: I think I've heard a few times that one or the other vendor promised to do one of the simple things. It hasn't happened anywhere. It may well be Pierre's problem can't be attacked by anything that also is stable. 00:39:00 - Carlo (?) from LACNIC (?) but speaking from previous life as operator. I agree that filtering more-specifics automatically is dangerous, but I also think that forgetting about automatic tools just won't scale in the future. - Pierre: If you monitor your traffic, it's just about detecting that traffic you receive from one peer, that you send out to another peer, is not zero. That's a policy violation. If your edge routers give you the means to do that of course. This would be an exceptional case, so picking up the phone might scale. This is the feedback I've gotten. - Carlo: You're assuming everyone knows how to work with, and monitor, BGP. That's not so. I agree with Ruediger that we need more automation. [comment time cut by chair] 00:41:00 - Keyur Patel (on Jabber): You could do the suppression using aggregates if the nexthops match with a more specific routes. - Pierre: Yes. In that case you're sparing memory on your FIB and forwarding the same way. He's right. - Pierre: where should this become a WG doc? IDR or GROW? - John: Let's discuss after the meeting. ---- 00:42:00 o Distribution of MPLS Traffic Engineering (TE) LSP State using BGP draft-dong-idr-te-lsp-distribution-00 Jie Dong 00:46:30 - Hannes Gredler: I agree there is a need for a unified protocol for extending and disseminating TE information. I'd like to invite you to work with the BGP LS-TE authors to include your work (which is very nice, BTW) as part of the LS-TE framework. It's been a recurring customer request. - Jie: Thank you. - John: From my point of view, that'd be the best outcome, assuming the WG is happy with it. We'll find that out from mailing list comments, but I think that's a good way forward. ---- 00:48:00 o North-Bound Distribution of Link-State and TE Information using BGP draft-ietf-idr-ls-distribution-01 Hannes Gredler 00:52:00 - Expect interop testing by late Q1 2013, hopefully will have an interop report by IETF-87. 00:52:30 - Sue: Do you anticipate adding significant amount of more NLRI and information to this? Is it the first of many? Looking for more substance to operational report. - Hannes: To start with, how we want to drive extensions. There appears to be great adoption, lots of demand. So, I do expect we will have further additions. But I don't expect we'll have further additions to this spec. We'd like to start here at the level of passive information gathering, disseminating link state, interface, RSVP LSP information. However, there are lots of other ideas coming up. For example, reporting real-time stats of egress WAN uplinks, flexible influencing of BGP policy, things like that. At a certain point we want to freeze this spec and open up a new document. 00:55:00 - Sue: Thank you. I'm also wondering if you have stats on operational expense of this, other operational issues, at present. I realize you'll report again. - Hannes: Fortunately, our original projections held true. We figured this is purely control plane. As such, you can run it at a much higher frequency than BGP. Assuming it runs on a router. So far, doing scale testing we don't see anything odd. Not sure what you're after? 00:56:25 - Rob Shakir: I was the person on the list saying "help! I'm not sure this scales". Question for the chairs, if we're going to have this as a generic mechanism to put topology information into BGP can we look at that as such instead of just what's in the draft? For example, the Transport Instance BGP draft Robert wrote a few years ago might give you some separation. - Hannes: Protocols don't give you isolation. Implementations do. - John: Since that was a question to the chairs... I think you said, since the WG is working on this do we have to restrict ourselves to this draft or can we consider the architectural implications? The answer is "yes". - Sue: Rob, please raise this topic on this list. - Rob: Hannes, why I struggle with this is that it IS an implementation detail, yet if you having this sharing fate with... - Hannes: Yes, of course. And there will be bugs. And it will crash. And it will destabilize the Internet as a whole. - Rob: How do we document operational concerns without talking about implementation? - Hannes: We can put your concern in the operational section of the draft. In the long term we want a BGP implementation where fault domains are on an application boundary. - Rob: Possibly we want to do something more broadly that ties multisession, fault domains, would be useful. 00:59:40 - Jan Medved: One comment about scope of this document. Goes to data models we're planning to use with IRS. This document is concerned with topology: links, nodes, paths. Hannes was talking about freezing it after adding LSPs. Thus all elements of the topology data model would be covered in this draft so they could all be funneled into a topology server in one channel. - Sue: In this WG we do BGP. I like IRS, but... - Jan: I'm not suggesting this is an IRS draft. It's about carrying information and what information we're carrying in this channel. It's links, nodes and paths. - Sue: I encourage you to do a data model. It's just about where is the best fit. - Hannes: My discomfort is that IRS isn't doing protocols. We're supposed to do that in the respective protocol WGs. - Sue: The IRS charter is unclear, IESG hasn't ruled. - John: Thank you for putting that in context of IRS. To resolve this concern, the thing to observe is that this work makes sense even if we remove the words "IRS". If it wouldn't make sense outside of IRS we'd have a problem. ---- 01:03:00 o Considerations for Route Reflection and EBGP draft-scudder-idr-ebgp-rr-02 John Scudder 01:07:40 - Enke Chen: Have you considered respinning the route reflection spec instead of creating another draft? - John: A bis would also be valid. - Enke: We could also define error conditions and handling for RR too. I'd prefer one draft instead of two. - John (with co-chair hat on): I agree with Enke. 01:09:00 - Lucy Yong: This draft is proposed to allow reflection between IBGP and EBGP. Is that right? - John: Exactly the opposite. This draft codifies what implementations do already. When reflecting routes, do what 4456 says. If a router is also doing EBGP, it should do what 4271 says. 01:10:00 - Jeff Haas: Dear chairs: In addition to adopting the draft, do the implementation report, and RFC it before June. - Sue: Are you suggesting we shouldn't bis it? - Jeff: No, do the bis but keep the scope narrow. 01:11:30 - Ruediger Volk: As I recall, I only configure sessions to have route reflector semantics. As far I know there's no configuration of a BGP entity as a route reflector. - John: Good point. 01:12:00 - Randy Bush (via Jabber): If the WG can't trivially process this to RFC, we should be embarrassed. - Enke: I'm embarrassed too. Draft should have said that to begin with. - John: Well, it was obvious. ---- 01:13:30 o Transitive BGP Graceful Restart draft-zhang-idr-transitive-gr-01 Alvaro Retana 01:21:40 - John: In routers-in-a-line, in left-hand column you have that R1 waits to send its EoR to NR1 until the end. How does it know it has to wait until the end? - Alvaro: Normally what R1 would do is get the stuff from NR1, know that R2 is restarting, send the routes and then the EoR. But with our extension, we're saying that if you have a restarting router, R1 waits for the EoR from R2 before converging back with the non-restarting router. So that's how R1 knows to wait for R2. 01:22:50 - Enke Chen: I think there's an issue there. What we usually do is receive updates, receive EoRs from all routers other than those that are restarting, then calculate bestpath and download into local RIB/FIB. Only after that start advertising to peers. Here I'm not sure if your proposal violates that principle. I get the impression you run bestpath and advertise out without doing local installation. - Alvaro: Yes, exactly. You receive routes from peers, run bestpath, you DON'T install them because then you wouldn't have routes from your restarting router. The point is that you have complete forwarding already. - Enke: This will have side-effects. It violates the basic principle that when you advertise something you have to be ready to forward traffic. - Alvaro: We try to cover that in the draft. Most of the routes will be ones that are already in the RIB. There will be routes that will change in direction. Point is we don't think these routes will cause a loop. I'd love to see problem cases. - Enke: At that stage we just don't know. - Alvaro: That's true in graceful restart anyway. - Enke: But that's the point of EoR. - Sue: Please take it offline. 01:26:00 - Enke: Also, GR draft is in respin. If this is applicable, we should fold it in. - Sue: Yes. 01:26:30 - Warren Kumari: This seems like a lot of complexity for a case that doesn't occur much. Seems like it can be avoided by "don't do that". - Alvaro: All I can say is, we've started seeing some of this. ---- 01:28:00 o Service Advertisement using BGP draft-keyupate-bgp-services-00 Jan Medved 01:30:25 - Jan: Multisession to provide isolation between different AFI/SAFI. - Sue: We should poll WG for how many people actually implement multisession. 01:32:50 - Jan: When multiple paths are aggregated, service information also must be aggregated. - John: When you say "must aggregate the services attribute" do you just mean take the set union? - Jan: Yes. - Ruediger Volk: You write "optionally transitive". Do you mean "optional transitive" or something else? - Jan: Optional transitive, it's a typo. 01:36:30 - Randy Bush (via Jabber): how do i communicate the authorization needed to see or use the service? - Jan: We don't address authorization. It's a good point. - Lucy Yong: Similar question. This is about advertisement, doesn't allow consumer to request a service. - Jan: Right. - Lucy: BGP is bidirectional, you could also let the consumer request a particular service. - Jan: You could. Whether the consumer is allowed to do it is outside the scope of this document, it would be within the scope of the service itself. - Lucy: There's no intention to extend this work to... - Jan: It's open to discussion. 01:38:30 - Ruediger Volk: Do you intend to look into the security implications? - Jan: Yes. - Ruediger: Do you have an idea of what the requirements of the -- pretty general -- applications might be? - Jan: Some of them. - Ruediger: In other places where information like this is passed along, we're at a stage where hard security work is applied. The hard work of getting more security into BGP seems difficult to extend to this kind of stuff. - Jan: This is really advertising the reachability of services. I would think all or most of the existing/planned security mechanisms could be extended. - John: Let's note there are security questions and ask the authors to address them. 01:40:20 - Keyur Patel (via Jabber): You could use Pub/Sub model using RTs to request the service so in that case service wont be announced untill the request comes in. Authorization can be done as part of distribution. Good part of security work is done in SIDR which can be leveraged for BGP services 01:40:50 - Robert Raszuk: About pub/sub, we've discussed whether RTs should be per-AFI or global. The decision was to keep it global. I think if you're going this way and trying to use RTs to request/deny a given service you should revisit this. - Jan: Good point, thank you. ---- 01:41:40 o BGP Remote-Next-Hop draft-vandevelde-idr-remote-next-hop Gunter Van de Velde (Poll of readers -- who read it? Three people?) - Looking for feedback, please! 01:46:00 - Hannes Gredler: What's wrong with having the BGP speaker be at the end of the tunnel? - Gunter: Why should the BGP speaker HAVE to be a tunnel endpoint? - Hannes: Use recursive tunnels, and you're done! 01:46:35 - Robert Raszuk: Currently 5512 sets next hop to the tunnel endpoint. This draft removes this restriction, so I can do next hop self on any number of midpoints and the traffic will still be tunneled to the endpoint. - Hannes: So do a 5512bis. - Robert: That would be fine too. Functionality is the point. 01:47:00 - Lucy Yong: I think this is useful for nvo3. You allow to attach the tunnel encap. It's for the remote nexthop, not for the endpoint? - Gunter: It's signaling of what encap is supported by that particular endpoint. - Lucy: Can you just attach one of them, or multiple? - Gunter: As many as you want. 01:47:55 - Lou Berger: Please use tunnel types in the existing registry. 5512 didn't, then we did 5566. If you use the types, we won't have to do that work again. - Gunter: Perfect. 01:48:20 - Keyur Patel (via Jabber) regarding Hannes' question: "RFC5512 is practically impossible to get deployed across inter-as as it requires syncronization across ASes. This draft tries to solve that by using an attribute." 01:49:00 - Xu Xiaohu: Your draft wants to use a new IP address rather than a nexthop address as the tunnel destination, right? - Gunter: What do you mean by "new address"? - Xiaohu: New remote nexthop address. But the nexthop address can be remained when propagating across AS boundaries. - Gunter: The use of the nexthop isn't changed at all. - Xiaohu: You want to advertise multiple tunnel endpoint addresses. - Gunter: It's like a recursive endpoint, which you can, or cannot, use, depending on what you want to do. - Xiaoho: I submitted a similar draft at the last IETF talking about advertisement of multiple tunnel endpoint addresses. There's some similarity. Third point, you want to advertise encap type. Why not decouple the encap advertisement from the NLRI? - Gunter: We're just building up what's already out there and what people found useful. It makes sense that instead of just sending the endpoint you also send what it supports. 01:51:50 - Lucy Yong: You allow the remote to advertise the tunnel encap types they support, but in the data plane the peer can choose any of them. - Gunter: This is a control plane mechanism. - Lucy: Is this tunnel encap related to whether you use nvgre or vxlan or... - Gunter: I don't know where you're going. - Lucy: Isn't that what this is for? - Gunter: Let's take this off-line. I don't understand your point. 01:53:00 - Gunter: What do people think about this? - John: How many people understood the point? - Hannes Gredler: Isn't this softwires, not IDR? - Robert Raszuk: It's a BGP attribute. - Sue: PWE3 and L2VPN have a lot of these. ---- 01:54:00 o Authenticating L3VPN Origination Signaling draft-ymbk-l3vpn-origination-00 Arjun Sreekantiah 01:57:30 - Sue: You've mentioned L3VPN a lot. Are you planning to present at L3VPN? - Arjun: We're here because of the BGP extensions. We'd also like your input as to where to do it. - (Multiple people): SIDR! - John: Let's hold discussion of venue for the end. 02:02:30 - Robert Raszuk: (slide 77 please) I'm afraid this kind of validation can't be achieved on the ASBR. ASBRs can serve many overlapping address spaces. You're not using RT, but RT determines what the VPN is. You use the term "VPN ID" which isn't even carried in BGP. - Arjun: The RT determines VPN context, yes. Local policy on ASBR2 can match on the RT and path validation status. Policy can augment RT policy. - Robert: But you never saw the key identifier carrying the RT value. - John: short comments only please. 02:03:40 - Hannes Gredler: Please move this work into SIDR. There are already two authentication and trust models there, with expert review. - Arjun: Thanks. 02:04:15 - Rob Shakir: SIDR is in the context of the open Internet. VPN is a closed environment. Have you seen a problem in the wild or is it a theoretical problem? I don't know about other L3VPN problems but for us, we run the CEs even if on other people's networks. - Arjun: This is for the case where you have a transit provider over which you don't have control. I did get this requirement from a service provider. - Rob: A transit provider... for an L3VPN service... ?! - Arjun: Yes, inter-AS. - Rob: I question how many deployments there are where there's a pure transit AS in an L3VPN deployment. In my experience when you partner, there are two providers, using it for reach on the other's network. 02:05:45 - Jeff Haas: I'd like to encourage the authors to add something to the document explaining why the AS path that's being transported isn't secured. You're just signing the prefix. - Arjun: Yes, this is origin, not path. - Jeff: It's just not clear why we're not doing any of that other stuff. In SIDR, that's in-scope. - Arjun: Simplicity. Don't want to mandate a PKI. - Jeff: My second observation is ATTR-128 allows you to tunnel path attributes. That might let you do signatures from PE-to-PE. 02:07:30 - Bruno DeCraene: Sometimes routes are advertised inside a VPN by a SP for a reason, for example to provide access to a voice gateway, etc. Do you have a way to handle that? - Arjun: You're saying routes can be sourced from transit? - Bruno: Yes. Also same route advertised into multiple VPNs. - Arjun: Extranet? - Bruno: Or voice gateway. - Arjun: You can share keys across extranet, or defined different key IDs for the shared prefixes. - Bruno: OK. If you want to add another route to the extranet, do you have to touch the CE? - Arjun: No, just sign it with the appropriate key. 02:09:15 - Warren Kumari: This doesn't fit within the SIDR charter, so it can't go there. - John: What I've heard listening to the discussion is two high-order points. One is significant debate about whether it's a problem that needs to be addressed. That's a problem that should be had before anything else goes forward, and L3VPN needs to be included in that conversation. Second is whether the security model is appropriate. That question needs review from SIDR even if the work isn't progressed in SIDR, since that's where the expertise it. ---- 02:11:00 o Scalable BGP FRR Protection against Edge Node Failure draft-bashandy-bgp-edge-node-frr-03 BGP FRR Protection against Edge Node Failure Using Vector Labels draft-bashandy-bgp-frr-vector-label-00 BGP FRR Protection against Edge Node Failure Using Table Mirroring draft-bashandy-bgp-frr-mirror-table-00 Ahmed Bashandy - Presenting three FRR solutions. Purpose of this presentation is to get feedback. 02:29:30 - Lucy Yong: Have you evaluated backward compatibility? Deep label stack may cause trouble for load-balancing. - Ahmed: There's no conflict between load-balancing and top label. - Sue: Please take this discussion off-line. - Lucy: Also, there's an EVPN solution that... - John: Short comments please. 02:30:45 - Hannes Gredler: Short comments. Five of them. First, the requirements have been carefully constructed to fit your product and rule out others. Second, the mirror table draft because it doesn't involve any BGP extension should go into RTGWG. - Ahmed: I disagree, there's a vector label there. I mean a repair label. - Hannes: I'm not finished. It's redundant with draft-minto-... - Ahmed: Disagree again. - John: Out of time. Hannes, please send your comments to the list. 02:31:30 - John: In terms of proper venue, you've presented three different FRR schemes, haven't said much about BGP. I see Alvaro and Stewart are both here. Given you're looking for feedback about what scheme to move forward with, I think you should take this to the RTGWG ("IPFRR WG") where there is significantly more expertise on IPFRR than we have in this room, and once you've converged on a scheme that requires BGP work... - Ahmed: How are you guys not seeing this? There's a label that needs to be advertised... - John: You're still in the architectural selection phase of the work. This isn't the group in which the IETF normally does IPFRR architecture. - Stewart Bryant: I agree. Guiding principle is "do the work where the expertise is". - Ahmed: When I presented this in RTGWG I got the feedback to go to IDR. Are you sending me back? - Sue: Yes. Get architectural review you need, and when you're ready to proceed, Alvaro and Alia will send you back.