On Mon, Aug 16, 2010 at 8:33 PM, Ole Troan <[email protected]> wrote:
>>>>>>> please ping my router, it's interface address is: 
>>>>>>> fe80::20e:cff:fe5c:b001/64
>>>>>>>
>>>>>>> my monitoring system can't ping this to ensure liveness of the
>>>>>>> interface either :(
>>>>>> but they can ping whatever global /128 you put on that interface, so why 
>>>>>> doesn't that solve the problems?
>>>>> Because you are then using one set of addresses for protool peerings
>>>>> and another one for global ping - thus making life more complicated
>>>>> for the operator.
>>>> is that any more "complicated" (I don't quite understand that argument) 
>>>> than using IS-IS?
>>>>
>>>
>>> Yes.
>>
>> yes. I tried something close to it 5 years ago and it was hell.
>
> how? Jared's "Yes" doesn't exactly help my understanding why this is 
> operationally complex.

I should have also asked you to contact your (cisco's) top 10 service
provider and enterprise operations folks, ask them if putting 2x the
interface addresses on interfaces, then attempting to monitor them is
something they are willing/able/trying to do. (really, ask what's
going to pay the bills, see if less complexity or more wins)

in today's world I have a router with 1.2.3.1/31 and another with
1.2.3.0/31 connected across a ptp link. I put these PTR's into my
local (potentially global, but that's a rathole) DNS and my monitoring
system tells me that 1.2.3.1 is alive and well. Sometime later it
tells me that 1.2.3.1 is 'down' (unpingable).

Tomorrow I'll also monitor 2001:db8:1::0/128 and 2001:db8:1::1/128
(which will also appear in DNS for me) on the same respective routers,
across the same respective ptp link. This I'd call, actually,
2001:db8:1::/127, some folks may chose (for religious reasons it turns
out) to call it 2 disconnected /128's. My routers will peer (bgp)
across this /127 (or 2 sets of /128's), they'll put into their IGP the
/127 for reachability info... things will work fine.

I don't have to worry or know about the fe80 addresses (I may not even
have them on the interfaces in question). Why would I add complexity
here? Why would I want to add more records keeping and more overhead?

I'd add that today, on all of the exchange points I see routers
connected to (quote a few) no one uses fe80 addresses for link
addressing, everyone uses globally unique addresses. For all
interprovider connections I see ONLY globally unique addresses used,
not a single person is attempting to interconnect over fe80/link-local
addresses. There is no guarantee of uniqueness with fe80/link-local
address:
o I can not monitor my network (or the interconnects with remote
networks) with link-local addresses
o I can not guarantee that 2 devices not on the same fabric won't
select the same address in link-local space
o I can not use these addresses in my routing protocols (because of
the above point)
o I will not add complexity and extraneous overhead to my operations
to use link-local addresses because of some silly religious reasons,
globally unique addresses work just fine. They even work just fine if
I use 'two disconnected /128's' that I'll happily call (and allocate)
as a /127.
o gymnastics in the address selection/routing world to avoid a problem
that flat shouldn't exist (ping/pong packets) is just silly attempts
to justify the same silly religion. Use a set of 'two disconnected
/128's' that are from the same /127 and be done with it. Seriously.


As an aside, and because it sort of mystifies me that you are asking
these questions Ole... is it because you honestly don't know or
because you are trying to run down the pathways of resistance to an
idea/plan? Have you operated a large network in the past? Have you not
sat with customers fighting to operate their networks in sane
fashions?

-Chris
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to