On 3/26/14, 6:31 PM, Christopher Morrow wrote: > On Wed, Mar 26, 2014 at 5:54 PM, Randy Bush <[email protected]> wrote: >>> unless you can always be assured of testing from the device which is >>> having problems. >>> >>> You could imagine an NMS/tool-set which knows: "Login to device before >>> testing!" >>> This also doesn't work of routing protocols for the device fail... >> >> i am in the noc 20 router hops away. so the code has to go hop by hop, >> logging in to every router en route. the sec folk will love that. you >> should talk to your sec folk. oh, you are your sec folk. > > So, I was presuming that the LLA was ONLY for the ptp links, and that > loopbacks would still be standard old addresses like today. > > If the above is the case (my presumption) then you have access to the > local-lo0 equivalent as along as your IGP is healthy, and you're ok. > Of course, as soon as you pooch your IGP you're sunk :( > > I'm, again, not arguing FOR this configuration, just saying you could > make it work, at a price of longer outages (most likely) and more > (much MUCH more) complexity in your operations. I don't see what LLA > gets you that: > 1) put all your ptp/loops into 1 aggregate > 2) do not announce the aggregate (internally (see schilller paper) > nor externally) > 3) acls on the edge that drop traffic destined to your ptp/loops addresses.
Having had the opportunity to do this, for better or worse several times that's basically what I've done, drop traffic bound for the interior infrastructure aggregate via ingress acls. I think when were were discussing this in the w.g. that it has the potential to make things such as recursive next-hop calculation much harder since using link-local-scope addresses that aren't on-link for you would seem problematic. maybe using the loopback is an acceptable alterntive for some applications but you loose access to some tools this way > complexity is going to cause you pain, it is going to cause you > problems and it is going to lengthen outages :( avoid complexity. > > -chris >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
