Subject: [v6ops] State of play as of today

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 1 Oct 2015 19:16:36 +0000

The draft repository closes 10/19, the chairs are supposed to file an initial agenda proposal the same day, and IETF 94 is the week of 11/1. To get on the agenda, I need an updated draft from before or a new -00 draft, and supportive discussion on the list of that draft. That means that filing a draft on 10/19, along with 355 others, is probably not a winning proposition. The time to file a new -00 or to stimulate discussion of an updated draft is now.

Please do so.

BTW, 355 is not an exaggeration:
Drafts posted 2015-07-01 -  34
Drafts posted 2015-07-02 -  58
Drafts posted 2015-07-03 -  55
Drafts posted 2015-07-04 -  26
Drafts posted 2015-07-05 -  81
Drafts posted 2015-07-06 - 355
Drafts posted 2015-07-07 -   4
Drafts posted 2015-07-08 -   4
Drafts posted 2015-07-09 -   4

Our status at this instant is as follows.
  - We are discussing draft-ietf-v6ops-host-addr-availability,
  - waiting for an update of draft-bao-v6ops-rfc6145bis in response to a comment yesterday
  - waiting for an update to draft-ietf-v6ops-design-choices,
  - otherwise have pretty much cleared our queue of documents.

I do have a proposal from Tom Herbert (formerly Google, now Facebook) to discuss https://tools.ietf.org/html/draft-herbert-nvo3-ila. This is interesting in the context of allocation of a /64 to a host in a data center. He tells me that there are a few changes (notably a routable interior address) in a version he is about to post, and that Facebook plans some "canary" deployments to test the concepts. I tend to think it would be an interesting discussion, but have not heard from the working group.

Status:

Independent Series RFC Editor's queue:
	2015-09-15	draft-ietf-v6ops-mobile-device-profile

Publication Requested
	2015-10-01	draft-ietf-v6ops-reducing-ra-energy-consumption

Waiting for AD Go-Ahead (IETF LC closed, on IESG agenda 10/15)
	2015-09-30	draft-ietf-v6ops-pmtud-ecmp-problem

Waiting for Writeup
	2015-09-22	draft-ietf-v6ops-siit-dc
	2015-09-22	draft-ietf-v6ops-siit-dc-2xlat
	2015-09-22	draft-ietf-v6ops-siit-eam

Waiting for update from authors:
	2015-07-06	draft-ietf-v6ops-design-choices

Unupdated WG Document
	2015-07-06	draft-ietf-v6ops-dhcpv6-slaac-problem
	2015-05-03	draft-ietf-v6ops-ula-usage-recommendations
	2015-05-01	draft-ietf-v6ops-ipv6-ehs-in-real-world

Updated WG Document
	2015-09-03	draft-ietf-v6ops-host-addr-availability

Unupdated Individual Submission
	2015-07-06	draft-akira-v6ops-mape-experience
	2015-07-06	draft-xcf-v6ops-chinatelecom-deployment
	2015-07-05	draft-hui-v6ops-ipv6trans-select-nfv
	2015-07-05	draft-xli-v6ops-cernet-deployment
	2015-07-05	draft-yang-v6ops-ipv6tran-select
	2015-07-01	draft-gont-v6ops-ipv6-ehs-packet-drops
	2015-06-26	draft-vyncke-v6ops-ipv6-only-thin-clients
	2015-06-25	draft-sun-v6ops-xlat-multi

Updated Individual Submission
	2015-09-21	draft-ybai-v6ops-ipv6-for-openstack
	2015-08-08	draft-bao-v6ops-rfc6145bis

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 1 Oct 2015 22:41:50 +0000

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Fred Baker (fred)
Sent: Thursday, October 01, 2015 3:17 PM
To: [email-masked]
Subject: [v6ops] State of play as of today

>I do have a proposal from Tom Herbert (formerly Google, now Facebook) to discuss https://tools.ietf.org/html/draft-herbert-nvo3-ila. This is interesting in the context of allocation of a /64 to a host in a >data center. He tells me that there are a few changes (notably a routable interior address) in a version he is about to post, and that Facebook plans some "canary" deployments to test the concepts. I >tend to think it would be an interesting discussion, but have not heard from the working group.

If Tom could please update the document with an email that does not bounce back when people contact him for his submission, I'd appreciate it.   Certainly, this work could be discussed including the fact whether the consensus is to remain within the 64-bit boundary between the interface-id vs. not for any IPv6 addressing. 

Other comments:

In section5.1.2 , the document says "Since migrations should be relatively rare events,".   If migration is a rare event, is it worth solving the task move problem?  Why not stay with "not to migrate" until the task runs to completion and not work on any ILA?

The WG  and the author could decide if the document serves the purpose for ILA and task move but keeps away from tenant separation because the security  in section 5.2 and its 3rd paragraph which ends in "not considered a significant risk" is questionable.   I suspect security will take lot more effort.

Thanks,

Hemant

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 1 Oct 2015 22:48:44 +0000

> On Oct 1, 2015, at 3:41 PM, Hemant Singh (shemant) <[email-masked]> wrote:
> 
> If Tom could please update the document with an email that does not bounce back when people contact him for his submission, I'd appreciate it.

He seems to be using [email-masked]

>  Certainly, this work could be discussed including the fact whether the consensus is to remain within the 64-bit boundary between the interface-id vs. not for any IPv6 addressing.
> 
> Other comments:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 2 Oct 2015 11:56:36 +1300

>>  Certainly, this work could be discussed including the fact whether the consensus is to remain within the 64-bit boundary between the interface-id vs. not for any IPv6 addressing.

I would strongly suggest discussing draft-smith-enhance-vne-with-ipv6 at
the same time.

   Brian

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Tom Herbert <[email-masked]>
Date: Thu, 1 Oct 2015 16:59:44 -0700

>> If Tom could please update the document with an email that does not bounce back when people contact him for his submission, I'd appreciate it.
Sorry about that, I'll update the draft soon.

> He seems to be using [email-masked]
Yes.

>> In section5.1.2 , the document says "Since migrations should be relatively rare events,".   If migration is a rare event, is it worth solving the task move problem?  Why not stay with "not to migr…
Rare is relative here, in a large data center we could be migrating
hundreds of jobs per second. There are also instances where we need to
a mass migration like when we need to bring down a cluster for repair.
The salient property is that the cost of adding the ability to migrate
is near zero when tasks that are not migrating.

>> The WG  and the author could decide if the document serves the purpose for ILA and task move but keeps away from tenant separation because the security  in section 5.2 and its 3rd paragraph which…

It's not a significant security risk in the sense that all tenants are
already part of the same entity. In a cloud application with third
party untrusting tenants then ILA would probably not offer adequate
security (although I would point out that this is no worse security
than with VXLAN).

Tom

---

From: Tom Herbert <[email-masked]>
Date: Thu, 1 Oct 2015 17:03:37 -0700

> I would strongly suggest discussing draft-smith-enhance-vne-with-ipv6 at
Brian, I think ILA is mostly a manifestion of the sections 4 and 5.1
of that draft (flow labels are not relevant in ILA).

Tom

---

From: Mark Smith <[email-masked]>
Date: Fri, 2 Oct 2015 10:20:37 +1000

Hi,

On 2 October 2015 at 08:56, Brian E Carpenter
<[email-masked]> wrote:

<snip>

> I would strongly suggest discussing draft-smith-enhance-vne-with-ipv6 at

To save people a bit of time, I did the following presentation on that
draft at the AusNOG 2014 conference:

"Network Virtualisation: The Killer App for IPv6?"
http://www.slideshare.net/MarkSmith214/nvtkaipv6-50785685

Tom asked me to review his ILA draft a while back. In the context of
both his and my drafts, and having had some further time to think
about them, I think there might be two different but related problems
being considered:

- network virtualization, which I think might actually be more
accurately described as "network emulation"

- virtual machine / process portability across physical machines and
grouping of them together so they share a prefix for policy and other
reasons

My draft was purely focussed on the first problem, although it
inherently addresses the second. From memory, I think Tom's was
specifically addressing both of the problems.

The reason I've come to realise there are probably two different
problems to consider is that one of the fundamental differences
between what I proposed (and what other network
virtualization/emulation methods propose) and what Tom proposed is
that in his model, the hosts within the virtual networks have to have
IPv6 addresses that are structured to suit the operation of the
underlay network. This is easy or easier to achieve when the operator
of both the underlay and overlay networks is the same
entity/organisation.

I think that difference is fairly significant from the point of view
of trying to perform network emulation successfully. It seems to me
that if you're emulating a network, then your fundamental goal is that
the emulation of the network should be as transparent as possible to
the hosts using the emulated network, which includes allowing them to
use what ever addressing / addressing structure they'd like.

I think Tom's proposal is a good solution to the second problem,
however I wouldn't see it as a complete network emulation solution
because of its client host addressing requirements. I do think there
is a need for solutions to both types of "network virtualization".

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 2 Oct 2015 11:17:59 +0900

On Fri, Oct 2, 2015 at 7:56 AM, Brian E Carpenter <
[email-masked]> wrote:

> >>  Certainly, this work could be discussed including the fact whether the
> consensus is to remain within the 64-bit boundary between the interface-id
> vs. not for any IPv6 addressing.
>

I would really like to hear about this sort of thing. It's a good example
of the kinds of things we'll be able to do with IPv6 when it's deployed
widely enough for us to think in terms of what we can do with IPv6, instead
of just mimicking whatever we do in IPv4.

---

From: Mark Smith <[email-masked]>
Date: Fri, 2 Oct 2015 14:06:58 +1000

On 2 October 2015 at 12:17, Lorenzo Colitti <[email-masked]> wrote:
> On Fri, Oct 2, 2015 at 7:56 AM, Brian E Carpenter
> I would really like to hear about this sort of thing. It's a good example of
> the kinds of things we'll be able to do with IPv6 when it's deployed widely
> enough for us to think in terms of what we can do with IPv6, instead of just
> mimicking whatever we do in IPv4.
>

Just did a bump of the draft, I forgot to delete a section a few rev's ago.

Here's the latest:

"Enhancing Virtual Network Encapsulation with IPv6"
https://tools.ietf.org/html/draft-smith-enhance-vne-with-ipv6-07

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 2 Oct 2015 12:58:05 +0000

>From: Lorenzo Colitti [mailto:[email-masked]] 
>Sent: Thursday, October 01, 2015 10:18 PM
>To: Brian E Carpenter
>Cc: Fred Baker (fred); Hemant Singh (shemant); Tom Herbert; [email-masked]
>Subject: Re: [v6ops] State of play as of today

>I would really like to hear about this sort of thing. It's a good example of the kinds of things we'll be able to do with IPv6 when it's deployed widely enough for us to think in terms of what 
>we can do with IPv6, instead of just mimicking whatever we do in IPv4. 

Does IPv4 in the data center support container/task migration and if so, how is it done today? 

Hemant

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 2 Oct 2015 20:18:39 +0000

> On Oct 2, 2015, at 5:58 AM, Hemant Singh (shemant) <[email-masked]> wrote:
> 

This isn't really an IPv4/IPv6 question as much as it is a process question. To my knowledge, there are two fundamental approaches.

One is suitable for transaction systems, like Jynga's games, web clusters, and client/server applications built on top of the web. In that model, consider that the server is a cluster of VM/Containers that one reaches by DNS name or something equivalent. In that model, one spins up a new server instance, adds its address to the DNS name in a DNS Resource Record (so it is now servicing transactions), deletes the old address's DNS Resource Record (so the only folks opening new transactions with it already had its address from a previous read of DNS), waits a while (the RR has to expire, and you then need to continue waiting until all active sessions acquiesce), and then kills the old system.

The other is more for applications that have to maintain memory across such a change. VMWare describes it at http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1000936. In that case, you're literally moving the VM/Container and its IP address; if you're not willing to stop its processing while you do so, it is changing its swap image while you're copying the image somewhere else. Net result - you copy the image, copy the parts that changed while you were doing that, and do so again, until you get something consistent at the new and the old locations. Then you kill the old and continue with the new.

The advantage of Tom's approach is that moving the "inside" address requires nothing in routing, only informing the systems that care where the instance is that the instance has changed. Depending on the nature of the application moved, you'll use something akin to one of those approaches.