Re: [lisp] [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt

[[e-mail] (Noel Chiappa)]

    > From: Fabio Maino <[e-mail]>

    > We just started from .. the lack of multiprotocol support

I don't really have a 'dog in that hunt' (i.e. a preference, for those who
aren't familiar with that US idiom). I can see how it might be useful, but
it's not like I will die of apoplexy if we don't add it.


    > For lisp-gpe, unfortunately, it comes to the expenses of the nonce and
    > versioning fields, that is certainly a higher cost to pay

But I don't think that it _is_ an un-avoidable tradeoff.

As I alluded to in my prior post, I believe a slightly different change to the
encapsulation is feasible, one which retains almost all the existing
functionality, and adds multi-protocol support.

My suggestion (based on some discussions with people, to find out what the
real-world constraints on changes are), and thinking about the various
functions and fields of the header, is to multiplex the LSB along with the
nonce and version in the field on the right of the first header word, freeing
up the 8-bit LSB field in the second header word (this is assuming the
Instance field is present, which I think it will likely be) to use for a
protocol type - in every packet.

I won't go into the analysis of flag bits and settings, but having looked at
6830 carefully, I believe they can be made to work in an upwardly compatible
way.

My position is that we don't _have_ to have the LSB in _every_ packet, any
more than we _have_ to have the nonce or version in _every_ packet. Exactly
what the 'right' mix is of the various functions (e.g. 'check the mapping
version every 10th data packet', etc), is something we'd probably want to work
out from experience.

Yes, this solution is not optimal - e.g. we have to have a translation between
16-bit Ethertype and an 8-bit protocol type - but it's _much_ better, IMO,
than the existing proposal - where we have to chose _between_ multi-protocol
support, and those important control functions.


    > we should try to see if there's a way to achieve a larger set of goals
    > of what lisp-gpe does today.

To repeat something I said elsewhere, I think we're getting close to the limit
of how many pounds we can fit in the particular 5-pound sack of the
double-word header. (For those who aren't familiar with this expression,
Google '5 pound sack'.)

Given that there are hardware implications for a longer header (which I think
we're likely to need at some point), we might want to go ahead and specify a
longer header, _without using it for anything for the moment_. Once hardware
support has made it into the pipeline, we can start to use it.

But unless we specify it _before_ we need it, we will not be able to use it
when we _do_ need it!

Hence my suggestion that we specify it now, without using it for anything.

      Noel