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

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

Just front-posting for this point:

> Indeed, we should pay attention that this Service YANG model doesn't 
> 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

On 07/10/2016 22:14, Benoit Claise wrote:
> 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:[e-mail]]
>> Sent: Thursday, October 06, 2016 21:58
>> To: LITKOWSKI Stephane OBS/OINIS; [e-mail]; 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, [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.
>>
>> [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.
>>
> 
>