Christian,
Christian Vogt a écrit :
Alberto -
As a member of the working group, not as its chair: You are right
that co-existence scenarios need to be handled. But I'm not sure that
coexistence requires /special/ behavior. As long as the behavior
desired for coexistence scenarios does not preclude the behavior
desired for non-coexistence scenarios, I think coexistence should be
covered by the /regular/ behavior of the various SAVI protocol
specifications. That is, in the particular case of SLAAC/SEND co-
existence, I think we should strive for a SAVI SEND protocol that can
handle non-SEND-capable SAVI devices.
As we are centralizing the co-existence decisions in a
"man-in-the-middle" savi-device, we can't just consider that the
capability of the savi-device (SeND, not SeND) are it's sole problem.
Which "looks" the case if the co-existence scenarios are described in
the savi-SeND protocol specification.
A savi device not SEND-capable breaks RFC3971. Like a bridge that would
mess with L3 messages. And it has no way to know. Can we **really**
specify that? There might be thousands of non-SeND capable nodes on the
link, and just one signle pair of SeND nodes, and this SAVI-switch in
the middle is completely messing with their "standard" behavior. Note
that there **are** such deployments out there. And the deployments
scenarios are exactly that (few SeND critical nodes, many non-SeND).
So I think the description of this scenario, and associated warnings
should show up either in all documents, or in a higher level doc(
framework, or other).
Eric
Does this make sense?
- Christian
On Oct 29, 2009, at 3:04, Alberto García wrote:
My opinion is that priorization is not enough.
I think we need to define "operation modes" (SEND-only, SLAAC-only,
SEND-SLAAC-compatible...) and describe the state machine for each one.
To support the idea of why we need a new state machine for SEND-SLAAC
compatibility, i.e. for a domain in which both SEND hosts and non-
SEND hosts
coexist, just consider what a node should do (extending naturally the
current FCFS and SEND proposals) if a SAVI device is in NO_BIND
state, and a
data packet (not DAD NSOL) is received, from a Validating port VP.
In this
case, the SEND SAVI device should send
- 2 (unsecured) NSOL messages through Trusted ports (according to
FCFS SAVI)
- and a secured NUD NSOL message through the Validating Port
(according to SEND SAVI
And The state is moved to TENTATIVE.
In the TENTATIVE state, the SAVI device should maybe wait long
enough (a
RetransTimer, which is the waiting time for NUD operation) for a
secured NUD
NADV even if an unsecured DAD NSOL is received from a trusted port
in the
meanwhile, to assure that SEND validated addresses have priority over
non-SEND addresses. [Note that this may occur if a SEND host has one
collision when performing DAD for an address, and it is not
withdrawing the
second address if an unsecured DAD NSOL is received for it, as RFC
3971
says].
Different states should be defined (VALID_SEND, VALID_NON_SEND), with
different behavior when the valid_timeout expires.
So I don't think this is just "ships in the night", but different
modes
should be defined to integrate all the possible combinations of
address
configuration mechanisms. Maybe one of these modes should be the
default
one, but the administrator could set the SAVI devices to the
appropriate
mode (well, they also have to define which ports are trusted or
not...).
Does this make sense?
Regards,
Alberto
_______________________________________________
savi mailing list
savi at ietf.org
https://www.ietf.org/mailman/listinfo/savi
|