Subject: [nvo3] WG Last Call for draft-ietf-nvo3-dataplane-requirements-02.txt

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Fri, 7 Feb 2014 09:49:50 +0000

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

---

From: "LASSERRE, MARC (MARC)" <[email-masked]>
Date: Fri, 7 Feb 2014 12:02:01 +0000

I'm not aware of any IPR on this draft.

Marc

________________________________
From: nvo3 [mailto:[email-masked]] On Behalf Of Bocci, Matthew (Matthew)
Sent: Friday, February 07, 2014 10:50 AM
To: [email-masked]
Cc: [email-masked]
Subject: [nvo3] WG Last Call for draft-ietf-nvo3-dataplane-requirements-02.txt

Best regards,

Matthew and Benson

---

From: Eric Gray <[email-masked]>
Date: Mon, 10 Feb 2014 18:17:40 +0000

I have reviewed this draft in detail and find that it is ready to forward to the
IESG for publication.

--
Eric

From: nvo3 [mailto:[email-masked]] On Behalf Of Bocci, Matthew (Matthew)
Sent: Friday, February 07, 2014 4:50 AM
To: [email-masked]
Cc: [email-masked]
Subject: [nvo3] WG Last Call for draft-ietf-nvo3-dataplane-requirements-02.txt

Best regards,

Matthew and Benson

---

From: Thomas Morin <[email-masked]>
Date: Thu, 13 Feb 2014 15:36:46 +0100

Hi Matthew,

Bocci, Matthew :
> 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). 
> [...]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.

I am not aware of any undisclosed IPR applying to 
draft-ietf-nvo3-dataplane-requirements.

Best,

-Thomas

---

From: "Black, David" <[email-masked]>
Date: Fri, 28 Feb 2014 12:57:54 -0500

> 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

Best regards,

Matthew and Benson