Subject: Re: [nsc] NSC BoF Outcomes

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 3 Sep 2013 20:20:32 +0000

Hi Adrian,

Thank you for this summary and for the kind words although I think "dazed"
would be more appropriate than cool ;-)

Please forgive my belated response but there have been numerous ongoing
activities that I would like to share with the list as follows. Please see
<Jim> inline.

On 8/13/13 7:20 AM, "Adrian Farrel" <[email-masked]> wrote:

>Hi NSC list,
>
>Sorry for the delay in this email - I took a short break after Berlin.
>
>Thanks for the focus and effort that went into the NSC BoF in Berlin.
>Thanks in
>particular to Thomas and Jim for their work herding the ducks and
>delivering the
>BoF that the IESG asked for. Special mention for Jim in being so cool
>turning up
>to chair the BoF after a complete travel nightmare.
>
>I believe that the BoF delivered what the IESG had hoped to see. That is,
>it
>allowed a number of network operators from a broad spectrum of network
>types to
>describe the problem space that they are interested in.
>
>It was clear to me that there is strong interest among network operators
>in
>investigating the concept of service chaining, and among equipment
>vendors and
>solution providers in addressing the requirements. This is very promising
>for
>the potential of forming critical mass around working in this area.

Jim> there is certainly strong interest for this work and the list of
folks willing to participate/contribute grows daily.

>
>However, it was less clear to me that there is agreement about the layer
>in
>which service chaining has to be solved. I felt that some people were
>talking
>about service chaining in the application layer, some about service
>chaining
>based on flows, and some about per-packet services. The solutions are, I
>think,
>likely to be very different for the different problems, and it would be
>wrong to
>try to bunch them all together.

Jim> although there was certainly initial confusion I believe this is
becoming less and less so as we socialize the basic idea of service
chaining; indeed, as we move forward we will reflect a more common
understanding within the problem statement.

>
>Since it is clear that a lot of people want to work on this, the next
>step must
>be to get a little more focus. This could be a small amount of work, and
>we may
>find that consensus comes quickly and easily. But it may also mean that
>some of
>the use cases need to be discarded - that doesn't mean that they are not
>valid,
>only that they don't fit into the focused effort that may become a working
>group.
>
>I suggest that the next steps (in no particular order) are as follows:
>- Everyone should revise their drafts. Add clarity and focus. Merge with
>other
>drafts if appropriate.

Jim> several of the existing drafts have been revised (several times)
since the BoF in Berlin and new content/authors added. Several new drafts
have been posted. Further revisions to these drafts is ongoing with many
contributors to this process.

>- Look for missing work. Is there a need for a simple and clear
>over-arching
>document? Terminology? Figures? Work cooperatively to fill the gaps.

Jim> A number of new and/or updated drafts have been posted including a
framework (draft-boucadair-service-chaining-framework), high-level
requirements (draft-boucadair-chaining-requirements), and problem
statement (draft-quinn-nsc-problem-statement). We expect these drafts to
evolve as more review comments are received and the drafts further
socialized within the IETF community.

>- Use the mailing list to narrow down and reach agreement on what you
>want to
>work on.
>- Start a thread on a potential WG charter. Maybe a couple of you (the BoF
>chairs?) could agree to hold the pen and make a first draft? Try to get
>the text
>lean and tight. Try to get consensus.

Jim> I have initiated a discussion thread today with a proposed WG charter
for consideration by the mailing list.

>- Start to plan for a WG-forming BoF. Look carefully at the dates for the
>next
>IETF (IETF-88, Vancouver) and decide whether the deadline is too tight.
>Recall
>that going off half-cocked does no-one any favors. See whether you can get
>everything ready in time.

Jim> a WG-forming BoF request has been posted to
http://trac.tools.ietf.org/bof/trac/

>- Apply to the IAB for a BoF shepherd. This is an IAB member who will
>give you
>dedicated time and advice to help focus the technical effort and prepare
>for a
>successful WG-forming BoF.

Jim> Joel Halpern has very kindly accepted to act as the BoF shepherd.
Thank you Joel !!

>
>We do not, at this stage, need to worry about where within the IETF
>structure
>this work will sit. Let's continue to pursue the effort within the
>Routing Area,
>and defer discussion about where it will live until we have a better
>handle on
>the description of the problem.
>
>Don't forget that you can review the BoF via the Meetecho archive, the
>usual
>audio archive, and the online materials.
>
>Please come back to me with any questions.
>
>Thanks,
>Adrian
>

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 3 Sep 2013 21:54:52 +0000

My comments are inserted below marked by [Linda]:

> -----Original Message-----
> 
> >

It is still not clear which layer service functions are chained together. The draft-quinn-nsc-problem-statement-03 discussed chaining of service functions that can be a network or application based packet treatment,..., to enable a service offered by a network operators. 

Today, there are many services offered by operators, e.g. L2VPN, L3VPN, P2P paths, etc. So you can interpret NSC as chaining L2/L3 service functions (like proxy forwarding, or fragmentation, etc.); 
You can also interpret NSC as chaining L4  (and above) service functions; or chaining of mixed L4-L7 service functions (i.e. with some service nodes consuming packets and reinitiate new packets).  

Is NSC including all chaining of all those services? 

Layer 2/3 service function chaining might require different schemes than Layer 4-7 service chaining. Therefore, it is more effective to define them separately to make the discussion more focused.

Linda Dunbar

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

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 3 Sep 2013 18:18:38 -0400

> It is still not clear which layer service functions are chained together. The draft-quinn-nsc-problem-statement-03 discussed chaining of service functions that can be a network or application based…

	Why do you think that matters?

> You can also interpret NSC as chaining L4  (and above) service functions; or chaining of mixed L4-L7 service functions (i.e. with some service nodes consuming packets and reinitiate new packets).  

	You can, and people actually do implement this today. 

> Layer 2/3 service function chaining might require different schemes than Layer 4-7 service chaining. Therefore, it is more effective to define them separately to make the discussion more focused.

	I do not think so. I'd prefer to not make this only as complicated as it needs to be, and no more. There are implementations of Layer 2 and 3 chaining that are all done with the same encap/provisioning systems. 

	--Tom

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 3 Sep 2013 22:25:39 +0000

Thomas, 

Are you saying that the NSC scope includes chaining Layer 2, Layer 3 service functions, Layer 4 to Layer 7 service functions, and various combination of them? 

Linda

> From: Thomas Nadeau [mailto:[email-masked]]
> Sent: Tuesday, September 03, 2013 5:19 PM
> To: Linda Dunbar
> Cc: Jim Guichard (jguichar); [email-masked]; [email-masked]; Thomas
> Narten; Stewart Bryant (stbryant)
> Subject: Re: [nsc] NSC BoF Outcomes
> 
> 
> >>> which service chaining has to be solved. I felt that some people
> >>> were talking about service chaining in the application layer, some
> >>> about service chaining based on flows, and some about per-packet
> >>> services. The solutions are,
> >> I
> >>> think,
> >>> likely to be very different for the different problems, and it
> would
> >> be
> >>> wrong to
> > It is still not clear which layer service functions are chained
> together. The draft-quinn-nsc-problem-statement-03 discussed chaining
> of service functions that can be a network or application based packet
> treatment,..., to enable a service offered by a network operators.
> 
> > Today, there are many services offered by operators, e.g. L2VPN,
> > L3VPN, P2P paths, etc. So you can interpret NSC as chaining L2/L3
> service functions (like proxy forwarding, or fragmentation, etc.); You
> can also interpret NSC as chaining L4  (and above) service functions;
> or chaining of mixed L4-L7 service functions (i.e. with some service
> nodes consuming packets and reinitiate new packets).
> 
> > Layer 2/3 service function chaining might require different schemes
> than Layer 4-7 service chaining. Therefore, it is more effective to
> define them separately to make the discussion more focused.
> 
> 	I do not think so. I'd prefer to not make this only as
> complicated as it needs to be, and no more. There are implementations
> of Layer 2 and 3 chaining that are all done with the same
> encap/provisioning systems.
> 
> 	--Tom
> 
> 
> >
> > Linda Dunbar
> >
> >>

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 3 Sep 2013 18:27:49 -0400

> Are you saying that the NSC scope includes chaining Layer 2, Layer 3 service functions, Layer 4 to Layer 7 service functions, and various combination of them? 

	I don't define the scope; thats up to the ADs.

	Could you please answer the question below? 

	--Tom

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 3 Sep 2013 22:47:59 +0000

Here are some of the reasons that chaining of Layer 2 and 3 service functions are different from chaining of Layer 4 to 7 service functions (I will add more later):

- Layer 4 to Layer 7 service functions (or service nodes) are to apply actions to data packets traversing through. They don't impact overall network topologies/routes/restorations. 

- Layer 4-7 service functions drop, pass, consume, re-initiate packets, etc. They don't change network topologies, and they don't impact network restoration scheme (e.g. fast re-route).  When you move a Layer 4 service module from Location A to B, the Layer 2/3 topology is not changed, routes/restoration are not changed. 

- When chaining Layer 4 to Layer 7 service functions together, like S1->S2->S3->S4, they are overlaying over the underlay network. 

-  Layer 2 and layer 3 nodes have control plane (e.g. IGP/BGP) to dynamically discover topology; forwarding paths; protection paths; restoration paths, etc. Today, all routers are connected together by links. Their topology is more like a meshed graph than chain. So when you chain Router-1<->Router-2<->Router-3, are you talking about source routing? Therefore, need a clear definition on what does it really mean by chaining Layer 2/3 service nodes. 
 
Linda

> Sent: Tuesday, September 03, 2013 5:28 PM
> To: Linda Dunbar
> Cc: [email-masked]; Jim Guichard (jguichar); Stewart Bryant (stbryant);
> Thomas Narten; [email-masked]
> > Are you saying that the NSC scope includes chaining Layer 2, Layer 3
> service functions, Layer 4 to Layer 7 service functions, and various
> combination of them?
> 
> >> Cc: Jim Guichard (jguichar); [email-masked]; [email-masked];
> >> Thomas Narten; Stewart Bryant (stbryant)
> >>>>> However, it was less clear to me that there is agreement about
> the
> >>>> layer
> >>>>> in
> >> of service functions that can be a network or application based
> >> packet treatment,..., to enable a service offered by a network
> operators.
> >>
> >> service functions (like proxy forwarding, or fragmentation, etc.);
> >> You can also interpret NSC as chaining L4  (and above) service
> >> functions; or chaining of mixed L4-L7 service functions (i.e. with
> >> some service nodes consuming packets and reinitiate new packets).
> >>
> complicated
> >> as it needs to be, and no more. There are implementations of Layer 2
> >> and 3 chaining that are all done with the same encap/provisioning
> >> systems.
> >>
> >> 	--Tom
> >>
> >>
> >>>
> >>> Linda Dunbar
> >>>
> >>>>

---

From: Ron Parker <[email-masked]>
Date: Wed, 4 Sep 2013 00:45:30 +0000

Hi, Linda.

With respect to:

Layer 4-7 services can, indeed, impact routing decisions.  For example, if the service is DPI analysis, then a detected protocol may cause the subsequent packets to be policy routed on a path different than the SPF path.

   Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Tuesday, September 03, 2013 6:48 PM
To: Thomas Nadeau
Cc: [email-masked]; Jim Guichard (jguichar); Thomas Narten; [email-masked]; Stewart Bryant (stbryant)
Subject: Re: [nsc] NSC BoF Outcomes

 
Linda

> >>>> Jim> although there was certainly initial confusion I believe 
> >>>> Jim> this
> >> is
> >>>> chaining; indeed, as we move forward we will reflect a more 
> >>>> common understanding within the problem statement.
> >>>
> >> as it needs to be, and no more. There are implementations of Layer 
> >> 2 and 3 chaining that are all done with the same encap/provisioning 
> >> systems.
> >>
> >> 	--Tom
> >>
> >>
> >>>
> >>> Linda Dunbar
> >>>
> >>>>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 4 Sep 2013 10:51:02 +0000

The same argument could be applied for firewalls as without them packets would get routed instead of perhaps dropped.

Sent from my iPhone

---

From: Jerome Moisand <[email-masked]>
Date: Wed, 4 Sep 2013 13:55:40 +0000

It seems to me that the entire point of service chaining is indeed to chain together heterogeneous service-enabling elements, and make the best out of such combo. 

Service Edge routers (including Biz-PEs, BNGs and Mobile GWs) enable L3 services, on a per subscriber basis. Firewalls can act either at L3/L4 or L4/L7 (e.g. adding some Intrusion Detection to the mix). DPI or HTTP Proxies/Filters engines act at L7. Session Border Controllers act at L7, although they do some L3/L4 processing too (NAT). All those various elements have their own strengths in terms of traffic classification and in terms of policy enforcement. Which can combined in smart ways (e.g. use DPI to identify/classify an application flow, use an edge router to perform fancy queuing based on such DPI classification among other traffic flows). 

The beauty of service chaining is to combine all those elements to make something truly useful (e.g. provide a more complex Service -with a capital 'S'- to service provider users or enterprise users). All the use cases I've heard so far from various parties do mix edge routers, security and application-oriented elements.

So... I would not be supportive to trying to separate a form of L2/L3 chaining from a form of L4/L7 chaining. On the contrary! ;-)

I would actually go as far as suggesting that we should make clearer in the proposed charter that this is a strong goal, to deal with such heterogeneous combos.

Just my 2 cents,
Jerome

====
Totally unrelated PS for Jim: you didn't answer my question about the control plane aspects, this may have slipped through the cracks! ;-)

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Wednesday, September 04, 2013 6:51 AM
To: Ron Parker
Cc: [email-masked]; Thomas Nadeau; Thomas Narten; [email-masked]; Linda Dunbar; Stewart Bryant (stbryant)
Subject: Re: [nsc] NSC BoF Outcomes

Sent from my iPhone

On Sep 3, 2013, at 8:45 PM, "Ron Parker" <[email-masked]> wrote:

> Cc: [email-masked]; Jim Guichard (jguichar); Thomas Narten; 
> [email-masked]; Stewart Bryant (stbryant)

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 4 Sep 2013 14:17:25 +0000

Hi Jerome,

My bad .. Responding to your PS ;) Š Right now the charter suggests that
the WG be responsible for defining the requirements of the control plane
with respect to service chaining. The problem here is of course that there
are multiple control planes. In my mind it makes little sense to try and
tackle them all but rather define what is necessary for a control plane to
implement to successfully enable service chains and then liaise with other
WG's on the details.

Some further comments inline.

On 9/4/13 9:55 AM, "Jerome Moisand" <[email-masked]> wrote:

>It seems to me that the entire point of service chaining is indeed to
>chain together heterogeneous service-enabling elements, and make the best
>out of such combo.

Jim> exactly. The point being separate service functions into a resource
pool that can be utilized and not constrained based on topology.

> 
>
>Service Edge routers (including Biz-PEs, BNGs and Mobile GWs) enable L3
>services, on a per subscriber basis. Firewalls can act either at L3/L4 or
>L4/L7 (e.g. adding some Intrusion Detection to the mix). DPI or HTTP
>Proxies/Filters engines act at L7. Session Border Controllers act at L7,
>although they do some L3/L4 processing too (NAT). All those various
>elements have their own strengths in terms of traffic classification and
>in terms of policy enforcement. Which can combined in smart ways (e.g.
>use DPI to identify/classify an application flow, use an edge router to
>perform fancy queuing based on such DPI classification among other
>traffic flows).

Jim> yep. 

> 
>
>The beauty of service chaining is to combine all those elements to make
>something truly useful (e.g. provide a more complex Service -with a
>capital 'S'- to service provider users or enterprise users). All the use
>cases I've heard so far from various parties do mix edge routers,
>security and application-oriented elements.
>
>So... I would not be supportive to trying to separate a form of L2/L3
>chaining from a form of L4/L7 chaining. On the contrary! ;-)
>
>I would actually go as far as suggesting that we should make clearer in
>the proposed charter that this is a strong goal, to deal with such
>heterogeneous combos.

Jim> any text and suggestion of where to insert into the charter?

>
>Just my 2 cents,
>Jerome
>
>====
>Totally unrelated PS for Jim: you didn't answer my question about the
>control plane aspects, this may have slipped through the cracks! ;-)
>
>The same argument could be applied for firewalls as without them packets
>would get routed instead of perhaps dropped.
>
>Sent from my iPhone
>
>>    - Layer 4 to Layer 7 service functions (or service nodes) are to
>>apply actions to data packets traversing through. They don't impact
>>overall network topologies/routes/restorations.
>> 
>> Layer 4-7 services can, indeed, impact routing decisions.  For example,
>>if the service is DPI analysis, then a detected protocol may cause the
>>subsequent packets to be policy routed on a path different than the SPF
>>path.
>> 
>>   Ron
>> 
>> 
>> Here are some of the reasons that chaining of Layer 2 and 3 service
>>functions are different from chaining of Layer 4 to 7 service functions
>>(I will add more later):
>> 
>> 
>> - Layer 4 to Layer 7 service functions (or service nodes) are to apply
>>actions to data packets traversing through. They don't impact overall
>>network topologies/routes/restorations.
>> 
>> - Layer 4-7 service functions drop, pass, consume, re-initiate packets,
>>etc. They don't change network topologies, and they don't impact network
>>restoration scheme (e.g. fast re-route).  When you move a Layer 4
>>service module from Location A to B, the Layer 2/3 topology is not
>>changed, routes/restoration are not changed.
>> 
>> - When chaining Layer 4 to Layer 7 service functions together, like
>>S1->S2->S3->S4, they are overlaying over the underlay network.
>> 
>> -  Layer 2 and layer 3 nodes have control plane (e.g. IGP/BGP) to
>>dynamically discover topology; forwarding paths; protection paths;
>>restoration paths, etc. Today, all routers are connected together by
>>links. Their topology is more like a meshed graph than chain. So when
>>you chain Router-1<->Router-2<->Router-3, are you talking about source
>>routing? Therefore, need a clear definition on what does it really mean
>>by chaining Layer 2/3 service nodes.
>> 
>> Linda
>>

---

From: Ron Parker <[email-masked]>
Date: Wed, 4 Sep 2013 15:39:08 +0000

Jim,

I agree that the charter should not be too specific on the design of the control plane, but rather to recognize that one could be advantageous (although not necessarily required) for the overall service chaining solution.    A control plane requirements and/or use cases document should precede any control plane protocol design or selection.

   Ron

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Wednesday, September 04, 2013 10:17 AM
To: Jerome Moisand; Ron Parker
Cc: [email-masked]; Thomas Nadeau; Thomas Narten; [email-masked]; Linda Dunbar; Stewart Bryant (stbryant)
Subject: Re: [nsc] NSC BoF Outcomes

Hi Jerome,

My bad .. Responding to your PS ;) Š Right now the charter suggests that the WG be responsible for defining the requirements of the control plane with respect to service chaining. The problem here is of course that there are multiple control planes. In my mind it makes little sense to try and tackle them all but rather define what is necessary for a control plane to implement to successfully enable service chains and then liaise with other WG's on the details.

On 9/4/13 9:55 AM, "Jerome Moisand" <[email-masked]> wrote:

>chain together heterogeneous service-enabling elements, and make the 
>best out of such combo.

>Proxies/Filters engines act at L7. Session Border Controllers act at 
>L7, although they do some L3/L4 processing too (NAT). All those various 
>elements have their own strengths in terms of traffic classification 
>and in terms of policy enforcement. Which can combined in smart ways (e.g.

Jim> yep. 

>capital 'S'- to service provider users or enterprise users). All the 
>use cases I've heard so far from various parties do mix edge routers, 

>The same argument could be applied for firewalls as without them 
>packets would get routed instead of perhaps dropped.
>
>Sent from my iPhone
>
>> Layer 4-7 services can, indeed, impact routing decisions.  For 
>>example, if the service is DPI analysis, then a detected protocol may 
>>cause the subsequent packets to be policy routed on a path different 
>>than the SPF path.
>> 
>>   Ron
>> 
>> 
>>functions are different from chaining of Layer 4 to 7 service 
>>functions (I will add more later):
>> 
>> 
>> - Layer 4-7 service functions drop, pass, consume, re-initiate 
>>packets, etc. They don't change network topologies, and they don't 
>>impact network restoration scheme (e.g. fast re-route).  When you move 
>>a Layer 4 service module from Location A to B, the Layer 2/3 topology 
>>is not changed, routes/restoration are not changed.
>> 
>>routing? Therefore, need a clear definition on what does it really 
>>mean by chaining Layer 2/3 service nodes.
>> 
>> Linda
>> 
>>> Cc: [email-masked]; Jim Guichard (jguichar); Stewart Bryant 
>>> (stbryant); Thomas Narten; [email-masked]
>>>>>>>> which service chaining has to be solved. I felt that some 
>>>>>>>> people were talking about service chaining in the application 
>>>>>>>> layer,
>>> some
>>>>>>>> about service chaining based on flows, and some about 
>>>>>>>> per-packet services. The solutions are,
>>>>>>> I
>>>>>>>> think,
>>>>> than Layer 4-7 service chaining. Therefore, it is more effective 
>>>>> to define them separately to make the discussion more focused.
>>>>> 
>>>>> 2 and 3 chaining that are all done with the same

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 4 Sep 2013 15:56:56 +0000

Is the suggestion therefore that separate data and control plane
requirements I-D's should be created rather than an overall requirements
document covering both?

On 9/4/13 11:39 AM, "Ron Parker" <[email-masked]> wrote:

>Jim,
>
>I agree that the charter should not be too specific on the design of the
>control plane, but rather to recognize that one could be advantageous
>(although not necessarily required) for the overall service chaining
>solution.    A control plane requirements and/or use cases document
>should precede any control plane protocol design or selection.
>
>   Ron
>
>
>with respect to service chaining. The problem here is of course that
>there are multiple control planes. In my mind it makes little sense to
>try and tackle them all but rather define what is necessary for a control
>plane to implement to successfully enable service chains and then liaise
>with other WG's on the details.
>

---

From: Ron Parker <[email-masked]>
Date: Wed, 4 Sep 2013 16:02:35 +0000

Yes, that is my suggestion.   It is motivated by my feeling that a control plane is advantageous but not required.    By separating them, we could more readily phase the work.

   Ron

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Wednesday, September 04, 2013 11:57 AM
To: Ron Parker; Jerome Moisand
Cc: [email-masked]; Thomas Nadeau; Thomas Narten; [email-masked]; Linda Dunbar; Stewart Bryant (stbryant)
Subject: Re: [nsc] NSC BoF Outcomes

Is the suggestion therefore that separate data and control plane requirements I-D's should be created rather than an overall requirements document covering both?

On 9/4/13 11:39 AM, "Ron Parker" <[email-masked]> wrote:

>Jim,
>
>I agree that the charter should not be too specific on the design of 
>the control plane, but rather to recognize that one could be 
>advantageous (although not necessarily required) for the overall service chaining
>My bad .. Responding to your PS ;) Š Right now the charter suggests 
>that the WG be responsible for defining the requirements of the control 
>plane with respect to service chaining. The problem here is of course 
>that there are multiple control planes. In my mind it makes little 
>sense to try and tackle them all but rather define what is necessary 
>for a control plane to implement to successfully enable service chains 
>and then liaise with other WG's on the details.
>
>Jim> exactly. The point being separate service functions into a 
>Jim> resource
>>Service Edge routers (including Biz-PEs, BNGs and Mobile GWs) enable 
>>L3 services, on a per subscriber basis. Firewalls can act either at 
>>L3/L4 or
>>L7, although they do some L3/L4 processing too (NAT). All those 
>>various elements have their own strengths in terms of traffic 
>>classification and in terms of policy enforcement. Which can combined 
>>in smart ways (e.g.
>>use DPI to identify/classify an application flow, use an edge router 
>>to perform fancy queuing based on such DPI classification among other 
>>traffic flows).
>
>Jim> yep. 
>
>> 
>>
>>The beauty of service chaining is to combine all those elements to 
>>make something truly useful (e.g. provide a more complex Service -with 
>>a capital 'S'- to service provider users or enterprise users). All the 
>>I would actually go as far as suggesting that we should make clearer 
>>in the proposed charter that this is a strong goal, to deal with such 
>>heterogeneous combos.
>
>>>impact network restoration scheme (e.g. fast re-route).  When you 
>>>move a Layer 4 service module from Location A to B, the Layer 2/3 
>>>topology is not changed, routes/restoration are not changed.
>>> 
>>>you chain Router-1<->Router-2<->Router-3, are you talking about 
>>>source routing? Therefore, need a clear definition on what does it 
>>>really mean by chaining Layer 2/3 service nodes.
>>> 
>>> Linda
>>> 
>>>> service functions, Layer 4 to Layer 7 service functions, and 
>>>> various combination of them?
>>>> 
>>>>>> service functions (like proxy forwarding, or fragmentation, 
>>>>>> etc.); You can also interpret NSC as chaining L4  (and above) 
>>>>>> service functions; or chaining of mixed L4-L7 service functions 
>>>>>> (i.e. with some service nodes consuming packets and reinitiate new packets).
>>>>>>

---

From: <[email-masked]>
Date: Wed, 4 Sep 2013 18:04:21 +0200

Hi*,

I support the publication of a single requirements document (for the sake of consistency), and which would include both control and data plane considerations among other topics.

Cheers,

Christian.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Jim Guichard (jguichar)
Envoyé : mercredi 4 septembre 2013 17:57
À : Ron Parker; Jerome Moisand
Cc : [email-masked]; Thomas Nadeau; Linda Dunbar; [email-masked]; Thomas Narten; Stewart Bryant (stbryant)
Objet : Re: [nsc] NSC BoF Outcomes

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 4 Sep 2013 16:17:07 +0000

Ron, 

My comments are inserted below: 
> From: Ron Parker [mailto:[email-masked]]
> Sent: Tuesday, September 03, 2013 7:46 PM
> To: Linda Dunbar; Thomas Nadeau
> Subject: RE: [nsc] NSC BoF Outcomes
> 
> Hi, Linda.
> 
> With respect to:
> 

[Linda] Do you call this "DPI" function that re-direct data frames to a different target (that is not the Destination of the data frame) "Layer 3" service?
When those "DPI" functions re-direct traffic, do they add another Destination address to the data frames (i.e. create a tunnel)? Or do they not touch the destination addresses in the existing data frames and expect all the nodes along the way to know how to forward the data frames? 

Bottom line, those services need to be distinguished from  traditional Layer 3 services, and be distinguished from routers/switches that dynamically establish topology, establish routes, and restoration paths. 

Linda

> etc. They don't change network topologies, and they don't impact
> network restoration scheme (e.g. fast re-route).  When you move a Layer
> 4 service module from Location A to B, the Layer 2/3 topology is not
> - When chaining Layer 4 to Layer 7 service functions together, like S1-
> >S2->S3->S4, they are overlaying over the underlay network.
> 
> people
> to

---

From: Jerome Moisand <[email-masked]>
Date: Wed, 4 Sep 2013 16:18:30 +0000

I would tend to agree with Christian, requirements should be about the overall problem to solve. Plus a control plane tends to control... the data plane! So better work on requirements which would be consistent enough to acknowledge such relationship.

Now, I also agree with Ron that a control plane may not be required in all cases. This should probably be a requirement, actually, to not mandate a control plane in all cases! 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, September 04, 2013 12:04 PM
To: Jim Guichard (jguichar); Ron Parker; Jerome Moisand
Cc: [email-masked]; Thomas Nadeau; Linda Dunbar; [email-masked]; Thomas Narten; Stewart Bryant (stbryant)
Subject: RE: [nsc] NSC BoF Outcomes

Hi*,

Cheers,

Christian.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Jim Guichard (jguichar) Envoyé : mercredi 4 septembre 2013 17:57 À : Ron Parker; Jerome Moisand Cc : [email-masked]; Thomas Nadeau; Linda Dunbar; [email-masked]; Thomas Narten; Stewart Bryant (stbryant) Objet : Re: [nsc] NSC BoF Outcomes

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 4 Sep 2013 17:19:55 +0000

Let me suggest that we keep a single requirements document for now and
perhaps split into separate data and control plane documents should that
become necessary as the single document evolves.

On 9/4/13 12:18 PM, "Jerome Moisand" <[email-masked]> wrote:

>I would tend to agree with Christian, requirements should be about the
>overall problem to solve. Plus a control plane tends to control... the
>data plane! So better work on requirements which would be consistent
>enough to acknowledge such relationship.
>
>Now, I also agree with Ron that a control plane may not be required in
>all cases. This should probably be a requirement, actually, to not
>mandate a control plane in all cases!
>
>I support the publication of a single requirements document (for the sake
>of consistency), and which would include both control and data plane
>considerations among other topics.
>
>Cheers,
>
>Christian.
>
>De : [email-masked] [mailto:[email-masked]] De la part de Jim
>Guichard (jguichar) Envoyé : mercredi 4 septembre 2013 17:57 À : Ron
>Parker; Jerome Moisand Cc : [email-masked]; Thomas Nadeau; Linda Dunbar;
>[email-masked]; Thomas Narten; Stewart Bryant (stbryant) Objet : Re:
>[nsc] NSC BoF Outcomes
>
>__________________________________________________________________________
>Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>exploites ou copies sans autorisation. Si vous avez recu ce message par
>erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
>pieces jointes. Les messages electroniques etant susceptibles
>d'alteration, Orange decline toute responsabilite si ce message a ete
>altere, deforme ou falsifie. Merci.
>
>This message and its attachments may contain confidential or privileged
>information that may be protected by law; they should not be distributed,
>used or copied without authorisation.

---

From: Ron Parker <[email-masked]>
Date: Wed, 4 Sep 2013 17:34:07 +0000

Jim,

That sounds fine to me.   I wanted to emphasize the idea that control plane should not be considered mandatory to realize a network service chaining deployment, and I feel that that concept is now on the table.

Thanks.

    Ron

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Wednesday, September 04, 2013 1:20 PM
To: Jerome Moisand; [email-masked]; Ron Parker
Cc: [email-masked]; Thomas Nadeau; Linda Dunbar; [email-masked]; Thomas Narten; Stewart Bryant (stbryant)
Subject: Re: [nsc] NSC BoF Outcomes

Let me suggest that we keep a single requirements document for now and perhaps split into separate data and control plane documents should that become necessary as the single document evolves.

On 9/4/13 12:18 PM, "Jerome Moisand" <[email-masked]> wrote:

>I support the publication of a single requirements document (for the 
>sake of consistency), and which would include both control and data 
>plane considerations among other topics.
>
>Cheers,
>
>Christian.
>
>De : [email-masked] [mailto:[email-masked]] De la part de 
>Jim Guichard (jguichar) Envoyé : mercredi 4 septembre 2013 17:57 À : 
>Ron Parker; Jerome Moisand Cc : [email-masked]; Thomas Nadeau; Linda 
>Dunbar; [email-masked]; Thomas Narten; Stewart Bryant (stbryant) Objet : Re:
>[nsc] NSC BoF Outcomes
>
>requirements I-D's should be created rather than an overall 
>requirements document covering both?
>
>>that the WG be responsible for defining the requirements of the 
>>control plane with respect to service chaining. The problem here is of 
>>course that there are multiple control planes. In my mind it makes 
>>little sense to try and tackle them all but rather define what is 
>>necessary for a control plane to implement to successfully enable 
>>service chains and then liaise with other WG's on the details.
>>
>>>make something truly useful (e.g. provide a more complex Service 
>>>-with a capital 'S'- to service provider users or enterprise users). 
>>>All the use cases I've heard so far from various parties do mix edge 
>>>routers, security and application-oriented elements.
>>>
>>>>example, if the service is DPI analysis, then a detected protocol 
>>>>may cause the subsequent packets to be policy routed on a path 
>>>>different than the SPF path.
>>>> 
>>>>   Ron
>>>> 
>>>> 
>>>>links. Their topology is more like a meshed graph than chain. So 
>>>>when you chain Router-1<->Router-2<->Router-3, are you talking about 
>>>>>> Are you saying that the NSC scope includes chaining Layer 2, 
>>>>>> Layer
>>>>>> 3
>>>>>>>> Today, there are many services offered by operators, e.g. 
>>>>>>>> L2VPN, L3VPN, P2P paths, etc. So you can interpret NSC as 
>>>>>>>> chaining
>>>>>>>> L2/L3
>_______________________________________________________________________
>___ _______________________________________________
>
>erreur, veuillez le signaler a l'expediteur et le detruire ainsi que 
>les pieces jointes. Les messages electroniques etant susceptibles 
>information that may be protected by law; they should not be 
>distributed, used or copied without authorisation.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 4 Sep 2013 17:38:27 +0000

Agreed Ron. Also, personally I think we will find that the number of
requirements for both data and control planes will necessitate the need
for two separate documents but I am happy to wait for the jury on that one
;-)

On 9/4/13 1:34 PM, "Ron Parker" <[email-masked]> wrote:

>Jim,
>
>That sounds fine to me.   I wanted to emphasize the idea that control
>plane should not be considered mandatory to realize a network service
>chaining deployment, and I feel that that concept is now on the table.
>
>Thanks.
>
>    Ron
>
>

---

From: Ken Gray <[email-masked]>
Date: Wed, 4 Sep 2013 18:04:26 +0000

In line ...

On 9/4/13 12:17 PM, "Linda Dunbar" <[email-masked]> wrote:

>[Linda] Do you call this "DPI" function that re-direct data frames to a
>different target (that is not the Destination of the data frame) "Layer
>3" service?
>When those "DPI" functions re-direct traffic, do they add another
>Destination address to the data frames (i.e. create a tunnel)? Or do they
>not touch the destination addresses in the existing data frames and
>expect all the nodes along the way to know how to forward the data frames?

<ken> I fail to see the point of the question.

> 
>
>
>Bottom line, those services need to be distinguished from  traditional
>Layer 3 services, and be distinguished from routers/switches that
>dynamically establish topology, establish routes, and restoration paths.

<ken> Disagree.  Bump-in-the-wire - to me, that's what this ALL is ...you
are making a distinction that is very temporary and (IMO) unnecessary.
What you describe as something "dynamically establish topology" is
morphing (heck, with the help of I2RS - sooner rather than later) to some
different definition of dynamic than we have today.  Bump-in-wire.

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 4 Sep 2013 18:50:39 +0000

Ken, 

You brought up a very good point, about I2RS. 

I see I2RS as a mechanism to chain L3 service modules. If NSC also covers the L3 service function chaining, are the use cases similar to I2RS' use cases? Or different? 

Linda

> From: Ken Gray [mailto:[email-masked]]
> Sent: Wednesday, September 04, 2013 1:04 PM
> To: Linda Dunbar; Ron Parker; Thomas Nadeau
> [email-masked]; Thomas Narten
> example,
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> >> Linda Dunbar
> apply
> packets,
> S1-
> when
> source
> L2VPN,
> etc.);

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 4 Sep 2013 15:44:59 -0400

I like this idea. Its practical and satisfies the desire to have detailed requirements. 

On Sep 4, 2013:1:19 PM, at 1:19 PM, "Jim Guichard (jguichar)" <[email-masked]> wrote:

>>>>> Of Linda Dunbar

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 4 Sep 2013 15:53:33 -0400

I2RS is not chartered to do service-chaining explicitly, especially any data plane changes that might be needed; its chartered to do fast programmability and topology.

	--Tom

---

From: Ken Gray <[email-masked]>
Date: Wed, 4 Sep 2013 22:46:04 +0000

To add - and that programmability can be policy driven thereby eliminating
a lot of the superficial distinctions being made based on the present-day
behaviors of service devices like DPI engines and routers/switches -
solely because the latter learn and program their forwarding "dynamically"
and the former by the hand of a policy engine. =8^)

On 9/4/13 3:53 PM, "Thomas Nadeau" <[email-masked]> wrote:

>
>	I2RS is not chartered to do service-chaining explicitly, especially any
>data plane changes that might be needed; its chartered to do fast
>programmability and topology.
>
>	--Tom
>
>> Ken, 
>> 
>> I see I2RS as a mechanism to chain L3 service modules. If NSC also
>>covers the L3 service function chaining, are the use cases similar to
>>I2RS' use cases? Or different?
>> 
>> Linda
>> 
>> 
>>

---

From: Ken Gray <[email-masked]>
Date: Wed, 4 Sep 2013 18:37:21 +0000

This gets back around to REQ#30 in the requirements already published.