Subject: [sfc] Framework

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Feb 2014 11:20:02 -0500

I was looking at the framework proposal.
The proposal has a very specific model of the scope of the transport 
header (that it is derived from, and relates only to, the first service 
function to which the packet will be directed.
That is clearly an operational model we need to support.

However, I would like to allow other transport operational models, such 
as the use of a VLAN to direct traffic along a chain.  Or the use of an 
MPLS label, or an MPLS label stack.

Yours,
Joel M. Halpern

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 12 Feb 2014 17:00:50 +0000

Agree with Joel's statement. 

I think a simple sentence below should be added Section 5.2 (SFC Classifier) to emphasize this point. 

	"A Service Chain Classifier node can associate a unique Layer 2 or 3 Label (e.g. VLAN, MPLS label) to the packets in the flow. Those  Layer 2 or 3 Label makes it easier for subsequent nodes along the flow path to steer the flow to the service functions specified by the flow's service chain."

Linda
-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, February 12, 2014 10:20 AM
To: [email-masked]
Subject: [sfc] Framework

I was looking at the framework proposal.
The proposal has a very specific model of the scope of the transport header (that it is derived from, and relates only to, the first service function to which the packet will be directed.
That is clearly an operational model we need to support.

However, I would like to allow other transport operational models, such as the use of a VLAN to direct traffic along a chain.  Or the use of an MPLS label, or an MPLS label stack.

Yours,
Joel M. Halpern

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

---

From: Ron Parker <[email-masked]>
Date: Wed, 12 Feb 2014 19:32:00 +0000

Linda,

My interpretation of the architecture docs is that the service function chain is built in an abstract manner (i.e., SF-A then SF-B then SF-C).    Separately, a locator table provides network location for each of those service functions.   In this way, you can locate the service functions in a manner appropriate to the type of transport you are using.   If you want that to be interface+VLAN, gateway-IP+MPLS label stack, IP address, GRE tunnel remote IP + key, etc., you can do that.    You can even potentially locate different service functions that reside in the same chain with different flavors of network locators.    Another justification to separate the identity of a service function from its network location is load balancing.   If, for example, SF-A had 3 IP addresses, that would imply load balancing to 3 instances using IP as a transport layer.

For all of those reasons, I strongly support a canonical service header that is independent of the transport methodology.    At a particular node, the decision as to where to go next should be based solely on information carried in the canonical service header and not on the fields in the transport header.   That is, the SFC node discards the transport header and extracts the chain ID from the service header.    Through mechanisms we have not yet begun to discuss, the SFC node knows how to interpret the chain ID and ultimately how to progress the packet.

    Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, February 12, 2014 12:01 PM
To: Joel M. Halpern; [email-masked]
Subject: Re: [sfc] Framework

Linda
-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, February 12, 2014 10:20 AM
To: [email-masked]
Subject: [sfc] Framework

Yours,
Joel M. Halpern

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Feb 2014 14:37:19 -0500

Ron, I think the architecture document (quinn) describes these issues in
a fashion taht is sufficiently flexible.
And I support the definition of the service header.

Some of the other individual drafts however refer to process that 
mandate transport behavior.  And do so in ways that are, in my view, too 
restrictive.  Since I don't know how much or little other people agree 
with those drafts, I wanted to raise the issue of the treatment of the 
transport in those drafts.

Yours,
Joel

On 2/12/14, 2:32 PM, Ron Parker wrote:
> Linda,
>
> My interpretation of the architecture docs is that the service
> function chain is built in an abstract manner (i.e., SF-A then SF-B
> then SF-C).    Separately, a locator table provides network location
> for each of those service functions.   In this way, you can locate
> the service functions in a manner appropriate to the type of
> transport you are using.   If you want that to be interface+VLAN,
> gateway-IP+MPLS label stack, IP address, GRE tunnel remote IP + key,
> etc., you can do that.    You can even potentially locate different
> service functions that reside in the same chain with different
> flavors of network locators.    Another justification to separate the
> identity of a service function from its network location is load
> balancing.   If, for example, SF-A had 3 IP addresses, that would
> imply load balancing to 3 instances using IP as a transport layer.
>
> For all of those reasons, I strongly support a canonical service
> header that is independent of the transport methodology.    At a
> particular node, the decision as to where to go next should be based
> solely on information carried in the canonical service header and not
> on the fields in the transport header.   That is, the SFC node
> discards the transport header and extracts the chain ID from the
> service header.    Through mechanisms we have not yet begun to
> discuss, the SFC node knows how to interpret the chain ID and
> ultimately how to progress the packet.
>
> Ron
>
>
> -----Original Message----- From: sfc [mailto:[email-masked]] On
> Behalf Of Linda Dunbar Sent: Wednesday, February 12, 2014 12:01 PM
> To: Joel M. Halpern; [email-masked] Subject: Re: [sfc] Framework
>
> "A Service Chain Classifier node can associate a unique Layer 2 or 3
> Label (e.g. VLAN, MPLS label) to the packets in the flow. Those
> Layer 2 or 3 Label makes it easier for subsequent nodes along the
> flow path to steer the flow to the service functions specified by the
> flow's service chain."
>
>
> Linda -----Original Message----- From: sfc
> [mailto:[email-masked]] On Behalf Of Joel M. Halpern Sent:
> Wednesday, February 12, 2014 10:20 AM To: [email-masked] Subject: [sfc]
> Framework
>
> I was looking at the framework proposal. The proposal has a very
> specific model of the scope of the transport header (that it is
> derived from, and relates only to, the first service function to
> which the packet will be directed. That is clearly an operational
> model we need to support.
>
> However, I would like to allow other transport operational models,
> such as the use of a VLAN to direct traffic along a chain.  Or the
> use of an MPLS label, or an MPLS label stack.
>
> Yours, Joel M. Halpern
>
> _______________________________________________ sfc mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/sfc
>
> _______________________________________________ sfc mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Ron Parker <[email-masked]>
Date: Wed, 12 Feb 2014 19:40:49 +0000

Thanks, Joel.

To be clear, do you support the strict separation of the service header and the transport header that I tried to describe in my response to Linda?

   Ron

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, February 12, 2014 2:37 PM
To: Ron Parker; Linda Dunbar; [email-masked]
Subject: Re: [sfc] Framework

Ron, I think the architecture document (quinn) describes these issues in a fashion taht is sufficiently flexible.
And I support the definition of the service header.

Some of the other individual drafts however refer to process that mandate transport behavior.  And do so in ways that are, in my view, too restrictive.  Since I don't know how much or little other people agree with those drafts, I wanted to raise the issue of the treatment of the transport in those drafts.

Yours,
Joel

On 2/12/14, 2:32 PM, Ron Parker wrote:
> Label (e.g. VLAN, MPLS label) to the packets in the flow. Those Layer 
> 2 or 3 Label makes it easier for subsequent nodes along the flow path 
> to steer the flow to the service functions specified by the flow's 
> service chain."
>
>
> derived from, and relates only to, the first service function to which 
> the packet will be directed. That is clearly an operational model we 
> need to support.
>
> such as the use of a VLAN to direct traffic along a chain.  Or the use 
> of an MPLS label, or an MPLS label stack.
>
> Yours, Joel M. Halpern
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Feb 2014 14:43:12 -0500

Yes, I support a strict separation of the transport and service headers.

Yours,
Joel

---

From: Sumandra Majee <[email-masked]>
Date: Wed, 12 Feb 2014 20:03:55 +0000

>>For all of those reasons, I strongly support a canonical service header
>>that is independent of the transport methodology.

I agree. However the format of service header should be standardized in a
way that is flexible. Some of us would like to see variable length header
that is also HW friendly. The service header can be represented as a
mandotory fixed length header (like IP header) along with an optional
variable length attribute field. Different services can be interested in
different metadata, for example subscriber ID could be of interest in the
mobile core service chain only.

Sumandra

On 2/12/14, 11:32 AM, "Ron Parker" <[email-masked]> wrote:

>Linda,
>
>My interpretation of the architecture docs is that the service function
>chain is built in an abstract manner (i.e., SF-A then SF-B then SF-C).
>Separately, a locator table provides network location for each of those
>service functions.   In this way, you can locate the service functions in
>a manner appropriate to the type of transport you are using.   If you
>want that to be interface+VLAN, gateway-IP+MPLS label stack, IP address,
>GRE tunnel remote IP + key, etc., you can do that.    You can even
>potentially locate different service functions that reside in the same
>chain with different flavors of network locators.    Another
>justification to separate the identity of a service function from its
>network location is load balancing.   If, for example, SF-A had 3 IP
>addresses, that would imply load balancing to 3 instances using IP as a
>transport layer.
>
>For all of those reasons, I strongly support a canonical service header
>that is independent of the transport methodology.    At a particular
>node, the decision as to where to go next should be based solely on
>information carried in the canonical service header and not on the fields
>in the transport header.   That is, the SFC node discards the transport
>header and extracts the chain ID from the service header.    Through
>mechanisms we have not yet begun to discuss, the SFC node knows how to
>interpret the chain ID and ultimately how to progress the packet.
>
>    Ron
>
>
>Label (e.g. VLAN, MPLS label) to the packets in the flow. Those  Layer 2
>or 3 Label makes it easier for subsequent nodes along the flow path to
>steer the flow to the service functions specified by the flow's service
>chain."
>
>
>Linda

---

From: Ron Parker <[email-masked]>
Date: Wed, 12 Feb 2014 20:10:51 +0000

Hi, Sumandra.

Regarding service header flexibility, I completely agree.   I might suggest a compromise between hardware friendliness and software flexibility.    If the header had the ability to add extensions (perhaps similar to IPv6) but also had the header length encoded in the mandatory part (like IPv4), then a hardware implementation would be free to skip over the extensions (in cases where the deployment justifies ignoring the extensions).

   Ron

-----Original Message-----
From: Sumandra Majee [mailto:[email-masked]] 
Sent: Wednesday, February 12, 2014 3:04 PM
To: Ron Parker; Linda Dunbar; Joel M. Halpern; [email-masked]
Subject: Re: [sfc] Framework

>>header that is independent of the transport methodology.

I agree. However the format of service header should be standardized in a way that is flexible. Some of us would like to see variable length header that is also HW friendly. The service header can be represented as a mandotory fixed length header (like IP header) along with an optional variable length attribute field. Different services can be interested in different metadata, for example subscriber ID could be of interest in the mobile core service chain only.

Sumandra

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 12 Feb 2014 20:39:48 +0000

Hi,

We certainly need to be very careful with variable length headers when hardware platform are in play.  

Ron, your examples of IP options and v6 EH have both suffered from significant implementation and deployment hurdles due to the complexity and cost associated with hardware support for the option/EH.

Paul

---

From: Sumandra Majee <[email-masked]>
Date: Wed, 12 Feb 2014 20:42:44 +0000

Yep, that is possible. I would hope to see the header format captured in
the architecture document itself.

On 2/12/14, 12:10 PM, "Ron Parker" <[email-masked]> wrote:

>Hi, Sumandra.
>
>Regarding service header flexibility, I completely agree.   I might
>suggest a compromise between hardware friendliness and software
>flexibility.    If the header had the ability to add extensions (perhaps
>similar to IPv6) but also had the header length encoded in the mandatory
>part (like IPv4), then a hardware implementation would be free to skip
>over the extensions (in cases where the deployment justifies ignoring the
>extensions).
>
>   Ron
>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Feb 2014 15:53:34 -0500

Paul, I agree that the various extension headers / options have not seen 
uptake.  This is in aprt due to it being somewhat more complex for the 
hardware.  But mostly because the initial need was not there.
In this case, we need variable metadata.  The range of metadata that 
people have discussed with me is so high that I can not imagine a fixed 
length header handling even 80% of the cases well.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Feb 2014 15:54:48 -0500

Sumandra, I would have to dsiagree with you.  The structure of the 
transport-independent service header (which will be carrying the 
metadata) is very important, but not architectural.  The existence of 
such a header is very much architectural.

Yours,
Joel

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Wed, 12 Feb 2014 21:04:15 +0000

+1 I complete agree with Joel's assessment.

Surendra.

On 2/12/14 12:54 PM, "Joel M. Halpern" <[email-masked]> wrote:

>>>>function
>>>>header
>>>>such

---

From: Ron Parker <[email-masked]>
Date: Wed, 12 Feb 2014 21:05:10 +0000

Paul, 

That is why I am proposing a hybrid where extensions or options can be added but the total length is contained in the fixed portion.   I can envision certain deployments (e.g., Enterprise) where perhaps extensions are not needed and the SFC functionality is realized in hardware.   And, I can envision certain other deployments (e.g., 3gpp) where the extension headers add sufficient value to justify software based implementations.

     Ron

-----Original Message-----
From: Paul Quinn (paulq) [mailto:[email-masked]] 
Sent: Wednesday, February 12, 2014 3:40 PM
To: Ron Parker
Cc: Sumandra Majee; Linda Dunbar; Joel M. Halpern; [email-masked]
Subject: Re: [sfc] Framework

Hi,

Paul

On Feb 12, 2014, at 3:10 PM, Ron Parker <[email-masked]> wrote:

>> function chain is built in an abstract manner (i.e., SF-A then SF-B then SF-C).
>> addresses, that would imply load balancing to 3 instances using IP as 
>> a transport layer.
>> 
>> mechanisms we have not yet begun to discuss, the SFC node knows how 
>> to interpret the chain ID and ultimately how to progress the packet.
>> 
>>   Ron
>> 
>> 
>> Layer
>> header (that it is derived from, and relates only to, the first 
>> service function to which the packet will be directed.

---

From: Dave Dolson <[email-masked]>
Date: Wed, 12 Feb 2014 21:09:59 +0000

I think a good approach would be:

The information required for forwarding (the SF Identifier) should be in a mandatory fixed-size header.

Optional information (if any) is NOT to be used for forwarding, but is for consumption by one or more of the applications in the chain.

Then the forwarding plane, and even the PDP, can be agnostic about the meta-data.

-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Wednesday, February 12, 2014 4:05 PM
To: Paul Quinn (paulq)
Cc: Joel M. Halpern; Sumandra Majee; [email-masked]; Linda Dunbar
Subject: Re: [sfc] Framework

Paul, 

     Ron

-----Original Message-----
From: Paul Quinn (paulq) [mailto:[email-masked]] 
Sent: Wednesday, February 12, 2014 3:40 PM
To: Ron Parker
Cc: Sumandra Majee; Linda Dunbar; Joel M. Halpern; [email-masked]
Subject: Re: [sfc] Framework

Hi,

Paul

---

From: Ron Parker <[email-masked]>
Date: Wed, 12 Feb 2014 21:24:26 +0000

Hi, Dave.

I  Agree with your statement.    And if the total length of the header is contained in the mandatory portion, the hardware implementation can easily locate the encapsulated packet.

   Ron

-----Original Message-----
From: Dave Dolson [mailto:[email-masked]] 
Sent: Wednesday, February 12, 2014 4:10 PM
To: Ron Parker; Paul Quinn (paulq)
Cc: Joel M. Halpern; Sumandra Majee; [email-masked]; Linda Dunbar
Subject: RE: [sfc] Framework

-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Wednesday, February 12, 2014 4:05 PM
To: Paul Quinn (paulq)
Cc: Joel M. Halpern; Sumandra Majee; [email-masked]; Linda Dunbar
Subject: Re: [sfc] Framework

Paul, 

     Ron

-----Original Message-----
From: Paul Quinn (paulq) [mailto:[email-masked]]
Sent: Wednesday, February 12, 2014 3:40 PM
To: Ron Parker
Cc: Sumandra Majee; Linda Dunbar; Joel M. Halpern; [email-masked]
Subject: Re: [sfc] Framework

Hi,

Paul

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Feb 2014 16:30:27 -0500

I agree as well.
Yours,
Joel

---

From: Dave Dolson <[email-masked]>
Date: Wed, 12 Feb 2014 22:17:59 +0000

The forwarding plane might not even need to look at the encapsulated packet.

For example, (if the SF Identifier is a VLAN tag), an Ethernet switch can forward packets of the form:  Ether | VLAN | BLOB.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, February 12, 2014 4:30 PM
To: Ron Parker; Dave Dolson; Paul Quinn (paulq)
Cc: Sumandra Majee; [email-masked]; Linda Dunbar
Subject: Re: [sfc] Framework

I agree as well.
Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Wed, 12 Feb 2014 22:25:32 +0000

Dave,

Yes, that is a good point if we logically separate the forwarding function from the SFC-aware service function, as we should.   The forwarding function is concerned with only the inbound transport header, the fixed portion of the service header containing the chain information, and the outbound transport header.    The service function may look at the entirety of the service header and would look at the encapsulated packet.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, February 12, 2014 4:30 PM
To: Ron Parker; Dave Dolson; Paul Quinn (paulq)
Cc: Sumandra Majee; [email-masked]; Linda Dunbar
Subject: Re: [sfc] Framework

I agree as well.
Yours,
Joel

On 2/12/14, 4:24 PM, Ron Parker wrote:
>>> addresses, that would imply load balancing to 3 instances using IP 
>>> as a transport layer.
>>>
>>> 	"A Service Chain Classifier node can associate a unique Layer 2 or 
>>> 3 Label (e.g. VLAN, MPLS label) to the packets in the flow. Those 
>>> Layer
>>> 2 or 3 Label makes it easier for subsequent nodes along the flow 
>>> path to steer the flow to the service functions specified by the 
>>> flow's service chain."
>>>
>>>
>>> Linda

---

From: Sumandra Majee <[email-masked]>
Date: Wed, 12 Feb 2014 22:27:12 +0000

Are you suggesting a different document? 

This would be required for interoperability so it is still part of *a* document. 
________________________________________
From: Joel M. Halpern [[email-masked]]
Sent: Wednesday, February 12, 2014 12:54 PM
To: Sumandra Majee; Ron Parker; Linda Dunbar; [email-masked]
Subject: Re: [sfc] Framework

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Feb 2014 17:42:06 -0500

Protocol descriptions are usually done in documents separate from 
architecture documents.
So yes, I am suggesting a different document.

Whether the service header ends up in its own document, as it is now in 
the quinn nsh draft, or ends up folded into a document with other 
protocol behavior work, if such is needed, is up to the WG.

Yours,
Joel

---

From: Nicolas BOUTHORS <[email-masked]>
Date: Thu, 13 Feb 2014 09:13:35 +0000

If we do not enforce a fix header size we have other implication.

There is the question of segmentation and reassembly responsibility as well.

If adding length to the service header forces segmentation, then whose responsibility is it
to reassemble the payload before passing it to the SF.  

Similar question for packet re-ordering.

________________________________________
From: Ron Parker [[email-masked]]
Sent: Wednesday, February 12, 2014 11:25 PM
To: Dave Dolson; Joel M. Halpern; Paul Quinn (paulq)
Cc: Sumandra Majee; [email-masked]; Linda Dunbar
Subject: Re: [sfc] Framework

Dave,

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, February 12, 2014 4:30 PM
To: Ron Parker; Dave Dolson; Paul Quinn (paulq)
Cc: Sumandra Majee; [email-masked]; Linda Dunbar
Subject: Re: [sfc] Framework

I agree as well.
Yours,
Joel

---

From: <[email-masked]>
Date: Thu, 13 Feb 2014 10:44:59 +0100

Hi Joel,

The document does not exclude any transport modes; the ones that are listed are provided for illustration purposes. The behavior of the classifier for instance is generic:  "The SFC Classifier classifies packets based on (some of) the contents of the packet."

Cheers,
Med

>-----Message d'origine-----
>De : sfc [mailto:[email-masked]] De la part de Joel M. Halpern
>Envoyé : mercredi 12 février 2014 17:20
>À : [email-masked]
>Objet : [sfc] Framework
>

---

From: <[email-masked]>
Date: Thu, 13 Feb 2014 11:14:38 +0100

Re-,

Please see inline.

Cheers,
Med

>Envoyé : mercredi 12 février 2014 20:37
>À : Ron Parker; Linda Dunbar; [email-masked]
>Objet : Re: [sfc] Framework
>

[Med] If by "other" you include draft-boucadair-sfc-framework, I reiterate my response: there is no excluded transport modes. The document lists some options as (non-exhaustive) examples, and points to a detailed design analysis document. This BTW aligned with the charter of the WG that says the following:

"
2. Architecture: This document will provide a description of the SFC
architectural building blocks and their relationships including
interconnection, placement of SFC specific capabilities, management,
diagnostics, design analysis, and security models, as well as
requirements on the protocol mechanisms. The initial scope is
restricted to a single administrative domain, keeping in mind that
architectural decisions made for the intra-domain case may have
implications for the inter-domain case.
"

>restrictive. 

[Med] There is no such restriction at least in draft-boucadair-*. I hope this is now more clearer.

 Since I don't know how much or little other people agree

---

From: <[email-masked]>
Date: Thu, 13 Feb 2014 11:30:53 +0100

Re-,

There is a need to assess the validity of those cases (and others which are documented in use-case drafts) to avoid over-specification. The WG need to identify the core functionally and ovoid designing a solution that would be much more complex that current practices. BTW, there should be a way to assess to what extent proposed solutions solves the issues raised in the Problem Statement draft. 

"Flexibility" cannot be blindly used as an argument to justify more complexity. There are trade-offs; we should be aware of those when making design decision. 

I really hope we can follow the principles in RFC1925 and RFC3439; particularly this one: 

" In protocol design, perfection has been reached not when there
        is nothing left to add, but when there is nothing left to take
        away."

My current position on mandatory piece of information to be included in the metadata is recorded in: http://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-02#section-5.5 that is one single code point.

Cheers,
Med

>Envoyé : mercredi 12 février 2014 21:54
>À : Paul Quinn (paulq); Ron Parker
>Cc : Sumandra Majee; [email-masked]; Linda Dunbar
>Objet : Re: [sfc] Metadata structure
>
>> Ron, your examples of IP options and v6 EH have both suffered from
>significant implementation and deployment hurdles due to the complexity and
>cost associated with hardware support for the option/EH.
>>
>> Paul
>>
>part (like IPv4), then a hardware implementation would be free to skip over
>the extensions (in cases where the deployment justifies ignoring the
>extensions).
>>>
>>>    Ron
>>>
>>>
>>> I agree. However the format of service header should be standardized in
>a way that is flexible. Some of us would like to see variable length header

---

From: Dave Dolson <[email-masked]>
Date: Thu, 13 Feb 2014 12:39:18 +0000

Good point to consider fragmentation. 

We should design the encapsulation such that the forwarding functions do not need to reassemble. Each fragment should be independently forwardable; some SFs may choose to ignore these packets. 

Any layer 2.5 protocol like VLAN or MPLS would support this. 
Otherwise, a reassembly layer could be added after the forwarding coordinates. Think of something like the IPv6 reassembly option after a GRE header, for instance.  

IP | GRE | reassem | frag data

We could alternatively mandate the inner IP be fragmented and that path-MTU discovery be supported. 

----- Original Message -----
From: Nicolas BOUTHORS [mailto:[email-masked]]
Sent: Thursday, February 13, 2014 04:13 AM
To: Ron Parker <[email-masked]>; Dave Dolson; Joel M. Halpern <[email-masked]>; Paul Quinn (paulq) <[email-masked]>
Cc: Sumandra Majee <[email-masked]>; [email-masked] <[email-masked]>; Linda Dunbar <[email-masked]>
Subject: Re: [sfc] Framework

Dave,

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, February 12, 2014 4:30 PM
To: Ron Parker; Dave Dolson; Paul Quinn (paulq)
Cc: Sumandra Majee; [email-masked]; Linda Dunbar
Subject: Re: [sfc] Framework

I agree as well.
Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Thu, 13 Feb 2014 12:52:50 +0000

Nicolas,

If you add even 1 byte, you could require fragmentation, so I don't think fixed vs variable creates the need, but perhaps contributes to the frequency that it must occur.   If the transport header includes an ipv4 or ipv6 header, then fragmentation, when necessary, would occur in the outer datagram, only.

   Ron

> On Feb 13, 2014, at 4:14 AM, "Nicolas BOUTHORS" <[email-masked]> wrote:
>

---

From: <[email-masked]>
Date: Thu, 13 Feb 2014 14:21:30 +0100

Re-,

FWIW, one of the existing architecture drafts includes the following behavior (http://tools.ietf.org/html/draft-boucadair-sfc-framework-02#section-6):

"
6. Fragmentation Considerations

   If adding the Service Chaining Header would result in a fragmented
   packet, the classifier should include a Service Chaining Header in
   each fragment.  Doing so would prevent SF Nodes to dedicate resource
   to handle fragments.
" 

Cheers,
Med

>De : sfc [mailto:[email-masked]] De la part de Dave Dolson
>Envoyé : jeudi 13 février 2014 13:39
>À : [email-masked]'; [email-masked]';
>[email-masked]'; [email-masked]'
>Cc : [email-masked]'; [email-masked]'; [email-masked]'
>We should design the encapsulation such that the forwarding functions do
>not need to reassemble. Each fragment should be independently forwardable;
>some SFs may choose to ignore these packets.
>
>Otherwise, a reassembly layer could be added after the forwarding
>coordinates. Think of something like the IPv6 reassembly option after a GRE
>header, for instance.
>
>To: Ron Parker <[email-masked]>; Dave Dolson; Joel M.
>Halpern <[email-masked]>; Paul Quinn (paulq) <[email-masked]>
>Yes, that is a good point if we logically separate the forwarding function
>from the SFC-aware service function, as we should.   The forwarding
>function is concerned with only the inbound transport header, the fixed
>portion of the service header containing the chain information, and the
>outbound transport header.    The service function may look at the entirety
>of the service header and would look at the encapsulated packet.
>
>   Ron
>
>
>For example, (if the SF Identifier is a VLAN tag), an Ethernet switch can
>forward packets of the form:  Ether | VLAN | BLOB.
>
>
>
>> I  Agree with your statement.    And if the total length of the header is
>contained in the mandatory portion, the hardware implementation can easily
>locate the encapsulated packet.
>>
>>     Ron
>>
>>
>> Optional information (if any) is NOT to be used for forwarding, but is
>for consumption by one or more of the applications in the chain.
>>
>> That is why I am proposing a hybrid where extensions or options can be
>added but the total length is contained in the fixed portion.   I can
>envision certain deployments (e.g., Enterprise) where perhaps extensions
>are not needed and the SFC functionality is realized in hardware.   And, I
>can envision certain other deployments (e.g., 3gpp) where the extension
>headers add sufficient value to justify software based implementations.
>>
>>       Ron
>>
>>
>then SF-C).

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 13 Feb 2014 09:28:15 -0500

Unfortunately, while you intended to be transport agnostic, much of the 
behavioral description in section 5.2 and 5.4 is very specific about the 
required forwarding behaviors, including the scope of the transport.

Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Thu, 13 Feb 2014 14:43:18 +0000

Joel,

In draft-boucadair-framework, section 5.2, SFC classifier, it is describing examination of fields in the IP header of the original packet, independent of what variant of transport delivered it to/from the classifier.   Perhaps we need to bring out that the payload that gets encapsulated by the service header and then the transport header could, itself, be L2 or L3, and consequently, examination of L2-L4 fields are potentially valid.

In section 5.4, SFC Egress Node, we could improve the text to say "strip the SFC transport header and the SFC service header" rather than calling out the SF Map Index, explicitly.

Would this satisfy your concerns?

   Ron

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 9:28 AM
To: [email-masked]; Ron Parker; Linda Dunbar; [email-masked]
Subject: Re: [sfc] Framework

Unfortunately, while you intended to be transport agnostic, much of the behavioral description in section 5.2 and 5.4 is very specific about the required forwarding behaviors, including the scope of the transport.

Yours,
Joel

On 2/13/14, 5:14 AM, [email-masked] wrote:
>> Envoyé : mercredi 12 février 2014 20:37 À : Ron Parker; Linda Dunbar; 
>> [email-masked] Objet : Re: [sfc] Framework
>>
>> Ron, I think the architecture document (quinn) describes these issues 
>> in a fashion taht is sufficiently flexible.
>> mandate transport behavior.  And do so in ways that are, in my view, 
>> too restrictive.
>
>> with those drafts, I wanted to raise the issue of the treatment of 
>> the transport in those drafts.
>>
>> Yours,
>> Joel
>>
>>> -----Original Message----- From: sfc [mailto:[email-masked]] 
>>> On Behalf Of Linda Dunbar Sent: Wednesday, February 12, 2014 12:01 
>>> PM
>>> flow path to steer the flow to the service functions specified by 
>>> the flow's service chain."
>>>
>>>
>>> Wednesday, February 12, 2014 10:20 AM To: [email-masked] Subject: 
>>> [sfc] Framework
>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 13 Feb 2014 10:09:59 -0500

There is a related complexity.
I hope that we expect to support IPv6.
IPv6 explicitly prohibits network elements from fragmenting end user 
packets.

Yours,
Joel

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 13 Feb 2014 15:15:26 +0000

It is a given that the architecture support both v4 & v6 while at the same
time we should not mandate one over the other.

Surendra.

On 2/13/14 7:09 AM, "Joel M. Halpern" <[email-masked]> wrote:

>> FWIW, one of the existing architecture drafts includes the following
>>behavior 
>>(http://tools.ietf.org/html/draft-boucadair-sfc-framework-02#section-6):
>>
>> "
>>> We could alternatively mandate the inner IP be fragmented and that
>>>path-MTU
>>> discovery be supported.
>>>
>>>
>>>
>>>
>>>> The information required for forwarding (the SF Identifier) should be
>>>>in
>>> a mandatory fixed-size header.
>>>>
>>>> On Feb 12, 2014, at 3:10 PM, Ron Parker
>>>><[email-masked]>
>>> wrote:
>>>>
>>>>> Hi, Sumandra.
>>>>>
>>>over
>>>>>> service functions.   In this way, you can locate the service
>>>>>>functions
>>> in

---

From: Ron Parker <[email-masked]>
Date: Thu, 13 Feb 2014 15:18:32 +0000

Joel,

That is an excellent point to consider when choosing transport encapsulations.   If the transport encapsulation is IPv4 or IPv6 based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, etc.), then fragmentation and defragmentation are naturally supported.    If the transport encapsulation is VLAN, MPLS, etc., then I believe one of the following must be true:

* The end-to-end path is known to support the resulting larger frames
* A path discovery mechanism is mandated by SFC when non-IP transports are used
* An SFC-specific fragmentation header and mechanisms must be defined (i.e., SFC-transport/SFC-fragmentation/SFC-service/original-packet-or-frame)

    Ron

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 10:10 AM
To: [email-masked]; Dave Dolson; [email-masked]'; Ron Parker; [email-masked]'
Cc: [email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: [sfc] Framework

There is a related complexity.
I hope that we expect to support IPv6.
IPv6 explicitly prohibits network elements from fragmenting end user packets.

Yours,
Joel

On 2/13/14, 8:21 AM, [email-masked] wrote:
>> Envoyé : jeudi 13 février 2014 13:39 À : 
>> [email-masked]'; [email-masked]';
>> We should design the encapsulation such that the forwarding functions 
>> do not need to reassemble. Each fragment should be independently 
>> forwardable; some SFs may choose to ignore these packets.
>>
>> coordinates. Think of something like the IPv6 reassembly option after 
>> a GRE header, for instance.
>>
>> path-MTU discovery be supported.
>>
>>
>>
>>
>> If adding length to the service header forces segmentation, then 
>> whose responsibility is it to reassemble the payload before passing 
>> it to the SF.
>>
>> function is concerned with only the inbound transport header, the 
>>fixed  portion of the service header containing the chain information, and the
>> For example, (if the SF Identifier is a VLAN tag), an Ethernet switch 
>> can forward packets of the form:  Ether | VLAN | BLOB.
>>
>>
>>
>> contained in the mandatory portion, the hardware implementation can 
>> easily locate the encapsulated packet.
>>>
>>>      Ron
>>>
>>>
>>> The information required for forwarding (the SF Identifier) should 
>>> be in
>>> Then the forwarding plane, and even the PDP, can be agnostic about 
>>> the
>> meta-data.
>>>
>>> -Dave
>>>
>>>
>> can envision certain other deployments (e.g., 3gpp) where the 
>> extension headers add sufficient value to justify software based implementations.
>>>
>>>        Ron
>>>
>>>
>>> We certainly need to be very careful with variable length headers 
>>> when
>> hardware platform are in play.
>>>
>> significant implementation and deployment hurdles due to the 
>> complexity and cost associated with hardware support for the option/EH.
>>>
>>> Paul
>>>
>> similar to IPv6) but also had the header length encoded in the 
>> mandatory part (like IPv4), then a hardware implementation would be 
>> free to skip over the extensions (in cases where the deployment 
>> justifies ignoring the extensions).
>>>>
>>>>     Ron
>>>>
>>>>
>> a way that is flexible. Some of us would like to see variable length 
>> header that is also HW friendly. The service header can be 
>> represented as a mandotory fixed length header (like IP header) along 
>> with an optional variable length attribute field. Different services 
>> can be interested in different metadata, for example subscriber ID 
>> could be of interest in the mobile core service chain only.
>>>>
>>>> Sumandra
>>>>
>>>> On 2/12/14, 11:32 AM, "Ron Parker" 
>>>>> node, the decision as to where to go next should be based solely 
>>>>> on information carried in the canonical service header and not on 
>>>>> the
>> fields
>>>>> mechanisms we have not yet begun to discuss, the SFC node knows 
>>>>> how to interpret the chain ID and ultimately how to progress the packet.
>>>>>
>>>>>     Ron
>>>>>
>>>>>
>>>>> The proposal has a very specific model of the scope of the 
>>>>> transport header (that it is derived from, and relates only to, 
>>>>> the first service function to which the packet will be directed.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 13 Feb 2014 10:31:22 -0500

I mostly agree with you Ron.  I can probably come up with some other 
variations, but your second point is that the transport must deal with 
the issue of frame size / fit.

I would note that if we assume that the carrying encaps (IPv4/v6 outer) 
is being fragmented, then we are assuming that the exit from service 
chaining can and will reassemble.

Yours,
Joel

On 2/13/14, 10:18 AM, Ron Parker wrote:
> Joel,
>
> That is an excellent point to consider when choosing transport
> encapsulations.   If the transport encapsulation is IPv4 or IPv6
> based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, etc.), then
> fragmentation and defragmentation are naturally supported.    If the
> transport encapsulation is VLAN, MPLS, etc., then I believe one of
> the following must be true:
>
> * The end-to-end path is known to support the resulting larger
> frames * A path discovery mechanism is mandated by SFC when non-IP
> transports are used * An SFC-specific fragmentation header and
> mechanisms must be defined (i.e.,
> SFC-transport/SFC-fragmentation/SFC-service/original-packet-or-frame)
>
>  Ron
>
>
> -----Original Message----- From: Joel M. Halpern
> [mailto:[email-masked]] Sent: Thursday, February 13, 2014 10:10
> AM To: [email-masked]; Dave Dolson;
> [email-masked]'; Ron Parker; [email-masked]' Cc:
> [email-masked]'; [email-masked]'; [email-masked]' Subject:
> Re: [sfc] Framework
>
> There is a related complexity. I hope that we expect to support
> IPv6. IPv6 explicitly prohibits network elements from fragmenting end
> user packets.
>
> Yours, Joel
>
>> FWIW, one of the existing architecture drafts includes the
>> following behavior
"
>> each fragment.  Doing so would prevent SF Nodes to dedicate
>> resource to handle fragments. "
>>
>> Cheers, Med
>>
>>
>>> -----Message d'origine----- De : sfc
>>> [mailto:[email-masked]] De la part de Dave Dolson Envoyé :
>>> jeudi 13 février 2014 13:39 À : [email-masked]';
>>> [email-masked]'; [email-masked]';
>>> [email-masked]' Cc : [email-masked]'; [email-masked]';
>>> [email-masked]' Objet : Re: [sfc] Framework
>>>
>>> We should design the encapsulation such that the forwarding
>>> functions do not need to reassemble. Each fragment should be
>>> independently forwardable; some SFs may choose to ignore these
>>> packets.
>>>
>>> Otherwise, a reassembly layer could be added after the
>>> forwarding coordinates. Think of something like the IPv6
>>> reassembly option after a GRE header, for instance.
>>>
>>> ----- Original Message ----- From: Nicolas BOUTHORS
>>> [mailto:[email-masked]] Sent: Thursday, February 13,
>>> 2014 04:13 AM To: Ron Parker <[email-masked]>;
>>> Dave Dolson; Joel M. Halpern <[email-masked]>; Paul Quinn
>>> (paulq) <[email-masked]> Cc: Sumandra Majee <[email-masked]>;
>>> [email-masked] <[email-masked]>; Linda Dunbar
>>> <[email-masked]> Subject: Re: [sfc] Framework
>>>
>>> whose responsibility is it to reassemble the payload before
>>> passing it to the SF.
>>>
>>> ________________________________________ From: Ron Parker
>>> [[email-masked]] Sent: Wednesday, February 12,
>>> 2014 11:25 PM To: Dave Dolson; Joel M. Halpern; Paul Quinn
>>> (paulq) Cc: Sumandra Majee; [email-masked]; Linda Dunbar Subject:
>>> Re: [sfc] Framework
>>>
>>> Dave,
>>>
>>> Yes, that is a good point if we logically separate the forwarding
>>> function from the SFC-aware service function, as we should.   The
>>> forwarding function is concerned with only the inbound transport
>>> header, the fixed  portion of the service header containing the
>>> chain information, and the outbound transport header.    The
>>> service function may look at the entirety of the service header
>>> and would look at the encapsulated packet.
>>>
>>> Ron
>>>
>>>
>>> -----Original Message----- From: Dave Dolson
>>> [mailto:[email-masked]] Sent: Wednesday, February 12, 2014
>>> 5:18 PM To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq) Cc:
>>> Sumandra Majee; [email-masked]; Linda Dunbar Subject: RE: [sfc]
>>> Framework
>>>
>>> For example, (if the SF Identifier is a VLAN tag), an Ethernet
>>> switch can forward packets of the form:  Ether | VLAN | BLOB.
>>>
>>>
>>>
>>> -----Original Message----- From: sfc
>>> Wednesday, February 12, 2014 4:30 PM To: Ron Parker; Dave Dolson;
>>> Paul Quinn (paulq) Cc: Sumandra Majee; [email-masked]; Linda
>>> Dunbar Subject: Re: [sfc] Framework
>>>
>>> I agree as well. Yours, Joel
>>>
>>> contained in the mandatory portion, the hardware implementation
>>> can easily locate the encapsulated packet.
>>>>
>>>> Ron
>>>>
>>>>
>>>> -----Original Message----- From: Dave Dolson
>>>> [mailto:[email-masked]] Sent: Wednesday, February 12,
>>>> 2014 4:10 PM To: Ron Parker; Paul Quinn (paulq) Cc: Joel M.
>>>> Halpern; Sumandra Majee; [email-masked]; Linda Dunbar Subject:
>>>> RE: [sfc] Framework
>>>>
>>>> The information required for forwarding (the SF Identifier)
>>>> should be in
>>>> Then the forwarding plane, and even the PDP, can be agnostic
>>>> about the
>>> meta-data.
>>>>
>>>> -Dave
>>>>
>>>>
>>>> -----Original Message----- From: sfc
>>>> [mailto:[email-masked]] On Behalf Of Ron Parker Sent:
>>>> Wednesday, February 12, 2014 4:05 PM To: Paul Quinn (paulq) Cc:
>>>> Joel M. Halpern; Sumandra Majee; [email-masked]; Linda Dunbar
>>> added but the total length is contained in the fixed portion.   I
>>> can envision certain deployments (e.g., Enterprise) where perhaps
>>> extensions are not needed and the SFC functionality is realized
>>> in hardware.   And, I can envision certain other deployments
>>> (e.g., 3gpp) where the extension headers add sufficient value to
>>> justify software based implementations.
>>>>
>>>> Ron
>>>>
>>>>
>>>> -----Original Message----- From: Paul Quinn (paulq)
>>>> [mailto:[email-masked]] Sent: Wednesday, February 12, 2014
>>>> 3:40 PM To: Ron Parker Cc: Sumandra Majee; Linda Dunbar; Joel
>>>> M. Halpern; [email-masked] Subject: Re: [sfc] Framework
>>>>
>>>> Hi,
>>>>
>>>> We certainly need to be very careful with variable length
>>>> headers when
>>> flexibility.    If the header had the ability to add extensions
>>> (perhaps similar to IPv6) but also had the header length encoded
>>> in the mandatory part (like IPv4), then a hardware implementation
>>> would be free to skip over the extensions (in cases where the
>>> deployment justifies ignoring the extensions).
>>>>>
>>>>> Ron
>>>>>
>>>>>
>>>>> -----Original Message----- From: Sumandra Majee
>>>>> [mailto:[email-masked]] Sent: Wednesday, February 12, 2014
>>>>> 3:04 PM To: Ron Parker; Linda Dunbar; Joel M. Halpern;
>>>>> [email-masked] Subject: Re: [sfc] Framework
>>>>>
>>>>>>> For all of those reasons, I strongly support a canonical
>>>>>>> service header that is independent of the transport
>>>>>>> methodology.
>>>>>
>>>>>
>>> a way that is flexible. Some of us would like to see variable
>>> length header that is also HW friendly. The service header can
>>> be represented as a mandotory fixed length header (like IP
>>> header) along with an optional variable length attribute field.
>>> Different services can be interested in different metadata, for
>>> example subscriber ID could be of interest in the mobile core
>>> service chain only.
>>>>>
>>>>> Sumandra
>>>>>
>>>>>> My interpretation of the architecture docs is that the
>>>>>> service function chain is built in an abstract manner
>>>>>> (i.e., SF-A then SF-B
>>> then SF-C).
>>>>>> Separately, a locator table provides network location for
>>>>>> each of those service functions.   In this way, you can
>>>>>> locate the service functions
>>> in
>>>>>> a manner appropriate to the type of transport you are
>>>>>> using.   If you want that to be interface+VLAN,
>>>>>> gateway-IP+MPLS label stack, IP
>>> address,
>>>>>> GRE tunnel remote IP + key, etc., you can do that.    You
>>>>>> can even potentially locate different service functions
>>>>>> that reside in the same chain with different flavors of
>>>>>> network locators.    Another justification to separate the
>>>>>> identity of a service function from its network location is
>>>>>> load balancing.   If, for example, SF-A had 3 IP addresses,
>>>>>> that would imply load balancing to 3 instances using IP as
>>>>>> a transport layer.
>>>>>>
>>>>>> For all of those reasons, I strongly support a canonical
>>>>>> service header that is independent of the transport
>>>>>> methodology.    At a particular node, the decision as to
>>>>>> where to go next should be based solely on information
>>>>>> carried in the canonical service header and not on the
>>> fields
>>>>>> in the transport header.   That is, the SFC node discards
>>>>>> the transport header and extracts the chain ID from the
>>>>>> service header.    Through mechanisms we have not yet begun
>>>>>> to discuss, the SFC node knows how to interpret the chain
>>>>>> ID and ultimately how to progress the packet.
>>>>>>
>>>>>> Ron
>>>>>>
>>>>>>
>>>>>> -----Original Message----- From: sfc
>>>>>> [mailto:[email-masked]] On Behalf Of Linda Dunbar
>>>>>> Sent: Wednesday, February 12, 2014 12:01 PM To: Joel M.
>>>>>> Halpern; [email-masked] Subject: Re: [sfc] Framework
>>>>>>
>>>>>> I think a simple sentence below should be added Section 5.2
>>>>>> (SFC Classifier) to emphasize this point.
>>>>>>
>>>>>> "A Service Chain Classifier node can associate a unique
>>>>>> Layer 2 or 3 Label (e.g. VLAN, MPLS label) to the packets
>>>>>> in the flow. Those Layer 2 or 3 Label makes it easier for
>>>>>> subsequent nodes along the flow path to steer the flow to
>>>>>> the service functions specified by the flow's service
>>>>>> chain."
>>>>>>
>>>>>>
>>>>>> [mailto:[email-masked]] On Behalf Of Joel M. Halpern
>>>>>> Sent: Wednesday, February 12, 2014 10:20 AM To:
>>>>>> [email-masked] Subject: [sfc] Framework
>>>>>>
>>>>>> I was looking at the framework proposal. The proposal has a
>>>>>> very specific model of the scope of the transport header
>>>>>> (that it is derived from, and relates only to, the first
>>>>>> service function to which the packet will be directed. That
>>>>>> is clearly an operational model we need to support.
>>>>>>
>>>>>> However, I would like to allow other transport operational
>>>>>> models, such as the use of a VLAN to direct traffic along a
>>>>>> chain.  Or the use of an MPLS label, or an MPLS label
>>>>>> stack.
>>>>>>
>>>>>> Yours, Joel M. Halpern
>>>>>>
>>>>>> _______________________________________________ sfc mailing
>>>>>> list [email-masked]
>>>>>> _______________________________________________ sfc mailing
>>>>>> list [email-masked]
>>>>>> _______________________________________________ sfc mailing
>>>>>> list [email-masked]
>>>>> _______________________________________________ sfc mailing
>>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/sfc
>>>>
>>>> _______________________________________________ sfc mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/sfc
>>>>
>>>

---

From: Dave Dolson <[email-masked]>
Date: Thu, 13 Feb 2014 16:02:50 +0000

it is overall more efficient to support PMTU discovery rather than fragmenting every large packet. The is why TCP adopted it so early on. 

The fragmenting also puts huge performance burden on the service functions.
Fragmenting may also affect the ability of load balancers to get each fragment to the correct destination.  

So PMTU discovery SHOULD be used, in my opinion. By this I mean the client or server is informed that its packets are too big (for IPv6 or IPv4 with DF=1). 

Some operators may wish to incur the extra cost to hide the existence of the tunneling, when the elements of the chain can support it, so we could consider that as an optional mechanism. 

-Dave

----- Original Message -----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Thursday, February 13, 2014 10:31 AM
To: Ron Parker <[email-masked]>; [email-masked] <[email-masked]>; Dave Dolson; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Cc: [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Subject: Re: [sfc] Framework

Yours,
Joel

"

---

From: Jerome Moisand <[email-masked]>
Date: Thu, 13 Feb 2014 16:13:20 +0000

Yes, fragmentation and variable headers are usually a really bad thing for forwarding performance. Let's not forget that we live in a 100G-ish kind of world nowadays.

Now the question should be: WHY would we want to do that (variable headers leading to fragmentation issues)?

For example, the type of metadata that may require variable-length fields might be a better candidate for some out-of-band signaling mechanism. If this is service authorization data (e.g. a service profile/policy), this sounds likely. Not 100% sure this is true for all use cases though. Only a good understanding of use cases, grounded by reflecting on existing network architectures (notably broadband, fixed or mobile), would tell us if one approach or another is the most appropriate.

Anyhoo, we're jumping way deep in the detailed protocol design here. This seems a tad premature.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Thursday, February 13, 2014 11:03 AM
To: [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
Cc: [email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: [sfc] Framework

-Dave

----- Original Message -----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Thursday, February 13, 2014 10:31 AM
To: Ron Parker <[email-masked]>; [email-masked] <[email-masked]>; Dave Dolson; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Cc: [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Subject: Re: [sfc] Framework

I mostly agree with you Ron.  I can probably come up with some other variations, but your second point is that the transport must deal with the issue of frame size / fit.

I would note that if we assume that the carrying encaps (IPv4/v6 outer) is being fragmented, then we are assuming that the exit from service chaining can and will reassemble.

Yours,
Joel

On 2/13/14, 10:18 AM, Ron Parker wrote:
> transport encapsulation is VLAN, MPLS, etc., then I believe one of the 
> following must be true:
>
> * A path discovery mechanism is mandated by SFC when non-IP transports 
> are used * An SFC-specific fragmentation header and mechanisms must be 
> defined (i.e.,
> There is a related complexity. I hope that we expect to support IPv6. 
"
>> to handle fragments. "
>>> -----Message d'origine----- De : sfc [mailto:[email-masked]] 
>>> De la part de Dave Dolson Envoyé :
>>> coordinates. Think of something like the IPv6 reassembly option 
>>> after a GRE header, for instance.
>>>
>>> [email-masked] <[email-masked]>; Linda Dunbar <[email-masked]> 
>>> service function may look at the entirety of the service header and 
>>> would look at the encapsulated packet.
>>>
>>> Ron
>>>
>>>
>>> On Behalf Of Joel M. Halpern Sent:
>>> Paul Quinn (paulq) Cc: Sumandra Majee; [email-masked]; Linda Dunbar 
>>>> On Behalf Of Ron Parker Sent:
>>>> 3:40 PM To: Ron Parker Cc: Sumandra Majee; Linda Dunbar; Joel M. 
>>> (perhaps similar to IPv6) but also had the header length encoded in 
>>> the mandatory part (like IPv4), then a hardware implementation would 
>>> be free to skip over the extensions (in cases where the deployment 
>>> represented as a mandotory fixed length header (like IP
>>>>>> can even potentially locate different service functions that 
>>>>>> reside in the same chain with different flavors of
>>>>>> that would imply load balancing to 3 instances using IP as a 
>>>>>> transport layer.
>>>>>>
>>>>>> header that is independent of the transport
>>>>>> where to go next should be based solely on information carried in 
>>>>>> the canonical service header and not on the
>>> fields
>>>>>> to discuss, the SFC node knows how to interpret the chain ID and 
>>>>>> "A Service Chain Classifier node can associate a unique Layer 2 
>>>>>> or 3 Label (e.g. VLAN, MPLS label) to the packets in the flow. 
>>>>>> Those Layer 2 or 3 Label makes it easier for subsequent nodes 
>>>>>> along the flow path to steer the flow to the service functions 
>>>>>> specified by the flow's service chain."
>>>>>>
>>>>>>
>>>>>> chain.  Or the use of an MPLS label, or an MPLS label stack.
>>>>>>
>>>>>> Yours, Joel M. Halpern
>>>>>>

---

From: Ron Parker <[email-masked]>
Date: Thu, 13 Feb 2014 16:36:07 +0000

The point I was trying to make that even fixed size headers will create the need for fragmentation.    Furthermore, the full increase in packet/frame size must account for both the SFC-transport header and the SFC-service header.    A good network design will avoid the need for fragmentation (which is admittedly easier to account for with fixed sized headers).   But when it is not possible to set MTU/MFS large enough on all links, then the network should still function properly, although with the obvious inefficiencies that are introduced.   This is the IPv4 and IPv6 approach, in, general (especially IPv6) -- try to avoid fragmentation but deal with it when necessary.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Thursday, February 13, 2014 11:03 AM
To: [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
Cc: [email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: [sfc] Framework

-Dave

----- Original Message -----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Thursday, February 13, 2014 10:31 AM
To: Ron Parker <[email-masked]>; [email-masked] <[email-masked]>; Dave Dolson; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Cc: [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Subject: Re: [sfc] Framework

Yours,
Joel

"

---

From: Ron Parker <[email-masked]>
Date: Thu, 13 Feb 2014 16:38:59 +0000

Also, I don't think PMTU discovery is applicable here.   We are encapsulating original packets/frames.   What would we do if PMTU discovery told us that there is not sufficient headroom to add our encapsulations?

    Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Thursday, February 13, 2014 11:36 AM
To: Jerome Moisand; Dave Dolson; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
Cc: [email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: [sfc] Framework

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Thursday, February 13, 2014 11:03 AM
To: [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
Cc: [email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: [sfc] Framework

-Dave

----- Original Message -----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Thursday, February 13, 2014 10:31 AM
To: Ron Parker <[email-masked]>; [email-masked] <[email-masked]>; Dave Dolson; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Cc: [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Subject: Re: [sfc] Framework

Yours,
Joel

"

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 13 Feb 2014 11:40:02 -0500

should the draft indicate how a router should respond when the DNF bit is set?  To what should the MTU be set in the reply?

From: [email-masked]<[email-masked]>
To: Jerome Moisand<[email-masked]>,Dave Dolson<[email-masked]>,[email-masked]'<[email-masked]>,[email-masked]'<[email-masked]>,[email-masked]'<[email-masked]>,[email-masked]'<[email-masked]>
cc: [email-masked]'<[email-masked]>,[email-masked]'<[email-masked]>,[email-masked]'<[email-masked]>
Sent: Thursday, February 13, 2014
Subject: Re: [sfc] Framework

   Ron

-----Original Message-----

From: Jerome Moisand [mailto:[email-masked]] Sent: Thursday, February 13, 2014 11:13 AMTo: Dave Dolson; [email-masked]'; Ron Parker; [email-masked]'; [email-masked]'; [email-masked]'Cc: [email-masked]'; [email-masked]'; [email-masked]'Subject: RE: [sfc] FrameworkYes, fragmentation and variable headers are usually a really bad thing for forwarding performance. Let's not forget that we live in a 100G-ish kind of world nowadays.Now the question should be: WHY would we want to do that (variable headers leading to fragmentation issues)?For example, the type of metadata that may require variable-length fields might be a better candidate for some out-of-band signaling mechanism. If this is service authorization data (e.g. a service profile/policy), this sounds likely. Not 100% sure this is true for all use cases though. Only a good understanding of use cases, grounded by reflecting on existing network architectures (notably broadband, fixed or mobile), would tell us if one approach or another is the most appropriate.Anyhoo, we're jumping way deep in the detailed protocol design here. This seems a tad premature.-----Original Message-----From: sfc [mailto:[email-masked]] On Behalf Of Dave DolsonSent: Thursday, February 13, 2014 11:03 AMTo: [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'Cc: [email-masked]'; [email-masked]'; [email-masked]'Subject: Re: [sfc] Frameworkit is overall more efficient to support PMTU discovery rather than fragmenting every large packet. The is why TCP adopted it so early on. The fragmenting also puts huge performance burden on the service functions.Fragmenting may also affect the ability of load balancers to get each fragment to the correct destination.  So PMTU discovery SHOULD be used, in my opinion. By this I mean the client or server is informed that its packets are too big (for IPv6 or IPv4 with DF=1). Some operators may wish to incur the extra cost to hide the existence of the tunneling, when the elements of the chain can support it, so we could consider that as an optional mechanism. -Dave----- Original Message -----From: Joel M. Halpern [mailto:[email-masked]]Sent: Thursday, February 13, 2014 10:31 AMTo: Ron Parker <[email-masked]>; [email-masked] <[email-masked]>; Dave Dolson; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>Cc: [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>Subject: Re: [sfc] FrameworkI mostly agree with you Ron.  I can probably come up with some other variations, but your second point is that the transport must deal with the issue of frame size / fit.I would note that if we assume that the carrying encaps (IPv4/v6 outer) is being fragmented, then we are assuming that the exit from service chaining can and will reassemble.Yours,JoelOn 2/13/14, 10:18 AM, Ron Parker wrote:> Joel,>> That is an excellent point to consider when choosing transport> encapsulations.   If the transport encapsulation is IPv4 or IPv6> based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, etc.), then> fragmentation and defragmentation are naturally supported.    If the> transport encapsulation is VLAN, MPLS, etc., then I believe one of the > following must be true:>> * The end-to-end path is known to support the resulting larger frames> * A path discovery mechanism is mandated by SFC when non-IP transports > are used * An SFC-specific fragmentation header and mechanisms must be > defined (i.e.,> SFC-transport/SFC-fragmentation/SFC-service/original-packet-or-frame)>>  Ron>>> -----Original Message----- From: Joel M. Halpern > [mailto:[email-masked]] Sent: Thursday, February 13, 2014 10:10 > AM To: [email-masked]; Dave Dolson; > [email-masked]'; Ron Parker; [email-masked]' Cc:> [email-masked]'; [email-masked]'; [email-masked]' Subject:> Re: [sfc] Framework>> There is a related complexity. I hope that we expect to support IPv6. > IPv6 explicitly prohibits network elements from fragmenting end user > packets.>> Yours, Joel>> On 2/13/14, 8:21 AM, [email-masked] wrote:>> Re-,>>>> FWIW, one of the existing architecture drafts includes the following >> behavior>> (http://tools.ietf.org/html/draft-boucadair-sfc-framework-02#section-6):>>>>>>">> 6. Fragmentation Considerations>>>> If adding the Service Chaining Header would result in a fragmented >> packet, the classifier should include a Service Chaining Header in >> each fragment.  Doing so would prevent SF Nodes to dedicate resource >> to handle fragments. ">>>> Cheers, Med>>>>>>> -----Message d'origine----- De : sfc [mailto:[email-masked]] >>> De la part de Dave Dolson Envoyé :>>> jeudi 13 février 2014 13:39 À : [email-masked]'; >>> [email-masked]'; [email-masked]'; >>> [email-masked]' Cc : [email-masked]'; [email-masked]'; >>> [email-masked]' Objet : Re: [sfc] Framework>>>>>> Good point to consider fragmentation.>>>>>> We should design the encapsulation such that the forwarding >>> functions do not need to reassemble. Each fragment should be >>> independently forwardable; some SFs may choose to ignore these >>> packets.>>>>>> Any layer 2.5 protocol like VLAN or MPLS would support this.>>> Otherwise, a reassembly layer could be added after the forwarding >>> coordinates. Think of something like the IPv6 reassembly option >>> after a GRE header, for instance.>>>>>> IP | GRE | reassem | frag data>>>>>> We could alternatively mandate the inner IP be fragmented and that >>> path-MTU discovery be supported.>>>>>>>>>>>>>>> ----- Original Message ----- From: Nicolas BOUTHORS >>> [mailto:[email-masked]] Sent: Thursday, February 13,>>> 2014 04:13 AM To: Ron Parker <[email-masked]>;>>> Dave Dolson; Joel M. Halpern <[email-masked]>; Paul Quinn>>> (paulq) <[email-masked]> Cc: Sumandra Majee <[email-masked]>; >>> [email-masked] <[email-masked]>; Linda Dunbar <[email-masked]>>>> Subject: Re: [sfc] Framework>>>>>> If we do not enforce a fix header size we have other implication.>>>>>> There is the question of segmentation and reassembly responsibility >>> as well.>>>>>> If adding length to the service header forces segmentation, then >>> whose responsibility is it to reassemble the payload before passing >>> it to the SF.>>>>>> Similar question for packet re-ordering.>>>>>>>>> ________________________________________ From: Ron Parker >>> [[email-masked]] Sent: Wednesday, February 12,>>> 2014 11:25 PM To: Dave Dolson; Joel M. Halpern; Paul Quinn>>> (paulq) Cc: Sumandra Majee; [email-masked]; Linda Dunbar Subject:>>> Re: [sfc] Framework>>>>>> Dave,>>>>>> Yes, that is a good point if we logically separate the forwarding>>> function from the SFC-aware service function, as we should.   The>>> forwarding function is concerned with only the inbound transport >>> header, the fixed  portion of the service header containing the>>> chain information, and the outbound transport header.    The>>> service function may look at the entirety of the service header and >>> would look at the encapsulated packet.>>>>>> Ron>>>>>>>>> -----Original Message----- From: Dave Dolson >>> [mailto:[email-masked]] Sent: Wednesday, February 12, 2014>>> 5:18 PM To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq) Cc:>>> Sumandra Majee; [email-masked]; Linda Dunbar Subject: RE: [sfc] >>> Framework>>>>>> The forwarding plane might not even need to look at the encapsulated >>> packet.>>>>>> For example, (if the SF Identifier is a VLAN tag), an Ethernet >>> switch can forward packets of the form:  Ether | VLAN | BLOB.>>>>>>>>>>>> -----Original Message----- From: sfc [mailto:[email-masked]] >>> On Behalf Of Joel M. Halpern Sent:>>> Wednesday, February 12, 2014 4:30 PM To: Ron Parker; Dave Dolson; >>> Paul Quinn (paulq) Cc: Sumandra Majee; [email-masked]; Linda Dunbar>>> Subject: Re: [sfc] Framework>>>>>> I agree as well. Yours, Joel>>>>>> On 2/12/14, 4:24 PM, Ron Parker wrote:>>>> Hi, Dave.>>>>>>>> I  Agree with your statement.    And if the total length of the>>>> header is>>> contained in the mandatory portion, the hardware implementation can >>> easily locate the encapsulated packet.>>>>>>>> Ron>>>>>>>>>>>> -----Original Message----- From: Dave Dolson >>>> [mailto:[email-masked]] Sent: Wednesday, February 12,>>>> 2014 4:10 PM To: Ron Parker; Paul Quinn (paulq) Cc: Joel M.>>>> Halpern; Sumandra Majee; [email-masked]; Linda Dunbar Subject:>>>> RE: [sfc] Framework>>>>>>>> I think a good approach would be:>>>>>>>> The information required for forwarding (the SF Identifier) should >>>> be in>>> a mandatory fixed-size header.>>>>>>>> Optional information (if any) is NOT to be used for forwarding, but >>>> is>>> for consumption by one or more of the applications in the chain.>>>>>>>> Then the forwarding plane, and even the PDP, can be agnostic about >>>> the>>> meta-data.>>>>>>>> -Dave>>>>>>>>>>>> -----Original Message----- From: sfc [mailto:[email-masked]] >>>> On Behalf Of Ron Parker Sent:>>>> Wednesday, February 12, 2014 4:05 PM To: Paul Quinn (paulq) Cc:>>>> Joel M. Halpern; Sumandra Majee; [email-masked]; Linda Dunbar>>>> Subject: Re: [sfc] Framework>>>>>>>> Paul,>>>>>>>> That is why I am proposing a hybrid where extensions or options can >>>> be>>> added but the total length is contained in the fixed portion.   I>>> can envision certain deployments (e.g., Enterprise) where perhaps >>> extensions are not needed and the SFC functionality is realized>>> in hardware.   And, I can envision certain other deployments>>> (e.g., 3gpp) where the extension headers add sufficient value to >>> justify software based implementations.>>>>>>>> Ron>>>>>>>>>>>> -----Original Message----- From: Paul Quinn (paulq) >>>> [mailto:[email-masked]] Sent: Wednesday, February 12, 2014>>>> 3:40 PM To: Ron Parker Cc: Sumandra Majee; Linda Dunbar; Joel M. >>>> Halpern; [email-masked] Subject: Re: [sfc] Framework>>>>>>>> Hi,>>>>>>>> We certainly need to be very careful with variable length headers >>>> when>>> hardware platform are in play.>>>>>>>> Ron, your examples of IP options and v6 EH have both suffered from>>> significant implementation and deployment hurdles due to the >>> complexity and cost associated with hardware support for the >>> option/EH.>>>>>>>> Paul>>>>>>>> On Feb 12, 2014, at 3:10 PM, Ron Parker >>>> <[email-masked]>>>> wrote:>>>>>>>>> Hi, Sumandra.>>>>>>>>>> Regarding service header flexibility, I completely agree.   I>>>>> might>>> suggest a compromise between hardware friendliness and software>>> flexibility.    If the header had the ability to add extensions>>> (perhaps similar to IPv6) but also had the header length encoded in >>> the mandatory part (like IPv4), then a hardware implementation would >>> be free to skip over the extensions (in cases where the deployment >>> justifies ignoring the extensions).>>>>>>>>>> Ron>>>>>>>>>>>>>>> -----Original Message----- From: Sumandra Majee >>>>> [mailto:[email-masked]] Sent: Wednesday, February 12, 2014>>>>> 3:04 PM To: Ron Parker; Linda Dunbar; Joel M. Halpern; >>>>> [email-masked] Subject: Re: [sfc] Framework>>>>>>>>>>>> For all of those reasons, I strongly support a canonical service >>>>>>> header that is independent of the transport methodology.>>>>>>>>>>>>>>> I agree. However the format of service header should be >>>>> standardized in>>> a way that is flexible. Some of us would like to see variable length >>> header that is also HW friendly. The service header can be >>> represented as a mandotory fixed length header (like IP>>> header) along with an optional variable length attribute field.>>> Different services can be interested in different metadata, for >>> example subscriber ID could be of interest in the mobile core >>> service chain only.>>>>>>>>>> Sumandra>>>>>>>>>> On 2/12/14, 11:32 AM, "Ron Parker">>>>> <[email-masked]>>>> wrote:>>>>>>>>>>> Linda,>>>>>>>>>>>> My interpretation of the architecture docs is that the service >>>>>> function chain is built in an abstract manner (i.e., SF-A then >>>>>> SF-B>>> then SF-C).>>>>>> Separately, a locator table provides network location for>>>>>> each of those service functions.   In this way, you can>>>>>> locate the service functions>>> in>>>>>> a manner appropriate to the type of transport you are>>>>>> using.   If you want that to be interface+VLAN,>>>>>> gateway-IP+MPLS label stack, IP>>> address,>>>>>> GRE tunnel remote IP + key, etc., you can do that.    You>>>>>> can even potentially locate different service functions that >>>>>> reside in the same chain with different flavors of>>>>>> network locators.    Another justification to separate the>>>>>> identity of a service function from its network location is>>>>>> load balancing.   If, for example, SF-A had 3 IP addresses,>>>>>> that would imply load balancing to 3 instances using IP as a >>>>>> transport layer.>>>>>>>>>>>> For all of those reasons, I strongly support a canonical service >>>>>> header that is independent of the transport>>>>>> methodology.    At a particular node, the decision as to>>>>>> where to go next should be based solely on information carried in >>>>>> the canonical service header and not on the>>> fields>>>>>> in the transport header.   That is, the SFC node discards>>>>>> the transport header and extracts the chain ID from the>>>>>> service header.    Through mechanisms we have not yet begun>>>>>> to discuss, the SFC node knows how to interpret the chain ID and >>>>>> ultimately how to progress the packet.>>>>>>>>>>>> Ron>>>>>>>>>>>>>>>>>> -----Original Message----- From: sfc >>>>>> [mailto:[email-masked]] On Behalf Of Linda Dunbar>>>>>> Sent: Wednesday, February 12, 2014 12:01 PM To: Joel M.>>>>>> Halpern; [email-masked] Subject: Re: [sfc] Framework>>>>>>>>>>>> Agree with Joel's statement.>>>>>>>>>>>> I think a simple sentence below should be added Section 5.2 (SFC>>>>>> Classifier) to emphasize this point.>>>>>>>>>>>> "A Service Chain Classifier node can associate a unique Layer 2 >>>>>> or 3 Label (e.g. VLAN, MPLS label) to the packets in the flow.>>>>>> Those Layer 2 or 3 Label makes it easier for subsequent nodes >>>>>> along the flow path to steer the flow to the service functions >>>>>> specified by the flow's service chain.">>>>>>>>>>>>>>>>>> Linda -----Original Message----- From: sfc >>>>>> [mailto:[email-masked]] On Behalf Of Joel M. Halpern>>>>>> Sent: Wednesday, February 12, 2014 10:20 AM To:>>>>>> [email-masked] Subject: [sfc] Framework>>>>>>>>>>>> I was looking at the framework proposal. The proposal has a very >>>>>> specific model of the scope of the transport header (that it is >>>>>> derived from, and relates only to, the first service function to >>>>>> which the packet will be directed. That is clearly an operational >>>>>> model we need to support.>>>>>>>>>>>> However, I would like to allow other transport operational >>>>>> models, such as the use of a VLAN to direct traffic along a >>>>>> chain.  Or the use of an MPLS label, or an MPLS label stack.>>>>>>>>>>>> Yours, Joel M. Halpern>>>>>>>>>>>> _______________________________________________ sfc mailing list >>>>>> [email-masked] https://www.ietf.org/mailman/listinfo/sfc>>>>>>>>>>>> _______________________________________________ sfc mailing list >>>>>> [email-masked] https://www.ietf.org/mailman/listinfo/sfc>>>>>>>>>>>> _______________________________________________ sfc mailing list >>>>>> [email-masked] https://www.ietf.org/mailman/listinfo/sfc>>>>>>>>>> _______________________________________________ sfc mailing list >>>>> [email-masked] https://www.ietf.org/mailman/listinfo/sfc>>>>>>>> _______________________________________________ sfc mailing list >>>> [email-masked] https://www.ietf.org/mailman/listinfo/sfc>>>>>>>>>> _______________________________________________ sfc mailing list >>> [email-masked] https://www.ietf.org/mailman/listinfo/sfc>>>>>>>>>>>> _______________________________________________ sfc mailing list >>> [email-masked] https://www.ietf.org/mailman/listinfo/sfc>>>>>> _______________________________________________ sfc mailing list >>> [email-masked] https://www.ietf.org/mailman/listinfo/sfc>>>_______________________________________________sfc mailing [email-masked]://www.ietf.org/mailman/listinfo/sfc_______________________________________________sfc mailing [email-masked]://www.ietf.org/mailman/listinfo/sfc

---

From: Dave Dolson <[email-masked]>
Date: Thu, 13 Feb 2014 17:00:40 +0000

That is when the ICMP "too big" message is sent to the sender, indicating an appropriate size to use, just as when any constraining MTU is encountered. 

So discovering the MTU of the chain is part of it, then passing the smaller value on to the original sender. 

Admittedly, it difficult to choose a size with a variable (unbounded?) header. 

----- Original Message -----
From: Ron Parker [mailto:[email-masked]]
Sent: Thursday, February 13, 2014 11:38 AM
To: Ron Parker <[email-masked]>; Jerome Moisand <[email-masked]>; Dave Dolson; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Cc: [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Subject: RE: [sfc] Framework

    Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Thursday, February 13, 2014 11:36 AM
To: Jerome Moisand; Dave Dolson; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
Cc: [email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: [sfc] Framework

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Thursday, February 13, 2014 11:03 AM
To: [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
Cc: [email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: [sfc] Framework

-Dave

----- Original Message -----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Thursday, February 13, 2014 10:31 AM
To: Ron Parker <[email-masked]>; [email-masked] <[email-masked]>; Dave Dolson; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Cc: [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Subject: Re: [sfc] Framework

Yours,
Joel

"

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 13 Feb 2014 13:16:03 -0500

The variable length shim header is needed even if every individual piece 
of metadata has a fixed length.  Different service chains will need 
different combinations of metadata.  So the metadata portion of the 
header needs to be variable length.

I think the approach of a fixed length initial part, and a variable 
length extension part, is the right model.

Yours,
Joel

---

From: Bruno Rijsman <[email-masked]>
Date: Thu, 13 Feb 2014 13:40:40 -0500

resend to avoid "too many recipients" warning

On Thu, Feb 13, 2014 at 1:39 PM, Bruno Rijsman <[email-masked]>wrote:

> There are ways to signal variable length amounts of metadata without
> needing an additional variable-length header on each data packet.
>
> draft-rijsman-sfc-metadata-considerations-00 discusses some of the
> possible approaches: out-of-band signaling (congruent or non-congruent) or
> a hybrid approach using a fix-length in-band correlator and out-of-band
> additional metadata.  See sections 3.3, 3.4 and 3.5 in the draft.
>
> The issue of fixed-length encoding versus variable length encoding is
> discussion in the challenges chapter in section 4.3.  I should probably
> mention the MTU and segmentation issues as well in that section.
>
>
> On Thu, Feb 13, 2014 at 1:16 PM, Joel M. Halpern <[email-masked]>wrote:
>
>> different combinations of metadata.  So the metadata portion of the header
>> needs to be variable length.
>>
>>> Yes, fragmentation and variable headers are usually a really bad thing
>>> for forwarding performance. Let's not forget that we live in a 100G-ish
>>> kind of world nowadays.
>>>
>>> Now the question should be: WHY would we want to do that (variable
>>> headers leading to fragmentation issues)?
>>>
>>> For example, the type of metadata that may require variable-length
>>> fields might be a better candidate for some out-of-band signaling
>>> mechanism. If this is service authorization data (e.g. a service
>>> profile/policy), this sounds likely. Not 100% sure this is true for all use
>>> cases though. Only a good understanding of use cases, grounded by
>>> reflecting on existing network architectures (notably broadband, fixed or
>>> mobile), would tell us if one approach or another is the most appropriate.
>>>
>>> To: [email-masked]'; [email-masked]'; '
>>> [email-masked]'; [email-masked]'; '
>>> [email-masked]'
>>> it is overall more efficient to support PMTU discovery rather than
>>> fragmenting every large packet. The is why TCP adopted it so early on.
>>>
>>> So PMTU discovery SHOULD be used, in my opinion. By this I mean the
>>> client or server is informed that its packets are too big (for IPv6 or IPv4
>>> with DF=1).
>>>
>>> Some operators may wish to incur the extra cost to hide the existence of
>>> the tunneling, when the elements of the chain can support it, so we could
>>> consider that as an optional mechanism.
>>>
>>> -Dave
>>>
>>>
>>> To: Ron Parker <[email-masked]>;
>>> [email-masked] <[email-masked]>; Dave
>>> Dolson; [email-masked]' <[email-masked]>; '
>>> [email-masked]' <[email-masked]>
>>> Cc: [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; '
>>> [email-masked]' <[email-masked]>
>>> variations, but your second point is that the transport must deal with the
>>> issue of frame size / fit.
>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 13 Feb 2014 14:15:08 -0500

While there are cases where out-of-band metadata makes sense, There are 
many cases I would not want to try to cover that way.  The best examples 
are situations where the metadata changes from packet to packet (such as 
the data produced by a DPI engine for consumption by other applications 
in the chain.)

More importantly, if you are putting correlators in the packet, it is 
still very complex if you want to use one correlator to handle metadata 
produced by several different entities (the initial classifer, the DPI 
engine, ...)  You quickly end up deciding that you need several 
correlators.  At which point we are back to variable amounts of metadata.

The alternative is to require exceedingly specific and strong coupling 
to a mandated out-of-band mechanism.  That seems to me to be a very bad 
idea.

Yours,
Joel

On 2/13/14, 1:40 PM, Bruno Rijsman wrote:
> On Thu, Feb 13, 2014 at 1:39 PM, Bruno Rijsman <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     possible approaches: out-of-band signaling (congruent or
>     non-congruent) or a hybrid approach using a fix-length in-band
>     correlator and out-of-band additional metadata.  See sections 3.3,
>     3.4 and 3.5 in the draft.
>
>     The issue of fixed-length encoding versus variable length encoding
>     is discussion in the challenges chapter in section 4.3.  I should
>     probably mention the MTU and segmentation issues as well in that
>     section.
>
>
>     On Thu, Feb 13, 2014 at 1:16 PM, Joel M. Halpern
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         The variable length shim header is needed even if every
>         individual piece of metadata has a fixed length.  Different
>         service chains will need different combinations of metadata.  So
>         the metadata portion of the header needs to be variable length.
>
>         I think the approach of a fixed length initial part, and a
>         variable length extension part, is the right model.
>
>         Yours,
>         Joel
>
>
>             Yes, fragmentation and variable headers are usually a really
>             bad thing for forwarding performance. Let's not forget that
>             we live in a 100G-ish kind of world nowadays.
>
>             Now the question should be: WHY would we want to do that
>             (variable headers leading to fragmentation issues)?
>
>             For example, the type of metadata that may require
>             variable-length fields might be a better candidate for some
>             out-of-band signaling mechanism. If this is service
>             authorization data (e.g. a service profile/policy), this
>             sounds likely. Not 100% sure this is true for all use cases
>             though. Only a good understanding of use cases, grounded by
>             reflecting on existing network architectures (notably
>             broadband, fixed or mobile), would tell us if one approach
>             or another is the most appropriate.
>
>             From: sfc [mailto:[email-masked]
>             <mailto:[email-masked]>] On Behalf Of Dave Dolson
>             To: [email-masked] <mailto:[email-masked]>';
>             [email-masked]
>             <mailto:[email-masked]>';
>             [email-masked]
>             <mailto:[email-masked]>'__;
>             [email-masked]
>             <mailto:[email-masked]>'; [email-masked]
>             <mailto:[email-masked]>'
>             Cc: [email-masked]'; [email-masked] <mailto:[email-masked]>';
>             [email-masked] <mailto:[email-masked]>'
>             it is overall more efficient to support PMTU discovery
>             rather than fragmenting every large packet. The is why TCP
>             adopted it so early on.
>
>             Fragmenting may also affect the ability of load balancers to
>             get each fragment to the correct destination.
>
>             So PMTU discovery SHOULD be used, in my opinion. By this I
>             mean the client or server is informed that its packets are
>             too big (for IPv6 or IPv4 with DF=1).
>
>             Some operators may wish to incur the extra cost to hide the
>             existence of the tunneling, when the elements of the chain
>             can support it, so we could consider that as an optional
>             mechanism.
>
>             -Dave
>
>
>             From: Joel M. Halpern [mailto:[email-masked]
>             <mailto:[email-masked]>]
>             To: Ron Parker <[email-masked]
>             <mailto:[email-masked]>>;
>             [email-masked]
>             <mailto:[email-masked]>
>             <[email-masked]
>             <mailto:[email-masked]>>__; Dave Dolson;
>             [email-masked]
>             <mailto:[email-masked]>'
>             <[email-masked]
>             <mailto:[email-masked]>>; [email-masked]
>             <mailto:[email-masked]>' <[email-masked]
>             <mailto:[email-masked]>>
>             Cc: [email-masked]' <[email-masked]>; [email-masked]
>             <mailto:[email-masked]>' <[email-masked] <mailto:[email-masked]>>;
>             [email-masked] <mailto:[email-masked]>'
>             <[email-masked] <mailto:[email-masked]>>
>             I mostly agree with you Ron.  I can probably come up with
>             some other variations, but your second point is that the
>             transport must deal with the issue of frame size / fit.
>
>             I would note that if we assume that the carrying encaps
>             (IPv4/v6 outer) is being fragmented, then we are assuming
>             that the exit from service chaining can and will reassemble.
>
>             Yours,
>             Joel
>
>                 SFC-transport/SFC-__fragmentation/SFC-service/__original-packet-or-frame)
>
>                    Ron
>
>
>                 [mailto:[email-masked]
>                 <mailto:[email-masked]>] Sent: Thursday, February
>                 13, 2014 10:10
>                 AM To: [email-masked]
>                 <mailto:[email-masked]>; Dave Dolson;
>                 [email-masked]
>                 <mailto:[email-masked]>'; Ron Parker;
>                 [email-masked] <mailto:[email-masked]>' Cc:
>                 [email-masked]'; [email-masked] <mailto:[email-masked]>';
>                 [email-masked]
>                 <mailto:[email-masked]>' Subject:
>                 Re: [sfc] Framework
>
>                 On 2/13/14, 8:21 AM, [email-masked]
>                 <mailto:[email-masked]> wrote:
>
>                     Re-,
>
>                     (http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02#section-6
>                     <http://tools.ietf.org/html/draft-boucadair-sfc-framework-02#section-6>):
>
>
>
>             "
>
>                         [mailto:[email-masked]
>                         <mailto:[email-masked]>]
>                         jeudi 13 février 2014 13:39 À :
>                         [email-masked]
>                         <mailto:[email-masked]>';
>                         [email-masked]
>                         <mailto:[email-masked]>';
>                         [email-masked] <mailto:[email-masked]>';
>                         [email-masked] <mailto:[email-masked]>' Cc :
>                         [email-masked]'; [email-masked]
>                         <mailto:[email-masked]>';
>                         [email-masked]
>                         <mailto:[email-masked]>' Objet : Re:
>                         [sfc] Framework
>
>                         [mailto:[email-masked]
>                         <mailto:[email-masked]>] Sent:
>                         Thursday, February 13,
>                         2014 04:13 AM To: Ron Parker
>                         <[email-masked]
>                         <mailto:[email-masked]>>;
>                         Dave Dolson; Joel M. Halpern
>                         <[email-masked]
>                         <mailto:[email-masked]>>; Paul Quinn
>                         (paulq) <[email-masked]
>                         <mailto:[email-masked]>> Cc: Sumandra Majee
>                         <[email-masked]>;
>                         [email-masked] <mailto:[email-masked]> <[email-masked]
>                         <mailto:[email-masked]>>; Linda Dunbar
>                         <[email-masked]
>                         <mailto:[email-masked]>>
>                         There is the question of segmentation and
>                         reassembly responsibility
>                         as well.
>
>                         __________________________________________ From:
>                         Ron Parker
>                         [[email-masked]
>                         <mailto:[email-masked]>] Sent:
>                         Wednesday, February 12,
>                         (paulq) Cc: Sumandra Majee; [email-masked]
>                         <mailto:[email-masked]>; Linda Dunbar Subject:
>                         Re: [sfc] Framework
>
>                         Dave,
>
>                         [mailto:[email-masked]
>                         <mailto:[email-masked]>] Sent: Wednesday,
>                         February 12, 2014
>                         Sumandra Majee; [email-masked]
>                         <mailto:[email-masked]>; Linda Dunbar Subject: RE:
>                         [sfc]
>                         Framework
>
>                         The forwarding plane might not even need to look
>                         at the encapsulated
>                         packet.
>
>                         [mailto:[email-masked]
>                         <mailto:[email-masked]>]
>                         Paul Quinn (paulq) Cc: Sumandra Majee;
>                         [email-masked] <mailto:[email-masked]>; Linda Dunbar
>                             I  Agree with your statement.    And if the
>                             total length of the
>                             header is
>
>                             [mailto:[email-masked]
>                             <mailto:[email-masked]>] Sent:
>                             Wednesday, February 12,
>                             Halpern; Sumandra Majee; [email-masked]
>                             <mailto:[email-masked]>; Linda Dunbar Subject:
>                             RE: [sfc] Framework
>
>                             Optional information (if any) is NOT to be
>                             used for forwarding, but
>                             is
>
>                             [mailto:[email-masked]
>                             <mailto:[email-masked]>]
>                             Joel M. Halpern; Sumandra Majee;
>                             [email-masked] <mailto:[email-masked]>; Linda Dunbar
>                             That is why I am proposing a hybrid where
>                             extensions or options can
>                             be
>
>                             [mailto:[email-masked]
>                             <mailto:[email-masked]>] Sent: Wednesday,
>                             February 12, 2014
>                             Halpern; [email-masked] <mailto:[email-masked]>
>                         complexity and cost associated with hardware
>                         support for the
>                         option/EH.
>
>
>                             Paul
>
>                             <[email-masked]
>                             <mailto:[email-masked]>>
>
>                         wrote:
>
>
>                                 Hi, Sumandra.
>
>                                 Regarding service header flexibility, I
>                                 completely agree.   I
>                                 might
>
>                                 [mailto:[email-masked]
>                                 <mailto:[email-masked]>] Sent:
>                                 Wednesday, February 12, 2014
>                                 [email-masked] <mailto:[email-masked]>
>                                 I agree. However the format of service
>                                 header should be
>                                 standardized in
>
>                                 <[email-masked]
>                                 <mailto:[email-masked]>>
>
>                         wrote:
>
>
>                                     Linda,
>
>                                     My interpretation of the
>                                     function chain is built in an
>                                     abstract manner (i.e., SF-A then
>                                     SF-B
>
>                         then SF-C).
>
>                                     [mailto:[email-masked]
>                                     <mailto:[email-masked]>] On
>                                     Behalf Of Linda Dunbar
>                                     Halpern; [email-masked]
>                                     <mailto:[email-masked]> Subject: Re:
>                                     [sfc] Framework
>
>                                     I think a simple sentence below
>                                     should be added Section 5.2 (SFC
>                                     Classifier) to emphasize this point.
>
>                                     [mailto:[email-masked]
>                                     <mailto:[email-masked]>] On
>                                     Behalf Of Joel M. Halpern
>                                     [email-masked] <mailto:[email-masked]>
>                                     Subject: [sfc] Framework
>
>                                     _________________________________________________
>                                     sfc mailing list
>                                     [email-masked] <mailto:[email-masked]>
>                                     https://www.ietf.org/mailman/__listinfo/sfc
>                                     <https://www.ietf.org/mailman/listinfo/sfc>
>
>                                     _________________________________________________
>                                     sfc mailing list
>                                     [email-masked] <mailto:[email-masked]>
>                                     https://www.ietf.org/mailman/__listinfo/sfc
>                                     <https://www.ietf.org/mailman/listinfo/sfc>
>
>                                     _________________________________________________
>                                     sfc mailing list
>                                     [email-masked] <mailto:[email-masked]>
>                                     https://www.ietf.org/mailman/__listinfo/sfc
>                                     <https://www.ietf.org/mailman/listinfo/sfc>
>
>
>                                 _________________________________________________
>                                 sfc mailing list
>                                 [email-masked] <mailto:[email-masked]>
>                                 https://www.ietf.org/mailman/__listinfo/sfc
>                                 <https://www.ietf.org/mailman/listinfo/sfc>
>
>
>                             _________________________________________________
>                             sfc mailing list
>                             [email-masked] <mailto:[email-masked]>
>                             https://www.ietf.org/mailman/__listinfo/sfc
>                             <https://www.ietf.org/mailman/listinfo/sfc>
>
>
>                         _________________________________________________ sfc
>                         mailing list
>                         [email-masked] <mailto:[email-masked]>
>                         https://www.ietf.org/mailman/__listinfo/sfc
>                         <https://www.ietf.org/mailman/listinfo/sfc>
>
>
>
>                         _________________________________________________ sfc
>                         mailing list
>                         [email-masked] <mailto:[email-masked]>
>                         https://www.ietf.org/mailman/__listinfo/sfc
>                         <https://www.ietf.org/mailman/listinfo/sfc>
>
>                         _________________________________________________ sfc
>                         mailing list
>                         [email-masked] <mailto:[email-masked]>
>                         https://www.ietf.org/mailman/__listinfo/sfc
>                         <https://www.ietf.org/mailman/listinfo/sfc>
>
>
>
>
>             _________________________________________________
>             sfc mailing list
>             [email-masked] <mailto:[email-masked]>
>             https://www.ietf.org/mailman/__listinfo/sfc
>             <https://www.ietf.org/mailman/listinfo/sfc>
>
>
>
>
>
>         _________________________________________________
>         sfc mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/sfc
>         <https://www.ietf.org/mailman/listinfo/sfc>
>
>
>

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 13 Feb 2014 19:22:44 +0000

There is draft about transport independent metadata.

http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encoding-01

The complexities you mention are discussed there: variable-encoding,
direction, security of metadata, etc.

Thanks,

-RP

On 2/13/14, 11:15 AM, "Joel M. Halpern" <[email-masked]> wrote:

>>service
>>service

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 13 Feb 2014 14:29:07 -0500

As I understand it, the tsvwg (and aeon) work is about flow metadata. 
That is long-lived metadata of use across many packets.  That does 
indeed seem well-suited to out-of-band cases.

My concern is that in SFC, there are many cases which are at best 
badly-addressed if we insist that they be solved using out-of-band 
metadata.

Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Thu, 13 Feb 2014 19:33:49 +0000

Joel,

I agree.    I think SFC can lend itself to lots of innovation if it is flexible enough to carry metadata flexibly.    Take, Kevin Ma's draft on decomposition of L7 transactions, http://datatracker.ietf.org/doc/draft-ma-sfc-decomposition.   This draft lends itself very well to service-function-specific correlation ID's (perhaps more than 1 in the same packet).   Likewise, in Vancouver, the use cases presentation called out a service-function-specific discard-eligibility conclusion that was conveyed from one SF to another non-adjacent SF.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, February 13, 2014 2:29 PM
To: [email-masked]
Subject: Re: [sfc] Framework

As I understand it, the tsvwg (and aeon) work is about flow metadata. 
That is long-lived metadata of use across many packets.  That does indeed seem well-suited to out-of-band cases.

My concern is that in SFC, there are many cases which are at best badly-addressed if we insist that they be solved using out-of-band metadata.

Yours,
Joel

On 2/13/14, 2:22 PM, Reinaldo Penno (repenno) wrote:
>> While there are cases where out-of-band metadata makes sense, There 
>> are many cases I would not want to try to cover that way.  The best 
>> examples are situations where the metadata changes from packet to 
>> packet (such as the data produced by a DPI engine for consumption by 
>> other applications in the chain.)
>>
>> still very complex if you want to use one correlator to handle 
>> metadata produced by several different entities (the initial 
>> classifer, the DPI engine, ...)  You quickly end up deciding that you 
>> need several correlators.  At which point we are back to variable amounts of metadata.
>>
>> The alternative is to require exceedingly specific and strong 
>> coupling to a mandated out-of-band mechanism.  That seems to me to be 
>> a very bad idea.
>>
>> Yours,
>> Joel
>>
>>> On Thu, Feb 13, 2014 at 1:39 PM, Bruno Rijsman 
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>> (http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02#sec
>>> tion-
>>> 6
>>>
>>>                                          For all of those reasons, I
>>>                                          strongly support a 
>>> canonical service
>>> <mailto:[email-masked]>
>>> <mailto:[email-masked]>
>>> <mailto:[email-masked]>

---

From: Jerome Moisand <[email-masked]>
Date: Thu, 13 Feb 2014 19:35:32 +0000

Joel,

Protocols like GTP and L2TP work exactly that, with a form of session correlator between the data plane and the control plane. This is very handy for subscriber and service management. Also if a correlator is defined as an opaque and unique number, then one can avoid some of the pitfalls you described. Long-lived metadata is clearly useful (and thanks for sharing, Reinaldo, will read), and there is clear applicability to various service chaining needs.

Now this is just one way. The I-D Bruno referred to was just listing this approach as one possible way among others. I totally agree with you that other forms of metadata (like an outcome of the classification of a packet or a sequence of a few packets) may not be suitable for out-of-band signaling. 

Bottomline seems to be that we have too many options to choose from, and none of them solving it all... Tough.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, February 13, 2014 2:29 PM
To: [email-masked]
Subject: Re: [sfc] Framework

Yours,
Joel

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 13 Feb 2014 19:38:13 +0000

>badly-addressed if we insist that they be solved using out-of-band

[RP] The draft only describes the encoding and framework which can be used
in and out of band.

>>>><mailto:[email-masked]>'
>>>><mailto:[email-masked]>'
>>>>              <[email-masked]
>>>>                  encapsulations.   If the transport encapsulation is
>>>>IPv4
>>>>                  or IPv6
>>>>                  * The end-to-end path is known to support the
>>>>resulting
>>>>                  larger frames
>>>>                  There is a related complexity. I hope that we expect
>>>>to
>>>>                  support IPv6.
>>>>(http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02#sectio
>>>>n-
>>>> 6
>>>>
>>>> 
>>>>                      If adding the Service Chaining Header would
>>>>result
>>>>                      in a fragmented
>>>>                      each fragment.  Doing so would prevent SF Nodes
>>>>to
>>>>                      dedicate resource
>>>>                      to handle fragments. "
>>>>
>>>>                      Cheers, Med
>>>>
>>>>
>>>>                          We should design the encapsulation such that
>>>>the
>>>>                          forwarding
>>>>                          independently forwardable; some SFs may
>>>>choose
>>>>                          to ignore these
>>>>                          packets.
>>>>
>>>>                          Any layer 2.5 protocol like VLAN or MPLS
>>>>would
>>>>                          support this.
>>>>                          We could alternatively mandate the inner IP
>>>>be
>>>>                          fragmented and that
>>>><[email-masked]
>>>>                          If we do not enforce a fix header size we
>>>>have
>>>>                          other implication.
>>>>
>>>>                          2014 11:25 PM To: Dave Dolson; Joel M.
>>>>Halpern;
>>>>                          Paul Quinn
>>>>                          function from the SFC-aware service
>>>>function, as
>>>>                          we should.   The
>>>>                          forwarding function is concerned with only
>>>>the
>>>>                          inbound transport
>>>>                          header, the fixed  portion of the service
>>>>header
>>>>                          containing the
>>>>                          service function may look at the entirety of
>>>>the
>>>>                          service header and
>>>>RE:
>>>>                          switch can forward packets of the form:
>>>>Ether |
>>>>                          VLAN | BLOB.
>>>>
>>>>
>>>>
>>>>                          contained in the mandatory portion, the
>>>>hardware
>>>>                          implementation can
>>>>                              The information required for forwarding
>>>>(the
>>>>                              SF Identifier) should
>>>>                              be in
>>>>
>>>>                              Then the forwarding plane, and even the
>>>>PDP,
>>>>                              can be agnostic about
>>>>                              the
>>>>
>>>>                          meta-data.
>>>>
>>>>
>>>>                              -Dave
>>>>
>>>>
>>>>                          added but the total length is contained in
>>>>the
>>>>                          fixed portion.   I
>>>>                          in hardware.   And, I can envision certain
>>>>other
>>>>                          deployments
>>>>                              -----Original Message----- From: Paul
>>>>Quinn
>>>>                              (paulq)
>>>>                              [mailto:[email-masked]
>>>>                              3:40 PM To: Ron Parker Cc: Sumandra
>>>>Majee;
>>>>                              Linda Dunbar; Joel M.
>>>>                              Halpern; [email-masked]
>>>><mailto:[email-masked]>
>>>>                              Ron, your examples of IP options and v6
>>>>EH
>>>>                              have both suffered from
>>>>
>>>>                          flexibility.    If the header had the
>>>>ability to
>>>>                          add extensions
>>>>                          the mandatory part (like IPv4), then a
>>>>hardware
>>>>                          implementation would
>>>>                                          strongly support a canonical
>>>> service
>>>>                          a way that is flexible. Some of us would
>>>>like to
>>>>                          see variable length
>>>>                          represented as a mandotory fixed length
>>>>header
>>>>                          (like IP
>>>>                          header) along with an optional variable
>>>>length
>>>>                          attribute field.
>>>>                                      Separately, a locator table
>>>>provides
>>>>                                      network location for
>>>>                                      a manner appropriate to the type
>>>>of
>>>>                                      transport you are
>>>>                                      identity of a service function
>>>>from
>>>>                                      its network location is
>>>>                                      load balancing.   If, for
>>>>example,
>>>>                                      SF-A had 3 IP addresses,
>>>>                                      that would imply load balancing
>>>>to 3
>>>>                                      instances using IP as a
>>>>                                      transport layer.
>>>>
>>>>strongly
>>>>                                      support a canonical service
>>>>                                      the canonical service header and
>>>>not
>>>>                                      on the
>>>>
>>>>                          fields
>>>>
>>>>                                      in the transport header.   That
>>>>is,
>>>>                                      the SFC node discards
>>>>                                      to discuss, the SFC node knows
>>>>how
>>>>                                      to interpret the chain ID and
>>>>                                      Sent: Wednesday, February 12,
>>>>2014
>>>>                                      12:01 PM To: Joel M.
>>>>                                      Halpern; [email-masked]
>>>>                                      "A Service Chain Classifier node
>>>>can
>>>>                                      associate a unique Layer 2
>>>>                                      or 3 Label (e.g. VLAN, MPLS 
>>>>label)
>>>>                                      to the packets in the flow.
>>>>                                      Sent: Wednesday, February 12, 
>>>>2014
>>>>                                      10:20 AM To:
>>>>                                      [email-masked] 
>>>><mailto:[email-masked]>
>>>>                                      Subject: [sfc] Framework
>>>>
>>>>                                      specific model of the scope of 
>>>>the
>>>>                                      transport header (that it is
>>>>                                      derived from, and relates only 
>>>>to,
>>>>                                      the first service function to
>>>>                                      which the packet will be 
>>>>directed.
>>>>                                      However, I would like to allow 
>>>>other
>>>>                                      transport operational
>>>>                                      models, such as the use of a 
>>>>VLAN to
>>>>                                      direct traffic along a
>>>>                                      chain.  Or the use of an MPLS 
>>>>label,
>>>>                                      or an MPLS label stack.
>>>>
>>>>                                      Yours, Joel M. Halpern
>>>>
>>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 13 Feb 2014 14:51:37 -0500

I know very well what GTP does in terms of correlators, and why.
If all you need is an identifier for the subscriber, carrying a short 
identifier, and using it to select the desired behavior that has been 
pre-populated when the subscribers session starts works really well.
That is part of why I am not objecting to having provision for 
out-of-band metadata.

However, claiming that a single such correlator is all that is needed 
for even 80% of SFC cases (and I very much supporting trying to focus on 
the 80% cases), just does not seem to work, given the broad range of 
requirements that we have seen.

Yours,
Joel

---

From: Sumandra Majee <[email-masked]>
Date: Thu, 13 Feb 2014 20:51:12 +0000

I believe most of us agree that an out of bad signalling will not address the majority of requirement. Also a typical http flow carries many transactions and each can have different or additional classification. So a metadata can not be simple connected with one flow either. Current implementations of proxies and load balancers has addressed this in many ways including custome header insertion. The custom header in this case equivalent of metadata vector. 

I think we need an efficient way annotate actual data with inline metadata. I also strongly believe in solving the 80% of the use case

Regards
Sumandra
________________________________________
From: sfc [[email-masked]] on behalf of Joel M. Halpern [[email-masked]]
Sent: Thursday, February 13, 2014 11:51 AM
To: Jerome Moisand; [email-masked]
Subject: Re: [sfc] Framework

Yours,
Joel

---

From: Kevin J Ma <[email-masked]>
Date: Thu, 13 Feb 2014 16:11:31 -0500

Sumandra,

  When you say custom headers, do you mean custom message (e.g., HTTP)
  headers, or packet headers?  Placing message-level metadata into
  every packet would not seem to me to be a good use of SFC metadata?
  For a mult-megabyte file, a kilobyte of metadata, relative to the
  file size might be reasonable, however, relative to each packet sent
  for that file, the overhead would not make sense?

  Note: HTTP header insertion is still in-band metadata, it's just may
        not be of any concern to SFC?

--  Kevin J. Ma

> From: sfc [mailto:[email-masked]] On Behalf Of Sumandra Majee
> Sent: Thursday, February 13, 2014 3:51 PM
> To: Joel M. Halpern; Jerome Moisand; [email-masked]
> I believe most of us agree that an out of bad signalling will not address
> the majority of requirement. Also a typical http flow carries many
> transactions and each can have different or additional classification. So
> a metadata can not be simple connected with one flow either. Current
> implementations of proxies and load balancers has addressed this in many
> ways including custome header insertion. The custom header in this case
> equivalent of metadata vector.
>
> I think we need an efficient way annotate actual data with inline
> metadata. I also strongly believe in solving the 80% of the use case
>
> Regards
> Sumandra
> > Protocols like GTP and L2TP work exactly that, with a form of session
> correlator between the data plane and the control plane. This is very
> handy for subscriber and service management. Also if a correlator is
> defined as an opaque and unique number, then one can avoid some of the
> pitfalls you described. Long-lived metadata is clearly useful (and thanks
> for sharing, Reinaldo, will read), and there is clear applicability to
> various service chaining needs.
> >
> > Now this is just one way. The I-D Bruno referred to was just listing
> this approach as one possible way among others. I totally agree with you
> that other forms of metadata (like an outcome of the classification of a
> packet or a sequence of a few packets) may not be suitable for out-of-band
> signaling.
> >
> > My concern is that in SFC, there are many cases which are at best badly-
> addressed if we insist that they be solved using out-of-band metadata.
> >
> > Yours,
> > Joel
> >
> >>>>               The fragmenting also puts huge performance burden on
> the
> >>>>               service functions.
> >>>>                   That is an excellent point to consider when
> choosing
> >>>>                   transport
> >>>>                   * A path discovery mechanism is mandated by SFC
> when
> >>>>                   non-IP transports
> >>>>                   There is a related complexity. I hope that we
> expect to
> >>>>                   support IPv6.
> >>>>                           We should design the encapsulation such
> that the
> >>>>                           forwarding
> >>>>                           Otherwise, a reassembly layer could be
> added
> >>>>                           after the forwarding
> >>>>                           coordinates. Think of something like the
> IPv6
> >>>>                           reassembly option
> >>>>                           If adding length to the service header
> forces
> >>>>                           segmentation, then
> >>>>                           whose responsibility is it to reassemble
> the
> >>>>                           payload before passing
> >>>>                           it to the SF.
> >>>>
> >>>>                           chain information, and the outbound
> transport
> >>>>                           header.    The
> >>>>                           service function may look at the entirety
> of the
> >>>>                           service header and
> >>>>                           5:18 PM To: Joel M. Halpern; Ron Parker;
> Paul
> >>>>                           Quinn (paulq) Cc:
> >>>>                           For example, (if the SF Identifier is a
> VLAN
> >>>>                           tag), an Ethernet
> >>>>                           Wednesday, February 12, 2014 4:30 PM To:
> Ron
> >>>>                           Parker; Dave Dolson;
> >>>>                               Wednesday, February 12, 2014 4:05 PM
> To:
> >>>>                               Paul Quinn (paulq) Cc:
> >>>>                           (e.g., 3gpp) where the extension headers
> add
> >>>>                           sufficient value to
> >>>>                               We certainly need to be very careful
> with
> >>>>                               variable length headers
> >>>>                               when
> >>>>
> >>>>                           be free to skip over the extensions (in
> cases
> >>>>                           where the deployment
> >>>>                                   3:04 PM To: Ron Parker; Linda
> Dunbar;
> >>>>                                   Joel M. Halpern;
> >>>>                                           header that is independent
> of
> >>>>                                           the transport methodology.
> >>>>
> >>>>
> >>>>
> >>>>                           header that is also HW friendly. The
> service
> >>>>                           header can be
> >>>>                           example subscriber ID could be of interest
> in
> >>>>                           the mobile core
> >>>>                           service chain only.
> >>>>
> >>>>
> >>>>                                   Sumandra
> >>>>
> >>>>                                       each of those service
> functions.
> >>>>                                       In this way, you can
> >>>>                                       a manner appropriate to the
> type of
> >>>>                                       transport you are
> >>>>                                       GRE tunnel remote IP + key,
> etc.,
> >>>>                                       you can do that.    You
> that
> >>>>                                       header that is independent of
> the
> >>>>                                       transport
> >>>>                                       where to go next should be
> based
> >>>>                                       solely on information carried
> in
> >>>>                                       the canonical service header
> and not
> >>>>                                       on the
> >>>>
> >>>>                           fields
> >>>>
> >>>>                                       the transport header and
> extracts
> >>>>                                       the chain ID from the
> >>>>                                       service header.    Through
> >>>>                                       mechanisms we have not yet
> begun
> On
> >>>>                                       "A Service Chain Classifier
> node can
> >>>>                                       Those Layer 2 or 3 Label makes
> it
> >>>>                                       easier for subsequent nodes
> >>>>                                       along the flow path to steer
> the
> >>>>                                       flow to the service functions
> >>>>                                       Linda -----Original Message----
> -
> >>>>                                       From: sfc
> On
> very

---

From: Ron Parker <[email-masked]>
Date: Thu, 13 Feb 2014 21:17:40 +0000

Just a thought, here, but what about an inband scheme for long lived metadata that is optimized for bidirectional chains?    A node that inserts metadata in the forward direction would continue inserting until it saw its metadata echoed back in the reverse direction (i.e., an implicit ack).

    Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Kevin J Ma
Sent: Thursday, February 13, 2014 4:12 PM
To: Sumandra Majee; Joel M. Halpern; Jerome Moisand; [email-masked]
Subject: Re: [sfc] Framework

Sumandra,

--  Kevin J. Ma

> I believe most of us agree that an out of bad signalling will not 
> address the majority of requirement. Also a typical http flow carries 
> many transactions and each can have different or additional 
> classification. So a metadata can not be simple connected with one 
> flow either. Current implementations of proxies and load balancers has 
> addressed this in many ways including custome header insertion. The 
> custom header in this case equivalent of metadata vector.
>
> for even 80% of SFC cases (and I very much supporting trying to focus 
> on the 80% cases), just does not seem to work, given the broad range 
> of requirements that we have seen.
>
> Yours,
> Joel
>
> pitfalls you described. Long-lived metadata is clearly useful (and 
> thanks for sharing, Reinaldo, will read), and there is clear 
> applicability to various service chaining needs.
> >
> this approach as one possible way among others. I totally agree with 
> you that other forms of metadata (like an outcome of the 
> classification of a packet or a sequence of a few packets) may not be 
> suitable for out-of-band signaling.
> >
> > Bottomline seems to be that we have too many options to choose from, 
> > and
> none of them solving it all... Tough.
> >
> > badly-
> >> http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encodi
> >> ng-
> >> 01
> >>
> >> The complexities you mention are discussed there: 
> >> variable-encoding, direction, security of metadata, etc.
> >>
> >> Thanks,
> >>
> >> -RP
> >>
> >>
> >>> While there are cases where out-of-band metadata makes sense, 
> >>> There are many cases I would not want to try to cover that way.  
> >>> The best examples are situations where the metadata changes from 
> >>> packet to packet (such as the data produced by a DPI engine for 
> >>> consumption by other applications in the chain.)
> >>>
> >>> More importantly, if you are putting correlators in the packet, it 
> >>> is still very complex if you want to use one correlator to handle 
> >>> classifer, the DPI engine, ...)  You quickly end up deciding that 
> >>> you need several correlators.  At which point we are back to 
> >>> variable
> amounts of metadata.
> >>>
> >>> coupling to a mandated out-of-band mechanism.  That seems to me to 
> >>> be a very bad idea.
> >>>
> >>> Yours,
> >>> Joel
> >>>
> >>>>       There are ways to signal variable length amounts of 
> >>>> metadata
> without
> >>>>       draft-rijsman-sfc-metadata-considerations-00 discusses some 
> >>>> of
> the
> >>>>       correlator and out-of-band additional metadata.  See 
> >>>> sections
> 3.3,
> >>>>               Yes, fragmentation and variable headers are usually 
> >>>> a
> really
> >>>>               bad thing for forwarding performance. Let's not 
> >>>> forget
> that
> >>>>               variable-length fields might be a better candidate 
> >>>> for
> some
> >>>>               sounds likely. Not 100% sure this is true for all 
> >>>> use
> cases
> >>>>               rather than fragmenting every large packet. The is 
> >>>> why
> TCP
> >>>>               adopted it so early on.
> >>>>
> >>>>               mean the client or server is informed that its 
> >>>> packets
> are
> >>>>               Some operators may wish to incur the extra cost to 
> >>>> hide
> the
> >>>>               existence of the tunneling, when the elements of 
> >>>> the
> chain
> >>>>               I mostly agree with you Ron.  I can probably come 
> >>>> up
> with
> >>>>               some other variations, but your second point is 
> >>>> that
> the
> >>>> SFC-transport/SFC-__fragmentation/SFC-service/__original-packet-o
> >>>> r-f
> >>>> rame)
> >>>>
> >>>>                      Ron
> >>>>
> >>>>
> >>>> <http://tools.ietf.org/html/draft-boucadair-sfc-framework-02#sect
> >>>> ion-
> 6>):
> >>>>
> >>>>
> >>>>
> >>>>               "
> >>>>
> >>>>                           The forwarding plane might not even 
> >>>> need to
> look
> >>>>                           at the encapsulated
> >>>>                           packet.
> >>>>
> >>>>                           [email-masked] <mailto:[email-masked]>; 
> >>>> Linda
> Dunbar
> >>>>                               -----Original Message----- From: 
> >>>> Dave
> Dolson
> >>>>                               Optional information (if any) is 
> >>>> NOT to
> be
> >>>>                               used for forwarding, but
> >>>>                               is
> >>>>
> >>>>                                       My interpretation of the
> >>>>                                       architecture docs is that 
> >>>> the service
> >>>>                                       Classifier) to emphasize 
> >>>> this
> point.
> >>>>                                       I was looking at the framework
> >>>>                                       proposal. The proposal has 
> >>>> a
> very

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 14 Feb 2014 00:18:48 +0000

I see two types of "metadata" being discussed here:

 1. The "flow metadata", like the transactions carried by http flows. They are inserted by applications, or inserted by a service function to pass some "cookies" to the next one. (many proxy based service functions have those capability)

 2. The "Service Chain metadata", that are inserted by "Chain Classifier" or control plane to carry extra information (in additional to Chain ID) for the purpose of controlling the sequence of functions on a chain. 

Correct? 

IMHO, the first bullet above are specific to applications or service functions internal processing. Many of today's proxy based service functions make changes to data packets, some of them make those changes for other service functions. Those changes won't be in the Service Chain Header field. 

Linda

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Sumandra Majee
Sent: Thursday, February 13, 2014 2:51 PM
To: Joel M. Halpern; Jerome Moisand; [email-masked]
Subject: Re: [sfc] Framework

Regards
Sumandra

I know very well what GTP does in terms of correlators, and why.
If all you need is an identifier for the subscriber, carrying a short identifier, and using it to select the desired behavior that has been pre-populated when the subscribers session starts works really well.
That is part of why I am not objecting to having provision for out-of-band metadata.

However, claiming that a single such correlator is all that is needed for even 80% of SFC cases (and I very much supporting trying to focus on the 80% cases), just does not seem to work, given the broad range of requirements that we have seen.

Yours,
Joel

On 2/13/14, 2:35 PM, Jerome Moisand wrote:
>> http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encoding
>> -
>> 01
>>
>>> you need several correlators.  At which point we are back to variable amounts of metadata.
>>>
>>>> SFC-transport/SFC-__fragmentation/SFC-service/__original-packet-or-
>>>> f
>>>> rame)
>>>>
>>>>                      Ron
>>>>
>>>>
>>>> Linda Dunbar
>>>>                                   Sumandra Majee
>>>>                                       architecture docs is that the 
>>>> service
>>>>                                       proposal. The proposal has a very

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 13 Feb 2014 19:25:06 -0500

I only consider the first of those to be metadata.  The chain 
identification in the service chaining header or the transport header 
are not metadata.  Treating fields which are needed for steering as 
metadata induces massive confusion.  can we please keep those two 
concepts separate?!

Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Fri, 14 Feb 2014 00:33:05 +0000

Linda,

Also, let's please separate "applications" and "service functions".   I view "applications" as things that are explicitly addressed, like an Apache Server that realizes some web service -- no SFC steering was necessary to cause packets to reach it.    "Service functions", on the other hand and purely from an SFC perspective, are transparent mid-boxes that would not have normally been part of the data path unless special steering mechanisms were applied or certain forced topologies were present in the network.    Metadata, for SFC, is information above and beyond that required for proper steering that is passed amongst and between the SFC classifier(s) and the SFC service functions.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, February 13, 2014 7:25 PM
To: Linda Dunbar; [email-masked]
Subject: Re: [sfc] Framework

I only consider the first of those to be metadata.  The chain identification in the service chaining header or the transport header are not metadata.  Treating fields which are needed for steering as metadata induces massive confusion.  can we please keep those two concepts separate?!

Yours,
Joel

On 2/13/14, 7:18 PM, Linda Dunbar wrote:
>   1. The "flow metadata", like the transactions carried by http flows. 
> They are inserted by applications, or inserted by a service function 
> to pass some "cookies" to the next one. (many proxy based service 
> functions have those capability)
>
>>>> packet (such as the data produced by a DPI engine for consumption 
>>>> by other applications in the chain.)
>>>>
>>>>> (http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02#s
>>>>> e
>>>>> c
>>>>> tion-
>>>>> 6
>>>>>

---

From: Nicolas BOUTHORS <[email-masked]>
Date: Fri, 14 Feb 2014 08:27:41 +0000

Hello Ron,

I agree on your statement that Metadata is beyond that required for proper steering, given we have
addressable applications or transparent mid-boxes.

What about Transparent proxies, used for header insertion? They are not explicitly addresses and are not transparent middle boxes as they terminate a tcp connection on one side, and create one on the other.

They are quite common and they should be address via ad'hoc mechanisms as you pointed out in a 
previous message, similarly to the issue of revealing Host Id discussed in RFC 6967. 

I am just concerned to keep them in scope of what sfc should cover.

Nicolas
________________________________________
From: Ron Parker [[email-masked]]
Sent: Friday, February 14, 2014 1:33 AM
To: Joel M. Halpern; Linda Dunbar; [email-masked]
Subject: Re: [sfc] Framework

Linda,

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, February 13, 2014 7:25 PM
To: Linda Dunbar; [email-masked]
Subject: Re: [sfc] Framework

Yours,
Joel

---

From: Bruno Rijsman <[email-masked]>
Date: Thu, 13 Feb 2014 13:39:18 -0500

draft-rijsman-sfc-metadata-considerations-00 discusses some of the possible
approaches: out-of-band signaling (congruent or non-congruent) or a hybrid
approach using a fix-length in-band correlator and out-of-band additional
metadata.  See sections 3.3, 3.4 and 3.5 in the draft.

On Thu, Feb 13, 2014 at 1:16 PM, Joel M. Halpern <[email-masked]>wrote:

> I think the approach of a fixed length initial part, and a variable length
> extension part, is the right model.
>
> Yours,
> Joel
>
>
>> For example, the type of metadata that may require variable-length fields
>> might be a better candidate for some out-of-band signaling mechanism. If
>> this is service authorization data (e.g. a service profile/policy), this
>> sounds likely. Not 100% sure this is true for all use cases though. Only a
>> good understanding of use cases, grounded by reflecting on existing network
>> architectures (notably broadband, fixed or mobile), would tell us if one
>> approach or another is the most appropriate.
>>

---

From: Ron Parker <[email-masked]>
Date: Fri, 14 Feb 2014 13:44:30 +0000

Nicolas,

By transparent, I meant solely that it is not addressed by the endpoints of the communication.   I did not intend to mean that it didn't change the packets or flows.    Perhaps I should have said simply midboxes to mean this.

   Ron

-----Original Message-----
From: Nicolas BOUTHORS [mailto:[email-masked]] 
Sent: Friday, February 14, 2014 3:28 AM
To: Ron Parker; [email-masked]
Subject: RE: [sfc] Framework

Hello Ron,

I agree on your statement that Metadata is beyond that required for proper steering, given we have addressable applications or transparent mid-boxes.

They are quite common and they should be address via ad'hoc mechanisms as you pointed out in a previous message, similarly to the issue of revealing Host Id discussed in RFC 6967. 

Nicolas

Linda,

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, February 13, 2014 7:25 PM
To: Linda Dunbar; [email-masked]
Subject: Re: [sfc] Framework

Yours,
Joel

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 14 Feb 2014 14:06:42 +0000

Yes agreed Joel. Metadata is really ³context² that is consumable by any
element of a given SFC. While our SFC encapsulation will of course carry
information relevant to the steering of traffic through the desired set of
service functions, I would not characterize that as metadata.

On 2/13/14, 7:25 PM, "Joel M. Halpern" <[email-masked]> wrote:

>>They are inserted by applications, or inserted by a service function to
>>pass some "cookies" to the next one. (many proxy based service functions
>>have those capability)
>>
>>   2. The "Service Chain metadata", that are inserted by "Chain
>>Classifier" or control plane to carry extra information (in additional
>>to Chain ID) for the purpose of controlling the sequence of functions on
>>a chain.
>>
>> Correct?
>>
>> IMHO, the first bullet above are specific to applications or service
>>functions internal processing. Many of today's proxy based service
>>functions make changes to data packets, some of them make those changes
>>for other service functions. Those changes won't be in the Service Chain
>>Header field.
>>
>> Linda
>>
>>
>>
>>
>>
>>classification. So a metadata can not be simple connected with one flow
>>either. Current implementations of proxies and load balancers has
>>>you that other forms of metadata (like an outcome of the classification
>>>of a packet or a sequence of a few packets) may not be suitable for
>>>out-of-band signaling.
>>>
>>>and none of them solving it all... Tough.
>>>
>>>>>variable amounts of metadata.
>>>>>
>>>>>>sections 3.3,
>>>>>>a really
>>>>>>forget that
>>>>>>for some
>>>>>>use cases
>>>>>>                Anyhoo, we're jumping way deep in the detailed
>>>>>>protocol
>>>>>>                design here. This seems a tad premature.
>>>>>>
>>>>>>[email-masked]
>>>>>>why TCP
>>>>>>packets are
>>>>>>hide the
>>>>>>                    encapsulations.   If the transport encapsulation
>>>>>>is IPv4
>>>>>>                    or IPv6
>>>>>>                    transport encapsulation is VLAN, MPLS, etc.,
>>>>>>then I
>>>>>>                    believe one of the
>>>>>>                    following must be true:
>>>>>>
>>>>>>                    are used * An SFC-specific fragmentation header
>>>>>>and
>>>>>>                    mechanisms must be
>>>>>>                    defined (i.e.,
>>>>>>
>>>>>>                        packet, the classifier should include a
>>>>>>Service
>>>>>>                        Chaining Header in
>>>>>>                        each fragment.  Doing so would prevent SF
>>>>>>Nodes to
>>>>>>                        dedicate resource
>>>>>>                        to handle fragments. "
>>>>>>
>>>>>>                        Cheers, Med
>>>>>>
>>>>>>
>>>>>>                            We could alternatively mandate the inner
>>>>>>IP be
>>>>>>                            fragmented and that
>>>>>>                            If we do not enforce a fix header size
>>>>>>we have
>>>>>>                            other implication.
>>>>>>
>>>>>>                            forwarding function is concerned with
>>>>>>only the
>>>>>>                            inbound transport
>>>>>>                            header, the fixed  portion of the
>>>>>>service header
>>>>>>                            containing the
>>>>>>                            service function may look at the
>>>>>>entirety of the
>>>>>>                            service header and
>>>>>>Dave Dolson
>>>>>>                                2014 4:10 PM To: Ron Parker; Paul
>>>>>>Quinn
>>>>>>                                (paulq) Cc: Joel M.
>>>>>>                                The information required for
>>>>>>forwarding (the
>>>>>>                                SF Identifier) should
>>>>>>                                be in
>>>>>>
>>>>>>                                Then the forwarding plane, and even
>>>>>>the PDP,
>>>>>>                                can be agnostic about
>>>>>>                                the
>>>>>>
>>>>>>                            meta-data.
>>>>>>
>>>>>>
>>>>>>                                -Dave
>>>>>>
>>>>>>
>>>>>>                            added but the total length is contained
>>>>>>in the
>>>>>>                            fixed portion.   I
>>>>>>                            in hardware.   And, I can envision
>>>>>>certain other
>>>>>>                            deployments
>>>>>>                                Ron, your examples of IP options and
>>>>>>v6 EH
>>>>>>                                have both suffered from
>>>>>>
>>>>>>                            (perhaps similar to IPv6) but also had
>>>>>>the
>>>>>>                            header length encoded in
>>>>>>                            example subscriber ID could be of 
>>>>>>interest in
>>>>>>                            the mobile core
>>>>>>                            service chain only.
>>>>>>
>>>>>>
>>>>>>                                    Sumandra
>>>>>>
>>>>>>                                        using.   If you want that to 
>>>>>>be
>>>>>>                                        interface+VLAN,
>>>>>>                                        identity of a service 
>>>>>>function from
>>>>>>                                        that would imply load 
>>>>>>balancing to 3
>>>>>>                                        methodology.    At a 
>>>>>>particular
>>>>>>                                        node, the decision as to
>>>>>>                                        solely on information 
>>>>>>carried in
>>>>>>                                        in the transport header.   
>>>>>>That is,
>>>>>>                                        to discuss, the SFC node 
>>>>>>knows how
>>>>>>                                        Sent: Wednesday, February 
>>>>>>12, 2014
>>>>>>                                        12:01 PM To: Joel M.
>>>>>>                                        Halpern; [email-masked]
>>>>>>                                        <mailto:[email-masked]> 
>>>>>>Subject: Re:
>>>>>>                                        [sfc] Framework
>>>>>>
>>>>>>this point.
>>>>>>                                        Those Layer 2 or 3 Label 
>>>>>>makes it
>>>>>>                                        Linda -----Original 
>>>>>>Message-----
>>>>>>                                        Sent: Wednesday, February 
>>>>>>12, 2014
>>>>>>                                        10:20 AM To:
>>>>>>                                        [email-masked] 
>>>>>><mailto:[email-masked]>
>>>>>>                                        Subject: [sfc] Framework
>>>>>>
>>>>>>                                        I was looking at the 
>>>>>>framework
>>>>>>                                        specific model of the scope 
>>>>>>of the
>>>>>>                                        derived from, and relates 
>>>>>>only to,
>>>>>>                                        That is clearly an 
>>>>>>operational
>>>>>>                                        However, I would like to 
>>>>>>allow other
>>>>>>                                        chain.  Or the use of an

---

From: Jerome Moisand <[email-masked]>
Date: Fri, 14 Feb 2014 15:39:56 +0000

Jim, Joel, glad to hear you guys express such views. 

This was a key point we were trying to convey in draft-rijsman-sfc-metadata-considerations (section 4.8 and conclusion). See the figure below:

                         .................
                         . Service Node  .
                         .               .
   +-----------+         . +-----------+ .   +-----------+   \
   | Service   |         . | Virtual   | .   | Physical  |   | Service
   | Classifier|         . | Service   | .   | Service   |   | Function
   |           |         . | Function  | .   | Function  |   | Layer
   |           |         . +-----------+ .   +-----------+   /
   |           |         .    |     |    .      |     |
   |           |         . +-----------+ .   +-----------+   \
   |           |         . | vSwitch   | .   | Proxy     |   | Service
   |           |===========|   or      |=====|   or      |== | Path
   |           | Overlay . | vRouter   | .   | Gateway   |   | Layer
   +-----------+ Tunnel  . +-----------+ .   +-----------+   /
         |               ........|........         |
         |                       |                 |
   +-----------+           +-----------+     +-----------+   \
   | Underlay  |           | Underlay  |     | Underlay  |   | Network
   | Switch or |-----------| Switch or |-----| Switch or |-- | Layer
   | Router    |           | Router    |     | Router    |   |
   +-----------+           +-----------+     +-----------+   /

                             Figure 8: Layers

So yes, there are TWO layers here (to map Jim's words, steering is in the service path layer; exchanging context is in the service function layer). And they probably should be thought about more independently that what we've seen so far in various encoding proposals.

Anyway, irrespective of the solution, it seems that the problem statement needs to be improved a tad to better convey those two aspects more independently. Let me try to make a rewording proposal on the corresponding e-mail thread later today...

Tx
Jerome

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, February 14, 2014 9:07 AM
To: Joel M. Halpern; Linda Dunbar; [email-masked]
Subject: Re: [sfc] Framework

Yes agreed Joel. Metadata is really ³context² that is consumable by any element of a given SFC. While our SFC encapsulation will of course carry information relevant to the steering of traffic through the desired set of service functions, I would not characterize that as metadata.

On 2/13/14, 7:25 PM, "Joel M. Halpern" <[email-masked]> wrote:

>>to Chain ID) for the purpose of controlling the sequence of functions 
>>on a chain.
>>
>> Correct?
>>
>>functions make changes to data packets, some of them make those 
>>changes for other service functions. Those changes won't be in the 
>>Service Chain Header field.
>>
>> Linda
>>
>>
>>
>>
>>
>>> Protocols like GTP and L2TP work exactly that, with a form of 
>>>session correlator between the data plane and the control plane. This 
>>>is very handy for subscriber and service management. Also if a 
>>>correlator is defined as an opaque and unique number, then one can 
>>>avoid some of the pitfalls you described. Long-lived metadata is 
>>>clearly useful (and thanks for sharing, Reinaldo, will read), and 
>>>there is clear applicability to various service chaining needs.
>>>
>>>> ng
>>>>>>metadata without
>>>>>>                The fragmenting also puts huge performance burden 
>>>>>>on the
>>>>>>                service functions.
>>>>>>the chain
>>>>>>up with
>>>>>>                    * A path discovery mechanism is mandated by 
>>>>>>SFC when
>>>>>>                    non-IP transports
>>>>>>                    are used * An SFC-specific fragmentation 
>>>>>>header and
>>>>>>                    mechanisms must be
>>>>>>                    defined (i.e.,
>>>>>>
>>>>>> r-
>>>>>> (http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02#
>>>>>> se
>>>>>> c
>>>>>> tion-
>>>>>> 6
>>>>>>
>>>>>> 
>>>>>><http://tools.ietf.org/html/draft-boucadair-sfc-framework-02#secti
>>>>>>on-
>>>>>>6>):
>>>>>>
>>>>>>
>>>>>>
>>>>>>                "
>>>>>>
>>>>>>                        If adding the Service Chaining Header 
>>>>>>would result
>>>>>>                        in a fragmented
>>>>>><mailto:[email-masked]>' Cc :
>>>>>>Objet
>>>>>>: Re:
>>>>>>                            We should design the encapsulation 
>>>>>>such that the
>>>>>>                            forwarding
>>>>>>                            independently forwardable; some SFs 
>>>>>>may choose
>>>>>>                            to ignore these
>>>>>>                            packets.
>>>>>>
>>>>>>                            Any layer 2.5 protocol like VLAN or 
>>>>>>MPLS would
>>>>>>                            support this.
>>>>>>                            We could alternatively mandate the 
>>>>>>inner IP be
>>>>>>                            fragmented and that
>>>>>>                            whose responsibility is it to 
>>>>>>reassemble the
>>>>>>                            payload before passing
>>>>>>                            it to the SF.
>>>>>>
>>>>>>                            5:18 PM To: Joel M. Halpern; Ron 
>>>>>>Parker; Paul
>>>>>>                            Quinn (paulq) Cc:
>>>>>>need to look
>>>>>>                            For example, (if the SF Identifier is 
>>>>>>a VLAN
>>>>>>                            tag), an Ethernet
>>>>>>                            contained in the mandatory portion, 
>>>>>>the hardware
>>>>>>                            implementation can
>>>>>>                                <mailto:[email-masked]>; Linda 
>>>>>>Dunbar
>>>>>>Subject:
>>>>>>                                RE: [sfc] Framework
>>>>>>
>>>>>>NOT to be
>>>>>>                                Then the forwarding plane, and 
>>>>>>even the PDP,
>>>>>>                                can be agnostic about
>>>>>>                                the
>>>>>>
>>>>>>                            meta-data.
>>>>>>
>>>>>>
>>>>>>                                -Dave
>>>>>>
>>>>>>
>>>>>><mailto:[email-masked]>;  Linda Dunbar
>>>>>>                            added but the total length is 
>>>>>>contained in the
>>>>>>                            fixed portion.   I
>>>>>>                            (e.g., 3gpp) where the extension 
>>>>>>headers add
>>>>>>                            sufficient value to
>>>>>>                                3:40 PM To: Ron Parker Cc: 
>>>>>>Sumandra Majee;
>>>>>>                                Linda Dunbar; Joel M.
>>>>>>                                Halpern; [email-masked] 
>>>>>><mailto:[email-masked]>
>>>>>>                                We certainly need to be very 
>>>>>>careful with
>>>>>>                                variable length headers
>>>>>>                                when
>>>>>>
>>>>>>                            be free to skip over the extensions 
>>>>>>(in cases
>>>>>>                            where the deployment
>>>>>>                            a way that is flexible. Some of us 
>>>>>>would like to
>>>>>>                            see variable length
>>>>>>                            represented as a mandotory fixed 
>>>>>>length header
>>>>>>                            (like IP
>>>>>>                            header) along with an optional 
>>>>>>variable length
>>>>>>                            attribute field.
>>>>>>                                        Separately, a locator 
>>>>>>table provides
>>>>>>                                        a manner appropriate to 
>>>>>>the type of
>>>>>>                                        GRE tunnel remote IP + 
>>>>>>key, etc.,
>>>>>>                                        can even potentially locate
>>>>>>                                        different service 
>>>>>>functions that
>>>>>>                                        For all of those reasons, 
>>>>>>I strongly
>>>>>>                                        the canonical service 
>>>>>>header and not
>>>>>>From: sfc
>>>>>>                                        "A Service Chain 
>>>>>>Classifier node can
>>>>>>                                        along the flow path to 
>>>>>>steer the
>>>>>>                                        From: sfc
>>>>>>a very
>>>>>>                                        specific model of the 
>>>>>>scope of the
>>>>>>                                        models, such as the use of 
>>>>>>a VLAN to
>>>>>>                                        direct traffic along a
>>>>>>                                        chain.  Or the use of an 
>>>>>>MPLS label,
>>>>>>                                        or an MPLS label stack.
>>>>>>
>>>>>>                                        Yours, Joel M. Halpern
>>>>>>
>>>>>>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 14 Feb 2014 15:51:23 +0000

Hi Jerome,

I think http://datatracker.ietf.org/doc/draft-quinn-sfc-arch/ points this
out pretty well - see section 3.2 and the descriptions for “Service
Function Forwarder” and “SFC Network Forwarder”. Welcome your comments.

On 2/14/14, 10:39 AM, "Jerome Moisand" <[email-masked]> wrote:

>This was a key point we were trying to convey in
>draft-rijsman-sfc-metadata-considerations (section 4.8 and conclusion).
>See the figure below:
>
>                         .................
>                         . Service Node  .
>                         .               .
>So yes, there are TWO layers here (to map Jim's words, steering is in the
>service path layer; exchanging context is in the service function layer).
>And they probably should be thought about more independently that what
>we've seen so far in various encoding proposals.
>
>Anyway, irrespective of the solution, it seems that the problem statement
>needs to be improved a tad to better convey those two aspects more
>independently. Let me try to make a rewording proposal on the
>corresponding e-mail thread later today...
>
>Tx
>Jerome
>
>information relevant to the steering of traffic through the desired set
>of service functions, I would not characterize that as metadata.
>
>>>>>>>                        FWIW, one of the existing architecture
>>>>>>>drafts
>>>>>>>                        includes the following
>>>>>>>                        behavior
>>>>>>>
>>>>>>>                            functions do not need to reassemble.
>>>>>>>Each
>>>>>>>                            fragment should be
>>>>>>>                            Yes, that is a good point if we
>>>>>>>logically
>>>>>>>                            separate the forwarding
>>>>>>>Subject: RE:
>>>>>>>                            significant implementation and 
>>>>>>>deployment
>>>>>>>                            hurdles due to the
>>>>>>>                                        reside in the same chain 
>>>>>>>                                        different flavors of
>>>>>>>                                        network locators.    Another
>>>>>>>                                        justification to separate 
>>>>>>>the
>>>>>>>                                        identity of a service 
>>>>>>>function from
>>>>>>>                                        its network location is
>>>>>>>                                        load balancing.   If, for 
>>>>>>>example,
>>>>>>>                                        SF-A had 3 IP addresses,
>>>>>>>                                        that would imply load 
>>>>>>>balancing to 3
>>>>>>>                                        instances using IP as a
>>>>>>>                                        transport layer.
>>>>>>>

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 14 Feb 2014 15:57:32 +0000

Jim, 

Just to clarify, if you agree with what Joel said, then the "context is consumable by SF", instead of "SFC" correct?

In that case, should this "metadata that are consumable by SF" be out of the scope of SFC? 

Those metadata are inserted/consumed by applications or SFs, they are really the internal processing within applications & related service functions. 

Linda

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Friday, February 14, 2014 8:07 AM
To: Joel M. Halpern; Linda Dunbar; [email-masked]
Subject: Re: [sfc] Framework

On 2/13/14, 7:25 PM, "Joel M. Halpern" <[email-masked]> wrote:

>>>>>>                                        justification to separate the
>>>>>>                                        identity of a service 
>>>>>>function from
>>>>>>                                        its network location is
>>>>>>                                        load balancing.   If, for 
>>>>>>example,
>>>>>>                                        SF-A had 3 IP addresses,
>>>>>>                                        that would imply load 
>>>>>>balancing to 3
>>>>>>                                        instances using IP as a
>>>>>>                                        transport layer.
>>>>>>

---

From: David Allan I <[email-masked]>
Date: Fri, 14 Feb 2014 16:04:43 +0000

Wild agreement!

D

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, February 13, 2014 4:25 PM
To: Linda Dunbar; [email-masked]
Subject: Re: [sfc] Framework

Yours,
Joel

On 2/13/14, 7:18 PM, Linda Dunbar wrote:
>>>>>                                        different service functions that

---

From: Ron Parker <[email-masked]>
Date: Fri, 14 Feb 2014 16:13:04 +0000

Linda 

I would agree that SFC metadata is created and consumed by SFs, but not by explicitly addressed applications, which are out of scope for SFC, IMO.   SFC provides the delivery mechanism for this metadata. 

   Ron

> On Feb 14, 2014, at 10:59 AM, "Linda Dunbar" <[email-masked]> wrote:
> 
> Jim, 
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 18 Feb 2014 00:27:51 +0000

Hi Linda,
Apologies for my late response. Inline.

Sent from my iPhone

> On Feb 14, 2014, at 10:57 AM, "Linda Dunbar" <[email-masked]> wrote:
> 
> Jim, 
> 

Jim> could be either and SFC should support both.

> In that case, should this "metadata that are consumable by SF" be out of the scope of SFC? 

Jim> definition of the metadata structure probably; carrying it in SFC absolutely not.

> Those metadata are inserted/consumed by applications or SFs, they are really the internal processing within applications & related service functions. 

Jim> yes but the SFC encap needs to carry it.