Re: [DNA] Re: RS/RA Exchange

[Greg Daley <greg.daley@eng.monash.edu.au>]

Hi Erik,

Erik Nordmark wrote:
>>So, I can dust off some "historic" code for this.  DVMRP has a HELLO
>>message like many other routing protocols.  But, DVMRP uses them to
>>announce reachability and discovery.  That is, peer routers on a link
>>look in the other routers' HELLO messages for their own addresses.
>>This allows them to determine when they have been "discovered" by
>>their peers.
>>
>>Could we mimic this and have some type of announcement message that
>>a router would send out with all the other routers' addresses that
>>it has heard from?
> 
> 
> I don't think for this case (RA collision avoidance) we need the
> confirmation of bidirectional reachability between the routers;
> allowing each router to have an ordered list where the lists on
> the different routers are loosly and approximately consistent should
> be sufficient. Doesn't mean it would hurt to know that the routers
> have a consistent view though.
> 
> One way to build this is to just interpret what is currently in the RA
> messages.
> Should this be insufficient and some new information needs to be
> exchanged between the routers than it makes sense reusing something
> which has already been built.
> I don't know if there are related things that the routers might want
> to advertise and coordinate with eachother.

I'd guess that actually exchanging the ordered list of
router information is probably excessive traffic, if the
agreement on ordering can be provided.

If there was a hash over an ordered set of identifiers, which
people could advertise, then all routers with the same hash
agree on the number of routers and the set's composition.
This could be used to determine who is first for RA scheduling.

Changes in set composition may have to be arbitrated by one
of the routers (the master? first/last element in current set?)
I'm not sure about this, but otherwise we can have synchronization
issues for the set agreement.

Of course these systems have byzantine failure modes.
Some of the trust can be provided using SEND router authorization,
but this could lead to contention or disagreement with non-SEND
routers.

Working out a fallback mechanism for devices which don't
agree with other routers could be useful.  If we could work this
out so that those nodes go to 2461 operation this may work
neatly.

Greg