IDR - IETF 88, Vancouver Chair: John Scudder Notes: Primarily Jeff Haas Jabber Scribe: Shane Amante Audio: http://www.ietf.org/audio/ietf88/ietf88-regencyc-20131108-0900-pm3.mp3 Slides: https://datatracker.ietf.org/meeting/88/materials.html ===================================================== Interdomain Routing (IDR) WG FRIDAY, November 8, 2013 0900-1100 PST Friday Morning Session I Regency C ===================================================== CHAIR(s): Susan Hares John Scudder o Administrivia Chairs 10 minutes - Note Well - Scribe - Blue Sheets - Document Status o draft-ietf-idr-aigp-10 last call issues 15 minutes http://tools.ietf.org/html/draft-ietf-idr-aigp-10 Eric Rosen o draft-ietf-idr-add-paths-09 10 minutes http://tools.ietf.org/html/draft-ietf-idr-add-paths-09 Jeff Haas o draft-haas-idr-flowspec-redirect-rt-bis-00 5 minutes http://tools.ietf.org/html/draft-haas-idr-flowspec-redirect-rt-bis-00 Jeff Haas o draft-ietf-idr-sla-exchange 5 minutes http://tools.ietf.org/html/draft-ietf-idr-sla-exchange Shitanshu Shah o draft-wu-idr-te-pm-bgp-03 5 minutes http://tools.ietf.org/html/draft-wu-idr-te-pm-bgp-03 Qin Wu o draft-patel-raszuk-bgp-vector-routing-00 10 minutes http://tools.ietf.org/html/draft-patel-raszuk-bgp-vector-routing-00 Keyur Patel o draft-li-idr-cc-bgp-arch-00 10 minutes http://tools.ietf.org/html/draft-li-idr-cc-bgp-arch-00 Lizhenbin (Robin) Speaker Shuffling Time 5 minutes Total 1 hour 15 minutes ===================================================== The below minutes copied from Etherpad (http://etherpad.tools.ietf.org:9000/p/notes-ietf-88-idr?useMonospaceFont=true) IDR Meeting, John Scudder Chairing. Note Well. Document Status: Due to John's laptop being broken, it will go out to the list in the next few days. Agenda. Presentation BGP Vector Routing, Keyur Patel for the authors. Lucy Yang, Huawei: Is the vector node attribute new? - KP, yes. - LY since this is applied to VPN, how is it related to Route-Target policy? - KP, it's an attribute. The routes in the VPN will be tagged with their own RTs. These addresses could be VPN or regular. - LY, Can be used ibgp, ebgp or vpn. In VPN, with RT import/export policy? - KP, business as usual. - Robert Raszuk - doesn't override any VPN rules we already have. In the VPN context, VRF context service nodes. - LY: Could be in destination routing table. - KP: Services needed in network are tagged with this attribute. All BGP speakers should install it and do the necessary thing. - Steve Patrick, Google: How do you do ECMP with this? Anycast? - KP: yes. - Xiaohu Xu Huawei: Any node in the vector route, BGP router or could be non-BGP router? - KP could be non-bgp speaker. - XX: How can that router forward the packet further? - KP: Depends on the network. Consider IPv4 network. - XX: Slide says no changes in forwarding plane. - KP: Correct. - XX: How can you get NH info from packet. - KP: This is a BGP based mechanism. The transit router must either be BGP, or if not, pull it from static information. Forwarding is separate from encapsulation. - XX: List of nodes in packet? Otherwise non-BGP routers may need that? - KP: They may be static routes. - LY: Need some local configuration to nail down this behavior. - RR: No local configuration needed. Vector nodes must be BGP speakers. Transit nodes don't need to be. - LY: Tunnels! - John Scudder: There is an important speaker between vector and transit nodes. A few comments: 1. Re: WG adoption - there was a well attended SFC BoF. Unclear if ADs will charter, but seems likely. In that charter would be service chaining architecture. - RR: If we remove service chaining from this and leave TE, would this fit? - JS: Probably so. - LY: But you'd need a valuable use ase. - JS: One of the points was that "service chaining" is a misnomer. Really service composition - i.e. graph. This draft only covers strictly a chain. It may be useful to place this in the context of that group's architecture. - KP: We deal with paths in BGP. We carry chain that affects that path. Draft doesn't deal with graph, but we can incorporate [...?] - JS: Really saying that this needs to go into the context of the architecture. - Rudiger Volk: Not really able to grok the content presented. Feel uncomfortable that there's no meat in the security considerations section. Don't buy it. - KP: The only comment they'll make is that this solution works with the security mechanism that the provider implements. - RV: In particular, if attributes for controlling the traffic are passed inter-domain, I find it hard to believe that if there is nothing to ensure the integrity of the data... - JS: If you think you're going to get away with the security section today, you're "charmingly optimistic". - RR: We do check that those nexthops are inserted by that AS. Aside from that, we're not doing more than setting the nexthop. In SFC, interdomain was left out of scope. :-) Even so, all protocol extensions will happen in respective groups. Think it fits in IDR. - JS: Saying "interdomain is out of scope" doesn't mean "IDR gets to do whatever". [09:26] - JS: Not saying we can't work on this in the group, take it to the list, ask for meeting time. It's only the WG adoption that's an issue. - RR: What would it take to get chairs to consider the TE-only case. - JS: It's the WG's decision as a whole, not just the chairs. - Jakob Heitz, Ericsson: Do all the nexthops need to be reachable at the beginning or later on. Cases for both. - RR: Checking the next-one. If you think there's need to check more, let's talk. - KP: Draft may need some sort of long-length check, - LY: Possible use case for TE, may need to think about loop prevention. Both in regular and VPN environment. - RR: No loops - list of nexthops. If you want to go through same node twice, that's allowed. - Eric Rosen, Cisco: From what I understand from SFC BoF, decisions might be made based on DPI. Strugglign to see how this mechanism can be used for that. - KP: [...]? - ER: Classification,if not based on destination address, this doesn't seem applicable. - RR: We can use flowspec on this. - ER: Impose spec based on DPI? - RR: Yes. - KP: That's one way of doing it. This mechanism doesn't impose that the chains are done op-by-hop - it's by the forwarding plane. - ER: how would that work? - Thomas Morin, Orange: carry chain naming information in control plane mechanisms? - LY: How do you plan to handle TTL? - KP: We don't! - LY: How do you expect the forwarding plane to handle this? May create a loop! - KP: List of nexthops aren't re-used. Please post scenario. - JS: You just told Eric that traffic could be diverted. Our current protocols say you can't create forwarding loop that isn't terminated by policy. Questions to WG: Authors say there's a SFC case and a TE case. How many people have read? Quite a lot. How many think the WG should work on the TE case? - Robin, Huawei. This isn't the first time that TE in BGP has been brought up. Adoption for TE? Authors and a small number. Needs work before adoption: lots SFC case: no one. Please take this to the mailing list, but keep working on use cases. Thanks for very productive conversation. LY: Please throw idr into WG draft name. [09:38] Presentation: AIGP last call issues, Eric Rosen. - John Scudder: Question about multiple TLV with same code point. If processing in reverse order, have you convinced yourself that it's okay? [09:49] - ER: If you get some garbage that happens to look like a type 1 TLV, it's hard to say what's going to go wrong. Didn't think that two type1 TLVs was going to be a problem on its own. Bigger issue would be that someone thinks of a use of two type 1's in the future. - Bruno deCraene, Orange: This is different than what's in draft error-handling. - ER: There will be many more people in this room with experience in this aspect of BGP than I. It would be good to address this particular issue. Clearing the transitive bit shouldn't make this worse. - JS: As an error handling co-author. I'm inclined to agree, the WG should reconsider thaas pect of the group. - Shane for Pratima: The draft needs to define the behavior when the aigp value has reached its maximum. - JS: We should say something about this in the draft even if it didn't come up during WGLC. Would you prefer it to come up during ietf or iesg last call? - Stewart Bryant: The only question is best for the protocol. - ER: Is it broken? - Rob Shakir: Is it broken or will it break? - ER: Is the spec broken? If not, then changing the spec will more likely make the spec more fragile. - JS: Concerned that this might be unspecified. If the range is so large, this may never happen. - Jeff Haas: Better to say that this going to cap at a maximum value and if they need a larger value, then use Type 2. - ER: OK, so you're worried about wraparound. Can look at that. Metric should not wrap around. [09:57] - Defaults. Some controversy still on list. - A recommendation to disable attr. on iBGP session as well, but don't think this is really necessary, because it's unlikely operators will not go around randomly enabling on BGP sessions. - JS: Your provisioning system required both ends. - RV: If enabling can only happen on one side, but you can't tell, saying I want to receive then expecting the sender to send it probably doesn't work. - ER: Shouldn't there be a capability? No, not for every new optional attribute. [10:02] - Robert Raszuk: New draft posted that encapsulates aigp attribute into cost community. Didn't discuss punching holes in best path selection, either, in AIGP draft. - ER: That draft is 5 years too late. - JS: Are you suggesting that something be changed in aigp spec? - RR: Ideal situation to merge drafts. - ER: When talking about cost community, if we held up everything when someone said we should do it a different way, nothing would advance. - JS: This is what the UPDATES field in the RFC is for. John Scudder: Deck covers the open issues. For purpose of resolving WGLC comments. Next step would be to consider all of these. [10:23] Presentation: SLA Exchange Cisco has an implementation. - John Scudder: Is there field experience with the feature? - Solely internal at the moment. [10:26] BGP attribute for north-bound distribution of TE performance metric, presented by Qin Wu [10:06] Presentation: Advancing add-path, Jeff Haas. - Current status: well deployed by at least 3 vendors. - Concerns about advancing add-path + People weren't sure about how it would behave within a hop-by-hop network. + Issues are much better understood nowaways & documented in draft-idr-add-path-guidelines. Separate draft will carry these forward. - An issue that we still have is: how do we deal with fast convergence? - Have normative reference to draft-pmohapat-idr-fast-conn, which contained Edge_Discrimintor Path Attr. - As far as Jeff knows, there are no implementations of this feaure. - Know that operators are getting good benefits. - People on list raised that this might be useful in Route Server environments. Not doing traditional BGP, doing proxy BGP, so perhaps not critical there. - Question for WG is: we have a stable draft, it's deployed everywhere, should we remove the Normative Reference to advance - Are you aware of add-paths features? Lots of hands - Should add-paths advance in absence of Edge_Discriminator feature? Lots of hands. - Opposite question: Should we not advance it? No hands. - Robert Razsuk: If we make this feature optional, does that solve your problem? - JH: Probably split into 2 cases. That draft contains good guidelines on how to make your convergence faster. But, also muddies the waters by throwing in eBGP. Recommendationis to separate the two out and get rid of eBGP side. - RR: ??? - JH: Agree, but larger issue is do we hold up this draft waiting for a feature that no one has implemented. Need to also see 2 implementations, per IDR tradition. - RR: Different thing to advance add-paths for iBGP vs. eBGP. - JH: Do we need to add to add-paths that there is an outstanding issue with eBGP? - RR: Let's put it to the list. Add-paths draft is just encoding. Use cases were removed from it. So, not a good idea to put it back. JH: One additional issue. Current draft just says whether you're sending or receiving add-paths. Is the WG interested in discussing adding a cap on the # of paths you're willing to accept from remote peer? - RR: It was discussed in base draft. It got really hairy, particularly from perspective of RR. - Adam Simpsion: a number of implementaitons already support that capability. - JH: Will take that up with people to suggest a path forward. - Eric Rosen: Have experience with that and would recommend to never do it. - JH: Attempting to keep progress on [10:18] Jeff Haas: Next Presentation - Flow Spec Extended Community - Allows traffic to be redirected to a VRF - Issue is: 0x8008 - Small fix: suggest that this has same encoding as RT extended community - Create IANA Registry - JS: How many think WG should take this on? Decent # of hands? - JS: How many should not take this on? No hands. - Eric Rosen: Are you familiar with Ext. Community Registry draft? - JS: Yes - ER: Please make sure this draft aligns with organizational principles of that draft - ER: Draft reorganizing it has been sent to IESG. - JH: Has that draft been scheduled on IESG telechat? - Stewart Bryant: It's either on a telechat or on a Last Call - JS: OK, let's move foward. [10:22] Inter-Domain SLA Exchange, Shitanshu Shah - Concern that parameters were already defined and should re-use those. - Re-use IPFIX for Traffic Classifier & TSpec for rate profile - Have working implementation of the draft - Submitted implementation report for the draft - Looking for more implementations [10:25] JS: Do you have field experience? SS: No, just implementation experience, for now. [10:25] BGP attribute for North-Bound Distribution of TE performance metric, Qin Wu - Re-use BGP-LS attribute with 7 new TLV's to icnlude link delay, link variation, packet loss, BW, etc. - Think it is better aligned with BGP-LS and think it is ready to request WG adoption. [10:31] Questions? - JS: Of those who read the draft, how many think this is ready for WG adoption? Yes: Decent # of people. No, need more work before adoption: Nobody. We'll take it to the list. Sense of the room is to adopt it. [10:32] Architecture of Central Controlled BGP, Robin @ Huawei - Yesterday, presented similar topic in OSPF WG - Reference Model: BGP controller controls BGP clients in its administrative domain - Decouple BGP client and forwarding - Need protocols extensions to connect BGP controller and BGP clients + Need IGP extensions to automate Auto-Discovery, Connectivity processes between client & controller + Need capability negotiation between Controller and BGP client - Use Cases: + Acquire BGP Topology; BGP has been extended to disitrbute link-state and TE info. + Simplify operations and maintenance: use I2RS API's to allow operator to setup/control BGP policy configuration + VPN service can be more rapidly deployed + MPLS Global Label Allocation - guarantee that all nodes understand global label space + RR-Based Traffic Steering + Inter-Controller Applications - svc set-up between nodes is proxied by BGP Controllers - Next Steps: Soliciting feedback & comments. [10:49] - Eric Rosen: Simplicity of central control is greatly underestimated. To avoid single point of failure, you need multiple central failures, but if you are assigning global labels from 2 different central controllers, then you have multiple points of failure and need to worry about things like coordination between the central controllers. And, finally, you have to worry about having reliable communication path between the client and controller and ensure it's not used for distribution of labels used in fwd'ing plane. - Robin: This has been proposed several times in IETF. I think this is simple, because you don't need to adjust fwd'ing plane, just distribute label over control plane. I don't see the complexity. In L3VPN, I proposed this scenario for mobile backhaul and it can use global label. - Robert Raszuk: Saw this at OSPF, IS-IS and now BGP into I2RS. However, you are not providing any protocol extension in document or in slides? - Robin: Propose draft to recognize these ideas so we can do work on new solutions on a centralized control. You mentioned protocol extensions, right now this is more of a framework. - WeiWu @ Huawei: Point of draft is to resolve problem of underlay network service. The detail protocol extensions may be defined later. - Luyuan Fang: Controller concept is not new. Don't see anything new here, but if you have specific protocol extensions then please present them, because I'm not seeing them. Second point, is wrt global labels. I think MPLS scales well because of distributed labels. If you want to have centralized labels, use PBB. - Robin: We presented an overview of use cases. Re: I agree that MPLS is working well, as is, but think there are ways to improve MPLS with work on PCE. - Ali Sajassi: Need to decouple global label and controller. Already have a draft in L3VPN that already talks about central controller, so I do not see a need for this draft. Also, I did not hear an answer to Eric Rosen's question. - Robin: This is just use cases for the architecture. Re: global label and multiple controllers ... that's a good question. - Adrian Farrell: You can do anything with any protocol. We have a WG already that is chartered to inject and retrieve routing information, which is I2RS. If what is going on here is you want to inject global labels, then I think the work should be taken to I2RS. - Robin: OK, will coordinate with chairs. - Chris Liljenstople: Adrian said pretty much what I wanted to say. What are the problems you are actually trying to solve? We need to know that, before considering changing the protocol. - ???, NEC: If we don't like to use Openflow, then we need to define a new protocol to communicate from controller to fwd'ing plane. - JS: I would like to point out that that is probably under the charter of I2RS. [11:03] Meeting adjourned.