Re: [v6ops] BGP Identifier

If nothing else, if the authors intend to apply this to more routing protocols than just BGP, they should change the proposal to reflect that they seek to change ROUTER-IDs in general and not just the BGP identifier.

However, I believe that the idea of converting a router-id from 32 bits to 128 bits is woefully misguided. I say this as an operator who has operated IPv4 and IPv6 and dual-stack networks.

It has always, IMHO, been unfortunate that OSPF Area numbers and Router-IDs for various protocols have been tied to IPv4 address syntax and, in the case of router-IDs, affiliated with interface (including loopback) IP addresses. This has created no end of confusion among less well trained operators.

IPv6 gives us the opportunity to correct this problem and have IDs which no longer match addresses. That is a "good thing™" IMHO.

As near as I can tell, this draft seeks to prevent that improvement from occurring.

Instead, I think that Sander and David are on a much better track and I would be willing to join in on the efforts to write such an operational draft.

Owen

On Feb 15, 2014, at 10:49 , Nick Hilliard <nick@foobar.org> wrote:

> On 15/02/2014 15:26, Sander Steffann wrote:
>> Op 15 feb. 2014, om 16:13 heeft Shane Amante <shane@castlepoint.net> het volgende geschreven:
>>> On Feb 15, 2014, at 12:55 AM, Randy Bush <randy@psg.com> wrote:
>>>> I use this funny thing called DNS. 
>>> 
>>> And that has what to do with the problem of determining liveness or determining where in the topology is a ROUTER_ID?
>> 
>> And what does an integer called ROUTER_ID tell you about that?
>> 
>> And hey, you can always create records like
>>  1.2.3.4.router-id.castlepoint.net IN CNAME router1.somewhere.castlepoint.net
> 
> guys, we're all having a bit of an ietf moment here: within the space of 48
> hours, the conversation has ratholed.  Let's love up a bit.
> 
> The authors of the draft have a simple operational desire to make their
> lives a little easier and as an operator I sympathise with this,
> particularly because they are using ipv6-only networks in anger which is
> more than I do.
> 
> There are two advantages of having a 128 bit router-id (with the unstated
> convention of tying router-id == address of first loopback):
> 
> - firstly it's easy to identify the location of prefix announcements on
> your network
> - secondly the router-id can be autoconfigured.
> 
> On the other hand, implementing this will require that the authors define a
> transition mechanism to allow 128 bit router-id routers interoperate with
> 32 bit router-id routers in such a way that router-id collisions don't occur.
> 
> If the authors want to progress this, they need to state a stronger use
> case and they need to create a transition mechanism.  If they can do this
> in a reasonable way which doesn't break backwards compatibility, then it
> might be appropriate for idr / v6ops / etc to take another look at the draft.
> 
> Also, I wish them well because everyone understands what a router ID is and
> everyone will want to paint theirs a different colour.
> 
> Nick
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops