[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC 3484 update


El 07/11/2005, a las 22:28, Pierre Baume escribió:


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



ok


  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.



right, i see what you mean
With current policy table, what you could do is to allow that for certain destiantions, the source addresses for public service are tried first and for other destiantions the remote admin address is tried first. 

However, you cannot:
- do it per service/application using the policy table (since its granularity is per address/prefix and does not takes into account the service/application). In this case, i guess that the remote admin application will select the proper source address, forcing the source address selection mechanism - prevent that the remote admin address is used by the public service if the other two addresses are not working (i.e. the policy table allows you to provide an ordering but not to prevent some of the addresses to be tried)
I guess that this is probably not enough for supporting this case, however, it should be noted that the proposed policy table is just a minimum functionality that needs to be provided, and extended features can be supported 

rfc 3484 states that:

   IPv6 implementations SHOULD support configurable address selection
   via a mechanism at least as powerful as the policy tables defined
   here.
So improved mechanisms can be provided... I am not sure if you consider that the default mechanisms should be able to deal with the scenario that you describe?
I guess that in the case described, a possible approach would be to cosnider that are two virtual hosts, one which is the server, with the 2 public service addresses and other that is the admin, which has a single address, which is the remote admin address. In this case, there would be two address selection mechanisms running, one with the two public service addresses and the other with a single address, the remote admin address. 


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



Yes, i was ashamed for the number of errors :-(

Regards, marcelo



Pierre.