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

Re: mech-v2-05pre


Pekka Savola wrote:

On Tue, 24 Aug 2004, Alex Conta wrote:

The tunnel protocol, like any other similar protocol, has two phases: a
protocol setup phase (a), which can also be called protocol control, and a protocol data change phase (b). 
[...]


- Point-to-point links are between two nodes
[...]
The concepts of network, links, interfaces, addresses, are part of the Internet Architecture, they are strongly inter-connected, and inter-dependent, and you cannot simply change the definition, or the use of one the concepts, without defining a new architecture: Good luck if that's what you intend!
[...] 
If we wanted to be 100% accurate, I guess one could reword:

All tunnels are assumed to be bidirectional, behaving as
virtual point-to-point links between the IPv4 tunnel endpoint
addresses.

to something like:

All tunnels are assumed to be bidirectional, behaving as virtual
point-to-point links between nodes, using the specified IPv4 addresses as tunnel endpoints.



This is a lot better than before.

I suggest two small changes: remove 'the', and replace 'as' with 'of the' as in the following text:

   All tunnels are assumed to be bidirectional, behaving as virtual
   point-to-point links between nodes, using IPv4 addresses of the
   tunnel endpoints.


Comment 3
----------
Page 15, Section 3.5

               An IPv4 address of the encapsulator: either manually
               configured or an address of the outgoing interface

problem: language

Suggestion:
replace with:
[...] 

I see your point, you are right. Switching places would do it:

        An IPv4 address of the encapsulator: automatically
        selected from the addresses of the outgoing interface
        or manually configured.



Compared to the current text, this has switched the order, removed
"either" (which seems like a no-op), and included "automatically
selected from the [addresses]", which is IMHO worse.  That's because
automatic selection should really not be used when there are multiple
addresses (because the results will likely not be deterministic, and
the decapsulator must have the correct configuration) -- you cannot
rely on automatic configuration getting it right!   So, I'd like to
avoid giving the expectation that automatic selection would work w/
multiple addresses.., hence I'd prefer to leave it as-is.


I suggested "automatically selected", to balance, and for symmetry to
"manually configured". Even if you remove "automatic selection", if it is not "manually configured", then it is still automatically selected, so you say "manually" for "configuring", but you say nothing for "automatic selection".

If you dislike "automatically selected", then just remove "manually", to
balance the text, but to me, the text that says both is better balanced.

Furthermore, regarding the technical aspects, which you elaborated above, I would like to walk through, to make some clarifications:

The "automatic selection of source address" relies on *route* selection:
this is always deterministic. The selected route to destination yields the outgoing interface, which is also deterministic.

Based on that, and furthermore, the "automatic selection" from *multiple addresses of a node* is *deterministic* if:
a. - there is one address per interface
else
b. - the prefix of one of the multiple addresses per interface matches the destination.
else
c. - the "automatic selection" is non-deterministic.

So, while I understand your point, I think it applies, only for (c.) and not the others, as you implied in your text above, and how the spec implies:

As the current text says "an address", it can also be any of the multiple addresses of an interface. Furthermore, as I pointed out before, the last paragraph in Section 3.5, is exposing itself once more as being weak.

So this need better clarification in the text.

Maybe changing the second phrase from:
   This may be a problem
   with multi-addressed, and in particular, multi-interface nodes,
   especially when the routing is changed from a stable condition, as
   the source address selection may be adversely affected.

to:
   Configuring the source address is to be considered particularly in
   cases in which the automatic selection of source address is not
   deterministic.

or,

   Configuring the source address is appropriate particularly in cases
   in which automatic selection of source address is not deterministic.

Note that an implementation has multiple choices:
1. can always give a WARNING to the operator, if the "automatic selection" is not deterministic, or
2. return with a question to the operator, which of the addresses in a possible list to choose.
3. return the selected address to the operator, to be used for further configuration at the other end node.

These could be documented in an Appendix, if you intended to have an Implementation Notes section.

[...]


This has been narrowed down considerably. I am really happy with the progress! If we could work out these last 2 issues, it would be great.

Regards,
Alex

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature