Please see my reply inline [lucy].
-----Original Message-----
From: nvo3-boun...@ietf.org [mailto:nvo3-boun...@ietf.org] On Behalf Of Fabio
Maino
Sent: Wednesday, September 25, 2013 1:23 PM
To: Noel Chiappa
Cc: n...@ietf.org; lisp@ietf.org
Subject: Re: [nvo3] [lisp] 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.
[Lucy] disagree. This certainly makes LISP more complex and harder to
interwork. The lisp-gpe draft has many holes on the interworking.
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.
[Lucy] Although VXLAN encapsulation had intention to align with LISP at
beginning, if expanding it to support multiprotocol, it means the separation
between two because LISP does not have goal. In fact, VXLAN and LISP already
uses different UDP port number, it is sufficient to separate them. Lisp-gpe
proposal will result a bad LISP protocol. Hope that the WG give a cautious
consideration.
Lucy
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
_______________________________________________
nvo3 mailing list
n...@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
