Zu Qiang <[email protected]> writes: > I have one comment which I have sent in the control plane draft > discussion. But it may have an impact on the architecture draft as > well. In section 7.1, there are two alternatives described. However > it shall be possible for an implementation to use NVE-NVE protocol > for inner-outer mapping updating. Using NVE-NVE protocol may not be > the best solution. But as an architecture document, it may be good > to list all the possibilities.
Agreed. That is why both are mentioned. > And it may be better to have some > analysis text on the pros and cons of each alternatives. That I would like to avoid. The architecture document should describe the direction the WG has chosen to go in. I don't think we should document the pros/cons of various approaches (that is more what the framework does). Also, in the specific case above, I'm not sure listing pros/cons of the two approaches helps. I don't expect folk to pick one or the other based on the pros/cons. One of the starting premises is that there are already existing orchestration systems that provide the functionality of the NVA, and existing deployments use them. I don't expect implementations already using such a facility to change. I do think we will need to coexist with such approaches, hence they need to be part of the architecture. Does that make sense? Thomas _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
