Re: [GROW] ISC Response to draft-ietf-grow-unique-origin-as

2011-09-29 Thread Christopher Morrow
in the vein of 'new deployment folks may want to shortcut all of the bad lessons everyone else learned' On Thu, Sep 29, 2011 at 4:20 PM, Leo Bicknell wrote: > So the question to ask is, do we have a good reason to strongly > encourage all new Anycast deployments to be in this model, as opposed t

Re: [GROW] ISC Response to draft-ietf-grow-unique-origin-as

2011-09-29 Thread Leo Bicknell
In a message written on Thu, Sep 29, 2011 at 03:04:03PM -0500, John Kristoff wrote: > It seems to me this is VeriSign trying to document a BCP that works for > them and may work for others. So perhaps it is just the BCP status > that is disconcerting? That may be part of it. At the risk of offe

Re: [GROW] ISC Response to draft-ietf-grow-unique-origin-as

2011-09-29 Thread John Kristoff
On Thu, 29 Sep 2011 19:07:06 + Leo Bicknell wrote: > time. I think the question is if anyone else on the list cares one > way or another, because if no other opinions have been changed we > might as well stop. I often play contrarian or skeptic, if not an honest critic when I take the time t

Re: [GROW] ISC Response to draft-ietf-grow-unique-origin-as

2011-09-29 Thread Christopher Morrow
jumping in in the middle... On Thu, Sep 29, 2011 at 3:07 PM, Leo Bicknell wrote: > In a message written on Thu, Sep 29, 2011 at 11:22:45AM -0400, Danny > McPherson wrote: >> With normal unicast there's a single tree for the prefix in the routing >> system, while anycasting inherently introduces

Re: [GROW] ISC Response to draft-ietf-grow-unique-origin-as

2011-09-29 Thread Leo Bicknell
In a message written on Thu, Sep 29, 2011 at 11:22:45AM -0400, Danny McPherson wrote: > With normal unicast there's a single tree for the prefix in the routing > system, while anycasting inherently introduces a polytree for the prefix. > However, anycasting with a common origin AS creates a 'ps

Re: [GROW] ISC Response to draft-ietf-grow-unique-origin-as

2011-09-29 Thread Danny McPherson
On Sep 29, 2011, at 9:35 AM, Leo Bicknell wrote: > > Ok, fair enough. So let's ask the direct question: > > Would it not be even better then for them to have a unique origin > ASN, and publish the list of paths that originate the route, > achieving the same result without needing to have an

Re: [GROW] ISC Response to draft-ietf-grow-unique-origin-as

2011-09-29 Thread Leo Bicknell
In a message written on Thu, Sep 29, 2011 at 09:27:57AM -0400, Danny McPherson wrote: > I never said "does not require any pre-knowledge". As a matter of fact, > what I said, and what the draft says, is that with unique origins the > services operator _could publish in a well-known location a

Re: [GROW] ISC Response to draft-ietf-grow-unique-origin-as

2011-09-29 Thread Danny McPherson
On Sep 29, 2011, at 9:06 AM, Leo Bicknell wrote: > > Seriously, show me an algorythm to find a leak for a Anycast service > that does not require any pre-knowledge about how the Anycast service is > configured. I submit such a thing does not exist. I never said "does not require any pre-knowled

Re: [GROW] ISC Response to draft-ietf-grow-unique-origin-as

2011-09-29 Thread Leo Bicknell
In a message written on Wed, Sep 28, 2011 at 09:35:55PM -0400, Danny McPherson wrote: > Simply put, if detection or policies can't be defined (discriminated) > based on authorized origin and a single upstream adjacent AS alone then > adjacent ASes and upstreams need to be codified. If the origi