Subject: [sfc] MTU

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

Dave,

I have been thinking that SFC is operating transparently to the end user.   Coupling SFC to end-user explicit behavioral requirements seems like the proverbial slippery slope to me.   How do others feel about this?

    Ron

-----Original Message-----
From: Dave Dolson [mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 12:01 PM
To: Ron Parker; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
Cc: [email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: [sfc] Framework

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

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

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: Jerome Moisand [mailto:[email-masked]]
Sent: Thursday, February 13, 2014 11:13 AM
To: Dave Dolson; [email-masked]'; Ron Parker; [email-masked]'; [email-masked]'; [email-masked]'
Cc: [email-masked]'; [email-masked]'; [email-masked]'
Subject: RE: [sfc] Framework

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

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

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
>
> 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 list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc

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

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 13 Feb 2014 12:21:05 -0500

This isn't an end-user behavior requirement, though.  To make SFC transparent to the end-user, you would want to send back an appropriate 'too big' message.  The draft text on this could be as simple as requiring that any SFC implementation send back an appropriate MTU for the sender to use based on the header that would have been applied, leaving the 'how' up to implementation.

From: [email-masked]<[email-masked]>
To: [email-masked]'<[email-masked]>
Sent: Thursday, February 13, 2014
Subject: [sfc] MTU

Dave,

    Ron

----- 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

"
>>> 2014 04:13 AM To: Ron Parker <[email-masked]>
;>>> Dave Dolson; Joel M. Halpern <[email-masked]>; Paul Quinn

---

From: Barry Greene <[email-masked]>
Date: Fri, 14 Feb 2014 07:15:43 +0700

On Feb 14, 2014, at 12:21 AM, [email-masked] wrote:

> The draft text on this could be as simple as requiring that any SFC implementation send back an appropriate MTU for the sender to use based on the header that would have been applied, leaving the 'how' up to implementation

Agreed. You need this to troubleshoot the corner cases.