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

[Brian E Carpenter <[e-mail]>]

Stephane,

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

On 06/10/2016 21:46, [e-mail] wrote:
...
>> 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.
> 
> [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.

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

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

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

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

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

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

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