Grow Notes IETF 89 London 4th March 2014 (1) Pierre Francis ietf-grow-filtering-threats Description of cases that may result in potential violation of policies in the neighborhood of ASes filtering more specific routes. It is tricky because there is no blackholing. Main message/recommendation of the draft: people who want to filter more specific or tag routes for specific purposes should do it very carefully..monitoring should be in place to identify potential violations. History: the draft has been presented at operator forums..good reception. Jon Mitchel: good job in cleaning up the language..should do it more (don't include words like "victim" and "policy violation"). Will point out specific sections. Peter: need confirmation on the list to go forward. (2) Jon Mitchel BGP Routing for Large Scale DCs Design document on how to use eBGP in a large scale DC..lots of details in it. In the latest revision added text about aggregation and convergence properties. At least one large scale DC operator has implemented the design. Some informal feedback about others implementing. Chairs: No strong support for it being a WG doc (raise hands). Follow up off line. (3) Wes George AS Migration Problem: difficult for operators to coordinate ASN changes with eBGP peers. Solution: use vendor existing knobs (local-as, replace-as, iBGP alias, etc.). No coordination required. There is a companion draft in sidr to add AS validation to path validation. This draft is an idr WG document. Recommended to share here for additional feedback. Q: should 2119 language be used to describe the necessary implementation? Ilya: Started with nice idea, but are now offering interpretation of vendors documentation. Migration is just one case. Also mentioned PE migrating in one instance, but that is unrealistic. Wes: the intent is each PE, not all at the same time. Will Clarify. Wes: it is not intended to be a cookbook on how to do migration, but more a draft about the fact that the knobs exist. We could add other use cases if they exist. Ilya: Suggest references instead of details on operation of knobs..simplify. Wes: Please send specific feedback so the draft is as clear as possible. Jon Mitchel: I think 2119 should be used..that way you don't have external dependencies. Wes: there is some risk in the specification if we're basically documenting existing features. It is local implementation. Jon: multiple vendors could be problematic. Sue Hares (idr Chair): I asked to include vendor specific info to have a proof point to move the draft forward. Jon: shouldn't that be an implementation report? Sue: we were trying to simplify the draft..process. It was easier to move trough the IESG. Jon: my concern is that the external references may not be stable. Wes: maybe we have a section that is sort of an "implementation report"..and document the how it is implemented in the body…should make the decision in idr. (4) Fabian Mejia opsec-origin-a-country Talked about a project in Ecuador to deploy RPKI-based BGP Origin Validation at the NAP.ec. Success story that brings value to both operators and resource holders. The results show routes with a valid state going from 1% before the event and almost 100% at this point. Invalid routes will start to be dropped on Mar/15. Wes: The relative cleanness of usage records, etc. is a significant barrier..requires tooling, automation, etc.. What was your experience? Fabian: LACNIC provided some tools to view the current allocations and announcements.. Some work was needed to reconcile policies. Alvaro: We educated the audience on the use of policies related to what was advertised and the potential impact; the operators then made the decision. Jared Mauch (NTT): if the performance hurts (from dropping invalid routes) then there's always going to be people that are going to use that to not deploy.. ??: I really liked the document and recommend finding a way to publish. Carlos (LACNIC): LACNIC has developed tools for looking at the routing tables, resources, RPKI, etc.. The tools are publicly available, but it is only useful for the LACNIC region at this point. (5) Job Snijders snijders-rpsl-via Problem: with RPSL there is no way to instruct a Route Server to whom they should advertise prefixes. Policy can only be described "towards" the route server, but not to instruct it to do things in your behalf. Current mechanisms don't provide the needed flexibility and functionality. Proposal: add attributes 'import-via'/'export-via' to signal the indirect policies. RADB and RIPE already run the enhancements.. Adopt?? Jeff Haas: What do the chairs think on where should rpsl should end? Peter (chair): not settled. Joel (AD): operational improvement, so it probably fits here…need charter update to give the group the option to look at a wide variety to documents Jeff: I like it. Peter: Will take adoption to the list.