locator pair selection (was Re: continued review of /draft-ietf-shim6-failure-detection-03.txt

marcelo bagnulo braun <marcelo@it.uc3m.es> Fri, 28 April 2006 12:47 UTC

Envelope-to: shim6-data@psg.com
Delivery-date: Fri, 28 Apr 2006 12:47:22 +0000
Mime-Version: 1.0 (Apple Message framework v623)
Content-Type: text/plain; charset="ISO-8859-1"; delsp="yes"; format="flowed"
Message-Id: <a6843b561be09464c1f3eaf278e16dcd@it.uc3m.es>
Content-Transfer-Encoding: quoted-printable
Cc: shim6@psg.com
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
Subject: locator pair selection (was Re: continued review of /draft-ietf-shim6-failure-detection-03.txt
Date: Fri, 28 Apr 2006 15:47:15 +0300
To: john.loughney@nokia.com

Hi John,

One comment w.r.t. one of the points you make below...

El 28/04/2006, a las 15:17, <john.loughney@nokia.com> escribió:

>
> Section 5.3:
>
>    Nodes MUST first consult RFC 3484 [6] Section 4 rules to determine
>    what combinations of addresses are allowed from a local point of
>    view, as this reduces the search space.
>
> RFC 3484 is "default address selection"; I would hesitate to make this
> a MUST.  I would say that 3484 is the default mechanism for REAP, but
> surely nodes can have an optimized algorithm?
>

I agree with respect to this point.
probably when selecting the locators pairs to be explored, we need to:
- consider the issues included in RFC3484 but probably with a different  
priority
- consider other information, like reachability, preferenes and so on,  
available from the shim6 protocol

I have wrote a mechanism for locator pair selection that takes into  
account this additional issues.

I haven't submitted it yet, but you can find it in:

http://www.it.uc3m.es/marcelo/draft-bagnulo-shim6-locator-pair- 
selection-00.txt

perhaps this could be a useful tool...

regards, marcelo

locator pair selection (was Re: continued review … marcelo bagnulo braun