Subject: Re: [sfc] Comments on draft-ww-sfc-control-plane-04

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 30 May 2015 14:27:26 -0400

Clearly, there are cases where a service funtion will originate packets.
I would strongly hope that the service function is not required to know 
the details of the service function path identification inorder to do so.
My assumption has been that to support this need (both for bidirectional 
cases, and for others), there would be a classifier in place to apply 
the necessary headers.  That classifier could be colocated with the SFF, 
or could be colocated with the service function itself.

Thus, if one wants to deploy a service function and the ability to add 
path information, I would expect a service funciton with colocated 
classifier.  Arguably this is only a descriptive difference.  But that 
description keeps much clearer what functionality we are discussing, and 
where it may exist.

Yours,
Joel

On 5/30/15 8:13 AM, Dave Dolson wrote:
> I will review the document later, but I can quickly answer your question.
>> I have question why not the SFC forwarding system handle the paired chain itself?
>
> Here is the very simple example that indicates the problem:
>   - An SF firewall has a policy to respond to not-permitted incoming connections with TCP RST
> (rather than allowing the connection to reach the protected host).
>   - Therefore when a TCP SYN packet arrives at the SF firewall with NSH encapsulation
> having path ID x and Path Index y, it must be able to insert the response into the path that is
> the bidirectional complement, an NSH encapsulation having path ID x' and path index y' to send
> the packet back to the source, following the reverse path.
>
> I hope that shows why the paths need to be paired?
>
> I believe that most flow-stateful devices will require the pairing information.
>
> -Dave
>
>
> ________________________________
> From: Huangyong (Oliver) [[email-masked]]
> Sent: Friday, May 29, 2015 9:06 PM
> To: Dave Dolson; [email-masked]; Hongyu Li (Julio); Qin Wu; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Huangjing (A); Linda Dunbar
> Subject: RE: Comments on draft-ww-sfc-control-plane-04
>
> Hello Dave,
>
>          Thank you for your detailed consideration on the draft.  I agree that the SF should support the capability of bidirectional chains. For example, the NAT SF may provide the new allocated address/port to the controller.  You mentioned the control plane should inform SF bidirectional chain (which path id are paired).  I have question why not the SFC forwarding system handle the paired chain itself?
>
>          Performance mornitoring is a basic capability which should exist in all interfaces C1,C2,C3.
>
>          Mohamed have developed a new version of this draft and made a big promotion. In the new draft, C3,C4 are introduced for SF and SF proxy separately.  I think it may cover the related scenario.  I attached it in this email,  please check it.
>
>          Now James.Huang(I add in this email), Qin.Wu and Linda. Dunbar are representative of Huawei on this draft. Please contact more detail to them.   Thank you very much!
>
> BR
> Oliver
>
> ---------------------------
> Huangyong (Oliver)
> Network research, Huawei
>
> From: Dave Dolson [mailto:[email-masked]]
> Sent: Saturday, May 30, 2015 4:42 AM
> To: [email-masked]; Hongyu Li (Julio); Qin Wu; Huangyong (Oliver); [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: Comments on draft-ww-sfc-control-plane-04
>
> Authors of draft-ww-sfc-control-plane,
>
> I’ve been reading over https://tools.ietf.org/html/draft-ww-sfc-control-plane-04
>
> I have some very high-level suggestions:
>
>
> 1.      I believe the “F” interface should be split into two interfaces. One for performance monitoring (availability and workload were cited), and one for updating classification information.
>
> Call these F1 and F2, I suppose. My reasons are that (a) as a general principle, interfaces should not have multiple purposes and (b) F1 and F2 could be communicating to different control-plane managers.
>
>
>
> 2.      A control interface is required to SF components. Call it C3. This interface is required to (a) inform the SF about bidirectional chains (i.e., which Path IDs are paired) and (b) inform the SF about semantics of types of meta-data. C3 should also be connected to the SFC Proxy.
>
> I propose:
>
> 4.5  C3 Interface
>
>     A service function may need information about the service paths
>     passing through it, and may need information about specific meta-data
>     types attached to packets on the paths.
>
>     Some types of SF might be agnostic about the paths traversing them, but
>     most transport-layer-flow-aware devices will require this configuration.
>
>     When bidirectional chains are deployed, the C3 interface provisions
>     each SF with each path identifier/path index pair that will pass through.
>     Each such pair is associated with an opposite-direction pair of
>     identifier/index.
>
>     Meta-data is for the benefit of SFs. The C3 interface informs the SF
>     about the semantics of the meta-data, which would otherwise have
>     opaque meaning. Meta-data attributes include "scope" (per-packet, per-flow
>     or per host), "mandatory" (must be understood), "bidirectional" (same
>     value may be used in both directions), "is_qualifier" (indicates a
>     distinct routing domain).
>
>
> I think there is quite a bit to explore, but I believe this starts the discussion.
> Thoughts?
>
>
> David Dolson
> Senior Software Architect, Sandvine Inc.
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: "Huangyong (Oliver)" <[email-masked]>
Date: Mon, 1 Jun 2015 01:02:33 +0000

Dave,

    I think we all agree that the "paired/bidirectional path" requirement.  

    My question is, it seems unclear that the "control plane inform the SF about bidirectional chains" to achieve this goal.  From my point of view, SF provide the reverse path flow identifier via either control plane or data plane to the classifier. It seems that the SF need not know which path ids are paired. 

    Anyway, you have provided very useful information regarding the control interface which may be described in the draft I think.  Thank you Dave.

BR
Oliver

-----Original Message-----
From: Dave Dolson [mailto:[email-masked]] 
Sent: Saturday, May 30, 2015 8:14 PM
To: Huangyong (Oliver); [email-masked]; Hongyu Li (Julio); Qin Wu; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Huangjing (A); Linda Dunbar
Subject: RE: Comments on draft-ww-sfc-control-plane-04

Here is the very simple example that indicates the problem:
 - An SF firewall has a policy to respond to not-permitted incoming connections with TCP RST (rather than allowing the connection to reach the protected host).
 - Therefore when a TCP SYN packet arrives at the SF firewall with NSH encapsulation having path ID x and Path Index y, it must be able to insert the response into the path that is the bidirectional complement, an NSH encapsulation having path ID x' and path index y' to send the packet back to the source, following the reverse path.

-Dave

Hello Dave,

BR
Oliver

I've been reading over https://tools.ietf.org/html/draft-ww-sfc-control-plane-04

1.      I believe the "F" interface should be split into two interfaces. One for performance monitoring (availability and workload were cited), and one for updating classification information.

I propose:

4.5  C3 Interface

David Dolson

---

From: Dave Dolson <[email-masked]>
Date: Mon, 1 Jun 2015 15:29:43 +0000

Regarding the 2nd paragraph in 2.1,

2.1.  Generic Requirements

   For deployments that would require so, SFC forwarding must be allowed
   even if no control protocols are enabled.  Static configuration must
   be allowed.

   A permanent association between an SFC data plane element with a
   Control Element must not be required; specifically, the SFC-enabled
   domain must keep on processing incoming packets according to the SFC
   instructions, even when control plane components are unavailable or
   unreachable for some reason.

"Control Element must not be required" is contrary to how OpenFlow works (as I understand it).
So the "must" wording seems to preclude the use of OpenFlow and similar protocols. Was this intended?

And it is probably a bad idea to allow an uncontrolled data-plane element to keep running indefinitely. Would you want a switch to run without MAC learning? Would you want a router to run if it lost its BGP connection? No, and this is why loss of control plane should generally lead to shutting down the data plane.

I understand the sentiment to allow static configuration, which I think is fine. But if the control-plane is dynamic, loss of controller should lead to shut-down.

-Dave

From: Huangyong (Oliver) [mailto:[email-masked]]
Sent: Friday, May 29, 2015 9:06 PM
To: Dave Dolson; [email-masked]; Hongyu Li (Julio); Qin Wu; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Huangjing (A); Linda Dunbar
Subject: RE: Comments on draft-ww-sfc-control-plane-04

Hello Dave,

BR
Oliver

From: Dave Dolson [mailto:[email-masked]]
Sent: Saturday, May 30, 2015 4:42 AM
To: [email-masked]<mailto:[email-masked]>; Hongyu Li (Julio); Qin Wu; Huangyong (Oliver); [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: Comments on draft-ww-sfc-control-plane-04

I propose:

4.5  C3 Interface

David Dolson

---

From: Ron Parker <[email-masked]>
Date: Mon, 1 Jun 2015 15:43:04 +0000

Hi, Dave.

OpenFlow implementations locate the policy decision point in the controller and hence per-flow policy analysis is supported via the control plane messaging.   Assuming that the controller, after analyzing a flow, provides both the action and the filter it used to define the flow, then we get to whether the filter is coarse-grained or fine-grained.   If the filter is coarse-grained (e.g., all TCP/80), then additional control plane activity is not required for subsequent micro-flows that match the macro-flow's filter.   But, if fine-grained (i.e., fully qualified 5-tuple) filtering is used, then the control plane overhead becomes very large and perhaps impractical.    Many of the use cases we've talked about for SFC suggest micro-flow level policy decisions.

While I wouldn't suggest that we preclude centralized fine-grained policy as a design/implementation decision, I also feel there should be an alternative to allow for distributed/fine-grained policy decisions.   In that case, the control plane's job would be to provide and maintain all of the data necessary to those distributed policy decision points, but not necessarily handle per-micro-flow transactions.

In summary, we could end up with any or all of the following operating points (as a fundamental capability or simply a deployment approach):

*        Centralized coarse-grained policy decision point

*        Centralized fine-grained policy decision point

*        Distributed coarse-grained policy decision point

*        Distributed fine-grained policy decision point

   Ron

From: Dave Dolson [mailto:[email-masked]]
Sent: Monday, June 1, 2015 11:30 AM
To: Huangyong (Oliver); [email-masked]; Hongyu Li (Julio); Qin Wu; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Ron Parker; Huangjing (A); Linda Dunbar
Subject: RE: Comments on draft-ww-sfc-control-plane-04

-Dave

From: Huangyong (Oliver) [mailto:[email-masked]]
Sent: Friday, May 29, 2015 9:06 PM
To: Dave Dolson; [email-masked]<mailto:[email-masked]>; Hongyu Li (Julio); Qin Wu; [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]>; Huangjing (A); Linda Dunbar
Subject: RE: Comments on draft-ww-sfc-control-plane-04

Hello Dave,

BR
Oliver

I propose:

4.5  C3 Interface

David Dolson

---

From: Dave Dolson <[email-masked]>
Date: Mon, 1 Jun 2015 15:50:08 +0000

I may not have explained my point we'll enough. I only have issue with the case of the control plane being unreachable.

David Dolson
Senior Software Architect, Sandvine Inc.
From: Ron Parker
Sent: Monday, June 1, 2015 11:43 AM
To: Dave Dolson; Huangyong (Oliver); [email-masked]; Hongyu Li (Julio); Qin Wu; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Huangjing (A); Linda Dunbar
Subject: RE: Comments on draft-ww-sfc-control-plane-04

Hi, Dave.

OpenFlow implementations locate the policy decision point in the controller and hence per-flow policy analysis is supported via the control plane messaging.   Assuming that the controller, after analyzing a flow, provides both the action and the filter it used to define the flow, then we get to whether the filter is coarse-grained or fine-grained.   If the filter is coarse-grained (e.g., all TCP/80), then additional control plane activity is not required for subsequent micro-flows that match the macro-flow’s filter.   But, if fine-grained (i.e., fully qualified 5-tuple) filtering is used, then the control plane overhead becomes very large and perhaps impractical.    Many of the use cases we’ve talked about for SFC suggest micro-flow level policy decisions.

While I wouldn’t suggest that we preclude centralized fine-grained policy as a design/implementation decision, I also feel there should be an alternative to allow for distributed/fine-grained policy decisions.   In that case, the control plane’s job would be to provide and maintain all of the data necessary to those distributed policy decision points, but not necessarily handle per-micro-flow transactions.

·        Centralized coarse-grained policy decision point

·        Centralized fine-grained policy decision point

·        Distributed coarse-grained policy decision point

·        Distributed fine-grained policy decision point

   Ron

“Control Element must not be required” is contrary to how OpenFlow works (as I understand it).
So the “must” wording seems to preclude the use of OpenFlow and similar protocols. Was this intended?

-Dave

Hello Dave,

BR
Oliver

I propose:

4.5  C3 Interface

David Dolson

---

From: Ron Parker <[email-masked]>
Date: Mon, 1 Jun 2015 17:41:30 +0000

Hi, Dave.

I did catch that from your original message and I apologize for my comments that weren't very direct wrt your point.   So to complete the circle, my thinking is that if the policy decision point (PDP) is centralized, then you live and die by the control plane availability.   But, if the policy decision points are distributed, there is a significantly increased tolerance to temporary loss of the control plane.   I'd like to retain within the architecture the possibility for this distributed approach so that for any deployment the relative strengths and weaknesses of centralized vs distributed can be weighed and decided upon.    Based on which approach there is a profound impact on what the control plane is doing -- is it policy delivery or is it policy evaluation?

Thanks.

   Ron

-----Original Message-----
From: Dave Dolson [mailto:[email-masked]] 
Sent: Monday, June 1, 2015 11:50 AM
To: Ron Parker; Huangyong (Oliver); [email-masked]; Hongyu Li (Julio); Qin Wu; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Huangjing (A); Linda Dunbar
Subject: Re: Comments on draft-ww-sfc-control-plane-04

David Dolson

Hi, Dave.

   Ron

-Dave

Hello Dave,

BR
Oliver

I propose:

4.5  C3 Interface

David Dolson

---

From: Dave Dolson <[email-masked]>
Date: Mon, 1 Jun 2015 18:20:17 +0000

Ron, 

I don't disagree with those statements. 
But I believe the wording in the text precludes OpenFlow "fail standalone mode".

The wording is "... must keep on processing incoming packets according to the 
SFC instructions, even when control plane components are unavailable or 
unreachable for some reason".

As I read it, this prohibits any special failure mode behavior, and hence is too strongly worded.

There isn't even a time limit in the requirement. Must keep the SFC instructions forever? Even after power cycle?
As literally written, for example, C1 classification rules based on volatile identifiers such as IP addresses
MUST be maintained forever. (Although lower-case "must" was used -- intentionally or in error?)

Was this strong requirement really intended, or is the wording just incomplete?
My feeling is that a more flexible approach would be valid. 
E.g., an operator may wish to drop IP-address classification rules after a few minutes if there is no control-plane connectivity.

I think you *could* keep this wording if the classification rules themselves have timeouts. 
But then the controller would always be refreshing them.

-Dave

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Monday, June 01, 2015 1:42 PM
To: Dave Dolson; Huangyong (Oliver); [email-masked]; Hongyu Li (Julio); Qin Wu; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Huangjing (A); Linda Dunbar
Subject: RE: Comments on draft-ww-sfc-control-plane-04

Hi, Dave.

Thanks.

   Ron

-----Original Message-----
From: Dave Dolson [mailto:[email-masked]] 
Sent: Monday, June 1, 2015 11:50 AM
To: Ron Parker; Huangyong (Oliver); [email-masked]; Hongyu Li (Julio); Qin Wu; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Huangjing (A); Linda Dunbar
Subject: Re: Comments on draft-ww-sfc-control-plane-04

David Dolson

Hi, Dave.

   Ron

-Dave

Hello Dave,

BR
Oliver

I propose:

4.5  C3 Interface

David Dolson

---

From: <[email-masked]>
Date: Tue, 2 Jun 2015 09:37:49 +0000

Hi Dave,

-05 includes this text inspired by your first message in this thread: 

   Also, this interface informs the SFC-aware SF about the semantics of
   a context information, which would otherwise have opaque meaning.
   Several attributes may be associated with a context information such
   as (but not limited to) the "scope" (e.g., per-packet, per-flow or
   per host), whether it is "mandatory" or "optional" to process flows
   bound to a given chain, etc.  Note that a context may be mandatory
   for "chain 1", but optional for "chain 2".

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Dave Dolson [mailto:[email-masked]]
> Envoyé : lundi 1 juin 2015 20:20
> À : Ron Parker; Huangyong (Oliver); [email-masked]; Hongyu Li (Julio); Qin
> Wu; BOUCADAIR Mohamed IMT/OLN; JACQUENET Christian IMT/OLN;
> [email-masked]; [email-masked]; Huangjing (A); Linda
> Dunbar
> Objet : RE: Comments on draft-ww-sfc-control-plane-04
> 
> Ron,
> 
> There isn't even a time limit in the requirement. Must keep the SFC
> instructions forever? Even after power cycle?
> As literally written, for example, C1 classification rules based on
> volatile identifiers such as IP addresses

[Med] -05 includes the following text: 

   A permanent association between an SFC data plane element with a
   Control Element must not be required; specifically, the SFC-enabled
   domain must keep on processing incoming packets according to the SFC
   instructions even during unavailability events of control plane
   components.  SFC implementations that do not meet this requirement
   will suffer from another flavor of the constrained high availability
   issue, discussed in Section 2.3 of [RFC7498], supposed to be solved
   by SFC designs.

The point is to encourage SFC mechanisms that do not degrade the serviceability of an SFC-enabled domain. If such requirement is not met, then service disruption is likely...which is not desired. If activating SFC solution will lead to more unavailability events, then I do think we are not addressing correctly the SFC problem space (RFC7498).

Does this make sense?

> E.g., an operator may wish to drop IP-address classification rules after a
> few minutes if there is no control-plane connectivity.

[Med] Which means no service, no? Why not relying on "stale" information maintained by SFC data plane elements to process packets?

> themselves have timeouts.

[Med] The point about timeouts is a good point. I do personally think that associating timeouts with classification entries will ease the management of classification entries (especially the removal of obsolete entries by local decisions at the classifier).    

> But then the controller would always be refreshing them.

[Med] This depends on the timeout (that can be expressed in days, months, etc.) or be set to infinite (for entries that are supposed to last for too too long periods). 

> To: Dave Dolson; Huangyong (Oliver); [email-masked]; Hongyu Li (Julio); Qin
> Wu; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Huangjing (A); Linda
> Dunbar
> I did catch that from your original message and I apologize for my
> comments that weren't very direct wrt your point.   So to complete the
> circle, my thinking is that if the policy decision point (PDP) is
> centralized, then you live and die by the control plane availability.
> But, if the policy decision points are distributed, there is a
> significantly increased tolerance to temporary loss of the control plane.
> I'd like to retain within the architecture the possibility for this
> distributed approach so that for any deployment the relative strengths and
> weaknesses of centralized vs distributed can be weighed and decided upon.
> Based on which approach there is a profound impact on what the control
> plane is doing -- is it policy delivery or is it policy evaluation?
> 
> Thanks.
> 
>    Ron
> 
> 
> To: Ron Parker; Huangyong (Oliver); [email-masked]; Hongyu Li (Julio); Qin
> Wu; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Huangjing (A); Linda
> Dunbar
> I may not have explained my point we'll enough. I only have issue with the
> case of the control plane being unreachable.
> 
> David Dolson
> To: Dave Dolson; Huangyong (Oliver); [email-masked]; Hongyu Li (Julio); Qin
> Wu; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Huangjing (A); Linda
> Dunbar
> OpenFlow implementations locate the policy decision point in the
> controller and hence per-flow policy analysis is supported via the control
> plane messaging.   Assuming that the controller, after analyzing a flow,
> provides both the action and the filter it used to define the flow, then
> we get to whether the filter is coarse-grained or fine-grained.   If the
> filter is coarse-grained (e.g., all TCP/80), then additional control plane
> activity is not required for subsequent micro-flows that match the macro-
> flow's filter.   But, if fine-grained (i.e., fully qualified 5-tuple)
> filtering is used, then the control plane overhead becomes very large and
> perhaps impractical.    Many of the use cases we've talked about for SFC
> suggest micro-flow level policy decisions.
> 
> While I wouldn't suggest that we preclude centralized fine-grained policy
> as a design/implementation decision, I also feel there should be an
> alternative to allow for distributed/fine-grained policy decisions.   In
> that case, the control plane's job would be to provide and maintain all of
> the data necessary to those distributed policy decision points, but not
> necessarily handle per-micro-flow transactions.
> 
> In summary, we could end up with any or all of the following operating
> points (as a fundamental capability or simply a deployment approach):
> 
> To: Huangyong (Oliver); [email-masked]; Hongyu Li (Julio); Qin Wu;
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Ron Parker; Huangjing
> (A); Linda Dunbar
> And it is probably a bad idea to allow an uncontrolled data-plane element
> to keep running indefinitely. Would you want a switch to run without MAC
> learning? Would you want a router to run if it lost its BGP connection?
> No, and this is why loss of control plane should generally lead to
> shutting down the data plane.
> 
> 
> I understand the sentiment to allow static configuration, which I think is
> fine. But if the control-plane is dynamic, loss of controller should lead
> to shut-down.
> 
> 
> 
> -Dave
> 
> 
> 
> 
> To: Dave Dolson; [email-masked]<mailto:[email-masked]>; Hongyu Li (Julio); Qin
> Wu; [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]>;
> Huangjing (A); Linda Dunbar
>         Thank you for your detailed consideration on the draft.  I agree
> that the SF should support the capability of bidirectional chains. For
> example, the NAT SF may provide the new allocated address/port to the
> controller.  You mentioned the control plane should inform SF
> bidirectional chain (which path id are paired).  I have question why not
> the SFC forwarding system handle the paired chain itself?
> 
>         Mohamed have developed a new version of this draft and made a big
> promotion. In the new draft, C3,C4 are introduced for SF and SF proxy
> separately.  I think it may cover the related scenario.  I attached it in
> this email,  please check it.
> 
>         Now James.Huang(I add in this email), Qin.Wu and Linda. Dunbar are
> representative of Huawei on this draft. Please contact more detail to
> them.   Thank you very much!
> 
> BR
> Oliver
> 
> To: [email-masked]<mailto:[email-masked]>; Hongyu Li (Julio); Qin Wu;
> Huangyong (Oliver);
> [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]>
> 1.      I believe the "F" interface should be split into two interfaces.
> One for performance monitoring (availability and workload were cited), and
> one for updating classification information.
> 
> Call these F1 and F2, I suppose. My reasons are that (a) as a general
> principle, interfaces should not have multiple purposes and (b) F1 and F2
> could be communicating to different control-plane managers.
> 
> 
> 
> 2.      A control interface is required to SF components. Call it C3. This
> interface is required to (a) inform the SF about bidirectional chains
> (i.e., which Path IDs are paired) and (b) inform the SF about semantics of
> types of meta-data. C3 should also be connected to the SFC Proxy.
> 
> I propose:
> 
> 4.5  C3 Interface
>

---

From: Dave Dolson <[email-masked]>
Date: Tue, 2 Jun 2015 16:13:46 +0000

[trimmed the list a bit to avoid the mailing list holding up the message]
Med,
Thanks for including changes in the document.

You asked me a question:

What is "no service"? I think this could mean passing packets without applying any SF functions,
or applying a default set of SF functions.
It could mean falling back to a CLI-provisioned forwarding policy.

The question of "stale" information is exactly the point.
If the control plane is not available, any volatile data might be stale.
Concrete example: using IP addresses to classify subscriber policy, when IP address assignment is dynamic.

Which is a more valid way to think of stale state?
(a) assume previous state is still the current state? The wrong chaining might be applied.
(b) assume current state is unknowable? A default chaining should be applied.

I don't know the answer. Neither is correct. I think operators must make the decision, based on failure analysis and 
choosing the lesser evil of applying a default policy or possibly the wrong policy.

I think a pragmatic approach is to assume the previous state is valid for some period of time,
and only after the time expires, fall back to a default forwarding configuration.
This would allow temporary network interruption or reboot of a controller without any down-side.

I can think of two ways to implement this:
1. In a global sense, revert to a default rule set after a period of controller interruption
2. On a per-rule sense, allowing timeouts on each rule. Controller can put shorter timeouts on more volatile rules.

I'm mainly thinking of classifier state, but I think similar concepts apply to SFFs.
A cohesive failure mode should be designed for the entire network.
No operator wants to ever experience this, but...

How do you feel about adding the word "temporary" ? 

   instructions even during temporary unavailability events of control plane
                            ^^^^^^^^^

-Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, June 02, 2015 5:38 AM
To: Dave Dolson; Ron Parker; Huangyong (Oliver); [email-masked]; Hongyu Li (Julio); Qin Wu; JACQUENET Christian IMT/OLN; [email-masked]; [email-masked]; Huangjing (A); Linda Dunbar
Subject: RE: Comments on draft-ww-sfc-control-plane-04

Hi Dave,

Please see inline.

Cheers,
Med

Does this make sense?

---

From: Ron Parker <[email-masked]>
Date: Tue, 2 Jun 2015 16:27:51 +0000

I agree that a likely pragmatic approach is to hold the last known policy/state as received from CP for some time and then fall back to a default policy after some timeout. 

   Ron

> On Jun 2, 2015, at 12:13 PM, Dave Dolson <[email-masked]> wrote:
>

---

From: <[email-masked]>
Date: Wed, 3 Jun 2015 05:57:22 +0000

Hi Dave,

Please see inline. 

Cheers,
Med

> Envoyé : mardi 2 juin 2015 18:14
> À : BOUCADAIR Mohamed IMT/OLN; Ron Parker; Huangyong (Oliver);
> [email-masked]
> [Med] Which means no service, no? Why not relying on "stale" information
> maintained by SFC data plane elements to process packets?
> 

[Med] Those are options that can be indeed envisaged. Applying a stale policy or a default policy when failure is much better (from a service availability standpoint) than dropping/stopping treating packets entering an SFC-enabled domain during CP failure events. The question is which strategy would better ensure a service (relying on service chains) will still be delivered even during CP failure events. This can be left to the taste of operators.

> IP address assignment is dynamic.

[Med]  I see your point. FWIW, we already have this text:

   o  Adjust classification rules when rules are based on volatile
      identifiers (e.g., an IPv4 address, IPv6 prefix).

> I don't know the answer. Neither is correct. I think operators must make
> the decision, based on failure analysis and

[Med] The value I see in assigning timeouts is that, in addition to self-clearing entries, long-lived entries may be serviced during long failure periods compared to short-lived entries.   

>    issue, discussed in Section 2.3 of [RFC7498], supposed to be solved

[Med] Works for me. I implemented this change in my local copy. Thank you.

> To: Dave Dolson; Ron Parker; Huangyong (Oliver); [email-masked]; Hongyu Li
> (Julio); Qin Wu; JACQUENET Christian IMT/OLN;
> > But I believe the wording in the text precludes OpenFlow "fail
> standalone
> > mode".
> >
> > The wording is "... must keep on processing incoming packets according
> to
> > the
> > As I read it, this prohibits any special failure mode behavior, and
> hence
> > is too strongly worded.
> >
> The point is to encourage SFC mechanisms that do not degrade the
> serviceability of an SFC-enabled domain. If such requirement is not met,
> then service disruption is likely...which is not desired. If activating
> SFC solution will lead to more unavailability events, then I do think we
> are not addressing correctly the SFC problem space (RFC7498).
> 
> Does this make sense?
> 
> [Med] Which means no service, no? Why not relying on "stale" information
> maintained by SFC data plane elements to process packets?
> 
> >
> [Med] The point about timeouts is a good point. I do personally think that
> associating timeouts with classification entries will ease the management
> of classification entries (especially the removal of obsolete entries by
> local decisions at the classifier).
> 
> [Med] This depends on the timeout (that can be expressed in days, months,
> etc.) or be set to infinite (for entries that are supposed to last for too
> too long periods).
> 
> >
> >
> > -Dave
> >
> >
> >
> >    opaque meaning. Meta-data attributes include "scope" (per-packet,
> per-
> > flow