Subject: Re: [sfc] Yang Data Model for Service Function Chaining (02)

From: Jan Lindblad <[email-masked]>
Date: Tue, 3 Jun 2014 11:05:52 +0200

Reinaldo,

Good work! I made a quick review of your proposed SFC YANG module. I have been monitoring this list for a couple of weeks only, so please bear with any misconceptions on my part. I'm a YANG Doctor, however, so I was hoping I could contribute with a few YANG-level suggestions or options for you.

module vxlan-gpe:

The namespace declaration in each of the modules starts with urn:cisco:... Namespaces on this form are supposed to be registered with IANA. http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml

I suggest either changing this to an IETF reserved name, or move it to a proper cisco-namespace, e.g.:
namespace "http://cisco.com/ns/ietf/wg/sfc";
or, perhaps better, an IETF registered name:
namespace "urn:ietf:rfc:XXXX"; // RFC Ed.: Replace XXXX with actual RFC number and remove this note.
This applies to all modules in the submission, but I will not keep repeating this comment for the others.

There are a number of reserved bits and fields in the module. I think it may be wise to think this through a bit more before publishing. According to the YANG RFC 6020 section 10, IETF does not allow itself to ever remove a published configurable item from a module, so those reserved names will have to stick forever. To make it worse, the bit positions must be unique, so the bit names will have to remain r1, r2, r3, ... indefinitely, even if a proper meaning and name is invented at a later stage. I suggest simply not listing them in the specification in this version, only adding them when they have a well defined meaning.

The leaf-list vni will not behave as intended. A leaf list will automatically sort itself into the natural (ascending) order (unless ordered-by user is specified), and can never contain repeated values (such as [1,1,1]). I'd suggest you use a 24-bit integer instead. Or possibly a list (not leaf list) with a position key. Or three separate 8-bit leafs (vni-low, vni-med, vni-high).

module service-function:

Revision dates are YYYY-MM-DD

Identity+identityref seems like a good way to handle this extensible set. It does require YANG modeling to define new types however, so if operators should be able to invent new types "on the fly", another option would be to have one more config table with the operator specified types, and then use a leafref to point to one of them.

Mandatory true on a key element is not necessary, so this can be removed for improved readability and brevity. This also applies to several other lists, but I will not keep repeating this comment.

There is no mandatory true on the type and ip-host-address leafs. What would it mean if a sfc entry exists and has no type nor ip-host-address? Should one or both be mandatory, or have a default? Note that if we specify a default, that default value can never ever be changed to something else according to the YANG RFC 6020, sec 10.

module service-function-chain:

As noted by Ron Parker, this allows only a single instance of each service type in each chain. With the current model, an operator has no way of defining additional service types to say clone a dpi service into an dpi-early and dpi-late. If this was modeled as a list with a string name and a service-function-type leaf instead, the same function could appear multiple times in a chain.

module service-node:

The leafs type, transport, ip-host-address and failmode are not mandatory and have no defaults. Will it be entirely clear to operators what the system will do if some or all of them have no values? This is not obvious to me (but that could be only me).

As noted by Ron Parker, type can hold only a single value. Could a service node be of multiple types simultaneously?

module service-function-path:

The service-function-path is modeled as a container. So there can be only one of these in the whole system. I might be missing something, but I think you want a list here, in some way.

module service-function-forwarder:

Once again, the leafs ip and port are not mandatory. Is that ok? Should each service function have a single ip/port pair?

In general, I think these modules are very small. Typically I recommend to make separate modules for things that need to be versioned separately, i.e. corresponding to software components. To me, these modules feel very closely related, so even a single module for all of this would be fine. Factoring things out into separate modules may make it harder to get a full grasp of what SFC is about, repeating things in module descriptions, making creation of new revisions harder.

/Jan Lindblad

On 30 maj 2014, at 09:57, Reinaldo Penno (repenno) <[email-masked]> wrote:

> A new version of I-D, draft-penno-sfc-yang-02.txt
> has been successfully submitted by Reinaldo Penno and posted to the
> IETF repository.
> 
> Name:           draft-penno-sfc-yang
> Revision:       02
> Title:          Yang Data Model for Service Function Chaining
> Document date:  2014-05-29
> Group:          Individual Submission
> Pages:          20
> URL:            http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-penno-sfc-yang/
> Htmlized:       http://tools.ietf.org/html/draft-penno-sfc-yang-02
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-penno-sfc-yang-02
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Sat, 7 Jun 2014 02:28:25 +0000

Hello Jan,

Thanks for the review, I will submit a new version shortly.

Inline with [RP]

From: Jan Lindblad <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, June 3, 2014 at 2:05 AM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Yang Data Model for Service Function Chaining (02)

Reinaldo,

module vxlan-gpe:

[RP] changed throughput to urn:TBD:...

[RP] okay.

[RP] Used 3 separate 8-bit leafs for now.

module service-function:

[RP] Done

[RP] Done

[RP] This can be modified later.

[RP] I’ve made this change but in order to avoid confusion I’m relying on the description to clear things up. Meaning, in the best case where you have a chain where there is only one of each type the leaf “name"  is redundant and in the worst case it might cause confusion, for example,  if you can have a name “dpi-early” and a type “firewall”. I guess we needed a list in Yang where indexes are assigned and you can have repeated values, otherwise it feels I created a leaf name for no purpose.

   list service-function {
      key "name";
      leaf name {
        type string;
        description
            "The name of the service function. This could be the
            same as the type or in the case where multiple service
            functions or the same type are used in chain, something
            like ingress-firewall and egress-firewall";
      }
      leaf type {
        type sfc-sf:service-function-type;
        description
            "The type of the service function.";
      }
      ordered-by user;
      description
        "A list of service functions that compose the service chain";
    }

module service-node:

[RP] I think the idea here is that at the time of creation the operator could not (or might not) want to specify all these things.

[RP] As I said in my reply to Ron this might be something to think about. It is a trade-off of complexity vs. flexibility.

[RP] Good catch.  Changed.

[RP] They were even smaller and based on opendaylight testing and feedback from folks like you they have been growing in order to accommodate the use-cases.  Therefore we should and decide later to consolidate or keep them apart.

/Jan Lindblad

On 30 maj 2014, at 09:57, Reinaldo Penno (repenno) <[email-masked]<mailto:[email-masked]>> wrote:

[email-masked]<mailto:[email-masked]>