Subject: [nsc] Progress toward WG formation

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 26 Nov 2013 21:27:19 -0000

Hi SFC list (still pretending to be NSC),

Jim and Thomas have collated the discussion on a proposed WG charter and I have
updated this at https://datatracker.ietf.org/doc/charter-ietf-sfc/

I have still two tasks:
1. Read the mailing list to make sure they have captured consensus
2. Read the charter to make sure I support it.

You can help me by commenting (on the list is preferred) about any deficiencies
in the charter text or proposed milestones.

My plan is to put the charter before the IESG on Thursday December 5th, and if
all goes well it should go out for IESG and external review before coming to the
IESG again for final approval on the 19th. Just be aware that snafus are
"normal".

As soon as we know the WG is forming, I will get the Secretariat to migrate the
list to [email-masked]. They're pretty good at that and you should feel no pain
(mostly).

Thanks,
Adrian

---

From: Lucy yong <[email-masked]>
Date: Tue, 26 Nov 2013 22:14:50 +0000

Text:
An SFC is instantiated through selection of specific service function instances and the network nodes on which they are provided, thereby forming a service graph: this is called a Service Function Path (SFP). -end

Does it mean to say this?

A SFC is instantiated through selection of specific service function instances and/or the network nodes on which they are provided, thereby forming a service graph: this is called a Service Function Path (SFP).

"and/or" means different from "and".

Text in Generic SFC Encapsulation:
a single service-level data plane encapsulation format for conveying the service function chain and the service function path, and for communicating context information between nodes that implement service functions and service function chains. -end

Do these nested "and" means that the data plane encapsulation format has to have the fields for all of these? I thought that only service function chain is mandated in data plane; other two are optional in data plane because some solutions may want to convey them via other mechanism such as control plane, is that right? If the text does not imply that the last two have to be present, then I am fine with it.

Lucy

-----Original Message-----
From: nsc [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Tuesday, November 26, 2013 3:27 PM
To: [email-masked]
Subject: [nsc] Progress toward WG formation

Jim and Thomas have collated the discussion on a proposed WG charter and I have updated this at https://datatracker.ietf.org/doc/charter-ietf-sfc/

I have still two tasks:
1. Read the mailing list to make sure they have captured consensus 2. Read the charter to make sure I support it.

You can help me by commenting (on the list is preferred) about any deficiencies in the charter text or proposed milestones.

My plan is to put the charter before the IESG on Thursday December 5th, and if all goes well it should go out for IESG and external review before coming to the IESG again for final approval on the 19th. Just be aware that snafus are "normal".

As soon as we know the WG is forming, I will get the Secretariat to migrate the list to [email-masked]. They're pretty good at that and you should feel no pain (mostly).

Thanks,
Adrian

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

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 26 Nov 2013 17:46:19 -0500

Hi all,

  This may be a nit, but wrt the encapsulation spec:

  "It is intended that
   the encapsulation be agnostic to the layer at which it is applied and
   the service that is being constructed. That is, the same 
   encapsulation may be used on a service function path realized at the 
   network layer or at any other layer, and the same encapsulation will
   apply for the construction of service function paths regardless of
   the actual service."

  The first sentance says "layer at which it is applied".  That implies
  to me that the encapsulation header can be applied at different layers?
  Is that really the intent?  To have encapsulation happen at different
  layers for different legs of the service path? 

  From the second sentance, it seems like what we really want to say is
  "layer from which it is applied" (i.e., application layer service vs.
  L2 service that provides the information necessary for encapsulation)?

  This then goes back to my previous questions related to cross-layer
  signalling of encapsulation information.  Is the discussion of such
  requirements and/or mechanisms (API)s in or out of scope?  Note: As
  previously stated, I dont believe this to be a control plane issue.

thanx.

--  Kevin J. Ma

> Sent: Tuesday, November 26, 2013 4:27 PM
> To: [email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 26 Nov 2013 22:53:13 -0000

Hi Lucy,

I think you may be trying to be a lawyer here.

> Text:
> An SFC is instantiated through selection of specific service function
instances and
> the network nodes on which they are provided, thereby forming a service graph:
> this is called a Service Function Path (SFP). -end
> 
> A SFC is instantiated through selection of specific service function instances
> and/or the network nodes on which they are provided, thereby forming a service
> graph: this is called a Service Function Path (SFP).
> 

If I select a specific service function instance I have presumably selected the
node on which it is provided.
So I guess you are suggesting that we might want to select a node for the path,
but not worry about which instance of the service on that node is used.

Of course, if we read selection of specific service function instances [NB
plural] then we note that selection of a node could encompass all of the
instances on that node.

If you feel strongly about this we could change "and" to "and/or" but frankly I
think it is all the same thing.

> a single service-level data plane encapsulation format for conveying the
service
> function chain and the service function path, and for communicating context
> information between nodes that implement service functions and service
> function chains. -end
> 
> Do these nested "and" means that the data plane encapsulation format has to
> have the fields for all of these? I thought that only service function chain
is
> mandated in data plane; other two are optional in data plane because some
> solutions may want to convey them via other mechanism such as control plane,
is
> that right? If the text does not imply that the last two have to be present,
then I
> am fine with it.

What does "has to have" mean?
You have four seats in your car - do you always carry four people?
However, the design spec of the car allows you to carry four people if that is
the choice of the day.

Thus, the service-level encapsulation has some purposes: 
- it is for conveying:
   - the service function chain
   - the service function path
- it is for communicating context information

When designing the encapsulation you must design for all of these.

When using the encapsulation, you only use what you need.

Now, it MIGHT be a reasonable design goal to make sure that the encapsulation is
optimal on the wire when only a subset of the information needs to be carried.
And you MIGHT observe that "context information" might be of varying size.  This
all sounds like solution-specific details arising from the requirements that
haven't been written/agreed yet.

Cheers,
Adrian

---

From: Thomas Narten <[email-masked]>
Date: Tue, 26 Nov 2013 17:58:56 -0500

Hi Lucy.

> An SFC is instantiated through selection of specific service
> function instances and the network nodes on which they are provided,
> thereby forming a service graph: this is called a Service Function
> Path (SFP). -end

> A SFC is instantiated through selection of specific service function
> instances and/or the network nodes on which they are provided,
> thereby forming a service graph: this is called a Service Function
> Path (SFP).

> "and/or" means different from "and".

To be clear, you are asking that "and" be changed to "and/or"?

Actually, better text would probably be something like:

   An SFC is instantiated through selection of specific service
   function instances on specific network nodes on which they are
   provided, thereby forming a service graph: this is called a Service
   Function Path (SFP). -end

I.e., change the "and the network nodes ..." to "on specific network
nodes..."

Would that work?

> a single service-level data plane encapsulation format for conveying
> the service function chain and the service function path, and for
> communicating context information between nodes that implement
> service functions and service function chains. -end

> Do these nested "and" means that the data plane encapsulation format
> has to have the fields for all of these? I thought that only service
> function chain is mandated in data plane; other two are optional in
> data plane because some solutions may want to convey them via other
> mechanism such as control plane, is that right?

I think the answer is both yes and no. Yes, those fields will be
needed, but there may be cases where some fields can be omitted. But
that sort of detail is for the WG to decide later. E.g., even if the
fields aren't needed it may be simpler just to always have them to
keep the header size constant in all packets. But in no way should the
wording in the charter be taken to mean that this sort of (detailed)
decision has already been made. These sorts of details need to be
worked out in the WG.

> If the text does not imply that the last two have to be present,
> then I am fine with it.

I do not believe the charter text implies that.

Thomas (with concurrence from Jim)

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 26 Nov 2013 21:28:56 -0500

just to clarify, as an example, do we expect to be able to:
- use L2 encapsulation to get from the classifier to the firewall
- use L4 encapsulation to get from the firewall to the TLS offload
- use L5 encapsulation to get from the TLS offload to the load balancer
- use L3 encapsulation to get from the load balancer to AV scanner
etc., for a chain that starts out FW -> TLS -> LB -> AV -> ...
(with all the necessary re-classification steps in between)?

> From: Kevin J Ma
> Sent: Tuesday, November 26, 2013 5:46 PM
> To: [email-masked]'; [email-masked]
> Subject: RE: [nsc] Progress toward WG formation
> 
> Hi all,
> 
> > Jim and Thomas have collated the discussion on a proposed WG charter and
> I
> > have
> > all goes well it should go out for IESG and external review before
> coming
> > to the

---

From: Lucy yong <[email-masked]>
Date: Wed, 27 Nov 2013 02:59:41 +0000

Hi Adrian,

I think you may be trying to be a lawyer here.
[Lucy] never thought about it; not my intention at all. :) 

instances and
> instances and/or the network nodes on which they are provided, thereby 
> forming a service

If I select a specific service function instance I have presumably selected the node on which it is provided.
So I guess you are suggesting that we might want to select a node for the path, but not worry about which instance of the service on that node is used.

Of course, if we read selection of specific service function instances [NB plural] then we note that selection of a node could encompass all of the instances on that node.

If you feel strongly about this we could change "and" to "and/or" but frankly I think it is all the same thing.
[Lucy] The sentence confuses me on whether the service function path (SFP) for a SFC will be presented as a list of service function instances, or both a list of service function instances and the network nodes on which they are provided, or ... I don't have strong feeling, just want to get a bit more clear on it. 

> the
service
> function chain and the service function path, and for communicating 
> context information between nodes that implement service functions and 
> service function chains. -end
> 
> function chain
is
> mandated in data plane; other two are optional in data plane because 
> some solutions may want to convey them via other mechanism such as 
> control plane,
is
then I

What does "has to have" mean?
[Lucy] means "always presence, not optional".
You have four seats in your car - do you always carry four people?
However, the design spec of the car allows you to carry four people if that is the choice of the day.
[Lucy] I don't think that this is a good example to use here. If we use car as example, my point would be if the last two are as the ceiling window or the seat of car. One is optional, another is included in all models. 

When using the encapsulation, you only use what you need.
[Lucy] This is what I want to hear. Thank you for the clarification.

Now, it MIGHT be a reasonable design goal to make sure that the encapsulation is optimal on the wire when only a subset of the information needs to be carried.
And you MIGHT observe that "context information" might be of varying size.  This all sounds like solution-specific details arising from the requirements that haven't been written/agreed yet.
[Lucy] Sorry, IMO: my point is not solution-specific. 

Regards,
Lucy

Lucy

Cheers,
Adrian

---

From: Lucy yong <[email-masked]>
Date: Wed, 27 Nov 2013 03:14:00 +0000

Hi Thomas,

Please see inline below.

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Tuesday, November 26, 2013 4:59 PM
To: Lucy yong
Cc: [email-masked]; [email-masked]
Subject: Re: [nsc] Clarification RE: Progress toward WG formation

Hi Lucy.

> instances and the network nodes on which they are provided, thereby 
> forming a service graph: this is called a Service Function Path (SFP). 
> -end

> forming a service graph: this is called a Service Function Path (SFP).

I.e., change the "and the network nodes ..." to "on specific network nodes..."

Would that work?
[Lucy] This is better. The point is what is used to form the service graph, service function instances, nodes, or both. If you think that should be discussed in the solution development, I am fine with the text. BTW, why use "An SFC"?

> communicating context information between nodes that implement service 
> functions and service function chains. -end

> mechanism such as control plane, is that right?

I think the answer is both yes and no. Yes, those fields will be needed, but there may be cases where some fields can be omitted. But that sort of detail is for the WG to decide later. E.g., even if the fields aren't needed it may be simpler just to always have them to keep the header size constant in all packets. But in no way should the wording in the charter be taken to mean that this sort of (detailed) decision has already been made. These sorts of details need to be worked out in the WG.
[Lucy] Good. I am fine with this approach.

Regards,
Lucy

> If the text does not imply that the last two have to be present, then 
> I am fine with it.

---

From: "Hongyu Li (Julio)" <[email-masked]>
Date: Wed, 27 Nov 2013 03:42:46 +0000

Actually, I have a similar question. Solution address by SFC WG (when it comes into reality) should be applicable to both physical nodes and virtual instance, or even a mix of the two. In other words, an "instance" may resides in a network node, or in a server, where may contains multiple instances. Having that said, to cover all cases, I'd suggest following text:

   An SFC is instantiated through selection of specific service function instances, thereby forming a service graph: this is called a Service Function Path (SFP). -end

Removing "on specific network nodes on which they are provided".

Would this be OK?

Cheers,
Hongyu

-----Original Message-----
From: nsc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Wednesday, November 27, 2013 11:14 AM
To: Thomas Narten
Cc: [email-masked]; [email-masked]
Subject: Re: [nsc] Clarification RE: Progress toward WG formation

Hi Thomas,

Please see inline below.

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: Tuesday, November 26, 2013 4:59 PM
To: Lucy yong
Cc: [email-masked]; [email-masked]
Subject: Re: [nsc] Clarification RE: Progress toward WG formation

Hi Lucy.

Would that work?

Regards,
Lucy

---

From: Melinda Shore <[email-masked]>
Date: Tue, 26 Nov 2013 19:11:53 -0900

> (with all the necessary re-classification steps in between)?

No.  I'm also not sure what you mean by "reclassification"
in this context.  I don't see this mechanism as being significantly
different from how everything from network stacks to filesystems
are implemented - they have a demultiplexing element in the
messages.  What you're suggesting sounds unfortunately and
unnecessarily complicated.

Melinda

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Wed, 27 Nov 2013 04:12:11 +0000

+-----------+-----------+---------+
| Transport | SFC-Encap | Payload |
+-----------+-----------+---------+

It means SFC-Encap being independent of the Transport/Payload and the
overall service.
In your example, you could have L2/3/4/5 (or a mix of the same) for
transport, as dictated by the implementation. You may find some discussion
around this in the NSC archive.

Surendra.

On 11/26/13 6:28 PM, "Kevin J Ma" <[email-masked]> wrote:

>> > My plan is to put the charter before the IESG on Thursday December
>>5th,
>> > and if
>> > list to [email-masked]. They're pretty good at that and you should feel
>>no
>> > pain
>> > (mostly).
>> >
>> > Thanks,
>> > Adrian
>> >

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 26 Nov 2013 23:32:08 -0500

Hi Melinda,

> What you're suggesting sounds unfortunately and

I'm not suggesting anything.  I'm trying to understand what the charter says.

>   L2 service that provides the information necessary for encapsulation)?

The wording is not clear to me whether it means the encapsulation is at any
layer, or if the encapsulation is at a single layer, and it is the service
that can be at any layer, which influences encapsulation at a single layer.

thanx.

--  Kevin J. Ma

> From: nsc [mailto:[email-masked]] On Behalf Of Melinda Shore
> Sent: Tuesday, November 26, 2013 11:12 PM
> To: [email-masked]
> Subject: Re: [nsc] Progress toward WG formation
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 26 Nov 2013 23:40:02 -0500

The way I read the "agnostic" is that one transport might be MPLS, while 
another might be VxLAN, and a third might be IP-in-IP.  However, they 
both carry the same common header so that logic which needs to extract 
metadata or other related operations is always working with the same 
constructs.

Yours,
Joel

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Wed, 27 Nov 2013 04:44:58 +0000

Irrespective of the no of virtual layers, you need a physical node and
that being on a network is conveyed by "network node". I would think this
whole effort is moot if either one is excluded.

Surendra.

On 11/26/13 7:42 PM, "Hongyu Li (Julio)" <[email-masked]> wrote:

>Actually, I have a similar question. Solution address by SFC WG (when it
>comes into reality) should be applicable to both physical nodes and
>virtual instance, or even a mix of the two. In other words, an "instance"
>may resides in a network node, or in a server, where may contains
>multiple instances. Having that said, to cover all cases, I'd suggest
>following text:
>
>
>instances, thereby forming a service graph: this is called a Service
>[Lucy] This is better. The point is what is used to form the service
>graph, service function instances, nodes, or both. If you think that
>should be discussed in the solution development, I am fine with the text.
>BTW, why use "An SFC"?
>
>I think the answer is both yes and no. Yes, those fields will be needed,
>but there may be cases where some fields can be omitted. But that sort of
>detail is for the WG to decide later. E.g., even if the fields aren't
>needed it may be simpler just to always have them to keep the header size
>constant in all packets. But in no way should the wording in the charter
>be taken to mean that this sort of (detailed) decision has already been
>made. These sorts of details need to be worked out in the WG.

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 26 Nov 2013 23:48:09 -0500

Hi Surendra,

  I have some questions about how that would work, but if that is the goal,
  thank you for the clarification.

--  Kevin J. Ma

> From: Surendra Kumar (smkumar) [mailto:[email-masked]]
> To: Kevin J Ma; [email-masked]; [email-masked]

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 27 Nov 2013 00:08:25 -0500

Hi Joel,

  I read "encapsulation" as the act of encapsulating, and therefore
  also the act of decapsulating, not as the header itself.

  It's not immediately clear to me how this could be made "agnostic".
  The entity that decap's the lower layer needs some way to know that
  the next layer up is an SFC encap, and that seems like it would be
  lower-layer-protocol-specific?  I can see making the parsing of the
  encap header: "agnostic", but not the recognition of the encap?

thanx.

--  Kevin J. Ma

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Tuesday, November 26, 2013 11:40 PM
> To: Kevin J Ma; Melinda Shore; [email-masked]

---

From: "Hongyu Li (Julio)" <[email-masked]>
Date: Wed, 27 Nov 2013 08:48:40 +0000

I am afraid "network node" doesn't include a server in a DC, where virtual SFs are running. That's why I proposed to remove "network node" in case we don’t add "server" explicitly here and add more complexity.

Hongyu

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]] 
Sent: Wednesday, November 27, 2013 12:45 PM
To: Hongyu Li (Julio); Lucy yong; Thomas Narten
Cc: [email-masked]; [email-masked]
Subject: Re: [nsc] Clarification RE: Progress toward WG formation

Irrespective of the no of virtual layers, you need a physical node and that being on a network is conveyed by "network node". I would think this whole effort is moot if either one is excluded.

Surendra.

On 11/26/13 7:42 PM, "Hongyu Li (Julio)" <[email-masked]> wrote:

>Actually, I have a similar question. Solution address by SFC WG (when 
>it comes into reality) should be applicable to both physical nodes and 
>function instances, thereby forming a service graph: this is called a 
>Service Function Path (SFP). -end
>
>> thereby forming a service graph: this is called a Service Function Path (SFP).
>
>fields aren't needed it may be simpler just to always have them to keep 
>the header size constant in all packets. But in no way should the 
>decision has already been made. These sorts of details need to be worked out in the WG.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 27 Nov 2013 13:08:05 +0000

Hi Kevin,

The lower layer encapsulation (e.g. the "transport") needs some way of
indicating that an SFC encapsulation follows. This will be addressed as
part of the SFC encapsulation work item.

On 11/27/13 12:08 AM, "Kevin J Ma" <[email-masked]> wrote:

>> > I'm not suggesting anything.  I'm trying to understand what the
>>charter
>> says.
>> >
>> > The wording is not clear to me whether it means the encapsulation is
>>at
>> any

---

From: Lucy yong <[email-masked]>
Date: Wed, 27 Nov 2013 14:12:54 +0000

Agree with Jim. 

-----Original Message-----
From: nsc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, November 27, 2013 7:08 AM
To: Kevin J Ma; Joel M. Halpern; Melinda Shore; [email-masked]
Subject: Re: [nsc] Progress toward WG formation

Hi Kevin,

The lower layer encapsulation (e.g. the "transport") needs some way of indicating that an SFC encapsulation follows. This will be addressed as part of the SFC encapsulation work item.

On 11/27/13 12:08 AM, "Kevin J Ma" <[email-masked]> wrote:

>> The way I read the "agnostic" is that one transport might be MPLS, 
>> while another might be VxLAN, and a third might be IP-in-IP.  
>> However, they both carry the same common header so that logic which 
>> needs to extract metadata or other related operations is always 
>> working with the same constructs.
>> 
>> Yours,
>> Joel
>> 
>> >> What you're suggesting sounds unfortunately and unnecessarily 
>> >> complicated.
>> >
>> >>     the encapsulation be agnostic to the layer at which it is 
>> >> applied
>> and
>> >>     encapsulation may be used on a service function path realized 
>> >> at
>> the
>> >>     network layer or at any other layer, and the same 
>> >> encapsulation
>> will
>> >>     apply for the construction of service function paths 
>> >> regardless
>>of
>> >>     the actual service."
>> >>
>> >>    From the second sentance, it seems like what we really want to 
>> >> say
>> is
>> >>    "layer from which it is applied" (i.e., application layer 
>> >> service
>> vs.
>> > that can be at any layer, which influences encapsulation at a 
>> > single
>> layer.
>> >
>> > thanx.
>> >
>> > --  Kevin J. Ma
>> >
>> >>> - use L3 encapsulation to get from the load balancer to AV 
>> >>> scanner etc., for a chain that starts out FW -> TLS -> LB -> AV -> ...
>> >> in this context.  I don't see this mechanism as being 
>> >> significantly different from how everything from network stacks to 
>> >> filesystems are implemented - they have a demultiplexing element 
>> >> in the messages.  What you're suggesting sounds unfortunately and

---

From: Ron Parker <[email-masked]>
Date: Wed, 27 Nov 2013 14:19:15 +0000

We said in Vancouver that service function chaining applies equally to purely traditional physical deployments, purely virtualized deployments, or any mix of the two.   

In email exchanges, we've also said that service functions are logical entities, independent of physical or virtual.   That is, more than one can be located at the same IP address.

SDN provides a useful abstraction that I think we can apply to SFC.   SDN differentiates between the "overlay" and the "underlay".   The "overlay" is where the applications reside -- they see IP addresses that may not correspond to the network topology.   The "underlay" is the toplogically significant network (i.e., some collection of physical or virtual switches and routers). 

If we view the service functions as similar to the applications in an SDN network (this is a loose analogy and I'm not implying anything about which ISO layers the service function operates at), then we can say the service functions and therefore the SFC operate in the overlay.   Whether there is or is not an underlay and what form it takes is therefore hidden from the operation of the SFC.   

This would allow us to discuss chains of service functions where the service functions are logical entities that are then located within a network using network addresses (e.g., IP, Ethernet).   Whether that network sat on top of some underlay becomes irrelevant.

   Ron

-----Original Message-----
From: nsc [mailto:[email-masked]] On Behalf Of Hongyu Li (Julio)
Sent: Wednesday, November 27, 2013 3:49 AM
To: Surendra Kumar (smkumar); Lucy yong; Thomas Narten
Cc: [email-masked]; [email-masked]
Subject: Re: [nsc] Clarification RE: Progress toward WG formation

Hongyu

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]] 
Sent: Wednesday, November 27, 2013 12:45 PM
To: Hongyu Li (Julio); Lucy yong; Thomas Narten
Cc: [email-masked]; [email-masked]
Subject: Re: [nsc] Clarification RE: Progress toward WG formation

Surendra.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 27 Nov 2013 16:02:35 +0000

Hi Kevin,

I think that you make a valid point and the wording in the current charter is perhaps misleading (or at least difficult to parse). The key point to pull from this is that the SFC encapsulation could be processed by an SF running at the network layer or any higher layer. I think this is easily fixed by an adjustment to the wording of work item #3. I would like to suggest the following text to replace the existing text (changes in bold):

"It is intended that the encapsulation be agnostic to the layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function chain applied at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service".

If there are no objections to this wording I can track the change.

On 11/26/13 5:46 PM, "Kevin J Ma" <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

  "It is intended that

thanx.

--  Kevin J. Ma

-----Original Message-----
From: nsc [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Tuesday, November 26, 2013 4:27 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [nsc] Progress toward WG formation
Hi SFC list (still pretending to be NSC),
Jim and Thomas have collated the discussion on a proposed WG charter and I
have
updated this at https://datatracker.ietf.org/doc/charter-ietf-sfc/
I have still two tasks:
1. Read the mailing list to make sure they have captured consensus
2. Read the charter to make sure I support it.
You can help me by commenting (on the list is preferred) about any
deficiencies
in the charter text or proposed milestones.
My plan is to put the charter before the IESG on Thursday December 5th,
and if
all goes well it should go out for IESG and external review before coming
to the
IESG again for final approval on the 19th. Just be aware that snafus are
"normal".
As soon as we know the WG is forming, I will get the Secretariat to
migrate the
list to [email-masked]<mailto:[email-masked]>. They're pretty good at that and you should feel no
pain
(mostly).
Thanks,
Adrian
_______________________________________________
nsc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nsc
_______________________________________________
nsc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nsc

---

From: Ron Parker <[email-masked]>
Date: Wed, 27 Nov 2013 16:07:06 +0000

Jim,

Your proposed change sounds good to me.

   Ron

From: nsc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, November 27, 2013 11:03 AM
To: Kevin J Ma; [email-masked]; [email-masked]
Subject: Re: [nsc] Progress toward WG formation

Hi Kevin,

Hi all,

  "It is intended that

thanx.

--  Kevin J. Ma

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 27 Nov 2013 11:11:19 -0500

Hi Jim,

  I agree.  I assume that the WG would probably adopt additional items
  to, e.g., specify how to recognize SFC encap from individual lower
  level protocols, rather than try to combine an exhaustive list with
  the definition of the encapsulation format?

  I still have a question as to whether or not cross-layer signaling
  is in scope or not?

  Getting back to the charter, I took a shot at clarifying the text
  for the encapsulation deliverable, based on what I've gathered from
  this thread.  Please see if my understanding is correct:

  "Generic SFC Encapsulation: This document will describe a single 
   service-level data plane encapsulation format for conveying the
   service function chain and the service function path, and for 
   communicating context information between nodes that implement 
   service functions and service function chains. It is intended that
   the encapsulation format be agnostic to the layer at which it is
   applied and that a service that is being constructed may indicate
   the need for encapsulation from any layer at or above the layer at
   which the encapsulation is requested to be applied for each leg of
   the service path."

thanx.

--  Kevin J. Ma

> From: Jim Guichard (jguichar) [mailto:[email-masked]]
> Sent: Wednesday, November 27, 2013 8:08 AM
> while

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 27 Nov 2013 11:19:01 -0500

Hi Jim,

  I actually just sent some other text in response to your other email.  ;)
  I think the change helps to clarify, but please see my other response.

thanx.

--  Kevin J. Ma

Hi Kevin,

Hi all,

  "It is intended that

thanx.

--  Kevin J. Ma

---

From: Melinda Shore <[email-masked]>
Date: Wed, 27 Nov 2013 07:59:17 -0900

On 11/27/13 7:02 AM, Jim Guichard (jguichar) wrote:
> I think that you make a valid point and the wording in the current
> charter is perhaps misleading (or at least difficult to parse). The key
> point to pull from this is that the SFC encapsulation could be processed
> by an SF running at the network layer or any higher layer.

I think I see the source of the confusion.  I think it's not so much
that it's "running at" a given layer but that it's treating traffic
at a given layer.  I don't think the original language was at all
unclear but maybe that's just me.  I do think the "running at" language
is both more confusing and confused than "layer at which it is applied."

Melinda

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 27 Nov 2013 17:05:09 +0000

Hi Melinda,

On 11/27/13 11:59 AM, "Melinda Shore" <[email-masked]> wrote:

>at a given layer. 

Jim> yes precisely, but you knew what I meant ;-)

> I don't think the original language was at all

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 27 Nov 2013 13:06:56 -0500

My current understanding is that:

a) the service can be at any layer.
b) the encapsulation can be at any layer.
c) the encapsulation may be at a different (lower) layer than the service
d) the service may be at a different layer on each leg of the chain
e) the encapsulation may be at a different layer on each leg of the path
f) the signaling from service layer to encapsulation layer is out-of-scope

The encapsulation layer and the service layer are independent, and only
related by c) above, with the caveat of f) above?

If I reread the charter with these in mind, then I can see these as being
a valid interpretation of: layer and service agnostic.  However, I still
find the last sentance confusing as I interpret it to preclude e) above.
Is this sentance needed at all?  Perhaps it can just be removed?
 
  "That is, the same 

I would also change the prior sentance:

  "It is intended that
   the encapsulation be agnostic to the layer at which it is applied and
   the service that is being constructed."

adding the word "format" to be consistent with the first sentance:

  "It is intended that
   the encapsulation format be agnostic to the layer at which it is applied and
   the service that is being constructed."

or see the alternate text in my other email.

thanx.

--  Kevin J. Ma

> Sent: Wednesday, November 27, 2013 12:05 PM
> To: Melinda Shore; [email-masked]

---

From: Melinda Shore <[email-masked]>
Date: Wed, 27 Nov 2013 09:17:36 -0900

> Jim> yes precisely, but you knew what I meant ;-)

I did.  I think if it were just me I'd drop any discussion of layering
here as I don't think it's particularly helpful and I don't think it
changes anything.  On the other hand if enough people are confused,
that's a problem, but on a third hand I think that if people are
confused about this particular scenario then they're probably
confused about layering more generally and I'm not sure it's nsc's
job to fix that.  (And I'll note that there seems to be a lot more
confusion about network layering than there used to be).

I'm wondering if there are other people who feel as if it's
helpful to provide clarifying text around this.

Melinda

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 27 Nov 2013 14:07:52 -0500

> I think that if people are
> job to fix that. 

If anyone was confused by my question, it has consistently been about
the distinction between the layer at which the encapsulation occurs
and the layer at which the service is operating, and the signaling
between the two, should they be different [1].

In addition, I asked if the layer at which encapsulation could
occur for a given service path could change on each leg of the 
service path, which I believe Surendra confirmed [2].

Though I appreciate the concern for my possible general confusedness.

--  Kevin J. Ma

[1] http://www.ietf.org/mail-archive/web/nsc/current/msg00756.html

[2] http://www.ietf.org/mail-archive/web/nsc/current/msg00770.html

> Sent: Wednesday, November 27, 2013 1:18 PM
> To: Jim Guichard (jguichar)
> Cc: [email-masked]

---

From: Melinda Shore <[email-masked]>
Date: Wed, 27 Nov 2013 10:34:00 -0900

> between the two, should they be different [1].

Right, and I don't understand why this is a question.
Aside from there not really being any sort of issue there,
I think, I've been a bit concerned that being legalistic
about layering has tended to lead to more confusion rather
than less, and to more complicated protocols that are
difficult to implement and deploy.

When it comes right down to it, this could be done as
a RESTful protocol, a radio/PHY protocol, and anything
in-between.  You could write the messages down on
paper and carry them to some guy who'll manually
configure a device, if it came down to it.  Thinking
about layers is a lot less useful than thinking about
the transport (in its general sense, for heaven's sake)
characteristics that you need to support the service
whose messages you're carrying.

It wasn't *that* long ago that it was a matter of faith
that the IP stack doesn't have seven layers, etc.  Not
sure what happened but I think it's tended to lead to
discussions like we're having here and that have taken
place in nvo3.  That is to say, a bunch of ratholing and
unnecessary complexity.  I don't think a discussion of
layering in the nsc charter is clarifying or helps
frame scope issues, although I'll grant that saying that
nsc may be used to provision/manage/etc. services operating
at any layer in the IP stack may help stave off confusion
on the part of those who tend to ask that question in the
first place.  It seems tautological to me but I may be
alone in that.

Melinda

Melinda

---

From: Ron Parker <[email-masked]>
Date: Wed, 27 Nov 2013 19:47:30 +0000

Hi, Kevin. 

I'm not entirely clear on "the layer that the encapsulation occurs".  Are you thinking of this from an ISO 7 layer perspective or from a modular implementation perspective?   Perhaps, naively, I've always envisioned the sfc service header inserted before the original/modified/manufactured IP datagram that the layer 3 and above service function operates on.   And a transport encapsulation of some sort is inserted before the sfc service header.     

Although I haven't spent much time thinking about it, I suppose this could be extended to insertion of the SFC header in front of an original/modified/manufactured MAC frame that a layer 2 and above service function operates on.   And then the obligatory transport encapsulation in front of the inserted SFC header.  

Is this consistent with your layering concepts?

   Ron

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 27 Nov 2013 14:48:03 -0500

Hi Melinda,

  I agree that the layer discussion in the charter may be unnecessary.

  The original discussion stemmed from concerns that the initial set
  of documents only considered lower layer encapsulation, but did not
  consider the useability of such encapsulation by a higher layer
  service.  Defining an encapsulation format that cannot be used by
  a large number of applications would be unfortunate.  I don't feel
  that this is an unreasonable concern (though it may not be charter-
  worthy).

thanx.

--  Kevin J. Ma

> From: Melinda Shore [mailto:[email-masked]]
> Sent: Wednesday, November 27, 2013 2:34 PM
> To: Kevin J Ma
> Cc: Jim Guichard (jguichar); [email-masked]

---

From: Melinda Shore <[email-masked]>
Date: Wed, 27 Nov 2013 10:56:59 -0900

>   that this is an unreasonable concern (though it may not be charter-

Can you give an example of the sort of thing you're concerned about?
I'm having a very difficult time envisioning a "higher-layer" service
even seeing the encapsulation.

Melinda

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 27 Nov 2013 15:03:24 -0500

Hi Ron,

> Perhaps, naively, I've always envisioned the
> sfc service header inserted before the original/modified/manufactured IP
> datagram that the layer 3 and above service function operates on.

My question was partially about whether it would always be the IP datagram,
or whether it could be an ethernet frame, or a TCP payload, or whether it
might be just the HTTP entity body.

Along with that, as one who develops applications that only care about the
HTTP request, and might not have direct access to the code (layer, whatever)
responsible for encap/decap of the sfc header, how the application layer
would get access to the sfc information, if the encapsulation was not at
the same layer as the service function.

I don't really care where the sfc header is, as long as the information
is available to the service, but it was/is not clear to me yet how the
service would get that information, or if I missed something about the
intended flexibility of the encapsulation.

thanx.

--  Kevin J. Ma

> From: Ron Parker [mailto:[email-masked]]
> Sent: Wednesday, November 27, 2013 2:48 PM
> To: Kevin J Ma
> Cc: Melinda Shore; Jim Guichard (jguichar); [email-masked]
> I'm not entirely clear on "the layer that the encapsulation occurs".  Are
> you thinking of this from an ISO 7 layer perspective or from a modular
> implementation perspective?   Perhaps, naively, I've always envisioned the
> sfc service header inserted before the original/modified/manufactured IP
> datagram that the layer 3 and above service function operates on.   And a
> transport encapsulation of some sort is inserted before the sfc service
> header.
> 
> Although I haven't spent much time thinking about it, I suppose this could
> be extended to insertion of the SFC header in front of an
> original/modified/manufactured MAC frame that a layer 2 and above service
> function operates on.   And then the obligatory transport encapsulation in
> front of the inserted SFC header.
>

---

From: Ron Parker <[email-masked]>
Date: Wed, 27 Nov 2013 20:25:04 +0000

Kevin,

As has been pointed out on the thread, "layer" can and does mean multiple things.

Let's consider the protocol stackup for your example --we have L2/L3/TCP/HTTP as the thing that an HTTP-aware network element acts upon.   Depending on the internal software design of that network element, it is certainly conceivable that some internal software module acts solely on the HTTP portion.   But whether or not it has access to particulars from L2/L3/TCP is a design and implementation decision.

Now with an SFC header, we might have (I'll pick IP/UDP as my exemplary transport for the SFC encapsulated packets) -- L2/IP/UDP/SFC/L3/TCP/HTTP.   Let's also assume that the network element has been enhanced to understand this new SFC tunneling concept (whether that is in the kernel, in application space, etc., is a design and implementation decision).   Now the argument can be extended that whether that software module that looks at HTTP, only, has access to the outer IP/UDP and SFC data is a design and implementation decision.

   Ron

-----Original Message-----
From: Kevin J Ma [mailto:[email-masked]] 
Sent: Wednesday, November 27, 2013 3:03 PM
To: Ron Parker
Cc: Melinda Shore; Jim Guichard (jguichar); [email-masked]
Subject: RE: [nsc] Progress toward WG formation

Hi Ron,

> Perhaps, naively, I've always envisioned the sfc service header 
> inserted before the original/modified/manufactured IP datagram that 
> the layer 3 and above service function operates on.

My question was partially about whether it would always be the IP datagram, or whether it could be an ethernet frame, or a TCP payload, or whether it might be just the HTTP entity body.

Along with that, as one who develops applications that only care about the HTTP request, and might not have direct access to the code (layer, whatever) responsible for encap/decap of the sfc header, how the application layer would get access to the sfc information, if the encapsulation was not at the same layer as the service function.

I don't really care where the sfc header is, as long as the information is available to the service, but it was/is not clear to me yet how the service would get that information, or if I missed something about the intended flexibility of the encapsulation.

thanx.

--  Kevin J. Ma

> I'm not entirely clear on "the layer that the encapsulation occurs".  
> Are you thinking of this from an ISO 7 layer perspective or from a modular
> transport encapsulation of some sort is inserted before the sfc 
> service header.
> 
> Although I haven't spent much time thinking about it, I suppose this 
> could be extended to insertion of the SFC header in front of an 
> > If anyone was confused by my question, it has consistently been 
> > about the distinction between the layer at which the encapsulation 
> > occurs and the layer at which the service is operating, and the 
> > signaling between the two, should they be different [1].
> >
> > In addition, I asked if the layer at which encapsulation could occur 
> > for a given service path could change on each leg of the service 
> > path, which I believe Surendra confirmed [2].
> >
> >>>> I think I see the source of the confusion.  I think it's not so 
> >>>> much that it's "running at" a given layer but that it's treating 
> >>>> traffic at a given layer.
> >>>
> >> I did.  I think if it were just me I'd drop any discussion of 
> >> layering here as I don't think it's particularly helpful and I 
> >> don't think it changes anything.  On the other hand if enough 
> >> people are confused, that's a problem, but on a third hand I think 
> >> that if people are confused about this particular scenario then 
> >> they're probably confused about layering more generally and I'm not 
> >> sure it's nsc's job to fix that.  (And I'll note that there seems 
> >> to be a lot more confusion about network layering than there used to be).
> >>
> >> I'm wondering if there are other people who feel as if it's helpful 
> >> to provide clarifying text around this.
> >>
> >> Melinda
> >>

---

From: Melinda Shore <[email-masked]>
Date: Wed, 27 Nov 2013 15:02:50 -0900

> might be just the HTTP entity body.

Where I think you've wandered into the weeds is that you
appear to believe that the nsc "application" is going to
receive the entire datagram, from the Ethernet (or
whatever) frame up.  Unless someone's written something
*extremely* funky, as a rule encapsulations/headers/
etc. are not available to the services "above" them.  That's
certainly true for all modern operating systems (TCP
does not see the Ethernet frame [or the IP datagram], and
so on).

Melinda

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 27 Nov 2013 19:44:41 -0500

Hi Melinda,

> Can you give an example of the sort of thing you're concerned about?

  Sure, but this is unrelated to the charter text discussion.

  Ron and I had an offline discussion about my previous example:

  >    --> FE_TLS --> RR --> AV --> LB --> BE_TLS -->
  >               /      \          ^  \
  >              /        \        /    \
  >    ---------+          +------+      +---------->

  where it would be desirable to have a single front-end TLS termination
  paired with a single back-end TLS connection, but with the ability for
  individual application layer multiplexed objects (e.g., a particular
  HTTP entity) to follow different service paths from RR to LB (e.g.,
  not everything needs to go through AV).

  There are certainly many ways to skin this: individual connections and
  SFC paths for each object between RR and LB, or a single SFC path that
  sends everything through AV, or a completely non-SFC path between RR and
  LB.  There are also various amounts of metadata that could be shared,
  e.g., FE_TLS flow id, application object id, internal flow id, etc.

  The question was about whether or not the encapsulation is taking into
  account the fact that many of the services listed in the problem statement
  and use cases are actually application layer functions that often involve
  TCP termination and application layer message parsing, and are not themselves
  packet oriented, even though they have packet-based transport below them.

thanx.

--  Kevin J. Ma

> Sent: Wednesday, November 27, 2013 2:57 PM
> To: Kevin J Ma

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 27 Nov 2013 19:45:27 -0500

Hi Melinda,

> Unless someone's written something
> etc. are not available to the services "above" them.  

  Indeed.  That is precisely the problem.

  If I have a service that runs above that encapsulation layer,
  (e.g., an HTTP load balancer, AV Scanner, Video Optimizer, etc.)
  how does that service know what chain it's in, and how does
  it indicate to the lower encapsulation layer what chain to
  send it back out on if reclassification occurs?

--  Kevin J. Ma

> Sent: Wednesday, November 27, 2013 7:03 PM
> To: Kevin J Ma
> Cc: Ron Parker; Jim Guichard (jguichar); [email-masked]

---

From: Melinda Shore <[email-masked]>
Date: Wed, 27 Nov 2013 16:01:11 -0900

>From NSC control traffic.  It's surely not going to learn those
things from an IP header, etc.

Melinda

---

From: Ron Parker <[email-masked]>
Date: Thu, 28 Nov 2013 02:57:58 +0000

I don't think there is a strict prohibition on seeing data from lower layers.  Even in a traditional user space application implementation there is limited capability to get lower layer information via sockopt and recvmsg.  

    Ron

> On Nov 27, 2013, at 7:45 PM, "Kevin J Ma" <[email-masked]> wrote:
> 
> Hi Melinda,
>

---

From: "Diego R. Lopez" <[email-masked]>
Date: Thu, 28 Nov 2013 09:14:57 +0000

Indeed. In a typical HTTP application scenario, you have by default access to local and remote IP addresses, TCP port numbers, TLS identity parameters, and process environment variables, to name the essential ones. I think it would be reasonable to expect that a SFC module (not to use the accursed "layer": I fully agree with Melinda's previous statement on the layering confusion) would be able to expose some information on its metadata. Anyway, that should be a design decision and certainly out of scope for this group.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

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

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

________________________________

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

---

From: Kevin J Ma <[email-masked]>
Date: Thu, 28 Nov 2013 10:08:43 -0500

Hi Ron/Diego,

  Certainly there are ways to implement it, but again, my original question
  was simply: is this discussion in or out of scope?  And I think the simple
  answer was/is no.

thanx.

--  Kevin J. Ma

> From: Diego R. Lopez [mailto:[email-masked]]
> Sent: Thursday, November 28, 2013 4:15 AM
> To: Ron Parker
> Cc: Kevin J Ma; [email-masked]; Jim Guichard (jguichar); Melinda Shore
> Indeed. In a typical HTTP application scenario, you have by default access
> to local and remote IP addresses, TCP port numbers, TLS identity
> parameters, and process environment variables, to name the essential ones.
> I think it would be reasonable to expect that a SFC module (not to use the
> accursed "layer": I fully agree with Melinda's previous statement on the
> layering confusion) would be able to expose some information on its
> metadata. Anyway, that should be a design decision and certainly out of
> scope for this group.
> 
> Be goode,
> 
> > I don't think there is a strict prohibition on seeing data from lower
> layers.  Even in a traditional user space application implementation there
> is limited capability to get lower layer information via sockopt and
> recvmsg.
> >
> >    Ron
> >
> >
> >>>> or whether it could be an ethernet frame, or a TCP payload, or
> whether
> >>> it
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
> nuestra política de envío y recepción de correo electrónico en el enlace
> situado más abajo.
> This message is intended exclusively for its addressee. We only send and
> receive email on the basis of the terms set out at:

---

From: "Diego R. Lopez" <[email-masked]>
Date: Thu, 28 Nov 2013 15:21:27 +0000

Yes! I mean, I agree in that the simple answer is "no"...

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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

---

From: Ron Parker <[email-masked]>
Date: Fri, 29 Nov 2013 17:14:55 +0000

As Kevin mentioned, he and I had an offline discussion on this topic and I'd like to summarize for the group what we discussed.   

The issue at hand is whether the SFC architecture will include those service functions that operate sub-5-tuple, at the transaction level.   Take, for example, HTTP2.0 where an HTTP2.0 aware service function/classifier may choose to send some transactions on one chain and others on another.   Since these transactions were separated out from a common five-tuple, in practical terms, all of those transaction-level chains would need to return back to the original service function (which perhaps is represented as two distrinct service functions -- front-half and back half.    

Kevin's basic question is whether the SFC architecture supports this type of functionality and my view is categorically, yes.   In fact 5-tuple aware and transaction aware decision making is one of the prime advantages over existing physical or VLAN-based chaining.

Clearly, there are additional complexities to do this (i.e., what is the full encapsulation stackup for those packets that represent a subset of the original 5-tuple?).   As a group we would need to decide what, if any, of that complexity was pushed down into the SFC capability set or whether that complexity remains solely within the domain of the affected service functions (i.e., do those service functions that are chained after the HTTP2.0-aware classifier need to implicitly know that they are indeed participating in such a scenario?).

   Ron

________________________________________
From: Kevin J Ma [[email-masked]]
Sent: Thursday, November 28, 2013 10:08 AM
To: Diego R. Lopez; Ron Parker
Cc: [email-masked]; Jim Guichard (jguichar); Melinda Shore
Subject: RE: [nsc] Progress toward WG formation

Hi Ron/Diego,

thanx.

--  Kevin J. Ma

---

From: Melinda Shore <[email-masked]>
Date: Fri, 29 Nov 2013 10:15:47 -0900

On 11/29/13 8:14 AM, Ron Parker wrote:
> Kevin's basic question is whether the SFC architecture supports this
> type of functionality and my view is categorically, yes.   In fact
> 5-tuple aware and transaction aware decision making is one of the
> prime advantages over existing physical or VLAN-based chaining.

I'd think long and hard about whether you're planning on
using addresses as what might essentially be considered to
be topology descriptors or as identifiers.  As long as
there's an assumption that there can be a NAT in a service
chain you've got to accept the possibility that if you're
using addresses this way you'll be getting things wrong,
that you'll be using what's essentially a form of source
routing that can lead to tromboning, and a number of other
brokennesses.

Melinda

---

From: Ron Parker <[email-masked]>
Date: Fri, 29 Nov 2013 19:31:43 +0000

Hi, Melinda.

>From your response, I don't think I conveyed my point adequately.   I was trying to describe a service chaining scenario that could operate at the sub-5-tuple level by splitting out subflows from a 5-tuple flow for differentiated treatment and then potentially reassembling them in some service-function-specific manner.   The issue of locators (IP address or otherwise) doesn't enter into this, IMO.

   Ron

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]] 
Sent: Friday, November 29, 2013 2:16 PM
To: Ron Parker
Cc: Kevin J Ma; Diego R. Lopez; [email-masked]; Jim Guichard (jguichar)
Subject: Re: [nsc] Progress toward WG formation

> prime advantages over existing physical or VLAN-based chaining.

I'd think long and hard about whether you're planning on using addresses as what might essentially be considered to be topology descriptors or as identifiers.  As long as there's an assumption that there can be a NAT in a service chain you've got to accept the possibility that if you're using addresses this way you'll be getting things wrong, that you'll be using what's essentially a form of source routing that can lead to tromboning, and a number of other brokennesses.

Melinda

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 29 Nov 2013 19:59:31 +0000

Seems to me Ron that what you describe is essentially a pipeline where the
SFC encapsulation would need to carry enough information to successfully
reassemble the original flow on exit from the service function. As you
stated, such a service function would need an entry and exit process point
and in between specific aspects of the "overall" service function would be
applied to parts of the flow.

On 11/29/13 2:31 PM, "Ron Parker" <[email-masked]> wrote:

>Hi, Melinda.
>
>From your response, I don't think I conveyed my point adequately.   I was
>trying to describe a service chaining scenario that could operate at the
>sub-5-tuple level by splitting out subflows from a 5-tuple flow for
>differentiated treatment and then potentially reassembling them in some
>service-function-specific manner.   The issue of locators (IP address or
>otherwise) doesn't enter into this, IMO.
>
>   Ron
>
>
>I'd think long and hard about whether you're planning on using addresses
>as what might essentially be considered to be topology descriptors or as
>identifiers.  As long as there's an assumption that there can be a NAT in
>a service chain you've got to accept the possibility that if you're using
>addresses this way you'll be getting things wrong, that you'll be using
>what's essentially a form of source routing that can lead to tromboning,
>and a number of other brokennesses.
>
>Melinda

---

From: Melinda Shore <[email-masked]>
Date: Fri, 29 Nov 2013 11:10:17 -0900

On 11/29/13 10:31 AM, Ron Parker wrote:
> From your response, I don't think I conveyed my point adequately.   I
> was trying to describe a service chaining scenario that could operate
> at the sub-5-tuple level by splitting out subflows from a 5-tuple
> flow for differentiated treatment and then potentially reassembling
> them in some service-function-specific manner.   The issue of
> locators (IP address or otherwise) doesn't enter into this, IMO.

I think that if you're looking at using addresses for identifiers
only, and aren't interested in leveraging them for some sort of
understanding of topology, you're probably better off coming up
with some sort of other identifier rather than reusing addresses.
To be honest I'm not sure whether what you're discussing here
would be considered control plane or data plane, which makes
a difference.

Melinda

---

From: Ron Parker <[email-masked]>
Date: Fri, 29 Nov 2013 20:32:07 +0000

Exactly.   This is a great use of metadata -- service-function-specific tags or handles that allow this type of disassociated service processing.   In fact, there was a use case presentation in Vancouver that gave a tangentially similar example.   Some service function added a discard eligibility tag that some downstream service function would examine in its intelligent overload control processing. 

In terms of separating SFC capabilities from service function capabilities, I think we can consider for the SFC realm the connectionless or connection-oriented manner of achieving SFC tunnels, where an SFC tunnel is the composition of the SFC transport plus SFC service encapsulation (i.e., IP + UDP + SFC header).   Many service functions operate at the fully-qualified or filtered 5-tuple level.   Thus, any reliability is end-to-end and connectionless tunnels between the classifier and service functions will suffice.   If a packet is dropped between service functions, end-to-end reliability, if applicable, will cause it to be resent.   But, for service functions operating sub-fully-qualified-5-tuple, the assumption is that the "front-half" service function terminated the end-to-end 5-tuple (i.e., TCP).   This now creates the need to have reliable transport of the sub-flows between the classifier and service functions.

   Ron

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Friday, November 29, 2013 3:00 PM
To: Ron Parker; Melinda Shore
Cc: Kevin J Ma; Diego R. Lopez; [email-masked]
Subject: Re: [nsc] Progress toward WG formation

Seems to me Ron that what you describe is essentially a pipeline where the SFC encapsulation would need to carry enough information to successfully reassemble the original flow on exit from the service function. As you stated, such a service function would need an entry and exit process point and in between specific aspects of the "overall" service function would be applied to parts of the flow.

On 11/29/13 2:31 PM, "Ron Parker" <[email-masked]> wrote:

>trying to describe a service chaining scenario that could operate at 
>the sub-5-tuple level by splitting out subflows from a 5-tuple flow for 
>I'd think long and hard about whether you're planning on using 
>addresses as what might essentially be considered to be topology 
>descriptors or as identifiers.  As long as there's an assumption that 
>there can be a NAT in a service chain you've got to accept the 
>possibility that if you're using addresses this way you'll be getting 
>things wrong, that you'll be using what's essentially a form of source 
>routing that can lead to tromboning, and a number of other brokennesses.
>
>Melinda