Re: [DNA] linkid

[Brett Pentland <brett.pentland@eng.monash.edu.au>]

Sorry for the slow response - I'm only in sporadic email contact this
week.

Thanks for taking a look at the draft.

Erik Nordmark wrote:

> From looking at draft-pentland-mobileip-linkid-02.txt
> I have a few comments and questions.
> 
> When two routers boot at the same time, them seem to send a request
> and then (at about the same time) they will give up and pick their own
> linkid and advertise it.
> Thus there is a risk that both of them will have different ids for a while.

They don't start advertising it in RAs immediately.  They start by
advertising it just to the other routers on the link and listening for
conflicts.
> 
> An alternate approach is that a router will first generate a random number
> (which will be used if no other router on the list has a number)
> and offer that in the RtR message. If there is an existing router which
> has already picked a linkID it will respond with its number.
> But if not, i.e., multiple routers boot at the same time, 
> the two routers might both receive a proposed random number from their peer.
> Having some comparison (such as smallest number) would allow the routers
> to pick the same number from the ones they proposed.
> This might require defining both a "proposed linkid" option and
> a "linkid" option for the RtR message.

I think this is pretty much what it does (section 5.2).  There is no
"proposed linkid" option, but internally the router keeps the generated
value in "ProspectiveLinkID" until after it has gone through a period of
advertising it just to other routers and listening for contradictory
responses (2nd last para of section 5.2).

> BTW: It might make sense to require the routers to keep the linkid in
> stable storage so that with high probability even after all the routers
> fail (due to power failure) and come back they will have the same linkid.
> 
Good point.  I'll add that.

> The draft talks about administrator change of the linkid, which I don't
> think is that useful.

It was put in to make it simple to initiate a change if that becomes
necessary for reasons not yet thought of (or ones that are). Perhaps it
is not needed.

> But it doesn't talk about the case of the partioned link where multiple
> (sets of) routers might pick different linkids and when the partition heals
> there is a need for all of them to converge to a single number.

I hadn't really thought about that.  Quite an oversight.  I guess the
change management procedures would work ok, but there needs to be a
mechanism defined to recognise this situation and initiate the change.
Two possibilities are to 1), have routers listen to LinkIDs from other
routers in multicast RAs and initiate LinkID change if necessary, or 2)
have the routers periodically multicast RtR messages to one another with
LinkID options, which would then be picked up by the existing change
management procedure (sec 5.3.2).  Any thoughts on which approach would
be more sensible?

If the link is split and then the administrator decides to keep it split
for some reason, then one of the new halves should change its LinkID.
Perhaps we could come up with some way to detect this and respond, but
maybe it's just simpler to let the administrator make this decision and
act to initiate the change.  A possible argument to keep
administrator-initiated LinkID change?

Brett.