Subject: [sfc] YANG data model for complex service structures (Re: FW: New Version Notification for draft-penno-sfc-yang-11.txt)

From: Sevil Mehraghdam <[email-masked]>
Date: Tue, 10 Mar 2015 10:00:28 +0100

Hello,

we have been working on a formal specification model for complex service 
structures besides a simple chain of totally ordered service functions, 
i.e., partially ordered sets that can be chained in different ways, 
branches, full meshes, etc.

We have developed a context-free grammar for the abstract specification 
of these structures. For a more concrete model that can include other 
attributes of a service together with the "structure", we have ideas for 
integrating our description model into the the latest draft of the Yang 
data model for SFC. You can find our paper (currently under review) with 
more details on this in:

http://arxiv.org/abs/1503.02442

We would very much appreciate your comments and suggestions.

Best regards,
Sevil

On 02/28/2015 01:30 AM, Reinaldo Penno (repenno) wrote:
>
> On 2/27/15, 4:29 PM, "[email-masked]" <[email-masked]>
> wrote:
>
>> A new version of I-D, draft-penno-sfc-yang-11.txt
>> has been successfully submitted by Reinaldo Penno and posted to the
>> IETF repository.
>>
>> Name:		draft-penno-sfc-yang
>> Revision:	11
>> Title:		Yang Data Model for Service Function Chaining
>> Document date:	2015-02-27
>> Group:		Individual Submission
>> Pages:		56
>> URL:
>> http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-11.txt
>> Status:         https://datatracker.ietf.org/doc/draft-penno-sfc-yang/
>> Htmlized:       http://tools.ietf.org/html/draft-penno-sfc-yang-11
>> Diff:           http://www.ietf.org/rfcdiff?url2=draft-penno-sfc-yang-11
>>
>> Abstract:
>>    This document defines a YANG data model that can be used to configure
>>    and manage Service Function Chains.
>>
>>
>>                   
>>         
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

-- 
Sevil Mehraghdam
University of Paderborn
Computer Networks group – http://wwwcs.upb.de/cs/ag-karl
Tel.: +49 5251 / 601755
Room: O3.161

---

From: Jan Lindblad <[email-masked]>
Date: Tue, 10 Mar 2015 13:29:52 +0100

Hi Reinaldo,

I haven’t seen a lot of review comments on the service-function.yang family of modules, so I decided to go through it. I’m a "YANG Doctor", so I understand YANG, but I haven’t followed the discussion on the list closely.

> On 28 feb 2015, at 01:30, Reinaldo Penno (repenno) <[email-masked]> wrote:
...
>> http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-11.txt <http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-11.txt>

First, I should say I find this document nicely arranged and highly readable. Considering that this is an initial review of 50+ pages worth of YANG models, I think the number of comments I have is surprisingly low. Comments here are more or less in document order.

service-function.yang:
- What is the purpose with rpc put-service-function, rpc read-service-function, rpc delete-service-function? If only to manipulate the configuration with no specific side effects, they are not required. The management protocols (NETCONF, RESTCONF, …) all have built-in mechanisms for creating, reading, deleting etc the configuration modeled in the YANG model. I would suggest to remove the rpcs.
- The rpc delete-all-service-function may have a slight value, but it’s actually very easy to delete all instances with the built-in operations in NETCONF, RESTCONF etc.
- leaf request_reclassification, I suggest renaming to request-reclassification, in order to follow IETF naming conventions
- list sf-data-plane-locator, I suggest renaming to data-plane-locator, in order to follow IETF naming conventions. There is no value in keeping prefixes like “sf-“ indicating the location of the object, since that is evident from the object path anyhow.
- leaf service-function-forwarder is of type string. I’m not sure I understand what the valid values would be for this string. Is this actually a reference? Is there reason to add a few words to the description field, or should we perhaps model this differently?
- As mentioned above the rpcs may not be necessary at all, but if any rpcs are included, they would often have an output clause, to report some sort of status

service-function-type.yang:
- list sft-service-function-name, suggest removing “sft-“ prefix
- leaf name, are these the SF instances? Perhaps clarify the description with a few words.

service-function-chain.yang:
- rpc instantiate-service-function-chain, does this modify the configuration, or just the operational state?
- rpc put-service-function-chains appears to be unnecessary. Suggest removing or explaining the side effects it implements in the description.
- list sfc-service-function is ordered by user, but also has a leaf order. How do these relate? Lists ordered by user would normally not have any leafs suggesting sorting order.

service-function-path.yang:
- leaf classifier is a string. What string values can it take?
- leaf symmetric-classifier is a string. What string values can it take?
- list service-path-hop is ordered by user, but has a key hop-number which seems to be the natural sorting key. Remove order-by user?
- leaf service-index, I don’t understand the description. Does the description relate to the configuration or to the SFF wire operation?
- leaf service-chain-name is a string, should this be a reference?

service-function-forwarder.yang:
- leaf service-node is a string, should this be a reference?
- list sff-data-plane-locator, suggest removing “sff-“ prefix
- container sff-sf-data-plane-locator, suggest removing “sff-sf-“ prefix
- list sff-interfaces, suggest removing “sff-“ prefix

service-funciton-forwarder-ova.yang:
(no comments)

service-locator.yang:
(no comments)

rendered-service-path.yang:
- list rendered-service-path, leaf name is a string. Should this be a reference?
- leaf parent-service-function-path is a string. Should this be a reference?
- list rendered-service-path-hop is a config false list keyed by a naturally sequenced key hop-number, yet it is marked as order-by user. Remove?
- leaf service-chain-name is a string. Should this be a reference?
- rpc delete-rendered-path, will this change the configuration, or just op state?
- rpc create-rendered-path, will this change the configuration, or just op state?

service-function-classifier.yang:
- the tree diagram is wrong (copy paste problem?)
- leaf bridge is a string. Should this be a reference?
- leaf interface is a string. Should this be a reference?
- leaf access-list is a string. What is the format?
- leaf rendered-service-path is a string. Should this be a reference?
- list scl-service-function-forwarder, suggest removing “scl-“ prefix

service-function-description-monitor-report.yang:
- config false statement appears to be missing
- rpc get-SF-description, suggest removing. This information can be retrieved without any rpc definition.
- rpc get-SF-monitoring-info, suggest removing. This information can be retrieved without any rpc definition.

service-function-description-monitor.yang:
(no comments)

/Jan Lindblad

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 10 Mar 2015 15:51:48 +0000

Thanks Jan, I will go though your comments and provide detailed answers.

In the newsiest version (13) I added a section explaining the overall architecture of the Yang models that might help readers.

Thanks,

Reinaldo

From: Jan Lindblad <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 10, 2015 at 5:29 AM
To: Reinaldo Penno <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] New Version Notification for draft-penno-sfc-yang-11.txt

Hi Reinaldo,

On 28 feb 2015, at 01:30, Reinaldo Penno (repenno) <[email-masked]<mailto:[email-masked]>> wrote:
...
A new version of I-D, draft-penno-sfc-yang-11.txt
has been successfully submitted by Reinaldo Penno and posted to the
IETF repository.

service-function.yang:

service-locator.yang:
(no comments)

/Jan Lindblad