Subject: [sfc] draft-boucadair-sfc-requirements-03 Service function discovery

From: Dave Dolson <[email-masked]>
Date: Tue, 4 Mar 2014 01:37:02 +0000

I'm looking at the "must" service function discovery requirements in draft-boucadair-sfc-requirements.

Some of these requirements seem incompatible with a PDP/orchestrated approach, which some have been discussing.

For example,
   DISC_REQ#3:  The solution MUST allow for the dynamic discovery of all
                locations where a given Service Function may reside and
                be invoked for a given SF chain.  Particularly, the
                solution MUST allow for the dynamic discovery of both
                IPv4 and IPv6 locators of a Service Function instance.

Intended or not, I've got router discovery protocol in my mind when I read this. Broadcast "who is out there?"...

I don't think all operators would want this. Some would want to explicitly configure the elements that can be used.
In fact, DISC_REQ#5 identifies that there is a security problem with auto discovery.

In short, I don't think everyone wants auto discovery, so this requirement should not be "MUST".

David Dolson
Senior Software Architect
Sandvine

---

From: Ron Parker <[email-masked]>
Date: Tue, 4 Mar 2014 09:24:12 +0000

Hi, Dave.

For a chain management control plane, I had in mind more of a client/server arrangement where the PDP is the server and the SF's are the clients.   I know this is premature,  but my thinking was that the keepalive from the client doubled as a request for any chain updates that were necessary since the last poll.   In this way, service functions gain knowledge of the chains, allowing for a single flattened chain identity in the packets, and PDP gains knowledge of the liveness of the service functions.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Tuesday, March 04, 2014 1:37 AM
To: [email-masked]
Cc: [email-masked]
Subject: [sfc] draft-boucadair-sfc-requirements-03 Service function discovery

For example,

David Dolson

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 04 Mar 2014 04:37:53 -0500

I would hope that the service functions themselves (the applications) 
don't need any knowledge of the chains.  That is one of the regards 
where I have difficulty with the framework draft (on which this 
requirements draft is based.)

Yours,
Joel

On 3/4/14, 4:24 AM, Ron Parker wrote:
> Hi, Dave.
>
> For a chain management control plane, I had in mind more of a
> client/server arrangement where the PDP is the server and the SF’s are
> the clients.   I know this is premature,  but my thinking was that the
> keepalive from the client doubled as a request for any chain updates
> that were necessary since the last poll.   In this way, service
> functions gain knowledge of the chains, allowing for a single flattened
> chain identity in the packets, and PDP gains knowledge of the liveness
> of the service functions.
>
>     Ron
>
> *From:* sfc [mailto:[email-masked]] *On Behalf Of *Dave Dolson
> *Sent:* Tuesday, March 04, 2014 1:37 AM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* [sfc] draft-boucadair-sfc-requirements-03 Service function
> discovery
>
> I’m looking at the “must” service function discovery requirements in
> draft-boucadair-sfc-requirements.
>
> Some of these requirements seem incompatible with a PDP/orchestrated
> approach, which some have been discussing.
>
> For example,
>
> Intended or not, I’ve got router discovery protocol in my mind when I
> read this. Broadcast “who is out there?”…
>
> I don’t think all operators would want this. Some would want to
> explicitly configure the elements that can be used.
>
> In short, I don’t think everyone wants auto discovery, so this
> requirement should not be “MUST”.
>
> David Dolson
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Dave Dolson <[email-masked]>
Date: Tue, 4 Mar 2014 10:06:28 +0000

Ron,

I entirely agree that liveliness checking is required.

I feel that gaining knowledge of liveliness of configured service functions is different from dynamically discovering new service functions.

Is this really a MUST requirement, or an implementation choice?

-Dave

From: Ron Parker [mailto:[email-masked]]
Sent: Tuesday, March 04, 2014 9:24 AM
To: Dave Dolson; [email-masked]
Cc: [email-masked]
Subject: RE: [sfc] draft-boucadair-sfc-requirements-03 Service function discovery

Hi, Dave.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Tuesday, March 04, 2014 1:37 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [sfc] draft-boucadair-sfc-requirements-03 Service function discovery

For example,

David Dolson

---

From: Ron Parker <[email-masked]>
Date: Tue, 4 Mar 2014 10:09:33 +0000

Joel, 

It is a matter of integration.  If one wanted to colocate an SFC termination entity with a legacy service function, the appearance of the set would be that of an SFC aware service function.  This may become more important for service functions that create or modify the original flows.  The default, behavior I would expect is that subordinate flows inherit the chain is from the original flow , but perhaps this concept needs more discussion. 

    Ron

> On Mar 4, 2014, at 9:37 AM, "Joel M. Halpern" <[email-masked]> wrote:
> 
> I would hope that the service functions themselves (the applications) don't need any knowledge of the chains.  That is one of the regards where I have difficulty with the framework draft (on which this requirements draft is based.)
> 
> Yours,
> Joel
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 04 Mar 2014 05:46:56 -0500

I suspect we agree.
In order to be clear about functions, I always want to refer to the 
chain forwarding function as a distinct function.
It is always allowed to bundle functions together in delivered software. 
  Thus allowing the case of an SF with chain forwarding capability.
What concerned me was that some of the phrasing (probably from others 
using similar terms to what you used) implied that SFs had to include 
that function.  Which is what prompted my comment.

Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Tue, 4 Mar 2014 17:03:44 +0000

Joel,

Do you believe we must specify the interface and primitives between the service function and the service function forwarder?   I'm not taking a position on this at this time, but want to tease out some of the details.

I suspect this will be trickier than it at first appears once you account for proxy-type service functions like HTTP Proxy (with related value added service functions), SIP Proxy, or even a NAT function.    When a flow arrives from the service function towards the service function forwarder, and that flow was not already seen in the forwarder to service function direction, we will need  a hint from the service function -- treat the subordinate flow identically to the original flow, reclassify from scratch, or some other primitive.     And take the case of "treat the new flow the same as the old flow" -- this implies that the forwarding function handed off a local correlation id to the service function and then got it back so it could make sense of  a primitive which said "the same as the old one".

I will admit that until now, I have been more or less lumping the service function and service function forwarder together in my description of an "SFC-aware" service function.   And for simplistic service functions that don't modify the flow and don't create new flows and don't care about metadata, I've been thinking of the service function forwarder as the SFC proxy.

Thoughts on this?   Should the architecture call this out as a formal reference point?    Clearly that wouldn't prevent implementers from combining and treating the reference point as internal.

   Ron

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Tuesday, March 04, 2014 10:47 AM
To: Ron Parker
Cc: Dave Dolson; [email-masked]; [email-masked]
Subject: Re: [sfc] draft-boucadair-sfc-requirements-03 Service function discovery

I suspect we agree.
In order to be clear about functions, I always want to refer to the chain forwarding function as a distinct function.
It is always allowed to bundle functions together in delivered software. 
  Thus allowing the case of an SF with chain forwarding capability.
What concerned me was that some of the phrasing (probably from others using similar terms to what you used) implied that SFs had to include that function.  Which is what prompted my comment.

Yours,
Joel

On 3/4/14, 5:09 AM, Ron Parker wrote:
>>> client/server arrangement where the PDP is the server and the SF's are
>>> functions gain knowledge of the chains, allowing for a single 
>>> flattened chain identity in the packets, and PDP gains knowledge of 
>>> the liveness of the service functions.
>>>
>>>     Ron
>>>
>>> *Subject:* [sfc] draft-boucadair-sfc-requirements-03 Service 
>>> function discovery
>>>
>>> Intended or not, I've got router discovery protocol in my mind when 
>>> I read this. Broadcast "who is out there?"...
>>>
>>> I don't think all operators would want this. Some would want to

---

From: Joel Halpern Direct <[email-masked]>
Date: Tue, 04 Mar 2014 16:37:11 -0500

If we try to specify in full that interface for all cases, it is going 
to be hard.
So I tend to look at it as something where we will define the required 
behavior, and define how to achieve that in a few well-specified cases.
Other cases may be untenable.  For example, an HTTP proxy which 
originates new TCP connections on behalf of the user, if it is not 
upgraded to understand how service chaining works, is just going to make 
a mess.  I will be happy if we can cover 80% of the legacy cases.

Yours,
Joel

On 3/4/14, 12:03 PM, Ron Parker wrote:
> Joel,
>
> Do you believe we must specify the interface and primitives between
> the service function and the service function forwarder?   I'm not
> taking a position on this at this time, but want to tease out some of
> the details.
>
> I suspect this will be trickier than it at first appears once you
> account for proxy-type service functions like HTTP Proxy (with
> related value added service functions), SIP Proxy, or even a NAT
> function.    When a flow arrives from the service function towards
> the service function forwarder, and that flow was not already seen in
> the forwarder to service function direction, we will need  a hint
> from the service function -- treat the subordinate flow identically
> to the original flow, reclassify from scratch, or some other
> primitive.     And take the case of "treat the new flow the same as
> the old flow" -- this implies that the forwarding function handed off
> a local correlation id to the service function and then got it back
> so it could make sense of  a primitive which said "the same as the
> old one".
>
> I will admit that until now, I have been more or less lumping the
> service function and service function forwarder together in my
> description of an "SFC-aware" service function.   And for simplistic
> service functions that don't modify the flow and don't create new
> flows and don't care about metadata, I've been thinking of the
> service function forwarder as the SFC proxy.
>
> Thoughts on this?   Should the architecture call this out as a formal
> reference point?    Clearly that wouldn't prevent implementers from
> combining and treating the reference point as internal.
>
> Ron
>
>
> -----Original Message----- From: Joel M. Halpern
> [mailto:[email-masked]] Sent: Tuesday, March 04, 2014 10:47 AM
> To: Ron Parker Cc: Dave Dolson;
> [email-masked]; [email-masked]
> I suspect we agree. In order to be clear about functions, I always
> want to refer to the chain forwarding function as a distinct
> function. It is always allowed to bundle functions together in
> delivered software. Thus allowing the case of an SF with chain
> forwarding capability. What concerned me was that some of the
> phrasing (probably from others using similar terms to what you used)
> implied that SFs had to include that function.  Which is what
> prompted my comment.
>
> Yours, Joel
>
>> It is a matter of integration.  If one wanted to colocate an SFC
>> termination entity with a legacy service function, the appearance
>> of the set would be that of an SFC aware service function.  This
>> may become more important for service functions that create or
>> modify the original flows.  The default, behavior I would expect is
>> that subordinate flows inherit the chain is from the original flow
>> , but perhaps this concept needs more discussion.
>>
>> Ron
>>
>>> I would hope that the service functions themselves (the
>>> applications) don't need any knowledge of the chains.  That is
>>> one of the regards where I have difficulty with the framework
>>> draft (on which this requirements draft is based.)
>>>
>>> Yours, Joel
>>>
>>>> On 3/4/14, 4:24 AM, Ron Parker wrote: Hi, Dave.
>>>>
>>>> client/server arrangement where the PDP is the server and the
>>>> SF's are the clients.   I know this is premature,  but my
>>>> thinking was that the keepalive from the client doubled as a
>>>> request for any chain updates that were necessary since the
>>>> last poll.   In this way, service functions gain knowledge of
>>>> the chains, allowing for a single flattened chain identity in
>>>> the packets, and PDP gains knowledge of the liveness of the
>>>> service functions.
>>>>
>>>> Ron
>>>>
>>>> *From:* sfc [mailto:[email-masked]] *On Behalf Of *Dave
>>>> Dolson *Sent:* Tuesday, March 04, 2014 1:37 AM *To:*
>>>> [email-masked] *Cc:*
>>>> [email-masked] *Subject:* [sfc]
>>>> draft-boucadair-sfc-requirements-03 Service function discovery
>>>>
>>>> I'm looking at the "must" service function discovery
>>>> requirements in draft-boucadair-sfc-requirements.
>>>>
>>>> Some of these requirements seem incompatible with a
>>>> PDP/orchestrated approach, which some have been discussing.
>>>>
>>>> For example,
>>>>
>>>> Intended or not, I've got router discovery protocol in my mind
>>>> when I read this. Broadcast "who is out there?"...
>>>>
>>>> I don't think all operators would want this. Some would want
>>>> to explicitly configure the elements that can be used.
>>>>
>>>> _______________________________________________ sfc mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/sfc
>>>>
>>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 5 Mar 2014 18:58:37 +0000

I would suggest that any change in a service path definition would be an explicit push from the PDP rather than a pull from the client.

Sent from my iPhone

On Mar 4, 2014, at 4:24 AM, "Ron Parker" <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Dave.

For a chain management control plane, I had in mind more of a client/server arrangement where the PDP is the server and the SF’s are the clients.   I know this is premature,  but my thinking was that the keepalive from the client doubled as a request for any chain updates that were necessary since the last poll.   In this way, service functions gain knowledge of the chains, allowing for a single flattened chain identity in the packets, and PDP gains knowledge of the liveness of the service functions.

   Ron

I’m looking at the “must” service function discovery requirements in draft-boucadair-sfc-requirements.

For example,

Intended or not, I’ve got router discovery protocol in my mind when I read this. Broadcast “who is out there?”…

I don’t think all operators would want this. Some would want to explicitly configure the elements that can be used.
In fact, DISC_REQ#5 identifies that there is a security problem with auto discovery.

In short, I don’t think everyone wants auto discovery, so this requirement should not be “MUST”.

David Dolson

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

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 5 Mar 2014 19:01:52 +0000

Either the SF or the proxy (depending upon who processes the SFC encap) need knowledge of the service paths they participate in plus the mapping from path to associated chain for identification of local SF applicability and next SF.

Sent from my iPhone

> On Mar 4, 2014, at 4:38 AM, "Joel M. Halpern" <[email-masked]> wrote:
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 05 Mar 2014 14:09:36 -0500

As I consider there to be a meaningful and significant distinction 
between the Service Chain Forwarding functions and the proxy.  As such, 
I do not consider that the SF needs this capability in the absence of a 
proxy.

Additionally, I want to emphasis that I believe the architecture needs 
to support the cases where the transport can forward packets across more 
than one service function (for example in the cases that Dave talked 
about using VLANs.)  As such, the forwarding function may not even be 
examining the path identifier in the service chain header.

Yours,
Joel

---

From: Qin Wu <[email-masked]>
Date: Wed, 5 Mar 2014 19:10:08 +0000

Why pull should be forbidden?

Regards!
-Qin
发件人: sfc [mailto:[email-masked]] 代表 Jim Guichard (jguichar)
发送时间: 2014年3月6日 2:59
收件人: Ron Parker
抄送: [email-masked]; [email-masked]; Dave Dolson
主题: Re: [sfc] draft-boucadair-sfc-requirements-03 Service function discovery

Sent from my iPhone

   Ron

For example,

David Dolson

---

From: Qin Wu <[email-masked]>
Date: Wed, 5 Mar 2014 19:18:05 +0000

I prefer only proxy or the box which the SF is embedded knows the service functions path. 

Regards!
-Qin
-----邮件原件-----
发件人: sfc [mailto:[email-masked]] 代表 Jim Guichard (jguichar)
发送时间: 2014年3月6日 3:02
收件人: Joel M. Halpern
抄送: [email-masked]; [email-masked]; Dave Dolson; Ron Parker
主题: Re: [sfc] draft-boucadair-sfc-requirements-03 Service function discovery

Sent from my iPhone

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 05 Mar 2014 14:27:58 -0500

Why would we as the IETF mandate the packaging of the functions?  You
certainly can deliver them together.  But equally, other folks can
deliver them separately.  Yes, folks will have to make them work
together.  In many cases, that will be easy.  In others, it will not be
easy.  But requiring the app to be the forwarder creates major
constraints on the behavior and possible deployments.

Yours,
Joel

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 5 Mar 2014 19:30:42 +0000

I did not say that it should but merely suggested a preference for push.

Sent from my iPhone

On Mar 5, 2014, at 2:10 PM, "Qin Wu" <[email-masked]<mailto:[email-masked]>> wrote:

Regards!
-Qin
发件人: sfc [mailto:[email-masked]] 代表 Jim Guichard (jguichar)
发送时间: 2014年3月6日 2:59
收件人: Ron Parker
抄送: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Dave Dolson
主题: Re: [sfc] draft-boucadair-sfc-requirements-03 Service function discovery

Sent from my iPhone

   Ron

For example,

David Dolson

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 5 Mar 2014 19:32:36 +0000

+1 .. 

Sent from my iPhone

> On Mar 5, 2014, at 2:28 PM, "Joel M. Halpern" <[email-masked]> wrote:
>

---

From: Qin Wu <[email-masked]>
Date: Wed, 5 Mar 2014 19:38:02 +0000

I agree with your point. However bigger benefit to deliver them together is to make service topology creation more easier. You only need to gather sf related performance information and capability information using management plane protocol and aggregate with the underlying network topology.
Using either existing control plane in the underlying network that gathers network topo or new control plane in the overlay to distribute sf related information is painful since sf failure or moving can lead to frequent update to service topology. Baking service chaining info into service topo make that even painful.

Regards!
-Qin
-----邮件原件-----
发件人: Joel M. Halpern [mailto:[email-masked]] 
发送时间: 2014年3月6日 3:28
收件人: Qin Wu; Jim Guichard (jguichar)
抄送: [email-masked]; [email-masked]; Dave Dolson; Ron Parker
主题: Re: 答复: [sfc] draft-boucadair-sfc-requirements-03 Service function discovery

Why would we as the IETF mandate the packaging of the functions?  You certainly can deliver them together.  But equally, other folks can deliver them separately.  Yes, folks will have to make them work together.  In many cases, that will be easy.  In others, it will not be easy.  But requiring the app to be the forwarder creates major constraints on the behavior and possible deployments.

Yours,
Joel

On 3/5/14, 2:18 PM, Qin Wu wrote:
>>> Intended or not, I’ve got router discovery protocol in my mind when 
>>> I read this. Broadcast “who is out there?”…
>>>

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 5 Mar 2014 20:17:52 +0000

Joel,

On Mar 5, 2014, at 2:09 PM, Joel M. Halpern <[email-masked]> wrote:

> As I consider there to be a meaningful and significant distinction between the Service Chain Forwarding functions and the proxy.  As such, I do not consider that the SF needs this capability in the absence of a proxy.
> 

Agreed, we should not impose forwarding requirement onto SF.   The SFC-proxy assumes responsibility for SFC encap handling, the rest of the architecture remains unchanged (i.e. the forwarding is performed by the appropriate logical block)

> Additionally, I want to emphasis that I believe the architecture needs to support the cases where the transport can forward packets across more than one service function (for example in the cases that Dave talked about using VLANs.)  As such, the forwarding function may not even be examining the path identifier in the service chain header.
> 

You draw an interesting distinction: I suggest that if there's no SFC encap, then "chaining" can occur as needed, but it's somewhat orthogonal to SFC (unless of course a proxy is being used).

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 5 Mar 2014 20:18:45 +0000

Agreed, let's consider all element logical, and allow implementations to decide on packaging.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 05 Mar 2014 15:22:51 -0500

In line, with some pruning.  Joel

> On Mar 5, 2014, at 2:09 PM, Joel M. Halpern <[email-masked]>
...
>> Additionally, I want to emphasis that I believe the architecture
>> needs to support the cases where the transport can forward packets
>> across more than one service function (for example in the cases
>> that Dave talked about using VLANs.)  As such, the forwarding
>> function may not even be examining the path identifier in the
>> service chain header.
>>
>
> You draw an interesting distinction: I suggest that if there's no SFC
> encap, then "chaining" can occur as needed, but it's somewhat
> orthogonal to SFC (unless of course a proxy is being used).

There are hybrid cases.  I may use transport to handle the first three 
SFs in a a chain, then have to forward based on the the NSH path ID, and 
then be able to use transport for the next two SFs.

Also, if we do this right, the SF won't know the difference.  For SFs 
that are metadata aware, they would still have access to the metadata.

Yours,
Joel

---

From: Nicolas BOUTHORS <[email-masked]>
Date: Wed, 5 Mar 2014 21:10:39 +0000

Joel, Paul

>> Agreed, we should not impose forwarding requirement onto SF.   The SFC-proxy assumes responsibility for SFC encap handling, the rest of the architecture remains unchanged (>> i.e. the forwarding is performed by the appropriate logical block)

A reminder maybe.  Routing traffic is not the only objective of SFC, metadata handling is one too.

Not imposing forwarding requirement onto SF should not mean that we do not pass inband metadata (if so exist) to the SF including possible contextual information
such as policy id, application id or subscriber id, as set by the classifier and possibly modified by previous SF in the path.

Nicolas

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 5 Mar 2014 21:24:06 +0000

On Mar 5, 2014, at 3:22 PM, Joel M. Halpern <[email-masked]> wrote:

> There are hybrid cases.  I may use transport to handle the first three SFs in a a chain, then have to forward based on the the NSH path ID, and then be able to use transport for the next two SFs.
> 
> Also, if we do this right, the SF won't know the difference.  For SFs that are metadata aware, they would still have access to the metadata.
> 

I characterize that as: SF-encap aware + proxy (i.e. the SFF, as per the architecture draft) to enable the non-SFC aware functions.  So, yup, we are on the same page and consistent with the arch draft.

---

From: <[email-masked]>
Date: Tue, 11 Mar 2014 14:12:47 +0100

Dear David,

The generic SF discovery requirement is captured in https://tools.ietf.org/html/draft-boucadair-sfc-requirements-03#page-7:

   REQ#29:  Means to dynamically discover Service Functions SHOULD be
            supported.

As you can see the requirement is not a "MUST" but as a "SHOULD".

Section 4 provides a detailed requirements list ** if ** such discovery procedure is to be supported by an SFC domain. Section 4 says the following:

   This section lists the set of requirements for the Service Function
   Discovery procedure (denoted hereafter as "the solution").

Requirements in Section 4 apply only of a discovery solution is to be specified.

Hope this clarifies your concern.

Cheers,
Med

De : Dave Dolson [mailto:[email-masked]]
Envoyé : mardi 4 mars 2014 02:37
À : [email-masked]
Cc : [email-masked]
Objet : draft-boucadair-sfc-requirements-03 Service function discovery

For example,

David Dolson

---

From: Dave Dolson <[email-masked]>
Date: Tue, 11 Mar 2014 14:50:12 +0000

OK, I understand. I think the wording within section 4 should be more explicit that section 4 is optional.

Yet still, I don't know how a discovery procedure would be done. How is a network element supposed to discover an IP address of an SF in a non-local data center? A machine is powered on somewhere and it is discovered? No, that cannot be what you intended.  I don't think you really mean this to be configuration-less like router discovery, so what does it mean?

David Dolson
Senior Software Architect, Sandvine Inc.

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 11, 2014 9:13 AM
To: Dave Dolson; [email-masked]
Cc: [email-masked]
Subject: RE: draft-boucadair-sfc-requirements-03 Service function discovery

Dear David,

Cheers,
Med

De : Dave Dolson [mailto:[email-masked]]
Envoyé : mardi 4 mars 2014 02:37
À : [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>
Objet : draft-boucadair-sfc-requirements-03 Service function discovery

For example,

David Dolson

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 11 Mar 2014 12:36:44 -0400

What is the motivation for including service discovery in this work?  It 
seems likely to be unnecessary in many cases, and even when needed it 
does not seem related to the goals in the charter?

Yours,
Joel

On 3/11/14, 9:12 AM, [email-masked] wrote:
> Dear David,
>
> The generic SF discovery requirement is captured in
> */https://tools.ietf.org/html/draft-boucadair-sfc-requirements-03#page-7:/*
>
> As you can see the requirement is not a “MUST” but as a “SHOULD”.
>
> Section 4 provides a detailed requirements list ** if ** such discovery
> procedure is to be supported by an SFC domain. Section 4 says the following:
>
> *De :*Dave Dolson [mailto:[email-masked]]
> *Envoyé :* mardi 4 mars 2014 02:37
> *À :* [email-masked]
> *Cc :* [email-masked]
> *Objet :* draft-boucadair-sfc-requirements-03 Service function discovery
>

---

From: <[email-masked]>
Date: Thu, 27 Mar 2014 08:52:59 +0100

Dear Dave,

I made the following changes to the document:

OLD:

NEW:

            *  Section 4 discusses more detailed requirements for such
               discovery mechanism if enabled in a given domain.

And

OLD:
   This section lists the set of requirements for the Service Function
   Discovery procedure (denoted hereafter as "the solution").
NEW:
   This section lists the set of requirements for the Service Function
   Discovery procedure (denoted hereafter as "the solution").  These
   requirements expand the discovery requirement listed in Section 3.
   These requirements apply only with a discovery solutions is to be
   supported by an SFC domain.

Please let me know if these modifs solve your concern.

As for your question, the document focuses only on the requirement, not the solution to fulfil it. I suggest, that at this stage we avoid getting into solution-specific discussions.

Cheers,
Med

De : Dave Dolson [mailto:[email-masked]]
Envoyé : mardi 11 mars 2014 15:50
À : BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]
Objet : RE: draft-boucadair-sfc-requirements-03 Service function discovery

David Dolson

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, March 11, 2014 9:13 AM
To: Dave Dolson; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: draft-boucadair-sfc-requirements-03 Service function discovery

Dear David,

Cheers,
Med

For example,

David Dolson

---

From: <[email-masked]>
Date: Thu, 27 Mar 2014 08:54:55 +0100

Hi Joel,

The text says:

Do you have concerns with this particular requirement?

Cheers,
Med

>-----Message d'origine-----
>De : Joel M. Halpern [mailto:[email-masked]]
>Envoyé : mardi 11 mars 2014 17:37
>À : BOUCADAIR Mohamed IMT/OLN; Dave Dolson; draft-boucadair-sfc-
>[email-masked]
>Cc : [email-masked]
>Objet : Re: [sfc] draft-boucadair-sfc-requirements-03 Service function
>discovery
>
>> Intended or not, I've got router discovery protocol in my mind when I
>> read this. Broadcast "who is out there?".
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 27 Mar 2014 09:45:59 -0400

Yes, I have a problem with this requirement.  Even at a SHOULD level.
I do not see how or why this would be included in our work at all. 
Service instance location is a problem of concern to the chain 
establishment mechanism.  It may or may not need discovery.  But the 
tools used there are not driven by requirements of the data plane for 
service chaining.  Hence, discovery does not seem to fit the charter.

Yours,
Joel

---

From: Jerome Moisand <[email-masked]>
Date: Thu, 27 Mar 2014 13:47:36 +0000

Agreed.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, March 27, 2014 9:46 AM
To: [email-masked]; Dave Dolson; [email-masked]
Cc: [email-masked]
Subject: Re: [sfc] draft-boucadair-sfc-requirements-03 Service function discovery

Yes, I have a problem with this requirement.  Even at a SHOULD level.
I do not see how or why this would be included in our work at all. 
Service instance location is a problem of concern to the chain establishment mechanism.  It may or may not need discovery.  But the tools used there are not driven by requirements of the data plane for service chaining.  Hence, discovery does not seem to fit the charter.

Yours,
Joel

On 3/27/14, 3:54 AM, [email-masked] wrote:
>> De : Joel M. Halpern [mailto:[email-masked]] Envoyé : mardi 11 
>> mars 2014 17:37 À : BOUCADAIR Mohamed IMT/OLN; Dave Dolson; 
>> draft-boucadair-sfc- [email-masked] Cc : [email-masked] 
>> Objet : Re: [sfc] draft-boucadair-sfc-requirements-03 Service 
>> function discovery
>>
>> What is the motivation for including service discovery in this work?  
>> It seems likely to be unnecessary in many cases, and even when needed 
>> it does not seem related to the goals in the charter?
>>
>> Yours,
>> Joel
>>
>>> */https://tools.ietf.org/html/draft-boucadair-sfc-requirements-03#pa
>>> ge-
>> 7:/*
>>>
>>> Section 4 provides a detailed requirements list ** if ** such 
>>> discovery procedure is to be supported by an SFC domain. Section 4 
>>> says the
>> following:
>>>
>>> *De :*Dave Dolson [mailto:[email-masked]] *Envoyé :* mardi 4 
>>> mars 2014 02:37 *À :* 
>>> [email-masked]
>>> *Cc :* [email-masked]
>>> I read this. Broadcast "who is out there?".
>>>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 27 Mar 2014 14:13:31 +0000

I agree with Joel. From a requirements standpoint I think we should be
focused on those requirements that MUST be present in order to build
solutions that satisfy all of the pain points as documented in the problem
statement. While it is true that dynamic discovery of service functions
might be nice for some folks it is clearly not a requirement that if not
present prevents us from building a solution to satisfy the problem
statement. 

On 3/27/14, 9:45 AM, "Joel M. Halpern" <[email-masked]> wrote:

>>>It

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 27 Mar 2014 15:23:53 +0000

+1

Surendra.

On 3/27/14 7:13 AM, "Jim Guichard (jguichar)" <[email-masked]> wrote:

>>>>>*/https://tools.ietf.org/html/draft-boucadair-sfc-requirements-03#page
>>>>>-
>>>> 7:/*
>>>>>

---

From: <[email-masked]>
Date: Fri, 28 Mar 2014 11:04:28 +0100

Hi Joel,

It seems we both agree the discovery functionality is not mandatory. The solution should not assume the existence of such discovery.. that's evident from my side. I even think that the solution should work without assuming any control plane.

The functionality is listed in the document because we should acknowledge its usefulness from an operational standpoint. Activating the feature is deployment-specific. 

It is not because some can use static routing schemes that dynamic routing should be abolished!

Cheers,
Med

>Envoyé : jeudi 27 mars 2014 14:46

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 28 Mar 2014 11:38:49 -0400

Med, your comparison with static and dynamic routing is completely 
missing the point, nad probably misleading to readers.
In this case, including discovery in the document does not add anything 
of relevance to the SFC working group.  Yes, if the document were 
intended to be an overview of requirements for the entire service 
chaining ecosystem then a discussion of discovery and its possible roles 
would fit.  But that is not the document we are working on, as far as I 
know.

Yours,
Joel

---

From: <[email-masked]>
Date: Mon, 31 Mar 2014 13:33:16 +0200

Hi Joel,

I can claim in my turn that you missed the point of my comparison but I won't do that. 

You said "But that is not the document we are working on". I'm puzzled with this assertion. Can you please share what is your reference?

FWIW, my reference for including service function discovery is this excerpt from the charter: 

"
The working group will examine what information needs to be gathered
from the network and service functions in support of Service Function
Chaining and how that information may be made available to the
components of the Service Function Chaining architecture.
"

Another motivation for including service discovery is that the problem statement is raising the complexity of manual configuration (in general). SF discovery feature may be a helper to introduce some automation in the way SFCs are structured, and therefore remove some of manual configuration.

Despite this divergence about the scope of the requirement draft, I do think that we both agree on the level of support of the service function discovery.

Cheers,
Med

>Envoyé : vendredi 28 mars 2014 16:39
>> It seems we both agree the discovery functionality is not mandatory. The
>solution should not assume the existence of such discovery.. that's evident
>from my side. I even think that the solution should work without assuming
>any control plane.
>>
>> The functionality is listed in the document because we should acknowledge
>its usefulness from an operational standpoint. Activating the feature is
>deployment-specific.
>>
>>>>>> */https://tools.ietf.org/html/draft-boucadair-sfc-requirements-
>03#page-
>>>>> 7:/*
>>>>>>
>>>>>>       DISC_REQ#3:  The solution MUST allow for the dynamic discovery
>of
>>> all
>>>>>>
>>>>>>                    locations where a given Service Function may
>reside
>>> and
>>>>>>

---

From: Ron Parker <[email-masked]>
Date: Mon, 31 Mar 2014 12:00:47 +0000

Med, Joel,

Is it possible some are thinking of "discovery" differently than others?   For example if in a future control plane, SF's (as clients) registered with PDP (as server) would that meet the definition?

   Ron

> On Mar 31, 2014, at 7:33 AM, "[email-masked]" <[email-masked]> wrote:
> 
> Hi Joel,
>

---

From: <[email-masked]>
Date: Mon, 31 Mar 2014 14:17:48 +0200

Hi Ron,

Yes, your registration mode is a way to meet the discovery requirement. Of course, others may propose other solutions to meet that requirement as well.

Cheers,
Med

>De : Ron Parker [mailto:[email-masked]]
>Envoyé : lundi 31 mars 2014 14:01
>Cc : Joel M. Halpern; Dave Dolson; draft-boucadair-sfc-
>[email-masked]; [email-masked]
>Is it possible some are thinking of "discovery" differently than others?
>For example if in a future control plane, SF's (as clients) registered with
>PDP (as server) would that meet the definition?
>
>   Ron
>
>
>> You said "But that is not the document we are working on". I'm puzzled
>with this assertion. Can you please share what is your reference?
>>
>> Another motivation for including service discovery is that the problem
>statement is raising the complexity of manual configuration (in general).
>SF discovery feature may be a helper to introduce some automation in the
>way SFCs are structured, and therefore remove some of manual configuration.
>>
>> Despite this divergence about the scope of the requirement draft, I do
>think that we both agree on the level of support of the service function
>discovery.
>>
>> Cheers,
>> Med
>>
>function
>>>>>>>>      REQ#29:  Means to dynamically discover Service Functions
>SHOULD
>>> be
>>>>>>>>
>>>>>>>>               supported.
>>>>>>>>
>>>>>>>> Requirements in Section 4 apply only of a discovery solution is to
>be
>>>>>>>> specified.
>>>>>>>>
>>>>>>>> I'm looking at the "must" service function discovery requirements
>in
>PDP/orchestrated
>I
>>>>>>>> In fact, DISC_REQ#5 identifies that there is a security problem
>with
>>>>>>>> auto discovery.
>>>>>>>>