On 3/27/14, Mikael Abrahamsson wrote: > There are people who number P-T-P links using "unnumbered" between CE and > PE today. This works for them. You just have to know the caveats ...
Is this a fair summary of the caveats mentioned earlier?[1] - not being able to specifically ping one particular interface from the management system - not having traceroute tell me on which exact path my packets are flowing - NMS/discovery limitations - attempting to understand a deployed topology - as soon as you pooch your IGP you're sunk - longer outages and more complexity in your operations. Personally, I think 'attempting to understand a deployed topology' is a bit understated. The ability to match up interfaces on different routers & do off-line analysis can be huge. Anyone that hasn't seen Managing IP Networks with Free Software https://www.nanog.org/meetings/abstract?id=785 should go look now. And to ratchet the level of hyperbole down a notch, enabling uRPF can lead to - not being able to specifically ping one particular interface from the management system - not having traceroute tell me on which exact path my packets are flowing - NMS/discovery limitations and yet enabling uRPF is generally considered A Good Idea. It's a trade-off; at work we have a requirement for either uRPF or an input access list on "user subnet" interfaces. I got lazy, enabled uRPF and had someone at my desk two days ago saying they couldn't ping the HSRP interface address. ^shrug^ the input access list is a pain to create and manual verification is so error-prone that you really have to have a program that looks at the config to verify correctness. The point being that I went with uRPF _knowing_ it was going to cause some small level of operational complexity/breakage (oh Noes!! I can't ping ...) because I thought the alternative was worse. Which is a very long intro to the section 2.3 caveats list should also include off-line analysis: using LLA interface addresses mean that you can not do an off-line analysis of the deployed topology or do consistency checks between interfaces on each side of a link. - as soon as you pooch your IGP you're sunk should be listed but darn if I can come up with the wording - longer outages and more complexity in your operations. I'm leaning towards "value judgement" and so shouldn't be listed as a caveat Lee [1] snippets I saved for generating the caveats summary list: If you go back, I have commented on that draft that we'll never ever go link-local-only, because the drawbacks of not being able to specifically ping one particular interface from the management system, and not having traceroute tell me on which exact path my packets are flowing are not acceptable. YMMV on this, of course. Gert Doering Let me be explicit for those who need it... Operating with only link-local addresses isolates the devices from management systems located in a NOC (i.e., not directly adjacent). A typical first-step diagnostic when something goes wrong is to ping the address of the suspect interface *from the NOC*. That can't be done if the pesky device only has a link-local address. Brian Haberman Well, not attempting to speak for Randy, but I'd like to see a more balanced introduction (it summarizes the benefits; it should not just defer the caveats to the body), and maybe some discussion on where it might be useful to deploy a network using lla-only (homenets or small meshy things? I can't think of any enterprise or carrier scenario where I would want to do this), and clearer statement that this may not be for everybody and is not a general BCP. And while the caveats hint at it, there's also an operational complexity burden that isn't called out - the ping and NMS/discovery limitations also apply to human operators troubleshooting faults and attempting to understand a deployed topology. LLDP and NDP add a layer of indirection in identifying what devices should be adjacent to a given interface, and only work when there is operational state available and links are up (whereas GUAs on interconnected devices can be compared by configuration alone, telling you what's supposed to be there). Erik Muller 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. complexity is going to cause you pain, it is going to cause you problems and it is going to lengthen outages :( avoid complexity. -chris > what is missing is "therefore all monitoring, diagnostic, management, ... > tools > will not work. you will be unable to maintain your network. Since the loopback address still works to poll SNMP from, ssh to, etc, I don't agree with your statement. You have to use extra special care if you want to number using LL, but stating that it *won't work at all* isn't correct in my book. There are people who number P-T-P links using "unnumbered" between CE and PE today. This works for them. You just have to know the caveats, which is what the documents tries to describe. If there are caveats not listed, do tell and let's include them. Mikael Abrahamsson _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
