On 3/4/14 11:18 PM, Anton Ivanov (antivano) wrote:
The "security key" portion needs to go to SFC for definition where it
belongs. The security meaning needs are real security use case and
security assessment. Otherwise it is RFC 3514 just expanded to an
arbitrarily large size of [do no] evil. Lots and Lots of "evil" bits
aligned on a 32 bit boundary. Nice...
Anton,
I'm trying to understand your argument.
As I understand in GUE the security parameter is there to provide
additional assurance for the VNID. The NVO3 VNID is part of the GUE
proposed NVO3 encapsulation and most (all?) of the other potential
encapsulation forms. It seems odd to have the VNID be part of an NVO3
header while the cookie/hash to provide better assurance of the content
of the VNID field be part of a service chaining header.
If you do that, shouldn't the VNID also be moved out from NVO3 to SFC?
Regards,
Erik
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
