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

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 30 May 2014 07:57:04 +0000

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

---

From: Ron Parker <[email-masked]>
Date: Fri, 30 May 2014 19:50:58 +0000

To draft-penno-sfc-yang authors,

Please consider the questions and comments below.  Thank you.

   Ron

-------------
1.  Why must there be exactly 3 elements in the leaf-list "/vxlan-gpe-header/vni" ?

2.  Regarding the identity statements that define service function types, I feel that it is limiting to enumerate them.   In list /service-functions/service-function, the type is optional, anyway, so perhaps just make it a description string?

3.  /service-functions/service-function/ip-host-address is a single leaf.   I realize that it is a slippery slope to make this a list, because then we introduce confusion about if the list is a set of addresses for one managed entity vs. a set of independently managed entities, but I am thinking about certain internal load balancing scenarios (i.e., within the a single managed service function) that may require more than 1 IP address for that service function (i.e., multiple loopback IP addresses or even multiple interface-level IP addresses).

4.   In section 5 (Service Function Chain description), suggest chainging "But a service function chain does not specify exactly which service (firewal1 vs. firewall2) will be used" to "But a service function chain does not specify exactly which service <insert> function instance </insert> (firewal1 vs. firewall2) will be used".

5.  leaf-list /service-function-chain/service-function limits the chain to at most one occurrence of a given type of service function.   While that would be typical, there could be cases where a given type must be visited more than once in the chain.   Also, since the chain is defined in terms of the types, new types of service functions can not be supported without a corresponding change to this YANG module.   For these reasons, I would like to suggest that the chain be defined in terms of user-specified service function types.    One approach would be to have a 2 level hierarchy where the network administrator defines the meaningful service-functions (i.e., list service-function {key = name} ) and within that list have a list of instances and within that a list of IP addresses specific to the instance.

For example:

-- list service function {key type string}
    +-- list instance {key type string}
        +-- leaf-list ip-address

6.  Service-node type definitions -- what if a service node is simultaneously an ingress, middle, egress, legacy, etc?

7.  /service-nodes/service-node -- how is the ip-host-address interpreted here?   Is it the management IP address of the service-node?

8.  /service-function-path description -- suggest changing "the actual firewall" to "the actual firewall instance".

9.  /service-function-path/service-function-instance is a singleton leaf-list.   That is, exactly one sequence of service-functions can be specified.   Shouldn't there be a higher level list so that multiple sequences can be defined?   Also, is this the philosophy that we want for the service function path -- that all paths are fully identified a priori (i.e., centralized instance selection) vs. instance selection is done in a distributed manner?   I'm not taking a position, but merely asking the question.   In the case of pre-defining paths, the number of fully instantiated paths would grow arithmetically.

10.  /service-function-forwarding-map/service-map -- how does this differ from the ip address associated with the service function instance, itself?   Or from the service-node IP address?

-------------

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Reinaldo Penno (repenno)
Sent: Friday, May 30, 2014 3:57 AM
To: [email-masked]
Subject: [sfc] Yang Data Model for Service Function Chaining (02)

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.

_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 30 May 2014 21:09:40 +0000

Hello Ron,

Lots of good comments, comments inline with [RP]

On 5/30/14, 12:50 PM, "Ron Parker" <[email-masked]> wrote:

>2.  Regarding the identity statements that define service function types,
>I feel that it is limiting to enumerate them.   In list
>/service-functions/service-function, the type is optional, anyway, so
>perhaps just make it a description string?

[RP] This is the approach used for IETF interfaces and the consensus of
netmod on how to approach similar issues.

http://tools.ietf.org/html/rfc7224 - List if interface type identities
http://tools.ietf.org/html/rfc7223 - Base model

Basically there is a list of identities for many interfaces and folks can
augment that list with their own identities. My intention is that folks
are free to also augment the list of service function types.

>
>3.  /service-functions/service-function/ip-host-address is a single leaf.
>  I realize that it is a slippery slope to make this a list, because then
>we introduce confusion about if the list is a set of addresses for one
>managed entity vs. a set of independently managed entities, but I am
>thinking about certain internal load balancing scenarios (i.e., within
>the a single managed service function) that may require more than 1 IP
>address for that service function (i.e., multiple loopback IP addresses
>or even multiple interface-level IP addresses).

[RP] This is the management address. The actual address used in the data
plane is found in SFF/Service Path, but your comments applies irrespective.

>
>4.   In section 5 (Service Function Chain description), suggest chainging
>"But a service function chain does not specify exactly which service
>(firewal1 vs. firewall2) will be used" to "But a service function chain
>does not specify exactly which service <insert> function instance
></insert> (firewal1 vs. firewall2) will be used".

[RP] Certainly.

>
>5.  leaf-list /service-function-chain/service-function limits the chain
>to at most one occurrence of a given type of service function.   While
>that would be typical, there could be cases where a given type must be
>visited more than once in the chain.   Also, since the chain is defined
>in terms of the types, new types of service functions can not be
>supported without a corresponding change to this YANG module.   For these
>reasons, I would like to suggest that the chain be defined in terms of
>user-specified service function types.    One approach would be to have a
>2 level hierarchy where the network administrator defines the meaningful
>service-functions (i.e., list service-function {key = name} ) and within
>that list have a list of instances and within that a list of IP addresses
>specific to the instance.
>
>For example:
>

[RP] Let me think about this one.

>
>6.  Service-node type definitions -- what if a service node is
>simultaneously an ingress, middle, egress, legacy, etc?

[RP] Possible. Much like a router can be peering and edge. Do you think we
should support multiple types or that would complicate things?

>
>7.  /service-nodes/service-node -- how is the ip-host-address interpreted
>here?   Is it the management IP address of the service-node?

[RP] Management. I will make clear next revision.

>
>8.  /service-function-path description -- suggest changing "the actual
>firewall" to "the actual firewall instance".

[RP] Can do.

>
>9.  /service-function-path/service-function-instance is a singleton
>leaf-list.   That is, exactly one sequence of service-functions can be
>specified.   Shouldn't there be a higher level list so that multiple
>sequences can be defined?

[RP] Wouldn¹t they be separate function paths then?

>Also, is this the philosophy that we want for the service function path
>-- that all paths are fully identified a priori (i.e., centralized
>instance selection) vs. instance selection is done in a distributed
>manner?   I'm not taking a position, but merely asking the question.   In
>the case of pre-defining paths, the number of fully instantiated paths
>would grow arithmetically.

[RP] How would that impact the Yang model? The configuration needs to be
consistent and known by a SN/SFF by the time it will make selection of
next SF in path. 

>
>10.  /service-function-forwarding-map/service-map -- how does this differ
>from the ip address associated with the service function instance,
>itself?   Or from the service-node IP address?

[RP] Data plane vs. management. I think this point is not clear given your
other comments.

>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.
>
>URL:            
>http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-02.txt