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

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
> 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,
>
> Thanks for the response and the proposed updates. Some follow-up on a few points:
>
> On 06/10/2016 21:46, [email-masked] 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.
>
> [SLI2] I added a note in a new "feature and augmentation" paragraph that I already created to accommodate another comment.
>
>>
>>> 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.
>
> [SLI2] I'm adding it.
>
>>
>>> 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).
>
> [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.

>   
>
>
>> 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?
>
> [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.
>
>
>> 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.
>
> [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.
>
>
>> 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
>
> _________________________________________________________________________________________________________________________
>
> 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: 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.)
> 
> ______________________________________________________________________
> ___________________________________________________
>