John Scudder: Administrativa - assign jabber scribe (Nathalie Trenaman) - assign minute taker (Massimiliano Stucchi) Chairs 5 minutes ################################################################### * Discuss Current Drafts draft-ietf-grow-wkc-behavior WGLC done, move forward draft-ietf-grow-bmp-adj-rib-out draft-ietf-grow-bmp-local-rib draft-ietf-grow-rpki-as-cones draft-ietf-grow-bmp-registries-change WGLC? draft-scudder-grow-bmp-peer-up Call for Adoption? 5 minutes ################################################################### John Scudder invited everyone to read his draft and ################################################################### draft-szarecki-grow-abstract-nh-scaleout-peering - Rafal Jan Szarecki ################################################################### Rafal Jan Szarecki presented: https://datatracker.ietf.org/meeting/104/materials/slides-104-grow-draft-szarecki-grow-abstract-nh-scaleout-peering-01 Job Snijders: Is applicatbility within a single administrtative domain ? Rafal: From the AS perspective we can use it between ASns, but it's rather one administrative scope. It should work, but we are not sure. Ignas Bogdonas: What you describe does not specify the protocol and it's more about applicability. What is to standardize here, then ? Is this the right format - the RFC - for this kind of info ? What is the role of the IETF here ? Rafal: Is this a question to me ? Ignas: A loud thought. We have a similar issue with BGP Pick. This probably is in the same direction, and this is just a thought. Rafal: Thank you. Ron Bonica: I think informational is the correct category here. There were no more questions nor comments. ################################################################### draft-ietf-grow-bmp-local-rib / draft-ietf-grow-bmp-adj-rib-out - Paolo Lucente ################################################################### Paolo Lucente presented: https://datatracker.ietf.org/meeting/104/materials/slides-104-grow-draft-ietf-grow-bmp-local-rib-draft-ietf-grow-bmp-adj-rib-out-00 Jeff Haas: When you say FIB do you mean FIB or active routes ? Paolo: Both. Jeff: There are use cases considering either one of those, so I think we should clarify it. Paolo: If something in the text is not clear, please speak up. Jeff: I will send you my notes. Igor Gashinsky: I think this is overdue. Paolo: I think at the beginning we were offering limited ways f Igor: Usually the problems in collecting data is timestamps. If you can have one protocol exporting everything, it would be helpful especially for correlation. How can we help you move this forward ? Paolo: We should talk later. Jared Mauch: I'm also interested in everything discussed by Ivo. Paolo: I had another draft in 2014, called BGP Path Marking. It was an attempt at describing the problem of understanding which are the active paths. That draft didn't get enough traction and support. I also have interest in what Jeff was saying earlier. Job: There were no objections in moving the draft along from reviewers. John Scudder had some questions, though. If people could have a look at the draft, we could move it on. There were no more questions nor comments. ################################################################### draft-sa-grow-maxprefix - Job Snijders ################################################################### Job Snijders presented: https://datatracker.ietf.org/meeting/104/materials/slides-104-grow-bgp-maximum-prefix-limits-00 Jared Mauch: Yes, please. I would be happy to help you with the draft, and working with the vendors as part of the implementation keys. The outbound issue has especially bitten us sometimes. Job: Look forward to working with you. Kaname Nishizuka: I support this draft. John Scudder: Based on experience of RFC7606, I would ask you to reconsider asking the vendor to be creative with the outbound policy. Job: I suggest the session would be turned down. And that's the only thing I want to sufggest. John: Please, reconsider this. With inbound we can do it because it's the most sensible thing. With outbound there might be better choices. Job: I look forward to discussing this. Jared: I agree with John Scudder. Job: I would prefer to destroy the session because it creates a fault in the network and makes it visibile as issue. Igor Gashinsky: I agree with Scudder and Mauch. We need a set of options for a vendor to do. I understand for many networks it would be best to just tear down the session. For my network I would prefer not to do it. Can we make sure that this limit is post-policy if we go ahead with this ? Job: It is. Igor: It is not explicitly stated in the slides. Job: The intention of the document is to make it unambiguous how the mechanism works. Igor: We need more options. Ruediger Volk: What I think should go explicitly on the list is if the implementation of the session termination on overflow inblund include the info on what limit was hit. Job: You can include the number in the message notification Ruediger: You should. The creativity that was described earlier can lead down an unexpected path., I can imagine people doing weird stuff or asking for particular stuff. Thomas Graf: I would like to see in the capability exchange if there is a prefix limitation. This can also reused in BMP to have a vew on how many routes would be expected. Job: There is a draft in IDR to communicate prefix limit to other networks. You can check that. Jeff Haas: This is a potential time to discuss the twitter of BGP that we've discussed in the past. Warren Kumari: This sounds grand. You should mention this on the IDR list to make sure they're informed the change is going to happen. Job: Good feedback. We can talk about that. Alvaro Retana: If we're changing State machine, maybe it should be in IDR. Job: I will talk to them. There were no more questions nor comments. ################################################################### draft-xu-grow-bmp-route-policy-attr-trace - Yunan Guyunan ################################################################### Yunan Guyunan presented: https://datatracker.ietf.org/meeting/104/materials/slides-104-grow-xu-grow-bmp-route-policy-attr-trace-00 Jeff Haas: The good thing is that it is good for correlation of logs. Unfortunately a discussion came up some sessions ago about adding this to BMP. The problem is about what you're trying to trace. We probably don't want to get that giant list of output into BMP itself, though. Here if you want to keep the interesting things, not in BMP, but we can move the problem into telemetry. Telemetry means you can tell your routers about looking at specific prefixes. Telemetry might be a better solution. Ynan: Thank you for the suggestion. I think it's an optional approach to do that, but I can't really tell which one is better now. I forgot to mention, here the policy part, it is not a policy itself, it's just an indicator. For the policy you use GRPC to export. Jeff: This is still useful and it has some use. Certain providers that I know, the chain of policy will give you less hints about why and where something changed. Ruediger: There are different questions that come up in the problem space you're addressing. Depending on the questions, different tools and logic are appropriate as solutions. Tagging information into regular BMP streams would match very easily and nicely oif you create additional info for one pass in your egress or ingress policy. Usually something happens that will produce a BMP record, and tagging into that, giving info you are interested in is nice. Using BMP for doing single stacking through one policy, which could be big and have plenty of conditions does not look feasible. It maybe interesting to ask vendors to implement this. I've been asking to try for my use case to scale things down and give me the opportunity to tag on on the drop primitives, an optional exit codes that tell me the reason for rejecting customer routes. At some point in time I want to create reports for the customers to tell them what's wrong with what they're announcing. This can't go into BMP records. Susan Hares: Sorry if I repeat my advice. One of the things for the actions that Ruediger described, you can use functionalities from netconf. I encourage you to look at those options. We need more eyes and reviews there. If you think Yang models are better, please have a look at them. It's just another thought to choose between. Yunan: Thank you for the suggestion. We should do a comparison of different options. Igor: You are trying to fix two different problems here. What you are trying to see and why. What is simple, why is more complicated. I don't know how you would express some of our policies in these messages. I don't think you can encode most of this into the BMP messages. I don't see how useful it could be to put all this into BMP. One use case would be Ruediger's log message. Ruediger: We are not doing that much complexity. If you get the chance for marking the points with something that will be meaningful for you, it may change some of your policy to emit the specific reason where now it's all the same. You want to know the reason for a drop, and you might end up with a split. Igor: An example of policy: We have a chain that strips communities, blocks route, sets local pref. Block that route is divided into areas about bogons, and others. Block bad might stop because of some issues. Do you want logs to specifically tell you this data and where the issue was ? Some people need that, some others don't. I'm not sure this belongs to BMP. Yunan: I'll explain how the policy works for us. We don't use recursion under route policy. Job: This is very interesting. My concern is that it might be challenging to correlate the BMP messages with the policy that existed at the time on the routers. Yunan: Can you explain slower. Job: When you send the BMP message to the collector, it might be hard to correlate what the policy was. If I update the policy every few seconds, I can't know what version of the policy was at the moment the BMP message happened. I don't have a solution for this. I however encourage you to contibue working on this. Thomas Graf: I also think it's important. With adj-rib-in and adj-rib-out we know exactly what we have and where, and with this we know which policy at which time. I think the yang policy configuration should not be part of BMP. Yunan: We will do that. Thank you. There were no more questions nor comments. ################################################################### draft-chen-grow-enhanced-as-loop-detection - Yunan Guyunan ################################################################### Yunan Guyunan presented: https://datatracker.ietf.org/meeting/104/materials/slides-104-grow-chen-grow-enhanced-as-loop-detection-00 Ruediger Volk: I saw the emails on the list about it, but didn't read them. I wonder wether you are aware of the ASPA being developed in sidrops. Yunan: I don't know the details. Ruediger: It's for doing AS-path filtering, Have a look there, as it might be a good source for feeding into the policies you want to run. ASPA is a very solid concept and the information base you could get from it could be trustworthy and certainly should not be ignored. Job Snijders: Very interesting. If we know it's not an as-poath coming from a route leak, then what ? Normally I would not accept such a route anyway. Yunan: Very good suggestion. I think I might check policy records to see what happens. Job: This could empower networks to figure out they're being victimised. John Scudder: Do I correctly understand that youre identifying path poisoning attacks ? Christopher: That's one thing she showed. John: It seems like a lot of this could be addressed today by looking in the routing table to see all the looped paths that were not selected. In an ideal world you should be able to take it and analyse it offline. I don't thhnik it would be needed to change the protocol for this. Yunan: We are not changing any protocol. I agree there have been work done on this. Jeff Haas: Our implementation shows what route are installable. Being able to identify what kind of loops you see is a useful thing. Christopher: I think I agree with Job's comments. Also with Jeff's comments. But I haven't seen much of this in th edraft. Yunan: The goal is to understand what's going on. Alexander Asimov: It's a good thing to have internal paths you're receiving with your own as. The problem though are IXes, which are not visible in your path and there's no way to retrieve them. Yunan: We can discuss it offline. There were no more questions nor comments. ################################################################### AOB ################################################################### No AOB reported.