1) Document status At RFC editor Queue: - idr-ietf-idr-route-filter-17.txt - idr-ietf-idr-bgp-prefix-ortf-06.txt 2) BGP well-known Communities procedures: Dave Ward Dave ward: - i sent proposal to list - well known communities - RFC 1997 - no registration procedures - two reserved spaces and defined well known - proposal is to keep one reserve space and existing well known - split 50-50 into first come first serve and IANA defined - same as ext communities - polled a few people - no other requested ranges - as on the list, req to use well known community from well know to equiv of reserved - how to know when something is well known - whether change semantics or not change to code points Discussion: Danny McPherson: One of my concerns is that many people that are using community values today will not supported in the new scheme. Dave: It is in the community reserve well-known range (0xFFFF8001 - 0XFFFF FFFF) Yakov: Why do we need to reserve well-known range? Why can't we use a combination of First-Come-First Served and Standards Action/Early IANA Allocation ? Dave Ward: more than happy to have that, that was what was one the list Yakov: any comments on that? Yakov: assume there will be no more well known communities Brian Dickson: I have a proposal new well-known community. - for effective deployment of what i'm proposing will need to be well- known community Dave Ward: What is required is that a well-known community will have to turn on a knob? Brian Dickson: My proposal requires that the last-resort community be on by-default. Dave Ward: That may mean that your feature is un-deployable given these rules. Yakov Rekhter: That is the issues with well-known communities. What is exactly the meaining of "well-known" ? Brian Dickson: At what point do we consider that the proposal is "well- known". The status of a proposal can help find the "well-known" issue. If the proposal Danny McPhearson: You are proposing a "pretty well-known community". Dave Ward: Until a community is at full standard, then it is not full- well-known. Brian: There is no consensus on what is well-known. Your definition means that no more well-known communities will occur. Dave: I would indicated, unless we agree on a procedures no well-known communities Yakov: let's take to the list. We still have an issue of what is the meaning of "well-known". 2) draft-ietf-idr-bgp4-mibv2-07.txt 10 mins MIB Status (via the presentation). Danny presenting Danny McPherson - thanks to joan - most of the stuff is there - mostly structural - a big issue is do we want to allow configuration objects - largely the consensus that no - if you use that make it known quickly - indexes... - looking for a new name for BGP extensions - all this was on the list - since no pays attention to MIB presentation - jeff summarized all this on the IDR list - look there if you are interested in the MIB - email jeff or IDR - send comments there Yakov: questions? 3) draft-knoll-idr-qos-attribute-01.txt 15 mins Discussion: Yakov: What do you want done with this draft ? Knoll: I want IDR Working Group to accept both this draft and draft- knoll-idr-cos-interconnect-00.txt as IDR working group documents. Yakov: I suggest that you combine these drafts before asking the working group to approve it. Yakov: How many people read the draft? (10-15 hands raised) Yakov: How many people feel this draft is ready for a working group draft? (no hands) Yakov: I suggest that you send email to the mailing list asking the working group chairs to poll the working group for a consensus on accepting your draft as an IDR working group document. 4) draft-chakrabarti-idr-as4-route-cap-01.txt 15 mins Discussion: Pradosh: I have a hard time finding the usefulness of the draft. Samita: In the four byte a difference between the four byte and the two byte. If configured with two route targets (four-byte and two-byte) you would get two different sets of route type. Pradosh: It is a local policy type. You can set this by configuration type. Yakov: The reason Route Targets could be either 2-byte AS based or 4-octet AS based, or IPv4 address based is to allow different service providers to use different allocation procedures of Route Targets. E.g., a provider may choose either 2 byte or 4 byte allocations. Whether a route target is IP-v4 based on 2-byte AS-based or 4-byte AS based matters only for the purpose of Route Target allocation. The receiving PE should not care whether Route Target is 2-octet AS based or 4-octet AS based or IPv4 address based. Robert Raszuk: If you have the new Route Target and the Old Route Target, what is the point of this draft? Yakov: Why does it matter from the receiving side what type of Route target you are receiving. Robert Raszuk: Receiver doesn't care. Yakov: Yes, receiver doesn't care. The provisioning system is the one that provides such a Route Target. Yakov: You (Samita) need to articulate the problem that we need to solve. Otherwise, we have a solution without a problem. Samita: The problem we faced when the receiver is configured for 2-byte AS based extended community and it receives the 4-byte AS based extended community, it looks at the type and doesn't know what to do with it. Yakov: An implementation should not be configured to accept certain types of Route Targets. The implementation should be accept all types of Route Target. 5) draft-dickson-idr-last-resort-04.txt 10 mins Discussion: Yakov: Do you want to take questions after both or after each. Brian: After each presentation. Dow: when saying it solves the BGP wedgies, you are thinking of cases of preferred and last resort?, but not preferred, second preferred, ... last-resort. - in other words, you can still have cases - this solves certain cases... Brian: Strictly the last resort. It would take the last resort out of the wedgies. Dow: There is indeterminism of the BGP wedgies that are improved by the addition of more information. It does not solve all the BGP wedgies problems. Geoff Huston: this doesn't solve the wedgies problem - solves some problems, but not the general case - adding information solves some cases, but not the underlying determinism in BGP Brian: it solves some of the wedgies problems Geoff Huston: BGP wedgies are caused by BGP behavior. My point is that it would be over-claiming to solve all BGP wedgies. Volk: - i think it solves most of the problems i would be concerned with - i think this standardization is welcome - it will help Yakov: how many read the draft ? Yakov: how many think this draft should be accepted as an IDR WG doc? Yakov: Suggest author ask the working group chairs to poll the the working group for a consensus on accepting this draft as an IDR WG document. 6) draft-dickson-idr-well-ordered-nth-best-01.txt, draft-dickson- add-paths-ordered-01.txt 20 mins Discussion: Brian: Takes multiple instance of a MRAI timer to as much as several minutes to several seconds of the Dow Street: Your statement that this reduces bandwidth. I can imagine it really increases between router bandwidth. Brian: I am talking about in-chassis bandwidth where bandwidth is exchanged. Dow Street: This is not messages between routers? Brian: Normally in chassis bandwidth is much more restricted than between routers. Yakov: with respect to extra memory requirement by Brian's proposal we need to keep in mind this is control plane memory, not data plane memory. Yakov: with respect to extra bandwidth required by Brian's proposal we need to keep in mind that the links between control plane are 1 Gigabit and up. Mark Handley: I am sure it might reduce churn of route table churn within the box. But it requires more BGP bandwidth passing to/from. Brian: An extra amount of data is flood to set-up this detailed level of information. After this point, the exceptions (failures/up-down) are the traffic. I realized late that it is the order re-changing that allows some more density of information. Dimitri: What happens when best returns to trump second-best and return to Best? Brian: When the best returns, the second best [need to provide the information]. Lixia Zhang: In our work we saw a ton of data. We saw that after the failures switch from path A to path B (due to failure in A), there are a lot of paths that stay on path A because they do not see the failure within A. Brian: You need the subsequent "N-events", because you not know what additional events. It is a combinatorial issue. Yakov: The whole purpose behind this proposal is fast connectivity restoration. If a site is multi-home, the interesting question how fast you switch between providers. How much path-hunting has negative impact in this case ? Lixia Zhang: How bad is the convergence? It is not 30% of the cases that are really bad. In the 70% of the cases, there is not a convergence problem. Chris Mark: There is 270,000 current routes and 200,000 alternate paths. Verizon networks keep 16+ paths in the network. This is very expenses for everyone. Yakov: Therefore it is important that this is an optional feature because it may be expensive to some ISPs. Brian: This is passes another set of information to different routers. Pradosh: I don't find it useful in multiple provider environment since the repair in case of failure is local to the AS. If a site is multi-homed to a single AS, the repair can be easily done locally. If it is multi-homed to multiple ASs, the repair can again be done locally in the region where they merge since in most cases, the merge point will receive the advertisement from each such provider... Brian: It is bi-direction for sending information. If you examine, the data flow you may find that there is Lixia: In the experience of worrying about the worst case, when the bad things happen multiple prefixes may have multiple prefixes where it gets really bad. Yakov: To solve 100% of problem the cost may so high that it will make the solution undeployable. Resolution after discussion: Yakov: Is there any interest in going on with what is going? Yakov: How many people have read this draft? (15 people) Yakov: How many people think we should go on with this draft (10 people)? Brian: Please send the odd-ball topologies that may stress this algorithm to me. 5) draft-ohara-idr-practical-request-00.txt 10 mins Yakov: Comments from the audience Ruediger Volk: Routers should not crash under unexpected data. If unexpected data occurs, it should be filtered away from the protocol side. This is information. Operators like to have robust router implementations. If unexpected data floats around, we want to have means to catch such data. This seems to be entirely a router implementation Vince Fuller: It is a very good case to reset the bgp peer session near the source. Yakov: This is a bit of historical information because BGP is 20 years old. One of the complaints against BGP from day one was that the error handling is simple. All errors are treated as fatal, and cause drop of BGP session. There are reasons for this. Once you pass the information, the information gets stuck on the other end. If you just ignore the information, you may get into difficulty. In the case where a BGP speaker detects an error in the BGP stream it receives from the peer the speaker may: 1) refresh the data from the peer via the BGP-Refresh processing, 2) If the error occurs a second time, then keep the connection to the peer down. Ruediger Volk: I care that you can filter out information. But that is an implementation. Yakov: If folks have specific cases, where different vendors give different interpretation to specification - please bring that to the working group. This case of non-interoperability indicates a specification bug, and we will fix it. 6) Two drafts below: Francis draft-francis-idr-intra-va-00.txt 20 mins Discussion: Dino Farinacci: Do you believe that the highest level it will be a tree of informaiton or it will be Paul Francis: I am not sure that you Dino Farancci: How far will the packet go up before it gets dropped? It goes up to the aggregation drop. Rajiv: What exactly is the draft asking for? Community value? Paul Francis: The -00 draft has a new extended community. It could turn out that there is good be that there is no additional changes to the BGP specification and very little changes to the BGP implementations. Rajiv: Have you given any thought to operational issues about having RIB that is not the FIB? Why not filter what goes into the RIB? Paul Francis: This concept of suppressing things in the RIB is problematic. Look at the all the proposal in the Routing Research group about this topic. Paul Francis: There is no topology changes. The only addition is that the routers set-up tunnels between routers. Yakov Rekhter: One way to reduce the state on routers is to have multiple areas, and within each area point Default to the ABRs of that area. Robert Raszuk: Marking with the special community it. Chris Lilentoje: Value to see in the RIB. I can still propogate this information out the RIB. Internally the RIB is not as fully populated and efficient. Brain Dickson: I think there is an interesting corner to this topic. Having the ability to suppress from the RIB to the FIB, is generally applicable to defensive proxy aggregation. Defensive proxy aggregation is when you aggregate internally but do not pass it on (???. It is important to have a mechanism that allows you to tag the things that do/do-not go into the RIB. Yakov Rekhter: You should look at NANOG-39 with presentation from Force-10, as it describes a way to reduce the size of FIB Tony Li (RedBack): We have another document series where this is appropriate for the work. It is a BCP. 7) LISPs information - Vince Fuller draft-fuller-lisp-alt-02.txt, draft-farinacci-lisp-07.txt 20 mins Vince Speaking on the LISP-ALT group. Questions: Yakov: You claim that BGP configuration complexity is a barrier to site-multihoming, but in reality how many lines of configuration is required for a simple BGP setup ? Dino: LISP full 4 lines, BGP is 10 lines. Yakov: I am sure that 6 line does not matters a great deal for others. Shane Massey: Enterprise networking people are afraid of BGP. We have mail them a template from level-3 to get connected. Tony Li: It is entirely reasonable that enterprise are afraid. How many have them sent all routes into the routing table (???) Tony Li: What is the minimal configuration to do multiple-homing? When people go to multi-homing is to balance their traffic incoming and outgoing. This requires an enormous to take all prefixes and munge the routes. Peter Lothberg: I use multi-home on my little home network. Vince: We'll give Peter's phone number to the ISPs and he'll get little sleep in the next few days. Dimitri: How does the EID space allocation work? How do you guarantee that the EID space will be contiguous over time? Vince: You create the EID space and assign it to follow the topology? You need to have the topology congruent to the EID topology (??). Topology has tunnels. Yakov: It is geographic addressing. Vince: It is not true. The reason that geographic topology does not work because (EID and addresses)[need the input here]. Yakov: There is no additional traffic that goes through the ALT traffic. Hannes: I have got one comment on the amount of geographical topology. In fixing convergence problem, we see that data driven state is the barrier to fixing the convergence problems. My request would be to avoid data driven state. Vince: It is not a requirement to use data driven state. It is not a requirement Tony Li: My understanding that EID is going to use IPv4 address space? Vince: It is not true that EID space will necessary be holding IPv4 address space or the Dino: IPv4 is a swamp. IPv6 is much better to provide geographical address. If we renumber we can have addresses. If we cannot renumber, we LISP. Tony Li: Why do LISP if you renumber? Dino: You only have renumber once more. Tony Li: The interesting place is where do you renumber the swamp?