Subject: [nsc] Service chaining architecture question

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Wed, 24 Jul 2013 09:51:44 +0000

I have a basic question with respect to the architecture/framework so far mentioned in the drafts in NSC. I understand the meta-data is a mechanism to avoid multiple re-classifications when the packet enters the NSC domain and identifies the chain of service functions. Now my understanding is that the services/applications are unaware of the meta-data and that a layer underneath should provide the mediation and that we use a well defined interface to the application/service to indicate the chain. In the context of Cloud/enterprise environment I can see this work given you can use a dedicate VLAN e.g. within the tenant. However we also try to address residential use cases for mobile and fixed and here this becomes more tricky afais. In the residential environment we can't expose a VLAN per application/service per chain since this would not be very effective. So I am wondering how we envision this to work?

---

From: <[email-masked]>
Date: Wed, 24 Jul 2013 15:54:33 +0200

Hi Wim,

I think not only effectivness/scalability might be a problem but also the fact that not all applications (service bringing functions) are able to handle packets coming from/going to potentially thousands of different VLANs at the same time. VLANs will work in certain environments but not in all. I see the need for an information exchange between the application and a mediation layer as well. Ideally this should be as simple as possible without heavy impact on the application itself (might be difficult to achieve but from my experience it is not very likely, that there will be big rewrites of existing applications in order to support the chaining).

  regards

     Nic

________________________________
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Henderickx, Wim (Wim)
Gesendet: Mittwoch, 24. Juli 2013 11:52
An: [email-masked]
Betreff: [nsc] Service chaining architecture question

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Wed, 24 Jul 2013 16:30:16 +0000

indeed

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 24 July 2013 15:54
To: Wim Henderickx <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: AW: Service chaining architecture question

Hi Wim,

  regards

     Nic

________________________________
Von: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] Im Auftrag von Henderickx, Wim (Wim)
Gesendet: Mittwoch, 24. Juli 2013 11:52
An: [email-masked]<mailto:[email-masked]>
Betreff: [nsc] Service chaining architecture question

---

From: David Allan I <[email-masked]>
Date: Wed, 24 Jul 2013 19:52:20 +0000

Saying functions will have a problem with something that exists as a potential rationale for defining something new with exactly the same properties and problems does not quite work for me....

VLANs on a vNIC or multiple vNICs (depending on the application stack construction and this being combined with application "cooperation" to preserve pairwise mappings of either VID/NIC tuples or simply NICs) currently exist as potential vehicles for preserving chain context and avoiding per hop classification. Anything else will be implemented more or less the same way and have exactly the same set of scaling and application design issues...Some extra information available on a single interface, or achieved by mapping chain instances onto one of a plurality of interfaces....

But to back up... I'm not a carrier employee but I cannot envision a carrier offering potentially 1000s of distinct service bundles ("pick 53 from column A and 49 from column B"). So I suspect a much smaller number is realistic for  the number of chains a function instance is expected to participate in, even allowing for dynamic reclassification of flows at a chain ingress to "skip a few functions".... These are things that are fully operationalized in OSS, have policy associated with, have been industrialized and demonstrated to work prior to deployment. Going all combinatorial on this will break that big time....

So are we really discussing a function participating in more than a handful of chain instances? And either a plurality of vNICs or VIDs being actually more than sufficient?

Thanks
Dave

From: [email-masked] [mailto:[email-masked]] On Behalf Of Henderickx, Wim (Wim)
Sent: Wednesday, July 24, 2013 9:30 AM
To: [email-masked]; [email-masked]
Subject: Re: [nsc] Service chaining architecture question

indeed

Hi Wim,

  regards

     Nic

---

From: Ron Parker <[email-masked]>
Date: Wed, 24 Jul 2013 20:05:27 +0000

Dave,

I agree that the number of chains is unlikely to scale to vast numbers (i.e., millions).     And I agree that it is bounded from a practical business perspective, as you point out.

You may already be on this page, but I wanted to point out a distinction of coarse-grained definition of a service function vs. finer-grained definition of a service function.   Consider a service function to be logical in such a way that the identity of the logical function may also imply some differentiated behavior.   For example, a conceptual function is HTTP content filtering.    This conceptual function can then be further instantiated at the logical level based on differentiated policies such as content-filter-children, content-filter-adults-no-porn, content-filter-adults (I'm taking no stand on opt-in vs. opt-out, Mr. Cameron).   It may be that the same network element (dedicated physical box or virtual network function) realizes all 3 of the example policies.   The HTTP content filtering network function is really 3 logical network functions from the perspective of inclusion in a service chain.   Now extend this to multiple conceptual functions that utilize differentiated policies and the number of combinations will grow, at least modestly.

Thanks,
Ron

From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Wednesday, July 24, 2013 3:52 PM
To: Henderickx, Wim (Wim); [email-masked]; [email-masked]
Subject: Re: [nsc] Service chaining architecture question

Thanks
Dave

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Henderickx, Wim (Wim)
Sent: Wednesday, July 24, 2013 9:30 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [nsc] Service chaining architecture question

indeed

Hi Wim,

  regards

     Nic

---

From: David Allan I <[email-masked]>
Date: Wed, 24 Jul 2013 20:17:54 +0000

I'd tend to look at your example as a class of  function that implements subscriber specific policies, of which there can be multiple outcomes. Either pass the traffic or proxy a "forbidden response".

>From a networking point of view I don't think multiple function outcomes has scaling implications for the network part of the implementation with the exception of when the function has a means to self-elect to be bypassed as an outcome...."I no longer need to process this flow...".

In which case I would need chain permutations with and without that class of function....

Wow, long way to say I think I agree ;-)
Dave

From: Ron Parker [mailto:[email-masked]]
Sent: Wednesday, July 24, 2013 1:05 PM
To: David Allan I; Henderickx, Wim (Wim); [email-masked]; [email-masked]
Subject: RE: [nsc] Service chaining architecture question

Dave,

Thanks,
Ron

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Wednesday, July 24, 2013 3:52 PM
To: Henderickx, Wim (Wim); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [nsc] Service chaining architecture question

Thanks
Dave

indeed

Hi Wim,

  regards

     Nic

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 24 Jul 2013 20:30:54 +0000

Hi Wim,

A few comments/questions inline ..

I have a basic question with respect to the architecture/framework so far mentioned in the drafts in NSC. I understand the meta-data is a mechanism to avoid multiple re-classifications when the packet enters the NSC domain and identifies the chain of service functions. Now my understanding is that the services/applications are unaware of the meta-data

Jim> this is true in the proxy-mode case but it is also possible that the service functions themselves understand the NSH metadata. Both modes of operation are valid imho.

and that a layer underneath should provide the mediation and that we use a well defined interface to the application/service to indicate the chain. In the context of Cloud/enterprise environment I can see this work given you can use a dedicate VLAN e.g. within the tenant.

Jim> note that the dedicated VLAN you describe is local between the proxy and the service e.g. We are not talking about domain-wide VLANs in this context. So this interface between the proxy and the service is in fact a "local identifier" where that might be a VLAN but could also be something else such as the IP address of the residential consumer. Further, the number of local identifier's you will need will be dependent on the differentiation you require; for example, is differentiation needed by user, or "class" of user (i.e. Gold, silver, bronze analogy), or something else.  So this boils down to what the local identifier is used for and whether it has policy associated with it e.g. vlan-1 -> do firewall rule "x", vlan-2 -> do firewall rule "y", and so on.

However we also try to address residential use cases for mobile and fixed and here this becomes more tricky afais. In the residential environment we can't expose a VLAN per application/service per chain since this would not be very effective. So I am wondering how we envision this to work?

Jim> I'm assuming when you say residential, you mean serving residential customers with services in the POP or head-end, NOT services in the home right?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 24 Jul 2013 16:46:40 -0400

Ron,
     maybe I am missing something, but you seem to lay out very nicely 
the case for wanting both service chain identification and separately 
subscriber identification.  Then the HTTP filter can use the subscriber 
ID to decide which exact content filtering behavior it should apply.  I 
would not want to fold that level of detail into the chain identification.

Yours,
Joel

On 7/24/13 4:05 PM, Ron Parker wrote:
> Dave,
>
> I agree that the number of chains is unlikely to scale to vast numbers
> (i.e., millions).     And I agree that it is bounded from a practical
> business perspective, as you point out.
>
> You may already be on this page, but I wanted to point out a distinction
> of coarse-grained definition of a service function vs. finer-grained
> definition of a service function.   Consider a service function to be
> logical in such a way that the identity of the logical function may also
> imply some differentiated behavior.   For example, a conceptual function
> is HTTP content filtering.    This conceptual function can then be
> further instantiated at the logical level based on differentiated
> policies such as content-filter-children, content-filter-adults-no-porn,
> content-filter-adults (I’m taking no stand on opt-in vs. opt-out, Mr.
> Cameron).   It may be that the same network element (dedicated physical
> box or virtual network function) realizes all 3 of the example
> policies.   The HTTP content filtering network function is really 3
> logical network functions from the perspective of inclusion in a service
> chain.   Now extend this to multiple conceptual functions that utilize
> differentiated policies and the number of combinations will grow, at
> least modestly.
>
> Thanks,
>
> Ron
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf Of
> *David Allan I
> *Sent:* Wednesday, July 24, 2013 3:52 PM
> *To:* Henderickx, Wim (Wim); [email-masked]; [email-masked]
> *Subject:* Re: [nsc] Service chaining architecture question
>
> Saying functions will have a problem with something that exists as a
> potential rationale for defining something new with exactly the same
> properties and problems does not quite work for me….
>
> VLANs on a vNIC or multiple vNICs (depending on the application stack
> construction and this being combined with application “cooperation” to
> preserve pairwise mappings of either VID/NIC tuples or simply NICs)
> currently exist as potential vehicles for preserving chain context and
> avoiding per hop classification. Anything else will be implemented more
> or less the same way and have exactly the same set of scaling and
> application design issues…Some extra information available on a single
> interface, or achieved by mapping chain instances onto one of a
> plurality of interfaces….
>
> But to back up… I’m not a carrier employee but I cannot envision a
> carrier offering potentially 1000s of distinct service bundles (“pick 53
> from column A and 49 from column B”). So I suspect a much smaller number
> is realistic for  the number of chains a function instance is expected
> to participate in, even allowing for dynamic reclassification of flows
> at a chain ingress to “skip a few functions”…. These are things that are
> fully operationalized in OSS, have policy associated with, have been
> industrialized and demonstrated to work prior to deployment. Going all
> combinatorial on this will break that big time….
>
> So are we really discussing a function participating in more than a
> handful of chain instances? And either a plurality of vNICs or VIDs
> being actually more than sufficient?
>
> Thanks
>
> Dave
>
> *From:[email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]] *On Behalf Of *Henderickx, Wim (Wim)
> *Sent:* Wednesday, July 24, 2013 9:30 AM
> *To:* [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>
> *Subject:* Re: [nsc] Service chaining architecture question
>
> indeed
>
> *From: *"[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>
> *Date: *Wednesday 24 July 2013 15:54
> *To: *Wim Henderickx <[email-masked]
> <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> *Subject: *AW: Service chaining architecture question
>
> Hi Wim,
>
> I think not only effectivness/scalability might be a problem but also
> the fact that not all applications (service bringing functions) are able
> to handle packets coming from/going to potentially thousands of
> different VLANs at the same time. VLANs will work in certain
> environments but not in all. I see the need for an information exchange
> between the application and a mediation layer as well. Ideally this
> should be as simple as possible without heavy impact on the application
> itself (might be difficult to achieve but from my experience it is not
> very likely, that there will be big rewrites of existing applications in
> order to support the chaining).
>
>    regards
>
>       Nic
>
> ------------------------------------------------------------------------
>
> *Von:[email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]] *Im Auftrag von *Henderickx, Wim (Wim)
> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
> *An:* [email-masked] <mailto:[email-masked]>
> *Betreff:* [nsc] Service chaining architecture question
>
> I have a basic question with respect to the architecture/framework so
> far mentioned in the drafts in NSC. I understand the meta-data is a
> mechanism to avoid multiple re-classifications when the packet enters
> the NSC domain and identifies the chain of service functions. Now my
> understanding is that the services/applications are unaware of the
> meta-data and that a layer underneath should provide the mediation and
> that we use a well defined interface to the application/service to
> indicate the chain. In the context of Cloud/enterprise environment I can
> see this work given you can use a dedicate VLAN e.g. within the tenant.
> However we also try to address residential use cases for mobile and
> fixed and here this becomes more tricky afais. In the residential
> environment we can't expose a VLAN per application/service per chain
> since this would not be very effective. So I am wondering how we
> envision this to work?
>
>
>
> _______________________________________________
> nsc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nsc
>

---

From: Ron Parker <[email-masked]>
Date: Wed, 24 Jul 2013 22:01:41 +0000

Joel,

IMO, the primary reason for understanding the subscriber identity at a network service is to choose from a differentiated set of policies.    I think there is utility and efficiency in driving that selection from one place -- the network services classifier.     Say there were 2 groups of subscribers -- children and adults.   Let's now define 2 chains, where the chains have a business-based meaning to the operator.    Chain 1 = HTTP-filter-child + Firewall-child.   Chain 2 = HTTP-filter-adult + Firewall-adult.    The referenced network services are logical and it is possible, but not required, that multiple logical network services be located at the same IP address or FQDN.     Conveying the actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain ID, ...) allows the IP-addressable server that realizes these service(s) to know two things -- 1) which logical network function should be invoked and 2) which logical network function is next. 

Thanks.
Ron

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, July 24, 2013 4:47 PM
To: Ron Parker
Cc: [email-masked]
Subject: Re: [nsc] Service chaining architecture question

Ron,
     maybe I am missing something, but you seem to lay out very nicely the case for wanting both service chain identification and separately subscriber identification.  Then the HTTP filter can use the subscriber ID to decide which exact content filtering behavior it should apply.  I would not want to fold that level of detail into the chain identification.

Yours,
Joel

On 7/24/13 4:05 PM, Ron Parker wrote:
> You may already be on this page, but I wanted to point out a 
> distinction of coarse-grained definition of a service function vs. finer-grained
> policies such as content-filter-children, 
> content-filter-adults-no-porn, content-filter-adults (I'm taking no stand on opt-in vs. opt-out, Mr.
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *David Allan I
> properties and problems does not quite work for me....
>
> construction and this being combined with application "cooperation" to 
> avoiding per hop classification. Anything else will be implemented 
> more or less the same way and have exactly the same set of scaling and 
> application design issues...Some extra information available on a single 
> plurality of interfaces....
>
> But to back up... I'm not a carrier employee but I cannot envision a 
> carrier offering potentially 1000s of distinct service bundles ("pick 
> 53 from column A and 49 from column B"). So I suspect a much smaller 
> number is realistic for  the number of chains a function instance is 
> expected to participate in, even allowing for dynamic reclassification 
> of flows at a chain ingress to "skip a few functions".... These are 
> things that are fully operationalized in OSS, have policy associated 
> with, have been industrialized and demonstrated to work prior to 
> deployment. Going all combinatorial on this will break that big time....
>
> the fact that not all applications (service bringing functions) are 
> able to handle packets coming from/going to potentially thousands of 
> environments but not in all. I see the need for an information 
> exchange between the application and a mediation layer as well. 
> Ideally this should be as simple as possible without heavy impact on 
> the application itself (might be difficult to achieve but from my 
> experience it is not very likely, that there will be big rewrites of 
> existing applications in order to support the chaining).
>
>    regards
>
>       Nic
>
> indicate the chain. In the context of Cloud/enterprise environment I 
> can see this work given you can use a dedicate VLAN e.g. within the tenant.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 24 Jul 2013 22:16:51 +0000

Ron,
Or alternatively carry the subscriber awareness in metadata thereby utilizing a single chain.

Sent from my iPhone

---

From: Ron Parker <[email-masked]>
Date: Wed, 24 Jul 2013 22:20:22 +0000

Jim,

Yes, that could work, too, conceptually.   But it does require that each coarsely-defined network service have access to a subscriber-aware policy resolution mechanism.   IMO, it is better to have fewer network elements making subscriber-aware policy decisions.

   Ron

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Wednesday, July 24, 2013 6:17 PM
To: Ron Parker
Cc: Joel M. Halpern; [email-masked]
Subject: Re: [nsc] Service chaining architecture question

Ron,

Sent from my iPhone

On Jul 24, 2013, at 6:02 PM, "Ron Parker" <[email-masked]> wrote:

>> construction and this being combined with application "cooperation" 
>> to preserve pairwise mappings of either VID/NIC tuples or simply 
>> NICs) currently exist as potential vehicles for preserving chain 
>> context and avoiding per hop classification. Anything else will be 
>> implemented more or less the same way and have exactly the same set 
>> of scaling and application design issues...Some extra information 
>> available on a single interface, or achieved by mapping chain 
>> instances onto one of a plurality of interfaces....
>> 
>> expected to participate in, even allowing for dynamic 
>> reclassification of flows at a chain ingress to "skip a few 
>> functions".... These are things that are fully operationalized in 
>> OSS, have policy associated with, have been industrialized and 
>> demonstrated to work prior to deployment. Going all combinatorial on this will break that big time....
>> 
>> *To:* [email-masked] <mailto:[email-masked]>; 
>> [email-masked] <mailto:[email-masked]>
>> ---------------------------------------------------------------------
>> -
>> --
>> 
>> meta-data and that a layer underneath should provide the mediation 
>> and that we use a well defined interface to the application/service 
>> to indicate the chain. In the context of Cloud/enterprise environment 
>> I can see this work given you can use a dedicate VLAN e.g. within the tenant.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 24 Jul 2013 22:27:49 +0000

Hi Ron,

I would think that either way requires an "identifier" to "service function" mapping to be available at the service invocation point.

Sent from my iPhone

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 24 Jul 2013 22:53:56 +0000

Agree with Ron that it is better to have fewer nodes in network to make subscriber-aware policy decisions.

Besides, it is not uncommon for multiple subscribers to share same sequence of service modules. In this environment, if the network edge nodes, such as Broadband Network Gateway or Cell Site Gateway, can use Layer 2 or 3 labels to mark the traffic, the subsequent network nodes can steer traffic to the needed service modules without looking into "Mega data" or other higher layer fields in the data frames. 

This approach can make "service chain" work without making changes to majority of existing deployed network elements. 

Linda  

> Yes, that could work, too, conceptually.   But it does require that
> each coarsely-defined network service have access to a subscriber-aware
> policy resolution mechanism.   IMO, it is better to have fewer network
> elements making subscriber-aware policy decisions.

> > IMO, the primary reason for understanding the subscriber identity at
> a network service is to choose from a differentiated set of policies.
> I think there is utility and efficiency in driving that selection from
> one place -- the network services classifier.     Say there were 2
> groups of subscribers -- children and adults.   Let's now define 2
> chains, where the chains have a business-based meaning to the operator.
> Chain 1 = HTTP-filter-child + Firewall-child.   Chain 2 = HTTP-filter-
> adult + Firewall-adult.    The referenced network services are logical
> and it is possible, but not required, that multiple logical network
> services be located at the same IP address or FQDN.     Conveying the
> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain ID, ...)
> allows the IP-addressable server that realizes these service(s) to know
> two things -- 1) which logical network function should be invoked and 2)
> which logical network function is next.
> >
> > Thanks.
> > Ron
> >

---

From: David Allan I <[email-masked]>
Date: Wed, 24 Jul 2013 22:56:05 +0000

Hmmm

I would have a problem with this as I'm driving up the combinatorial number of chains on the basis of identifying  specific policy classes. The actual enforcement action may be similar, all HTTP requests processed against a common database with multiple permit-deny classes in it. Specifying multiple chains as a mechanism of encoding permit deny class is a hopeless overloading of the chain identifier and pushing some degree of function awareness into the front end chain classifier.

This places an inappropriate burden on both the initial classification function as well as the intra chain networking. At the same time I would actually expect the individual HTTP filter function instances to participate in the multiple sub-class chains as it likely is a common filtering database, and I wish to have a larger  flow base using that function at any given time for statistical load balancing purposes.  

My opinion of what a chain ID should do is identify a set of PEPs/VFs to be traversed by any flow mapped to the chain, not to try and subclass PEPs/VFs of common function by making the front end classification subclass aware.  That actually strike me as an impediment to TTM as introduction of a new subclass involves software upgrade of multiple functions in the chain, but the function itself and the front end classifier...

My 2 cents
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Wednesday, July 24, 2013 3:02 PM
To: Joel M. Halpern
Cc: [email-masked]
Subject: Re: [nsc] Service chaining architecture question

Joel,

Thanks.
Ron

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Wednesday, July 24, 2013 4:47 PM
To: Ron Parker
Cc: [email-masked]
Subject: Re: [nsc] Service chaining architecture question

Ron,

Yours,
Joel

On 7/24/13 4:05 PM, Ron Parker wrote:
> application design issues...Some extra information available on a 
> single interface, or achieved by mapping chain instances onto one of a

---

From: David Allan I <[email-masked]>
Date: Wed, 24 Jul 2013 23:11:14 +0000

Joys of autocorrect....

An edit below c/but/both/

Cheers
D

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Wednesday, July 24, 2013 3:56 PM
To: Ron Parker; Joel M. Halpern
Cc: [email-masked]
Subject: Re: [nsc] Service chaining architecture question

Hmmm

My opinion of what a chain ID should do is identify a set of PEPs/VFs to be traversed by any flow mapped to the chain, not to try and subclass PEPs/VFs of common function by making the front end classification subclass aware.  That actually strike me as an impediment to TTM as introduction of a new subclass involves software upgrade of multiple functions in the chain, both the function itself and the front end classifier...

My 2 cents
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Wednesday, July 24, 2013 3:02 PM
To: Joel M. Halpern
Cc: [email-masked]
Subject: Re: [nsc] Service chaining architecture question

Joel,

Thanks.
Ron

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Wednesday, July 24, 2013 4:47 PM
To: Ron Parker
Cc: [email-masked]
Subject: Re: [nsc] Service chaining architecture question

Ron,

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 24 Jul 2013 19:12:28 -0400

Yes, having the chain ingress node mark the traffic makes good sense.
Having it mark the subscriber identity and the chain to be traversed 
seems quite sensible.

The difference I think I have with Ron is that he proposes to use one 
identifier for both entities.  That causes, as Dave said, a 
combinatorial explosion.  Rather, use two fields.  Two VLANs.  Two MPLS 
labels.

And if the existing boxes don't know how to handle that (as seems 
likely) then we need a proxy / support function to translate the common 
protocol into whatever they used before we got something generally 
usable out there.

Yours,
Joel

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 24 Jul 2013 23:29:46 +0000

Hi Linda,

The service chaining "problem" is not just about data plane and getting
packets from point A to point B. That's the easy bit. True, some basic
services may be just fine with this approach but the wider issue is how to
share "intelligence" between the network and services, and between
services. A simple label allocation may not satisfy such requirements.
Mapping 1:1 chain-id<->policy seems the wrong direction to take imho.

On 7/24/13 6:53 PM, "Linda Dunbar" <[email-masked]> wrote:

>Besides, it is not uncommon for multiple subscribers to share same
>sequence of service modules. In this environment, if the network edge
>nodes, such as Broadband Network Gateway or Cell Site Gateway, can use
>Layer 2 or 3 labels to mark the traffic, the subsequent network nodes can
>steer traffic to the needed service modules without looking into "Mega
>data" or other higher layer fields in the data frames.
>
>This approach can make "service chain" work without making changes to
>majority of existing deployed network elements.
>
>Linda  
>
>
>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 24 Jul 2013 23:30:09 +0000

Joel,

> identifier for both entities.

[Linda] I hope you don't mean per subscriber identity, do you? With today's PCRF, subscribers are categorized based on their subscription types. Throughout the network, the "subscription types" dictate what service modules their corresponding traffic need to traverse through.
Some service modules might need to examine packets deeper (i.e. look into payload) for their intended functions. They may need to extract the "HTTP header" or HTTP messages from one or multiple packets.

That causes, as Dave said, a
> combinatorial explosion.  Rather, use two fields.  Two VLANs.  Two MPLS

[Linda] It doesn't have to be two "VLANs" or two MPLS, right?
The subscriber identity could be some bits in the payload.

> Layer 2 or 3 labels to mark the traffic, the subsequent network nodes
> can steer traffic to the needed service modules without looking into
> "Mega data" or other higher layer fields in the data frames.
> >
> >>>> logical in such a way that the identity of the logical function
> may
> >> also
> >>>> content-filter-adults-no-porn, content-filter-adults (I'm taking
> no
> >> stand on opt-in vs. opt-out, Mr.
> >>>> demonstrated to work prior to deployment. Going all combinatorial
> on
> >> this will break that big time....
> >>>>
> >>>> ------------------------------------------------------------------
> --
> >> -
> >>>> -
> >>>> --
> >>>>

---

From: "Pham, Chuong D" <[email-masked]>
Date: Thu, 25 Jul 2013 09:30:37 +1000

Wim,
We are also investigating service chaining in a Mobile/Fixed Broadband service provider environment.
I understand that your question is about what information element can be used to identify an individual user i.e. a Mobile subscriber in the meta-data set. If this is correct then we have the same concern.
The way I envision it works is for the per-subscriber meta-data to be obtained/created in the "control plane". One example is using Mobile/Fixed user identification such as MSISDN and MAC-address to identify the users in the meta-data. The "control plane" entity would receive identification information via control plane messages from entities such as PCRF and AAA server. Such messages also have the user's dynamically allocated IP addresses.  The control plane entity will push identity <User identity>-<IP address> value pairs to the edge node. The edge node now can use these value pairs to match with per-user policies and include the information in the meta-data.

From: Henderickx, Wim (Wim) [mailto:[email-masked]]
Sent: Wednesday, 24 July 2013 7:52 PM
To: [email-masked]
Subject: [nsc] Service chaining architecture question

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 24 Jul 2013 19:34:58 -0400

I would not be surprised if we want all three of
Service Chain,
Service Policy, and
Subscriber / user identity
in the packet.
If the Chain is in the VLAN / MPLS label, then we can discuss whether 
the other information goes in additional ids of the same type or in a 
carried header.  I can construct arguments for either approach.

It may be easier to just carry the subscriber identity, and used the 
same management systems to assign policies to the devices that care.  I 
am concerned that it may not be practical to use a single policy 
identifier to specify which HTTP rule set to use, which Firewall rule 
set to use, and then which specific policy for other user selected 
policy applications.

Yours,
Joel

On 7/24/13 7:30 PM, Linda Dunbar wrote:
> [Linda] I hope you don't mean per subscriber identity, do you? With
> today's PCRF, subscribers are categorized based on their subscription
> types. Throughout the network, the "subscription types" dictate what
> service modules their corresponding traffic need to traverse through.
> Some service modules might need to examine packets deeper (i.e. look
> into payload) for their intended functions. They may need to extract the
> "HTTP header" or HTTP messages from one or multiple packets.

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 24 Jul 2013 23:41:42 +0000

Jim, 

Do you mean that some service modules need information inserted by the upstream service modules to make the needed actions? 

That is fine. Then those "mega data" inserted by the service modules are really internal among the service modules. 

Layer 4-7 services have been discussed in ONF for quite some time. We have decided to describe service modules in two categories: Proxy based and packet based. 

*	Proxy based service functions: these service functions terminate original packets, may reassemble multiple packets, reopen a new connection, or formulate new packets based on the received packets.

*	Packet based service functions: these service modules maintain original packets, i.e. they don't make changes to packets traversed through except possibly changing some header fields.

Linda

> Sent: Wednesday, July 24, 2013 6:30 PM
> To: Linda Dunbar; Ron Parker
> Cc: [email-masked]; Joel M. Halpern
> >Agree with Ron that it is better to have fewer nodes in network to
> make
> >subscriber-aware policy decisions.
> >
> can
> >> >> definition of a service function.   Consider a service function
> to
> >> be
> >> >> -----------------------------------------------------------------
> ---
> >> -
> >> >> -
> >> >> --
> >> >>
> >> >> I have a basic question with respect to the
> architecture/framework
> >> so

---

From: David Allan I <[email-masked]>
Date: Wed, 24 Jul 2013 23:43:59 +0000

My suspicion is that source IP address would stunt double for subscriber ID for the forseeable future, and NAT in the home means effective maintenance of subclassing the subscriber (for example associating children with specific devices behind the NAT) is an intractable problem at the classifier unless it becomes a full ALG/service portal in its own right, and duplicating functionality best deployed in the VF....

Cheers
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, July 24, 2013 4:35 PM
To: Linda Dunbar
Cc: [email-masked]; Jim Guichard (jguichar); Ron Parker
Subject: Re: [nsc] Service chaining architecture question

I would not be surprised if we want all three of Service Chain, Service Policy, and Subscriber / user identity in the packet.
If the Chain is in the VLAN / MPLS label, then we can discuss whether the other information goes in additional ids of the same type or in a carried header.  I can construct arguments for either approach.

It may be easier to just carry the subscriber identity, and used the same management systems to assign policies to the devices that care.  I am concerned that it may not be practical to use a single policy identifier to specify which HTTP rule set to use, which Firewall rule set to use, and then which specific policy for other user selected policy applications.

Yours,
Joel

On 7/24/13 7:30 PM, Linda Dunbar wrote:
> into payload) for their intended functions. They may need to extract 
> the "HTTP header" or HTTP messages from one or multiple packets.
>> combinatorial explosion.  Rather, use two fields.  Two VLANs.  Two 
>> MPLS labels.
>> likely) then we need a proxy / support function to translate the 
>> common protocol into whatever they used before we got something 
>> generally usable out there.
>>
>> Yours,
>> Joel
>>
>> make subscriber-aware policy decisions.
>> >
>> nodes, such as Broadband Network Gateway or Cell Site Gateway, can 
>> use Layer 2 or 3 labels to mark the traffic, the subsequent network 
>> nodes can steer traffic to the needed service modules without looking 
>> into "Mega data" or other higher layer fields in the data frames.
>> >
>> >>>> further instantiated at the logical level based on 
>> >>>> differentiated policies such as content-filter-children, 
>> >>>> differentiated policies and the number of combinations will 
>> >>>> grow,
>> at
>> >>>> least modestly.
>> >>>>
>> >>>> Thanks,
>> >>>>
>> >>>> Ron
>> >>>>
>> >>>> Saying functions will have a problem with something that exists 
>> >>>> as
>> a
>> >>>> context and avoiding per hop classification. Anything else will 
>> >>>> be implemented more or less the same way and have exactly the 
>> >>>> same
>> set
>> >>>> of scaling and application design issues...Some extra 
>> >>>> information available on a single interface, or achieved by 
>> >>>> mapping chain instances onto one of a plurality of interfaces....
>> >>>>
>> >>>> But to back up... I'm not a carrier employee but I cannot 
>> >>>> envision
>> a
>> >>>> number is realistic for  the number of chains a function 
>> >>>> instance
>> is
>> >>>> functions".... These are things that are fully operationalized 
>> >>>> in OSS, have policy associated with, have been industrialized 
>> >>>> and demonstrated to work prior to deployment. Going all 
>> >>>> combinatorial
>> on
>> >>>> So are we really discussing a function participating in more 
>> >>>> than
>> a
>> >>>> able to handle packets coming from/going to potentially 
>> >>>> thousands
>> of
>> >>>> Ideally this should be as simple as possible without heavy 
>> >>>> impact
>> on
>> >>>> the application itself (might be difficult to achieve but from 
>> >>>> my experience it is not very likely, that there will be big 
>> >>>> rewrites
>> of
>> >>>> far mentioned in the drafts in NSC. I understand the meta-data 
>> >>>> is
>> a
>> >>>> the NSC domain and identifies the chain of service functions. 
>> >>>> Now
>> my
>> >>>> understanding is that the services/applications are unaware of 
>> >>>> the meta-data and that a layer underneath should provide the 
>> >>>> mediation and that we use a well defined interface to the
>> application/service
>> >>>> I can see this work given you can use a dedicate VLAN e.g. 
>> >>>> within
>> >> the tenant.
>> >>>> fixed and here this becomes more tricky afais. In the 
>> >>>> residential environment we can't expose a VLAN per 
>> >>>> application/service per
>> chain

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Wed, 24 Jul 2013 23:47:16 +0000

> If the Chain is in the VLAN / MPLS label, 

Yes. We should separate signaling of network connectivity from metadata associated with the payload. These are two separate problems. In a data center, some VMs will be participating in service chains, some not, at a given time. We don't want to end up with two different forwarding paradigms for both types of those VMs.

> then we can discuss whether the other information goes in additional ids of the same type or in a

We should avoid introducing a new header for carrying metadata (such as subscriber-id). The same result can be achieved by using the IP header of the payload packet (such as IP option or flow label). 

> set to use, and then which specific policy for other user selected

Agree. Or use a *local* (to a given appliance) logical interface per service "profile" but. Typically though, a "service" would be realized by software and the goal would be to run it on a VM of a virtualized x86 server. It is cheap to spin a VM. So, instead of having different profiles in the same VM it will be much simpler to manage a larger number of VMs, each with limited bandwidth.
 
Maria

> the
> MPLS
> common
> use
> >> >> each coarsely-defined network service have access to a
> subscriber-
> >> aware
> >> >> Or alternatively carry the subscriber awareness in metadata
> thereby
> >> >> utilizing a single chain.
> >> >>
> >> >> Sent from my iPhone
> >> >>
> >> >>> IMO, the primary reason for understanding the subscriber
> identity
> >> at
> >> >> allows the IP-addressable server that realizes these service(s)
> to
> >> know
> >> >> ID to decide which exact content filtering behavior it should
> apply.
> >> I
> >> >>>> distinction of coarse-grained definition of a service function
> vs.
> >> >> finer-grained
> differentiated
> >> >>>> policies.   The HTTP content filtering network function is
> really
> >> 3
> >> >>>> logical network functions from the perspective of inclusion in
> a
> >> >> service
> information
> in
> >> >>>> I think not only effectivness/scalability might be a problem
> but
> >> >> also
> >> >>>> experience it is not very likely, that there will be big
> rewrites
> >> of
> the
> residential

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 24 Jul 2013 23:48:41 +0000

Hi Linda,

There are actually many use cases. Here are just a small sample:

- forwarding information, such as VRF: the ingress VRF of the packet on
the 1st classifier.  Using this encoded VRF the last node in the chain can
place the (post service(s)) packets into the right forwarding context.
This way the service chain is "vrf enabled" without the service
participating in the routing topology, and there is no need to return the
packets, after chaining, to the original classifier.

- application id: if the first classifier knows the application (from
direct classification, or from an external source such as a VM manager),
that application can be carried in the metadata.  For example, the
classifier imposes a value that indicates that the packet belong to
"oracle".  The firewall now no longer has to try to figure out if packets
are "oracle" or not, and can permit/deny based on the pre-classified
context.  This model gets even more powerful when extended to services:
they can update contexts as well and share it amongst themselves.

- External information about a flow: for example, PCRF subscriber
information can be encoded in the data plane.  The services can use this
context to apply subscriber-aware policy without having to participate in
the policy/control planes.

On 7/24/13 7:41 PM, "Linda Dunbar" <[email-masked]> wrote:

>Jim, 
>
>Do you mean that some service modules need information inserted by the
>upstream service modules to make the needed actions?
>
>That is fine. Then those "mega data" inserted by the service modules are
>really internal among the service modules.
>
>Layer 4-7 services have been discussed in ONF for quite some time. We
>have decided to describe service modules in two categories: Proxy based
>and packet based. 
>
>*	Proxy based service functions: these service functions terminate
>original packets, may reassemble multiple packets, reopen a new
>connection, or formulate new packets based on the received packets.
>
>*	Packet based service functions: these service modules maintain original
>packets, i.e. they don't make changes to packets traversed through except
>possibly changing some header fields.
>
>Linda
>
>
>> as a
>> envision a

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 24 Jul 2013 23:52:44 +0000

Joel, 

Agree with what you said and your concern. I think that Service Chain from subscriber perspective is different from service chain from network traffic steering perspective. The information to be passed among service modules for specific flows is at another dimension. 

>From user's (or subscriber) perspective, the service chain is a sequence of service functions, such as Chain#1 {s1, s4, s6}, Chain#2{s4, s7} applied to the user's (or subscriber's) traffic.

>From the traffic steering perspective, a Service Chain guarantees that specific data flows go through a specific sequence of service modules at designated points along the flow paths in the network. Those flows can be aggregated traffic among multiple subscribers. 

>From traffic steering point of view, one service chain consists of:
-	Identifier
-	{Steering point List}
-	Steering Point #1, {list of Service Modules}
-	Steering Point #2, {list of Service Modules}
-	...

Two service chains with the same sequence of service modules but different steering points should be considered as two different service chains from traffic steering point of view.

Linda

> Sent: Wednesday, July 24, 2013 6:35 PM
> To: Linda Dunbar

---

From: Ron Parker <[email-masked]>
Date: Thu, 25 Jul 2013 00:42:20 +0000

Thanks, all, for a lively discussion on this topic.

One thing that flavors the discussion of network service chaining is the definition of "service".   It really means different things to different people.   We networking types tend to look at it as a software application or software system composed of multiple software applications (i.e., an HTTP content filter).   But when I interact with the business folks, especially on the operator side, I hear a different notion of "service" -- something subscribers pay for, government mandates, etc.   This is why, IMO, it is defensible to say that the HTTP-content-filter-children is a distinct service from HTTP-content-filter-adult, even if both are realized on the same server by the same software application using the same global URL database.

It does sound like at least some that have chimed in do feel that both the general service type (i.e., HTTP content filter) and the policy set need to be conveyed in some manner.    How to do this is a set of tradeoffs around control plane protocol and data plane encapsulation.    Without any control plane, both types of information need to be on the wire in some form.   I will assume that the policy set identity is distinct at each service instance (i.e, policy set 2 at the HTTP content filter does not imply the same set of subscribers as policy set 2 at the firewall).   I will also assume that the meaning and interpretation of a policy set identity is specific to that type of service and probably to the vendor that supplied the service.   This is similar to when a PCRF names a PCC rulebase rather than supplying the full set of explicit PCC rules.     

The advantage of a single chain ID that can be interpreted as a sequence of {service-type-instance, policy-set} is that it minimizes the per-packet encapsulation requirement (i.e., a single GRE key could suffice).   The disadvantage that has been pointed out is that global coordination of this identity is required and the number of combinations could become unwieldy.   

Another approach could be to have a new encapsulation that represents a stack of 2-tuples {service-ip-address, service-specific-policy-id}, or even 3-tuples {service-ip-address, service-type, service-specific-policy-id} where the 3-tuple brings the added advantage of allowing for multiple dissimilar services realized by the same server at the same server ip address.   The advantage of this approach is that it avoids the combinatorial explosion problem, but it requires a larger and variable length encapsulation.

If the global chain id approach is used, a control plane protocol could be used to distribute the definitions of each chain (i.e, each chain is really a stack of 2-tuples or 3-tuples, per description above).    

Thanks.

    Ron

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, July 24, 2013 7:35 PM
To: Linda Dunbar
Cc: [email-masked]; Jim Guichard (jguichar); Ron Parker
Subject: Re: [nsc] Service chaining architecture question

Yours,
Joel

On 7/24/13 7:30 PM, Linda Dunbar wrote:
>> >> thereby utilizing a single chain.
>> >>
>> >> Sent from my iPhone
>> >>

---

From: David Allan I <[email-masked]>
Date: Thu, 25 Jul 2013 01:25:43 +0000

I would prefer to think what is on the wire facilitates the forwarding of frames, e.g. chain ID (analogous to VPN), perhaps an entropy shorthand to help both LB and  testabilty....and facilitates uniquely identifying the subscriber. (within the bounds of the art of the possible, see my last post on NAT). I cannot envision a need for more. And ideally I should be able to align such an approach with existing Cloud technologies.

The individual VF should be able to determine actual subscriber to a granularity suitable for it's purposes and obtain the necessary profile information via a northbound interface. If you then read between the lines,  I'm all for separation of concerns as much as possible ;-) and not creating dependencies across chain components beyond the networking level.

I also do not see a huge difference between a service chain, and any other flow of information across a string of processing elements. Just in one application, the packet is preserved with perhaps a bit of fondling, and in others the content may be completely deconstructed, and repackaged into a set of transactions....and what is on the wire between chain components does not remotely look like what went in the front end...

Cheers
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Wednesday, July 24, 2013 5:42 PM
To: Joel M. Halpern; Linda Dunbar
Cc: [email-masked]; Jim Guichard (jguichar)
Subject: Re: [nsc] Service chaining architecture question

Thanks.

    Ron

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Wednesday, July 24, 2013 7:35 PM
To: Linda Dunbar
Cc: [email-masked]; Jim Guichard (jguichar); Ron Parker
Subject: Re: [nsc] Service chaining architecture question

Yours,
Joel

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 25 Jul 2013 06:23:52 +0000

On 7/25/13 5:22 AM, "Linda Dunbar" <[email-masked]> wrote:

>Joel, 
>
>Agree with what you said and your concern. I think that Service Chain
>from subscriber perspective is different from service chain from network
>traffic steering perspective. The information to be passed among service
>modules for specific flows is at another dimension.
>
>
>From user's (or subscriber) perspective, the service chain is a sequence
>of service functions, such as Chain#1 {s1, s4, s6}, Chain#2{s4, s7}
>applied to the user's (or subscriber's) traffic.
>
>
>From the traffic steering perspective, a Service Chain guarantees that
>specific data flows go through a specific sequence of service modules at
>designated points along the flow paths in the network. Those flows can be
>aggregated traffic among multiple subscribers.
>

==
>Two service chains with the same sequence of service modules but
>different steering points should be considered as two different service
>chains from traffic steering point of view.
==
SK> That is the definition of "Service Path" in NSH - actual forwarding
path; you get two *service paths* for the same *service chain*, in your
example. Service Chain exists in the control plane while Service Path
exists in the data plane, so to speak.

Surendra.

---

From: <[email-masked]>
Date: Thu, 25 Jul 2013 09:46:23 +0200

Hi Joel,

I'm not sure there is a need for such granularity (i.e., individual rules level) which may lead to unjustified complications. Some of the policies can be configured off-band without having the need to carry it the packet itself.

If instead distinct (few) profiles are configured in a device, this can be considered as distinct instances of the same function but can be distinguished using distinct identifiers. FWIW, we have touched in this point at: http://tools.ietf.org/html/draft-boucadair-network-function-chaining-02#section-6.2

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la part de Joel
>M. Halpern
>Envoyé : jeudi 25 juillet 2013 01:35
>À : Linda Dunbar
>Cc : [email-masked]; Jim Guichard (jguichar); Ron Parker
>Objet : Re: [nsc] Service chaining architecture question
>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 25 Jul 2013 16:01:15 +0000

Surendra, 

Thank you very much for the clarification. I like this distinction: Service Path & Service Chain. 

Is "Service Chain Path" more accurate? 
"Service path" can be easily interpreted as Network Service Path, like the path along a sequence of network nodes that data packets traverse. They are so much like today's network. 

Is NSC also try to re-characterize today's network using a new term? 
I can see that all today's network elements can be re-characterized as various service modules, like L2/L3 forwarding service, GRE encapsulating service, pushing/popping MPLS label  service, etc, but is it necessary to do so? 

Linda

> >> >> > This approach can make "service chain" work without making
> changes
> >> to
> >> >> >> I think there is utility and efficiency in driving that
> selection
> >> >> from
> >> >> >> one place -- the network services classifier.     Say there
> were
> >> 2
> >> >> >> groups of subscribers -- children and adults.   Let's now
> define
> >> 2
> >> >> >> Chain 1 = HTTP-filter-child + Firewall-child.   Chain 2 =
> HTTP-
> >> >> filter-
> >> >> >> services be located at the same IP address or FQDN.
> Conveying
> >> >> the
> >> >> >> two things -- 1) which logical network function should be
> invoked
> >> >> and 2)
> >> >> >>>      maybe I am missing something, but you seem to lay out
> very
> >> >> nicely
> >> >> >>>> I agree that the number of chains is unlikely to scale to
> vast
> >> >> >> numbers
> >> >> >>>> imply some differentiated behavior.   For example, a
> conceptual
> >> >> >> function
> >> >> >>>> is HTTP content filtering.    This conceptual function can
> then
> >> be
> >> >> >>>> Cameron).   It may be that the same network element
> (dedicated
> >> >> >> physical
> >> >> >>>> chain.   Now extend this to multiple conceptual functions
> that
> >> >> >> utilize
> >> >> >>>> *From:[email-masked] [mailto:[email-masked]]
> *On
> >> >> Behalf
> >> >> >>>> Of *David Allan I
> >> >> >>>> potential rationale for defining something new with exactly
> the
> >> >> same
> >> >> >>>> VLANs on a vNIC or multiple vNICs (depending on the
> application
> >> >> >> stack
> >> >> >>>> implemented more or less the same way and have exactly the
> same
> >> >> set
> >> >> >>>> carrier offering potentially 1000s of distinct service
> bundles
> >> >> >> ("pick
> >> >> >>>> handful of chain instances? And either a plurality of vNICs
> or
> >> >> VIDs
> >> >> >>>> the fact that not all applications (service bringing
> functions)
> >> >> are
> >> >> >>>> ------------------------------------------------------------
> ---
> >> ---
> >> >> --
> >> >> >> -
> >> >> >>>> -
> >> >> >>>> --
> >> >> >>>>
> >> >> >>>> [mailto:[email-masked]] *Im Auftrag von *Henderickx,
> Wim
> >> >> (Wim)
> >> >> >>>> mechanism to avoid multiple re-classifications when the
> packet
> >> >> >> enters
> >> >> >>>> However we also try to address residential use cases for
> mobile
> >> >> and
> >> >> >>>> environment we can't expose a VLAN per application/service
> per
> >> >> chain
> >> >> >>>> since this would not be very effective. So I am wondering
> how
> >> we
> >> >> >>>> envision this to work?
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>

---

From: Paul Quinn <[email-masked]>
Date: Thu, 25 Jul 2013 09:26:24 -0700

Hi Maria,

> Yes. We should separate signaling of network connectivity from metadata associated with the payload. These are two separate problems. In a data center, some VMs will be participating in service cha…

IMHO, you want to separate both chaining information and metadata.  The chain information is used to provide a form of indirection into the existing forward models.

> We should avoid introducing a new header for carrying metadata (such as subscriber-id). The same result can be achieved by using the IP header of the payload packet (such as IP option or flow label…

Adding data to existing IP headers might not prove viable, most fields are either spoken for, or have significant technical limitations.  For example, IP options are usually filtered/dropped and rarely handled in the fast path for forwarding.

> Agree. Or use a *local* (to a given appliance) logical interface per service "profile" but. Typically though, a "service" would be realized by software and the goal would be to run it on a VM of a…

In many environments, physical and/or shared services must be supported as well for a variety of reasons.

---

From: Ron Parker <[email-masked]>
Date: Thu, 25 Jul 2013 17:30:10 +0000

Linda,

When the classifier determines the appropriate chain, it should do so in 2 steps.   In the first step, it should determine the sequence of network services to be applied where each service is abstract and is not yet mapped to an addressable network entity.   In the second step, each abstract service function is mapped to an addressable entity that will be engaged to actually perform the required service.   This approach would lend itself to 1:1 mapping as well as 1:N mapping, implying a load balancing function may be performed by the classifier.   This is covered, in part, by draft-boucadair-network-function-chaining-02 section 3.4, Building NLFC Policy Tables.

   Ron

-----Original Message-----
From: Linda Dunbar [mailto:[email-masked]] 
Sent: Thursday, July 25, 2013 12:01 PM
To: Surendra Kumar (smkumar); Joel M. Halpern
Cc: [email-masked]; Jim Guichard (jguichar); Ron Parker
Subject: RE: [nsc] Service chaining architecture question

Surendra, 

Linda

> SK> That is the definition of "Service Path" in NSH - actual 
> SK> forwarding
> path; you get two *service paths* for the same *service chain*, in 
> your example. Service Chain exists in the control plane while Service 
> Path exists in the data plane, so to speak.
> 
> Surendra.
> 
> >
> >Linda
> >
> >> I would not be surprised if we want all three of Service Chain, 
> >> Service Policy, and Subscriber / user identity in the packet.
> >> It may be easier to just carry the subscriber identity, and used 
> >> the same management systems to assign policies to the devices that care.
> I
> >> >> The difference I think I have with Ron is that he proposes to 
> >> >> use
> >> one
> >> >> > Agree with Ron that it is better to have fewer nodes in 
> >> >> > network
> to
> >> >> >> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH 
> >> >> >> chain
> >> >> ID, ...)
> >> >> >>>> You may already be on this page, but I wanted to point out 
> >> >> >>>> a distinction of coarse-grained definition of a service
> function
> >> vs.
> >> >> >> finer-grained
> >> >> >>>> 53 from column A and 49 from column B"). So I suspect a 
> >> >> >>>> much
> >> >> smaller
> >> >> >>>> [mailto:[email-masked]] *On Behalf Of *Henderickx, 
> >> >> >>>> Wim
> >> (Wim)
> >> >> >>>> different VLANs at the same time. VLANs will work in 
> >> >> >>>> certain environments but not in all. I see the need for an
> information

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Thu, 25 Jul 2013 18:03:40 +0000

Hi Paul,

> > Yes. We should separate signaling of network connectivity from
> metadata associated with the payload. These are two separate problems.
> In a data center, some VMs will be participating in service chains,
> some not, at a given time. We don't want to end up with two different
> forwarding paradigms for both types of those VMs.
> >
> 
> IMHO, you want to separate both chaining information and metadata.  The
> chain information is used to provide a form of indirection into the
> existing forward models.

Could you clarify what you mean by "a form of indirection into the existing forward models", 
especially in the scenario of virtualized servers (services running in VMs)? 

> > We should avoid introducing a new header for carrying metadata (such
> as subscriber-id). The same result can be achieved by using the IP
> header of the payload packet (such as IP option or flow label).
> >
> 
> Adding data to existing IP headers might not prove viable, most fields
> are either spoken for, or have significant technical limitations.  For
> example, IP options are usually filtered/dropped and rarely handled in
> the fast path for forwarding.

IMO, services should be deployed on the "edge" of the network in software. There is only one type of forwarding in software. 

> > Agree. Or use a *local* (to a given appliance) logical interface per
> service "profile" but. Typically though, a "service" would be realized
> by software and the goal would be to run it on a VM of a virtualized
> x86 server. It is cheap to spin a VM. So, instead of having different
> profiles in the same VM it will be much simpler to manage a larger
> number of VMs, each with limited bandwidth.
> >
> 

If a physical (typically, legacy) device needs to participate in a service chain, I would proxy it.

Maria
 
> >>>>>>>> --------------------------------------------------------------
> -
> >> ---
> >>>> --
> >>>>>> -
> >>>>>>>> -
> >>>>>>>> --
> >>>>>>>>

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 25 Jul 2013 18:05:35 +0000

On 7/25/13 6:12 AM, "Ron Parker" <[email-masked]> wrote:

>One thing that flavors the discussion of network service chaining is the
>definition of "service".   It really means different things to different
>people.   We networking types tend to look at it as a software
>application or software system composed of multiple software applications
>(i.e., an HTTP content filter).   But when I interact with the business
>folks, especially on the operator side, I hear a different notion of
>"service" -- something subscribers pay for, government mandates, etc.
>This is why, IMO, it is defensible to say that the
>HTTP-content-filter-children is a distinct service from
>HTTP-content-filter-adult, even if both are realized on the same server
>by the same software application using the same global URL database.
>
>It does sound like at least some that have chimed in do feel that both
>the general service type (i.e., HTTP content filter) and the policy set
>need to be conveyed in some manner.    How to do this is a set of
>tradeoffs around control plane protocol and data plane encapsulation.
>Without any control plane, both types of information need to be on the
>wire in some form.   I will assume that the policy set identity is
>distinct at each service instance (i.e, policy set 2 at the HTTP content
>filter does not imply the same set of subscribers as policy set 2 at the
>firewall).   I will also assume that the meaning and interpretation of a
>policy set identity is specific to that type of service and probably to
>the vendor that supplied the service.
SK> The last statement is very true and I want add to it a bit: There are
two extremes to this: a) All services in the solution (or in a service
chain) are controlled by the same policy/control planes, in which case the
same policy-id may be relevant across all services. The policy-plane may
organize the policies in that fashion. b) Every service in the solution
(or chain) belongs to a different vendor and they all have their own
policy planes. Obviously the policy-id at one service has no meaning at
another or has a different meaning.
In fact, some services may not even rely on external
classification/policies or meta-data.

>   This is similar to when a PCRF names a PCC rulebase rather than
>supplying the full set of explicit PCC rules.
>     
>
>The advantage of a single chain ID that can be interpreted as a sequence
>of {service-type-instance, policy-set} is that it minimizes the
>per-packet encapsulation requirement (i.e., a single GRE key could
>suffice).   The disadvantage that has been pointed out is that global
>coordination of this identity is required and the number of combinations
>could become unwieldy.
>
>Another approach could be to have a new encapsulation that represents a
>stack of 2-tuples {service-ip-address, service-specific-policy-id}, or
>even 3-tuples {service-ip-address, service-type,
>service-specific-policy-id} where the 3-tuple brings the added advantage
>of allowing for multiple dissimilar services realized by the same server
>at the same server ip address.   The advantage of this approach is that
>it avoids the combinatorial explosion problem, but it requires a larger
>and variable length encapsulation.
>
>If the global chain id approach is used, a control plane protocol could
>be used to distribute the definitions of each chain (i.e, each chain is
>really a stack of 2-tuples or 3-tuples, per description above).
SK> Keeping the chain ID (actually, the service path ID) for the purposes
of service forwarding is simple and clean. One can definitely encode these
identifiers to mux a lot of things into it but it will get messy. They are
better solved differently. Since classification is not limited to the
network; a service-plane entity could re-classify and re-steer using a
different service-path based on the re-classification. This
re-classification may be based on the subscriber-policy for instance. In
this sense, a service-path can be influenced while still keeping it simple.
A global chain-id mapped to a unique data-plane-id (service path id)
allows for keeping (service) forwarding path distinct from policy and
other aspects. I do not believe you need large/complex encapsulations.
Yes, you do need control-plane co-ordination, but may not be with all
services, depending on how it is done.

Surendra.

>I would not be surprised if we want all three of Service Chain, Service
>Policy, and Subscriber / user identity in the packet.
>If the Chain is in the VLAN / MPLS label, then we can discuss whether the
>other information goes in additional ids of the same type or in a carried
>header.  I can construct arguments for either approach.
>
>It may be easier to just carry the subscriber identity, and used the same
>management systems to assign policies to the devices that care.  I am
>concerned that it may not be practical to use a single policy identifier
>to specify which HTTP rule set to use, which Firewall rule set to use,
>and then which specific policy for other user selected policy
>applications.
>
>Yours,
>Joel
>

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 25 Jul 2013 18:32:40 +0000

On 7/25/13 11:33 PM, "NAPIERALA, MARIA H" <[email-masked]> wrote:

>IMO, services should be deployed on the "edge" of the network in
>software. There is only one type of forwarding in software.
SK> Services should be "deployable" in software and so should they be in
physical appliances - we need to account for them given the
transitional/hybrid data centers that exist today, as one reason.

Surendra.

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 25 Jul 2013 18:49:21 +0000

On 7/25/13 6:55 AM, "David Allan I" <[email-masked]> wrote:

>I would prefer to think what is on the wire facilitates the forwarding of
>frames, e.g. chain ID (analogous to VPN), perhaps an entropy shorthand to
>help both LB and  testabilty....and facilitates uniquely identifying the
>subscriber. (within the bounds of the art of the possible, see my last
>post on NAT). I cannot envision a need for more. And ideally I should be
>able to align such an approach with existing Cloud technologies.
SK> For entropy you are better off choosing the right transport and
relying on that than the chain-id.
>
>The individual VF should be able to determine actual subscriber to a
>granularity suitable for it's purposes and obtain the necessary profile
>information via a northbound interface. If you then read between the
>lines,  I'm all for separation of concerns as much as possible ;-) and
>not creating dependencies across chain components beyond the networking
>level.
SK> Agree but I would add that subscriber identification may require
policy-plane interaction and if it is done once in the chain, the rest of
the chain can benefit from it.

Surendra.
>
>I also do not see a huge difference between a service chain, and any
>other flow of information across a string of processing elements. Just in
>one application, the packet is preserved with perhaps a bit of fondling,
>and in others the content may be completely deconstructed, and repackaged
>into a set of transactions....and what is on the wire between chain
>components does not remotely look like what went in the front end...
>
>Cheers
>Dave
>
>
>
>
>
>
>the vendor that supplied the service.   This is similar to when a PCRF
>names a PCC rulebase rather than supplying the full set of explicit PCC
>rules.     
>

---

From: David Allan I <[email-masked]>
Date: Thu, 25 Jul 2013 19:56:44 +0000

Hi Surendra:

Unless the intent is to embed RADIUS records or similar in the meta data, all that is going to be carried is a subscriber ID itself, which implies a policy lookup for each function that is subscriber stateful and needs subscriber specific policies.

Ultimately the notion of subscriber will be uniquely inferable from information embedded in the customer frame when it arrives at the ingress to a chain, and that is without any protocol changes, else the network would already be broken!  So I'm not sure how that can be improved upon...translating what is in the frame to yet another identifier would not really have a lot of utility and would add IMO gratuitous complexity

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Surendra Kumar (smkumar)
Sent: Thursday, July 25, 2013 11:49 AM
To: David Allan I; Ron Parker; Joel M. Halpern; Linda Dunbar
Cc: [email-masked]; Jim Guichard (jguichar)
Subject: Re: [nsc] Service chaining architecture question

On 7/25/13 6:55 AM, "David Allan I" <[email-masked]> wrote:

>I would prefer to think what is on the wire facilitates the forwarding 
>of frames, e.g. chain ID (analogous to VPN), perhaps an entropy 
>shorthand to help both LB and  testabilty....and facilitates uniquely 
>identifying the subscriber. (within the bounds of the art of the 
>possible, see my last post on NAT). I cannot envision a need for more. 
>And ideally I should be able to align such an approach with existing Cloud technologies.
SK> Agree but I would add that subscriber identification may require
policy-plane interaction and if it is done once in the chain, the rest of the chain can benefit from it.

Surendra.
>other flow of information across a string of processing elements. Just 
>in one application, the packet is preserved with perhaps a bit of 
>fondling, and in others the content may be completely deconstructed, 
>and repackaged into a set of transactions....and what is on the wire 
>between chain components does not remotely look like what went in the front end...
>
>Cheers
>Dave
>
>
>
>
>
>
>distinct at each service instance (i.e, policy set 2 at the HTTP 
>content filter does not imply the same set of subscribers as policy set 2 at the
>The advantage of a single chain ID that can be interpreted as a 
>sequence of {service-type-instance, policy-set} is that it minimizes 
>the per-packet encapsulation requirement (i.e., a single GRE key could
>coordination of this identity is required and the number of 
>combinations could become unwieldy.
>
>service-specific-policy-id} where the 3-tuple brings the added 
>advantage of allowing for multiple dissimilar services realized by the same server
>>> The difference I think I have with Ron is that he proposes to use 
>>> one identifier for both entities.
>>> sequence of service modules. In this environment, if the network 
>>> edge nodes, such as Broadband Network Gateway or Cell Site Gateway, 
>>> can use Layer 2 or 3 labels to mark the traffic, the subsequent 
>>> network nodes can steer traffic to the needed service modules 
>>> without looking into "Mega data" or other higher layer fields in the data frames.
>>> >
>>> >>>> NICs) currently exist as potential vehicles for preserving 
>>> >>>> chain context and avoiding per hop classification. Anything 
>>> >>>> else will be implemented more or less the same way and have 
>>> >>>> exactly the same
>>> set
>>> >>>> ---------------------------------------------------------------
>>> >>>> -
>>> >>>> --
>>> --
>>> >> -
>>> >>>> -
>>> >>>> --
>>> >>>>
>>> >>>> since this would not be very effective. So I am wondering how 
>>> >>>> we envision this to work?
>>> >>>>
>>> >>>>
>>> >>>>

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Thu, 25 Jul 2013 20:27:50 +0000

Sorry for the late reply but I am traveling quiet a bit with little email access.

From: "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 24 July 2013 22:30
To: Wim Henderickx <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nsc] Service chaining architecture question

Hi Wim,

WH> My question is more in the context that the service function does not understand the NSH metadata, but I do understand going forward that certain services could understand the NSH metadata.

WH> I do understand this and I agree the ID is local and managed by the policy system. The scenario I have in mind is this and a lot of people deploy the following scenario afais.
An ADC is configured with the chain function based on Policy interaction for subscriber profiles and the service/application have a single interface to the ADC. Given the ADC is involved in the flows all the time the service/application has a single interface/vlan/vnic/etc irrespective of the different chains that are setup. So unless the service/application understands the metadata you need to deploy a different interface/VLAN per network chain and this can be cumbersome depending on the environment. E.g. A FW in a residential environment is deployed with a single interface today irrespective of the amount of chains. If we believe that forwarding the meta-data to the application/service is the answer we need to ensure this is easily supported by the interface stack such that people can adopt it easily.

WH> correct

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Thu, 25 Jul 2013 20:34:01 +0000

I am not talking about the individual subscriber info in the Metadata, but how a service is involved in the chain information with respect to forwarding.
Assume I have an application/service which has an interface to the NSC network domain and you have traffic arriving with different chain Metadata, how is the traffic coming out of the application/service going to be mapped to the proper Metadata header w/o doing reclassification.

From: <Pham>, Chuong D <[email-masked]<mailto:[email-masked]>>
Date: Thursday 25 July 2013 01:30
To: Wim Henderickx <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [nsc] Service chaining architecture question

Wim,
We are also investigating service chaining in a Mobile/Fixed Broadband service provider environment.
I understand that your question is about what information element can be used to identify an individual user i.e. a Mobile subscriber in the meta-data set. If this is correct then we have the same concern.
The way I envision it works is for the per-subscriber meta-data to be obtained/created in the “control plane”. One example is using Mobile/Fixed user identification such as MSISDN and MAC-address to identify the users in the meta-data. The “control plane” entity would receive identification information via control plane messages from entities such as PCRF and AAA server. Such messages also have the user’s dynamically allocated IP addresses.  The control plane entity will push identity <User identity>-<IP address> value pairs to the edge node. The edge node now can use these value pairs to match with per-user policies and include the information in the meta-data.

From: Henderickx, Wim (Wim) [mailto:[email-masked]]
Sent: Wednesday, 24 July 2013 7:52 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [nsc] Service chaining architecture question

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Thu, 25 Jul 2013 21:17:14 +0000

> 
> Ultimately the notion of subscriber will be uniquely inferable from
> information embedded in the customer frame when it arrives at the
> ingress to a chain, and that is without any protocol changes, else the
> network would already be broken!  So I'm not sure how that can be
> improved upon...translating what is in the frame to yet another
> identifier would not really have a lot of utility and would add IMO
> gratuitous complexity

Right!  Now, the services may want to know what is the subscriber id or application id. This is where the metadata comes in.
We should handle metadata in such a way that it does not require the entire IP stack on the appliance to be modified to pass this extra data.

Maria
> Service
> >>> >>>> definition of a service function.   Consider a service
> function to
> >>> >> be
> then be

---

From: David Allan I <[email-masked]>
Date: Thu, 25 Jul 2013 21:25:59 +0000

So it is going to pass other stuff instead.... ????

Isn't this pretty much the same, make the VF "frame transparent" and you're DONE....  just need to write a BCP!

cheers
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of NAPIERALA, MARIA H
Sent: Thursday, July 25, 2013 2:17 PM
To: David Allan I; Surendra Kumar (smkumar); Ron Parker; Joel M. Halpern; Linda Dunbar
Cc: [email-masked]; Jim Guichard (jguichar)
Subject: Re: [nsc] Service chaining architecture question

Maria
> >I would prefer to think what is on the wire facilitates the 
> >forwarding of frames, e.g. chain ID (analogous to VPN), perhaps an 
> >entropy shorthand to help both LB and  testabilty....and facilitates 
> >uniquely identifying the subscriber. (within the bounds of the art of 
> >the possible, see my last post on NAT). I cannot envision a need for more.
> >lines,  I'm all for separation of concerns as much as possible ;-) 
> >and not creating dependencies across chain components beyond the
> networking
> >level.
> >other flow of information across a string of processing elements. 
> >Just in one application, the packet is preserved with perhaps a bit 
> >of fondling, and in others the content may be completely 
> >deconstructed, and repackaged into a set of transactions....and what 
> >is on the wire between chain components does not remotely look like 
> >what went in the
> front end...
> >
> >Cheers
> >Dave
> >
> >
> >
> >
> >
> >
> >It does sound like at least some that have chimed in do feel that 
> >both the general service type (i.e., HTTP content filter) and the 
> >policy
> set
> >stack of 2-tuples {service-ip-address, service-specific-policy-id}, 
> >or even 3-tuples {service-ip-address, service-type, 
> >advantage of allowing for multiple dissimilar services realized by 
> >the
> same server
> >> types. Throughout the network, the "subscription types" dictate 
> >> what service modules their corresponding traffic need to traverse
> through.
> >> Some service modules might need to examine packets deeper (i.e. 
> >> look into payload) for their intended functions. They may need to 
> >> extract the "HTTP header" or HTTP messages from one or multiple packets.
> >>> edge nodes, such as Broadband Network Gateway or Cell Site 
> >>> Gateway, can use Layer 2 or 3 labels to mark the traffic, the 
> >>> subsequent network nodes can steer traffic to the needed service 
> >>> modules without looking into "Mega data" or other higher layer 
> >>> fields in
> the data frames.
> >>> >
> >>> >>>> logical network functions from the perspective of inclusion 
> >>> >>>> in a
> >>> >> service
> >>> >>>> functions".... These are things that are fully 
> >>> >>>> operationalized in OSS, have policy associated with, have 
> >>> >>>> been industrialized and demonstrated to work prior to 
> >>> >>>> deployment. Going all combinatorial
> >>> on
> >>> >>>> environments but not in all. I see the need for an 
> >>> >>>> information exchange between the application and a mediation 
> >>> >>>> layer as
> well.
> >>> >>>> the application itself (might be difficult to achieve but 
> >>> >>>> from my experience it is not very likely, that there will be 
> >>> >>>> big rewrites
> >>> of
> >>> >>>> far mentioned in the drafts in NSC. I understand the 
> >>> >>>> meta-data is
> >>> a
> >>> >>>> understanding is that the services/applications are unaware 
> >>> >>>> of the meta-data and that a layer underneath should provide 
> >>> >>>> the mediation and that we use a well defined interface to the
> >>> application/service

---

From: <[email-masked]>
Date: Fri, 26 Jul 2013 13:51:35 +0200

Dear Paul, 

Please see inline.

Cheers,
Med

>De : [email-masked] [mailto:[email-masked]] De la part de Paul
>Quinn
>Envoyé : jeudi 25 juillet 2013 18:26
>À : NAPIERALA, MARIA H
>Cc : [email-masked]; Jim Guichard (jguichar); Joel M. Halpern; Ron Parker;
>Linda Dunbar
>> Yes. We should separate signaling of network connectivity from metadata
>associated with the payload. These are two separate problems. In a data
>center, some VMs will be participating in service chains, some not, at a
>given time. We don't want to end up with two different forwarding paradigms
>for both types of those VMs.
>>
>
>> We should avoid introducing a new header for carrying metadata (such as
>subscriber-id). The same result can be achieved by using the IP header of
>the payload packet (such as IP option or flow label).
>>
>
>Adding data to existing IP headers might not prove viable, most fields are
>either spoken for, or have significant technical limitations.  For example,
>IP options are usually filtered/dropped

[Med] This is not a valid argument for the chaining case. This limitation would be a no starting point if the chaining procedure is to be activated at the level of Internet...which is not the case here. The solution will be enabled in a controlled environment, and as such, introducing a new IP option, IPv6 extension header, should be part of the viable solutions. It is too early at this stage to exclude any candidate channel to convey the marking bits.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 26 Jul 2013 12:48:37 +0000

Hi Med,

On 7/26/13 7:51 AM, "[email-masked]"
<[email-masked]> wrote:

>[Med] This is not a valid argument for the chaining case. This limitation
>would be a no starting point if the chaining procedure is to be activated
>at the level of Internet...which is not the case here. The solution will
>be enabled in a controlled environment, and as such, introducing a new IP
>option, IPv6 extension header, should be part of the viable solutions. It
>is too early at this stage to exclude any candidate channel to convey the
>marking bits. 

Jim> even in a controlled environment by using IP options you may prevent
cross-domain chaining and at the very least prevent firewalls being part
of the chain; every firewall I know about will drop packets containing IP
options.

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Fri, 26 Jul 2013 12:53:38 +0000

Dave,

If I understand you correctly, you are not disputing that some meta-data
is needed for correctness of steering packets around (apart from the chain
Id itself) but just that a service can derive some kind of metadata
independently, every time.

Deriving meta-data (from the packet,) independently by a service has its
downsides:
* It loads the north-bound interface, if every service does this ...
* You made a case for NAT already and I would think, if you need a service
after a NAT in the chain, source-ip is not going to help
* In some solutions, I could potentially have the network determine which
policy to use while the service simply executes that policy - in this
scenario, the service itself depends on the policy-input from the network
(an external classifier); we do not want to preclude such use-cases
* In some other cases I can imagine deriving policies not only based the
packet contents but also on various other attributes including
environmental at the network or one of the services which may not be
available at another service

IOW, there is a lot of value that meta-data can bring to enhanced service
delivery.
Surendra

On 7/26/13 1:26 AM, "David Allan I" <[email-masked]> wrote:

>Hi Surendra:
>
>Unless the intent is to embed RADIUS records or similar in the meta data,
>all that is going to be carried is a subscriber ID itself, which implies
>a policy lookup for each function that is subscriber stateful and needs
>subscriber specific policies.
>
>information embedded in the customer frame when it arrives at the ingress
>to a chain, and that is without any protocol changes, else the network
>would already be broken!  So I'm not sure how that can be improved
>upon...translating what is in the frame to yet another identifier would
>not really have a lot of utility and would add IMO gratuitous complexity
>
>Dave
>

---

From: <[email-masked]>
Date: Fri, 26 Jul 2013 15:05:34 +0200

Re-,

I guess you are talking about unknown IP options in general. If a new option is to be defined for what we are discussing here, these firewalls will need to be updated. This is not a problem at all.

Unlike the proposals for which the new IP option is to be carried over internet (e.g., http://tools.ietf.org/html/rfc6967#section-4.2.2), the chaining case is restricted to a network segment managed by the same administrative entity.

I'm not trying to advocate for the use an IP option but the point is it is early to decide which channel is viable or not.

Cheers,
Med

>De : Jim Guichard (jguichar) [mailto:[email-masked]]
>Envoyé : vendredi 26 juillet 2013 14:49
>À : BOUCADAIR Mohamed OLNC/OLN; Paul Quinn (paulq); NAPIERALA, MARIA H
>Cc : [email-masked]; Joel M. Halpern; Ron Parker; Linda Dunbar

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 26 Jul 2013 13:29:15 +0000

Hi, Med,

I absolutely agree with your point of not deciding early and not jumping to solutions early.

However, without trying to drive an early decision, I think that it's fair to say that the shortcomings of IP options are more pervasive than just constrained to unknown options in the Internet.

I remember an experiment that Dan Wing started http://www.ietf.org/mail-archive/web/int-area/current/msg02360.html in which using known options in the Internet had basically the same effect. In fact, we used something like just a NOOP end EOO only, and just having known options triggered drops. Narrowing the use-case, options seem to severely limit the ability to perform cross-domain service chains. This is in a way a consequence of tying the metadata to the IP layer, instead of providing a way that is independent from it (and works equally in IPv4, IPv6, MPLS). Even within a controlled domain, there is performance in addition to just connectivity issues; there are also limitations in terms of processing (slow path) of optioned packets, potential inability to be deterministic with ECMP, and like Jim said firewalls. If for example dataplane performance, load-balancing and cross-domain chains are requirements, certainly these need to be considered.

Thanks,

-- Carlos.

---

From: <[email-masked]>
Date: Fri, 26 Jul 2013 15:50:41 +0200

Dear Carlos,

Please see inline.

Cheers,
Med

>De : Carlos Pignataro (cpignata) [mailto:[email-masked]]
>Envoyé : vendredi 26 juillet 2013 15:29
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : Jim Guichard (jguichar); Paul Quinn (paulq); NAPIERALA, MARIA H;
>[email-masked]; Joel M. Halpern; Ron Parker; Linda Dunbar
>However, without trying to drive an early decision, I think that it's fair
>to say that the shortcomings of IP options are more pervasive than just
>constrained to unknown options in the Internet.

[Med] The experiments I'm aware span multiple domain and are not restricted to a managed network.

>
>I remember an experiment that Dan Wing started http://www.ietf.org/mail-
>archive/web/int-area/current/msg02360.html

[Med] I'm aware of Dan's work in this space and also of many other experiment results in this space. Actually, we used some of that work when writing RFC6967.

 in which using known options in
>the Internet had basically the same effect.

[Med] You said the magic word "Internet". This is not the scope of the work we are discussing here. 

 In fact, we used something like
>just a NOOP end EOO only, and just having known options triggered drops.

[Med] Isn't this caused by the option not being explicitly configured to pass in?

>Narrowing the use-case, options seem to severely limit the ability to
>perform cross-domain service chains.

[Med] Do you mean inter-domain? For whom this is a requirement? What is the use case for that? At least for our side, we don't see inter-domain as a requirement for this work.

 This is in a way a consequence of
>tying the metadata to the IP layer, instead of providing a way that is
>independent from it (and works equally in IPv4, IPv6, MPLS). Even within a
>controlled domain, there is performance in addition to just connectivity
>issues; there are also limitations in terms of processing (slow path) of
>optioned packets, potential inability to be deterministic with ECMP, and
>like Jim said firewalls. If for example dataplane performance, load-
>balancing and cross-domain chains are requirements, certainly these need to
>be considered.
>
>Thanks,
>
>-- Carlos.
>
>> I guess you are talking about unknown IP options in general. If a new
>option is to be defined for what we are discussing here, these firewalls
>will need to be updated. This is not a problem at all.
>>
>> Unlike the proposals for which the new IP option is to be carried over
>internet (e.g., http://tools.ietf.org/html/rfc6967#section-4.2.2), the
>chaining case is restricted to a network segment managed by the same
>administrative entity.
>>
>> I'm not trying to advocate for the use an IP option but the point is it
>is early to decide which channel is viable or not.
>>
>> Cheers,
>> Med
>>

---

From: "Diego R. Lopez" <[email-masked]>
Date: Fri, 26 Jul 2013 14:00:08 +0000

Hi,

Just a quick reflection while I try to recover from the enormous backlog caused by the NFV meeting

> [Med] Do you mean inter-domain? For whom this is a requirement? What is the use case for that? At least for our side, we don't see inter-domain as a requirement for this work.

Precisely in NFV we are considering the possibility of such arrangements, where you could use NS-as-a-Service. With an appropriate "NSC/NLF/... control plane" we could support several labeling mechanisms, adapted intra- and inter-domain scenarios.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 26 Jul 2013 14:10:49 +0000

Hello, Med,

Thanks for the follow-up -- please see inline.

> [Med] You said the magic word "Internet". This is not the scope of the work we are discussing here. 

Yes, the first part of my response was only to add that both unknown (as you said) as well as known options have issues in the broad Internet. Comments on narrowscoped use cases were included below.

> [Med] Do you mean inter-domain? For whom this is a requirement? What is the use case for that? At least for our side, we don't see inter-domain as a requirement for this work.

Yes, but only by way of example -- basically any use case that is not limited to IP only single management domain only.

>> balancing and cross-domain chains are requirements, certainly these need to

Additionally, draft-ietf-opsec-ip-options-filtering might be of some interest, in particular the Intro.

Thanks,

-- Carlos.

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 26 Jul 2013 15:15:51 +0000

> option is to be defined for what we are discussing here, these
> firewalls will need to be updated. This is not a problem at all.
> 
Absolutely agree.
Whichever way metadata will be carried will require some changes on the appliance (especially, when adding NSH in front of IP packet).
The point is to do it in the least disruptive way, i.e., without modifying the entire IP stack in the appliance. IP option is a realistic proposal. The "service chain" infrastructure doesn't need to change in order to accomplish this goal.

Maria

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 26 Jul 2013 15:29:33 +0000

Dave,

There might be cases (e.g., when offering IP services to mobile subscribers) where the metadata (e.g., subscriber-id, application-id) could be of value. Some services might operate on subscriber-id information (e.g., MSISDN in mobility). Or, after a DPI, a downstream service might need to know the app-id. 

Maria

> From: David Allan I [mailto:[email-masked]]
> Sent: Thursday, July 25, 2013 5:26 PM
> To: NAPIERALA, MARIA H; Surendra Kumar (smkumar); Ron Parker; Joel M.
> Halpern; Linda Dunbar
> Isn't this pretty much the same, make the VF "frame transparent" and
> you're DONE....  just need to write a BCP!
> 
> cheers
> Dave
> 
> Right!  Now, the services may want to know what is the subscriber id or
> application id. This is where the metadata comes in.
> We should handle metadata in such a way that it does not require the
> entire IP stack on the appliance to be modified to pass this extra
> data.
> 
> Maria
> > policy-plane interaction and if it is done once in the chain, the
> rest
> > of the chain can benefit from it.
> >
> > Surendra.
> > >
> > >From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> > >Ron Parker
> > >firewall).   I will also assume that the meaning and interpretation
> of
> > a
> > >Another approach could be to have a new encapsulation that
> represents
> > a

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 26 Jul 2013 16:02:32 +0000

On 7/26/13 11:15 AM, "NAPIERALA, MARIA H" <[email-masked]> wrote:

>Whichever way metadata will be carried will require some changes on the
>appliance (especially, when adding NSH in front of IP packet).
>The point is to do it in the least disruptive way, i.e., without
>modifying the entire IP stack in the appliance. IP option is a realistic
>proposal. The "service chain" infrastructure doesn't need to change in
>order to accomplish this goal.

Let's be careful before painting ourselves into a corner. It is my opinion
that virtualization in general allows us the opportunity of unprecedented
service mobility that will by its very nature lead to much stronger
inter-domain dependencies. Even a basic WAN-DC service chain can be
thought of as "inter-domain", at the very least from an administrative and
operational control standpoint. If this is in fact true then using any
technology that is (i) transport-dependent (noting that engraining
metadata in the transport is not extensible to other transports), and (ii)
proven to have numerous inter-domain issues, is a dead-end street and we
should avoid placing such restrictions on ourselves. Further, one might
argue that the higher up the stack metadata is placed then the least
amount of changes are necessary down the stack; I see no realistic
evidence that the "entire" IP stack needs to be modified and even less so
if we move up the stack. It is my hope that our upcoming BoF use case
presentations will make the above statements much clearer and show that
the number and diversity of use cases is unbounded.

---

From: Ron Parker <[email-masked]>
Date: Fri, 26 Jul 2013 16:14:05 +0000

Jim,

I agree that transport-dependent mechanisms should be avoided.   In my mind, IP connectivity between the midboxes is both necessary and sufficient.   Mechanisms to transport metadata follow from that.

   Ron

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Friday, July 26, 2013 12:03 PM
To: NAPIERALA, MARIA H; [email-masked]; Paul Quinn (paulq)
Cc: [email-masked]; Joel M. Halpern; Ron Parker; Linda Dunbar
Subject: Re: [nsc] Service chaining architecture question

On 7/26/13 11:15 AM, "NAPIERALA, MARIA H" <[email-masked]> wrote:

>modifying the entire IP stack in the appliance. IP option is a 
>realistic proposal. The "service chain" infrastructure doesn't need to 
>change in order to accomplish this goal.

Let's be careful before painting ourselves into a corner. It is my opinion that virtualization in general allows us the opportunity of unprecedented service mobility that will by its very nature lead to much stronger inter-domain dependencies. Even a basic WAN-DC service chain can be thought of as "inter-domain", at the very least from an administrative and operational control standpoint. If this is in fact true then using any technology that is (i) transport-dependent (noting that engraining metadata in the transport is not extensible to other transports), and (ii) proven to have numerous inter-domain issues, is a dead-end street and we should avoid placing such restrictions on ourselves. Further, one might argue that the higher up the stack metadata is placed then the least amount of changes are necessary down the stack; I see no realistic evidence that the "entire" IP stack needs to be modified and even less so if we move up the stack. It is my hope that our upcoming BoF use case presentations will make the above statements much clearer and show that the number and diversity of use cases is unbounded.

>> >De : Jim Guichard (jguichar) [mailto:[email-masked]] Envoyé : 
>> >vendredi 26 juillet 2013 14:49 À : BOUCADAIR Mohamed OLNC/OLN; Paul 
>> >Quinn (paulq); NAPIERALA, MARIA H Cc : [email-masked]; Joel M. 
>> >Halpern; Ron Parker; Linda Dunbar Objet : Re: [nsc] Service chaining 
>> >architecture question
>> >
>> >Hi Med,
>> >
>> >>>either spoken for, or have significant technical limitations.  For 
>> >>>example, IP options are usually filtered/dropped
>> >>
>> >>is too early at this stage to exclude any candidate channel to 
>> >>convey
>> the
>> >>marking bits.
>> >
>> >of the chain; every firewall I know about will drop packets 
>> >containing
>> IP
>> >options.
>> >
>> >>
>

---

From: Paul Quinn <[email-masked]>
Date: Fri, 26 Jul 2013 09:14:34 -0700

Hi Med,

> I guess you are talking about unknown IP options in general. If a new option is to be defined for what we are discussing here, these firewalls will need to be updated. This is not a problem at all.

Exactly, regardless of where metadata is carried, the services will be to be updated to support that metadata.  Since this seems well understood, the question becomes: how to best carry metadata, in way that is broadly applicable.

---

From: David Allan I <[email-masked]>
Date: Fri, 26 Jul 2013 16:33:37 +0000

Hi Surendra:

If I understand you correctly, you are not disputing that some meta-data is needed for correctness of steering packets around (apart from the chain Id itself) but just that a service can derive some kind of metadata independently, every time.

DA> Effectively yes.  Conflating every packet with any significant amount of information makes no sense to me. And I'm assuming that is what you actually mean.....

DA> If services could use a common schema and multiple services had common elements in that schema that applied to a given subscriber, I would design the service implementation around a multi-core shared memory architecture so a single fetch of subscriber information could be shared by a number of service instances , not try to imbed it in the frame. 

Deriving meta-data (from the packet,) independently by a service has its
downsides:
* It loads the north-bound interface, if every service does this ...
DA> Yes, if an implementation goes and re-fetches the same stuff for every packet. Otherwise a PPP login could pre-position this stuff....

* You made a case for NAT already and I would think, if you need a service after a NAT in the chain, source-ip is not going to help
DA> NAT I see as a special case, it is lossy of information, is mapping subscribers flows onto a scarce resources (IPv4 ports and addresses), has logging requirements etc. I see lots of reasons for putting services in front  of a NAT (e.g. content caching, parental controls etc) so the amount of traffic that actually reaches the NAT is minimized. I have trouble envisioning use cases for a service I want to put after a NAT. 

* In some solutions, I could potentially have the network determine which policy to use while the service simply executes that policy - in this scenario, the service itself depends on the policy-input from the network (an external classifier); we do not want to preclude such use-cases

DA> I don't see the classifier as "the network" . The network is simply interconnect.  IMO casting the network or the classifier as a PDP and the services as a PEP does not really work for me either. I see the classifier simply as a flow subsetting mechanism permitting a degree of specialization in PEPs and deployment of policy "profiles" that map to identified subsets...

* In some other cases I can imagine deriving policies not only based the packet contents but also on various other attributes including environmental at the network or one of the services which may not be available at another service
DA> You're going to have to clarify that sentence...at 50000 feet it looks like you mean what a PDP does... 

IOW, there is a lot of value that meta-data can bring to enhanced service delivery.
Surendra
DA> Beyond very simple tokens or apriori information in the frame, I don't see it. That's the view from here....

Cheers
D

On 7/26/13 1:26 AM, "David Allan I" <[email-masked]> wrote:

>Hi Surendra:
>
>Unless the intent is to embed RADIUS records or similar in the meta 
>data, all that is going to be carried is a subscriber ID itself, which 
>implies a policy lookup for each function that is subscriber stateful 
>and needs subscriber specific policies.
>
>>granularity suitable for it's purposes and obtain the necessary 
>>profile information via a northbound interface. If you then read 
>>between the lines,  I'm all for separation of concerns as much as 
>>possible ;-) and not creating dependencies across chain components 
>>beyond the networking level.
>>HTTP-content-filter-adult, even if both are realized on the same 
>>server by the same software application using the same global URL database.
>>
>>content filter does not imply the same set of subscribers as policy 
>>set
>>2 at the
>>Another approach could be to have a new encapsulation that represents 
>>a stack of 2-tuples {service-ip-address, service-specific-policy-id}, 
>>it avoids the combinatorial explosion problem, but it requires a 
>>larger and variable length encapsulation.
>>
>>If the global chain id approach is used, a control plane protocol 
>>could be used to distribute the definitions of each chain (i.e, each 
>>chain is really a stack of 2-tuples or 3-tuples, per description above).
>>
>>Thanks.
>>
>>    Ron
>>
>>same management systems to assign policies to the devices that care.  
>>I am concerned that it may not be practical to use a single policy 
>>>> Having it mark the subscriber identity and the chain to be 
>>>> traversed seems quite sensible.
>>>>
>>> today's PCRF, subscribers are categorized based on their 
>>> subscription types. Throughout the network, the "subscription types" 
>>> dictate what service modules their corresponding traffic need to traverse through.
>>>> > changes to
>>>> >>>> Saying functions will have a problem with something that 
>>>> >>>> exists as
>>>> a

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 26 Jul 2013 16:44:35 +0000

Jim,

> realistic

You are making certain assumptions about how WAN-DC connectivity is done, i.e., that it is done at the IP level. It might not be. It may be at MPLS level.
But even if it is done at the IP level, the DC-WAN gateway connectivity is in a managed environment.
Using the proposed new NSH header, the DC-WAN gateway has to able to understand this header, and it doesn't today. So, you consider it less impacting than ability to pass an IPv4 option or IPv6 flow label in a managed environment. 

> evidence that the "entire" IP stack needs to be modified and even less

What is the realistic evidence that it is not?

Maria

> >> >>at the level of Internet...which is not the case here. The
> solution
> >> will

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 26 Jul 2013 16:58:27 +0000

Hi Maria,

>
>You are making certain assumptions about how WAN-DC connectivity is done,
>i.e., that it is done at the IP level. It might not be. It may be at MPLS
>level.
>Using the proposed new NSH header, the DC-WAN gateway has to able to
>understand this header, and it doesn't today. So, you consider it less
>impacting than ability to pass an IPv4 option or IPv6 flow label in a
>managed environment.

To the contrary, I make no assumptions to the type of WAN-DC connectivity,
but simply make a statement that all are in scope. Further, by pushing the
metadata up the stack then the WAN-DC gateway need not be forced to
understand the header which is precisely why you want to make this whole
thing independent from the transport.

>What is the realistic evidence that it is not?

Because one of the goals is to make the service plane independent from the
transport.

---

From: David Allan I <[email-masked]>
Date: Fri, 26 Jul 2013 17:03:20 +0000

HI Maria:

Ultimately we have a very restricted set of use cases....

We require flow subsetting to the point where a specific class of service function sees the smallest useful aggregate of traffic it can operate upon.  I see a chain identifier as the "subset ID"....which I would like to think could subsume the concept of "application ID",  as it combined with "chain ID" is simply two layers of flow subsetting.

That service function may implement subscriber specific policies, so the subscriber ID needs to be in the frame, to date I've argued that it is already there.

Whatever else is required would be there to facilitate OAM, scale out etc.

So I think our mental models are conceptually close!

Dave

-----Original Message-----
From: NAPIERALA, MARIA H [mailto:[email-masked]] 
Sent: Friday, July 26, 2013 8:30 AM
To: David Allan I; Surendra Kumar (smkumar); Ron Parker; Joel M. Halpern; Linda Dunbar
Cc: [email-masked]; Jim Guichard (jguichar)
Subject: RE: [nsc] Service chaining architecture question

Dave,

Maria

> Right!  Now, the services may want to know what is the subscriber id 
> or application id. This is where the metadata comes in.
> > Of Surendra Kumar (smkumar)
> > >entropy shorthand to help both LB and  testabilty....and 
> > >facilitates uniquely identifying the subscriber. (within the bounds 
> > >of the art
> of
> > >the possible, see my last post on NAT). I cannot envision a need 
> > >for
> more.
> > >And ideally I should be able to align such an approach with 
> > >existing
> > Cloud technologies.
> > >The individual VF should be able to determine actual subscriber to 
> > >a granularity suitable for it's purposes and obtain the necessary
> > profile
> > >information via a northbound interface. If you then read between 
> > >the lines,  I'm all for separation of concerns as much as possible 
> > >;-) and not creating dependencies across chain components beyond 
> > >the
> > networking
> > >level.
> > >I also do not see a huge difference between a service chain, and 
> > >any other flow of information across a string of processing elements.
> > >deconstructed, and repackaged into a set of transactions....and 
> > >what is on the wire between chain components does not remotely look 
> > >like what went in the
> > front end...
> > >
> > >Cheers
> > >Dave
> > >
> > >
> > >
> > >
> > >
> > >
> > >One thing that flavors the discussion of network service chaining 
> > >is
> > the
> > >folks, especially on the operator side, I hear a different notion 
> > >of "service" -- something subscribers pay for, government mandates,
> etc.
> > server
> > set 2 at the
> > >policy set identity is specific to that type of service and 
> > >probably
> > to
> > >sequence of {service-type-instance, policy-set} is that it 
> > >minimizes the per-packet encapsulation requirement (i.e., a single 
> > >GRE key
> could
> > could
> > >be used to distribute the definitions of each chain (i.e, each 
> > >chain
> > is
> > >>> use one identifier for both entities.
> > subscription
> > exists
> > >>> >>>> So are we really discussing a function participating in 
> > >>> >>>> more than
> > >>> a
> > >>> >>>> I think not only effectivness/scalability might be a 
> > >>> >>>> problem but
> > >>> >> also
> > >>> >>>> information exchange between the application and a 
> > >>> >>>> mediation layer as
> > well.
> > >>> >>>> from my experience it is not very likely, that there will 
> > >>> >>>> be big rewrites
> > >>> of

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 26 Jul 2013 17:04:52 +0000

Hi Carlos,

> >> issues; there are also limitations in terms of processing (slow

I am not sure what is the scope of the problem you are trying to solve.
Why do you mention MPLS in the context? What is the use case for this?
The immediate (and realistic) problem to be solved is chaining of "middlebox" functions.
And it is needed "tomorrow" not 5 years from now ;-)
The only examples (in the e-mails sent) were firewall, ADC, HTTP
proxy.. These functions operate on IP packets.

> >> balancing and cross-domain chains are requirements, certainly these

The service/middlebox functions operate in software today. I am not
sure why you worry about "slow path".. 
In fact, DC-WAN GW also operates at the edge of a network and maybe very well implemented in software.

> firewalls
> >>>>> be enabled in a controlled environment, and as such, introducing
> a new
> >> IP
> >>>>> option, IPv6 extension header, should be part of the viable
> solutions.
> >> It

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 26 Jul 2013 18:10:39 +0000

Hi, Maria,

> proxy.. These functions operate on IP packets.

My comments are in the context of the same problem space and scope, trying to also balance the least intrusive way with transport independence, and future extensibility.

Apologies if I was not clear before, let me try to further clarify:

The service function chaining creates a service overlay logical topology. This service overlay is, as a goal, independent of the network topology -- this independence allows for versatility in selecting the underlay technology. Using IP options essentially leaks the metadata into the transport, tying them together. Given that the service is metadata aware, a corollary goal is to not ripple this down to the transport.

> In fact, DC-WAN GW also operates at the edge of a network and maybe very well implemented in software.

The challenge is what happens in the forwarding between service functions in a chain. One of the goals of having the service overlay topologically independent from the transport is that the forwarding does not change in the network topology. One of the problems is that utilizing options changes the forwarding in nodes that are not service-aware. In other words, the network does not only forward unchanged encapsulated packets between service nodes.

Thanks,

-- Carlos.

---

From: Jiangyuanlong <[email-masked]>
Date: Sat, 27 Jul 2013 06:30:12 +0000

Hi Ron and all,

I agree that HTTP content filtering is a very valid use case. Though I have a different opinion on the following statement "The HTTP content filtering network function is really 3 logical network functions from the perspective of inclusion in a service chain." Actually a subscriber cannot be applied with all these 3 functions at the same time - he may be either a child or an adult, but not both :)
IMHO, HTTP content filtering network function (NF) can be implemented as one single logical network function with different profiles ( maybe each accommodated with a different filtering database), and 3 different service chains may share this NF, thus service chain ID  is enough for this NF to apply different profiles on packets on different service chains.
Section 3.4 of draft-liu-service-chaining-use-cases-00 covers this kind of multiplexing on NFs, maybe you can have a look at it.

My 2 cents,
Best regards,
Yuanlong

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Thursday, July 25, 2013 4:05 AM
To: David Allan I; Henderickx, Wim (Wim); [email-masked]; [email-masked]
Subject: Re: [nsc] Service chaining architecture question

Dave,

Thanks,
Ron

Thanks
Dave

indeed

Hi Wim,

  regards

     Nic

---

From: Jiangyuanlong <[email-masked]>
Date: Sat, 27 Jul 2013 07:07:41 +0000

Hi Ron & Joel,

Implementing HTTP-filter with multiple logical NFs is definitely another option and I agree that service chain ID is enough to work this way.
But I noticed that you restricted it to "IP-addressable server", is router/switches intended to be out of your consideration?

Regards,
Yuanlong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Thursday, July 25, 2013 6:02 AM
To: Joel M. Halpern
Cc: [email-masked]
Subject: Re: [nsc] Service chaining architecture question

Joel,

Thanks.
Ron

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, July 24, 2013 4:47 PM
To: Ron Parker
Cc: [email-masked]
Subject: Re: [nsc] Service chaining architecture question

Ron,

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 27 Jul 2013 04:21:46 -0400

In order to have flexible service chaining, it seems necessary that one 
have network infrastructure supporting the network service delivery agents.

One could argue that we only need ethernet switches for that.  As has 
been pointed out several times in this discussion, there are clearly 
cases where one will want IP forwarding in support of service chains.

Thus, I expect to treat forwarding, at both the IP and Ethernet layers, 
as a capability the network delivers to the service chaining, rather 
than as a network resident value added service.

Yours,
Joel:

PS: Note that this aspect is about the structure of the data plane. 
Network Service Chaining should function whether the network elements 
are devices with integrated control or split architecture (OpeNflow, 
ForCES, GSMP, ...) components.  It shoudl also work whether the policies 
are expressed to the network with conventional network management, with 
I2RS protocols, or with other means.

---

From: Linda Dunbar <[email-masked]>
Date: Sun, 28 Jul 2013 05:43:36 +0000

> proxy.. These functions operate on IP packets.
[Linda] 100% agree with what Maria has said above. 
Several drafts and some emails seem to advocate for including chaining of traditional Layer 2-3 network functions. 
There are already many IETF WG groups working on various aspects of chaining traditional Layer 2-3 forwarding functions. 

Linda