Re: RFC 3484 update

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

Hi Pierre,

thanks for the comments and the detailed review...
see inline for my  reply

El 06/11/2005, a las 16:10, Pierre Baume escribió:

> Hi Marcelo,
>
>   Good stuff.
>
>   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?

>   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?

> As a default, I
> suggest that we use the policy table and limit it to addresses with 
> the same
> label.

I am not sure this would result in the expected behaviour...
As i understand it, labels are used to determine which source address 
to prefer for a given destiantion address.
In order for this to work, you need to include the destiantion address 
(or a prefix containing it) in the policy table and assign a lable to 
it.
I am not sure how to use this in order to limit the number of 
retrials....
perhaps you could expand on what usage did you have in mind for doing 
this...

>  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.

Well, the order of the list will be certainly influenced by the policy 
table and the labels assigned to the source addresses, but this would 
not result in limiting the number of addresses included in the list 
(unless we do some modification to the current behaviour of the policy 
table)
Again, do you have in mind some specific change here?

> >    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.

Right, i certainly agree that may make sense to reduce the amount of 
source addresses but i am not sure if the policy table is the right 
tool for doing it


>   Typos and nitpicks follow. :-)

Thanks, i will correct those asap.
(i am sorry for all the mistakes but i was in kind of a rush...)

Regards, marcelo