Re: [sfc] Framework
Jerome Moisand <jmoisand@juniper.net> Thu, 13 February 2014 19:36 UTC
Return-Path: <jmoisand@juniper.net>
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 7EA681A0424 for <sfc@ietfa.amsl.com>; Thu, 13 Feb 2014 11:36:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 4UqsEEqoZXwr for <sfc@ietfa.amsl.com>; Thu, 13 Feb 2014 11:35:55 -0800 (PST)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id F092A1A0405 for <sfc@ietf.org>; Thu, 13 Feb 2014 11:35:54 -0800 (PST)
Received: from mail164-va3-R.bigfish.com (10.7.14.244) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.22; Thu, 13 Feb 2014 19:35:53 +0000
Received: from mail164-va3 (localhost [127.0.0.1]) by mail164-va3-R.bigfish.com (Postfix) with ESMTP id 20E4A400265; Thu, 13 Feb 2014 19:35:53 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -75
X-BigFish: VPS-75(zzbb2dI98dI9371Ic89bh148cI542I1432I15caKJ4015Idb82hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh9a9j1155h)
Received-SPF: pass (mail164-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(164054003)(24454002)(13464003)(55784002)(199002)(189002)(51704005)(52604005)(377454003)(479174003)(85306002)(65816001)(561944002)(95416001)(19580395003)(54316002)(80976001)(56776001)(77982001)(19580405001)(59766001)(80022001)(54356001)(53806001)(66066001)(51856001)(76482001)(63696002)(46102001)(94316002)(47446002)(74662001)(86362001)(93516002)(31966008)(83322001)(74502001)(33646001)(56816005)(94946001)(15975445006)(50986001)(47736001)(47976001)(81816001)(81686001)(93136001)(49866001)(85852003)(69226001)(4396001)(74366001)(90146001)(74316001)(74876001)(2656002)(87266001)(81342001)(87936001)(81542001)(74706001)(92566001)(95666001)(79102001)(83072002)(15202345003)(76576001)(76796001)(76786001)(24736002)(579004)(569005); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB713; H:CO2PR05MB716.namprd05.prod.outlook.com; CLIP:66.129.241.10; FPR:E66DF9D9.A7FA9383.B9C17173.82A5DB49.209F2; InfoNoRecordsA:1; MX:1; LANG:en;
Received: from mail164-va3 (localhost.localdomain [127.0.0.1]) by mail164-va3 (MessageSwitch) id 1392320149453207_9399; Thu, 13 Feb 2014 19:35:49 +0000 (UTC)
Received: from VA3EHSMHS001.bigfish.com (unknown [10.7.14.245]) by mail164-va3.bigfish.com (Postfix) with ESMTP id DB0B526004D; Thu, 13 Feb 2014 19:35:47 +0000 (UTC)
Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS001.bigfish.com (10.7.99.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 13 Feb 2014 19:35:35 +0000
Received: from CO2PR05MB713.namprd05.prod.outlook.com (10.141.228.147) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.411.0; Thu, 13 Feb 2014 19:35:35 +0000
Received: from CO2PR05MB716.namprd05.prod.outlook.com (10.141.228.152) by CO2PR05MB713.namprd05.prod.outlook.com (10.141.228.147) with Microsoft SMTP Server (TLS) id 15.0.873.15; Thu, 13 Feb 2014 19:35:33 +0000
Received: from CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) by CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) with mapi id 15.00.0873.009; Thu, 13 Feb 2014 19:35:33 +0000
From: Jerome Moisand <jmoisand@juniper.net>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: [sfc] Framework
Thread-Index: AQHPKO/ox4fmGuSHEU24oNCjTCFRY5qzkBAAgAAByYCAAABOIA==
Date: Thu, 13 Feb 2014 19:35:32 +0000
Message-ID: <245f4cf6d3824c1f8758ddeefdc7c16b@CO2PR05MB716.namprd05.prod.outlook.com>
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: [66.129.241.10]
x-forefront-prvs: 0121F24F22
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/uRDKx-AYs1Q8LSHxAQ9WhfaEqt4
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:36:06 -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: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)