Re: [v6ops] [Idr] BGP Identifier

[David Farmer <[e-mail]>]

> On Feb 14, 2014, at 21:58, Shane Amante <[e-mail]> wrote:
> 
> I would take exception to a ROUTER_ID being just a 32-bit integer.  Specifically, when a ROUTER_ID is an IP address that allows an operator to quickly perform diagnosis & troubleshooting using ping/traceroute/etc. to identify the availability and location within the topology of the router purporting to have said ROUTER_ID.
> 
> The other question I would raise is, in a far-off future, if we ever manage to get networks converted away from dual-stack and back to a single AFI -- namely, IPv6 -- if ROUTER_ID's are only 32-bits and you lose those capabilities mentioned above ... would you care?

I agree it is a very common and useful operational practice to use the IPv4 loopback address for the ROUTER_ID.  This practice is strongly reinforced in that most implementations represent the ROUTER_ID in dotted quad decimal notation, the same way we represent IPv4 addresses.

However, common practice does not make it a protocol requirement.  I would suggest there are several possible new operational practices that could be developed that don't require complicate changes to the protocol.  

A very simple one would be to use a common IPv6 prefix for all your /128 IPv6 loopback addresses and embed the ROUTER_ID as the least significant 32 bits.  Just as implementations reinforce the current operational practice, they could also reinforce this possible new practice by representing the 32bit ROUTER_ID in hex instead of dotted quad decimal, or even better both representations next to each other.  Maybe implementations could allow you to specify a /96 IPv6 prefix to be appended with the ROUTER_ID when it is output, giving you the IPv6 address you wanted without changing the protocol.

As an example: let's say your ROUTER_ID is 192.0.2.5 or 0xC0000205.  Then you can use an IPv6 loopback address of 2001:db8:1::c000:205, or you could even used mixed notation 2001:db8:1::192.0.2.5.

So, you do not loose the ability to "quickly perform diagnosis & troubleshooting using ping/traceroute/etc. to identify the availability and location within the topology."

There was also a DNS recommendation made in the thread, that would work too.

So, I'd prefer effort be put toward an informational draft suggesting operational practices and maybe implementation suggestions that reinforce these suggestions rather than complicated protocol changes.  

Thanks.

-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota    
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================