-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Ole-san
Ole Troan wrote: > Seiichi-san, > >>> BGP peerings and what not could use link-local addresses. e.g: >>> >>> router A -------------- router B >>> fe80::1 fe80::2 >>> dead:beef::1/128 c001:cafe::2/128 >> if >> I get a BGP neighbor down message with fe80::2 >> then >> what address do I ping, trace? I can look at config of router A >> and my address is dead:beef::1. What's the other side's global address? >> If router B isn't mine, I may not have a clue. >> >> The challenge here is that we don't always have the knowledge of >> whats on the other side of the router. When you have tons of these >> links on one router, this is just making trouble shooting harder. >> >> Even if I did know the other side's global address, monitoring pings >> cannot be sent to fe80::2. We'll have to ping c001:cafe::2 and >> manually link that status with fe80::2 peering session on the NMS. >> I would hate to do that with hundreds of sessions running inside my network. >> That's always been a causes mistakes. We want to monitor what's >> acutally running and not some alias address. > > yes, I see that point. > how do you troubleshoot when you get a OSPFv3, RIP, or ISIS neighbor down > message? We're sort of drifting away from the original /127 /128 discussion, but I think this is a good point so I'll make a comment on this one. My router is configured with 2001:db8:aaaa:bbbb::bbbb:1 fe80::bbbb:1 the "bbbb" wich is the 48 bit to 64 bit is copied to the next to the last 16-bit field. We do this so when we ge an ospf neighbor down, we can guess the global address easily. When we do show ipv6 ospf neighbor, we can guess the global address from the output. We still need to figure out the aaaa but that's allocated on a wider scale versus the /64 which is allocated to each link. (note: ethernet links and not /127) I don't use /127 internally, but if I did, this addressing scheme will not work. I'll need some other way to work around. I don't run RIP (not anymore), and ISIS, but that's how i do things. Some others do it other ways, like mapping the Ipv4 address to the interface identifier to achieve the same goal. I don't do that because someday I hope I won't have to operate dual stack networks and just be single stack IPv6. I would loooooooooove to have show ipv6 ospf neighbor give me a global address output. > cause then you'd only have a link-local address or a CLNS address. or is BGP > troubleshooting different in some way? yes. In two ways. One, in BGP we only have to deal with a single address (not technically, but operationally we don't have to care about the link local). Two, in BGP we have to deal with the unknown. Your neighbor may not disclose all the information to you. In OSPF, its your own little world most of the time. BTW, I tried link-local BGP peering once many years ago, and swore to myself to never do it again. > this is a solvable problem. it could be done through a management system, > better support in routers, a script pinging the link-local address from the > router, and I'm sure lots of other solutions. yes, I understand your point. There isn't a solution available to me on my current router, but if there was better support for ospf, I would appreciate the implementation very much. However, for addressing of links, dealing with the unkown is complex enough, that having special odd addressing structures (like not setting a global or setting some odd /128)on that link does not seem like a choice that would speed up troubleshooting. That's a risk that many operators would not really want to take. Even if the link is not used by BGP and only by OSPF, having a uniform simple design throught a routing domain is essential in running a 24/365 NOC team. The requirements of the NOC team ultimately decide the happiness of the customer. > I'm trying to understand if this is "just" resistance to change (yeah, I know > both too little and too much got changed with IPv6.) with the argument being > that "this is how we have done it for the last 20 years and we will continue > to do it this way whatever argument you make", or if there are real technical > and operational issues with link-local only (optionally with /128) p2p links. > > we as the IETF community need operator input and we need to understand > operational complexities. thanks for replying. Operators need IETF guidance as well. Especially in times like these. Thanks for asking :-) Regards, Seiichi > (and perhaps even Randy with his ever so charming ways also think so.) > > cheers, > Ole -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkxqc+UACgkQcrhTYfxyMkIQzACfXHnOmqzwwoGNEivNaFy5A+Qy lGQAnR0mZW5kkEtTCJgqk+3vXaDYs1R8 =fYod -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
