Re: [sfc] Framework
Ron Parker <Ron_Parker@affirmednetworks.com> Thu, 13 February 2014 19:33 UTC
Return-Path: <Ron_Parker@affirmednetworks.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1228B1A0417 for <sfc@ietfa.amsl.com>; Thu, 13 Feb 2014 11:33:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeciUu1giy1J for <sfc@ietfa.amsl.com>; Thu, 13 Feb 2014 11:33:52 -0800 (PST)
Received: from hub021-ca-6.exch021.serverdata.net (hub021-ca-6.exch021.serverdata.net [64.78.56.71]) by ietfa.amsl.com (Postfix) with ESMTP id 161681A0421 for <sfc@ietf.org>; Thu, 13 Feb 2014 11:33:52 -0800 (PST)
Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 11:33:50 -0800
From: Ron Parker <Ron_Parker@affirmednetworks.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: [sfc] Framework
Thread-Index: AQHPKA5Sg2Ayd84yH0WUHw67lVJO2JqyXfUA//+hziCAAJFagP//euxwgACPGgD//4A48AARBvCAABBNRgD//4NNgIAADUiAgACFeFCAADG0gIAAOXoAgAALywCAAB5PgIAAheoA//+ADwCAAAjLAIAAAu8AgAAiSYCAAAZ/AIAAAGIAgAAJoQCAAAIgAIAAAcmAgACF7vA=
Date: Thu, 13 Feb 2014 19:33:49 +0000
Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A7A6DDC@MBX021-W3-CA-2.exch021.domain.local>
References: <CF225A5B.90D3%repenno@cisco.com> <52FD1D03.9030905@joelhalpern.com>
In-Reply-To: <52FD1D03.9030905@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [108.20.29.62]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/skWXMEdIc37XvE_fwgLJWA-qBrg
Subject: Re: [sfc] Framework
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Feb 2014 19:33:58 -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:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Thursday, February 13, 2014 2:29 PM To: sfc@ietf.org 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: > 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" <jmh@joelhalpern.com> 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.) >> >> 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: >>> resend to avoid "too many recipients" warning >>> >>> >>> On Thu, Feb 13, 2014 at 1:39 PM, Bruno Rijsman >>> <brunorijsman@gmail.com <mailto:brunorijsman@gmail.com>> 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 >>> <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>> 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 >>> >>> >>> On 2/13/14, 11:13 AM, Jerome Moisand wrote: >>> >>> 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:sfc-bounces@ietf.org >>> <mailto:sfc-bounces@ietf.org>] On Behalf Of Dave Dolson >>> Sent: Thursday, February 13, 2014 11:03 AM >>> To: 'jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>'; >>> 'Ron_Parker@affirmednetworks.__com >>> <mailto:Ron_Parker@affirmednetworks.com>'; >>> 'mohamed.boucadair@orange.com >>> <mailto:mohamed.boucadair@orange.com>'__; >>> 'Nicolas.BOUTHORS@qosmos.com >>> <mailto:Nicolas.BOUTHORS@qosmos.com>'; 'paulq@cisco.com >>> <mailto:paulq@cisco.com>' >>> Cc: 'S.Majee@F5.com'; 'sfc@ietf.org <mailto:sfc@ietf.org>'; >>> 'linda.dunbar@huawei.com <mailto:linda.dunbar@huawei.com>' >>> 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:jmh@joelhalpern.com >>> <mailto:jmh@joelhalpern.com>] >>> Sent: Thursday, February 13, 2014 10:31 AM >>> To: Ron Parker <Ron_Parker@affirmednetworks.__com >>> <mailto:Ron_Parker@affirmednetworks.com>>; >>> mohamed.boucadair@orange.com >>> <mailto:mohamed.boucadair@orange.com> >>> <mohamed.boucadair@orange.com >>> <mailto:mohamed.boucadair@orange.com>>__; Dave Dolson; >>> 'Nicolas.BOUTHORS@qosmos.com >>> <mailto:Nicolas.BOUTHORS@qosmos.com>' >>> <Nicolas.BOUTHORS@qosmos.com >>> <mailto:Nicolas.BOUTHORS@qosmos.com>>; 'paulq@cisco.com >>> <mailto:paulq@cisco.com>' <paulq@cisco.com >>> <mailto:paulq@cisco.com>> >>> Cc: 'S.Majee@F5.com' <S.Majee@F5.com>; 'sfc@ietf.org >>> <mailto:sfc@ietf.org>' <sfc@ietf.org <mailto:sfc@ietf.org>>; >>> 'linda.dunbar@huawei.com <mailto:linda.dunbar@huawei.com>' >>> <linda.dunbar@huawei.com <mailto:linda.dunbar@huawei.com>> >>> 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-f >>> rame) >>> >>> Ron >>> >>> >>> -----Original Message----- From: Joel M. Halpern >>> [mailto:jmh@joelhalpern.com >>> <mailto:jmh@joelhalpern.com>] Sent: Thursday, February >>> 13, 2014 10:10 >>> AM To: mohamed.boucadair@orange.com >>> <mailto:mohamed.boucadair@orange.com>; Dave Dolson; >>> 'Nicolas.BOUTHORS@qosmos.com >>> <mailto:Nicolas.BOUTHORS@qosmos.com>'; Ron Parker; >>> 'paulq@cisco.com <mailto:paulq@cisco.com>' Cc: >>> 'S.Majee@F5.com'; 'sfc@ietf.org <mailto:sfc@ietf.org>'; >>> 'linda.dunbar@huawei.com >>> <mailto:linda.dunbar@huawei.com>' 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, mohamed.boucadair@orange.com >>> <mailto:mohamed.boucadair@orange.com> wrote: >>> >>> Re-, >>> >>> FWIW, one of the existing architecture drafts >>> includes the following >>> behavior >>> >>> (http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02#sec >>> tion- >>> 6 >>> >>> <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:sfc-bounces@ietf.org >>> <mailto:sfc-bounces@ietf.org>] >>> De la part de Dave Dolson Envoyé : >>> jeudi 13 février 2014 13:39 À : >>> 'Nicolas.BOUTHORS@qosmos.com >>> <mailto:Nicolas.BOUTHORS@qosmos.com>'; >>> 'Ron_Parker@affirmednetworks.__com >>> <mailto:Ron_Parker@affirmednetworks.com>'; >>> 'jmh@joelhalpern.com >>> <mailto:jmh@joelhalpern.com>'; >>> 'paulq@cisco.com <mailto:paulq@cisco.com>' Cc : >>> 'S.Majee@F5.com'; 'sfc@ietf.org >>> <mailto:sfc@ietf.org>'; >>> 'linda.dunbar@huawei.com >>> <mailto:linda.dunbar@huawei.com>' 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:Nicolas.BOUTHORS@__qosmos.com >>> <mailto:Nicolas.BOUTHORS@qosmos.com>] Sent: >>> Thursday, February 13, >>> 2014 04:13 AM To: Ron Parker >>> <Ron_Parker@affirmednetworks.__com >>> <mailto:Ron_Parker@affirmednetworks.com>>; >>> Dave Dolson; Joel M. Halpern >>> <jmh@joelhalpern.com >>> <mailto:jmh@joelhalpern.com>>; Paul Quinn >>> (paulq) <paulq@cisco.com >>> <mailto:paulq@cisco.com>> Cc: Sumandra Majee >>> <S.Majee@F5.com>; >>> sfc@ietf.org <mailto:sfc@ietf.org> <sfc@ietf.org >>> <mailto:sfc@ietf.org>>; Linda Dunbar >>> <linda.dunbar@huawei.com >>> <mailto:linda.dunbar@huawei.com>> >>> 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 >>> [Ron_Parker@affirmednetworks.__com >>> <mailto:Ron_Parker@affirmednetworks.com>] Sent: >>> Wednesday, February 12, >>> 2014 11:25 PM To: Dave Dolson; Joel M. Halpern; >>> Paul Quinn >>> (paulq) Cc: Sumandra Majee; sfc@ietf.org >>> <mailto:sfc@ietf.org>; 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:ddolson@sandvine.com >>> <mailto:ddolson@sandvine.com>] Sent: Wednesday, >>> February 12, 2014 >>> 5:18 PM To: Joel M. Halpern; Ron Parker; Paul >>> Quinn (paulq) Cc: >>> Sumandra Majee; sfc@ietf.org >>> <mailto:sfc@ietf.org>; 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:sfc-bounces@ietf.org >>> <mailto:sfc-bounces@ietf.org>] >>> 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; >>> sfc@ietf.org <mailto:sfc@ietf.org>; 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:ddolson@sandvine.com >>> <mailto:ddolson@sandvine.com>] Sent: >>> Wednesday, February 12, >>> 2014 4:10 PM To: Ron Parker; Paul Quinn >>> (paulq) Cc: Joel M. >>> Halpern; Sumandra Majee; sfc@ietf.org >>> <mailto:sfc@ietf.org>; 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:sfc-bounces@ietf.org >>> <mailto:sfc-bounces@ietf.org>] >>> On Behalf Of Ron Parker Sent: >>> Wednesday, February 12, 2014 4:05 PM To: >>> Paul Quinn (paulq) Cc: >>> Joel M. Halpern; Sumandra Majee; >>> sfc@ietf.org <mailto:sfc@ietf.org>; >>> 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:paulq@cisco.com >>> <mailto:paulq@cisco.com>] Sent: Wednesday, >>> February 12, 2014 >>> 3:40 PM To: Ron Parker Cc: Sumandra Majee; >>> Linda Dunbar; Joel M. >>> Halpern; sfc@ietf.org <mailto:sfc@ietf.org> >>> 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 >>> <Ron_Parker@affirmednetworks.__com >>> >>> <mailto:Ron_Parker@affirmednetworks.com>> >>> >>> 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:S.Majee@F5.com >>> <mailto:S.Majee@F5.com>] Sent: >>> Wednesday, February 12, 2014 >>> 3:04 PM To: Ron Parker; Linda Dunbar; >>> Joel M. Halpern; >>> sfc@ietf.org <mailto:sfc@ietf.org> >>> 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" >>> <Ron_Parker@affirmednetworks.__com >>> >>> <mailto:Ron_Parker@affirmednetworks.com>> >>> >>> 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:sfc-bounces@ietf.org >>> <mailto:sfc-bounces@ietf.org>] On >>> Behalf Of Linda Dunbar >>> Sent: Wednesday, February 12, 2014 >>> 12:01 PM To: Joel M. >>> Halpern; sfc@ietf.org >>> <mailto:sfc@ietf.org> 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:sfc-bounces@ietf.org >>> <mailto:sfc-bounces@ietf.org>] On >>> Behalf Of Joel M. Halpern >>> Sent: Wednesday, February 12, 2014 >>> 10:20 AM To: >>> sfc@ietf.org <mailto:sfc@ietf.org> >>> 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 >>> sfc@ietf.org >>> <mailto:sfc@ietf.org> >>> >>> https://www.ietf.org/mailman/__listinfo/sfc >>> >>> <https://www.ietf.org/mailman/listinfo/sfc> >>> >>> >>> _________________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> <mailto:sfc@ietf.org> >>> >>> https://www.ietf.org/mailman/__listinfo/sfc >>> >>> <https://www.ietf.org/mailman/listinfo/sfc> >>> >>> >>> _________________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> <mailto:sfc@ietf.org> >>> >>> https://www.ietf.org/mailman/__listinfo/sfc >>> >>> <https://www.ietf.org/mailman/listinfo/sfc> >>> >>> >>> >>> _________________________________________________ >>> sfc mailing list >>> sfc@ietf.org <mailto:sfc@ietf.org> >>> >>> https://www.ietf.org/mailman/__listinfo/sfc >>> >>> <https://www.ietf.org/mailman/listinfo/sfc> >>> >>> >>> >>> _________________________________________________ >>> sfc mailing list >>> sfc@ietf.org <mailto:sfc@ietf.org> >>> https://www.ietf.org/mailman/__listinfo/sfc >>> >>> <https://www.ietf.org/mailman/listinfo/sfc> >>> >>> >>> >>> _________________________________________________ sfc >>> mailing list >>> sfc@ietf.org <mailto:sfc@ietf.org> >>> https://www.ietf.org/mailman/__listinfo/sfc >>> <https://www.ietf.org/mailman/listinfo/sfc> >>> >>> >>> >>> >>> _________________________________________________ sfc >>> mailing list >>> sfc@ietf.org <mailto:sfc@ietf.org> >>> https://www.ietf.org/mailman/__listinfo/sfc >>> <https://www.ietf.org/mailman/listinfo/sfc> >>> >>> >>> _________________________________________________ sfc >>> mailing list >>> sfc@ietf.org <mailto:sfc@ietf.org> >>> https://www.ietf.org/mailman/__listinfo/sfc >>> <https://www.ietf.org/mailman/listinfo/sfc> >>> >>> >>> >>> >>> _________________________________________________ >>> sfc mailing list >>> sfc@ietf.org <mailto:sfc@ietf.org> >>> https://www.ietf.org/mailman/__listinfo/sfc >>> <https://www.ietf.org/mailman/listinfo/sfc> >>> >>> >>> >>> >>> >>> _________________________________________________ >>> sfc mailing list >>> sfc@ietf.org <mailto:sfc@ietf.org> >>> https://www.ietf.org/mailman/__listinfo/sfc >>> <https://www.ietf.org/mailman/listinfo/sfc> >>> >>> >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc
- [sfc] Framework Joel M. Halpern
- Re: [sfc] Framework Linda Dunbar
- Re: [sfc] Framework Ron Parker
- Re: [sfc] Framework Joel M. Halpern
- Re: [sfc] Framework Ron Parker
- Re: [sfc] Framework Joel M. Halpern
- Re: [sfc] Framework Sumandra Majee
- Re: [sfc] Framework Ron Parker
- Re: [sfc] Framework Paul Quinn (paulq)
- Re: [sfc] Framework Sumandra Majee
- Re: [sfc] Metadata structure Joel M. Halpern
- Re: [sfc] Framework Joel M. Halpern
- Re: [sfc] Framework Surendra Kumar (smkumar)
- Re: [sfc] Framework Ron Parker
- Re: [sfc] Framework Dave Dolson
- Re: [sfc] Framework Ron Parker
- Re: [sfc] Framework Joel M. Halpern
- Re: [sfc] Framework Dave Dolson
- Re: [sfc] Framework Ron Parker
- Re: [sfc] Framework Sumandra Majee
- Re: [sfc] Framework Ron Parker
- Re: [sfc] Framework Joel M. Halpern
- Re: [sfc] Framework Nicolas BOUTHORS
- Re: [sfc] Framework mohamed.boucadair
- Re: [sfc] Framework mohamed.boucadair
- Re: [sfc] Metadata structure mohamed.boucadair
- Re: [sfc] Framework Dave Dolson
- Re: [sfc] Framework Jerome Moisand
- Re: [sfc] Framework Ron Parker
- Re: [sfc] Framework mohamed.boucadair
- Re: [sfc] Framework Joel M. Halpern
- Re: [sfc] Framework Ron Parker
- Re: [sfc] Framework Reinaldo Penno (repenno)
- Re: [sfc] Framework Joel M. Halpern
- Re: [sfc] Framework Surendra Kumar (smkumar)
- Re: [sfc] Framework Ron Parker
- Re: [sfc] Framework Joel M. Halpern
- Re: [sfc] Framework Joel M. Halpern
- Re: [sfc] Framework Dave Dolson
- Re: [sfc] Framework Jerome Moisand
- Re: [sfc] Framework Ron Parker
- Re: [sfc] Framework Ron Parker
- Re: [sfc] Framework mikebianc@aol.com
- Re: [sfc] Framework Dave Dolson
- Re: [sfc] Framework Joel M. Halpern
- Re: [sfc] Framework Bruno Rijsman
- Re: [sfc] Framework Joel M. Halpern
- Re: [sfc] Framework Reinaldo Penno (repenno)
- Re: [sfc] Framework Joel M. Halpern
- Re: [sfc] Framework Sumandra Majee
- Re: [sfc] Framework Kevin J Ma
- Re: [sfc] Framework Ron Parker
- Re: [sfc] Framework Linda Dunbar
- Re: [sfc] Framework Joel M. Halpern
- Re: [sfc] Framework Ron Parker
- Re: [sfc] Framework Nicolas BOUTHORS
- Re: [sfc] Framework Bruno Rijsman
- Re: [sfc] Framework Ron Parker
- Re: [sfc] Framework Jim Guichard (jguichar)
- Re: [sfc] Framework Jerome Moisand
- Re: [sfc] Framework Jim Guichard (jguichar)
- Re: [sfc] Framework Linda Dunbar
- Re: [sfc] Framework David Allan I
- Re: [sfc] Framework Ron Parker
- Re: [sfc] Framework Jim Guichard (jguichar)