Subject: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

From: Linda Dunbar <[email-masked]>
Date: Mon, 21 Oct 2013 21:15:29 +0000

There have been many drafts submitted for SFC (Service Function Chaining) BOF already. However, we felt that architecture and issues associated with chaining existing Layer 4-7 service functions that are not aware of Service Encapsulation header haven’t been addressed by any drafts (which is called “Proxy Nodes” by draft-quinn-nsh-01).   

We put together a draft to analyze the issues associated with chaining existing
   Layer 4-7 service functions that are not aware of service
   encapsulation layers. This draft also examines the network
   architecture for chaining existing L4-L7 service functions. The
   intent is to identify and describe gaps that have not been
   addressed by other SFC drafts. 

Your comments are greatly appreciated. 

Filename:	 draft-dunbar-sfc-legacy-l4-l7-chain-architecture
Revision:	 00
Title:		 Architecture for Chaining Legacy Layer 4-7 Service Functions
Creation date:	 2013-10-16
Group:		 Individual Submission
Number of pages: 16
URL:             http://www.ietf.org/internet-drafts/draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt
Status:          http://datatracker.ietf.org/doc/draft-dunbar-sfc-legacy-l4-l7-chain-architecture
Htmlized:        http://tools.ietf.org/html/draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00

Linda, Ning, Ian, Sumandra, and Donald

---

From: Ron Parker <[email-masked]>
Date: Mon, 21 Oct 2013 22:01:57 +0000

Hi, Linda.

This contribution is very useful in adding clarity as to how SFC can be realized with legacy service functions.   I do have a few comments and one overall theme regarding "steering", which I consider the legacy approach that we are trying to improve in SFC.

Respectfully,

    Ron

In section 3.3, figure 2 (Chainging existing Layer 4-7 service nodes) -- although it may be slightly off topic for your draft, it occurs to me that the proxy nodes would be ideal locations to load balance towards multiple instances of the same type of service node (i.e., combining proxy-node and load-balancing).

In section 4.1 (L4-L7 nodes connection to Service Chain Proxy Nodes), the first indented bullet states that the service function can be embedded in a service chain proxy.   From a software implementation perspective that makes perfect sense.   But from a network topology perspective, the proxy would not be explicitly observable -- the service function would look like it had native SFC capabilities with respect to other SFC service nodes and/or classifiers.

Also in section 4.1, there is discussion of particular network topologies.   It has been proposed in other drafts that the SFC approach be topology unaware.

Section 4.2 (traffic steering).   Consistent with my comment above, my feeling is that one of the biggest advantages of SFC is to become topology and transport unaware so that a new mechanism need not be invented for every combination of network topology (i.e., 1 hop away, 2 hops away, more) and transport technology (i.e., MAC bridging, IP forwarding, MPLS LER/LSR, ACL-based filtered forwarding, etc.).

Section 5.1 (multiple instances).   Consistent with comments above, with correct separation of the logical and physical, steering tables would not need to be updated each time an NFV event occurred (i.e., instace up, down, moved, expanded, contracted, etc.).

Section 5.2 (challenges of Layer 4-7 traffic steering).   Similar comments to above.   If we choose a topology and transport independent mechanism to follow a service chain, the complexity is reduced and the reliability is improved.    Something akin to the steering that you mention is constrained to the classification node(s), greatly simplifying the service nodes.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Monday, October 21, 2013 5:15 PM
To: [email-masked]
Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee
Subject: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

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

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 22 Oct 2013 20:31:19 +0000

Ron, 

Thank you very much for the valuable comments. See my response inserted below:

> In section 3.3, figure 2 (Chainging existing Layer 4-7 service nodes) -
> - although it may be slightly off topic for your draft, it occurs to me
> that the proxy nodes would be ideal locations to load balance towards
> multiple instances of the same type of service node (i.e., combining
> proxy-node and load-balancing).

[Linda] are you saying that multiple instances are co-located? What if multiple instances for one network function are located in different places? 
Do you think the "proxy node" should balance them, or should the controller balance them and simply inform the "proxy node"?  or combination of both?

> 
> In section 4.1 (L4-L7 nodes connection to Service Chain Proxy Nodes),
> the first indented bullet states that the service function can be
> embedded in a service chain proxy.   From a software implementation
> perspective that makes perfect sense.   But from a network topology
> perspective, the proxy would not be explicitly observable -- the
> service function would look like it had native SFC capabilities with
> respect to other SFC service nodes and/or classifiers.

[Linda] I will change the text to reflect this point. On the other hand, many of today's service functions are independent. They don't care who is ahead of them and who is after. How would you describe this scenario? 

> 
> Also in section 4.1, there is discussion of particular network
> topologies.   It has been proposed in other drafts that the SFC
> approach be topology unaware.
> 
[Linda]  In this context, the Proxy nodes are topology unaware. But proxy nodes know their connection to the directly connected service functions. Is it OK?  

Maybe we can chat face to face in Vancouver for the following points. 

Linda
> Section 4.2 (traffic steering).   Consistent with my comment above, my
> feeling is that one of the biggest advantages of SFC is to become
> topology and transport unaware so that a new mechanism need not be
> invented for every combination of network topology (i.e., 1 hop away, 2
> hops away, more) and transport technology (i.e., MAC bridging, IP
> forwarding, MPLS LER/LSR, ACL-based filtered forwarding, etc.).
> 
> Section 5.1 (multiple instances).   Consistent with comments above,
> with correct separation of the logical and physical, steering tables
> would not need to be updated each time an NFV event occurred (i.e.,
> instace up, down, moved, expanded, contracted, etc.).
> 
> Section 5.2 (challenges of Layer 4-7 traffic steering).   Similar
> comments to above.   If we choose a topology and transport independent
> mechanism to follow a service chain, the complexity is reduced and the
> reliability is improved.    Something akin to the steering that you
> mention is constrained to the classification node(s), greatly
> simplifying the service nodes.
> 
> 
> 
> 
> There have been many drafts submitted for SFC (Service Function
> Chaining) BOF already. However, we felt that architecture and issues
> associated with chaining existing Layer 4-7 service functions that are
> not aware of Service Encapsulation header haven’t been addressed by any
> drafts (which is called “Proxy Nodes” by draft-quinn-nsh-01).
>

---

From: Ron Parker <[email-masked]>
Date: Tue, 22 Oct 2013 21:48:38 +0000

Hi, Linda.

Responses inline.

	Ron

-----Original Message-----
From: Linda Dunbar [mailto:[email-masked]] 
Sent: Tuesday, October 22, 2013 4:31 PM
To: Ron Parker; [email-masked]
Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Ron, 

Thank you very much for the valuable comments. See my response inserted below:

> - although it may be slightly off topic for your draft, it occurs to 
> me that the proxy nodes would be ideal locations to load balance 
> towards multiple instances of the same type of service node (i.e., 
> combining proxy-node and load-balancing).

[Ron] My thinking, so far, is that a load-balancer is, itself a network service function which understands that it manges some set of functionally equivalent subtended network service function instances.    But, from a logical perspective, I think that I have argued myself out of co-mingling the proxy concept and the load balancing concept.   They can be mixed and matched as necessary, and co-located as desired.   For example, a chain may indicate that a load-balancer must be visited.   The load balancer balances to multiple instances of proxy-fronted non-SFC-aware service functions.    But, all of this is off-topic, so I apologize for introducing it here.

[Ron] I think we are saying that to be SFC-aware is to know, explicitly, which service function is next.   A service function which doesn't understand that concept is front-ended by an SFC-proxy.

[Ron] I think this goes to where the intelligence is for the forwarding.

[Ron] It would be my pleasure :).   Please contact me privately.

Linda
> invented for every combination of network topology (i.e., 1 hop away, 
> 2 hops away, more) and transport technology (i.e., MAC bridging, IP 
> Subject: [nsc] New Version Notification for 
> draft-dunbar-sfc-legacy-l4- l7-chain-architecture-00.txt
> 
> not aware of Service Encapsulation header haven’t been addressed by 
> any drafts (which is called “Proxy Nodes” by draft-quinn-nsh-01).
>

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 23 Oct 2013 14:48:46 +0000

Hi,

I fully agree with Ron in finding this draft extremely valuable in how to achieve SFC without supporting the SFC procedures-to-be, and therefore a key aspect for supporting migration and satisfying one of the key requirements that were made at the beginning of the NSC/SFC discussion (by Maria Napierala, if I remember well) Furthermore, I find the node classification into proxy-based and packet-based extremely interesting and worth more deep exploration, including the reflection on nodes able to change the values under which classification was originally performed.

What I find strange is the usage of the "L4-L7" label to qualify the kind of services being considered, as my understanding is that principles are generally applicable, unless you understand that almost anything is a L4-L7 service (like the mention of things like NAT seems to imply) Why not talk about legacy chain mechanisms in plain?

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: Sumandra Majee <[email-masked]>
Date: Wed, 23 Oct 2013 18:02:23 +0000

>>What I find strange is the usage of the "L4-L7" label to qualify the kind of services being considered, as my understanding is that principles are generally applicable, unless you understand that a…

[SM] You are correct this approach is broadly applicable, however the l7 services e.g. content optimizers, protocol converters etc. are often inserted dynamically based on deeper classification (http request hdr,  response side etc.).  

-----Original Message-----
From: Diego R. Lopez [mailto:[email-masked]] 
Sent: Wednesday, October 23, 2013 7:49 AM
To: Ron Parker
Cc: Linda Dunbar; [email-masked]; Donald Eastlake; Ian Smith; Ning So; Sumandra Majee
Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Hi,

Be goode,

On 22 Oct 2013, at 00:01 , Ron Parker wrote:

> There have been many drafts submitted for SFC (Service Function Chaining) BOF already. However, we felt that architecture and issues associated with chaining existing Layer 4-7 service functions that are not aware of Service Encapsulation header haven't been addressed by any drafts (which is called "Proxy Nodes" by draft-quinn-nsh-01).
>

Dr Diego R. Lopez
Telefonica I+D

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

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 23 Oct 2013 18:20:04 +0000

> [SM] You are correct this approach is broadly applicable, however the l7 services e.g. content optimizers, protocol converters etc. are often inserted dynamically based on deeper classification (ht…

I can agree with this, but let me insist in this fact not justifying that those general principles are only discussed in the document for those L4-L7 services. I see there a difference in the classification mechanisms (also applicable for SFC-tagged environments) but not in the purpose of the services...

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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

---

From: Sumandra Majee <[email-masked]>
Date: Wed, 23 Oct 2013 20:43:57 +0000

>I do have a few comments and one overall theme regarding "steering", which I consider the legacy approach that we are trying to improve in SFC.

[SM] Not sure I get the distinction between "chaining" and "steering".  The L7 services are often inserted dynamically to the service chain based on 1) later classification 2) based on network condition like "steering" to video optimizer when available bandwidth falls below certain threshold. 

[SM] Agreed that the forwarding point need to be aware of the topology but proxy-node itself doesn't need to. 

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Tuesday, October 22, 2013 2:49 PM
To: Linda Dunbar; [email-masked]
Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Hi, Linda.

Responses inline.

	Ron

-----Original Message-----
From: Linda Dunbar [mailto:[email-masked]]
Sent: Tuesday, October 22, 2013 4:31 PM
To: Ron Parker; [email-masked]
Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Ron, 

Linda

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 23 Oct 2013 22:25:37 +0000

How can a proxy-node not know the topology? Maybe I am missing the point
of this discussion but a proxy node (as defined in the reference made in
draft-dunbar-sfc-legacy-l4-l7-chain) is a front-end to one or more service
functions that are unable to process any type of service encapsulation.
Therefore the proxy processes said encapsulation on their behalf. In order
for a proxy to forward traffic to the next service function in the chain
it *has* to know the topology.

Further, a previous comment said "it has been proposed in other drafts
that the SFC approach be topology unaware"; which proposal indicates this?
I would agree that the SFC approach should be *transport independent* but
topology awareness is necessary somewhere as otherwise one could not
forward packets from/to the right places.

On 10/23/13 4:43 PM, "Sumandra Majee" <[email-masked]> wrote:

>>I do have a few comments and one overall theme regarding "steering",
>>which I consider the legacy approach that we are trying to improve in
>>SFC.
>
>[SM] Not sure I get the distinction between "chaining" and "steering".
>The L7 services are often inserted dynamically to the service chain based
>on 1) later classification 2) based on network condition like "steering"
>to video optimizer when available bandwidth falls below certain
>threshold. 
>
>> 
>[Linda]  In this context, the Proxy nodes are topology unaware. But proxy
>nodes know their connection to the directly connected service functions.
>Is it OK?  
>Subject: RE: [nsc] New Version Notification for
>draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt
>
>Hi, Linda.
>
>Responses inline.
>
>	Ron
>
>
>Subject: RE: [nsc] New Version Notification for
>draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt
>
>Ron, 
>
>[Linda] are you saying that multiple instances are co-located? What if
>multiple instances for one network function are located in different
>places? 
>Do you think the "proxy node" should balance them, or should the
>controller balance them and simply inform the "proxy node"?  or
>combination of both?
>
>
>[Ron] My thinking, so far, is that a load-balancer is, itself a network
>service function which understands that it manges some set of
>functionally equivalent subtended network service function instances.
>But, from a logical perspective, I think that I have argued myself out of
>co-mingling the proxy concept and the load balancing concept.   They can
>be mixed and matched as necessary, and co-located as desired.   For
>example, a chain may indicate that a load-balancer must be visited.   The
>load balancer balances to multiple instances of proxy-fronted
>non-SFC-aware service functions.    But, all of this is off-topic, so I
>apologize for introducing it here.
>
>> 
>[Linda] I will change the text to reflect this point. On the other hand,
>many of today's service functions are independent. They don't care who is
>ahead of them and who is after. How would you describe this scenario?
>
>
>[Ron] I think we are saying that to be SFC-aware is to know, explicitly,
>which service function is next.   A service function which doesn't
>understand that concept is front-ended by an SFC-proxy.
>
> 
>> 
>[Linda]  In this context, the Proxy nodes are topology unaware. But proxy
>nodes know their connection to the directly connected service functions.
>Is it OK?  
>
>> not aware of Service Encapsulation header haven¹t been addressed by
>> any drafts (which is called ³Proxy Nodes² by draft-quinn-nsh-01).
>>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 23 Oct 2013 22:38:09 +0000

Jim, 

There are tunnels (e.g. VxLAN, NVGRE, or others) interconnecting the "proxy nodes" and "service nodes". Therefore, the "proxy nodes" know their connection to other "Proxy nodes" or/and "service nodes", but "proxy nodes" don't know the network topology underneath the "tunnels". 

The "proxy nodes" are very much like "service nodes" in that sense. "Service nodes" know their interconnection to other "service nodes", but "service nodes" don't know the network topology underneath the "tunnels" that interconnect the "service nodes".  

Linda

> From: Jim Guichard (jguichar) [mailto:[email-masked]]
> Sent: Wednesday, October 23, 2013 5:26 PM
> To: Sumandra Majee; Ron Parker; Linda Dunbar; [email-masked]
> Cc: Donald Eastlake; Ian Smith; Ning So
> >Thank you very much for the valuable comments. See my response
> inserted
> >below:
> >
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> >> Linda Dunbar
> >> We put together a draft to analyze the issues associated with
> chaining
> >> existing
> >> URL:             http://www.ietf.org/internet-drafts/draft-dunbar-
> sfc-
> >> legacy-l4-l7-chain-architecture-00.txt
> >> Htmlized:        http://tools.ietf.org/html/draft-dunbar-sfc-legacy-
> l4-
> >> l7-chain-architecture-00
> >>
> >>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 23 Oct 2013 22:57:17 +0000

Linda,
That may or may not be a valid assumption. While it is true that some
proxies may rely upon an upstream node to perform packet forwarding into
the underlay on their behalf (think TOR), it is also true that the proxy
may simply have that capability itself (think router).

On 10/23/13 6:38 PM, "Linda Dunbar" <[email-masked]> wrote:

>Jim, 
>
>There are tunnels (e.g. VxLAN, NVGRE, or others) interconnecting the
>"proxy nodes" and "service nodes". Therefore, the "proxy nodes" know
>their connection to other "Proxy nodes" or/and "service nodes", but
>"proxy nodes" don't know the network topology underneath the "tunnels".
>
>The "proxy nodes" are very much like "service nodes" in that sense.
>"Service nodes" know their interconnection to other "service nodes", but
>"service nodes" don't know the network topology underneath the "tunnels"
>that interconnect the "service nodes".
>
>Linda
>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 23 Oct 2013 23:06:01 +0000

Jim

> may simply have that capability itself (think router).

[Linda] Then there are (at least) two components on this "router": proxy for service functions and the routing for the underlay networks. 

The "proxy component" don't know the underlay network. It is like having service functions embedded in a router. 
The service functions don't know the underlay network. 

Linda

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 23 Oct 2013 23:13:54 +0000

That's an implementation detail and not a requirement of the architecture;
it is unnecessary in my opinion to assume that the proxy component is
independent of the forwarding component.

On 10/23/13 7:06 PM, "Linda Dunbar" <[email-masked]> wrote:

>[Linda] Then there are (at least) two components on this "router": proxy
>for service functions and the routing for the underlay networks.
>

---

From: <[email-masked]>
Date: Wed, 23 Oct 2013 18:45:58 -0500

... it appears that the proxy has these 4 functional components

a) A Gateway function at the ingress and egress of a chain to transfer packets to and from the network layer
b) An access function to the service while maintaining the service context
c) A topology function  to identify the location of the next service in the service chain
d) A forwarding function to the next proxy node in the service chain 

right ?

Snigs

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, October 23, 2013 4:14 PM
To: Linda Dunbar; Sumandra Majee; Ron Parker; [email-masked]
Cc: Donald Eastlake; Ian Smith; Ning So
Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

That's an implementation detail and not a requirement of the architecture; it is unnecessary in my opinion to assume that the proxy component is independent of the forwarding component.

On 10/23/13 7:06 PM, "Linda Dunbar" <[email-masked]> wrote:

>> proxies may rely upon an upstream node to perform packet forwarding 
>> into the underlay on their behalf (think TOR), it is also true that 
>> the proxy may simply have that capability itself (think router).
>
>[Linda] Then there are (at least) two components on this "router": 
>proxy for service functions and the routing for the underlay networks.
>
>The "proxy component" don't know the underlay network. It is like 
>having service functions embedded in a router.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 23 Oct 2013 23:56:25 +0000

>apologize for introducing it here.

Jim> Ron, your point is not off-topic. A proxy node *could* load balance
across multiple instances of the next service function in the chain, and
this could be a local decision at the proxy node, or a decision taken by
the controller and pushed down to the proxy node, either directly or
indirectly.

---

From: Ken Gray <[email-masked]>
Date: Thu, 24 Oct 2013 14:01:53 +0000

I just don't think you can assume an overlay all the time.

On 10/23/13 7:06 PM, "Linda Dunbar" <[email-masked]> wrote:

>> into

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 24 Oct 2013 10:29:13 -0400

I agree. You definitely can construct situations where no overlays are desired or needed.  Insisting on them as a requirement for NSC to work in these cases adds unnecessary complication.

	--Tom

---

From: Ian Smith <[email-masked]>
Date: Thu, 24 Oct 2013 15:46:34 +0000

In my mind, steering is more "smart" than chaining because a host making a steering decision has to evaluate a lot of options to arrive at the next hop, whereas a host in the middle of a chain is, I think, only supposed to have one option for the next-hop.  

There are a lot more nuance and context to service chains, but in this particular case it seems to me that there is a pretty clear parallel between a host that is a router and a host that has a single default gateway; steering gets you into a chain, but once in the chain you can only get to the next link in that chain (because otherwise it isn't really a chain).

this is a steering rule:

match==[apn==phone.west1.example.net and ip.src==2001:DB8:0:FFFF/64 and tcp.dst==80 and (flow.classification==video or ip.dscp==32) ] action==[ip.option==0,64,253,4,1000 and ip.nexthop==2001:DB8:0:FFFF::AAAA/132] 
(for traffic port 80 using the phone.west1.example.net access point name, and coming from the IP prefix and that is either classified as video or assigned DSCP 32, insert an options header designating the policy for the next four hops and forward to the next hop.) 

this is a chaining rule:

match==[ip.src==2001:DB8:0:FFFF/64] action==[ip.nexthop==2001:DB8:0:FFFF::AAAA/132]
(for traffic from the source prefix, send to the default gateway)

or

match==[ip.option.253.[1]==1000] action==[ip.nexthop==2001:DB8:0:FFFF::AAAA/132]
(for traffic with policy 1000, send to the default gateway)

________________________________________
From: Sumandra Majee
Sent: Wednesday, October 23, 2013 4:43 PM
To: Ron Parker; Linda Dunbar; [email-masked]
Cc: Donald Eastlake; Ning So; Ian Smith
Subject: RE: [nsc] New Version Notification     for     draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Tuesday, October 22, 2013 2:49 PM
To: Linda Dunbar; [email-masked]
Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Hi, Linda.

Responses inline.

        Ron

-----Original Message-----
From: Linda Dunbar [mailto:[email-masked]]
Sent: Tuesday, October 22, 2013 4:31 PM
To: Ron Parker; [email-masked]
Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Ron,

Linda

---

From: Ron Parker <[email-masked]>
Date: Thu, 24 Oct 2013 16:01:56 +0000

Hi, Ian.

I agree conceptually that there is a difference between making a local policy based decision as to how to progress a packet vs. respecting a decision that was made by an upstream entity.

Extending those concepts into the SFC realm, the classifier makes a full "source-routed" decision as to which logical "mid-boxes" shall be visited and in which order.   Any midbox that is also a classifier may optionally reclassify and optionally choose a different chain.   Any midbox that is not a classifier (or chooses not to reclassify) is obligated to follow the chain determined by the most recent upstream classifier.

   Ron

-----Original Message-----
From: Ian Smith [mailto:[email-masked]] 
Sent: Thursday, October 24, 2013 11:47 AM
To: Sumandra Majee; Ron Parker; Linda Dunbar; [email-masked]
Cc: Donald Eastlake; Ning So
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

this is a steering rule:

this is a chaining rule:

or

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Tuesday, October 22, 2013 2:49 PM
To: Linda Dunbar; [email-masked]
Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Hi, Linda.

Responses inline.

        Ron

-----Original Message-----
From: Linda Dunbar [mailto:[email-masked]]
Sent: Tuesday, October 22, 2013 4:31 PM
To: Ron Parker; [email-masked]
Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Ron,

Linda
> not aware of Service Encapsulation header haven't been addressed by 
> any drafts (which is called "Proxy Nodes" by draft-quinn-nsh-01).
>

---

From: Ian Smith <[email-masked]>
Date: Thu, 24 Oct 2013 16:16:30 +0000

Yeah.  I'm not in agreement - the classification function isn't necessarily co-located with the "start the chain" policy enforcement function.

Basically, there are millions of DPI platforms that don't need to be replaced for you to be able to use their marking for steering decisions, and there are much, much more complex marking/classification mechanisms that can't be done in-line on the wire that will also need to be accommodated by a policy enforcement point.

Also, while having the ability to "reclassify" in the middle of the chain is conceptually useful, you aren't chaining at that point anymore and you've entered a realm of content switching, which is, if I understand correctly, one of the things that is being called too complex/expensive as a justification for creating a service chains in the first place.

________________________________________
From: Ron Parker [[email-masked]]
Sent: Thursday, October 24, 2013 12:01 PM
To: Ian Smith; Sumandra Majee; Linda Dunbar; [email-masked]
Cc: Donald Eastlake; Ning So
Subject: RE: [nsc] New Version Notification     for     draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Hi, Ian.

   Ron

-----Original Message-----
From: Ian Smith [mailto:[email-masked]]
Sent: Thursday, October 24, 2013 11:47 AM
To: Sumandra Majee; Ron Parker; Linda Dunbar; [email-masked]
Cc: Donald Eastlake; Ning So
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

this is a steering rule:

this is a chaining rule:

or

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Tuesday, October 22, 2013 2:49 PM
To: Linda Dunbar; [email-masked]
Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Hi, Linda.

Responses inline.

        Ron

-----Original Message-----
From: Linda Dunbar [mailto:[email-masked]]
Sent: Tuesday, October 22, 2013 4:31 PM
To: Ron Parker; [email-masked]
Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Ron,

Linda

---

From: Ron Parker <[email-masked]>
Date: Thu, 24 Oct 2013 16:31:23 +0000

Hi, Ian.

Please see inline below.

   Ron

-----Original Message-----
From: Ian Smith [mailto:[email-masked]] 
Sent: Thursday, October 24, 2013 12:17 PM
To: Ron Parker; Sumandra Majee; Linda Dunbar; [email-masked]
Cc: Donald Eastlake; Ning So
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Ron> Sure, the "start the chain" enforcement function is free to engage the services of a remote policy evaluation engine.   Nothing in the architecture precludes that.

Ron> Are you saying that DPI platforms should become "start the chain" enforcement functions?   Nothing in the architecture precludes that.   Can you elaborate on the "marking" concept, please?   In an SFC environment, would that become the addition of the SFC service header encapsulation?

Ron> This capability would not be restricted to flows carrying "content" as commonly defined (i.e., HTTP objects, FTP files, etc.).   One example could be a service function that is performing some sort of quota accounting -- after reaching some quota threshold, a different set of services is chosen (perhaps a subset of what is selected at original policy classification).

Hi, Ian.

   Ron

-----Original Message-----
From: Ian Smith [mailto:[email-masked]]
Sent: Thursday, October 24, 2013 11:47 AM
To: Sumandra Majee; Ron Parker; Linda Dunbar; [email-masked]
Cc: Donald Eastlake; Ning So
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

this is a steering rule:

this is a chaining rule:

or

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Tuesday, October 22, 2013 2:49 PM
To: Linda Dunbar; [email-masked]
Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Hi, Linda.

Responses inline.

        Ron

-----Original Message-----
From: Linda Dunbar [mailto:[email-masked]]
Sent: Tuesday, October 22, 2013 4:31 PM
To: Ron Parker; [email-masked]
Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Ron,

Linda

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Thu, 24 Oct 2013 16:35:48 +0000

Hi Ian,

> Yeah.  I'm not in agreement - the classification function isn't necessarily co-located with the "start the chain" policy enforcement function.

Not all classification is related to SFC, however rhe SFC classification is the start of the chain. You can have non-SFC classification (i.e. packets are classified but orthogonal to the SFC chain) that reside anywhere.  

> Also, while having the ability to "reclassify" in the middle of the chain is conceptually useful, you aren't chaining at that point anymore and you've entered a realm of content switching, which is…

I disagree.  Re-classfiication essentially duplicate the "start of chain" logic which is certainly understood and implementable

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 24 Oct 2013 16:36:44 +0000

Hi Ron,

On 10/24/13 12:01 PM, "Ron Parker" <[email-masked]> wrote:

>Hi, Ian.
>
>I agree conceptually that there is a difference between making a local
>policy based decision as to how to progress a packet vs. respecting a
>decision that was made by an upstream entity.
>
>Extending those concepts into the SFC realm, the classifier makes a full
>"source-routed" decision as to which logical "mid-boxes" shall be visited
>and in which order.

Jim> The classifier *may* make a source routed decision but it is not
required by the architecture. In the general sense the classifier need
only classify traffic into a service chain and then forward that traffic
to the *first* service node that hosts the *first* service function of the
chain; it need not know which subsequent service nodes will perform the
rest of the service functions.

>  Any midbox that is also a classifier may optionally reclassify and
>optionally choose a different chain.   Any midbox that is not a
>classifier (or chooses not to reclassify) is obligated to follow the
>chain determined by the most recent upstream classifier.
>
>   Ron
>
>
>In my mind, steering is more "smart" than chaining because a host making
>a steering decision has to evaluate a lot of options to arrive at the
>next hop, whereas a host in the middle of a chain is, I think, only
>supposed to have one option for the next-hop.
>
>There are a lot more nuance and context to service chains, but in this
>particular case it seems to me that there is a pretty clear parallel
>between a host that is a router and a host that has a single default
>gateway; steering gets you into a chain, but once in the chain you can
>only get to the next link in that chain (because otherwise it isn't
>really a chain).
>
>this is a steering rule:
>
>match==[apn==phone.west1.example.net and ip.src==2001:DB8:0:FFFF/64 and
>tcp.dst==80 and (flow.classification==video or ip.dscp==32) ]
>action==[ip.option==0,64,253,4,1000 and
>ip.nexthop==2001:DB8:0:FFFF::AAAA/132]
>(for traffic port 80 using the phone.west1.example.net access point name,
>and coming from the IP prefix and that is either classified as video or
>assigned DSCP 32, insert an options header designating the policy for the
>next four hops and forward to the next hop.)
>
>this is a chaining rule:
>
>match==[ip.src==2001:DB8:0:FFFF/64]
>action==[ip.nexthop==2001:DB8:0:FFFF::AAAA/132]
>match==[ip.option.253.[1]==1000]
>action==[ip.nexthop==2001:DB8:0:FFFF::AAAA/132]
>to video optimizer when available bandwidth falls below certain threshold.
>
>>
>> Title:                 Architecture for Chaining Legacy Layer 4-7
>>Service
>> Functions

---

From: Ian Smith <[email-masked]>
Date: Thu, 24 Oct 2013 16:40:26 +0000

Sent: Thursday, October 24, 2013 12:31 PM

Hi, Ian.

Please see inline below.

   Ron

-----Original Message-----
From: Ian Smith [mailto:[email-masked]]
Sent: Thursday, October 24, 2013 12:17 PM
To: Ron Parker; Sumandra Majee; Linda Dunbar; [email-masked]
Cc: Donald Eastlake; Ning So
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

[ims] no, but when you say "the classifier makes a full "source-routed" decision" that does imply that classification function is going to do more than just setting of DSCP/ToS/QoS based on the packet inspection.

[ims]  I suppose, but that is a novel use of chaining, since quota management is ordinarily done out-of-and and enforced in-band, i.e., you don't alter the chain you are in, you quench the existing flows in the old chain set a new chain for new flows so that you don't break the transport layer.

Hi, Ian.

   Ron

-----Original Message-----
From: Ian Smith [mailto:[email-masked]]
Sent: Thursday, October 24, 2013 11:47 AM
To: Sumandra Majee; Ron Parker; Linda Dunbar; [email-masked]
Cc: Donald Eastlake; Ning So
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

this is a steering rule:

this is a chaining rule:

or

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Tuesday, October 22, 2013 2:49 PM
To: Linda Dunbar; [email-masked]
Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Hi, Linda.

Responses inline.

        Ron

-----Original Message-----
From: Linda Dunbar [mailto:[email-masked]]
Sent: Tuesday, October 22, 2013 4:31 PM
To: Ron Parker; [email-masked]
Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Ron,

Linda

---

From: Ian Smith <[email-masked]>
Date: Thu, 24 Oct 2013 16:45:40 +0000

> Re-classfiication essentially duplicate the "start of chain" logic which is certainly understood and implementable

no, reclassification _within a chain_ is branching, which is the same as content switching, which again, I understand to be an existing methodology that SFC is asserting is failing and needs to be superseded.  When you branch you lose all the advantages of chaining (namely that you can set up a sequence of hosts that will only get traffic delivered to them that they will act on, so they don't have to make decisions and pipe the traffic directly to them)

________________________________________
From: Paul Quinn (paulq) [[email-masked]]
Sent: Thursday, October 24, 2013 12:35 PM
To: Ian Smith
Cc: [email-masked]
Subject: Re: [nsc] New Version  Notification    for     draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Hi Ian,

---

From: Sumandra Majee <[email-masked]>
Date: Thu, 24 Oct 2013 16:47:04 +0000

>>Also, while having the ability to "reclassify" in the middle of the chain is conceptually useful, you aren't chaining at that point anymore and you've entered a realm of content switching, which is…

[sm]  For transactional "steering" the classification often happens on the response path (it may or may not have to remember request side classification). This type of reclassification for steering is not conceptual but deployed. 

If I visualize a service chain as ordered list of Network function as driven by a few packets at the start of a flow then it may not be able to solve a variety of use cases in the application services area in particular.

From: Ian Smith
Sent: Thursday, October 24, 2013 9:16 AM

Hi, Ian.

   Ron

-----Original Message-----
From: Ian Smith [mailto:[email-masked]]
Sent: Thursday, October 24, 2013 11:47 AM
To: Sumandra Majee; Ron Parker; Linda Dunbar; [email-masked]
Cc: Donald Eastlake; Ning So
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

this is a steering rule:

this is a chaining rule:

or

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Tuesday, October 22, 2013 2:49 PM
To: Linda Dunbar; [email-masked]
Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Hi, Linda.

Responses inline.

        Ron

-----Original Message-----
From: Linda Dunbar [mailto:[email-masked]]
Sent: Tuesday, October 22, 2013 4:31 PM
To: Ron Parker; [email-masked]
Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Ron,

Linda

---

From: Ron Parker <[email-masked]>
Date: Thu, 24 Oct 2013 17:14:26 +0000

[Ron] The classifier adds the SFC service encapsulation which carries the chain ID and optionally metadata, the specifics of which will be defined by the WG.

-----Original Message-----
From: Ian Smith [mailto:[email-masked]] 
Sent: Thursday, October 24, 2013 12:40 PM
To: Ron Parker; Sumandra Majee; Linda Dunbar; [email-masked]
Cc: Donald Eastlake; Ning So
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Hi, Ian.

Please see inline below.

   Ron

-----Original Message-----
From: Ian Smith [mailto:[email-masked]]
Sent: Thursday, October 24, 2013 12:17 PM
To: Ron Parker; Sumandra Majee; Linda Dunbar; [email-masked]
Cc: Donald Eastlake; Ning So
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Hi, Ian.

   Ron

-----Original Message-----
From: Ian Smith [mailto:[email-masked]]
Sent: Thursday, October 24, 2013 11:47 AM
To: Sumandra Majee; Ron Parker; Linda Dunbar; [email-masked]
Cc: Donald Eastlake; Ning So
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

this is a steering rule:

this is a chaining rule:

or

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Tuesday, October 22, 2013 2:49 PM
To: Linda Dunbar; [email-masked]
Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Hi, Linda.

Responses inline.

        Ron

-----Original Message-----
From: Linda Dunbar [mailto:[email-masked]]
Sent: Tuesday, October 22, 2013 4:31 PM
To: Ron Parker; [email-masked]
Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Ron,

Linda

---

From: Ian Smith <[email-masked]>
Date: Thu, 24 Oct 2013 18:05:16 +0000

Which is why I say that you're lumping the decision of what something is (classification), what policy that matches (start the chain), and where it's next hop is (traffic steering) into a single functional block.

They _MAY_ be the same host, but saying they _MUST_ be the same host seems to be missing a lot about how this is already working today.  

If you want, as Paul is saying, a multi-tiered classification where the network might have packet classification but the SFC system has something more, you are adding complexity and expense to the solution (since most customers already have commodity DPIs and transport layer policy routing in place) just to arrive at the opportunity to make a policy selection instead of being able to make a policy selection with what is already there (DSCP).  The difference between each step of specificity from tcp:80, HTTP, HTTP video, HTTP video from YouTube, to this particular HTTP video from YouTube is significant in terms of the amount of work you need to do and what you can do once you've done it; in most cases, the most granular result isn't worth much more than a less granular one so it doesn't justify the extra effort (and corresponding UX impact). 

Furthermore, a policy selection outcome that decides "which logical "mid-boxes" shall be visited and in which order" is just source routing or label stacking, which we know how to do already and have standards for and can do with a sightly smarter router (cheap and not terribly complex).  If you are insistent on having a new overlay networking protocol defined, then the actual policy selection outcome is more like "decides which logical "middle-boxes" shall be visited and in which order _and then instantiates a service chain of network hosts that matches and creates an SFC tunnel endpoint to forward the packets into".  At which point you've just ramped up the sophistication (and the complexity and expense) of that box from a slightly smarter router to a slightly smarter application delivery controller plus a dynamic infrastructure that is a little bit out in front of where NFV is today but not quite all the way to a fully realized SDN. 

Which means that, "carries the chain ID and optionally metadata" probably isn't necessary if you have the service orchestration framework that all of this implies that you have in order to get all the moving parts in sync; you have to have the infrastructure being orchestrated, so passing policy updates or embedding new config state as part of deploying resources isn't done on the wire in the forwarding plane since you are doing it as part of configuration state updates.

Sent: Thursday, October 24, 2013 1:14 PM

-----Original Message-----
From: Ian Smith [mailto:[email-masked]]
Sent: Thursday, October 24, 2013 12:40 PM
To: Ron Parker; Sumandra Majee; Linda Dunbar; [email-masked]
Cc: Donald Eastlake; Ning So
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Hi, Ian.

Please see inline below.

   Ron

-----Original Message-----
From: Ian Smith [mailto:[email-masked]]
Sent: Thursday, October 24, 2013 12:17 PM
To: Ron Parker; Sumandra Majee; Linda Dunbar; [email-masked]
Cc: Donald Eastlake; Ning So
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Hi, Ian.

   Ron

-----Original Message-----
From: Ian Smith [mailto:[email-masked]]
Sent: Thursday, October 24, 2013 11:47 AM
To: Sumandra Majee; Ron Parker; Linda Dunbar; [email-masked]
Cc: Donald Eastlake; Ning So
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

this is a steering rule:

this is a chaining rule:

or

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Tuesday, October 22, 2013 2:49 PM
To: Linda Dunbar; [email-masked]
Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Hi, Linda.

Responses inline.

        Ron

-----Original Message-----
From: Linda Dunbar [mailto:[email-masked]]
Sent: Tuesday, October 22, 2013 4:31 PM
To: Ron Parker; [email-masked]
Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee
Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Ron,

Linda

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 24 Oct 2013 19:21:28 +0000

Ian,

On 10/24/13 2:05 PM, "Ian Smith" <[email-masked]> wrote:

>Which is why I say that you're lumping the decision of what something is
>(classification), what policy that matches (start the chain), and where
>it's next hop is (traffic steering) into a single functional block.

Jim> with the counter argument that the detailed splitting of functions
and the naming each interface that connects the functions of the
architecture (like IMS or other mobility architectures are so fond of
doing) not only adds arbitrary complexity to the architecture (making it
difficult for non experts to grasp), but in addition  leads to over
specification and limits implementation freedom, and this rigidity tends
to lead to fragility in the overall system.

>
>They _MAY_ be the same host, but saying they _MUST_ be the same host
>seems to be missing a lot about how this is already working today.
>
>If you want, as Paul is saying, a multi-tiered classification where the
>network might have packet classification but the SFC system has something
>more, you are adding complexity and expense to the solution (since most
>customers already have commodity DPIs and transport layer policy routing
>in place) just to arrive at the opportunity to make a policy selection
>instead of being able to make a policy selection with what is already
>there (DSCP).

Jim> classification based on policy for packet forwarding with associated
marking/re-marking/policing/forwarding is different from classification to
enable policy selection at the services layer. Policy in this case may not
simply mean how to forward packets but rather how a service function
should process said packets upon receipt.

>  The difference between each step of specificity from tcp:80, HTTP, HTTP
>video, HTTP video from YouTube, to this particular HTTP video from
>YouTube is significant in terms of the amount of work you need to do and
>what you can do once you've done it; in most cases, the most granular
>result isn't worth much more than a less granular one so it doesn't
>justify the extra effort (and corresponding UX impact).
> 
>
>Furthermore, a policy selection outcome that decides "which logical
>"mid-boxes" shall be visited and in which order" is just source routing
>or label stacking, which we know how to do already and have standards for
>and can do with a sightly smarter router (cheap and not terribly
>complex).  If you are insistent on having a new overlay networking
>protocol defined, then the actual policy selection outcome is more like
>"decides which logical "middle-boxes" shall be visited and in which order
>_and then instantiates a service chain of network hosts that matches and
>creates an SFC tunnel endpoint to forward the packets into".  At which
>point you've just ramped up the sophistication (and the complexity and
>expense) of that box from a slightly smarter router to a slightly smarter
>application delivery controller plus a dynamic infrastructure that is a
>little bit out in front of where NFV is today but not quite all the way
>to a fully realized SDN.

Jim> it is neither source routing or label stacking. Policy selection at a
classifier determines which service chain packets should be directed
through but it does *not* decide which logical mid-boxes shall be visited
but only infers this by the encapsulation and simply forwards to the
next-hop (which could be one of multiple available) that is able to apply
the first service function of the chain.

> 
>
>Which means that, "carries the chain ID and optionally metadata" probably
>isn't necessary if you have the service orchestration framework that all
>of this implies that you have in order to get all the moving parts in
>sync; you have to have the infrastructure being orchestrated, so passing
>policy updates or embedding new config state as part of deploying
>resources isn't done on the wire in the forwarding plane since you are
>doing it as part of configuration state updates.
>
>
>
>
>[ims] no, but when you say "the classifier makes a full "source-routed"
>decision" that does imply that classification function is going to do
>more than just setting of DSCP/ToS/QoS based on the packet inspection.
>
>[Ron] The classifier adds the SFC service encapsulation which carries the
>chain ID and optionally metadata, the specifics of which will be defined
>by the WG.
>
>
>Yeah.  I'm not in agreement - the classification function isn't
>necessarily co-located with the "start the chain" policy enforcement
>function.
>
>
>Ron> Sure, the "start the chain" enforcement function is free to engage
>the services of a remote policy evaluation engine.   Nothing in the
>architecture precludes that.
>
>
>Basically, there are millions of DPI platforms that don't need to be
>replaced for you to be able to use their marking for steering decisions,
>and there are much, much more complex marking/classification mechanisms
>that can't be done in-line on the wire that will also need to be
>accommodated by a policy enforcement point.
>
>
>Ron> Are you saying that DPI platforms should become "start the chain"
>enforcement functions?   Nothing in the architecture precludes that.
>Can you elaborate on the "marking" concept, please?   In an SFC
>environment, would that become the addition of the SFC service header
>encapsulation?
>
>[ims] no, but when you say "the classifier makes a full "source-routed"
>decision" that does imply that classification function is going to do
>more than just setting of DSCP/ToS/QoS based on the packet inspection.
>
>Also, while having the ability to "reclassify" in the middle of the chain
>is conceptually useful, you aren't chaining at that point anymore and
>you've entered a realm of content switching, which is, if I understand
>correctly, one of the things that is being called too complex/expensive
>as a justification for creating a service chains in the first place.
>
>
>Ron> This capability would not be restricted to flows carrying "content"
>as commonly defined (i.e., HTTP objects, FTP files, etc.).   One example
>could be a service function that is performing some sort of quota
>accounting -- after reaching some quota threshold, a different set of
>services is chosen (perhaps a subset of what is selected at original
>policy classification).
>
>[ims]  I suppose, but that is a novel use of chaining, since quota
>management is ordinarily done out-of-and and enforced in-band, i.e., you
>don't alter the chain you are in, you quench the existing flows in the
>old chain set a new chain for new flows so that you don't break the
>transport layer.
>
>and in which order.   Any midbox that is also a classifier may optionally
>reclassify and optionally choose a different chain.   Any midbox that is
>not a classifier (or chooses not to reclassify) is obligated to follow
>the chain determined by the most recent upstream classifier.
>
>   Ron
>
>

---

From: Ken Gray <[email-masked]>
Date: Thu, 24 Oct 2013 19:51:38 +0000

Hey, Ian.  A few inlines ...

While I agree that we shouldn't ignore the way things work today, and what
works well, I don't think we should assume they are optimal or that a
solution for an environment like mobile (which is dictated architecturally
based on a long, long history) is necessarily optimal for an emerging
domain like a DC.  

On 10/24/13 2:05 PM, "Ian Smith" <[email-masked]> wrote:

>there (DSCP).  The difference between each step of specificity from
>tcp:80, HTTP, HTTP video, HTTP video from YouTube, to this particular
>HTTP video from YouTube is significant in terms of the amount of work you
>need to do and what you can do once you've done it; in most cases, the
>most granular result isn't worth much more than a less granular one so it
>doesn't justify the extra effort (and corresponding UX impact).

<keg> I agree that we should take into consideration what's already out
there, but we also shouldn't assume that what works in one domain (maybe
because of architectural dictate) like mobile is an optimal solution for
another like DC.  Nor should we assume that what works today is actually
desirable or least cost.  For example, I think a large number of providers
would say being able to tell HTTP video from HTTP IS a step worth taking
for their environment. And I find the use of the term "commodity DPI" kind
of funny ... because while DPI costs may be dropping as virtualized
versions are introduced (or smaller scope, integral agents are licensed) I
wouldn't assume it's an expense that even current users wouldn't want to
minimize further.

>little bit out in front of where NFV is today but not quite all the way

<keg> I fully expect that there's a few vendors that think they're already
there - the problem is that without standards they don't interoperate.  I
also think that reactive chain building vs proactive chain building will
depend on your environment.

>doing it as part of configuration state updates.

<keg> This seems like an independent assertion rather than something
conclusive from the former argument.  I think we're still debating the
metadata issue and thus it is on the agenda.  I don't think that I could
agree you don't need metadata at all.  Whether you're an advocate of
inline or out of band metadata, a lookup flag/tag inline would certainly
be helpful.

---

From: Ian Smith <[email-masked]>
Date: Thu, 24 Oct 2013 20:21:12 +0000

> with the counter argument that the detailed splitting of functions and the naming each interface that connects the functions of the architecture 

Granted, and i'm not advocating that, I am arguing however that these are functions (and subsequently implementation requirements) that need to be clearly delineated because they are different in kind and when you draw it out as a UML diagram, you don't put all three in the same box; that may or may not lead to them being different classes or processes or products, which is an implementation time decision.

>Policy in this case may not simply mean how to forward packets but rather how a service function should process said packets upon receipt.

This is a rfc2460 Hop-by-Hop options header:  "The Hop-by-Hop Options header is used to carry optional information that must be examined by every node along a packet's delivery path."  If you have IPv4 traffic, we have rfc2473 to use IPv6 as your encapsulation protocol.

>  Policy selection at a classifier determines which service chain packets should be directed through but it does *not* decide which logical mid-boxes shall be visited but only infers this by the encapsulation and simply forwards to the next-hop (which could be one of multiple available) that is able to apply the first service function of the chain.

How do you determine which one-of-many is the next-hop?  Some actor somewhere MUST make that decision, so why aren't you doing that when you can do it once per policy assignment?  If not, then what is?  You have to assume that either every link in the chain has multiple target hosts or that the chain is instantiated with one and only one host per link; you can't reasonably assume that there is a mix of that.  Therefore you need to either pick the one-and-only one link when you start, as Ron is suggesting, or you need to have a directory service that each host uses to select the next hop which can be pull (i.e., DNS) or push (i.e., orchestration).  The fundamental question that we need to answer at each node is "What does the forwarding table say and why does it say it?" and we need to provide an easy to implement way to delivering that that doesn't require the server OS to do a lot of work or need a lot of new code.  And ideally, you want to be able to say the same for the network device OSs as well.

Doing it once at the beginning is an rfc2460 Routing options header (probably with a new routing type definition, since we've deprecated type 0, even though the type 0 behavior is what you want).
Doing it at every link is another rfc2460 Hop-By-Hop options header

The combination of ipip encapsulation, routing options, and hop-by-hop options, as well as the opportunity to use locally defined options, appears to satisfy every need statement on the table.

> ...which logical mid-boxes shall be visited but only infers this by the encapsulation...

This seems to me to be somewhat naively assuming that "the overlay network will take care of everything" instead of actually figuring out what has to happen to make a set of packets result in a desired service delivery outcome, which is part of why I'm arguing against pre-supposing an overlay network being part of the solution.  I know you aren't being naive, but the continued presence of comments like this from some parts of the list is worrisome and makes me feel like this is just a push to write a wire protocol not an attempt to actually solve the problem as it is being stated (which may not actually need a new wire protocol).  There are a lot of tools already in the tool kit and the combination of IPv6, ipip encapsulation for IPv4 traffic, routing options, and hop-by-hop options, as well as the opportunity to use locally defined options, appears to satisfy every need on the table.

________________________________________
From: Jim Guichard (jguichar) [[email-masked]]
Sent: Thursday, October 24, 2013 3:21 PM
To: Ian Smith; Ron Parker; Sumandra Majee; Linda Dunbar; [email-masked]
Cc: Donald Eastlake; Ning So
Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

Ian,

---

From: Ian Smith <[email-masked]>
Date: Thu, 24 Oct 2013 20:38:54 +0000

________________________________________
From: Ken Gray [[email-masked]]
Sent: Thursday, October 24, 2013 3:51 PM
To: Ian Smith; Ron Parker; Sumandra Majee; Linda Dunbar; [email-masked]
Cc: Donald Eastlake; Ning So
Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

[ims]  I agree, that PBR isn't enough, but I'm not sure a lot of providers really want to go down the rabbit hole of knowing HTTP video on a per URI basis (this one particular video).  Granted, this is an unbalanced example - the origin server DC has a much smaller problem space than the access network provider, but they also control the software of the server (so they can do access controls in the application, not the network, for example). But for any similar level of granularity, the numbers just become too big to do real-time classification from the wire.  "This is HTTP video that can be optimized" is the current state of the art in my world, and there is a nice bit of stability there for now.

Commodity DIP - ok, in fairness that is probably too harsh, but I refer to it like that because you can buy merchant silicon and OEM classification libraries and achieve 80-90% of the results of a purpose built DPI and the prices are falling.

[ims] agreed.

[ims] Yes, i'm making a distinction between the policy or chain ID and things like subscriberID, contentType, destinationID, etc. that seem like pure metadata and can be referential.  I agree that if you have chain-links that are going to make decisions, you have to stick something into the packet for them to key that decision on if it isn't already there.

---

From: Ian Smith <[email-masked]>
Date: Thu, 24 Oct 2013 20:39:48 +0000

oops - inline comments
________________________________________
From: [email-masked] [[email-masked]] on behalf of Ian Smith [[email-masked]]
Sent: Thursday, October 24, 2013 4:38 PM
To: Ken Gray; Ron Parker; Sumandra Majee; Linda Dunbar; [email-masked]
Cc: Donald Eastlake; Ning So
Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt

[ims] agreed.

---

From: Thomas Narten <[email-masked]>
Date: Fri, 25 Oct 2013 11:00:16 -0400

Hi Ian.

Ian Smith <[email-masked]> writes:

> The combination of ipip encapsulation, routing options, and
>  hop-by-hop options, as well as the opportunity to use locally
>  defined options, appears to satisfy every need statement on the
>  table.

This is an assertion that the WG can work through.  I personally don't
believe HBH options are a panacea -- there are a number of reasons why
they may not be a good choice -- but the WG can have a discussion
about this where it looks at requirements and how well existing
approaches address the requirements.

Is your specific issue that this WG is not needed at all (because
there are already solutions that work) or just that a new
encapsulation is not needed, as existing ones are good enough?

Thomas

---

From: Ian Smith <[email-masked]>
Date: Fri, 25 Oct 2013 15:54:05 +0000

My perception is that that is a foregone conclusion the working group should be chartered to create a new protocol and that seems premature.  

I do believe that there is work to be done in a working group, but that informational and cbp documents may be all that is required to solve the problem statements that I've seen put forth.  Some have argued that a standard protocol is required for interoperability, and I agree, but I contend that we ought to look at existing options before starting from scratch because it will allow us to deliver faster and it makes for a simpler and more manageable adoption. 

I'm open to the potential that new problem statements do arise that cannot be solved sufficiently by using or extending existing standards to do that, but I haven't seen them presented in any of the sfc drafts.

The drafts are very casual in their dismissal of using existing protocols as part of the solution and they don't explain why enough to justify committing to a new protocol in the charter, in my view.

In particular, we already have a number of on-going efforts that are creating new encapsulation protocols or methodologies and we have several existing encapsulation protocols that have already been standardized, so trying to deal with non-standard encapsulation protocol proliferation by creating standardized encapsulation protocol proliferation seems foolish, particularly when we've already delivered a road forward in IPv6, which for better or worse is the way forward.  Both IPv6 and IPIP have extensibility built into them if the current extension headers aren't sufficient.

Of peripheral concern is the activity of those advocating for programmable, elastic, and virtualized infrastructure as an operational and logistical methodology and the amount of overlap those orchestration efforts have on this work, both in form and consumers; we could end up writing a new protocol for nothing because a PEV infrastructure is doing everything that sfc is claiming needs to be done with dynamic configuration orchestration and the prospective customers have already solved their problem.

________________________________________
From: Thomas Narten [[email-masked]]
Sent: Friday, October 25, 2013 11:00 AM
To: Ian Smith
Cc: [email-masked]
Subject: encap for SFC [was Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt]

Hi Ian.

Thomas

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 25 Oct 2013 17:42:54 +0000

> The drafts are very casual in their dismissal of using existing
> protocols as part of the solution and they don't explain why enough to
> justify committing to a new protocol in the charter, in my view.

I tend to agree with this statement. 

I would also add that this effort should separate signaling of metadata from signaling of a service path. In TCP/IP stack there is a distinction between data/payload being transported and data used on the networking layer. So, using the same header for metadata and path signaling is unusual and not in common with IP protocols. There can be many ways to signal a path, hence, tying together the metadata and path signaling is not a good idea, IMO. We should keep those two mechanisms independent.
If we have the best path signaling protocol, we should be able to use not only for services ;-)

---

From: Ken Gray <[email-masked]>
Date: Fri, 25 Oct 2013 19:02:47 +0000

I think I've already commented that we shouldn't be making blanket
assumptions that what we have now works "best".

The problem statement is relatively generic.  There are no real standards
for swathes of NFV/NSC/SFC.  I don't know anyone disagreeing with that.  I
don't think the statement contains anything about there not being
implementations or methods that work.

Even though solutions might exist (and I don't know one that doesn't claim
to be based on a standard ...or at least the draft of a standard) they're
hardly universal - they are either domain specific or network architecture
specific.

Examples:

You probably think policy and diameter are just groovy for this
application if you work in mobility - you probably don't if these have
stuff you don't think you need for your application and have some other
favorite.  

You might think IF-MAP is groovy if you're working with security (and
maybe it has use in metadata passing in your architecture as well) - a lot
of people don't use IF-MAP and think Yang is better for creating info/data
models because it's more extensible and universal.

You might think extending a protocol you understand really, really well
(and have build YOUR network on) by giving its existing bits overloaded
meaning or adding new bits to it is a groovy idea too - and somebody else
might think that either that protocol is already expensive to maintain in
the human capital they have to hire or already overloaded with too many
meanings and want a simpler method.

In fact, by merely pointing at all of these possibilities - you can see
why we're here.  

On 10/25/13 1:42 PM, "NAPIERALA, MARIA H" <[email-masked]> wrote:

>I would also add that this effort should separate signaling of metadata
>from signaling of a service path. In TCP/IP stack there is a distinction
>between data/payload being transported and data used on the networking
>layer. So, using the same header for metadata and path signaling is
>unusual and not in common with IP protocols. There can be many ways to
>signal a path, hence, tying together the metadata and path signaling is
>not a good idea, IMO. We should keep those two mechanisms independent.

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Fri, 25 Oct 2013 19:11:39 +0000

>If we have the best path signaling protocol, we should be able to use not
I disagree with this analogy.
Service path is identifying a certain forwarding path because of
additionally intelligence by way of policy. The same policy could also
specify metadata or metadata may be derived as a result of the policy
application. This metadata is meaningful in the context of that service
path and hence it makes sense to carry them together. While path+metadata
are related to the actual data, is still a separate from it. In this
sense, the entire original data (frame/packet being serviced) becomes
payload and is still distinct from the service header - consist with the
norm.

Surendra.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 25 Oct 2013 19:22:31 +0000

While I appreciate this discussion and there are certainly a number of
differing opinions on whats "best" in terms of encapsulations, extending
existing or adding new protocols, etc etc, I do not think we need
reconcile all viewpoints prior to formation of the WG, or get bogged down
in the intricacies of individual solutions or draft submissions. Right now
we are working on chartering the WG and ironing out any kinks in the
problem statement and/or charter. Once the WG is formed we will have
plenty of opportunities to debate; indeed, part of our job will be to
reconcile and debate differing opinions and solutions. So for now, let me
respectfully ask that we focus on the charter and problem statement.

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 25 Oct 2013 20:37:46 +0000

Jim, 

> That's an implementation detail and not a requirement of the

[Linda] Architecturally, there is a proxy node, who doesn't have to know the underlay network topology, whose primary job is to steer traffic to the service functions connected based on some header fields/bits in the packets, and/or policies from external entity (e.g. classification nodes, or controller). 

Whether this "proxy node" is a standalone device, or embedded in a router can be an implementation issue. 

Linda

> proxy

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 28 Oct 2013 01:44:33 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ian Smith
> Sent: Friday, October 25, 2013 10:54 AM
> To: Thomas Narten
> Cc: [email-masked]
> Subject: Re: [nsc] encap for SFC [was Re: New Version Notification for
> draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt]
> 
> My perception is that that is a foregone conclusion the working group
> should be chartered to create a new protocol and that seems premature.

[Linda] There are flexible service chaining without new encapsulation at data plane. So I would say "it may be premature to assume creating a new data plane protocol" 

> 
> I do believe that there is work to be done in a working group, 
[Linda] such as management plane or control plane to make service chaining more flexible? 

My two cents.  

Linda

---

From: Thomas Narten <[email-masked]>
Date: Mon, 28 Oct 2013 16:41:13 -0400

Ian Smith <[email-masked]> writes:

> My perception is that that is a foregone conclusion the working
> group should be chartered to create a new protocol and that seems
> premature.

> I do believe that there is work to be done in a working group, but
> that informational and cbp documents may be all that is required to
> solve the problem statements that I've seen put forth.  Some have
> argued that a standard protocol is required for interoperability,
> and I agree, but I contend that we ought to look at existing options
> before starting from scratch because it will allow us to deliver
> faster and it makes for a simpler and more manageable adoption.

So let me (perhaps) be a bit provocative in order to draw out the
discussion a bit more.

My understanding is that one can do service chaining today. But it
isn't always easy, and at least some folk are looking for a different
way that has less pain. I see two major assumptions behind the SFC
work:

1) One can do traffic steering today by manipulating/modifying the
network. E.g., one can place Service Functions on the data path or one
can reprogram the network to steer the traffic to the places it needs
to go. But this is viewed as painful and looking forward, increasingly
inflexible in terms of doing this in an automated, dynamic way. Hence,
SFC is very definitely looking at addressing this problem in a
different manner than just continuing to use protocols that manipulate
the L2/L3 forwarding plane. Specifically, SFC wants to decouple the
"steering" from the underlying network.

If one doesn't want to modify the network forwarding plane, using
tunneling between Service Functions (e.g., via something like
draft-quinn-sfc) is an obvious approach. The key point here though is
that reather than changing the data plane to make packets go where we
want, we tunnel instead, so that this can be done without modifying
the data plane of the underlay.

2) Even in cases where current data plane steering approaches work
good enough (i.e,. 1 above isn't needed), there is also a separate
need to carry meta-data with data packets so that the Service
Functions along the chain can properly (or more easily) implement
those services in a context-sensitive manner.

I believe the charter and problem statement documents are pretty clear
about the above need.

While we might be able to use IP options and other existing mechanisms
tocarry such meta-data, there is long history/experience with IP
options that suggests they may not be a good approach. But the WG
should describe what some of the possible existing approaches are and
what issues (if any) there are with them.

Personally, I don't see IP options as really viable for this stuff. We
have a fair amount of experience/history with such options, and they
are no panacea. What other *existing* approaches are there that we
could consider?

> I'm open to the potential that new problem statements do arise that
> cannot be solved sufficiently by using or extending existing
> standards to do that, but I haven't seen them presented in any of
> the sfc drafts.

> protocols as part of the solution and they don't explain why enough
> to justify committing to a new protocol in the charter, in my view.

What other specific options should we consider?

Thomas

---

From: Ian Smith <[email-masked]>
Date: Mon, 28 Oct 2013 21:41:26 +0000

I understand what you are saying, and thank you, since this is the clearest enunciation of motives I've seen.

It seems to me that you are saying in 1. that you believe that the issues that keep you from solving the problem by dynamically updating the forwarding plane will not follow you into an overlay network, and I disagree strongly.  It also sounds like the idea that traffic steering and service chaining are different in kind to next-hop selection and therefore can be decoupled from the router or switch, to which I also disagree.  I also believe that if you aren't going to address the challenges of updating the forwarding plane, you are running away from the single most important unaddressed requirement for deploying a service delivery architecture.  Tunnelling _is_ changing the data plane; an encapsulation packet still must be sent to the correct destination for the encapsulated payload, and now you've made that cost more system resources in the infrastructure nodes.

Furthermore, by pre-emptively declaring the only solution to be an overlay network you are doing two things:  First, you are requiring bigger and bigger forwarding plane platforms with greater and greater amounts of sophistication to deal with the additional requirements of the proliferation of overlay networks, which is not what the end-users of the standard are asking for, isn't consistent with the work of other standards bodies working on dynamic networking, and results in a more catastrophic failure domain; Second, you are staking out a need for a new working group where there are existing working groups already formed and active based on a very narrow set of desired features that both nvo3 and l3vpn both would seem to be capable of embracing.  

If all you want is a dynamic multi-point vpn, which is functionally what you are describing, then why can't either of those WGs, which are already well into standardizing dmvpn protocols, provide the standard for dmvpns that happen to hook together services that include firewalls, LSN, server LB, and VAS?  Do we really need three IETF dmvpn working groups at the same time?

________________________________________
From: Thomas Narten [[email-masked]]
Sent: Monday, October 28, 2013 4:41 PM
To: Ian Smith
Cc: [email-masked]
Subject: Re: [nsc] encap for SFC [was Re: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt]

Thomas

---

From: Ken Gray <[email-masked]>
Date: Mon, 28 Oct 2013 23:19:13 +0000

+1 overloading protocol bit meanings has a BUNCH of downside and
implementation headache

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 29 Oct 2013 06:14:06 -0400

For me, and important part of this is interoperability.  WHile I can see 
many ways to do service chaining, I really want to make sure that our 
data plane solutions can work together.

In particular, while there are existing techniques for the service chain 
forwarding that I would like to use, the techniques for carrying 
metadata with those are, at best, awkward.  The detailed discussion of 
alternatives and issues belongs down the road, not at this point in the 
process.

Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Tue, 29 Oct 2013 13:18:18 +0000

Hi, Joel.

I agree, and I think most on the thread do, that there are already various techniques to achieve service chaining.    

But, from my experience, the real issue is to get the set of devices/functions all on the same page.   Device/function 1 uses only technique A, device/function 2 uses only technique B, etc.   There may be some legitimate reasons why each device/function developer chose the particular supported technique -- perhaps it is more efficient on the wire or perhaps it fits with a network paradigm that is typical for networks where that device/function is deployed.    

As you've pointed out, the goal should be real-world, practical, multi-vendor interoperability.

   Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Tuesday, October 29, 2013 6:14 AM
To: Ken Gray
Cc: Thomas Narten; [email-masked]; Ian Smith
Subject: Re: [nsc] encap for SFC [was Re: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt]

For me, and important part of this is interoperability.  WHile I can see many ways to do service chaining, I really want to make sure that our data plane solutions can work together.

In particular, while there are existing techniques for the service chain forwarding that I would like to use, the techniques for carrying metadata with those are, at best, awkward.  The detailed discussion of alternatives and issues belongs down the road, not at this point in the process.

Yours,
Joel

On 10/28/13 7:19 PM, Ken Gray wrote:
>> network. E.g., one can place Service Functions on the data path or 
>> one can reprogram the network to steer the traffic to the places it 
>> needs to go. But this is viewed as painful and looking forward, 
>> increasingly inflexible in terms of doing this in an automated, 
>> dynamic way. Hence, SFC is very definitely looking at addressing this 
>> problem in a different manner than just continuing to use protocols 
>> that manipulate the L2/L3 forwarding plane. Specifically, SFC wants 
>> to decouple the "steering" from the underlying network.
>>
>> I believe the charter and problem statement documents are pretty 
>> clear about the above need.
>>
>> While we might be able to use IP options and other existing 
>> mechanisms tocarry such meta-data, there is long history/experience 
>> with IP options that suggests they may not be a good approach. But 
>> the WG should describe what some of the possible existing approaches 
>> are and what issues (if any) there are with them.
>>
>> Personally, I don't see IP options as really viable for this stuff. 
>> We have a fair amount of experience/history with such options, and 
>> they are no panacea. What other *existing* approaches are there that 
>> we could consider?
>>