Hi Lucy,
I’m going back to the original question of whether we need a new service type,
and starting from a couple of comments from you on how the proposed new L2-3
service works ...
> But a frame from TS have both Ethernet and IP header. From TS perspective,
> the frame to the TS on the same s
Hi Lucy,
More inline.
Thanks,
--David
From: nvo3-boun...@ietf.org [mailto:nvo3-boun...@ietf.org] On Behalf Of Lucy
yong
Sent: Wednesday, December 26, 2012 1:52 PM
To: Black, David
Cc: nvo3@ietf.org
Subject: Re: [nvo3] Multi-subnet VNs - should be a new service type?
Hi David,
Glad to see
attachment of IP
routing functionality to L2 (virtual) networks.
Thanks,
--David
From: Lucy yong [mailto:lucy.y...@huawei.com]
Sent: Thursday, December 27, 2012 11:55 AM
To: Black, David
Cc: nvo3@ietf.org
Subject: RE: Multi-subnet VNs - should be a new service type?
David,
Please see in-line with
> I do not really understand how the source MAC address of a frame received
> from an overlay
> tunnel can be learned against the L3 tunnel destination address by an L2 NVI,
> since the
> Overlay module already removed the overlay encapsulation header before the
> frame is
> delivered to the L2
I believe that BGP is among the possible ways to implement this service.
I think that “directory” is not a good characterization of BGP.
Hence “directory” does not appear to be a good word to use as part of the
replacement of the “Oracle” term.
Thanks,
--David
From: nvo3-boun...@ietf.org [mailto
NVMA +1, and I think Mapping is ok wrt BGP, as nvo3’s use of BGP would be to
distribute (address) mapping information.
Thanks,
--David
From: nvo3-boun...@ietf.org [mailto:nvo3-boun...@ietf.org] On Behalf Of Sharon
Sent: Wednesday, April 10, 2013 1:00 AM
To: Truman Boyes
Cc: Lou Berger; Larry Kre
I think this may reflect some confusion around possible meanings of
“interface”. I believe that the notion of “interface” that is desired here
corresponds to a vNIC, not a bonded set of vNICs (and likewise to a NIC, not a
bonded set of NICs). If that clarification is clear, I think TSI would b
: Jon Hudson [mailto:jon.hud...@gmail.com]
Sent: Wednesday, April 17, 2013 10:29 AM
To: Truman Boyes
Cc: John E Drake; nvo3@ietf.org; Reith, Lothar; Black, David; Anoop Ghanwani;
Larry Kreeger (kreeger); Qin Wu
Subject: Re: [nvo3] NVO3 Terminology changes
It's a worthwhile point. While I think
ple VLANs end-to-end, and those VLANs have no interactions with
the
NVEs (the VLAN tag just passes through encap and decap).
Thanks,
--David
From: Eric Gray [mailto:eric.g...@ericsson.com]
Sent: Wednesday, April 17, 2013 11:20 AM
To: Black, David; Jon Hudson; Truman Boyes
Cc: nvo3@ietf.org
..@ericsson.com]
Sent: Wednesday, April 17, 2013 11:59 AM
To: Black, David
Cc: nvo3@ietf.org
Subject: RE: [nvo3] NVO3 Terminology changes
David,
If you had a virtual machine consisting of a single virtual
instance as part of a physical server,
connected via a single-instance vNI
+1, --David
> -Original Message-
> From: nvo3-boun...@ietf.org [mailto:nvo3-boun...@ietf.org] On Behalf Of Thomas
> Narten
> Sent: Thursday, April 18, 2013 8:41 AM
> To: Qin Wu
> Cc: Eric Gray; nvo3@ietf.org
> Subject: Re: [nvo3] 答复: 答复: Comments on draft-ietf-nvo3-overlay-problem-
> state
+1, --David
From: nvo3-boun...@ietf.org [mailto:nvo3-boun...@ietf.org] On Behalf Of Pat
Thaler
Sent: Monday, April 22, 2013 6:32 PM
To: Larry Kreeger (kreeger); nvo3@ietf.org
Subject: Re: [nvo3] New name for "oracle"
Thumb up. Pat
From: nvo3-boun...@ietf.org [mailto:nvo3-boun...@ietf.org] On Be
A -02 version of this draft can be found at:
http://datatracker.ietf.org/doc/draft-kompella-nvo3-server2nve/
This is the draft version that I should've completed and posted before
the Orlando meetings. The primary purpose of this -02 version is to
serve as a useful source of text for other draft
d.
Thanks,
--David
> -Original Message-
> From: nvo3-boun...@ietf.org [mailto:nvo3-boun...@ietf.org] On Behalf Of Reith,
> Lothar
> Sent: Tuesday, April 30, 2013 5:24 AM
> To: Black, David; nvo3@ietf.org
> Subject: Re: [nvo3] New version of draft-kompella-nvo3-server2nve posted
My initial reaction is that this seems no worse than the typical route-flapping
effects of some routing updates - it's certainly worth noting, but I would not
require that it be eliminated completely in all solutions.
Thanks,
--David
David L.
I am not aware of any IPR relevant to this draft.
--David
From: nvo3-boun...@ietf.org [mailto:nvo3-boun...@ietf.org] On Behalf Of
NAPIERALA, MARIA H
Sent: Friday, May 17, 2013 1:42 PM
To: Luyuan Fang (lufang); Larry Kreeger (kreeger); Bocci, Matthew (Matthew);
nvo3@ietf.org
Subject: Re: [nvo3]
What are the specific text changes that you are suggesting?
Thanks,
--David
From: nvo3-boun...@ietf.org [mailto:nvo3-boun...@ietf.org] On Behalf Of Florian
Mahr
Sent: Friday, May 31, 2013 11:39 AM
To: nvo3@ietf.org
Subject: [nvo3] Comments on draft-kreeger-nvo3-overlay-cp-03
I would like to mak
In working on some control plane draft material, I've run across an
inconsistency in the use of the concept of a "virtual network instance"
(or VNI) between the problem statement and framework drafts.
The problem statement draft does not define "virtual network instance"
and uses that term more or
LASSERRE, MARC (MARC) [mailto:marc.lasse...@alcatel-lucent.com]
> Sent: Wednesday, June 19, 2013 3:54 AM
> To: Black, David
> Cc: nvo3@ietf.org
> Subject: RE: Virtual Network - what's an instance?
>
> Hi David,
>
> In the soon-to-be-published revision of the framework draft,
E: Virtual Network - what's an instance?
> >
> > IMO, a virtual network is the set of [network] resources exposed by a
> > server to a client. From the client's point of view, there is only one
> > VN. From the server's point of view, there are as many VNIs as
and
"virtual network instance" (problem statement draft) ought to be the
same term - do you disagree?
Thanks,
--David
> -Original Message-
> From: Eric Gray [mailto:eric.g...@ericsson.com]
> Sent: Thursday, June 27, 2013 4:19 PM
> To: Black, David; Reith, Lothar;
Support as author. I am not aware of any IPR relevant to this draft.
Thanks,
--David
> -Original Message-
> From: nvo3-boun...@ietf.org [mailto:nvo3-boun...@ietf.org] On Behalf Of Benson
> Schliesser
> Sent: Thursday, June 27, 2013 9:26 PM
> To: nvo3@ietf.org
> Subject: [nvo3] Poll for W
on is either a tautology, or
> > it is wrong.
> >
> > As one of my colleagues has put it, a VN is a concept and a VNI
> > is a realization of the concept.
> >
> > VLAN 41 may be an instance of the VLAN concept.
> >
> > The subnet associated w
Hi Lizhong
> One more comment for section 3.1 Inner to Outer Address Mapping. The
> destination inner
> address here, I think refer to destination IP/MAC address. But from my view,
> this is
> a bit narrow concept. A flow to outer address mapping would be a more general
> concept.
> The flow co
The question that I have is: How does your notion of flow-based forwarding
relate to
the notions of L2 and L3 service in the problem statement and framework drafts?
We've had a prior discussion of IRB (combined L2/L3 implementation) and my
impression
of the conclusion of that discussion is that
Lizhong,
We can certainly talk about what the WG will or won't standardize, but
(IMHO), it's necessary to pay attention to what's in use - this is a
specific case of looking at "running code" in addition to "rough consensus".
All three of those encapsulations are deployed and in use, today.
Than
I should first say that there is a lot to like in the security requirements
draft (draft-ietf-nvo3-security-requirements-01), and I particularly
appreciate the distinction that it makes between secure vs. insecure underlay
networks as well as secure vs. insecure connectivity on the non-NVO3 side of
e
inherently multi-VN and multi-tenant (and probably don't have tenant
security credentials) suggests that REQ5 is probably still
overstated even for just data plane security signaling.
Thanks,
--David
> -Original Message-
> From: Zhangdacheng (Dacheng) [mailto:zhangdach...@
rd boundaries on the NVE side will be needed to prevent
the independent NVAs from interfering with each other.
Thanks,
--David
From: Linda Dunbar [mailto:linda.dun...@huawei.com]
Sent: Thursday, October 24, 2013 2:19 PM
To: Larry Kreeger (kreeger); Linda Dunbar; Thomas Narten; Black, David
Cc: nvo3@
> Sorry to jump into this discussion. A few questions on the Distributed
> Gateways definition.
> - There is Gateway defined in section 5.3. Do we still need a Gateway when
> Distributed Gateways are enabled in the NVEs? Maybe yes. Please clarify it in
> the draft.
Gateway = function, Distributed
statement
that Distributed Gateways apply to both types of service.
Thanks,
--David
> -Original Message-----
> From: Larry Kreeger (kreeger) [mailto:kree...@cisco.com]
> Sent: Thursday, October 24, 2013 6:44 PM
> To: Black, David; Zu Qiang
> Cc: nvo3@ietf.org
> Subject: R
onging to different VNs MUST use different keys to secure
> the control packets exchanges with their NVE."
>
> I would like to rewrite it to "If assuming the hypervisors can be compromised,
> each hypervisor MUST use different keys to secure
> its control packet exchange
to elaborate ...
Thanks,
--David
From: Linda Dunbar [mailto:linda.dun...@huawei.com]
Sent: Wednesday, October 30, 2013 7:00 PM
To: Thomas Narten; Black, David; 'Jon Hudson'; Larry Kreeger (kreeger);
LASSERRE, MARC (MARC)
Cc: nvo3@ietf.org
Subject: Comments to draft-narten-nvo3-arch
Support (as a co-author). I am not aware of any IPR that applies to this draft.
Thanks,
--David
From: nvo3-boun...@ietf.org [mailto:nvo3-boun...@ietf.org] On Behalf Of Bocci,
Matthew (Matthew)
Sent: Wednesday, November 13, 2013 8:58 AM
To: nvo3@ietf.org
Subject: [nvo3] Poll for WG adoption and
Writing as an individual, not co-author of draft-narten-nvo3-arch:
> What is missing for me is a higher-level statement whether or not we see
> an NVE providing combined L2 and L3 service as being architecturally
> different that the non-overlay case of a bridge+router that provides
> combined ser
or routing and VLANs.
Thanks,
--David
> -Original Message-----
> From: Lucy yong [mailto:lucy.y...@huawei.com]
> Sent: Sunday, November 24, 2013 7:50 PM
> To: Black, David; Erik Nordmark
> Cc: nvo3@ietf.org
> Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Serv
I may over-simplify the router to focus on this case only. My point is
> that the router device in this case typically handles one L3 address space and
> one MAC address space in the reality.
See above on "multiple instances" of the "router".
Thanks,
--David
> ---
+1 - new specifications should definitely not be using MD5, and the SHA-2
hashes are preferable to SHA-1.
A useful related reference is NIST SP 800-131A:
http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf
Thanks,
--David
From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Tr
Hello Zu,
For the MPLS comment, could you propose revised text?
> >resulting
> >in a specific Tenant Address (on a specific VN) being reachable
> >via more than one underlay IP address. Second, a specific tenant
> >system may be reachable through more than one NVE. In both cases,
> This email begins a two week working group last call for
> draft-ietf-nvo3-dataplane-requirements-02.txt.
>
> Please review the draft and post any comments to the NVO3 working group list.
Here are some belated comments on this draft (sorry, but any WG LC in the weeks
immediately preceding an IE
Hi Lucy,
I'm not at all sure. For a layer 2 appliance (e.g., firewall), it suffices for
the destination MAC to be reachable only through the firewall; the NVA can set
up the appropriate address mapping so that the firewall NVE is chosen. For
layer 3 appliance (e.g., firewall), if the firewall
And inline ...
From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Lucy yong
Sent: Monday, March 10, 2014 4:21 PM
To: Black, David; draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org
Cc: nvo3@ietf.org
Subject: Re: [nvo3] needed data plane encap requirement in
draft-ietf-nvo3-dataplane
From: Lucy yong [mailto:lucy.y...@huawei.com]
Sent: Monday, March 10, 2014 7:29 PM
To: Black, David; draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org
Cc: nvo3@ietf.org
Subject: RE: needed data plane encap requirement in
draft-ietf-nvo3-dataplane-requirements
Snip..
I'm not at all sure.
vid
From: Lucy yong [mailto:lucy.y...@huawei.com]
Sent: Tuesday, March 11, 2014 11:41 AM
To: Black, David; draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org
Cc: nvo3@ietf.org
Subject: RE: needed data plane encap requirement in
draft-ietf-nvo3-dataplane-requirements
Snip.. [lucy1]
and more is
sponsibility to specify any needed
indication of whether an SFC header is present.
Thanks,
--David
From: Lucy yong [mailto:lucy.y...@huawei.com]
Sent: Tuesday, March 11, 2014 3:08 PM
To: Black, David; draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org
Cc: nvo3@ietf.org
Subject: RE: needed data
I agree that nvo3 data planes will carry some SFC traffic ...
... and some UDP traffic, and some RTP traffic and some HTTP traffic, etc.
Thanks,
--David
From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Lucy yong
Sent: Tuesday, March 11, 2014 3:21 PM
To: Black, David; draft-ietf-nvo3
.@huawei.com]
Sent: Wednesday, March 12, 2014 3:45 AM
To: Black, David; Lucy yong;
draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org
Cc: nvo3@ietf.org
Subject: 答复: needed data plane encap requirement in
draft-ietf-nvo3-dataplane-requirements
发件人: nvo3 [mailto:nvo3-boun...@ietf.org] 代表 Black, Dav
Guichard (jguichar) [mailto:jguic...@cisco.com]
Sent: Wednesday, March 12, 2014 11:08 AM
To: Black, David; Xuxiaohu;
draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org
Cc: nvo3@ietf.org
Subject: Re: [nvo3] needed data plane encap requirement in
draft-ietf-nvo3-dataplane-requirements
I have only just
Anton,
This doesn't look like a minor amendment. It looks like the NVE is being
split across the TS and the NVO3 infrastructure, with the encap/decap
processing moved into the TS.
When a VM is "attach[ed] directly to an overlay", the service provided
to that VM (encap/decap code is in the VM, or
think the focus on section 5.2 to
cover use of containers to provide mulitple TSs on a single physical
server is "digging in the wrong place" - this discussion probably belongs
in Section 4.2 on split-NVEs, or possibly a new 4.x section, as the
examples in that section move encap outboar
-Original Message-
From: IETF-Announce [mailto:ietf-announce-boun...@ietf.org] On Behalf Of IETF
Secretariat
Sent: Thursday, April 10, 2014 1:04 PM
To: IETF Announcement List
Cc: mls.i...@gmail.com; to...@ietf.org
Subject: New Non-WG Mailing List: Tofoo -- Discussion list for Tunneling ove
Subscription requests are being served - the list is new, so there's nothing in
the archive ... yet ;-).
Thanks,
--David
From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com]
Sent: Friday, April 11, 2014 11:14 AM
To: Black, David
Cc: nvo3@ietf.org
Subject: Re: [nvo3] FW: New Non-WG Mailing
-udp-encap:
http://www.ietf.org/proceedings/89/minutes/minutes-89-tsvwg
Thanks,
--David (*not* wearing tsvwg WG co-chair hat)
From: Linda Dunbar [mailto:linda.dun...@huawei.com]
Sent: Friday, April 11, 2014 11:21 AM
To: Black, David; sarik...@ieee.org
Cc: nvo3@ietf.org
Subject: RE: [nvo3] FW
ewpoint, I think the
architecture draft could use some text to discuss this scenario.
Thanks,
--David
From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Linda Dunbar
Sent: Wednesday, May 14, 2014 5:51 PM
To: Thomas Narten; nvo3@ietf.org; Black, David; Jon Hudson; Larry Kreeger;
LASSERRE, MAR
Linda,
Would removing the word "traditional" help? Nothing in the quoted text implies
termination of the overlay header.
Thanks,
--David
From: Linda Dunbar [mailto:linda.dun...@huawei.com]
Sent: Thursday, May 15, 2014 2:45 PM
To: Black, David; Thomas Narten; nvo3@ietf.org; Jon Hud
Thanks,
--David
> -Original Message-
> From: Anton Ivanov (antivano) [mailto:antiv...@cisco.com]
> Sent: Tuesday, May 13, 2014 2:35 AM
> To: Black, David
> Cc: nvo3@ietf.org
> Subject: Re: Proposal for some minor amendments of the arch draft
>
>
> Apologies for the
re.
Thanks,
--David
From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Linda Dunbar
Sent: Thursday, May 15, 2014 2:38 PM
To: Black, David; Thomas Narten; nvo3@ietf.org; Jon Hudson; Larry Kreeger;
LASSERRE, MARC (MARC)
Subject: [nvo3] What is Splict-NVE and the VLAN between Hypervisor and NV
dressed by
adapting the "If a
single NVE implementation is talking to multiple NVAs" paragraph above to add
to section 7.3
of the draft.
Comments?
Thanks,
--David
From: Black, David
Sent: Thursday, May 15, 2014 12:42 PM
To: Linda Dunbar; Thomas Narten; nvo3@ietf.org; Jon Hudson; Larry
vid
From: Linda Dunbar [mailto:linda.dun...@huawei.com]
Sent: Monday, May 19, 2014 2:38 PM
To: Black, David; nvo3@ietf.org
Subject: RE: NVA structure - Arch draft section 7.3
David,
To get proper answers from the community, can you classify:
- For [A] below, does the single logical
After my WGLC comments on the framework draft, I "won" the action item
to seek Transport Area review of the draft's path MTU text. The results
of that review are that the current text on "Classical ICMP-based MTU Path
Discovery" looks reasonable, but the text on "Extended Path MTU Discovery
techni
th to its destination.
Thanks,
--David
> -Original Message-
> From: LASSERRE, MARC (MARC) [mailto:marc.lasse...@alcatel-lucent.com]
> Sent: Wednesday, May 21, 2014 7:46 AM
> To: Black, David; nvo3@ietf.org
> Subject: RE: [nvo3] Framework draft - Section 4.2.4 - path MTU te
Turning to the dataplane requirements draft, here's proposed elaboration
text for the path MTU material in section 3.5 (no change to the second and
third bullet items - they're included for completeness):
OLD
Either of the following options MUST be supported:
o Classical ICMP
emnt,
where would that implementation be located?
Thanks,
--David
> -Original Message-
> From: LASSERRE, MARC (MARC) [mailto:marc.lasse...@alcatel-lucent.com]
> Sent: Thursday, May 22, 2014 4:12 AM
> To: Black, David; nvo3@ietf.org
> Subject: RE: Dataplane requirements draft -
Marc, More inline ... Thanks, --David
> -Original Message-
> From: LASSERRE, MARC (MARC) [mailto:marc.lasse...@alcatel-lucent.com]
> Sent: Friday, May 23, 2014 3:49 AM
> To: Black, David; nvo3@ietf.org
> Subject: RE: Dataplane requirements draft - section 3.5 - path MTU
Trying again, here's a second attempt at proposing elaboration text
for the path MTU material in section 3.5 of the dataplane requirements
draft.
This is getting longer because the original text mixed dataplane
techniques with Tenant System techniques. See below the text for a
list of requirement
> Coincidentally, we are also polling for knowledge of any IPR that
> applies to this draft, to ensure that IPR has been disclosed in
> compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for
> more details).
>
> If you are listed as a document author or contributor please respond
>
Hi Zu,
> I have no objections to this adaptation. But I really prefer authors can
> make a clarifications on the scope of the draft. The terminologies used in the
> draft are not in line with the framework draft.
Yes - this is the initial merge of text from three drafts written by at least
Barry,
> Does that mean that the working group would be willing to pull the
> architecture document back out of the RFC Editor queue for rework,
> should it come to that?
There appears to be some confusion here:
The nvo3 architecture draft is not in RFC Editor queue, it's still with the WG:
http
I'd be concerned that this could lead to a *long* discussion of
alternative implementation approaches in this requirements draft.
Thanks,
--David
From: ghanw...@gmail.com [mailto:ghanw...@gmail.com] On Behalf Of Anoop Ghanwani
Sent: Tuesday, June 03, 2014 12:20 PM
To: Black, David
Cc:
Three quick questions:
(1) Why is this draft intended as standards track? What protocol or standard
does it specify?
Both the problem statement and framework drafts are Informational.
(2) What is the nature of the use of RFC 2119 terms (e.g., "MUST") in this
document?
(3) Why are the
uot;an exercise to the reader" has a
rather poor track record in the IETF.
Thanks,
--David
> -Original Message-
> From: Yakov Rekhter [mailto:ya...@juniper.net]
> Sent: Wednesday, September 17, 2014 9:03 AM
> To: Black, David
> Cc: Benson Schliesser; nvo3@ietf.or
I have significant concerns about the contents of this draft (beyond
the missing security considerations), and don't think it's ready for
the IESG.
-- Section 2.1 Terminology
In this document the term "Top of Rack Switch (ToR)" is used to refer
to a switch in a data center that is connected
ds are being used to state
protocol design requirements, not protocol implementation/behavior requirements.
Thanks,
--David
> -Original Message-
> From: Yakov Rekhter [mailto:ya...@juniper.net]
> Sent: Wednesday, September 17, 2014 9:03 AM
> To: Black, David
> Cc: Benson
these keywords in
standards track documents to express requirements for protocol implementation,
deployment and/or usage.
Thanks,
--David
> -Original Message-
> From: Yakov Rekhter [mailto:ya...@juniper.net]
> Sent: Wednesday, September 17, 2014 5:12 PM
> To: Black, David
> Cc: n
Inline at [David-2].
Thanks,
--David
From: Linda Dunbar [mailto:linda.dun...@huawei.com]
Sent: Thursday, September 18, 2014 5:09 PM
To: Black, David; nvo3@ietf.org
Cc: Yakov Rekhter
Subject: RE: draft-ietf-nvo3-vm-mobility-issues - Technical WG LC comments
David,
Thank you very much for the
Butting in w/one comment ...
> [Linda-2] When VMs in a single VN are spread across many different DCBRs, all
> DCBRs have to announce their directly
> VMs in order to achieve optimal routing. This approach can dramatically
> increase the number of routes on routers in the wide area network.
Thanks,
--David
From: Linda Dunbar [mailto:linda.dun...@huawei.com]
Sent: Monday, September 22, 2014 11:32 AM
To: Black, David; Larry Kreeger (kreeger); nvo3@ietf.org
Subject: RE: [nvo3] WG Last Call on draft-ietf-nvo3-vm-mobility-issues
David,
See comment in line below
From: Black, David [
id
From: Linda Dunbar [mailto:linda.dun...@huawei.com]
Sent: Monday, September 22, 2014 11:59 AM
To: Black, David; Larry Kreeger (kreeger); nvo3@ietf.org
Subject: RE: [nvo3] WG Last Call on draft-ietf-nvo3-vm-mobility-issues
David,
I see what you mean now. How about this updated wording:
In or
tware network
switches in hypervisors (all of which the current draft assumes as I understand
it), that could be considered as a solution draft, but it would not be a
general (solution-independent) VM issues draft.
Thanks,
--David
From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Linda Dun
Elaboration on this:
> that could be considered as a solution draft, but it would not be a general
> (solution-independent) VM issues draft.
"that could be considered" is poorly phrased - "it may be a reasonable" would
have been better - sorry :-(.
Thanks,
--Davi
:linda.dun...@huawei.com]
Sent: Tuesday, September 23, 2014 6:37 PM
To: Black, David; Larry Kreeger (kreeger); nvo3@ietf.org
Subject: RE: [nvo3] WG Last Call on draft-ietf-nvo3-vm-mobility-issues
David,
Is your "hot potato" routing referring to outbound traffic going through a
different DC Gate
ribed in the problem statement draft, the vm-issues draft looks
like a solutions draft.
Thanks,
--David
From: Linda Dunbar [mailto:linda.dun...@huawei.com]
Sent: Tuesday, September 23, 2014 6:54 PM
To: Black, David; Larry Kreeger (kreeger); nvo3@ietf.org
Subject: RE: [nvo3] WG Last Call on dr
reserve
anything whose state was solely on the hardware that's now a
smoking pile of parts.
Thanks,
--David
> -Original Message-
> From: Tom Herbert [mailto:therb...@google.com]
> Sent: Friday, October 03, 2014 9:04 PM
> To: Linda Dunbar
> Cc: nvo3@ietf.
Dunbar; Tom Herbert
Cc: Black, David; nvo3@ietf.org
Subject: AW: [nvo3] Poll for a better name for
draft-merged-nvo3-vm-mobility-scheme-00.txt
What about:
„overlay network endpoint mobility framework“
Which leaves open if L2-endpoint ID or L3 endpoint ID or both IDs require
mobility, and
Sri,
> On 10/7/14 8:32 PM, "Tom Herbert" wrote:
>
> >You've reverted to posing the networking virtualization problem in
> >terms of virtual machines which leads to a use case specific
> >solution-- this is exactly the reason I suggested to not use the term.
> >The general problem is not (virtual
---
> From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
> Sent: Wednesday, October 08, 2014 12:27 AM
> To: Black, David
> Cc: nvo3@ietf.org
> Subject: Re: [nvo3] Poll for a better name for draft-merged-nvo3-vm-mobility-
> scheme-00.txt
>
> David,
>
> Ok. Fair
> The architecture document now became an RFC, it is RFC 7365.
> Which next version will make this clearer?
That would be the framework document (draft-ietf-nvo3-framework).
There should be a new version of the architecture document
(draft-ietf-nvo3-arch) before the Honolulu draft cutoff.
Thanks
[+nvo3 list]
Well, item 3 is definitely a mistake. We went over that point at length during
one of the tsvwg sessions in London in the context of another draft, so it's
disappointing to see that mistake showing up again so soon (see Section 3 of
RFC 2474 to understand why it's a mistake).
Thanks
> I suggest carefully reviewing RFC 2474 and RFC 2475, and the
> specific descriptions of per-hop behaviours in RFC 2597 and RFC
> 3246. Also it is worth reviewing RFC 4594,
> draft-geib-tsvwg-diffserv-intercon, and the work of the AQM WG
> (http://datatracker.ietf.org/wg/aqm/charter/). Truly there
I said effectively the same thing at the mike in the nvo3 meeting - this draft
is not using diffserv - it's inventing something new, and that's a bad idea.
Thanks, --David +++Sent from Blackberry
- Original Message -
From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
Sent: Mond
Another +1, and please see RFC 2983, which is relevant to the DiffServ aspects
here.
Thanks,
--David
From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Larry Kreeger (kreeger)
Sent: Wednesday, November 12, 2014 3:27 PM
To: Osama Zia; Benson Schliesser; sarik...@ieee.org
Cc: nvo3@ietf.org; Di
Thanks,
--David
From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com]
Sent: Wednesday, November 12, 2014 4:03 PM
To: Black, David
Cc: nvo3@ietf.org; draft-xia-nvo3-vxlan-qosmark...@tools.ietf.org
Subject: Re: [nvo3] I-D Action: draft-xia-nvo3-vxlan-qosmarking-01.txt
On Wed, Nov 12, 2014 at 2:43 P
that and don’t modify VXLAN:
> This I think makes sense. We can change the marking place and move it to IP
> or Ethernet header.
Thanks,
--David
From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com]
Sent: Wednesday, November 12, 2014 8:58 PM
To: Black, David
Cc: nvo3@ietf.org; draft
A few clarifications, most of which are probably courtesy of the difficulty in
taking notes on a free flowing discussion:
OLD
GUE Encap (Tom Herbert):
Debate begins on checksums
David Black: Update on checksum for IPv6:
The checksum should be MUST USE FU
Hmm, in http://www.ietf.org/mail-archive/web/nvo3/current/msg04211.html,
one of our WG chairs wrote:
At this point, I maintain my view that the NVO3 consensus is: there is no QoS
gap that needs to be addressed in the overlap encap layer.
If NVO3 is not interested in this draft, what’s the purpose
Carter,
> Maybe you should go back further. How about say RFC 985, 1009, 1716, and
> 1812.
> Four RFCs devoted solely to trying to get the requirements for routers down.
> At a time when some of the best work was done.
Perhaps you should think more about the types and contents of requirements
d
achieving that goal,
but the focus should be on the goal, not the tools used to achieve it, IMHO.
Thanks,
--David (chair or past chair of 5 IETF WGs)
From: Carter Bullard [mailto:car...@qosient.com]
Sent: Saturday, February 07, 2015 1:15 PM
To: Black, David
Cc: nvo3@ietf.org
Subject: Re: [nvo3
Hi Mingui,
Thanks for the careful read. Comments inline.
--David
> -Original Message-
> From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Mingui Zhang
> Sent: Sunday, February 15, 2015 4:43 AM
> To: draft-ietf-nvo3-a...@tools.ietf.org
> Cc: nvo3@ietf.org
> Subject: [nvo3] Section 4
Inline ... --David
> -Original Message-
> From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Mingui Zhang
> Sent: Monday, February 16, 2015 9:00 PM
> To: Black, David; draft-ietf-nvo3-a...@tools.ietf.org
> Cc: nvo3@ietf.org
> Subject: Re: [nvo3] Section 4.4 Multi-Ho
cture draft, so (IMHO) the answer is "yes, both" and the
network
perspective is definitely important.
Thanks,
--David
> -Original Message-
> From: Mingui Zhang [mailto:zhangmin...@huawei.com]
> Sent: Monday, February 16, 2015 9:47 PM
> To: Black, David; draft-ietf-nvo3-a...
1 - 100 of 145 matches
Mail list logo
