Re: [nvo3] Updated Charter

[Yakov Rekhter <[e-mail]>]

Peter,

> 
> > > c)  Active/Active.  
> .....
> > 
> > I'm interested what others think about the need to add these to the
> > NVO3 requirements.
> 
> Something is required in the routers that terminate the tunnels to
> support active/active. At the very least the charter should recommend
> something that exis ts like VRRP and show how it maps. I suppose
> its also possible for the router to have some NVO3 tunnels terminating
> into a subnet handled by some VRF but also some other non NVO3
> mechanisms terminating into the same subnet/VRF, in which case any
> VRRP like mechanism would have to operate between the two different
> te chnologies.
> 
> Tromboning caused by picking the wrong gateway from outside the DC
> is LISPs realm and I suppose it begs the question of why not adopt
> a LISP style encap inside the DC too. Kill 2 birds with one stone.

You may look at draft-raggarwa-data-center-mobility-02.txt
for a description of mechanism that allow to eliminate
"tromboning". 

> So active/active I think should be in the charter.  External
> tromboning if included would be a pull towards LISP and would be
> nice to have just one encap for both purposes.

Yakov.

> 
> Peter Ashwood-Smith
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Balus
, Florin Stelian (Florin)
> Sent: Thursday, April 05, 2012 1:05 PM
> To: Thomas Narten; Shane Amante
> Cc: Bocci, Matthew (Matthew); [e-mail]; Benson Schliesser
> Subject: Re: [nvo3] Updated Charter
> 
> Thomas,
> 
> You asked below what others think about Shane use cases/requirements. 
> 
> I think what he described in his email are DC networking issues we need at le
ast to discuss in NVO3 data plane/control plane requirements and gap analysis. 
In particular the requirements to address traffic tromboning to/from NVO3 and r
esiliency at NVO3 gateways came up a number of times in the past in various IET
F WG sessions. We can see after that where/how exactly is the best place/way to
 address them. But we should not just ignore them.
> 
> My 2 cents...
> 
> Florin
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of
> > Thomas Narten
> > Sent: Thursday, April 05, 2012 9:12 AM
> > To: Shane Amante
> > Cc: Bocci, Matthew (Matthew); [e-mail]; Benson Schliesser
> > Subject: Re: [nvo3] Updated Charter
> > 
> > Shane,
> > 
> > > FWIW, the reason I bring up this issue is that I have encountered
> > this
> > > exact situation when I contributed to a redesign of DataCenters
> > > recently.  See below.
> > 
> > I'm not saying it can't or won't happen. I'm saying this is a
> > relatively hard problem to solve, and just wishing we had a solution
> > shouldn't be enough to make it a charter item for NVO3.
> > 
> > Furthermore, this is arguably a general IP issue and not specific to
> > NVO3. That raises fundamental questions about whether NVO3 is the right
> > place to attempt a solution. Presumably we'd want general solutions
> > that apply also in non-NVO3 scenarios.
> > 
> > > > The problem with that is that we just don't know how to do it
> > > > effectively at the IP level and we have not to date come up with a
> > > > general purpose way of doing that.  At least as far as I know.
> > 
> > > I find the above somewhat ironic given that this is the IETF, where
> > > we've defined both ARP and IPv6 Router + Neighbor Discovery ...
> > 
> > There are plenty of examples of problems where we wish we had a
> > solution, but there isn't necessarily one... No matter how much we'd
> > like one...
> > 
> > > > Or do you have some approaches in mind?
> > 
> > > As I look at:
> > > http://tools.ietf.org/html/draft-kreeger-nvo3-overlay-cp-00
> > > It seems fairly clear that NVO3 is, eventually, headed in a map &
> > > encaps direction, (cf: Section 3.1, "Inner to Outer Address
> > Mapping").
> > 
> > Absolutely. This is a given. That is what the data plane does.
> > 
> > > If this is true, then it would seem wise to think about requirements
> > > for additional attributes that can/should be included in the
> > requisite
> > > NVO3 mapping protocol(s).  For example, it's conceivable that a
> > > Hypervisor, implementing NVO3, could dynamically learn or be
> > > statically programmed with an idea as to its physical and/or logical
> > > location, (e.g.: NYC1 DC).  In addition, the "exit points" from the
> > > NVO3 overlay (would these exist on routers or switches or would it be
> > > another VM/server acting as a "router"?) could also dynamically learn
> > > and/or be programmed with similar information, since they need to (at
> > > a bare minimum) implement a encaps/de-encaps function to get traffic
> > > in/out of the overlay, right?  Then, when "mapping" is performed
> > in/by
> > > the NVO3 control plane for Inner <-> Outer Address Mapping the answer
> > > handed back as a result of that function /could/ be influenced by
> > > additional criteria so that you get back something like: "here is the
> > > topologically closest exit point from the NVO3 overlay".
> > > Ultimately, the NVO3 "FIB" gets programmed with that information and,
> > > perhaps, propagated further into the VM's ARP and/or ND tables ...
> > 
> > For the special case of a router, I can imagine optimizations. But what
> > about just using VRRP? There can be multiple instances of VRRP, and it
> > is (arguably) VRRP's job to figure out how to the optimal path
> > selection.  I'm not familiar with VRRP's details with regards to load
> > balancing, but it does allow for load balancing. That might be a better
> > place to handle the router exit selection problem...
> > 
> > > > In other words, this isn't an NVO3 problem per se, this is an
> > > > inherent limitation in the IP subnet model.
> > 
> > > True.  However, NVO3 appears headed down a road of needing and,
> > > eventually, defining (or, re-using?) a "mapping" function.  If that
> > is
> > > the case, then there's room for 'enhancement' above and beyond
> > > standard ARP & ICMPv6 RD/ND ...
> > 
> > The problem I see with this approach is that the mapping is based on IP
> > addresses. Given a target IP address, the mapping system presumably has
> > no information about the kind of service residing at that address and
> > whether or not there are multiple instances of such a service.
> > 
> > I gather you are suggesting that the mapping system should be augmented
> > with such information, so that the mapping function can be smarter
> > about what it returns.
> > 
> > This would certainly add to the complexities the mapping system has to
> > deal with.
> > 
> > Are you willing to scope the problem to the one case of wanting to
> > optimize the selection of exit routers? Or do you see additional places
> > where such optimizations would be desireable?
> > 
> > > I can use a variety of techniques in IP routing to influence the
> > > return traffic to go "the right way" back into the DC, e.g.:
> > > announcing longer prefixes into IGP/BGP to ensure that 'return
> > > traffic' is optimally routed back.  The key problem is, without
> > > running a dynamic routing protocol or using static routes on the
> > > server/VM, I have no way of influencing traffic that is transmitted
> > > *from* the server/VM to a optimal exit point.
> > 
> > Understood.
> > 
> > > >> So, IMO, it would be helpful to understand here on the list, and
> > in
> > > >> the charter, if NVO3 'solutions' care about optimizing traffic
> > > >> flows that are transmitted by one VM and are required to traverse
> > > >> an IP subnet boundary, for a variety of reasons, e.g.:
> > > >
> > > >> - traffic is required to pass through a "policy enforcement
> > point",
> > > >> such as a firewall/NAT/middle-box because:
> > > >
> > > > This will be something that has to be done, but it may be done
> > > > completely outside of NVO3. E.g., you can have a single default
> > > > router for the overlay instance, and all traffic would go through
> > it
> > > > (and the firewall beyond). It is unclear to me NVO3 has to know
> > this
> > > > is going on.
> > 
> > > Yikes.  I hope we're NOT designing for a single point-of-failure, out
> > > of the NVO3 overlay, from Day 1.  It seems we should be considering a
> > > minimum of 2 x exit points from the overlay from Day 1 or, at the
> > very
> > > least, the ability for some type of *extremely* fast fail-over from
> > > one 'physical' piece of hardware acting as the primary exit point to
> > a
> > > second piece of hardware acting as a secondary/standby exit point
> > from
> > > the overlay.
> > 
> > Don't we have existing techniques already for dealing with router
> > failover?  (e.g., VRRP).
> > 
> > And if you have multiple exit points, you need to deal with the
> > multiple (possibly stateful) FW issues (in some cases). Not saying that
> > can't be done, just that it may not be as simple as having multiple
> > exit routers.
> > 
> > > >>  a) it's traversing between two 'tenants'; and/or,
> > > >
> > > > By definition, we have been saying that if you go from one tenant
> > to
> > > > another, that requires that you  (conceptually) exit the overlay
> > and
> > > > re-enter it. So, again, this could be outside of NVO3's scope.
> > > >
> > > >>  b) one VM is consuming a common service/application from the DC
> > > >>   operator
> > > >
> > > > Can you expand on what this means?
> > 
> > > Let's say I'm an Amazon customer and have my own IP subnet.  At
> > times,
> > > I may want to use their S3 or other services they provide.
> > > The key point is I need my servers to talk to their S3 service, but I
> > > do not want their other customers to be able to see and/or talk to my
> > > servers, for security reasons.
> > 
> > Not sure this is a new problem to NVO3. Don't you have the same
> > scenario today using (say) VLANs? How does NVO3 change this scenario?
> > 
> > > Again, we need to be careful to include some form(s) of redundancy
> > in
> > > the plans for NVO3, specifically as it relates to traffic that  will
> > > enter/exit the overlay.  The way I see it there are three or  four
> > > things that should be considered:
> > 
> > > a)  No redundancy whatsoever for traffic entering/leaving the NVO3
> > > overlay -- good luck trying to sell this to Mega/Tera/Yotta
> > DataCenter
> > > customers ...
> > 
> > OK, but at a first cut, I see nor reason why one cannot have multiple
> > routers on a overlay given instance.
> > 
> > > b)  Active/Backup.  One exit is active at any given time; only when
> > it
> > > dies does the "backup" take over (instantaneously).
> > 
> > OK.
> > 
> > > c)  Active/Active.  Two, or more, exit points are active at any given
> > > time.  This is the scenario I think we should aim for, because it can
> > > be used to provide two physically diverse exit points from the same,
> > > physical DataCenter as well as from geographically diverse
> > > DataCenters.  Ultimately, this allows the possibility for traffic to
> > > enter/exit through the most optimal "active" entry/exit point.
> > 
> > OK.
> > 
> > I'm interested what others think about the need to add these to the
> > NVO3 requirements.
> > 
> > > >> - traffic is coming from a VM and destined toward an (IP)VPN,
> > which
> > > >> may have corporate offices spread all over the world that are
> > > >> using services provided by those VM's
> > > >
> > > > Not sure of the details of this case. Where is the overlay
> > boundary?
> > > > Are the VMs both inside an overlay instance, or is one outside?
> > (And
> > > > if the latter, isn't this  similar to previous cases?)
> > 
> > > VM's are inside the overlay, acting as application servers, but they
> > > are talking to clients (think: desktops/laptops/tablets/etc.) that
> > are
> > > sitting on a Corp WAN/LAN.  The latter, clients, are not aware of
> > NVO3
> > > and are speaking "regular" IP toward the DataCenter(s) to access
> > > various applications/resources.  It's the former, VM's inside the
> > NVO3
> > > overlay, that I care about in the context of this conversation,
> > > reqmt's and design space.
> > 
> > Understood.
> > 
> > To summarize, what you are saying about all these cases is you want to
> > have multiple exit/entry points into a specific overlay, and you want
> > NVO3 to help make sure the "closest" exit is used when possible.
> > Right?
> > 
> > Thomas
> > 
> > _______________________________________________
> > nvo3 mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/nvo3
> _______________________________________________
> nvo3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nvo3
> _______________________________________________
> nvo3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nvo3