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

Hi Noel,
there's certainly no intention of keeping this out of the LISP WG, since 
this is not part of the charter we just thought an individual submission 
was more appropriate.

We just started from the very practical consideration of the 
proliferation of encapsulations in the data center, and the lack of 
multiprotocol support in both VXLAN and LISP.

 From a vendor perspective having a more rationale encapsulation with 
multiprotocol support seems a good goal, as it simplifies the 
implementations and improves interoperability.

Since for both VXLAN and LISP there are already HW implementations the 
hard part is to provide some form of backward compatibility, that would 
allow a deployment of HW supporting the multiprotocol format to 
interoperate with legacy devices. The *-gpe drafts, are a proposal to do 
just that.

For lisp-gpe, unfortunately, it comes to the expenses of the nonce and 
versioning fields, that is certainly a higher cost to pay, compared with 
the extension of vxlan. In the judgement of the authors of the drafts 
this might be an acceptable compromise. That said I certainly respect 
your dissenting opinion.

To move forward I suggest we discuss the requirements and the different 
points of view, and we should try to see if there's a way to achieve a 
larger  set of goals of what lisp-gpe does today.

We have a great chance to talk in person next week at the LISP interim 
in Herndon, where I'm sure we can do a good use of aisle time.

Looking forward to meet you next week,
Fabio

On 9/24/13 8:07 AM, Noel Chiappa wrote:
> {This is mostly to the LISP WG; NVO3 - which I candidly admit to knowing
> almost nothing about, but which I justt joined - may or may not care. Sorry
> this goes on for a bit, but this is important. I hope people will take the
> time to read it - it's not _that_ long.}
>
>
>      > From: Dino Farinacci <farinacci at gmail.com>
>
>      > the P-bit is being proposed for LISP.
>
> For those who missed what this was all about (I sure did), there is a new ID:
>
>    http://tools.ietf.org/html/draft-lewis-lisp-gpe-00
>    "LISP Generic Protocol Extension"
>
> As a personal ID, this ID was not automagically announced to the LISP WG; I
> only happened to just see it when I was updating the LISP bibliography this
> weekend.
>
> May I suggest that in the future, anyone posting a personal draft _send a
> message to the WG_ - for people who are not subscibed to the full ID
> announcement feed (I'm not, it's way too much traffic, 97% of which I don't
> care about); otherwise, many people will have no idea that it's there.
>
> Even better, run the basic idea through the WG _before_ you write the draft;
> it may have a major flaw (as this one, I believe, does), or it may be a
> direction we just don't want to go (in which case there's no use putting in
> the effort to write an ID).
>
>
> To briefly let people know what this is about, it allows carriage of non-IP
> packets in LISP. This, I think, is basically a very good idea.
>
> However, the particular proposal in this ID is, IMO, very badly flawed. It
> proposes to take over the field used to carry i) the nonce (for neighbour xTR
> reachability detection), and ii) the version of the mapping entry, and use
> that field to carry the Ethertype.
>
> Obviously, then, since one _cannot_ carry a non-IP packet without making it
> _impossible_ to perform either of these functions: if only non-IP traffic is
> being carried over a particular link, these two (important, IMO) control
> functions will be _permanently_ disabled.
>
> I don't believe this is acceptable.
>
>
>      >> From: Lucy yong <lucy.yong at huawei.com>
>
>      >> Regarding to the protocol evolution, does this mean that
>      >> nonce/map-version features in LISP will be deprecated?
>      >> IMO: Having the same field overloaded for many differen[t] purposes
>      >> is not good way for the protocol evolution, it becomes messy.
>
> Yes and no. The engineering analysis on this sort of thing is subtle.
>
> With a limited length header, if you have several control functions that do
> not need to be applied _on every packet_, I think it's reasonable to share a
> field between them. One does have to carefully look at the functions to
> decide if they really are things that one doesn't have to do on every packet.
>
> The thing is that putting a separate field in for every possible function
> will make the header a lot longer, which will have an impact on overhead
> (somewhat problematic), and also MTU (even more problematic, especially if
> MTU Discovery is not working properly).
>
> I am given to understand that a number of organizations have hardware which
> looks at the first two 32-bit words, so unfortunately making the header longer
> is not available as a _short-term_ answer.
>
> (Although I think we're just about reaching the limits of what we can cram
> into a 2-word header, so it's probably time to start thinking about a longer
> one.)
>
>
>      > It means that the features need to be traded off. So the
>      > market/user-base will decide what it wants to use that field for.
>
> I have to tell you that I just about fell off my chair when I realized
> what you were saying here.
>
> I don't believe that is professionally acceptable to force users to chose
> between i) carrying non-IP traffic, and ii) having some important control
> functions available.
>
> I understand that in the real world there are constraints, so we can't
> necessarily 'clean sheet of paper' the answer; but at the same time, surely it
> is not beyond our wit to find an answer that doesn't force users into making
> that choice.
>
>
> I have some ideas on what to do here (technically), but before I launch into
> them I would like to hear if the WG agrees with me that this 'tradeoff' is
> unacceptable.
>
> Because, clearly, if the WG is happy with this, there's no point in my
> bringing up alternatives.
>
> 	Noel
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp