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

From: Brian E Carpenter <[email-masked]>
Date: Tue, 4 Oct 2016 15:53:55 +1300

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.

---

From: <[email-masked]>
Date: Thu, 6 Oct 2016 08:46:46 +0000

Hi Brian,

Please find some comments inline

Best Regards,

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Tuesday, October 04, 2016 04:54
To: [email-masked]; General Area Review Team
Subject: Gen-ART Last Call review of draft-ietf-l3sm-l3vpn-service-model-16

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>.

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:
-------------

...
>      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.

[SLI] We did not wanted to add all the possible options, but the most current ones. New scenarios can always been added through augmentations.

> 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.

[SLI] What we need to identify is a particular application running on a specific port, we are not defining a router configuration framework here.

> 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.
[SLI] Again, we captured the most used parameters by service providers. The goal is not to provide all. But If you see a specific parameter that is widely used and not implemented here, feel free to point it.

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.
[SLI] We discussed this point when we designed the model, and it was simpler to express the transport constraint at vpn level than trying to implement them per site. That's why it was decoupled.

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

...
>   If NAT is required to access to the cloud, the nat-enabled leaf MUST
...
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).

[SLI] NAT is a generic term, it only mentions that address translation is needed but does not tell what technology will be used. Nothing prevents SP to implement NPTv6.
The non working point is that the customer-nat-address is an IPv4 type which is a mistake ... it could be IPv6 also.

...
> 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.

[SLI] Fixed

...

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.

[SLI] I added a sentence in terminology. XML is the best way to provide examples of what will be used in Netconf or Restconf. JSON is also possible but less practical to write.

[SLI] It is fixed.

>      customer equipments, this is applicable to both IPv4 and IPv6

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.

[SLI] I changed the text to be more clear.

> 5.3.2.3.  Inheritance of parameters between site and 

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."

>   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.

[SLI] Customer can request SP to propagate its prefixes through dynamic routing protocols or static routing. The customer can do what he wants regarding how it manages its routing.

[SLI] This was here before but removed as considered out of scope by the WG.
Security container can be augmented if necessary.

>   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?).
[SLI] This is really device configuration oriented comment. I think the customer does not really care that we need to activate a special version of the protocol.
For BGP, it's a single BGP not another protocol :) (just a new AF carried)

Nits:
-----

...

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

[SLI] Thanks it's fixed.

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.

 [SLI] Fixed

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 7 Oct 2016 08:58:13 +1300

Stephane,

Thanks for the response and the proposed updates. Some follow-up on a few points:

On 06/10/2016 21:46, [email-masked] wrote:
...
> [SLI] We did not wanted to add all the possible options, but the most current ones. New scenarios can always been added through augmentations.

OK. I think a general note in the Introduction saying that would be very useful.

> [SLI] What we need to identify is a particular application running on a specific port, we are not defining a router configuration framework here.

No, but there are applications that run on multiple ports and it's a bit clumsy
to require a separate classifier for each port.

> [SLI] Again, we captured the most used parameters by service providers. The goal is not to provide all. But If you see a specific parameter that is widely used and not implemented here, feel free t…

Diffserv DSCP values are widely used. I suggested diffserv-intercon because it proposes
a specific subset useful at network boundaries, but there is also RFC 5127 and related
work for WebRTC (https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos).

> [SLI] We discussed this point when we designed the model, and it was simpler to express the transport constraint at vpn level than trying to implement them per site. That's why it was decoupled.

OK, but you still need a rich set of QoS parameters at that level, and shouldn't
it be the same set?

> I recommend having TSVWG review sections 5.12 and 5.13.

No, but the IETF strongly recommends against NAT66, while having specs for NAT44, NAT64 and NPTv6.
Hiding these distinctions under the buzzword "NAT" is misleading.

> The non working point is that the customer-nat-address is an IPv4 type which is a mistake ... it could be IPv6 also.

But it's not a NAT address, it's an NPTv6 prefix. A different animal.

...

Regards
    Brian

---

From: <[email-masked]>
Date: Fri, 7 Oct 2016 07:46:56 +0000

Hi Brian,

More inline.

Brgds,

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Thursday, October 06, 2016 21:58
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]; General Area Review Team
Subject: Re: Gen-ART Last Call review of draft-ietf-l3sm-l3vpn-service-model-16

Stephane,

[SLI2] I added a note in a new "feature and augmentation" paragraph that I already created to accommodate another comment.

> [SLI] What we need to identify is a particular application running on a specific port, we are not defining a router configuration framework here.

No, but there are applications that run on multiple ports and it's a bit clumsy to require a separate classifier for each port.

[SLI2] I'm adding it.

> [SLI] Again, we captured the most used parameters by service providers. The goal is not to provide all. But If you see a specific parameter that is widely used and not implemented here, feel free t…

Diffserv DSCP values are widely used. I suggested diffserv-intercon because it proposes a specific subset useful at network boundaries, but there is also RFC 5127 and related work for WebRTC (https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos).

[SLI2] The current model supports classification based on generic DSCP values. Isn't it enough ?
We can define DiffServ class matching as well with enumerations if really necessary, but I'm now wondering if we can not reuse any existing generic packet matching model instead of recreating it (as ours becomes bigger and bigger), the issue I see is that it would come from a device configuration model.  

> [SLI] We discussed this point when we designed the model, and it was simpler to express the transport constraint at vpn level than trying to implement them per site. That's why it was decoupled.

OK, but you still need a rich set of QoS parameters at that level, and shouldn't it be the same set?

[SLI2] Some of them are equivalent for example low latency/jitter, some are different as for diversity.
I understand your comment, but I think we need a larger discussion on this topic and this may imply a full remodeling of this part. Let me post a thread on L3SM list.

[SLI2] That was done for simplification purpose, could you list the different options that you would like to see in this model ? To be honest, I'm not fully aware of all the necessary combinations, so help would be required.

...

Regards
    Brian

---

From: Benoit Claise <[email-masked]>
Date: Fri, 7 Oct 2016 11:14:20 +0200

Hi Brian, all,

[including the L3SM mailing list]

It will be a very useful addition to add a few words about : "We did not 
wanted to add all the possible options, but the most current ones. New 
scenarios can always been added through augmentations.", as mentioned by 
Stephane.

In terms of QoS, I believe that this service model already contains too 
much details already
As I wrote in my AD review, 
https://mailarchive.ietf.org/arch/msg/l3sm/0JUa85ioK_mtw2GtRM_FKP53guQ:

    . QoS Classification
    I see match statements like in the ACL YANG model in NETMOD, I see QoS
    parameters, and I wonder if it makes sense to have so many details in a
    service model. Are you really sure that you don't have too much in that
    area? Don't you need just need a very generic mechanism such as the
    tc-latency, tc-jitter, tc-bandwidth, tc-path-diversity, and
    tc-site-diversity for gold, silver and bronze?

Indeed, we should pay attention that this Service YANG model doesn't 
turn into a full device configuration model.
 From the charter:

    It needs to be clearly understood that this L3VPN service model is
    not an L3VPN configuration model. That is, it does not provide
    details for configuring network elements or protocols. Instead it
    contains the characteristics of the service, as discussed between
    the operators and their customers. A separate process is responsible
    for mapping this service model onto the protocols and network
    elements depending on how the network operator chooses to realise
    the service.

We should focus on the most common options, from an operator point of 
view. Otherwise, we could be adding features forever.
IMO, it's time to declare victory on this service YANG model.

Regards, Benoit

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 8 Oct 2016 09:03:27 +1300

> turn into a full device configuration model.

Understood. I guess my concern is that people may make false assumptions
from the service model about what it implies for configuration. Thus
"NAT" might falsely imply "NAT66", and no doubt there are other examples.

I will think about this before replying to Stephane again.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 8 Oct 2016 13:07:59 +1300

[N.B. I have added the l3sm list but I am not subscribed]

On 07/10/2016 20:46, [email-masked] wrote:
...

...
> [SLI2] The current model supports classification based on generic DSCP values. Isn't it enough ?

Yes, I missed that. I agree, that seems the right level for this model. However,
this raises one detail. The model says:

            |  |  |     |  |  +--rw match-flow
            |  |  |     |  |     +--rw dscp?              uint8
            |  |  |     |  |     +--rw tos?               uint8

but tos was obsoleted when dscp was defined by RFC 2474. I don't think
you should include tos. You don't mention ECN, which are the two bits
from tos that are not included in dscp. Those bits are no good for flow
matching because they are variable.  If an operator tries to use the 8 TOS
bits for flow matching but a user supports ECN, the matching will not work
consistently.

...
> I understand your comment, but I think we need a larger discussion on this topic and this may imply a full remodeling of this part. Let me post a thread on L3SM list.

OK.

...
> [SLI2] That was done for simplification purpose, could you list the different options that you would like to see in this model ? To be honest, I'm not fully aware of all the necessary combinations,…

I think the three cases I mentioned are sufficient for a start, but (getting back to
Benoit's point) we could quickly get into configuration detail. So we have

NAT44 - which requires an outside ipv4-address.

NAT64 (for an IPv6-only network requiring IPv4 access) - which requires
an outside ipv4-address and an inside WKP (well-known ipv6-prefix).
(NAT64 implies DNS64, but I don't think that is needed in the model.)

NPTv6 - which requires an outside ipv6-prefix.

(There are also possible NAT444 and XLAT464 cases with added complexity,
but let's leave them for now.)

So the three cases are different. I think you would need something like

      |     |     +--rw nat44-enabled?            boolean
      |     |     +--rw customer-nat44-address?   inet:ipv4-address
      |     |     +--rw nat64-enabled?            boolean
      |     |     +--rw customer-nat64-address?   inet:ipv4-address
      |     |     +--rw customer-nat64-wkp?       inet:ipv6-prefix
      |     |     +--rw nptv6-enabled?            boolean
      |     |     +--rw customer-nptv6-prefix?    inet:ipv6-prefix

If you go that way it needs a quick check on the BEHAVE list, where
NAT expertise exists.

Regards
   Brian

---

From: <[email-masked]>
Date: Mon, 10 Oct 2016 08:29:11 +0000

For NAT, I would like to hear opinion for other people before doing the change.
And additional options can be added through augmentation.  One solution is to limit to IPv4 case which is really usual today.

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Saturday, October 08, 2016 02:08
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]; General Area Review Team; [email-masked]
Subject: Re: Gen-ART Last Call review of draft-ietf-l3sm-l3vpn-service-model-16

...
> [SLI2] The current model supports classification based on generic DSCP values. Isn't it enough ?

Yes, I missed that. I agree, that seems the right level for this model. However, this raises one detail. The model says:

but tos was obsoleted when dscp was defined by RFC 2474. I don't think you should include tos. You don't mention ECN, which are the two bits from tos that are not included in dscp. Those bits are no good for flow matching because they are variable.  If an operator tries to use the 8 TOS bits for flow matching but a user supports ECN, the matching will not work consistently.

...

OK.

...
> [SLI2] That was done for simplification purpose, could you list the different options that you would like to see in this model ? To be honest, I'm not fully aware of all the necessary combinations,…

I think the three cases I mentioned are sufficient for a start, but (getting back to Benoit's point) we could quickly get into configuration detail. So we have

NAT64 (for an IPv6-only network requiring IPv4 access) - which requires an outside ipv4-address and an inside WKP (well-known ipv6-prefix).
(NAT64 implies DNS64, but I don't think that is needed in the model.)

(There are also possible NAT444 and XLAT464 cases with added complexity, but let's leave them for now.)

If you go that way it needs a quick check on the BEHAVE list, where NAT expertise exists.

Regards
   Brian

---

From: Qin Wu <[email-masked]>
Date: Mon, 10 Oct 2016 08:55:13 +0000

Not sure we should enumerate all the options in the base model, so your solution makes sense to me.

-Qin

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]]
Sent: Saturday, October 08, 2016 02:08
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]; General Area Review Team; [email-masked]
Subject: Re: Gen-ART Last Call review of draft-ietf-l3sm-l3vpn-service-model-16

...

...

OK.

...

Regards
   Brian

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Oct 2016 12:49:06 +1300

That's certainly a valid option, but if you limit it to NAT44
I strongly suggest *calling* it NAT44, not plain NAT.

Regards
   Brian Carpenter

---

From: Qin Wu <[email-masked]>
Date: Tue, 11 Oct 2016 00:41:24 +0000

Fair enough. I think the author has implemented this in v(-017).

-Qin
-----邮件原件-----
发件人: Brian E Carpenter [mailto:[email-masked]] 
发送时间: 2016年10月11日 7:49
收件人: Qin Wu; [email-masked]; [email-masked]; General Area Review Team; [email-masked]
主题: Re: Gen-ART Last Call review of draft-ietf-l3sm-l3vpn-service-model-16

That's certainly a valid option, but if you limit it to NAT44 I strongly suggest *calling* it NAT44, not plain NAT.

Regards
   Brian Carpenter

On 10/10/2016 21:55, Qin Wu wrote:
> 收件人: Brian E Carpenter; 
> [email-masked]; General Area Review 
> Team; [email-masked]
> To: LITKOWSKI Stephane OBS/OINIS; 
> [email-masked]; General Area Review 
> Team; [email-masked]
> I think the three cases I mentioned are sufficient for a start, but 
> (getting back to Benoit's point) we could quickly get into 
> configuration detail. So we have
> 
> (There are also possible NAT444 and XLAT464 cases with added 
> complexity, but let's leave them for now.)
> 
> ______________________________________________________________________
> ___________________________________________________
>