[Gen-art] Gen-ART Last Call review of draft-ietf-l3sm-l3vpn-service-model-16

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 04 October 2016 02:54 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A43A1295AC; Mon, 3 Oct 2016 19:54:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0atn_ESUcJW5; Mon, 3 Oct 2016 19:54:01 -0700 (PDT)
Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F723127078; Mon, 3 Oct 2016 19:53:58 -0700 (PDT)
Received: by mail-pa0-x233.google.com with SMTP id cd13so64092020pac.0; Mon, 03 Oct 2016 19:53:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:organization:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=hj3qFcIscgb5AmKGCPPTY4ZTZ7GNZwunOua7mR/Hpxg=; b=jV7pOXEZzowDrhmd41+VVG64EI1dRZ2mkXJ3zuB/mX396up8F55uC/XZdU/43iLTRd irOIWV1CfNhWTtPF8qCIVGmJcYRPjo4uMwRjVr6pUG7QEnFiNTlo7SOvCtRxFjSvkIqm OCitPGpB+wHrFecIHAVmtm6Ak7j5ZF+DBru5c+DW/VOMHzKWjlbrGZrycxfpD1s9N+Y8 YCtNWfKYI1Vb+Ubwl0FvaFPiwfoTCMfUgC3bpr2Pn9wgFMRG8Nxe0ASPko9CpbxDf0zP IokTh0nSA6oW/ga7Q3iM5MLmM7b9hCjXHzcz8APA+74h0M/9hFxkKH+OmvEDCXFbNbaI hCrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=hj3qFcIscgb5AmKGCPPTY4ZTZ7GNZwunOua7mR/Hpxg=; b=Te0mTP0/iz9BMdX8OFdLnf1U9fUhpzDa2Ffmn5vG71xf9CEicI5jMoPODozAzP7ckG FrNgCHZX5yMp3U1v5EY7vCWB1xngRAbbfuAWA/VSn4sCbhX7DGSNJgEPtvGvBvq62lDS ysLNH21/2H8sgrKzy7Y/LN5cOwSZJke3e6XgzuWViMhvAuTYCLTU8ikYqJOICO4KgYuR HTRrbgicXWL50gZjtXswvV480Hnfr74i+Ygc0thq7iG8rfjFq3ekplzktnpj3D4geWYU lqswdqpkwmHhyhaB5bUbN2MUaBqaVD4N5syt8XW7R8yYvpgltTGgc3NAki8qTkJlgXD4 Qglw==
X-Gm-Message-State: AA6/9RkIe7E1bhs4SeSa6YwVccFADzktL29Yn37M6x+3e4LwJat1tZKK3AehEUDyqfyRfQ==
X-Received: by 10.66.27.165 with SMTP id u5mr1852109pag.200.1475549637423; Mon, 03 Oct 2016 19:53:57 -0700 (PDT)
Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id n88sm41264084pfk.56.2016.10.03.19.53.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Oct 2016 19:53:56 -0700 (PDT)
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
To: draft-ietf-l3sm-l3vpn-service-model.all@ietf.org, General Area Review Team <gen-art@ietf.org>
Organization: University of Auckland
Message-ID: <434b44e6-7168-81ce-beed-cc435d56e516@gmail.com>
Date: Tue, 04 Oct 2016 15:53:55 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/0XxE-CcPlOL6TyQBqkZEau-uO14>
Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-l3sm-l3vpn-service-model-16
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Oct 2016 02:54:02 -0000

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-l3sm-l3vpn-service-model-16.txt
Reviewer: Brian Carpenter
Review Date: 2016-10-04
IETF LC End Date: 2016-10-11
IESG Telechat date:

Summary: Ready with issues
--------

Comments:
---------

I assume that the minor fixes mentioned in the shepherd's writeup will
be done. I have not checked the details of the yang.

Maror Issues:
-------------

> 5.3.2.2.1.  IP addressing
...
>    o  slaac : enables stateless address autoconfiguration ([RFC4862]).
>      This is applicable only for IPv6.

You can't stop there. Within SLAAC, privacy addresses (RFC4941) may or
may not be allowed by an operator, and opaque addresses (RFC7217)
may be required. So two more Boolean properties are needed.

Also, DHCPv6, SLAAC and static addresses may coexist; they are not
mutually exclusive. I'm not sure if your model allows that.

> 5.12.2.1.  QoS classification

This is too simple. At least, it needs to be able to
handle a port range, not just a single port number.

> 5.12.2.2.  QoS profile

rate-limit, priority-level, and guaranteed-bw-percent may be OK for
MPLS, but they do not capture the needed parameters for differentiated
services. I could write an essay here, but I think the best starting
point is draft-ietf-tsvwg-diffserv-intercon.

Also, I don't understand how you can separate this issue from
Section 5.13.2. Transport constraints, where you do discuss parameters
relevant to diffserv. The whole point about diffserv-intercon is
to quantify and standardise the constraints at interconnections.

I recommend having TSVWG review sections 5.12 and 5.13.

Minor Issues:
-------------

> 5.2.2.  Cloud access
...
>   If NAT is required to access to the cloud, the nat-enabled leaf MUST
>   be set to true.
...
Although NAT is mentioned, I saw no support for NPTv6 (RFC6296). I also
saw no mention of private or shared address space (RFC1918, RFC4193 or RFC6598).

...
> How the restrictions will be configured on network elements is out of
> scope of this document and will be specific to each deployment.

"Each deployment"? I would have thought that this might be uniform for
a given suite of software+hardware implementing the model, or even that
standard practice might emerge with experience. So I suggest to truncate
this sentence:
 How the restrictions will be configured on network elements is out of
 scope of this document.

>   <vpn-svc>
>       <vpn-id>ZKITYHJ054687</vpn-id>
...

Suddenly we have two chunks of XML with no explanation. Why are we using XML?
Should these be captioned as figures? Some text explaining the usage of XML is
missing. Since there are XML configuration fragments in many places later in
the document, this could be in Section 1.1. Terminology.

> 5.3.2.2.1.  IP addressing
>
>   IP subnet can be configured for either transport protocols.  For a
>   dual stack connection, two subnets will be provided, one for each
>   transport layer.

Surely you don't mean 'transport layer'? And I think you mean 'prefix'
rather than 'subnet'.
...
>    o  provider-dhcp : the provider will provide DHCP service for
>      customer equipments, this is applicable to both IPv4 and IPv6
>      addressing.

I find it confusing that you use provider-dhcp for both DHCP and
DHCPv6. They are different protocols. I understand that the usage
is inside container ipv6 {} or container ipv4 {} but it's still
confusing.

> 5.3.2.3.  Inheritance of parameters between site and site-network-access

This section raises more questions than it answers - especially
questions about how the orchestrator works. I suggest adding
a comment along the lines of "out of scope... requires further study."

> 5.6.6.1.  Multihoming
>
>   The customer wants to create a multihomed site.

How do you express, for IPv6, that the customer has multiple IPv6
prefixes, one per ISP? (RFC7157 situation) This is not clear
in section 5.3.2. Site network accesses.

> 5.9.  Security

Don't you want a placeholder for firewall policy elements?

> 5.11.  Routing protocols
>
>   Routing-protocol defines which routing protocol must be activated
>   between the provider and the customer router.  The current model
>   support : bgp, rip, ospf, static, direct, vrrp.

As with DHCP, I find it confusing. There are two BGPs, two RIPs,
and two OSPFs, and using the same name for IPv4 and IPv6 seems wrong.
(VRRPv3 seems to be the same for both IP versions, but do you need
to distinguish it from VRRPv2?).

> 9.  Security Considerations

It would be useful to refer here to Section 5.9. Security.

Nits:
-----

Watch for undefined jargon (VRF is an example).

There are a lot of minor grammatical or typographical errors that make
the text more difficult to read. Quite a lot of work for the RFC
editor. Two examples:

> 5.2.1.2.  Any to any
...
> In the any to any VPN service topology, all VPN sites can discuss
> between each other without any restriction.

The word 'discuss' is badly chosen; I suggest 'communicate' everywhere:

 In the any-to-any VPN service topology, all VPN sites can communicate
 with each other without any restriction.

> It is expected that the
> management system that receives a any to any IPVPN service request
> through this model, needs to assign and then configure the VRF and
> route-targets on the appropriate PEs.

should be

 It is expected that the
 management system that receives an any-to-any IPVPN service request
 through this model needs to assign and then configure the VRF and
 route-targets on the appropriate PEs.