Subject: Re: [nvo3] FW: New Version Notification for draft-yong-nvo3-frwk-dpreq-addition-00.txt

From: Lizhong Jin <[email-masked]>
Date: Mon, 17 Dec 2012 21:40:34 +0800

>
>
> The new service type is to allow ingress NVE performs some routing. It is
> the L2/3 gateway for the TSes. But from TS perspective, it attaches a LAN
> or VLAN, not router.
>
[Lizhong] Lucy, I don't think it is appropriate to name this as a new
service type. The packets are still being processed by L2/3, no new
processing happened on the packet. The only difference is the gateway
location, on the local NVE or remote NVE. So I consider this as an
implementation specific thing.

Regards
Lizhong

> Regards,
> Lucy
>
> > -----Original Message-----
> > From: Thomas Narten [mailto:[email-masked]]
> > Sent: Friday, December 14, 2012 1:58 PM
> > To: Lucy yong
> > Cc: [email-masked]
> > Subject: Re: [nvo3] FW: New Version Notification for draft-yong-nvo3-
> > frwk-dpreq-addition-00.txt
> >
> > Lucy,
> >
> > > Tom,
> >
> > > >
> > > > > [Lucy] No, this is not what I mean. I mean we need a new service
> > > > > type to be able to support a single NVo3 virtual network that
> > > > > contains both cases via a L2 interface.
> > > >
> > > > By "both cases", do you mean both L2 service and L3 service?
> > > >
> > > > That is, do you mean a single Virtual Network, where TSs are
> > > > sending/receiving L2 frames, but in some cases the NVE treats them
> > as
> > > > IP (forwarding them based on their TS IP header) while in other
> > cases
> > > > they are treated as L2 (where the NVE forwards them based on the TS
> > L2
> > > > header and doesn't look at the IP header (if there is one)?)
> >
> > > [Lucy] Yes, this is what I mean. But I don't want to use two
> > >  services to construct a tenant virtual network in some case. Can I
> > >  just use one service to achieve it?
> >
> > I'm not at all sure it makes sense to mix and match L2 and IP service
> > on the same Virtual Network. Seems to me, that if you have some
> > traffic that needs to be forwarded at L2, just forward it all using
> > the VM's L2 addresses. This works. Doesn't matter if payload is IP or
> > not. Keep it simple.
> >
> > If you forward *some* traffic using L2 information, but other TSs
> > expect only L3, what is supposed to happen? This isn't going to work
> > right. Why would you even allow such a model?
> >
> > But before looking at the problems with such an approach, what I'd
> > really like to understand is what the use case is for such a mixed
> > model on a single VN. Not just "why not", but what is the real use
> > case. If there isn't one, I'd prefer that it just not be supported as
> > doing so will surely add complexity ... and if there is no real need
> > or benefit, then why?
> >
> > > > And can one TS send *both* types, or does a TS have to pick one
> > format
> > > > (always) with different TSs on the same VN possibly choosing
> > different
> > > > services?
> >
> > > [Lucy] Yes, one TS can send a frame to a TS that is on the same
> > >  subnet, it can also send a frame to a TS that is on the different
> > >  subnet.
> >
> > You didn't answer the question I'm trying to ask. The question I'm
> > asking is how does the NVE know (when it gets a packet) whether to
> > forward it using the L2 information or the L3. It has to pick one (for
> > each arriving packet). How does it know? Is the NVE supposed to know,
> > for example, what subnets look like from a VM's perspective (I would
> > argue that is not a good designe and has a bunch of issues).
> >
> > And per above, if you just always forward on L2 info, you can make the
> > intra- and inter-subnet case work. So why not just do that?
> >
> > > > If so, the WG has discussed this case before - and there are issues.
> > > > One issue is how does an NVE know whether to forward a packet
> > received
> > > > from the TS using the packets L2 header vs. its IP header? For an
> > IP
> > > > packet, it will have both headers, and depending on which choice is
> > > > made, you might get different forwarding behavior. That would
> > probably
> > > > not be good.
> >
> > > [Lucy] You get it. But a frame from TS have both Ethernet and IP
> > > header. From TS perspective, the frame to the TS on the same subnet
> > > will be bridged, the frame to the TS on the different subnet goes to
> > > the router. We need to a service to guarantee that.
> >
> > I am assuming that NVO3 networks providing IP service to tenants will
> > have to embed at least limited routing capability. Enough to handle
> > the "inter-subnet" case. But I can also imagine this being done on the
> > ingress NVE, in which case, there is no penalty or "extra hop". I.e.,
> > the ingress NVE recognizes that a packet is being sent to a router,
> > and just forwards the packet directly to where its supposed to go.
> >
> > That is, although architecturally a Virtual Network MAY need to have
> > an internal router to handle inter-subnet forwarding with an VN, this
> > can be implemented at the ingress NVE and doesn't need to add much, if
> > any overhead.
> >
> > Is there a reason why that wouldn't be good enough?
> >
> > > > > [Lucy] L2 service assumes a L2 interface and L3 service assume a
> > L3
> > > > > interface. VM has L2 interface only.  This is about to address VM
> > > > > communication in a single nvo3 virtual network. assumption is to
> > not
> > > > > change VM network function.
> > > >
> > > > Regarding the first statement, I don't see it this way at all. I
> > > > assume that even for L3 service, where all tenant traffic is
> > assumed
> > > > to be IP, the interface between the TS and the NVE will still be L2
> > > > Ethernet. However, the only allowed packets would be IP and ARP
> > (and
> > > > maybe DHCP and small number of other IP-related protocols sent at
> > > > L2). Any others would simply be discarded.
> >
> > > [Lucy] you need to configure an IP interface first for the service.
> >
> > Who is configuring what interface on what device?
> >
> > If you are referring to the VM and one of its interfaces, what VMs do
> > on their interfaces is outside of the scope of NVO3 -- I don't think
> > it matters to us. Right?
> >
> > > > To be honest, I'm not sure I understand what it means to have an
> > "L3
> > > > interface" between the TS and NVE in the case where the TS is
> > getting
> > > > L3 service only. Does that mean the TS is sending packets that DO
> > NOT
> > > > have an L2 header in front of them? I.e., between the TS and NVE?
> > > > Because that would presumably require changes to VMs, it would seem
> > to
> > > > be a non-starter. And what would be the point?
> >
> > > [Lucy] This is not what I mean. I mean for L3 service, you need to
> > > configure IP interface. All the frames from/to VM are Ethernet
> > > frames.
> >
> > Again, which IP interface? On what device?
> >
> > Thomas
>
>
>
>