Re: [L3sm] RtgDir review: draft-ietf-l3sm-l3vpn-service-model-17.txt

[<[e-mail]>]

Many thanks Les,

I will take care of your comments asap.

Regarding QoS, I agree that there is a kind of overlap with network element config. 
For classification, there is no other choice, customer must provide information about its flows and class mapping. This can be achieved through an abstracted way (using application match) or a less one (flow match) which is more similar to a router config. But we have no choice, it's impossible to match all flows using predefined applications.

For scheduling, this is linked to the fact that some customers are using pre-defined SP templates (GOLD, SILVER ...) that are abstracted , but as part of the service, some SP also propose customizable QoS models where the customer can define its own scheduling policy, that's why it also looks like a router config.

I think it's hard to remove those non abstracted parts (especially classification) as it's widely used today.


Brgds,

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[e-mail]] 
Sent: Thursday, October 13, 2016 06:52
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RtgDir review: draft-ietf-l3sm-l3vpn-service-model-17.txt

Hello,

I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-l3sm-l3vpn-service-model-17.txt
Reviewer: Les Ginsberg
Review Date: 12 October 2016
IETF LC End Date: 11 October 2016
Intended Status: Proposed Standard

Summary:

This is a well written and excellent document - impressive both for its attention to detail and its breadth.

I have one significant concern.
I have also identified a number of editorial issues.

Comments:
I have not followed the work on this document nor am I subscribed to the WG mailing list - so it is possible my comments do not account for some discussions that have occurred as this document progressed.

Major Issues:
The document mentions in Section 7 that the definition of the service model assumes that a number of YANG models for network elements will be provided.
In the list is "QoS : classification, profiles".

Looking at Section 5.12.2 of the document, it seems that the definitions could easily conflict with the definitions which we would expect in a network element QOS model (e.g., https://datatracker.ietf.org/doc/draft-asechoud-netmod-qos-model/ )

I wonder if it would be better to eliminate much of what is in this section of the draft and defer to the QOS config model?

I would be interested in the authors views on this point.

Minor Issues:

None

Nits:
I have prepared a "marked up" copy of the draft with a significant number of recommended editorial changes. As the most expedient way to provide this is by sending the entire document - and as that is large - I prefer not to send it to such a wide audience. I will therefore send the marked up copy directly to the authors. Anyone else who would like a copy please unicast me and I will be happy to send it.

    Les


_________________________________________________________________________________________________________________________

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.