Hello GROW Bit slow on the replying over here, sorry for the late chime.
Thoughts in line below.... > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Rob Shakir > Sent: Monday, November 19, 2012 10:57 AM > To: Shane Amante; [email protected] [email protected] > Cc: [email protected]; draft-foo-sidr-simple-leak-attack-bgpsec- > [email protected]; [email protected] > Subject: Re: [GROW] RouteLeaks - problem or not? > > > On 16 Nov 2012, at 04:10, Shane Amante wrote: > > >> is that better? I'm really asking whether or not there is a problem > >> and if we (ietf in general) can get a solution (or even the > >> requirements for a solution?) defined... > > > > Yes, there is a (big) operational problem wrt route-leaks. Agree with everyone!! > > > > Yes, we (IETF in general) should work toward a solution. As I stated > previously, I hope we remain open-minded as to the solution space and > do not pigeon-hole ourselves into thinking that one must exist inside > BGP, either solely or at all. Completely agree with this comment. imho part of our problem is that even though we know what route leaks are when we start defining them it gets complicated very quickly. There are several aspects that have a qualitative/subjective and to address those we may have to think outside of bgp. The operational perspective is the most important one and therefore GROW is the best place for taking up this problem, imo. > > Hi GROW, All, > > I would support the comments that Shane made here - essentially, this > is an operational concern, and we should at least properly document > what the problem is. If we can use this problem statement to work > towards a solution, then this would be a good aim. > This is a great start. There are probably a few more cases that fall into the Route leaks bucket that we should consider. I would be happy to share them with the authors and everyone on the mailing list. > However, I would urge that we consider the operational complexity, > manageability and overhead of any suggested solutions. A number of the > mechanisms in the sidr space have significant cost of implementation, > which I'm not sure is wholly being considered, and may present a > challenge for deployment of these solutions. > > Specifically regarding route leaks, I have some concerns around the > ease of classification of relationships between networks (that I raised > in idr when this was discussed) -- whilst it may be convenient to > consider there to be clearly defined categories in this space, in the > real world, I do not think that it is as clear cut. > Similar to yours, but one concern I have is that there are several non-engineering rules that also contribute to route leaks. Should we even open the can on them, or just keep it to engineering and operations while defining the problem? > My view is that GROW is the right place to begin this work within the > ietf -- however, some consultation with the wider operational community > (e.g., NANOG etc.) is likely to be advantageous to tap into the best > sources of knowledge on this matter. A solution specified without > considering those operators which are not represented in the ietf is > likely to be limited in its deployment. +1 --Anuja _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
