Subject: Re: [nsc] Questions to "draft-boucadair-network-function-chaining":

From: <[email-masked]>
Date: Mon, 22 Jul 2013 10:13:28 +0200

Dear Linda,

Please see inline.

Cheers,
Med

De : Linda Dunbar [mailto:[email-masked]]
Envoyé : vendredi 19 juillet 2013 01:53
À : Diego R. Lopez; BOUCADAIR Mohamed OLNC/OLN
Cc : [email-masked]
Objet : Questions to "draft-boucadair-network-function-chaining":

Mohamed, et al

The examples in your draft for "Network Located Functions" are called  by many people as Layer 4 to 7 services, such as Firewall, Security services, NAT, etc.
[Med] Saying L4-L7 is not accurate IMHO because some of these functions can be enforced at Layer 3 for instance (e.g., NPTv6 (RFC 6296)). Restricting these functions to L4-L7 is a pre-requisite which is not required for this work. IMO, we should not make any assumption on the layer on which a function, located in administrative domain, act on. The exact characterization of each of these functions is up to each administrative entity: it is deployment-specific and policy-based.

What does "Located" mean in your context?
[Med] The rationale behind that characterization is as follows: As you know in order to deliver connectivity services, several functions are invoked;  some of these functions are ** located in the network side ** while others are ** embedded in a host, a home router/CPE **. Examples of functions that are located in the host side or the CPE side include (non-exclusive list): NAT44, A+P NAT, MAP-E CE, MAP-T CE, DHCP client, DHCP server, DNS resolver, DNS proxy, NTP server, NTP Proxy, SIP Proxy Server, SIP User Agent, DNSSEC validator, cache, TCP profiler, IPv4 firewall, IPv6 firewall, DS-Lite B4 element, NAT64, etc. Orchestrating these functions is out of scope. Hence, the need to characterize the brand of functions which are in scope: only those located in the network side (i.e., Network-Located Functions).
Note, the he use of "located" avoids any confusion that can be induced by "network function" since some may think these functions act at the "network layer"...which is not true.

How different is the term "DiffForward"  (differentiated forwarding procedure) from traditional router's differentiated forwarding based on some priority bits?
[Med] Undertaking local decisions based on some priority criteria is more close to the notion of differentiated services...We are using DiffForward term in the sense of differentiated forwarding paths: distinct packets may follow distinct forwarding path under some classification conditions. These classification conditions are policy-driven. In order to benefit from this differentiated forwarding behavior, some marking may be needed. The marking bits may be the same as the priority bits you mentioned or be new ones.

Your draft touches upon "Network Located Function Map", are you advocating that this "Map" should be dynamically formed or adjusted from heartbeat messages sent from all the "Network Located Functions" scatted in the network?
[Med] The proposed framework may accommodate that need but this is an OPTIONAL feature. Please refer to http://tools.ietf.org/html/draft-boucadair-network-function-chaining-02#section-6.7. Are you referring to such liveness detection feature?

It seems to me that your draft tries to cover three major categories:
[Med] The document proposes an architecture framework document for the chaining of functions. The document explains in particular the role of each functional entity and the interactions between these entities. It also identifies and discusses some deployment options. The overall architecture is policy-driven. How these policies are generated and what are the required input to the decision-making process is orthogonal to the architectural discussions.

-          Dynamic formulating the "Network Located Function Map"

o   i.e. monitoring all the network service functions scattered in the network, and create a dynamic map of all those functions.

o   It is almost like "Topology discovery of all network functions". Correct?
[Med] These are optional feedback features. The overall architecture works without such dynamic detection and feedback means. The PDP (Policy Decision Point) can be provisioned using both static of dynamic means.

-          Automatically create chronology of service functions based on user demand and network resource availability:
[Med] Yes, this can be met with the proposed framework since the PDP is responsible for generating and enforcing the policies. Nevertheless, the document does not make any assumption on the provisioning cycle and the interactions with an administrator/user nor any order handling module. The usability of the proposed architecture is another dimension that can be detailed further if needed.

o   For example, client demand could be: "Traffic-Filtering-Criteria <-> a sequence of service modules {S1, S2}, where Si is generic function like Firewall or IPS.

o   Your draft states that there should be automation system that dynamically locate "Service Modules" for S1 and S2, and determine where traffic should be steering to S1, and where traffic should be steering to S2. Is it correct?

-          Proper enforcement of selective traffic to go through their designated "Service Functions" through the network.
[Med] Yes.

Linda Dunbar

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 22 Jul 2013 23:44:13 +0000

Mohamed,

Thank you very much for the reply. More clarification questions are inserted blow:

[Linda] That is a very interesting point. You are saying that all the functions listed above on the client side, or sometimes referred to as services associated with access routers, are not in the scope of the Network Located Services.

Can you give some examples of services that are located "in the network side"?

[Linda] Yes. But I think you need to include more dimensions in the Liveness Detection. First of all, you need to specify different service categories: e.g. video optimization, content caching, security (DDoS prevention, SSL Inspection, Malware analysis, etc), HTTP message recognition, etc. This is a very big problem space already.

It seems to me that your draft tries to cover three major categories:
[Med] The document proposes an architecture framework document for the chaining of functions. The document explains in particular the role of each functional entity and the interactions between these entities. It also identifies and discusses some deployment options. The overall architecture is policy-driven. How these policies are generated and what are the required input to the decision-making process is orthogonal to the architectural discussions.
[Linda] do you mean network architecture? i.e. methods  to enforce selected traffic to go through their designated service modules?

The PDP (Policy Decision Point) can be provisioned using both static of dynamic means.

[Linda] is PDP more like "Policy Driven Traffic Steering Point"? It is less about deciding policies, is it?

-        Automatically create chronology of service functions based on user demand and network resource availability:
[Med] Yes, this can be met with the proposed framework since the PDP is responsible for generating and enforcing the policies.

[Linda] is PDP in the data path or an entity, that could be separated from data path,  for making the policy decision?

Linda Dunbar

---

From: <[email-masked]>
Date: Wed, 24 Jul 2013 14:11:59 +0200

Dear Linda,

Please see inline.
Cheers,
Med

De : [email-masked] [mailto:[email-masked]] De la part de Linda Dunbar
Envoyé : mardi 23 juillet 2013 01:44
À : BOUCADAIR Mohamed OLNC/OLN; Diego R. Lopez
Cc : [email-masked]
Objet : Re: [nsc] Questions to "draft-boucadair-network-function-chaining":

Mohamed,

Can you give some examples of services that are located "in the network side"?
[Med] Examples of NLFs are cited in draft-boucadair-*. In addition to that list, some of the functions located in the customer side can also be enabled at the network side (e.g., SIP Proxy, NAT64, etc.). This is why, I prefer to characterize the function with regards to its location rather than its outcome. This recalls me another assumption I would vote to consider for this work: These functions do no span multiple administrative domains (but an administrative domain can host multiple DiffForward domains).

It seems to me that your draft tries to cover three major categories:
[Med] The document proposes an architecture framework document for the chaining of functions. The document explains in particular the role of each functional entity and the interactions between these entities. It also identifies and discusses some deployment options. The overall architecture is policy-driven. How these policies are generated and what are the required input to the decision-making process is orthogonal to the architectural discussions.
[Linda] do you mean network architecture? i.e. methods  to enforce selected traffic to go through their designated service modules?
[Med] Not only methods but also the behavior of involved functional elements.

[Linda] is PDP more like "Policy Driven Traffic Steering Point"? It is less about deciding policies, is it?
[Med] This is part of the PDP responsibility but the PDP is also responsible for:

·         Configuring NLF-specific policies (e.g., configure distinct user profiles, activate specific traffic filters, configure traffic conditioners,    etc.)

·         Selecting NLF profiles (see for instance http://tools.ietf.org/html/draft-boucadair-network-function-chaining-02#section-6.2)

[Linda] is PDP in the data path or an entity, that could be separated from data path,  for making the policy decision?
[Med] The typical model is to have the PDP separated from the data path.

Linda Dunbar