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

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Sun, 8 Jun 2014 19:46:41 +0000

New version of SFC Yang data models.

thanks to Jan Lindblad, Ron Parker and other reviewers.

A new version of I-D, draft-penno-sfc-yang-03.txt
has been successfully submitted by Reinaldo Penno and posted to the
IETF repository.

Name:           draft-penno-sfc-yang
Revision:       03
Title:          Yang Data Model for Service Function Chaining
Document date:  2014-06-06
Group:          Individual Submission
Pages:          21
URL:            http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-03.txt
Status:         https://datatracker.ietf.org/doc/draft-penno-sfc-yang/
Htmlized:       http://tools.ietf.org/html/draft-penno-sfc-yang-03
Diff:           http://www.ietf.org/rfcdiff?url2=draft-penno-sfc-yang-03

Abstract:
   This document defines a YANG data model that can be used to configure
   and manage Service Function Chains.
________________________________
From: sfc [[email-masked]] on behalf of Reinaldo Penno (repenno)
Sent: Friday, June 06, 2014 7:28 PM
To: Jan Lindblad
Cc: [email-masked]
Subject: Re: [sfc] Yang Data Model for Service Function Chaining (02)

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,

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.

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

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.

[RP] okay.

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).

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

module service-function:

Revision dates are YYYY-MM-DD

[RP] Done

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.

[RP] Done

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.

[RP] This can be modified later.

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.

[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:

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).

[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.

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

[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.

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.

[RP] Good catch.  Changed.

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.

[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:

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]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 08 Jun 2014 16:04:52 -0400

The definition of service function forwarder here seems MUCH too 
specific.  I would think we would want a generalized definition, and 
then an extension for the ase where the forwarder reachs the service 
functions based on IP address and port number.

Yours,
Joel

On 6/8/14, 3:46 PM, Reinaldo Penno (repenno) wrote:
> ------------------------------------------------------------------------
> *From:* sfc [[email-masked]] on behalf of Reinaldo Penno (repenno)
> *Sent:* Friday, June 06, 2014 7:28 PM
> *To:* Jan Lindblad
> *Cc:* [email-masked]
> *Subject:* Re: [sfc] Yang Data Model for Service Function Chaining (02)
>
> Hello Jan,
>
> From: Jan Lindblad <[email-masked] <mailto:[email-masked]>>
> To: Cisco Employee <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> 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
>
> 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.
>
> [RP] okay.
>
> 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).
>
> 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.
>
> [RP] Done
>
> 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.
>
> 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.
>
> [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 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).
>
> [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.
>
> As noted by Ron Parker, type can hold only a single value. Could a
> service node be of multiple types simultaneously?
>
> [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.
>
> 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.
>
> 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.
>
> [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
>
>
>> [email-masked] <mailto:[email-masked]>
> [email-masked]

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 9 Jun 2014 03:04:52 +0000

Sure, let's work on it.

Do you want to propose something that matches your expectations and then we can refine it?

thanks,

Reinaldo

________________________________________
From: Joel M. Halpern [[email-masked]]
Sent: Sunday, June 08, 2014 1:04 PM
To: Reinaldo Penno (repenno); [email-masked]
Subject: Re: [sfc] Yang Data Model for Service Function Chaining (03)

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 09 Jun 2014 00:27:17 -0400

It would seem that a starting point would be to replace the address and 
port with a reference to a service functiuon?

Also, should we have a distinction between a kind of service function as 
it appears in a service chian, and a location we can direct packets to 
for a service function, as it appears in the service path.  (I hesitate 
to use the word instance since while the thing appears as an isntance to 
the path, it may actually be a cluster, etc...)

Yours,
Joel

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 9 Jun 2014 22:37:30 +0000

Inline with [RP]

>port with a reference to a service functiuon?

[RP] Then the service function needs to have the locator. We should
provide for augmentation (read, Yang list) so that many types of locators
are possible.

>the path, it may actually be a cluster, etc...)

[RP] I¹ve been wrestling with this issue for some time that¹s why I put
the locator inside SFF originally. In my mind the locator means ³if you
send packets to this locator, it will reach this service function. It
might not reach it directly, but it will get there². Therefore SFF does
not need to bother about the specifics of load-blanacers, proxy services,
etc

>>> 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.:
>>> [RP] I¹ve made this change but in order to avoid confusion I¹m relying
>>> you have a chain where there is only one of each type the leaf ³name"
>>> example,  if you can have a name ³dpi-early² and a type ³firewall². I

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 09 Jun 2014 18:51:44 -0400

I see your point.  In fact, since the relevant forwarding information 
for an SFF may be a physical port id (possibly with a MAC address) or 
even a logical port ID, it does seem that attaching the information, as 
an extensible list of alternatives, to the SFF may be the right way to 
do it.

Yours,
Joel