On Wed, Nov 7, 2012 at 6:38 PM, Eric Osterweil <[email protected]> wrote: > > On Nov 7, 2012, at 6:10 PM, Christopher Morrow wrote: > >> On Wed, Nov 7, 2012 at 5:47 PM, Eric Osterweil <[email protected]> >> wrote: >>> >>> On Nov 7, 2012, at 4:11 PM, Christopher Morrow wrote: >> >> just as broke, bug lodged (I hope) for a fix. > > But, but, it works for me... jk ;) >
it's (apparently, or hopefully) a display only problem... which causes pita behavior for the responder (me in this case) if i want things to sort of look legible. >>> <broken record> >>> The offer to provide input to the threats and requirements docs is a genuine >>> attempt to help. For real! :) I have the sneaking suspicion that this >>> week's... >>> err, event... cost some people some sleep. I feel like we _should_ be >>> addressing it, no? >>> </broken record> >> >> don't disagree, haven't disagreed. (I think) > > I hear ya, but I feel like this obviates our need to begin discussions with > new > design proposals. How can I offer you a design if we don't agree on what it > should do, right? 'it should stop leaks' or as someone else said: "Show how to know that the leak is a leak and not another backup path coming to light for other reasons in the system" >> nor did filtering on the upstream/customer peerings (clearly)... so >> folk that want to fall back on 'but de filterz!!' .. are also in >> failville. > > Which of the parties was filtering? neither it would seem. >> maybe? folk have to see a benefit to any of this in order for it to >> move into production use. > > Right on... I think that kind of thinking is really what's motivating a lot > of > leak-based-discussion. Quick wins might come in plugging leaks, so... > on to the threats doc? :-P > >> if as a first step resource certification >> work gets me better filtering and/or more people filtering because >> more reliable filtering is possible, good. > > Yeah, we're on the same page w/ resource certification being a prerequisite. > >> eventually though, people will realize that: >> 1) not everyone is filtering >> 2) not everyone will filter >> 3) the only solution left is something in the bgp update :( >> >> if there is another '3', let's talk about that. > > Just to follow the same logic, could I not say, > 1) not everyone is running bgpsec [clearly, it's not here yet] > 2) not everyone will run bgpsec [therefore there will be isolated islands] > 3) the only solution left can't be something in the bgp update? not sure it quite goes that way, but i (and I think everyone else) do see that not everyone in the bright/new/shiney/future future will be happily configured and using bgpsec. Even if everyone does, it's fairly clear that there will be a range of answers to "the route signatures dont match". There's a clear entrance/exit protocol for the 'islands'... this isn't getting us to a 'what is a leak, in a way I can tell from even a directly connected peer' though. >> where else does the data from which you make a decision about 'leak or >> not' come from? > > My understanding is that we need to fallback to intent. With some way to > expose > and verify intent, we get there. Discussing how to do that seems like the > right first > step, imho. ok, see brian's docs... i think. >>> seem to be enough complexities in the policy semantics that the amount >>> of effort needed to get the minimum level of expressiveness into BGP >>> could be a non-starter... Just my 0.02... >> >> perhaps you could explain more/better this problem. > > Maybe I could just say, today we have a very complex policy specification > language, and > it's not clear how much of it is used, by whom, and to what extent... If we > were to say, > ``throw it all in an update,'' I think we'd see BGP updates bigger than the > bgpsec updates. why? > As of now, if we can't agree that leaks are a problem worth addressing > and/or we can't everyone stop... 'if we can't agree that leaks are a problem worth addressing' everyone (well, almost everyone I've read) has agreed they are a problem. Even one worth addressing. There's a path that, follow the path. now, re-read the above. please. > agree on what leaks actually are, how could we _not_ use a very verbose > language to > expose relevant policy? > >>>> I think techically rpki is just the jumble of certificate data and roas >>>> that talk about: > <snip> >> this is less concerning... and it's beside the discussion of leak-or-not. > > Yeah, but I didn't bring it... I just wanted to clarify the above comment. > I didn't mean > to distract, but felt the clarification was important. ok, it didn't seem to clarify... just distract. on we go though! >> as noted on-list more than one time I'd love to see some scaling and >> such work done on the certificate repository... that's not today's >> problem though. > > Yeah, working on that for sure... excellent. >>> What are we (as a wg) trying to solve? I.e. shouldn't we be talking about >>> threats >>> and requirements? >> >> i think we are/were. > > Then I would propose that the insistence on only submitting solutions before > allowing requirements discussions is not appropriate. i had thought the requirement was 'stop leaks'. if so, again: great. also, again: how. -chris _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
