On Wed, Mar 21, 2012 at 5:19 PM, Robert Raszuk <[email protected]> wrote: > Hi Chris, > > >> In the end, I think 'bgpsec suggests' that the operator would make >> some decision... ideally the same decision across the network. > > > Such decision is inherently per prefix. So even assuming ideal case and such
yes > policy like in your example would be the same across given AS how would you > see such policy to be the same across the entire path given update traverses > ? is the policy supposed to be the same across the whole of the path? does, today, 2914 have the same policy for prefix 128.2.35.0/24 as as701 as as7018 as as4134 ? The policy wrt any bgp learned (AND ANNOUNCED!) route is per-operator, 'per asn' at best. In reality there are even cases where where the policy is 'per link in an ASN'. I'm not sure why expecting this to be different in SIDR is a good thing to do. > Aren't you afraid about swiss cheese effect for end-to-end connectivity if > some ASes prefer signed and some other non signed paths ? In general, today there is no coherent policy across ASN's. EXCEPT 'make sure packets get as close to the destination as is possible for my asn to do.' I suspect that over the course of ~7-10 years BGPSEC (or similar) would rollout across enough ASN's to ensure 'good enough' security for a large portion of destinations/prefixes on the network. I hope that would be the case. I believe that, as I said before (perhaps not on sidr?) that the process looks something like (for an individual operator): 0) hear about bgpsec 1) figure out which end is up 2) upgrade code/etc to support this function after deciding it's worth your while. 3) start collecting stats on internal usage + customer usage + customer-certification-of-resources 4) action fixes to customer setup and internal setup 5) start signing your prefixes as you can 6) use metrics to judge success there's likely a few middle steps skipped there... I'm sure someone else could find other bits to add. (really jayb@att has done a lot of work on this planning...) > > What happens in your example if singed comes with PATH_SIG listing 4 ASes > (pCount=1 of each) and real AS_PATH is length of 3 ? so, pcount I'm not a fan of.... but, you're suggesting a path that's invalid? or impossible? > If you set local pref on inbound (just like shipping code allows for origin > validation) you will deliberately choose longer path as best since LOC_PREF > is checked much earlier in BGP Best path then AS_PATH length (even assuming > those would be comparable across two attributes). 'use the appropriate knob' I made an example, make it better. > Thx, you too! -chris _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
