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

["Black, David" <[e-mail]>]

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:[e-mail]]
Sent: Saturday, January 14, 2017 2:29 PM
To: Black, David
Cc: Mirja Kuehlewind (IETF); Martin Stiemerling; [e-mail]
Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11


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.

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 <[e-mail]><mailto:[e-mail]>
Date: 1/14/17 9:23 AM (GMT-08:00)
To: "Black, David" <[e-mail]><mailto:[e-mail]>
Cc: "Mirja Kuehlewind (IETF)" <[e-mail]><mailto:[e-mail]>, Martin Stiemerling <[e-mail]><mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>
Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11

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


On 1/14/2017 8:09 AM, Joe Touch wrote:
> I've been giving them feedback for a while.
>
> Joe
>
>> On Jan 14, 2017, at 7:07 AM, Black, David <[e-mail]><mailto:[e-mail]> wrote:
>>
>> 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:[e-mail]] On Behalf Of Mirja Kuehlewind
>>> (IETF)
>>> Sent: Saturday, January 14, 2017 6:49 AM
>>> To: Joe Touch
>>> Cc: Martin Stiemerling; [e-mail]<mailto:[e-mail]>
>>> 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
>>>
>>>
>>>> Am 13.01.2017 um 23:09 schrieb Joe Touch <[e-mail]><mailto:[e-mail]>:
>>>>
>>>> Hi Martin,
>>>>
>>>> I've been tracking this one for a while:
>>>>
>>>> draft-ietf-nvo3-use-case-15
>>>>
>>>> It does have significant transport issues, but it's already being
>>>> watched ;-)
>>>>
>>>> Joe
>>>>
>>>>
>>>>> On 1/11/2017 1:52 PM, Martin Stiemerling wrote:
>>>>> 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
>>>>>
>>>>> _______________________________________________
>>>>> Tsv-art mailing list
>>>>> [e-mail]<mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/tsv-art
>>>> _______________________________________________
>>>> Tsv-art mailing list
>>>> [e-mail]<mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/tsv-art
>>> _______________________________________________
>>> Tsv-art mailing list
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/tsv-art