> 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 IETF meeting tends to run into overload caused by the
flurry of last-minute draft submissions):
Issues:
-- Section 1.1
This draft is intended to be an Informational RFC, to which RFC 2119 keywords
are not applicable by default. Add some text here explaining how those terms
are used (and to be interpreted here). I believe that these are requirements
on dataplane technologies used in NVO3 solutions, or something like that.
-- Section 3.2.1
By default, data plane learning MUST be used to populate forwarding
tables. As frames arrive from VAPs or from overlay tunnels, standard
MAC learning procedures are used: The tenant system source MAC
address is learned against the VAP or the NVO3 tunneling
encapsulation source address on which the frame arrived. This
implies that unknown unicast traffic will be flooded (i.e.
broadcast)
I'm fairly certain that that "MUST" is wrong, and I don't think the "By
default" language is enough to weaken it.
When using multicast, the NVE MUST have one or more multicast trees
that can be used by local VNIs for flooding to NVEs belonging to the
same VN.
This should specify whether those are underlay or overlay multicast trees, and
what type of multicast. I think these are underlay IP multicast trees
because the next paragraph discusses tenant multicast. The same concern applies
to the last paragraph in Section 3.2.2 .
-- Section 3.3.1.1
The egress NVE uses this field to determine the appropriate virtual
network context in which to process the packet. This field MAY be an
explicit, unique (to the administrative domain) virtual network
identifier (VNID) or MAY express the necessary context information
in other ways (e.g. a locally significant identifier).
The "locally significant identifier" is about MPLS, so MPLS should be mentioned
as an example.
-- Section 3.3.1.2
Please expand and define the CoS and QoS acronyms.
-- Section 3.3.2
This section describes the underlay tunneling requirements. From an
encapsulation perspective, IPv4 or IPv6 MUST be supported, both IPv4
and IPv6 SHOULD be supported, MPLS tunneling MAY be supported.
I'm not sure whether I understand the mention of MPLS here. I think an
explanation of what "MPLS tunneling" is and its relationship to IPv4 and/or
IPv6 would help.
-- Section 3.3.2.1
Thus, in order to perform fine-grained load-balancing over LAG and
ECMP paths in the underlying network, the encapsulation MUST result
in sufficient entropy to exercise all paths through several LAG/ECMP
hops.
I think the "MUST" is inappropriate here, especially in light of this text in
the next paragraph: "If the overlay protocol does not support the necessary
entropy information ..."
So, I would change:
"MUST result in" -> "needs to present"
-- Section 3.4
NVO3 services MUST interoperate with current VPN and Internet
services.
That seems vague by itself and needs more explanation. How can one determine
whether the NVO3 service does interoperate ... ??
-- Section 3.4.1
Tenant sites may be already interconnected using one of the existing
VPN services and technologies (VPLS or IP VPN). If a new NVO3
encapsulation is used, a VPN GW is required to forward traffic
between NVO3 and VPN domains. Translation of encapsulations MAY be
required. Internet connected Tenants require translation from NVO3
encapsulation to IP in the NVO3 gateway. The translation function
SHOULD minimize provisioning touches.
Either delete or expand and explain "Translation of encapsulations MAY be
required."
-- Section 3.4.2
The need to configure the entire LAG bundle as operationally down when one of
the component links fails seems to be much more general (i.e., not NVO3-
specific). Is there a reference that could be cited for this more general
operational recommendation?
Also, last sentence in first paragraph:
Thus, there are likely no
additional requirements on NVO3 solutions to accommodate this type
of underlying network configuration and administration.
It looks like the word "likely" makes this sentence content-free - it should
be rephrased to be more explicit.
-- Section 3.4.2.2
Hmm - we should make sure that this triangular routing topic is addressed
consistently across all the NVO3 drafts, and that one draft has primary
responsibility. I suspect that this topic does not belong in this draft
because it's almost entirely in the control and management planes and
hence out of scope for this draft.
-- Section 3.5
o Classical ICMP-based MTU Path Discovery [RFC1191] [RFC1981] or
Extended MTU Path Discovery techniques such as defined in
[RFC4821]
That needs to be run by the Transport Area. Would one of the authors please
send a note to either the tsvwg or tsv-area lists with at least this text
to figure out what it should say?
-- Sections 3.6 and 3.7
I think the text in both of these sections should be moved to the architecture
draft ... now that we have one ;-).
Nits:
-- Section 2
Note
that additional criteria such as 802.1p and/or DSCP markings might
be used to select an appropriate tunnel or local VAP destination.
"802.1p" -> "Ethernet 802.1p priorities"
-- Section 3.2.2
Thus, the default behavior MUST be the TTL pipe model
where the overlay network looks like one hop to the sending NVE.
Configuration of a "uniform" TTL model where the outer tunnel TTL is
set equal to the inner TTL on ingress NVE and the inner TTL is set
to the outer TTL value on egress MAY be supported.
At the risk of "blowing my own horn", I would also cite RFC 2983 here
as providing more information on the uniform and pipe models.
-- Section 3.3.2.3
User-configurable knobs MUST be provided to select ...
Uhm, "knobs" is not a good word, find a better, more specific term.
-- Section 3.4 and 3.4.1
Expand GW acronym on first use in Section 3.4 and in the title of Section 3.4.1
.
-- Section 3.4.1.3
A gateway device, e.g. a ToR, is required to translate
the NVO3 to Ethernet VLAN encapsulation.
"ToR" -> "ToR switch"
-- Section 3.8.1
Explain what a VSwitch is, please.
Thanks,
--David
From: nvo3 [mailto:[email protected]] On Behalf Of Bocci, Matthew (Matthew)
Sent: Friday, February 07, 2014 4:50 AM
To: [email protected]
Cc: [email protected]
Subject: [nvo3] WG Last Call for draft-ietf-nvo3-dataplane-requirements-02.txt
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.
Coincidentally, we are also polling for knowledge of 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). To date, there have been no IPR declarations on this draft.
If you are listed as a document author or contributor please respond to this
email whether or not you are aware of any additional IPR. The draft will not be
forwarded to the IESG until a response has been received from each author and
contributor.
If you are on the PWE3 WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any IPR
that has not yet been disclosed in conformance with IETF rules.
This working group last call will close on Friday 21st February 2014.
Best regards,
Matthew and Benson
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
