[v6ops] Fwd: [Rtg-dt-encap-considerations] overlay encapsulation group

["Fred Baker (fred)" <[e-mail]>]

Running a question by the list. Tom and I got to talking about this because I proposed an approach to IPv6 networking for OpenStack (https://tools.ietf.org/html/draft-baker-openstack-ipv6-model), and Tom proposed a similar but different model in nvo3 (draft-herbert-nvo3-ila). From what he says, I gather that Facebook is looking at trial deployment of a modified version of his approach that takes an important step in the direction of mine.

What I wonder is whether the WG would be interested in an operational discussion of draft-herbert-nvo3-ila and Facebook's IPv6 deployment at IETF 94? And specifically, do folks have comments on his updated draft when he posts it?

On Sep 25, 2015, at 2:12 PM, Tom Herbert <[e-mail]> wrote:
> Thanks Fred.
> 
> The ILA draft is https://datatracker.ietf.org/doc/draft-herbert-nvo3-ila/.
> 
> Tom

> From: Tom Herbert <[e-mail]>
> Subject: Re: [Rtg-dt-encap-considerations] overlay encapsulation group
> Date: September 24, 2015 at 12:54:41 PM PDT
> To: "Fred Baker (fred)" <[e-mail]>
> 
> Hi Fred,
> 
> I'd like to give you an update on ILA.
> 
> We pushed an initial implementation to upstream
> https://lwn.net/Articles/654540/. I have a couple of more patches to
> get in, but this will get us to a pretty performant data path (much
> better than what we'll get from traditional encapsulation).
> 
> Internally (@FB), we are commencing canary deployments. There was an
> interesting debate on whether to use ULA or get a larger address
> allocation (the latter won), but so far this approach seems feasible.
> 
> One design change, which I think may be along the lines of you were
> asking, is that we will allow untranslated addresses to be routable.
> Untranslated packets would be routed to some intermediate device in
> the network which perform the translation and forward packet to the
> location of the virtual node. We'll have these nodes be able to send
> something like an ICMP redirect to the source to eliminate the
> triangular routing for future packets.
> 
> I'm planning on updating the ILA draft for IETF. I can present that
> work at nvo3, but do you think there would be any interest or reason
> to take this to an IPv6 WG?
> 
> Thanks,
> Tom
> 
> On Mon, Apr 27, 2015 at 1:41 PM, Fred Baker (fred) <[e-mail]> wrote:
>> 
>>> On Apr 27, 2015, at 1:31 PM, Tom Herbert <[e-mail]> wrote:
>>> In ILA the translation is always symmetric between sender and receiver, and the translation is transparent to the user in the same way that NV encapsulation would be. Applications at both endpoints see the same addresses for the connection (SIR addresses in the draft), and these are what is put into DNS. Many of the communication scenarios showing this are in section 4 of the ILA draft. On the wire intermediate devices would see the translated addresses.
>> 
>> In the data plane, at the network layer. The redirect is in an application message and might well be encrypted. But the sender of the redirect has to get it to the receiver, and give an address for the third party that the receiver can use.
>> 
>>> The problem we are trying to solve in virtualizing data center tasks is how to allow task A on physical host X to communicate with task B on physical host Y; and then how to continue communications when task B moves to physical host Z. I guess this could be considered a reachability, connectivity, routability, or authorization problem depending on how you want to look at it.
>> 
>> Yes. It’s one of the first three after it moves and before it is renumbered. Before moving and after renumbering, it is just an authorization problem, IMHO.
>> 
>>> In multi-tenancy, we have a requirement for isolation between tenants. If traffic crosses between tenant networks without authorization this is fundamentally bad, so we need strong guarantees (maybe this is what you mean by authorization problem?).
>> 
>> Yes
>> 
>>> The VNID is a mechanism of isolation, but not typically self-authenticated.
>> 
>> If it’s in the IPv6 IID, it’s assigned by the orchestrator, and the BCP 38 filter in the vSwitch enforces its use. That’s the same way VLAN numbers or whatever are used. Which is to say that it’s at least as secure as using a VLAN, given tat the orchestrator installs the correct ACLs.
>> 
>>> In GUE, we added a security option that allows shared cookie, secure hash, etc. Unfortunately, I haven't figured out how to add that in ILA and without security it makes large scale deployment for the multi tenant use case problematic (the lack of a secured VNID made VLXAN and NV-GRE non starters for us). I considered flow label for security bits in ILA, but maybe this could be something in the header options similar to what you describe in section B.2 (although I am leery of using any sort of IP options due to lack of middlebox support).
>> 
>> I think I’m telling you how to do that...
>> 
>>>> So, redraw my section B.5 in ILNP terms. Suppose we put the VNID (which I call a tenant number) in the IID, and treat the prefix as a locator as ILNP does. Did we accomplish your goal? I think we did, and we made it be without the coupling, and we made the ACL configuration (which is the authorization verification) consistent whether in one chassis, two data centers, or a hybrid cloud with multiple operators.
>>> 
>>> The VNID (tenant number) is already in the identifier (IID part) in ILA. I don't see any reason why ACLs can't be created for that. Only the locator part is translated on the wire, so the VNID is also visible to intermediate devices.
>> 
>> BUT THE LOCATOR IS TRANSLATED, which brings me back to my pervious email. In an ILNP system, it doesn’t need to be. Why not just use the ILNP address? A long list of issues go away.
>>