Forked from thread "A few comments on draft-vogt-savi-framework". On Oct 30, 2009, marcelo bagnulo braun wrote: >> 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. >> >> Does this make sense? >> > > yes, but the question is what do we do with the slaac send in the > presence of send capable hosts. For the record: s/slaac send/slaac savi/ Absolutely. In my opinion, the optimal solution would include separate SAVI SLAAC and SAVI SEND protocols, both designed for co-existence, but with minimal functionality specific to the respective other protocol. In particular, the SAVI SLAAC protocol should avoid complex SEND-specific functionality. An optimal solution would also allow non-SEND hosts to attach to SAVI SEND switches, and SEND hosts to attach to SAVI SLAAC switches. Such "interworking" may lead to sub-optimal protectiveness of SAVI, as Alberto notes, but it should not interfere with the hosts. Assuming we succeed in engineering this optimal solution, we would minimize the cost of SAVI SLAAC switches, while still enabling the incremental deployment of SAVI SEND switches in a network with SAVI SLAAC switches. Also, the use of SAVI SLAAC switches would not hinder the deployment of SEND, as SAVI SLAAC switches would simply provide less protectiveness compared to what was possible with SAVI SEND switches. Is this a reasonable goal? Any concerns, changes, or additions? - Christian
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.