/*** * _____ ______ _______ ______ ___ ______ * |_ _| ____|__ __| ____/ _ \____ | * | | | |__ | | | |__ | (_) | / / * | | | __| | | | __| \__, | / / * _| |_| |____ | | | | / / / / * |_____|______|__|_| |_| /_/ /_/ * |_ _| __ \| __ \ * | | | | | | |__) | * | | | | | | _ / * _| |_| |__| | | \ \ * |_____|_____/|_| \_\ * * */ Interdomain Routing (IDR) WG TUESDAY, November 15, 2016 1550-1820 Afternoon Session II Grand Ballroom 3 ===================================================== CHAIR(s): Susan Hares John Scudder Meeting starting. o Administrivia Chairs 10 minutes - Note Well - Scribe - Blue Sheets - Document Status Note well applies. Status overview since last meeting. 2 new RFCs. 2 new WG documents John asked for sense of the room on the deprecate-draft. Hands and nods suggests that a good idea. Waiting for implementation reports on ext messages and RTC. IDR wiki content updates. o Large BGP Community 15 minutes slides: https://www.ietf.org/proceedings/97/slides/slides-97-idr-large-bgp-community-00.pdf https://tools.ietf.org/html/draft-ietf-idr-large-community Job Snijders + Jakob Heitz Jakob presenting. Overview of large communities. Job presenting. Attributes. Jared Mauch: This attribute probing would be done after it is tested in the lab. [discussion] Keyur Patel: This is good work. When you deprecate something, what does that mean to the software that is already deployed? Job: It gets a clear instruction to IANA not to give that number to somebody. I have no way of forcing vendors not to use those deprecated code points. The target audience is IANA, what you do with it is up to you. Robin/Huawei: You criticized us in the slides. As an architect I must admit that we made a mistake and we should have followed the rules of the IETF. Huawei sent apology letter to the mailing list. We also explained the reason - it was targeted at a DC solution which moves very fast. SDN based solutions are popular in the industry and we had to find some solutions at that time, EVPN was not mature back then, and remote next hop was seen as a possible solution for the customer at that time. John Scudder: In interest of time management we have two more talks coming on codepoint management. We should be working on the best practices. Thanks for providing a comment. Robin: I am working on an SDN controller as an architect and customer requirement move faster than our standards. John: Please hold this topic for now, Jeff may address it in his topic. John: Thanks to all team of large communities, it has been an interesting experiment. Sue: It is really good to hear what operators need now. o Code point management 15 minutes Jeff Haas Jeff Haas presenting. Sue: Some people say that we move too slow. Come and talk to the chairs immediately if that is an issue for you. Mikael Abrahamsson: Does IDR own the registry or can any working group do that? Sue: IDR attributes are controlled by the IDR WG. Mikael: I have seen in v6ops WG work on new types. Alvaro: No. The registry definition defines a registry policy too. The allocation from the registry requires an RFC approved by the IESG. If some other WG is trying to allocate a BGP parameter me as an AD I need to do something. John Scudder: We talked in the past on adding a designated expert to the registry. Alvaro: Some allocation policies require a designated expert. Even if that is a document past LC, approved by IESG, it is required too. Sue: What is the status of BGP attribute registry that currently exists? What is the IANA status of that registry? Alvaro: Standards action. Anyone can allocate things from the registry. Sue: What prevents it from going random? Alvaro: If some other WG requests a BGP parameter I will read that draft and check. If that does not sound right I can refuse allocation. It could be that it is OK for someone else to request a BGP parameter. IDR would have seen the draft. Sue: Does IESG have a control over attribute? Alvaro: No. When you define a registry you need to be very specific on what you want to do. John Scudder: Out of time. This is important though. [discussion] Murray Kucherawy: The WG should own the registry. What happens when the WG is shut down? Jeff: When WG closes it goes to the responsible AD. Extended Experimental Path Attributes for BGP 15 minutes https://tools.ietf.org/html/draft-haas-idr-extended-experimental Jeff Haas Jeff presenting. Hannes Gredler: In ISIS we have such an attribute. Nobody is using that. Keyur Patel: The problem is that you have one code point. Why not to expand and have more bits? If we go FCFS path eventually we will need to change the values. Jeff: Will be addressed in a couple of slides. (Also per Jonathan Looney TCP has a similar mechanism.) [discussion] Job Snijders: Thank you for putting this idea. I have a concern on people not abiding the rules and still proposing the rules - that may not work eventually. A comment made earlier was on time to market to be as short as possible, and this draft does not address that concern. Jeff: If there is a structured way for people to do what they want and there is a filtering in place it should work. Job: It might be worth considering not filtering this. Randy Bush relaying for Sandy Murphy on Jabber: What was the blocker PR in previous talk? Jeff: Juniper term for a bug report that blocks a software release. Robin: We implemented the RPD mechanism based on our draft. Jeff: Discuss this on the list in the context of the prior presentation what the solution should look like. o Advertising Segment Routing Traffic Engineering Policies in BGP https://tools.ietf.org/html/draft-previdi-idr-segment-routing-te-policy BGP Link-State extensions for Segment Routing https://tools.ietf.org/html/draft-gredler-idr-bgp-ls-segment-routing-ext Stefano Previdi 5 minutes Stefano presenting. Stefano asked for WG Adoption to the draft-previdi-idr-segement-routing-te-polcy. [AI] [discussion] No questions. o Applying BGP flowspec rules on a specific interface set https://tools.ietf.org/html/draft-ietf-idr-flowspec-interfaceset Stephane Litkowski 10 minutes Stephane presenting. Acee Lindem: What if the actions prior to this changed the interface (say, PBR)? Stephane: In this case it will not be used as the incoming action will change the interface. Acee: It would still be filtered if it was inbound? Stephane: Yes. [discussion] Sue: a private comment: In the WG we had discussions about revisions to v1. Part 1 was to get errors fixed, and part 2 was to decide the ordering problems with existing v1 actions. Does this apply to v1 and v2 actions? Stephane: Yes Sue: In that case some people talked to me at NANOG they just want filters, and no actions. Have you heard that discussion from people who are using flowspec? Stephane: No. Sue: The discussion was about filters only and no actions. Robin: We proposed redirect to generalized ID. I would need clarification on combining the previous versions. When we have generalized ID, the definition of the set is not necessary specific and static, it may change with time. What we do in that case? Stephane: Not certain whether I understood the question. Robin: I will discuss this offline. Jeff Haas: If I try to interpret the question - interface set IDs are not specific enough. Robin: Taking offline. o Dissemination of Flow Specification Rules for L2 VPN 10 minutes https://tools.ietf.org/html/draft-ietf-idr-flowspec-l2vpn Albert Dong + Weiguo Hao Albert presenting. [discussion] Himanshu Shah: Is this L2VPN by using BGP signaling? Albert: No, this is for FS signaling. Himanshu: Is this ingress PE asking egress PE doing some action? Albert: This is for filtering only, not signaling. Sue: This is not for signaling. Robin: This has been presented several times before at IDR. We can talk offline. o Equal-Cost Multipath Considerations for BGP 10 minutes https://tools.ietf.org/html/draft-lapukhov-bgp-ecmp-considerations-00.html Petr Lapukhov Petr presenting. [discussion] Jeff Haas: An observation. When I was learning BGP may years ago I had a question why those features are not documented in specifications. The knobs are safe to operate only in certain topologies and the current DC deployments use BGP not just for routing. Jeff Haas: GROW had a similar issue when they tried to document as transition. Many vendor dependencies needed to be documented. This may be a bit bigger work than you expect. Jeff Tantsura: Anyone who tried to configure BGP in multivendor environment has been hit by that. Jeff Tantsura: Question to Petr - you should expect changes from vendors in time. Petr: If this is a BCP document for people to understand. Jeff Tantsura: Multiple vendors are at different stages of ECMP handling, and your document will need to grow in multiple dimensions. Petr: That is understood. We started this document based on actual deployment experiences. Documenting is easier than enforcing. Shawn Zandi: I understand most of this is happening on the single box. As an operator it is important for us to have the same decisions being made by different vendors. o BGP FlowSpec Extensions for Routing Policy Distribution (RPD) https://datatracker.ietf.org/doc/draft-li-idr-flowspec-rpd/ Zhenbin Li 10 minutes Robin presenting. [discussion] Sue: You also made an indication that there is an implementation of wide communities that will need code point allocation. o BGP Extensions for Service-Oriented MPLS Path Programming (MPP) https://datatracker.ietf.org/doc/draft-li-idr-mpls-path-programming/ Zhenbin Li (Sue Hares speaking) 10 minutes Sue Hares presenting. [discussion] Robin: 3 years ago my team did research on this work, there were several options proposed on this draft have been discussed internally. Some of those design principles should not be confused. Segment list sometimes can become label list, and that is confusing. Segment and label are different concepts. MPP and redirect to tunnel should be decoupled from the label list. Some redirects are implemented by the label stack and not by the tunnel. We need not to mix those options. The draft has a name of idr-tunnel-encapsulation, but that may be misleading. It may be covering too many options. The next draft - the segment list - seems to be a different concept from the label list. I think this is a problem. We do some prototype work based on open source. Now that I have explained this - BGP will be very very important in the era of central controller applications. John Scudder: Hannes, do you want to respond?. Robin: Hannes, please let me finish. Robin: BGP is hot for a multitude of solutions. If we have one than one draft this is not enough, we need more than one draft, I hope that WG has got the feedback coming from my own opinion. We can setup a design team and I will share my experience and we will work on a reasonable solution for the industry. Robin: If protocol extensions are defined only by the IDR WG - maybe we can do something with the SPRING WG on the MPP. Hannes Gredler: I tried just to understand what this is. Is it a general way of mapping prefixes to tunnel stacks? Sue Hares: Let’s talk with developers on this. We could talk in the bar on this. Jeff Tantsura: We have been doing similar things in PCE. Some generic routing protocol approaches seems to be of value. Sue: There was also a hackathon on some of this too. Robin: In the architecture of MPP and segment path programming we proposed the extensions requirements - those requirements do not include just BGP extensions, it requires IGP and PCE extensions for the whole solution to work. Please remember this as this solution has been prototyped by our team. o BGP Link-State Extensions for Seamless BFD https://datatracker.ietf.org/doc/draft-li-idr-bgp-ls-sbfd-extensions/ Shunwan Zhuang 10 minutes Shunwan presenting. [AI] request WG adoption [discusiion] Jeff Haas: Is there a requirement for a path to be symmetric? Do you care that the session traverses the same path in both directions? Shunwan: This question is for research. Maybe it can use a different path. Jeff Haas: So you do not care. Jeff Haas: With a BFD WG chair hat on. This extension to BGP-LS seems to be reasonable. Should this work be more general? Robin: Thanks for Jeff's comments. BGP-LS is not so hot now. There may be some new tools. At the past meeting my colleague made comments and tried to get WG adoption, but later coauthors had a lot of changes as this is a hot work. We apologize for this work. After this meeting I will talk to you on BFD and BGP-LS to find a portable solution if this is OK for the working group adoption. o Carry congestion status in BGP extended community 10 minutes https://tools.ietf.org/html/draft-li-idr-congestion-status-extended-community Zhenqiang Li Jie Dong presenting. [discussion] Hannes Gredler: Adding a dynamic bandwidth on top of prefixes is a problematic thing. I could see some of network operators getting frightened of this. Hannes: How does this work with existing implementation, e.g., link bandwidth community? Hannes: Would a BGP-LS with Stefano's extensions be applicable here? Jie: Can BGP-LS advertize the bandwidth utilization of the link? Job Snijders: At this time I would not support the adoption of this as it is semi broken. There are multiple conflicts. Job: My management systems can see the utilization of my links, and based that polled utilization information I can steer my traffic via influencing the routing policy. As a joke maybe you would consider adding in a session capability indicating that the link is congested. Jie: This is to signal congestion to another AS, congestion happens on a link between the backbones. Job: The common operational practice is if I hand a packet to you it is your problem to care about that packet. John Scudder: Can you explain on this diagram which router advertises this community? Jie: Router X advertises it and steer the traffic over one of the set of egress links. Job: Exposing this information may be disruptive to the routing system. Jie: This is configurable, you can set this for specific customer and for specific granularity. Robert Raszuk: For bandwidth you are using one octet, and assume I have 10000 sites with different bandwidth types, how do I encode that? Jie: We can change a unit to 10 gigabits. Jeff Haas: What route you would attach this community to? Jie: Based on policy you can choose to attach it to specific prefixes. Jeff Haas: BGP-LS seems to be a more natural point to use this. The congestion is a property of a link, and not a set of prefixes that go over that link. If you attach it to a prefix that represents the link address that approach might be more reasonable. Jie: This allows for steering traffic for some prefixes only, and not for all. [?Jonathan Hardwick?]: If you are deploying this over public network you may encounter multiple congestion points and will need to deal with multiple copies of this congestion indication. Second - if you apply this to particular prefixes this will affect update packing, you are decreasing the number of prefixes that share the same attributes. Randy Bush: We noticed a lack of metrics in BGP a few years back. The work in this area is useful but I do not hint it is ready for the prime time. Convergence is a major concern. I have two prefixes and a metric disagrees - what shall I do. The IDR work has a tradition of not accepting the draft until it is perfect. There is useful work in this document but it is not ready. John Scudder: Regarding code point - the draft has a suggested code point in it. The registry that you want a code point i FCFS - all you need to do is to fill a form and you will get it. Jeff Haas: A private experiment? o Shortest Path Routing Extensions for BGP Protocol https://www.ietf.org/internet-drafts/draft-keyupate-idr-bgp-spf-01.txt Keyur Patel 10 minutes Keyur presenting. [discussion] Alvaro: Routing AD hat on. This is very nice that you are reusing the formats. But changing a selection process is in fact defining a new protocol. And that is outside of the scope of IDR, I would like to see discussion on the problem outside of the IDR, rtgwg can be a good fit, take a discussion there, do not wait for the next IETF but do that earlier. John Scudder: Line will be cut soon. Hannes: In Berlin we had a lot of controversy on how you would do flooding. You use BGP as a northbound protocol to controller and you do not share much of the information between the peers. Keyur: There is no flooding here between the nodes. The routers establish the sessions with controller or reflector. Think of it as a one hop reflection, no flooding over the fabric. Acee: Discussion in Berlin covered multiple flooding options. In a DC environment an advantage of this is that you will have a much sparser set of connections at an expense of using something other than BGP. Randy Bush: You solved the problem for a few stupid devices that don’t do ISIS well. I am so-so on the controllers and datacenters, I am a BGP lover instead. Unusually I have no strong negative feeling - BGP scales. Uma Chunduri: On metrics - it says that you can use IGP metrics. Why didn’t you specify the metrics here? Keyur: We made a mistake, give us text to address that Jon Mitchell: You mentioned you are trying to contain the scope of failures, in the large DC routing draft that is covered. Why don’t; we deploy ISIS for this?. Keyur: The draft that you mentioned assumes that every peering is inband. We are taking those peerings off. John Scudder: Running out of time. Keyur: We have peering to the controller only. The update gets to controller and gets reflected back,. Updates in the controller are cheap. Kireeti: I object to link discovery being out of scope. Everything is in scope in BGP. o Route Leak Detection and Filtering using Roles in Update and Open messages https://www.ietf.org/id/draft-ymbk-idr-bgp-open-policy-01.txt Keyur Patel 10 minutes Randy Bush presenting. How many operators in the room? How many operators who never made a mistake? [discussion] Job Snijders: I can help with the question on the differences between the complex and no OTC - one is a lot of work and the other is what I have today. I assume all of my sessions are complex. Not everyone may agree with this though. Not all of our peers are customers, but from my perspective they are customers. I see this in support tickets all the time. Negotiating this relationship may be complex. Second issue for not setting the relationship at the beginning - it may change over time and this will require negotiating with the peer. John Scudder: We are over time. Keyur: If you have to renegotiate - then lock your RIBs and session bounce, we have a document for that. Randy Bush: What I am worried is that I am in Germany and I offer some local German provider transit and local peering, this typically results in two sessions. That is where the complexity is. Shane Amante: Regarding two sessions - I can see other configurations that can deliver the same over single session. Job Snijders: I want to make it clear that I appreciate the thoughts and a dialog on this topic. There clearly is an itch that can be scratched. Jon Mitchell: If this is meant to be configured per session maybe the default should be customer? If this is a default in a single line? Randy: If you ship all boxes default to customer no sessions will come up. Randy: We have a long list of previous accidents of missing policy. Jon Mitchel: Missing policy can be solved by another draft. Randy: The other draft is based on communities. Jon Mitchel: [missed] Randy: If you are asking configuration by default? Ruediger Volk: I would like to see the classification and giving a peering to open a session requiring a knob is reasonable. For customer to be open by default is right thing. Jared: I would support adopting this. This is to close the gaps that vendors have not been able to address the gaps. Randy: It is not only vendors. John Scudder: We will continue on the mailing list. [adoption request]. Total 2 hours 30 minutes Meeting ended. Additional, if time permits. Slides provided with meeting materials: o Extension to BGP's Route Refresh Message 10 minutes https://www.ietf.org/id/draft-idr-bgp-route-refresh-options-00.txt Aamod Vyavaharkar