Subject: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11

From: Martin Stiemerling <[email-masked]>
Date: Wed, 11 Jan 2017 22:52:54 +0100

Dear TSVers,

First of all, a happy new (western) year! :)

I did work through all documents that are in IETF LC, IESG processing or 
being requested for publication as of 01/11, 09:00 pm UTC.

Please find below all documents checked and what to do with these documents.

Documents that require TSV attention:
none.

Documents that do not require TSV attention:
draft-ietf-oauth-jwsreq-09
draft-ietf-ipsecme-rfc4307bis-15
draft-ietf-geojson-text-sequence-03
draft-ietf-dime-agent-overload-08
draft-ietf-bmwg-ipv6-nd-04
draft-ietf-intarea-hostname-practice-03
draft-mohali-dispatch-cause-for-service-number-12
draft-ietf-trill-rfc6439bis-04
draft-ietf-trill-directory-assist-mechanisms-10
draft-ietf-teas-p2mp-loose-path-reopt-08
draft-ietf-teas-gmpls-resource-sharing-proc-06
draft-ietf-sidr-rpki-oob-setup-06
draft-ietf-sidr-publication-10
draft-ietf-sidr-adverse-actions-03
draft-ietf-rtgwg-rlfa-node-protection-10
draft-ietf-mpls-residence-time-12
draft-ietf-lisp-type-iana-04
draft-ietf-ecrit-ecall-22
draft-ietf-ecrit-car-crash-21
draft-ietf-bfcpbis-bfcp-websocket-13
draft-ietf-6man-rdnss-rfc6106bis-14
draft-holmberg-dispatch-mcptt-rp-namespace-04
draft-murchison-webdav-prefer-13
draft-ietf-dnsop-edns-key-tag-03
draft-ietf-payload-melpe-04
draft-ietf-insipid-logme-reqs-11
draft-ietf-softwire-multicast-prefix-option-11
draft-ietf-clue-rtp-mapping-10
draft-ietf-bfcpbis-sdp-ws-uri-07
draft-ietf-dhc-dhcpv6-failover-protocol-03
draft-ietf-nvo3-use-case-15
draft-ietf-softwire-dslite-multicast-14

Thanks,

   Martin

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 12 Jan 2017 11:38:30 -0600

Thank you, Martin!

On Wednesday, January 11, 2017, Martin Stiemerling <[email-masked]>
wrote:

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

---

From: Joe Touch <[email-masked]>
Date: Fri, 13 Jan 2017 14:09:41 -0800

Hi Martin,

I've been tracking this one for a while:

It does have significant transport issues, but it's already being
watched ;-)

Joe

On 1/11/2017 1:52 PM, Martin Stiemerling wrote:
> I did work through all documents that are in IETF LC, IESG processing
> or being requested for publication as of 01/11, 09:00 pm UTC.
>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Sat, 14 Jan 2017 12:48:48 +0100

Hi Joe,

I also thought that this could potentially have a transport review. If you’d be able to send one that be great, please do so. Or what do you meant by it’s already being watched?

Mirja

> Am 13.01.2017 um 23:09 schrieb Joe Touch <[email-masked]>:
> 
> Hi Martin,
>

---

From: "Black, David" <[email-masked]>
Date: Sat, 14 Jan 2017 15:07:22 +0000

As one of the authors of the NVO3 architecture RFC, RFC 8014, I'd be willing to help with a Transport review of this NVO3 use case draft.  That'll have to happen quickly, as it looks like IETF LC ended on Wednesday, and the draft's on this week's telechat agenda.

Joe?

Thanks, --David

> -----Original Message-----
> From: Tsv-art [mailto:[email-masked]] On Behalf Of Mirja Kuehlewind
> (IETF)
> Sent: Saturday, January 14, 2017 6:49 AM
> To: Joe Touch
> Cc: Martin Stiemerling; [email-masked]
> Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11
> 
> Hi Joe,
> 
> I also thought that this could potentially have a transport review. If you’d be able
> to send one that be great, please do so. Or what do you meant by it’s already
> being watched?
> 
> Mirja
> 
>

---

From: Joe Touch <[email-masked]>
Date: Sat, 14 Jan 2017 08:09:59 -0800

I've been giving them feedback for a while. 

Joe

> On Jan 14, 2017, at 7:07 AM, Black, David <[email-masked]> wrote:
>

---

From: Joe Touch <[email-masked]>
Date: Sat, 14 Jan 2017 09:22:21 -0800

David - I think it'd be useful for fresh eyes on this. IMO, it's full of
vendor terminology that I don't think sufficiently differentiates the
data center case from any other variant of virtual network.

This is the use case doc that purports to motivate "yet another" UDP
tunneling mechanism, which has generated quite a bit of controversy and
I expect would be more relevant to TSV.

However, I'm struck by the need to publish a use case doc so soon after
the problem statement doc (just two years ago), but that's not a TSV issue.

Joe

---

From: "Black, David" <[email-masked]>
Date: Sat, 14 Jan 2017 18:33:47 +0000

Joe,

I'll take another look at this draft before the telechat. The NVO3 WG is publishing this use case draft now in part because they badly lost their way over the past couple of years :-(. I have not been a fan of this draft in the WG, but I don't fundamentally object to its publication.

Could you provide a few examples of terminology in the draft that you view as problematic?

Thanks, --David ... Sent from my Android not-so-smartphone.

-------- Original message --------
From: Joe Touch <[email-masked]>
Date: 1/14/17 9:23 AM (GMT-08:00)
To: "Black, David" <[email-masked]>
Cc: "Mirja Kuehlewind (IETF)" <[email-masked]>, Martin Stiemerling <[email-masked]>, [email-masked]
Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11

Joe

---

From: Joe Touch <[email-masked]>
Date: Sat, 14 Jan 2017 11:28:59 -0800

I'm not a fan of using human administrative, political, or economic
boundary terms as if they had any meaning in a network architecture.

Tenant system, VM, vGW, and even DC (or NVO3 for that matter) are
insufficiently defined, IMO. But that's a fault of the entire WG, not
just this doc.

This leads to gibberis (IMO) like:

  One NVO3 network can provide connectivity to many TSs that attach to
  many different NVEs in a DC. TS dynamic placement and mobility
  results in frequent changes of the binding between a TS and an NVE.

This doc boils down to "overlays are useful in data centers". Why
wouldn't they be? How are data centers different (they really aren't,
except that some fall into the class of "managed subnetworks" that can
use custom settings).

I really don't see the need for this doc at all.

Joe

On 1/14/2017 10:33 AM, Black, David wrote:
> Joe, 
>
> I'll take another look at this draft before the telechat. The NVO3 WG
> is publishing this use case draft now in part because they badly lost
> their way over the past couple of years :-(. I have not been a fan of
> this draft in the WG, but I don't fundamentally object to its
> publication. 
>
> Cc: "Mirja Kuehlewind (IETF)" <[email-masked]>, Martin
> Stiemerling <[email-masked]>, [email-masked]
> >> As one of the authors of the NVO3 architecture RFC, RFC 8014, I'd
> be willing to help with a Transport review of this NVO3 use case
> draft.  That'll have to happen quickly, as it looks like IETF LC ended
> on Wednesday, and the draft's on this week's telechat agenda.
> >>
> >> Joe?
> >>
> >> Thanks, --David
> >>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 16 Jan 2017 16:42:50 +0100

Hi Joe, hi David,

if one of you could actually still provide a „official“ tsv-art review, that would help Spencer and me to refer to something in our ballot position. But we would need that soon… anybody able to do that?

Thanks!
Mirja

> Am 14.01.2017 um 20:28 schrieb Joe Touch <[email-masked]>:
> 
> I'm not a fan of using human administrative, political, or economic boundary terms as if they had any meaning in a network architecture.
> 
> Tenant system, VM, vGW, and even DC (or NVO3 for that matter) are insufficiently defined, IMO. But that's a fault of the entire WG, not just this doc.
> 
> This doc boils down to "overlays are useful in data centers". Why wouldn't they be? How are data centers different (they really aren't, except that some fall into the class of "managed subnetworks" that can use custom settings).
>

---

From: "Black, David" <[email-masked]>
Date: Mon, 16 Jan 2017 21:34:24 +0000

I'll go do that tomorrow.

Thanks, --David

> Sent: Monday, January 16, 2017 10:43 AM
> To: Joe Touch; Black, David
> if one of you could actually still provide a „official“ tsv-art review, that would help
> Spencer and me to refer to something in our ballot position. But we would need
> that soon… anybody able to do that?
> 
> Thanks!
> Mirja
> 
> 
> > I'm not a fan of using human administrative, political, or economic boundary
> terms as if they had any meaning in a network architecture.
> >
> insufficiently defined, IMO. But that's a fault of the entire WG, not just this doc.
> >
> > This doc boils down to "overlays are useful in data centers". Why wouldn't they
> be? How are data centers different (they really aren't, except that some fall into
> the class of "managed subnetworks" that can use custom settings).
> >
> >> I'll take another look at this draft before the telechat. The NVO3 WG is
> publishing this use case draft now in part because they badly lost their way over
> the past couple of years :-(. I have not been a fan of this draft in the WG, but I
> don't fundamentally object to its publication.
> >>
> >> >> As one of the authors of the NVO3 architecture RFC, RFC 8014, I'd be willing
> to help with a Transport review of this NVO3 use case draft.  That'll have to
> happen quickly, as it looks like IETF LC ended on Wednesday, and the draft's on
> this week's telechat agenda.
> >> >>
> >> >> Joe?
> >> >>
> >> >> Thanks, --David
> >> >>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 16 Jan 2017 23:22:59 +0100

Thanks!

> Am 16.01.2017 um 22:34 schrieb Black, David <[email-masked]>:
>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 17 Jan 2017 13:10:51 +0100

Hi Joe,

I finally read the draft myself completely. I agree that there is nothing in the draft that motivates a new tunnel protocol, however, the draft is also not (explicitly) requiring a new protocol.

This says in the summary:

„A tunnel encapsulation protocol is necessary.“

which clearly doesn’t say that an existing one might not be sufficient.

I don’t think there is anything we can do at this stage and with this draft…

I’ll wait for David’s review before I put in my ballot.

Mirja

> Am 14.01.2017 um 18:22 schrieb Joe Touch <[email-masked]>:
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 17 Jan 2017 07:38:06 -0800

> which clearly doesn’t say that an existing one might not be sufficient.

Good point, but it begs the question of the need for the rest of the
document. The use cases have nothing to do uniquely with datacenters.
> I don’t think there is anything we can do at this stage and with this draft…

The IETF does err on the side of publishing (rather than requiring
"proof of need or utility"). However, there's always the opportunity for
pushback at the higher levels, e.g., to make sure that the doc itself
indicates clearly what it does and does not contribute. E.g., it's
possible to ask for a sentence explaining exactly how this is different
from any other sort of overlay network - or stating clearly that the
conclusion is that datacenters are not unique in their use of overlays.

Joe

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 17 Jan 2017 17:17:35 +0100

Hi Joe,

agreed but this still doesn’t justify a discuss. I will put a comment in my ballot. However, these are probably comments that should have been discussed at chartering…

Mirja

> Am 17.01.2017 um 16:38 schrieb Joe Touch <[email-masked]>:
> 
> 
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 17 Jan 2017 10:49:55 -0600

FWIW,

On Tue, Jan 17, 2017 at 9:38 AM, Joe Touch <[email-masked]> wrote:

> > I finally read the draft myself completely. I agree that there is
> nothing in the draft that motivates a new tunnel protocol, however, the
> draft is also not (explicitly) requiring a new protocol.
> >

This sounds like a plan. I'll include that in my ballot comments.

My biggest heartburn is that I'm not seeing a lot of details that separate
the use cases AT THE PROTOCOL LEVEL - yeah, of course, you'd rather run
compute-bound processes on real hardware, but how does that impact
requirements for protocols?

Spencer

> >>>> As one of the authors of the NVO3 architecture RFC, RFC 8014, I'd be
> willing to help with a Transport review of this NVO3 use case draft.
> That'll have to happen quickly, as it looks like IETF LC ended on
> Wednesday, and the draft's on this week's telechat agenda.
> >>>>
> >>>> Joe?
> >>>>
> >>>> Thanks, --David
> >>>>

---

From: "Black, David" <[email-masked]>
Date: Tue, 17 Jan 2017 22:04:10 +0000

I'm working on the review now.

I concur with Joe's observation that the terminology situation is "a fault of the entire WG" - one of the primary causes was the original AD decision (at WG formation time) to force the WG's scope to span both MAC-in-IP encapsulations like VXLAN and MPLS encapsulations like L3VPN, making it necessary to use neutral terminology that is not native to either of the underlay network technology domains ... and later on, both LISP and L2VPN joined the adventure ...

Subsequently, Alia dramatically cut back the scope of the NVO3 WG to {MAC,IP}-in-IP virtual network encapsulations in the hope of enabling the WG to actually do something useful ... but by then, the die was cast on terminology.

Thanks, --David

From: Joe Touch [mailto:[email-masked]]
Sent: Saturday, January 14, 2017 2:29 PM
To: Black, David
Cc: Mirja Kuehlewind (IETF); Martin Stiemerling; [email-masked]
Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11

Joe

-------- Original message --------
From: Joe Touch <[email-masked]><mailto:[email-masked]>
Date: 1/14/17 9:23 AM (GMT-08:00)
To: "Black, David" <[email-masked]><mailto:[email-masked]>
Cc: "Mirja Kuehlewind (IETF)" <[email-masked]><mailto:[email-masked]>, Martin Stiemerling <[email-masked]><mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11

Joe

On 1/14/2017 8:09 AM, Joe Touch wrote:
>> On Jan 14, 2017, at 7:07 AM, Black, David <[email-masked]><mailto:[email-masked]> wrote:
>>
>>> Cc: Martin Stiemerling; [email-masked]<mailto:[email-masked]>
>>> I also thought that this could potentially have a transport review. If you'd be able
>>> to send one that be great, please do so. Or what do you meant by it's already
>>> being watched?
>>>
>>> Mirja
>>>
>>>
>>>> Am 13.01.2017 um 23:09 schrieb Joe Touch <[email-masked]><mailto:[email-masked]>:
>>>>
>>>> Hi Martin,
>>>>
>>>>> [email-masked]<mailto:[email-masked]>
>>>> [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 19 Jan 2017 18:42:23 +0100

Hi Joe and David,

Thanks for taking care of this!

> It does have significant transport issues, but it's already being

Arg, ok, and I did believe that use case documents should be almost safe 
of not having transport issues.

   Martin