Le lundi 19 novembre 2012 à 15:57 +0000, Rob Shakir a écrit : > 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. > > > > 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. > > 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. > > 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. >
Right, I think we all know by now that modeling commercial or social desire or need is 'hard'. A good starting or way point would thus likely be to carefully study the problem space, in order to keep our pieces to develop as simple (and well defined) as ever possible. For instance, as you hint, inter domain routing knobs are currently quite often "used" to patch billing (or collection of sufficient or cheap enough billing data) shortcomings, which IMHO is a bit unfortunate. > 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. > Yep. Cheers mh > Cheers, > r. > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow
signature.asc
Description: This is a digitally signed message part
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
