Re: RFC 3484 update

[Pierre Baume <pierre@baume.org>]

Hi Marcelo,

  Good stuff.

  Would it be a good idea to update section 8 (Implementation
Considerations) of RFC 3484 as well?

  Here are some specific comments.

> 3.1.2.  Retrying with different source addresses
[...]

>    Rule 0: Avoid unreachable source addresses.
>
>    If the address pair with source address SA and destination address D
>    is known to be not working, then prefer SB

  I think that we need a way to control this iteration. As a default, I
suggest that we use the policy table and limit it to addresses with the same
label. That's provided that I understand what labels are for. ;-)

> 3.1.3.  Providing an ordered list of source address
>
>    In addition to recommending that when the application selects the
>    source address, it should try with all available address pairs to
>    establish the communication, it would also make sense to provide some
>    guidance about which addresses to try first.
[...]

  Same remark as above.

>    However, such approach has the drawback that the resulting order of
>    address pairs to try may not be the optimal, since for each
>    destination address, all the available source address would be tried
>    before moving on to the next destination address.
[...]

  Restricting the iteration through possible source addresses will also help
reduce the number of address pairs that are tried.

  Typos and nitpicks follow. :-)

> 2.1.  Reference topology
[...]

>    Host X has to global IPv6

  s/to/two/

>    addresses, which we will note "A:X" and "B:X", formed by combined the

  s/combined/combining/

>    prefixes allocated by ISP A and B to "site X" with the host
>    identifier of X. Y has only one address "C:Y".
[...]

> 2.1.1.  RFC 3484 and the shim6 protocol
[...]

>    Essentially , the
>    proposed mechanisms are aimed to allow a node in a multihomed site
>    that implement them to be able to establish a new communication after

  s/implement/implements/

>    an outage with an external host that does not have any multihoming
>    specific support mechanism.
[...]

>    It is also possible to use the mechanisms described in this note to
>    establish communications between two shim enable peers.
[...]

  s/enable/enabled/

> 2.2.  The problem: address selection after failures
[...]

>    o  If X tries to communicate with Y using A:X as a source address,
>       packets will be routed through ISPA in order to comply with
>       ingress filters, and because ISPA has no link available wit the

  s/wit/with/

>       rest of the Internet, the packet will be discarded (it should be
>       noted that even if the packet could make it to Y, reply packets
>       from Y to X would contain A:X as a destination address, which is
>       unreachable from Y).
[...]

> 3.  Updates to RFC 3484
[...]

>    o  In case that the application does not selects a source address,

  s/selects/select/

>       the source address selection mechanism described how the IP layer

  s/described/describes/

>       selects the source address for a given destination address.
[...]

>    o  When the source address is specified by the application, the
>       source address selection mechanism does not provides any guidance

  s/provides/provide/

>       to the application about how to select the source address for
>       communicating with a destination address.  In particular, RFC 3484
>       does not recommends that the application should iterate through

  s/recommends/recommend/

>       all available source address until a working address pair is

  s/address/addresses/

>       found.
[...]

> 3.1.1.  Considered scenario
[...]

>    The stack and the source address selection mechanisms should honnour

  s/honnour/honour/

>    this choice.
[...]

> 3.1.3.  Providing an ordered list of source address
[...]

>    A possibility would be to let the source address
>    selection mechanism to order that list before it is returned to the

  s/to order/order/

>    application.
[...]

> 3.2.3.  UDP sockets
>
>    In this case, it is not possible to use a similar approach to the one
>    described for TCP, because there is no way to determine if a given
>    source address is working or not, because there are no connection

  s/are/is/

>    establishment packet exchange as in the case of TCP.
[...]

>    A detailed description of how this would is

  s/would/would work/

>    included in [3].  In any case, the goal here is to keep track of
>    source address tried for each destination address and whether these

  s/source addresses/the source addresses/

>    have worked or not (according to the previous definition of
>    "working").
[...]

  That's it. :-)

Pierre.