Re: RFC 3484 update

[Pierre Baume <pierre@baume.org>]

Marcelo,

On 11/7/05, marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:
[...]

> >   Would it be a good idea to update section 8 (Implementation
> > Considerations) of RFC 3484 as well?
> >
>
> In general, I guess that retrying with different source addresses
> (whether it is performed by the application or by the transport) does
> indeed deserves some comments in the implementation considerations, but
> i didn't had in mind some specific issue to include there. Do you have
> anything particular in mind?

  Sorry for being vague, I was thinking that paragraphs 2, 3 and 4 of
section 3.1.3 of your draft could be used to update section 8 of RFC
3484. But this is just an editorial comment. :-)

> >   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.
>
> Do you mean a way to limit the number of source addresses that are
> retried?
> I asume that this will be up to the application in most of the cases...
> I mean in case that is the application the one making the retrial, the
> clearly is up to the app the number of retrials.
> In the case that is TCP the one retrying, i guess that the application
> will decide when to give up and try with another destiantion address.
> I mean, i am not sure whether the source address selection mechanisms
> should define the maximum number of retrials, since i guess it depends
> on the local policy, which i guess is aligned to your idea, of using
> the policy table for this, right?
[...]

> Regards, marcelo

  I was thinking about limiting the scope of the retries.

  For instance, if a host has 3 addresses, 2 used to run a public
service and 1 for remote administration.

  If you have trouble with a public service address, you don't want to
send any front-end traffic through your administrative interface, even
if it would work. This way, you give yourself a chance to connect to
the machine and troubleshoot. It can also be that the administrative
address is on a slower interface and practically useless for the
public service.

  Hopefully, this clarifies some of my other comments as well.

  I see that you already updated the draft. That's quick. :-)

Pierre.