Meeting starting. 1 - Admin data / Draft Status 10 min Note well applies. Agenda bashing. Job Snijders: Please add BGP reject to the agenda. 2 - Default propagation behaviour without policy. draft-ietf-grow-bgp-reject Job presenting [discussion] Jakob Heitz: You mentioned IOS and we are well aware of the problem, we designed IOs-XR that fixed that problem. We cannot change it as that will break the existing configurations. Job: That can be configured as a global knob. Jakob: We will not comply with it (IOS) unless you fix that sentence. Jared Mauch: I am concerned by vendors not providing secure software for the internet. Job: My personal motivation - at least going forward we have something to document that this is an expected behavior. ?/Cisco: I have a different perspective on the datacenter operators - this may be additional work for them. Jeff Haas: BGP is used in many places. It is for operators to decide on the packaging of the default parameters. We would comply with this document if there was a knob to change the defaults. Job: How we ship this in products and how we agree how this exists as a specification are two separate topics. Jeff Haas: Any change in behavior will be […] Job: What about v4 and v6? Jeff: Anything. What I am concerned is a blast radius. There are different scopes for VPN and global routing families. Jen Linkova: We need to think about migration here too. We should not break the internet by introducing it. Jon Mitchell: It seems that the current draft as it is is fine if focused on IPv4 and IPv6. Another point on the vendors - there are major changes going in in different versions, and it is surprising for me to see that vendors would not do this. Chris Morrow: Who in the room feel that this is ready for LC? Job: There was a comment on deployability - we can work on that. Peter Lothberg: If you make a change - it is better if it behaves the same for all address families. Doing it separately would add confusion in. Consistency is good here, and it is up to the vendors to do the different implementations. The install base problem - IETF has just to listen and say that we are very sorry that you have customers. Bringing in a box into a network should do nothing unless you explicitly tell it to do so. Jen Linkova: Support the consistency. Jared Mauch: Support Peter Lothberg’s comment - this is a well defined problem, this is a real problem, and it worries me that if it is such a big problem for vendors to support it. Job: Is anyone objecting for all address families? Jon Mitchell: I only object if you have no differentiation between internal and external BGP. Job: Does anyone object to include internal? Peter Schoenmaker: We need to confirm on the list, this seems to be a small issue. Jeff Haas: It could be observed that the real thing worked here is about the profiles for the software that is already existing. Peter Schoenmaker: We need to discuss those outstanding issues on the list. 2 - Large-Communities - job 15 min Large communities usage. Job presenting. [discussion] Joel Jaeggli: As a consumer of these provider communities as someone who buys a lot of transit - today we have a rosetta stone in our routing management system we need to abstract away from the interpretation of different interpretations of different providers. It would be good to move to something better than a proprietary format of signaling. This seems like a huge improvement even if you do not standardize the expression of the intent completely. This is a radical improvement as a consumer. The audience for this signaling are not large transit providers but people who buy transit, who are not necessary in this room. This is an improvement for mid level organizations. Peter Schoenmaker: Who thinks we should adopt this draft? We will take to the list. Peter Lothberg: Does that mean that community functions will be IANA registration thing? Job: No. 3 - Why doesn't IDR know about Ops Requirements? 10 min Chris Morrow presenting. [discussion] Job: I have two comments about the communities when the transition was done from 2 byte to 4 byte AS - I think an incomplete inventory was done at that time. Another risk that I have seen - when a relatively simple idea from GROW goes into IDR it suffers from the feature creep. Some proposals were completely out of hands. Could GROW put brakes on things sometimes by saying that we need this tool to be as it should be? Maybe we could agree that extensibility is something that we not always need? Bill Fenner: Rather than not taking things into account IDR was expecting that it will be subsumed by other work, and that work took over 10 years to complete. It is not that we need to solve those problems at once. Chris: To be fair - 4 byte as document says that there are use cases that will be addressed by the wide communities draft but that draft says nothing about this particular use case. Bin Fenner: The approach was to stick that to flexible communities and expect that it will be solved. Joej Jaeggli: I think it is second system problem here. Part of the reason that this system still works is that people are not able to build new shit into it. We need to look into what is the minimum necessary thing to go in. Any debate that looks at the system as relatively flexible misses the point on how it is deployed and how it can be changed. Randy Bush relying Jabber: This has been a long standing problem - and a burden of us not doing it is a lot of crap. Keyur Patel: AS4 was standardized long time ago, and when IDR progresses standards it could look at what else will be needed. John Scudder/IDR cochair: in ideal world when we did AS4 we would have done gap analysis and obviously this deployment case would need to be fixed. In reality everyone is constrained and optimistic approach took too long. My point is - we are using all of our bandwidth for discussion on this in IDR. IDR gets used on internet routing and also all other Swiss knife things, this room (GROW) is focused on internet routing. You could have more focus here and could help us focus too. Sue Hares/IDR cochair: If you see a situation where administrative wheel for IANA needs to be turned don’t be shy and come see us chairs, send us mail and we will discuss the process with you. Jeff Haas: Several points. One - RFC 4360 4octes AS numbers - that would not work for AS4 scenarios. The discussion on AS4:AS4 did not happen until a couple of years ago. The limitations of extended communities were known for a while. Interesting observation is that 4:4 discussions were coming in in private meetings, it did not come here in IETF. The requirements to an extent overrode the solution. Chris: Take to the list. Jared Mauch: One of lessons of this - I went to vendors as a proxy to reach IDR group and that message did not go through the IDR group. It is not that operators did not approach people - I remember approaching Jeff and saying this is a problem and we need to fix this. We have tried for years to address this directly via vendors but the message did not go through. Now it became a fire drill. Peter Lothberg: This may be a typical Peter comment - i think it is time to look at what we replace BGP with, instead of adding in all those small things in. Maybe we need a new BGP for the future of the internet. 4 - opsec-urpf-improvements - sriram 15 min Sriram presenting. [discussion] Keyur Patel: What you are saying that instead of it being nice, you need origin validation for this to work. Sriram: Yes. Barry Greene/Akamai: I am glad that you are looking at this. We need to reevaluate the assumptions where URPF strict mode fits, why do we use loose mode, why was VRF mode created, and why flowspec was created, you also need to look at why jtree vs CEF was done. Peter Schoenmaker: We are out of time. Meeting concluded.