From nobody Thu May 1 23:08:52 2014 Return-Path: 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 523DE1A08C2 for ; Thu, 1 May 2014 23:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 lqVdJTwA1Vrq for ; Thu, 1 May 2014 23:08:49 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED8F1A0776 for ; Thu, 1 May 2014 23:08:48 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id 10so2759247lbg.15 for ; Thu, 01 May 2014 23:08:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2IWvwO7hPUbYjYw9SMkBAOJ3UgRQblUZhA8bqN+UoDg=; b=bPa0PiYnqBHje+GHcG/jWB0S9MkSnaxAGNZfillOSa5/tj7mx+9qitpGVPb0xyVKnX m+2n4MoHX71w44GVQ+A6eswEsTivZcP3p3FKstc8nTRQ9/cRLt+hqWVOURZpmxVlUIct 6sWHtc5+C5Xv6mlg92tJD03UxPpJ4RddpO9QI0KXoK1MxBSqKKM1cCjGx3JohnaL/vk/ Nf3nHJKh6vh9woebMa0RVIUKETfaRPccg6HvSJ1eloZUHrlo0INGgt0Ga4ufiX/OHsu9 XK7SaVFa1N/N9LQFCUXm7bXJxOiwD28lNDS1pkBMZBgiTa2eabqp31tjCh8vXRc1SEbX i2jw== MIME-Version: 1.0 X-Received: by 10.112.137.5 with SMTP id qe5mr10448638lbb.16.1399010926025; Thu, 01 May 2014 23:08:46 -0700 (PDT) Received: by 10.114.229.44 with HTTP; Thu, 1 May 2014 23:08:45 -0700 (PDT) In-Reply-To: <5602569641FB314FB4D9AD5659D41B9C2C1B0AA05D@WSMSG3154V.srv.dir.telstra.com> References: <5351B460.5040709@joelhalpern.com> <5602569641FB314FB4D9AD5659D41B9C2C1B0AA05D@WSMSG3154V.srv.dir.telstra.com> Date: Fri, 2 May 2014 02:08:45 -0400 Message-ID: From: Peng He To: "Pham, Chuong D" Content-Type: multipart/alternative; boundary=089e0115fd3c48623404f8649dc8 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/uJybblyXUW9xyaFll0JIRzwuyY4 Cc: "Jim Guichard \(jguichar\)" , "Haeffner, Walter, Vodafone DE" , "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" , "sfc@ietf.org" , "Joel M. Halpern" Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 06:08:51 -0000 --089e0115fd3c48623404f8649dc8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would agree with Chuong's comments below, hence don't think the current draft is ready to become a WG doc at this moment. also wonder if the author has plan to take Sumandra's previous suggestion that 'focus on enterprise/cloud (call this draft-enterprise-=E2=80=A6.) and cover the uniq= ueness of that piece of land than a generic DC.'. Regards, Peng On Tue, Apr 29, 2014 at 7:35 PM, Pham, Chuong D < Chuong.D.Pham@team.telstra.com> wrote: > Separate drafts for pockets of environments will most likely overlook the > opportunities for identifying commonalities, synergies and reuse factors > between similar use cases for different environments. This is the painful > situation today where silos exist while at this point in time where Mobil= e, > Fixed Broadband and Data Centre are seeing strong forces towards > convergence with SDN, NFV and Cloud technologies. > > An overall draft such as draft-liu or similar must exist as a common > reference point for more detailed level drafts addressing use cases for > specific/pockets of environments while allowing for future > migration/convergence. > > Unless draft-kumar co-exists with high level draft-liu, I see more harm i= n > divergence rather than benefits therefore I disapprove. > > Regards, > Chuong > > > -----Original Message----- > From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com] > Sent: Wednesday, 30 April 2014 2:56 AM > To: Joel M. Halpern; Jim Guichard (jguichar); sfc@ietf.org > Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 > > I also support this draft. Being on DC level this draft will complement > the other use case drafts. Beside typical FW or DPI etc. there should be > not that much overlap with the more carrier services oriented use case > drafts. > > Cheers, Walter > > > -----Urspr=C3=BCngliche Nachricht----- > Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Joel M. Halpern > Gesendet: Samstag, 19. April 2014 01:25 > An: Jim Guichard (jguichar); sfc@ietf.org > Betreff: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 > > I support adoption of this document by the working group. It is a good > starting point for addressing the material it covers, and the working gro= up > should cover that material. > > Yours, > Joel > > On 4/18/14, 6:31 PM, Jim Guichard (jguichar) wrote: > > Dear WG: > > > > This message begins a two week call for WG adoption of the document > > http://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd > > May 2014. > > > > Please respond to the SFC mailing list with any statements of approval > > or disapproval. > > > > Please note: > > > > 1. This is not WG Last Call. The document is not final, and the WG is > > expected to modify the document's content until there is WG > > consensus that the content is solid. Therefore, please don't oppose > > adoption just because you want to see changes to its content. > > 2. If you have objections to adoption of the document, please state > > your reasons why, and explain what it would take to address your > > concerns. > > 3. If you have issues with the content, by all means raise those issue= s > > and we can begin a dialog about how best to address them. > > > > > > > > _______________________________________________ > > 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 mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --089e0115fd3c48623404f8649dc8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would agree with Chuong's comments below, hence= don't think the current draft is ready to become a WG doc at this mome= nt. also wonder if the author has plan to take Sum= andra's previous suggestion that 'f= ocus on enterprise/cloud (call this draft-enterprise-=E2=80=A6.) and cover the uniq= ueness of that piece of land than a generic DC.'.


Regards,
Peng


On Tue, Apr 2= 9, 2014 at 7:35 PM, Pham, Chuong D <Chuong.D.Pham@team.telstr= a.com> wrote:
Separate drafts for pockets of environments = will most likely overlook the opportunities for identifying commonalities, = synergies and reuse factors between similar use cases for different environ= ments. This is the painful situation today where silos exist while at this = point in time where Mobile, Fixed Broadband and Data Centre are seeing stro= ng forces towards convergence with SDN, NFV and Cloud technologies.

An overall draft such as draft-liu or similar must exist as a common refere= nce point for more detailed level drafts addressing use cases for specific/= pockets of environments while allowing for future migration/convergence.
Unless draft-kumar co-exists with high level draft-liu, I see more harm in = divergence rather than benefits therefore I disapprove.

Regards,
Chuong


-----Original Message-----
From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com]
Sent: Wednesday, 30 April 2014 2:56 AM
To: Joel M. Halpern; Jim Guichard (jguichar); sfc@ietf.org
Cc: Jeffrey Napper (jenapper) (jenapp= er@cisco.com)
Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01

I also support this draft. Being on DC level this draft will complement the= other use case drafts. Beside typical FW or DPI etc. there should be not t= hat much overlap with the more carrier services oriented use case drafts.
Cheers, Walter


-----Urspr=C3=BCngliche Nachricht-----
Von: sfc [mailto:sfc-bounces@ietf.o= rg] Im Auftrag von Joel M. Halpern
Gesendet: Samstag, 19. April 2014 01:25
An: Jim Guichard (jguichar); sfc@ietf.org
Betreff: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01

I support adoption of this document by the working group. =C2=A0It is a goo= d starting point for addressing the material it covers, and the working gro= up should cover that material.

Yours,
Joel

On 4/18/14, 6:31 PM, Jim Guichard (jguichar) wrote:
> Dear WG:
>
> This message begins a two week call for WG adoption of the document > http://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.t= xt ending 2nd
> May 2014.
>
> Please respond to the SFC mailing list with any statements of approval=
> or disapproval.
>
> Please note:
>
> =C2=A01. This is not WG Last Call. The document is not final, and the = WG is
> =C2=A0 =C2=A0 expected to modify the document's content until ther= e is WG
> =C2=A0 =C2=A0 consensus that the content is solid. Therefore, please d= on't oppose
> =C2=A0 =C2=A0 adoption just because you want to see changes to its con= tent.
> =C2=A02. If you have objections to adoption of the document, please st= ate
> =C2=A0 =C2=A0 your reasons why, and explain what it would take to addr= ess your
> =C2=A0 =C2=A0 concerns.
> =C2=A03. If you have issues with the content, by all means raise those= issues
> =C2=A0 =C2=A0 and we can begin a dialog about how best to address them= .
>
>
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>

_______________________________________________
sfc mailing list
sfc@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sfc


_______________________________________________
sfc mailing list
sfc@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sfc

--089e0115fd3c48623404f8649dc8-- From nobody Fri May 2 05:09:41 2014 Return-Path: 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 704D71A6F91 for ; Fri, 2 May 2014 05:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 9s7MG7dULH-t for ; Fri, 2 May 2014 05:09:38 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAF51A6F8E for ; Fri, 2 May 2014 05:09:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37400; q=dns/txt; s=iport; t=1399032575; x=1400242175; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=xgLa3H/COJrz07Ry1SdFhO54Z+WgrPpCIysbmci0qfs=; b=iaCORvT2vdaUapUJ4Oj4lJouwMP4ngNCwrF5vcd3VQgtSSeeU9qa4K4A VAlimWl74zsg7mivckbveWn26NofEfY8SelyhOuSkbh4efWvrSyxkkvhO 4b50KLeQ6Cw6iXu5N8v5i+epAY7cZbxRCPNVyVONj4c4+odYfOoyI4GBN 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAHGKY1OtJV2a/2dsb2JhbABQCoJCRIEmxE2BEBZ0giUBAQEEHRA+AxsCAQgRAQIBAQEhAQYHMhQDBggCBAESiEHJTReJMYQ/BgsBPxcBhDkEmTCSb4M0gXI5 X-IronPort-AV: E=Sophos; i="4.97,972,1389744000"; d="scan'208,217"; a="40531422" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP; 02 May 2014 12:09:34 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s42C9Yk1028464 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 May 2014 12:09:34 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.229]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Fri, 2 May 2014 07:09:34 -0500 From: "Jim Guichard (jguichar)" To: "Hongyu Li (Julio)" , "Surendra Kumar (smkumar)" , Lucy yong , "sfc@ietf.org" Thread-Topic: [sfc] Progression of SFC use case documents Thread-Index: AQHPW1rEFm/Jlqg5pk+xJViDitQIZpsdrwgAgAQsMwCAAab8gIAJ1pIA Date: Fri, 2 May 2014 12:09:33 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D45371EBE@dfweml701-chm.china.huawei.com> <6EB34CB5D82C4645B826C56144826EA97E9F312A@SZXEMA509-MBX.china.huawei.com> <6EB34CB5D82C4645B826C56144826EA97E9F66A5@SZXEMA509-MBX.china.huawei.com> In-Reply-To: <6EB34CB5D82C4645B826C56144826EA97E9F66A5@SZXEMA509-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.43.180] Content-Type: multipart/alternative; boundary="_000_CF89027220279jguicharciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/_cXDixvC2I_976cyZVFW5mj6v50 Subject: Re: [sfc] Progression of SFC use case documents X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 12:09:40 -0000 --_000_CF89027220279jguicharciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Hongyu, The sentence you quote is meant to say =93work directly with the applicable= SDOs on incorporating relevant content=94.. In other words, if an applicab= le SDO has input for a given use case then we should work with them to inco= rporate said content. I would expect the authors and subject matter experts= from within our WG to identify such applicability. From: "Hongyu Li (Julio)" > Date: Friday, April 25, 2014 at 9:55 PM To: "Surendra Kumar (smkumar)" = >, Lucy yong >, Jim Guich= ard >, "sfc@ietf.org" > Subject: RE: [sfc] Progression of SFC use case documents and that can work directly with the applicable SDOs on incorporating releva= nt content. There was a question on the mailing list asking what are the SDOs draft-kum= ar-sfc-dc-use-case is corresponding to, but no answer was posted so far. SK> Do you have a suggestion for an SDO for enterprise DC ? [HL] You=92ve just asked a brilliant question to the chairs, who is expecti= ng draft-kumar-sfc-dc-use-case can serve the purpose of =93work directly wi= th the applicable SDOs on incorporating relevant content=94. From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Sent: Friday, April 25, 2014 8:41 AM To: Hongyu Li (Julio); Lucy yong; Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] Progression of SFC use case documents Inline. From: "Hongyu Li (Julio)" > Date: Tuesday, April 22, 2014 1:58 AM To: Lucy yong >, "Jim Gui= chard (jguichar)" >, "sfc@iet= f.org" > Subject: Re: [sfc] Progression of SFC use case documents Hi Chairs, I support Lucy=92s comment. draft-kumar-sfc-dc-use-case has a fancy name, b= ut not so fancy use cases. Snipped from Chairs=92 email: SK> Our goal is to capture the use cases in enterprise DCs that highlight t= he challenges in deploying legacy service chaining and bring out the requir= ements for SFC architecture with examples. 1. Adopt a small number of WG documents (initially 2) that are applica= ble to specific environments and that can be worked on independently by mem= bers of the WG that have the necessary expertise for that environment, Both mobile and fixed network may put their Service Functions in a virtual = environment, which is very possibly a datacenter. So, draft-kumar-sfc-dc-u= se-case has a great overlap with other use case drafts including, even thou= gh you want to have =93specific environments=94 and clean cuts between them= . SK> In fact I would go a step further and say, the concepts underlying all = of them are the same - the reason all use cases are in this WG. The require= ments on the other hand are indeed different, specifically when contrasted = with Mobile SP. Although NFV is shining some light on SFC through Mobility use cases in rec= ent days, enterprise use cases have existed for a very long time. There are= a lot more enterprise deployments, small & large, than mobile SP. We would= be better served by not ignoring the vast majority of the SFC deployments,= in major enterprise DCs, pretty much everywhere. and that can work directly with the applicable SDOs on incorporating releva= nt content. There was a question on the mailing list asking what are the SDOs draft-kum= ar-sfc-dc-use-case is corresponding to, but no answer was posted so far. SK> Do you have a suggestion for an SDO for enterprise DC ? Surendra. So, it seems draft-kumar-sfc-dc-use-case doesn=92t serve your purpose at al= l. BR, Hongyu From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong Sent: Saturday, April 19, 2014 7:06 AM To: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] Progression of SFC use case documents Dear Chairs, People including myself did not voice a single document to capture all poss= ible use cases because there is no need to do that. We suggested capturing = all necessary use cases that help driving the architecture and requirement = development. Giving the situation, I support adopting draft-haeffner-sfc-use-case-moblit= y as WG draft. This is because a large portion of SFC use cases are in Mobi= le applications; and the draft describes many unique ways to use SFC. It is= good to have one draft to cover Mobile area. IMO: draft-kumar-sfc-dc-use-cases does not depict unique SFC cases from a g= eneral SFC case except the SFC applications location is in data centers. Th= us these cases can be easily merged into the general use case draft. So we = have another use case draft for the rest. Regards, Lucy Dear WG: There has been much discussion both on the list and during our face-to-face= meetings about how best to progress use case documents within the WG. Ther= e are clearly arguments for both of the following approaches: 1. A single document that captures all of the possible use cases. 2. A small number of targeted documents that are focused on a particular= subset of the overall problem space (such as broadband, mobility, and data= center). But, we can=92t choose both. In considering these approaches, the chairs re= cognize that there are benefits to having a single document, but do not bel= ieve having just one document is workable in this case. Nor is there consen= sus for having a single document. Therefore, we will pursue the following = approach going forward: 1. Adopt a small number of WG documents (initially 2) that are applicabl= e to specific environments and that can be worked on independently by membe= rs of the WG that have the necessary expertise for that environment, and th= at can work directly with the applicable SDOs on incorporating relevant con= tent. 2. Continue to leave open the possibility of adopting a high-level use c= ase document that serves as a =93catch all=94 for use cases that do not mer= it their own document or are not captured in the content of more focused us= e case documents. However, before taking on such a document, the WG will ne= ed to understand in more detail what the content would be and that the cont= ent justifies having such a document. Such a document should not duplicate = material that is covered in other documents. To facilitate the above direction the chairs will take the following steps: 1. Call for the adoption of draft-haeffner-sfc-use-case-moblity and draf= t-kumar-sfc-dc-use-cases as WG documents. 2. Encourage the authors to continue to work on refinement of draft-liu-= sfc-use-cases. The authors of that document should update their draft to re= move any duplication of material covered in other documents as well as iden= tify content that is not covered elsewhere. We hope that this approach will allow the WG to move forward and also provi= de enough flexibility to allow use cases to evolve independently, with dire= ct interaction with the appropriate SDOs. Thanks, Jim & Thomas --_000_CF89027220279jguicharciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5F6A0C1591623E4696E13057BAE42D26@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Hongyu,

The sentence you quote is meant to say =93work directly with the applicable SDOs on incorporating relevant conte= nt=94.. In other words, if an applicable SDO has input fo= r a given use case then we should work with them to incorporate said conten= t. I would expect the authors and subject matter experts from within our WG= to identify such applicability.

From: "Hongyu Li (Julio)"= <hongyu.li@huawei.com> Date: Friday, April 25, 2014 at 9:5= 5 PM
To: "Surendra Kumar (smkumar)&= quot; <smkumar@cisco.com>, L= ucy yong <lucy.yong@huawei.com>, Jim Guichard <jguichar@cis= co.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: RE: [sfc] Progression of S= FC use case documents

and that can work directly with the applicable SDOs on incorporating relev= ant content.

There was a questi= on on the mailing list asking what are the SDOs draft-kumar-sfc-dc-use-case= is corresponding to, but no answer was posted so far.

SK> Do you have a suggestion= for an SDO for enterprise DC ?

 <= /span>

[HL] You=92ve just= asked a brilliant question to the chairs, who is expecting draft-kumar-sfc-dc-use-case can se= rve the purpose of =93work directly with the applicable SDOs on incorporating relevant content=94.

 <= /span>

 <= /span>

From: Surendra Kumar (smk= umar) [mailto:smkumar@cisco.com]
Sent: Friday, April 25, 2014 8:41 AM
To: Hongyu Li (Julio); Lucy yong; Jim Guichard (jguichar); sfc@ietf.org
Subject: Re: [sfc] Progression of SFC use case documents<= /span>

 

Inline.

 

From: "Hongyu Li (Julio)" <hongyu.li@huawei.com>
Date: Tuesday, April 22, 2014 1:58 AM
To: Lucy yong <lucy.yong@= huawei.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sf= c@ietf.org>
Subject: Re: [sfc] Progression of SFC use case documents<= /span>

 

Hi Chairs,<= span lang=3D"EN-US" style=3D"color:black">

 

I support Lucy=92s= comment. draft-kumar-sfc-dc-use-case has a fancy name, but not so fancy us= e cases. Snipped from Chairs=92 email:

SK> Our goal is to capture t= he use cases in enterprise DCs that highlight the challenges in deploying l= egacy service chaining and bring out the requirements for SFC architecture with examples.

1.      Adopt a small num= ber of WG documents (initially 2) that are applicable to specific environme= nts and that can be worked on independently by members of the WG that have the necessary expertise for that environmen= t,

Both mobile and fi= xed network may put their Service Functions in a virtual environment, which= is very possibly  a datacenter. So, draft-kumar-sfc-dc-use-case has a great overlap with other use case drafts including, even though you = want to have =93specific environments=94 and clean cuts between them.

SK> In fact I would go a ste= p further and say, the concepts underlying all of them are the same - the r= eason all use cases are in this WG. The requirements on the other hand are indeed different, specifically when contrasted with = Mobile SP. 

Although NFV is shining some li= ght on SFC through Mobility use cases in recent days, enterprise use cases = have existed for a very long time. There are a lot more enterprise deployments, small & large, than mobile SP. = We would be better served by not ignoring the vast majority of the SFC depl= oyments, in major enterprise DCs, pretty much everywhere.

 

and that can work directly with the applicable SDOs on incorporating relev= ant content.

There was a questi= on on the mailing list asking what are the SDOs draft-kumar-sfc-dc-use-case= is corresponding to, but no answer was posted so far.

SK> Do you have a suggestion= for an SDO for enterprise DC ?

 

Surendra.<= /o:p>

 

So, it seems draft= -kumar-sfc-dc-use-case doesn=92t serve your purpose at all.

 

BR,

Hongyu

 

From: sfc [mailto:sfc-bounces@iet= f.org] On Behalf Of Lucy yong
Sent: Saturday, April 19, 2014 7:06 AM
To: Jim Guichard (jguichar); sfc@iet= f.org
Subject: Re: [sfc] Progression of SFC use case documents

 

Dear Chairs,<= span lang=3D"EN-US" style=3D"color:black">

 

People includi= ng myself did not voice a single document to capture all possible use cases= because there is no need to do that. We suggested capturing all necessary use cases that help driving the archi= tecture and requirement development.

 <= /i>

Giving the sit= uation, I support adopting draft-haeffner-sfc-use-case-moblity as WG draft.= This is because a large portion of SFC use cases are in Mobile applications; and the draft describes many unique = ways to use SFC. It is good to have one draft to cover Mobile area.

 <= /i>

IMO: draft-kum= ar-sfc-dc-use-cases does not depict unique SFC cases from a general SFC cas= e except the SFC applications location is in data centers. Thus these cases can be easily merged into the general= use case draft. So we have another use case draft for the rest.=

 <= /i>

Regards,

Lucy

 

Dear WG:

 

There has been much discussio= n both on the list and during our face-to-face meetings about how best to p= rogress use case documents within the WG. There are clearly arguments for both of the following approaches:

  1. A single document that captures all of the possible use cases.
  2. A small number of targeted documents that are focused on a particu= lar subset of the overall problem space (such as broadband, mobility, and d= ata center).

But, we can=92t choose both. = In considering these approaches, the chairs recognize that there are benefi= ts to having a single document, but do not believe having just one document is workable in this case. Nor is there co= nsensus for having a single document.  Therefore, we will pursue the f= ollowing approach going forward:

  1. Adopt a small number of WG documents (initially 2) that are applic= able to specific environments and that can be worked on independently by me= mbers of the WG that have the necessary expertise for that environment, and that can work directly with the applic= able SDOs on incorporating relevant content.
  2. Continue to leave open the possibility of adopting a high-level us= e case document that serves as a =93catch all=94 for use cases that do not = merit their own document or are not captured in the content of more focused use case documents. However, before taking = on such a document, the WG will need to understand in more detail what the = content would be and that the content justifies having such a document. Suc= h a document should not duplicate material that is covered in other documents. 

To facilitate the above direc= tion the chairs will take the following steps:

  1. Call for the adoption of draft-haeffner-sfc-use-case-moblity and d= raft-kumar-sfc-dc-use-cases as WG documents.
  2. Encourage the authors to continue to work on refinement of draft-l= iu-sfc-use-cases. The authors of that document should update their draft to= remove any duplication of material covered in other documents as well as identify content that is not covered= elsewhere. 

We hope that this approach wi= ll allow the WG to move forward and also provide enough flexibility to allo= w use cases to evolve independently, with direct interaction with the appropriate SDOs.

 

Thanks,

 

Jim & Thomas

 --_000_CF89027220279jguicharciscocom_-- From nobody Fri May 2 10:10:58 2014 Return-Path: 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 B65EC1A6FA0 for ; Fri, 2 May 2014 10:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 9LhcdwX4MONX for ; Fri, 2 May 2014 10:10:56 -0700 (PDT) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by ietfa.amsl.com (Postfix) with ESMTP id 513251A08DA for ; Fri, 2 May 2014 10:10:56 -0700 (PDT) Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 2 May 2014 13:10:53 -0400 Received: from d01dlp01.pok.ibm.com (9.56.250.166) by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 2 May 2014 13:10:52 -0400 Received: from b01cxnp23034.gho.pok.ibm.com (b01cxnp23034.gho.pok.ibm.com [9.57.198.29]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 948B038C804A for ; Fri, 2 May 2014 13:10:51 -0400 (EDT) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by b01cxnp23034.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s42HAp3n459040 for ; Fri, 2 May 2014 17:10:51 GMT Received: from d01av01.pok.ibm.com (localhost [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s42HAph2020431 for ; Fri, 2 May 2014 13:10:51 -0400 Received: from cichlid.raleigh.ibm.com ([9.80.100.70]) by d01av01.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s42HAofT020390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 2 May 2014 13:10:50 -0400 Received: from cichlid.raleigh.ibm.com.us.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id s42HAnek014628; Fri, 2 May 2014 13:10:49 -0400 Date: Fri, 02 May 2014 13:10:49 -0400 Message-ID: From: Thomas Narten To: In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F58B44EEF@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36F58B44EEF@PUEXCB1B.nanterre.francetelecom.fr> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/23.1 (x86_64-redhat-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14050217-5806-0000-0000-000024C7B181 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/UCAB6eZJmMIMajqn9deUpi5_9RM Cc: "sfc@ietf.org" Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 17:10:57 -0000 Let me try to split this thread into two different pieces. At Thu, 24 Apr 2014 08:27:20 +0200, wrote: > When checking the tracker, I found there is an IPR disclosure for the pro= blem > statement document: >=20 > https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3D > draft-ietf-sfc-problem-statement >=20 > I=A2m surprised to see such disclosure for a document that is supposed to > describe only problems (except section 3). Personally, I'm surprised too. But doesn't matter. Making an IPR disclosure is a legal decision, not an engineering one. The IETF is quite clear about IPR -- better to be safe and disclose, rather than not. And in my experience, IPR disclosures always have an explicit or implicit use of the word "may" to indicate that IPR "may" apply. Whether IPR does actually apply to specific technology is a nuanced discussion and one involving lawyers and the courts. Different people will have different opinions. > I=A2m re-iterating my comment to remove section 3 from the PS draft as it= seems > this is the only part that is close to the solution part than the problem > discussion. It's hard to see how removing section 3 will have any impact on IPR related to SFC. First, removing the section will not necessarily lead to the disclosure statement being removed (see above). Second, if there actually is in fact IPR that applies to SFC, that will become clear when we develop solutions, and additional specific disclosures will need to be made then. (Making a disclosure for one document isn't enough -- disclosures need to be made for every document to which IPR might apply.) Thus, tweaking the problem statement in an attempt to avoid an IPR disclosure seems more like wishful thinking than substance. Any IPR that applies to the problem statement will surely come up again in the context of specific a solution. IMO, it would be more appropriate for the WG to discuss how to handle potential IPR when discussing specific solutions -- when we can have a discussion in the context of specific technical approaches that are being considered. A number of folk on this thread have added a "+1". It would be helpful to get additional clarity as to whether the agreement is about the surprise at the IPR statement and a desire to try and avoid having the problem statement document have an IPR disclosure statement associated with it, or whether there is a support to remove section 3 for other reasons than the IPR disclosure (there have been earlier/separate threads on this question). Thomas >=20 > Cheers, >=20 > Med >=20 >=20 > [2 ] > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri May 2 10:11:17 2014 Return-Path: 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 DABEA1A6F5A for ; Fri, 2 May 2014 10:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.552 X-Spam-Level: X-Spam-Status: No, score=-9.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 UYpPymICideO for ; Fri, 2 May 2014 10:11:14 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id 29D651A6F1A for ; Fri, 2 May 2014 10:11:14 -0700 (PDT) Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 2 May 2014 13:11:11 -0400 Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 2 May 2014 13:11:09 -0400 Received: from b01cxnp23034.gho.pok.ibm.com (b01cxnp23034.gho.pok.ibm.com [9.57.198.29]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 6AF6AC90046 for ; Fri, 2 May 2014 13:11:04 -0400 (EDT) Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by b01cxnp23034.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s42HB0C4328120 for ; Fri, 2 May 2014 17:11:08 GMT Received: from d01av05.pok.ibm.com (localhost [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s42HAa5i024278 for ; Fri, 2 May 2014 13:10:36 -0400 Received: from cichlid.raleigh.ibm.com ([9.80.100.70]) by d01av05.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s42HAZQU023883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 2 May 2014 13:10:36 -0400 Received: from cichlid.raleigh.ibm.com.us.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id s42HAHsU014502; Fri, 2 May 2014 13:10:17 -0400 Date: Fri, 02 May 2014 13:10:16 -0400 Message-ID: From: Thomas Narten To: In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F544849C9@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36F544849C9@PUEXCB1B.nanterre.francetelecom.fr> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/23.1 (x86_64-redhat-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14050217-7182-0000-0000-00000A7D85DD Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/9axZJ5WXOKzvnsEwHXaHQZrwZrE Cc: "sfc@ietf.org" Subject: Re: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-03.txt) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 17:11:16 -0000 A few comments on this topic. At Tue, 1 Apr 2014 13:42:23 +0200, wrote: > > Dear all, > > I raised this point to the co-authors but I prefer to raise it also in > the mailing list. > > I suggest to remove Section 3 from the draft > http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-03#section-3, > because it goes beyond the problem discussion. That section is more a > discussion that should be hosted in a framework document. I think we should be careful about being too strict about "problem only" on the problem statement and not allowing any discussion about solution direction. The entire point of SFC (and indeed any WG problem statement) is to layout the problem and/or "pain points", but also to show the general direction of a solution. If we end up with a document that only outlines the problems, but provides no hint as to what sort of solution direction is being contemplated, we have done a disservice to the reader. That said, we of course don't want so much in the solution direction that it ends up restricting the architecture. But I don't think we are anywhere close to that. And, even if we were, the architecture document could overrule any such direction. The WG architecture document is where the WG makes real decisions and adds detail to them. > Furthermore, some of the points mentioned in that section are > questionable such as the use of metadata and the need of control > protocols, etc. Let's avoid mixing objectives and limit the scope of > the PS I-D to the identification to the problems to be solved. We most certainly will be using metadata. I don't see how anyone who can suggest we won't, given all the discussion so far on the topic. Also, we will need some sort of control protocol (or management protocol). Otherwise there is no way to coordinate the state carried in SFC packets and the various SFs that process packets. What we haven't worked out is the details of what that metadata looks like (that's a solution) or what the protocol/management protocols will look like (again a solution -- plus per the charter, we have at best only a vague idea of what this might entail). But this is normal for a WG at this stage of existence. > Aside not, the WG charter is clear about the scope of the PS I-D: > > " > 1. Problem Statement: This document will provide a summary of the > problem space to be addressed by the SFC working group including > example high-level use cases. > " Let's please not be strict constructionists in reading the words of the charter. Let's do what makes sense for the WG. The charter is a guideline and what is important is that we stay within the spirit of the charter, rather than the letter. I have no doubt that should we start straying from our charter in a significant way, we'll hear about it. And I'd be one of the first to raise such an alarm. Thomas From nobody Fri May 2 10:26:32 2014 Return-Path: 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 CF5171A0911 for ; Fri, 2 May 2014 10:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 fgpWcODycFFE for ; Fri, 2 May 2014 10:26:30 -0700 (PDT) Received: from hub021-ca-2.exch021.serverdata.net (hub021-ca-2.exch021.serverdata.net [64.78.22.169]) by ietfa.amsl.com (Postfix) with ESMTP id 305C71A6F6E for ; Fri, 2 May 2014 10:26:30 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0174.001; Fri, 2 May 2014 10:26:27 -0700 From: Ron Parker To: Thomas Narten , "mohamed.boucadair@orange.com" Thread-Topic: [sfc] IPR related to draft-ietf-sfc-problem-statement Thread-Index: Ac9fhj7PPNW+anohTi+gTFNE6u4L6QG3eReAAA42LrA= Date: Fri, 2 May 2014 17:26:26 +0000 Message-ID: References: <94C682931C08B048B7A8645303FDC9F36F58B44EEF@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] 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/je5-hfCg3JnWxQGzWqdKEEwx1OM Cc: "sfc@ietf.org" Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 17:26:31 -0000 Thomas, It would seem that the group has at least 3 paths wrt the IPR issue on the = problem statement: 1) Accept it as it is 2) The IPR claimant voluntarily decides to withdraw the claim, either with= or without corresponding content changes 3) A new draft is proposed by another party without IPR claims attached Can we get consensus on which path we would like to follow? Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas Narten Sent: Friday, May 02, 2014 1:11 PM To: mohamed.boucadair@orange.com Cc: sfc@ietf.org Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement Let me try to split this thread into two different pieces. At Thu, 24 Apr 2014 08:27:20 +0200, wrote: > When checking the tracker, I found there is an IPR disclosure for the=20 > problem statement document: >=20 > https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3D > draft-ietf-sfc-problem-statement >=20 > I=A2m surprised to see such disclosure for a document that is supposed=20 > to describe only problems (except section 3). Personally, I'm surprised too. But doesn't matter. Making an IPR disclosure is a legal decision, not an engineering one. The I= ETF is quite clear about IPR -- better to be safe and disclose, rather than= not. And in my experience, IPR disclosures always have an explicit or impl= icit use of the word "may" to indicate that IPR "may" apply. Whether IPR do= es actually apply to specific technology is a nuanced discussion and one in= volving lawyers and the courts. Different people will have different opinio= ns. > I=A2m re-iterating my comment to remove section 3 from the PS draft as=20 > it seems this is the only part that is close to the solution part than=20 > the problem discussion. It's hard to see how removing section 3 will have any impact on IPR related= to SFC. First, removing the section will not necessarily lead to the discl= osure statement being removed (see above). Second, if there actually is in fact IPR that applies to SFC, that will bec= ome clear when we develop solutions, and additional specific disclosures wi= ll need to be made then. (Making a disclosure for one document isn't enough= -- disclosures need to be made for every document to which IPR might apply= .) Thus, tweaking the problem statement in an attempt to avoid an IPR discl= osure seems more like wishful thinking than substance. Any IPR that applie= s to the problem statement will surely come up again in the context of spec= ific a solution. IMO, it would be more appropriate for the WG to discuss ho= w to handle potential IPR when discussing specific solutions -- when we can= have a discussion in the context of specific technical approaches that are= being considered. A number of folk on this thread have added a "+1". It would be helpful to g= et additional clarity as to whether the agreement is about the surprise at = the IPR statement and a desire to try and avoid having the problem statemen= t document have an IPR disclosure statement associated with it, or whether = there is a support to remove section 3 for other reasons than the IPR discl= osure (there have been earlier/separate threads on this question). Thomas >=20 > Cheers, >=20 > Med >=20 >=20 > [2 ] > _______________________________________________ > 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 From nobody Fri May 2 13:47:32 2014 Return-Path: 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 458E41A091A for ; Fri, 2 May 2014 13:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 AJTMt-zT8lMF for ; Fri, 2 May 2014 13:47:29 -0700 (PDT) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 304FC1A0939 for ; Fri, 2 May 2014 13:47:29 -0700 (PDT) Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 2 May 2014 16:47:26 -0400 Received: from d01dlp01.pok.ibm.com (9.56.250.166) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 2 May 2014 16:47:24 -0400 Received: from b01cxnp22036.gho.pok.ibm.com (b01cxnp22036.gho.pok.ibm.com [9.57.198.26]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 3253338C8047 for ; Fri, 2 May 2014 16:47:24 -0400 (EDT) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by b01cxnp22036.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s42KlOaR6488340 for ; Fri, 2 May 2014 20:47:24 GMT Received: from d01av03.pok.ibm.com (localhost [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s42KlNE8022968 for ; Fri, 2 May 2014 16:47:23 -0400 Received: from cichlid.raleigh.ibm.com ([9.80.100.70]) by d01av03.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s42KlMgX022933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 2 May 2014 16:47:23 -0400 Received: from cichlid.raleigh.ibm.com.us.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id s42KlL1W014593; Fri, 2 May 2014 16:47:21 -0400 Date: Fri, 02 May 2014 16:47:21 -0400 Message-ID: From: Thomas Narten To: Ron Parker In-Reply-To: References: <94C682931C08B048B7A8645303FDC9F36F58B44EEF@PUEXCB1B.nanterre.francetelecom.fr> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/23.1 (x86_64-redhat-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14050220-0320-0000-0000-00000328B496 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Jxw43CrE6YVVZvhENaGf1aVyYv8 Cc: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 20:47:31 -0000 Hi Ron. > It would seem that the group has at least 3 paths wrt the IPR issue on > the problem statement: >=20 > 1) Accept it as it is Right. And this is what happens in practice with most IPR disclosures these days. I'll just note that there have been some 45 disclosures in the IETF so far this year. For all of 2013, there were some 279. =20 IPR List: http://datatracker.ietf.org/ipr/ > 2) The IPR claimant voluntarily decides to withdraw the claim, either > with or without corresponding content changes In theory, this could happen. In practice, it's happened rarely. And the IPR holder would need a reason to do so. It is unclear to me what such motivation would be in this case (but of course the WG could attempt to make such a case). > 3) A new draft is proposed by another party without IPR claims > attached One of the realities of technology development is that much if not most technologies are covered by IPR of some sort. In most cases, we don't even know what that IPR is (e.g., there are plenty of IPR holders who don't even participate in the IETF). Any attempt at trying to change the problem statement in a way that avoids specific IPR that we know of would not address the potential IPR we don't know of. > Can we get consensus on which path we would like to follow? We are about to start a WG LC on the problem statement. Folk should followup there if they think a specific action should be taken wrt the disclosure. Thomas >=20 > Ron >=20 >=20 > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On > Behalf Of Thomas Narten Sent: Friday, May 02, 2014 1:11 PM To: > mohamed.boucadair@orange.com Cc: sfc@ietf.org Subject: Re: [sfc] IPR > related to draft-ietf-sfc-problem-statement >=20 > Let me try to split this thread into two different pieces. >=20 > At Thu, 24 Apr 2014 08:27:20 +0200, > wrote: >=20 > > When checking the tracker, I found there is an IPR disclosure for > > the problem statement document: > >=20 > > https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3D > > draft-ietf-sfc-problem-statement > >=20 > > I=A2m surprised to see such disclosure for a document that is supposed > > to describe only problems (except section 3). >=20 > Personally, I'm surprised too. But doesn't matter. >=20 > Making an IPR disclosure is a legal decision, not an engineering > one. The IETF is quite clear about IPR -- better to be safe and > disclose, rather than not. And in my experience, IPR disclosures > always have an explicit or implicit use of the word "may" to indicate > that IPR "may" apply. Whether IPR does actually apply to specific > technology is a nuanced discussion and one involving lawyers and the > courts. Different people will have different opinions. >=20 > > I=A2m re-iterating my comment to remove section 3 from the PS draft as > > it seems this is the only part that is close to the solution part > > than the problem discussion. >=20 > It's hard to see how removing section 3 will have any impact on IPR > related to SFC. First, removing the section will not necessarily lead > to the disclosure statement being removed (see above). >=20 > Second, if there actually is in fact IPR that applies to SFC, that > will become clear when we develop solutions, and additional specific > disclosures will need to be made then. (Making a disclosure for one > document isn't enough -- disclosures need to be made for every > document to which IPR might apply.) Thus, tweaking the problem > statement in an attempt to avoid an IPR disclosure seems more like > wishful thinking than substance. Any IPR that applies to the problem > statement will surely come up again in the context of specific a > solution. IMO, it would be more appropriate for the WG to discuss how > to handle potential IPR when discussing specific solutions -- when we > can have a discussion in the context of specific technical approaches > that are being considered. >=20 > A number of folk on this thread have added a "+1". It would be helpful > to get additional clarity as to whether the agreement is about the > surprise at the IPR statement and a desire to try and avoid having the > problem statement document have an IPR disclosure statement associated > with it, or whether there is a support to remove section 3 for other > reasons than the IPR disclosure (there have been earlier/separate > threads on this question). >=20 > Thomas >=20 > >=20 > > Cheers, > >=20 > > Med > >=20 > >=20 > > [2 ] > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc >=20 From nobody Fri May 2 13:57:12 2014 Return-Path: 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 EA4461A091A for ; Fri, 2 May 2014 13:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 a6a5iloiG-oB for ; Fri, 2 May 2014 13:57:08 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by ietfa.amsl.com (Postfix) with ESMTP id 26D171A0913 for ; Fri, 2 May 2014 13:57:08 -0700 (PDT) Received: from /spool/local by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 2 May 2014 14:57:05 -0600 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e35.co.us.ibm.com (192.168.1.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 2 May 2014 14:57:04 -0600 Received: from b03cxnp08028.gho.boulder.ibm.com (b03cxnp08028.gho.boulder.ibm.com [9.17.130.20]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id F0CE619D803E for ; Fri, 2 May 2014 14:56:57 -0600 (MDT) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by b03cxnp08028.gho.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s42KutWg7668092 for ; Fri, 2 May 2014 22:57:03 +0200 Received: from d03av03.boulder.ibm.com (localhost [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s42KuUdT031181 for ; Fri, 2 May 2014 14:56:30 -0600 Received: from cichlid.raleigh.ibm.com ([9.80.100.70]) by d03av03.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s42KuShV030701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 2 May 2014 14:56:30 -0600 Received: from cichlid.raleigh.ibm.com.us.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id s42KuBwE015760 for ; Fri, 2 May 2014 16:56:11 -0400 Date: Fri, 02 May 2014 16:56:11 -0400 Message-ID: From: Thomas Narten To: sfc@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/23.1 (x86_64-redhat-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14050220-6688-0000-0000-00000187C135 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/cTu7Xy8DiYEZ_eWM692zDOJ3MVk Subject: [sfc] WG Last Call for SFC Problem Statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 20:57:10 -0000 This note begins a 2-week WG Last Call on draft-ietf-sfc-problem-statement-05.txt. There is one outstanding issue that remains, but we can use the LC to clarify what the WG wants to do. Section 3 contains a description that explains the general approach SFC will use as a solution. There was a request to remove that section back in January, but there was no consensus to do so. Indeed, there was also significant support to leave it in, and that does not appear to have changed. The request came up again in the context of the IPR disclosure (https://datatracker.ietf.org/ipr/search/?option=document_search&id=draft-ietf-sfc-problem-statement); see my comments on that thread. While we can remove Section 3 in the hope that it mitigates the IPR concern, doing so would seem to have little (if any) practical benefit w.r.t. IPR. It is, of course, however the WG's decision as to the dispostion of Section 3. Substantive comments to the list please, editorial comments can go directly to the authors. Thomas & Jim From nobody Fri May 2 15:59:28 2014 Return-Path: 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 12DFF1A6FDE for ; Fri, 2 May 2014 15:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 oEUZ7NI3rapZ for ; Fri, 2 May 2014 15:59:24 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id C25411A09B6 for ; Fri, 2 May 2014 15:59:23 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id n15so1762429lbi.5 for ; Fri, 02 May 2014 15:59:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=AxJjtwPlhB90czhXnSHVzLjeut4i5IIciKunB4orZpg=; b=iR8auEoXQ/dxBGSbATGNoi8ahJLNgxacFFEkIboJ87s+679Wo0c76lE7oOR/9LQAeh jQZK0e/Hfi9xwtoqS0huoAcz4aeya8CNc/9nteLatvacSpRidqn07sZPNybsU/TbaZ4R M8zT0jp90w4mXc1ENcVVoDdH1UXs0xKUPqCRIRr2iMho6VNGGSCIxQiUYncJQ2VQZLxo 9pgE/0LT/51YZ7Mi16gX+AqUc/aKBA807mRPysd2tig0h5N0k/me5UszS04VADu+4mhq i+ETeEXbNBi2yOT96XABIRWJxxGQIk/7JtxHtX7P4lo8EQ+7itZhhbtRM+bax0iT0wDn ovKw== MIME-Version: 1.0 X-Received: by 10.152.87.71 with SMTP id v7mr395878laz.10.1399071560635; Fri, 02 May 2014 15:59:20 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Fri, 2 May 2014 15:59:20 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F58B44EFB@PUEXCB1B.nanterre.francetelecom.fr> References: <20140421195656.18585.39798.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F58B44EFB@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 2 May 2014 17:59:20 -0500 Message-ID: From: Behcet Sarikaya To: Mohamed Boucadair Content-Type: multipart/alternative; boundary=001a11c355b26319ad04f872bb5b Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/IMqpz_oBU4Rvtt7UUz0ai2-I9Fc Cc: "sfc@ietf.org" Subject: Re: [sfc] Fwd: New Version Notification for draft-xue-sfc-address-sharing-in-sfc-use-cases-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 22:59:26 -0000 --001a11c355b26319ad04f872bb5b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Med, Thank you for your comments. Please find my replies inline. Regards, Behcet On Thu, Apr 24, 2014 at 1:52 AM, wrote: > Hi Behcet, > > > > Thank you for sharing this document. Below some comments: > > > > =C2=B7 The document does not explicit if this is specific to the > service chaining case or if it is a generic concern. One can argue the > problem applies independently of service chaining. It would be useful to > include such discussion in the text with a focus on service chaining. > You are right. This has been corrected in the new version which is submitted as draft-sarikaya-sfc-address-sharing-in-sfc-use-cases-00.txt. > =C2=B7 Mandating all SFs are able to decrypt encrypted traffic is= not > viable IMHO. > Sure. We now stated that any solution is out of scope. > =C2=B7 If the problem is only specific to HTTPS, why not use the = TCP > option defined in > http://tools.ietf.org/html/draft-williams-exp-tcp-host-id-opt-02? > > > We now have a section on possible solutions, please check it. > Hope that helps. > > > > Cheers, > > Med > > > > *De :* sfc [mailto:sfc-bounces@ietf.org] *De la part de* Behcet Sarikaya > *Envoy=C3=A9 :* lundi 21 avril 2014 22:00 > *=C3=80 :* sfc@ietf.org > *Objet **:* [sfc] Fwd: New Version Notification for > draft-xue-sfc-address-sharing-in-sfc-use-cases-00.txt > > > > Hi all, > > We submitted this draft. It addresses an issue that is not covered in the > use case and requirements drafts. > > We solicit that it should be. > > Regards, > > Behcet > > > > > > > A new version of I-D, draft-xue-sfc-address-sharing-in-sfc-use-cases-00.t= xt > has been successfully submitted by Behcet Sarikaya and posted to the > IETF repository. > > Name: draft-xue-sfc-address-sharing-in-sfc-use-cases > Revision: 00 > Title: Host Identification Problem in Service Function Chaining > Use Cases > Document date: 2014-04-21 > Group: Individual Submission > Pages: 7 > URL: > http://www.ietf.org/internet-drafts/draft-xue-sfc-address-sharing-in-sfc-= use-cases-00.txt > Status: > https://datatracker.ietf.org/doc/draft-xue-sfc-address-sharing-in-sfc-use= -cases/ > Htmlized: > http://tools.ietf.org/html/draft-xue-sfc-address-sharing-in-sfc-use-cases= -00 > > > Abstract: > The purpose of this document is to present host identification > problem due to the address and prefix sharing in service function > chaining. So far we have identified this problem in the two use > cases of the parental control service and offloading service but it > is likely that more use cases can be identified. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > --001a11c355b26319ad04f872bb5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Med,

Thank you for your com= ments. Please find my replies inline.

Regards,

Be= hcet


On Thu, Apr 24, 2014 at 1:52 AM, <mohamed.boucadair@orange.com= > wrote:

Hi Behcet,

= =C2=A0

Thank you for sharing this document. Be= low some comments:

=C2=A0

=C2=B7=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <= span style=3D"font-size:10pt;font-family:"Courier New";color:rgb(= 31,73,125)">The document does not explicit if this is specific to the servi= ce chaining case or if it is a generic concern. One can argue the problem a= pplies independently of service chaining. It would be useful to include suc= h discussion in the text with a focus on service chaining.


You are right. This has been c= orrected in the new version which is submitted as draft-sarikaya-sfc-addres= s-sharing-in-sfc-use-cases-00.txt.

=

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <= /span>Mandating all SFs are able to decrypt encr= ypted traffic is not viable IMHO.


Sure. We now stated that any s= olution is out of scope.

=

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <= /span>If the problem is only specific to HTTPS, = why not use the TCP option defined in http://tools.ietf= .org/html/draft-williams-exp-tcp-host-id-opt-02? <= /p>

=C2=A0

We now have a section on possible solutions, please check it= .

=C2=A0

<= span style=3D"font-size:10pt;font-family:"Courier New";color:rgb(= 31,73,125)">

Hope that helps.

=C2=A0

Cheers,

Med

=C2=A0

De=C2=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Behcet Sarikaya
Envoy=C3=A9=C2=A0: lundi 21 avril 2014 22:00
=C3=80=C2=A0:= sfc@ietf.org
O= bjet=C2=A0: [sfc] Fwd: New Version Notification for draft-xue-sfc-address-sharing= -in-sfc-use-cases-00.txt

=C2=A0<= /u>

Hi all,

We submitted= this draft. It addresses an issue that is not covered in the use case and = requirements drafts.

We solicit that i= t should be.

Regards,

Behcet<= u>

=C2=A0

=C2=A0


A new version of I-D, draft-xue-sfc-address-s= haring-in-sfc-use-cases-00.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IET= F repository.

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-xue-sfc= -address-sharing-in-sfc-use-cases
Revision: =C2=A0 =C2=A0 =C2=A0 00
T= itle: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Host Identification Problem in Serv= ice Function Chaining Use Cases
Document date: =C2=A02014-04-21
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Individual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A07
U= RL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ietf.org/internet-drafts/draft-xue-sfc-address-sh= aring-in-sfc-use-cases-00.txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 htt= ps://datatracker.ietf.org/doc/draft-xue-sfc-address-sharing-in-sfc-use-case= s/
Htmlized: =C2=A0 =C2=A0 =C2=A0 ht= tp://tools.ietf.org/html/draft-xue-sfc-address-sharing-in-sfc-use-cases-00<= /a>


Abstract:
=C2=A0 =C2=A0The purpose of this document is to presen= t host identification
=C2=A0 =C2=A0problem due to the address and prefix= sharing in service function
=C2=A0 =C2=A0chaining. =C2=A0So far we have= identified this problem in the two use
=C2=A0 =C2=A0cases of the parental control service and offloading service b= ut it
=C2=A0 =C2=A0is likely that more use cases can be identified.
<= br>


Please note that it may take a couple of minutes from the ti= me of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretari= at

=C2=A0

--001a11c355b26319ad04f872bb5b-- From nobody Fri May 2 23:45:40 2014 Return-Path: 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 93CE01A001C for ; Fri, 2 May 2014 23:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 VyRfyQQSE0VT for ; Fri, 2 May 2014 23:45:37 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id A92571A0019 for ; Fri, 2 May 2014 23:45:37 -0700 (PDT) Received: from [192.168.1.5] (unknown [119.95.131.147]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id A6DEC1800905; Sat, 3 May 2014 08:45:32 +0200 (CEST) Message-ID: <5364908A.30704@pi.nu> Date: Sat, 03 May 2014 08:45:30 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Thomas Narten , Ron Parker References: <94C682931C08B048B7A8645303FDC9F36F58B44EEF@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/oHpqHcDVhuxIUfrbldFdhlp4_ss Cc: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 06:45:39 -0000 Folks, On 2014-05-02 22:47, Thomas Narten wrote: >> 1) Accept it as it is > Right. And this is what happens in practice with most IPR disclosures > these days. I'll just note that there have been some 45 disclosures in > the IETF so far this year. For all of 2013, there were some 279. I think the issue is not that most IPR disclosures does not lead to any action at all. For FRAND statements there is no problems to accept it as it is; however this is not FRAND but RAND. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sat May 3 08:04:31 2014 Return-Path: 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 3CBD81A00DA for ; Sat, 3 May 2014 08:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, 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 80x6y3kebkTZ for ; Sat, 3 May 2014 08:04:28 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0B31A00D7 for ; Sat, 3 May 2014 08:04:28 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id j5so5845683qga.8 for ; Sat, 03 May 2014 08:04:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PUEHppBT9pHcEpeamk56QkC/7TfgDhQFuOoscPNyxkU=; b=EO7S2sxj13rSd+JvT9hk+gGdoK3H5q6IEwEKXNxo6dwRB6pEmIRkrX5TFVJaBPWOpv ITTKKVZ7lIN6vLpWamow16R55D1+uibgUCO1M7hAPOYcB4r7uehDJzqXJtkEloARGAQ9 jwJBLPBJ3sZbKZ8TPX6zgpuFWdd3c6cP+SQKPAw7Fupp1cUNJtgVHoTYigFvrwJO+2jg yUjIMUyt6v419VI7mKCEibhFB2vemeg79ZrKCHL8D3ybcESLrvGdZZhyqFxAwnxPywrp 2C2KgxCkWfKBxjEDFf0K7hB/oIQ1VHyPWday2lt2c7d6OpKnyrk8XaVBWqLbPSIC2cHq Vixg== X-Received: by 10.224.172.2 with SMTP id j2mr31105703qaz.83.1399129465698; Sat, 03 May 2014 08:04:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.205.69 with HTTP; Sat, 3 May 2014 08:04:05 -0700 (PDT) In-Reply-To: <5364908A.30704@pi.nu> References: <94C682931C08B048B7A8645303FDC9F36F58B44EEF@PUEXCB1B.nanterre.francetelecom.fr> <5364908A.30704@pi.nu> From: "Andrew G. Malis" Date: Sat, 3 May 2014 11:04:05 -0400 Message-ID: To: Loa Andersson Content-Type: multipart/alternative; boundary=001a11c2b73ecc3f7104f88036a8 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/mf4v2fe1I_EH8yhEsGwHyHwWQnI Cc: Thomas Narten , "mohamed.boucadair@orange.com" , "sfc@ietf.org" , Ron Parker Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 15:04:30 -0000 --001a11c2b73ecc3f7104f88036a8 Content-Type: text/plain; charset=UTF-8 I agree with Loa - RAND on a problem statement implies that the entire technology is possibly encumbered. It would be best if the draft could be revised such that the IPR claim no longer applies, if that's even possible. That said, it's difficult to recommend specific changes without knowing why the IPR claim was made. Looking at the patent itself, "Creating distributed proxy configurations" at http://www.google.com/patents/US7200679 and looking at Figure 3 and Claim 1 in particular, the implication to me is that it's the entire technology that's being claimed. If that's the case, then our choices to look to be: - Accept that the entire technology is encumbered with a RAND claim, and continue on. - Drop the entire effort. - Ask the claimant to fill in section V.C. of the IPR claim, or otherwise clarify exactly what they are claiming. - Ask the claimant to change their claim from RAND licensing to free licensing with reciprocity. Cheers, Andy On Sat, May 3, 2014 at 2:45 AM, Loa Andersson wrote: > Folks, > > > On 2014-05-02 22:47, Thomas Narten wrote: > >> 1) Accept it as it is >>> >> Right. And this is what happens in practice with most IPR disclosures >> these days. I'll just note that there have been some 45 disclosures in >> the IETF so far this year. For all of 2013, there were some 279. >> > > I think the issue is not that most IPR disclosures does not lead to any > action at all. > > For FRAND statements there is no problems to accept it as it is; however > this is not FRAND but RAND. > > /Loa > > --001a11c2b73ecc3f7104f88036a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with Loa - RAND on a problem statement implies tha= t the entire technology is possibly encumbered. It would be best if the dra= ft could be revised such that the IPR claim no longer applies, if that'= s even possible. That said, it's difficult to recommend specific change= s without knowing why the IPR claim was made. Looking at the patent itself,= "Creating distributed proxy configurations" at http://www.google.com/patents/US7200679<= /a> and looking at Figure 3 and Claim 1 in particular, the implication to m= e is that it's the entire technology that's being claimed. If that&= #39;s the case, then our choices to look to be:

- Accept that the entire technology is encumbered with a RAN= D claim, and continue on.

- Drop the entire effort= .

- Ask the claimant to fill in section V.C. of th= e IPR claim, or otherwise clarify exactly what they are claiming.

- Ask the claimant to change their claim from RAND lice= nsing to free licensing with reciprocity.

Cheers,<= /div>
Andy

On = Sat, May 3, 2014 at 2:45 AM, Loa Andersson <loa@pi.nu> wrote:
Folks,


On 2014-05-02 22:47, Thomas Narten wrote:
1) Accept it as it is
Right. And this is what happens in practice with most IPR disclosures
these days. I'll just note that there have been some 45 disclosures in<= br> the IETF so far this year. For all of 2013, there were some 279.

I think the issue is not that most IPR disclosures does not lead to any
action at all.

For FRAND statements there is no problems to accept it as it is; however this is not FRAND but RAND.

/Loa

--001a11c2b73ecc3f7104f88036a8-- From nobody Sat May 3 19:23:33 2014 Return-Path: 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 0E5B31A01AB for ; Sat, 3 May 2014 19:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 hmwJdW8uWuW8 for ; Sat, 3 May 2014 19:23:28 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4681A019E for ; Sat, 3 May 2014 19:23:28 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id ib6so7072966vcb.33 for ; Sat, 03 May 2014 19:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=o8qfmQk6N/UWfa4tOf7QmxT/T4Z2KiG/fqQqpRpgSO8=; b=XEZWpjnkSN8G/ZerDi0oA9r59uBJbMgKujo+EMmN2NkgnP0AJMXJBOhvMS89S3nffj xE496eaS/OyhSZtDPU5nSVKr1qF/0gJs4yV8tnVCZKARUB3xmSMuwURcHRAn1QP9MmEe cT5iwwRKwjyEnzWqVKjAyWqnKYbe1DwI/DVKlZLuIKiQGaGqjn9AoAamBrasAUmCUatS 3mLlacjnl9JdXN9RkdovXnjAn8SMDHIJEZvynFSKfbmD4AgLJI7kXc9oksjTQ8q5jOrt Fs8qPGmMf4cI3/QQcsPJz1ucg9dodVYCkJqtJ6iYm9fzU5IXsy0yriRYFPXLqr48bZ9Y y+Cw== X-Received: by 10.220.191.134 with SMTP id dm6mr21097796vcb.16.1399170205172; Sat, 03 May 2014 19:23:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.142.143 with HTTP; Sat, 3 May 2014 19:22:45 -0700 (PDT) In-Reply-To: <5602569641FB314FB4D9AD5659D41B9C2C1B0AA05D@WSMSG3154V.srv.dir.telstra.com> References: <5351B460.5040709@joelhalpern.com> <5602569641FB314FB4D9AD5659D41B9C2C1B0AA05D@WSMSG3154V.srv.dir.telstra.com> From: Qiong Date: Sun, 4 May 2014 10:22:45 +0800 Message-ID: To: "Pham, Chuong D" Content-Type: multipart/alternative; boundary=089e0158a82a0f493d04f889b3dd Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/oPrYJpOELs8wOPfNxM1jZk24xB0 Cc: "Jim Guichard \(jguichar\)" , "Haeffner, Walter, Vodafone DE" , "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" , "sfc@ietf.org" , "Joel M. Halpern" Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 02:23:31 -0000 --089e0158a82a0f493d04f889b3dd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agree with Chuong and I disapprove the adoption of this draft. Best wishes On Wed, Apr 30, 2014 at 7:35 AM, Pham, Chuong D < Chuong.D.Pham@team.telstra.com> wrote: > Separate drafts for pockets of environments will most likely overlook the > opportunities for identifying commonalities, synergies and reuse factors > between similar use cases for different environments. This is the painful > situation today where silos exist while at this point in time where Mobil= e, > Fixed Broadband and Data Centre are seeing strong forces towards > convergence with SDN, NFV and Cloud technologies. > > An overall draft such as draft-liu or similar must exist as a common > reference point for more detailed level drafts addressing use cases for > specific/pockets of environments while allowing for future > migration/convergence. > > Unless draft-kumar co-exists with high level draft-liu, I see more harm i= n > divergence rather than benefits therefore I disapprove. > > Regards, > Chuong > > > -----Original Message----- > From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com] > Sent: Wednesday, 30 April 2014 2:56 AM > To: Joel M. Halpern; Jim Guichard (jguichar); sfc@ietf.org > Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 > > I also support this draft. Being on DC level this draft will complement > the other use case drafts. Beside typical FW or DPI etc. there should be > not that much overlap with the more carrier services oriented use case > drafts. > > Cheers, Walter > > > -----Urspr=C3=BCngliche Nachricht----- > Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Joel M. Halpern > Gesendet: Samstag, 19. April 2014 01:25 > An: Jim Guichard (jguichar); sfc@ietf.org > Betreff: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 > > I support adoption of this document by the working group. It is a good > starting point for addressing the material it covers, and the working gro= up > should cover that material. > > Yours, > Joel > > On 4/18/14, 6:31 PM, Jim Guichard (jguichar) wrote: > > Dear WG: > > > > This message begins a two week call for WG adoption of the document > > http://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd > > May 2014. > > > > Please respond to the SFC mailing list with any statements of approval > > or disapproval. > > > > Please note: > > > > 1. This is not WG Last Call. The document is not final, and the WG is > > expected to modify the document's content until there is WG > > consensus that the content is solid. Therefore, please don't oppose > > adoption just because you want to see changes to its content. > > 2. If you have objections to adoption of the document, please state > > your reasons why, and explain what it would take to address your > > concerns. > > 3. If you have issues with the content, by all means raise those issue= s > > and we can begin a dialog about how best to address them. > > > > > > > > _______________________________________________ > > 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 mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Qiong Sun China Telecom Beijing Research Institute =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --089e0158a82a0f493d04f889b3dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agree with=C2=A0Chuong=C2=A0and I disapprove the a= doption of this draft.

Best wishes


On Wed, Apr 30, 2014 at 7:35 AM, Pham, Chuon= g D <Chuong.D.Pham@team.telstra.com> wrote:
=
Separate drafts for pockets of environments will most likely overlook the o= pportunities for identifying commonalities, synergies and reuse factors bet= ween similar use cases for different environments. This is the painful situ= ation today where silos exist while at this point in time where Mobile, Fix= ed Broadband and Data Centre are seeing strong forces towards convergence w= ith SDN, NFV and Cloud technologies.

An overall draft such as draft-liu or similar must exist as a common refere= nce point for more detailed level drafts addressing use cases for specific/= pockets of environments while allowing for future migration/convergence.
Unless draft-kumar co-exists with high level draft-liu, I see more harm in = divergence rather than benefits therefore I disapprove.

Regards,
Chuong


-----Original Message-----
From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com]
Sent: Wednesday, 30 April 2014 2:56 AM
To: Joel M. Halpern; Jim Guichard (jguichar); sfc@ietf.org
Cc: Jeffrey Napper (jenapper) (jenapp= er@cisco.com)
Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01

I also support this draft. Being on DC level this draft will complement the= other use case drafts. Beside typical FW or DPI etc. there should be not t= hat much overlap with the more carrier services oriented use case drafts.
Cheers, Walter


-----Urspr=C3=BCngliche Nachricht-----
Von: sfc [mailto:sfc-bounces@ietf.o= rg] Im Auftrag von Joel M. Halpern
Gesendet: Samstag, 19. April 2014 01:25
An: Jim Guichard (jguichar); sfc@ietf.org
Betreff: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01

I support adoption of this document by the working group. =C2=A0It is a goo= d starting point for addressing the material it covers, and the working gro= up should cover that material.

Yours,
Joel

On 4/18/14, 6:31 PM, Jim Guichard (jguichar) wrote:
> Dear WG:
>
> This message begins a two week call for WG adoption of the document > http://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.t= xt ending 2nd
> May 2014.
>
> Please respond to the SFC mailing list with any statements of approval=
> or disapproval.
>
> Please note:
>
> =C2=A01. This is not WG Last Call. The document is not final, and the = WG is
> =C2=A0 =C2=A0 expected to modify the document's content until ther= e is WG
> =C2=A0 =C2=A0 consensus that the content is solid. Therefore, please d= on't oppose
> =C2=A0 =C2=A0 adoption just because you want to see changes to its con= tent.
> =C2=A02. If you have objections to adoption of the document, please st= ate
> =C2=A0 =C2=A0 your reasons why, and explain what it would take to addr= ess your
> =C2=A0 =C2=A0 concerns.
> =C2=A03. If you have issues with the content, by all means raise those= issues
> =C2=A0 =C2=A0 and we can begin a dialog about how best to address them= .
>
>
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>

_______________________________________________
sfc mailing list
sfc@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sfc


_______________________________________________
sfc mailing list
sfc@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sfc



--
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Su= n
China Telecom Beijing Research Institute

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--089e0158a82a0f493d04f889b3dd-- From nobody Sat May 3 22:13:49 2014 Return-Path: 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 4F4101A000E for ; Sat, 3 May 2014 22:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 wHvoS9IUXoc0 for ; Sat, 3 May 2014 22:13:45 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id ABFC81A000B for ; Sat, 3 May 2014 22:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1675; q=dns/txt; s=iport; t=1399180423; x=1400390023; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=wnikoHOeCkaBrkb2AvLGtnA6335j2E83/4Zvbts872g=; b=K4bV8xgBheapFEydFuBdhLJHdTtEVKIPaisPXc5RvK9kBxgd5kZ5B/Dw hl7NkJycuvfduJXBJHGSoRbqzgLoMJUdjxysstHhO6A+FkeNrY0QMeoL+ 2ub/oYHR4UlXt/LrJ8iibNdmOQGoQ01vKGY6XbMCuh80CNlqP7DspKt8E 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAHALzLZVOtJA2K/2dsb2JhbABZgwZPUQfEaIEQFnSCJQEBAQQ6PRICAQg2EDIbAQYDAgQTCYg4CAXJcBeOWYQ/BJk0gTyROIM0bYFC X-IronPort-AV: E=Sophos;i="4.97,980,1389744000"; d="scan'208";a="40872759" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP; 04 May 2014 05:13:42 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s445DgKh031878 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 4 May 2014 05:13:42 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.14]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Sun, 4 May 2014 00:13:42 -0500 From: "Surendra Kumar (smkumar)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-kumar-sfc-dc-use-cases-02.txt Thread-Index: AQHPZ1YaZo0UkuO5o0qvCnQ3ET7TUZsvvwUA Date: Sun, 4 May 2014 05:13:42 +0000 Message-ID: References: <20140504050251.23933.69979.idtracker@ietfa.amsl.com> In-Reply-To: <20140504050251.23933.69979.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.21.144.3] Content-Type: text/plain; charset="us-ascii" Content-ID: <570F2DFDD3C7F045B8BB9691825E878E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/NxU-oLHuBTx5H0_q3du4F9fN-CM Subject: [sfc] FW: New Version Notification for draft-kumar-sfc-dc-use-cases-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 05:13:47 -0000 All: We have posted a new draft to include minor clarification updates and new co-authors. Surendra. On 5/3/14 10:02 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-kumar-sfc-dc-use-cases-02.txt >has been successfully submitted by Surendra Kumar and posted to the >IETF repository. > >Name: draft-kumar-sfc-dc-use-cases >Revision: 02 >Title: Service Function Chaining Use Cases In Data Centers >Document date: 2014-05-03 >Group: Individual Submission >Pages: 18 >URL: =20 >http://www.ietf.org/internet-drafts/draft-kumar-sfc-dc-use-cases-02.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-kumar-sfc-dc-use-cases/ >Htmlized: http://tools.ietf.org/html/draft-kumar-sfc-dc-use-cases-02 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-kumar-sfc-dc-use-cases-02 > >Abstract: > Data center operators deploy a variety of layer 4 through layer 7 > service functions in both physical and virtual form factors. Most > traffic originating, transiting, or terminating in the data center is > subject to treatment by multiple service functions. > > This document describes use cases that demonstrate the applicability > of Service Function Chaining (SFC) within a data center environment > and provides SFC requirements for data center centric use cases, with > primary focus on Enterprise data centers. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > From nobody Sun May 4 04:34:53 2014 Return-Path: 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 2458F1A0117 for ; Sun, 4 May 2014 04:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 wmrwO0ww5u0H for ; Sun, 4 May 2014 04:34:49 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id BE6DC1A0076 for ; Sun, 4 May 2014 04:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2768; q=dns/txt; s=iport; t=1399203287; x=1400412887; h=from:to:subject:date:message-id:mime-version; bh=JpRXa6Nyi7V1f+/0IibwA+9Z1AZ7eTvMyyx0PWI4M1U=; b=cJ4sLxz53QvoAx4RKEtqQyedUUL8RB1DGG/JmrwkKgrGCBpIvfSzv93r p+USl/fumuSUfd3R6ZtRjLwGEK/fckgP3NcMpS8/p5kqCwROQtnC6h46U +1pPa1/fT13GFvksZvhBsMv65RqFzQwvnVyWHFIhDz86MwvF9UIEJgxOD M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoHAAAlZlOtJV2d/2dsb2JhbABZgkJEgSeqUwEBAQUBmxkWdIIsHVEdAQwBcycEiFSWerMaF4VWjUIEmTSSdIM0gi8 X-IronPort-AV: E=Sophos;i="4.97,982,1389744000"; d="scan'208,217";a="322276346" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 04 May 2014 11:34:46 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s44BYkbi014330 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 4 May 2014 11:34:46 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.229]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Sun, 4 May 2014 06:34:46 -0500 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: WG acceptance of DC use case document Thread-Index: AQHPZ4zZmOCxvX5ZJUmDR/KJEmbqkQ== Date: Sun, 4 May 2014 11:34:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.43.180] Content-Type: multipart/alternative; boundary="_000_CF8B9E132033Djguicharciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/p1Vd3_PdHU4ZCGrTRfWZsegUI_I Subject: [sfc] WG acceptance of DC use case document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 11:34:51 -0000 --_000_CF8B9E132033Djguicharciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings: Thank you for your responses on the call for adoption of draft-kumar-sfc-dc= -use-cases. Overall there seems to be general consensus that the document p= rovides relevant content and is a good baseline for documenting both SP and= Enterprise/cloud use cases and should serve as the basis for a WG document= . While several folks have expressed concern that particular content is curre= ntly missing from the document, please note that the omission of content is= normal process and the WG is expected to modify the document until there i= s WG consensus that the content is solid and complete. Therefore, if you be= lieve there is content missing please have that discussion either directly = with the authors or (preferably) on the mailing list so that all concerns b= ecome addressed and reflected (as appropriate) within the document. Authors, please post a new version as draft-ietf-sfc-dc-use-cases-00. Jim & Thomas. --_000_CF8B9E132033Djguicharciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <50C02B3EB92E0248AE35B98D112CAC45@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Greetings:

Thank you for your responses on the call for adoption of draft-kumar-s= fc-dc-use-cases. Overall there seems to be general consensus that the docum= ent provides relevant content and is a good baseline for documenting both S= P and Enterprise/cloud use cases and should serve as the basis for a WG document.

While several folks have expressed concern that particular content is = currently missing from the document, please note that the omission of conte= nt is normal process and the WG is expected to modify the document until th= ere is WG consensus that the content is solid and complete. Therefore, if you believe there is content missing = please have that discussion either directly with the authors or (preferably= ) on the mailing list so that all concerns become addressed and reflected (= as appropriate) within the document.

Authors, please post a new version as draft-ietf-sfc-dc-use-cases-00.<= /div>

Jim & Thomas.


--_000_CF8B9E132033Djguicharciscocom_-- From nobody Sun May 4 13:47:19 2014 Return-Path: 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 B19791A01D7; Sun, 4 May 2014 13:46:57 -0700 (PDT) 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] autolearn=unavailable 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 nAxA5pNwt2yO; Sun, 4 May 2014 13:46:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0CB1A0182; Sun, 4 May 2014 13:44:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140504204442.1294.14043.idtracker@ietfa.amsl.com> Date: Sun, 04 May 2014 13:44:42 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/mkc8s801duOh9FKpjfcfAQKxYkE Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-dc-use-cases-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 20:46:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining Working Group of the IETF. Title : Service Function Chaining Use Cases In Data Centers Authors : Surendra Kumar Cesar Obediente Mudassir Tufail Sumandra Majee Claudiu Captari Filename : draft-ietf-sfc-dc-use-cases-00.txt Pages : 18 Date : 2014-05-04 Abstract: Data center operators deploy a variety of layer 4 through layer 7 service functions in both physical and virtual form factors. Most traffic originating, transiting, or terminating in the data center is subject to treatment by multiple service functions. This document describes use cases that demonstrate the applicability of Service Function Chaining (SFC) within a data center environment and provides SFC requirements for data center centric use cases, with primary focus on Enterprise data centers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-dc-use-cases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sfc-dc-use-cases-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun May 4 19:33:42 2014 Return-Path: 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 218071A020F for ; Sun, 4 May 2014 19:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 XCBAOY2pd8qw for ; Sun, 4 May 2014 19:33:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EC0801A020E for ; Sun, 4 May 2014 19:33:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDU93363; Mon, 05 May 2014 02:33:35 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 5 May 2014 03:32:23 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 5 May 2014 03:33:34 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Mon, 5 May 2014 10:33:30 +0800 From: "Songhaibin (A)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: WG acceptance of DC use case document Thread-Index: AQHPZ4zZmOCxvX5ZJUmDR/KJEmbqkZsxO/8w Date: Mon, 5 May 2014 02:33:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.49] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F650C1329nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ghOXMV-LFxc0Wo_SzR5KHxb5Cqg Subject: Re: [sfc] WG acceptance of DC use case document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 02:33:41 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F650C1329nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear SFC Chairs, I have one logistic question, while the object of this call for adoption ac= tion is draft-kumar-sfc-dc-use-cases-01, why does the working group documen= t draft-ietf-sfc-dc-use-cases-00 have the same text with draft-kumar-sfc-dc= -use-cases-02? Did the WG call for the adoption of draft-kumar-sfc-dc-use-c= ases-02? Or I missed that email from the list? Best Regards! -Haibin From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Sunday, May 04, 2014 7:35 PM To: sfc@ietf.org Subject: [sfc] WG acceptance of DC use case document Greetings: Thank you for your responses on the call for adoption of draft-kumar-sfc-dc= -use-cases. Overall there seems to be general consensus that the document p= rovides relevant content and is a good baseline for documenting both SP and= Enterprise/cloud use cases and should serve as the basis for a WG document= . While several folks have expressed concern that particular content is curre= ntly missing from the document, please note that the omission of content is= normal process and the WG is expected to modify the document until there i= s WG consensus that the content is solid and complete. Therefore, if you be= lieve there is content missing please have that discussion either directly = with the authors or (preferably) on the mailing list so that all concerns b= ecome addressed and reflected (as appropriate) within the document. Authors, please post a new version as draft-ietf-sfc-dc-use-cases-00. Jim & Thomas. --_000_E33E01DFD5BEA24B9F3F18671078951F650C1329nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear SFC C= hairs,

 = ;

I have one= logistic question, while the object of this call for adoption action is dr= aft-kumar-sfc-dc-use-cases-01, why does the working group document draft-ietf-sfc-dc-use-cases-00 have the same text with draft-kuma= r-sfc-dc-use-cases-02? Did the WG call for the adoption of draft-kumar-sfc-= dc-use-cases-02? Or I missed that email from the list?

 =

Best Regards!

-Haibin

 = ;

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Sunday, May 04, 2014 7:35 PM
To: sfc@ietf.org
Subject: [sfc] WG acceptance of DC use case document

 

Greetings:

 <= /o:p>

Thank you fo= r your responses on the call for adoption of draft-kumar-sfc-dc-use-cases. = Overall there seems to be general consensus that the document provides relevant content and is a good baseline for documenting both SP a= nd Enterprise/cloud use cases and should serve as the basis for a WG docume= nt.

 <= /o:p>

While severa= l folks have expressed concern that particular content is currently missing= from the document, please note that the omission of content is normal process and the WG is expected to modify the document until ther= e is WG consensus that the content is solid and complete. Therefore, if you= believe there is content missing please have that discussion either direct= ly with the authors or (preferably) on the mailing list so that all concerns become addressed and reflected (a= s appropriate) within the document.

 <= /o:p>

Authors, ple= ase post a new version as draft-ietf-sfc-dc-use-cases-00.=

 <= /o:p>

Jim & Th= omas.

 <= /o:p>

 <= /o:p>

--_000_E33E01DFD5BEA24B9F3F18671078951F650C1329nkgeml501mbschi_-- From nobody Sun May 4 20:18:27 2014 Return-Path: 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 911C41A022A for ; Sun, 4 May 2014 20:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 OSl5pwG5fwNK for ; Sun, 4 May 2014 20:18:23 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id EDDB31A022B for ; Sun, 4 May 2014 20:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19532; q=dns/txt; s=iport; t=1399259900; x=1400469500; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/e+XxG3Lw9qsNJGQSz6ZnISJz3EkuEXz2lFxIn6UsDg=; b=Jr3o0jMIWKQ70sVWL3zLXi8Mpf62cAksfGS3l0It63uZoPQAfP5vKNlZ kK4+JZ2XZq/o3E4WlD+2AbsfNVqjEdvO7cRGy+TkUocpQzSdm30SClfV8 w3V6eRBQgCgklmM4B7QCPiqQ0dm010Gx9NX/kzeWvGrqRWpeqp7udFzv4 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8IAJABZ1OtJV2b/2dsb2JhbABYgkJET1iqIgEBAQEBAQUBklEBhziBFhZ0giUBAQEEAQEBawsQAgEIEQEDAQEoByEGCxQDBggCBA4FCRKIEgMRDcNVDYZEF4VWhmWBNRACAUsEBgGDKoEVBJdCgXKNF4VdgzRtgUI X-IronPort-AV: E=Sophos;i="4.97,984,1389744000"; d="scan'208,217";a="319319892" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 05 May 2014 03:18:19 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s453IJ70027928 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 May 2014 03:18:19 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Sun, 4 May 2014 22:18:18 -0500 From: "Carlos Pignataro (cpignata)" To: "sfc@ietf.org" Thread-Topic: [sfc] IPR related to draft-ietf-sfc-problem-statement Thread-Index: AQHPaBCoBiIR3LM1WEu47gblHIsyrw== Date: Mon, 5 May 2014 03:18:18 +0000 Message-ID: <0C1E7E86-07D7-45B0-B49D-391A2E6D8833@cisco.com> References: <94C682931C08B048B7A8645303FDC9F36F58B44EEF@PUEXCB1B.nanterre.francetelecom.fr> <15840_1398406976_5359FF40_15840_14055_1_5af784ba-d2f3-4684-ba30-1e4bcb8f9c3b@OPEXCLILH01.corporate.adroot.infra.ftgroup> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6F5984@szxema506-mbs.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645CFFA6E@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.210.5] Content-Type: multipart/alternative; boundary="_000_0C1E7E8607D745B0B49D391A2E6D8833ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/XhnGaN8ytm3OWs8JC3XhbroqXrU Cc: "Andrew G. Malis" , Med Boucadair , Ron Parker , Linda Dunbar Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 03:18:25 -0000 --_000_0C1E7E8607D745B0B49D391A2E6D8833ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable SFCers, Thomas, I think the line of reasoning proposed at the beginning of this thread is n= ot only fallacious but also quite dangerous. The first email on this thread from Med is basically saying/implying that a= n existing IPR disclosure for draft-ietf-sfc-problem-statement applies to a= particular section of that document only (Section 3), and also that conseq= uently that specific Section ought to be removed (regardless of licensing t= erms of that IPR disclosure). Both are, IMHO, non-sequitur. I am not a lawyer and I do not play one on this list -- however, it *cannot= * be inferred from the IPR disclosure that the IPR only applies to Section = 3. Similarly, it cannot be concluded as a consequence that a Section of a d= ocument should be surgically removed. Both statements are misleading. There are many reasons for which an IPR disclosure can apply to a Problem S= tatement document, to a Use Case document, to a Requirements document, and = of course to an Architecture and Protocol documents. I think it is dangerou= s to correlate the IPR to a specific section, and even worst to a particula= r action concerning such section. You can see other examples searching at h= ttps://datatracker.ietf.org/ipr/search/ The IPR disclosure points to Patent No: 7200679, that subject matter *may* = apply, and all of us should consider this and make an assessment on the WGL= C. However, the oversimplification below is incorrect and harmful. More importantly, there is really not full consensus (to my knowledge, ADs = please clarify otherwise) regardless the transitive nature of IPR disclosur= es and their terms. The disclosure applies to draft-quinn-sfc-problem-state= ment-02, and there is no explicit disclosure for any version of draft-ietf-= sfc-problem-statement. That ought to be clarified. See for example the disc= ussion at http://www.ietf.org/mail-archive/web/ipr-wg/current/msg06187.html My 2=A2, Carlos. On Apr 30, 2014, at 3:18 PM, Andrew G. Malis > wrote: I also agree with everyone else on this thread. Cheers, Andy On Wed, Apr 30, 2014 at 1:06 PM, Linda Dunbar > wrote: +1. Linda From: sfc [mailto:sfc-bounces@ietf.org] On Beh= alf Of Ron Parker Sent: Saturday, April 26, 2014 11:19 AM To: Liushucheng (Will) Cc: Jiangyuanlong; BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org; christian.jacquenet@orange.com Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement +1 Ron On Apr 25, 2014, at 9:21 PM, "Liushucheng (Will)" > wrote: +1. According to what we have agreed on the charter about the PS, =93This document will provide a summary of the problem space to be addressed by the SFC working group including example high-level use cases. Additionally, the working group will normalize nomenclature and definitions for service function chaining.=94 The part related to explicit architecture should be merged into the archite= cture document. Regards, Will (Shucheng LIU) From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Friday, April 25, 2014 7:35 PM To: christian.jacquenet@orange.com; = BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement +1, Section 3 addresses the architectural elements, which should be conside= red in a separate architecture document. From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of christian.jacquenet@or= ange.com Sent: Friday, April 25, 2014 2:23 PM To: BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement WG, I=92d like to second Med=92s comment: an IPR disclosure is a bit incongruou= s for a document that is supposed to document a problem statement and only = a problem statement. From this perspective, the current Section 3 is no les= s misplaced. Cheers, Christian. De : sfc [mailto:sfc-bounces@ietf.org] De la part de mohamed.boucadair@oran= ge.com Envoy=E9 : jeudi 24 avril 2014 08:27 =C0 : sfc@ietf.org Objet : [sfc] IPR related to draft-ietf-sfc-problem-statement Dear all, When checking the tracker, I found there is an IPR disclosure for the probl= em statement document: https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraf= t-ietf-sfc-problem-statement I=92m surprised to see such disclosure for a document that is supposed to d= escribe only problems (except section 3). I=92m re-iterating my comment to remove section 3 from the PS draft as it s= eems this is the only part that is close to the solution part than the prob= lem discussion. Cheers, Med _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_0C1E7E8607D745B0B49D391A2E6D8833ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <042919031DA7BC4C8DD32457EA0F4DAE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable SFCers, Thomas,

I think the line of reasoning proposed at the beginning of this thread= is not only fallacious but also quite dangerous.

The first email on this thread from Med is basically saying/implying t= hat an existing IPR disclosure for draft-ietf-sfc-problem-statement ap= plies to a particular section of that document only (Section 3), and also t= hat consequently that specific Section ought to be removed (regardless of licensing terms of that IPR disclosure)= . Both are, IMHO, non-sequitur.

I am not a lawyer and I do not play one on this list -- however, it *c= annot* be inferred from the IPR disclosure that the IPR only applies to Sec= tion 3. Similarly, it cannot be concluded as a consequence that a Section o= f a document should be surgically removed. Both statements are misleading.

There are many reasons for which an IPR disclosure can apply to a Prob= lem Statement document, to a Use Case document, to a Requirements document,= and of course to an Architecture and Protocol documents. I think it is dan= gerous to correlate the IPR to a specific section, and even worst to a particular action concerning such se= ction. You can see other examples searching at https://datatracker.ietf.org/ipr/search/<= /div>

The IPR disclosure points to Patent No: 7200679, that subject mat= ter *may* apply, and all of us should consider this and make an assessment = on the WGLC. However, the oversimplification below is incorrect and harmful= .

More importantly, there is really not full consensus (to my knowledge,= ADs please clarify otherwise) regardless the transitive nature of IPR disc= losures and their terms. The disclosure applies to draft-quinn-sfc-problem-= statement-02, and there is no explicit disclosure for any version of draft-ietf-sfc-problem-statement. That ought= to be clarified. See for example the discussion at http://www.ietf.org/mail-archive/web/ipr-wg/current/msg06187.html

My 2=A2,

Carlos.

On Apr 30, 2014, at 3:18 PM, Andrew G. Malis <agmalis@gmail.com> wrote:

I also agree with everyone else on this thread.

Cheers,
Andy


On Wed, Apr 30, 2014 at 1:06 PM, Linda Dunbar <linda.dunb= ar@huawei.com> wrote:

+1. =

 

Linda

 

From: sfc [mai= lto:sfc-bounces@i= etf.org] On Behalf Of Ron Parker
Sent: Saturday, April 26, 2014 11:19 AM
To: Liushucheng (Will)
Cc: Jiangyuanlong; BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org; christian.jacquenet@orange.com


Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement

 

+1

 

  Ron

 


On Apr 25, 2014, at 9:21 PM, "Liushucheng (Will)" <liushucheng@huawei.com= > wrote:

+1. =

 

According to what we h= ave agreed on the charter about the PS,

 =93This document= will provide a summary of the
problem space to be addressed by the SFC working group including
example high-level use cases. Additionally, the working group will
normalize nomenclature and definitions for service function chaining.=94

The part related to ex= plicit architecture should be merged into the architecture document.=

 

Regards,=

Will (Shucheng LIU)

 

From: sfc [mailto:sfc-bounces@i= etf.org] On Behalf Of Jiangyuanlong
Sent: Friday, April 25, 2014 7:35 PM
To: christian.jacquenet@orange.com; BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement

 

+= 1, Section 3 addresses the architectural elements, which should be consider= ed in a separate architecture document.

 = ;

From: sfc [mailto:sfc-bounces@i= etf.org] On Behalf Of christian.jacquenet@orange.com
Sent: Friday, April 25, 2014 2:23 PM
To: BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement

 

WG,

 

I=92d like to second Med=92s comment: an IPR= disclosure is a bit incongruous for a document that is supposed to documen= t a problem statement and only a problem statement. From this perspective, the current Section 3 is no less misplaced.<= u>

 

Cheers,

 

Christian.

 

De :<= /span> sfc [mailto:sfc-bounces@ietf.org] De la part de mohamed.boucadair@orange.com
Envoy=E9 : jeudi 24 avril 2014 08:27
=C0 : sfc@iet= f.org
Objet : [sfc] IPR related to draft-ietf-sfc-problem-statement

 

Dear all,<= /p>

 

When checking the tracker, I fo= und there is an IPR disclosure for the problem statement document:

https://datatracker.ietf.org/ipr/search/?op= tion=3Ddocument_search&id=3Ddraft-ietf-sfc-problem-statement

 

I=92m surprised to see such dis= closure for a document that is supposed to describe only problems (except s= ection 3).

 

I=92m re-iterating my comment t= o remove section 3 from the PS draft as it seems this is the only part that= is close to the solution part than the problem discussion.

 

Cheers,

Med


_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

--_000_0C1E7E8607D745B0B49D391A2E6D8833ciscocom_-- From nobody Sun May 4 20:32:08 2014 Return-Path: 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 AB47B1A023E for ; Sun, 4 May 2014 20:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 6utU0LMzAaPs for ; Sun, 4 May 2014 20:32:05 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 087661A01BD for ; Sun, 4 May 2014 20:32:05 -0700 (PDT) Received: from [192.168.1.8] (unknown [119.95.153.210]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id A68791802AD1; Mon, 5 May 2014 05:31:59 +0200 (CEST) Message-ID: <5367062D.5040002@pi.nu> Date: Mon, 05 May 2014 05:31:57 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Songhaibin (A)" , "Jim Guichard (jguichar)" , "sfc@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/hLerJoJ5jD5dnm0s2NPbHhZuMEM Subject: Re: [sfc] WG acceptance of DC use case document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 03:32:07 -0000 Haibin, I will let the the wg chairs respond exactly why the -02 text did go into the wg-doc. First, I have no problem with this procedure,; given that you do not have the opinion that these updtes should not have been made. The only drawback is that document history is a little bit harder to follow. I think that the wg chairs believe, as I do, that the call for adoption is part of the working group process and consensus reach within the call can be incorporated into the wg, either directly or via a new individual document. Secondly (personal opnion), I think it is a better practice: - not to update any document that is is in any type of consensus call (wg adoption, wglc or IETF LC), save the comments and agreements and update after the call; thus avoiding confusing which document version that is under discussion. - make the first version of the wg document the same as the document that was polled for adoption, and do the update quickly on the wg once the first version is published. - use the data tracker to capture what state the document is in /Loa On 2014-05-05 04:33, Songhaibin (A) wrote: > Dear SFC Chairs, > > I have one logistic question, while the object of this call for adoption > action is draft-kumar-sfc-dc-use-cases-01, why does the working group > document draft-ietf-sfc-dc-use-cases-00 have the same text with > draft-kumar-sfc-dc-use-cases-02? Did the WG call for the adoption of > draft-kumar-sfc-dc-use-cases-02? Or I missed that email from the list? > > Best Regards! > > -Haibin > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard > (jguichar) > *Sent:* Sunday, May 04, 2014 7:35 PM > *To:* sfc@ietf.org > *Subject:* [sfc] WG acceptance of DC use case document > > Greetings: > > Thank you for your responses on the call for adoption of > draft-kumar-sfc-dc-use-cases. Overall there seems to be general > consensus that the document provides relevant content and is a good > baseline for documenting both SP and Enterprise/cloud use cases and > should serve as the basis for a WG document. > > While several folks have expressed concern that particular content is > currently missing from the document, please note that the omission of > content is normal process and the WG is expected to modify the document > until there is WG consensus that the content is solid and complete. > Therefore, if you believe there is content missing please have that > discussion either directly with the authors or (preferably) on the > mailing list so that all concerns become addressed and reflected (as > appropriate) within the document. > > Authors, please post a new version as draft-ietf-sfc-dc-use-cases-00. > > Jim & Thomas. > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sun May 4 20:48:36 2014 Return-Path: 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 921B81A0148 for ; Sun, 4 May 2014 20:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 gzUNvd24N9ac for ; Sun, 4 May 2014 20:48:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C15071A00D8 for ; Sun, 4 May 2014 20:48:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGK03691; Mon, 05 May 2014 03:48:27 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 5 May 2014 04:46:56 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 5 May 2014 04:48:26 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Mon, 5 May 2014 11:48:23 +0800 From: "Songhaibin (A)" To: Loa Andersson , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] WG acceptance of DC use case document Thread-Index: AQHPZ4zZmOCxvX5ZJUmDR/KJEmbqkZsxO/8w//+T7YCAAIjFkA== Date: Mon, 5 May 2014 03:48:22 +0000 Message-ID: References: <5367062D.5040002@pi.nu> In-Reply-To: <5367062D.5040002@pi.nu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/KDRZaoYSZjmlxd86cSFMUljXZWw Subject: Re: [sfc] WG acceptance of DC use case document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 03:48:34 -0000 Loa, > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Monday, May 05, 2014 11:32 AM > To: Songhaibin (A); Jim Guichard (jguichar); sfc@ietf.org > Subject: Re: [sfc] WG acceptance of DC use case document >=20 > Haibin, >=20 > I will let the the wg chairs respond exactly why the -02 text did go into= the > wg-doc. >=20 > First, I have no problem with this procedure,; given that you do not have= the > opinion that these updtes should not have been made. The only drawback is > that document history is a little bit harder to follow. >=20 > I think that the wg chairs believe, as I do, that the call for adoption i= s part of > the working group process and consensus reach within the call can be > incorporated into the wg, either directly or via a new individual documen= t. >=20 > Secondly (personal opnion), I think it is a better practice: >=20 > - not to update any document that is is in any type of consensus call > (wg adoption, wglc or IETF LC), save the comments and agreements and > update after the call; thus avoiding confusing which document version > that is under discussion. > - make the first version of the wg document the same as the document > that was polled for adoption, and do the update quickly on the wg once > the first version is published. > - use the data tracker to capture what state the document is in I believe what you said here is the right way to do it. Make the first vers= ion of WG document the same with the individual draft version that was call= ed for adoption, and then make any change according to WG consensus. -Haibin > /Loa >=20 >=20 >=20 >=20 > On 2014-05-05 04:33, Songhaibin (A) wrote: > > Dear SFC Chairs, > > > > I have one logistic question, while the object of this call for > > adoption action is draft-kumar-sfc-dc-use-cases-01, why does the > > working group document draft-ietf-sfc-dc-use-cases-00 have the same > > text with draft-kumar-sfc-dc-use-cases-02? Did the WG call for the > > adoption of draft-kumar-sfc-dc-use-cases-02? Or I missed that email fro= m the > list? > > > > Best Regards! > > > > -Haibin > > > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard > > (jguichar) > > *Sent:* Sunday, May 04, 2014 7:35 PM > > *To:* sfc@ietf.org > > *Subject:* [sfc] WG acceptance of DC use case document > > > > Greetings: > > > > Thank you for your responses on the call for adoption of > > draft-kumar-sfc-dc-use-cases. Overall there seems to be general > > consensus that the document provides relevant content and is a good > > baseline for documenting both SP and Enterprise/cloud use cases and > > should serve as the basis for a WG document. > > > > While several folks have expressed concern that particular content is > > currently missing from the document, please note that the omission of > > content is normal process and the WG is expected to modify the > > document until there is WG consensus that the content is solid and comp= lete. > > Therefore, if you believe there is content missing please have that > > discussion either directly with the authors or (preferably) on the > > mailing list so that all concerns become addressed and reflected (as > > appropriate) within the document. > > > > Authors, please post a new version as draft-ietf-sfc-dc-use-cases-00. > > > > Jim & Thomas. > > > > > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sun May 4 22:06:13 2014 Return-Path: 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 EAB8A1A024A for ; Sun, 4 May 2014 22:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 fGnPK4dPolHG for ; Sun, 4 May 2014 22:06:09 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6C91A0249 for ; Sun, 4 May 2014 22:06:09 -0700 (PDT) Received: from [192.168.1.8] (unknown [119.95.153.210]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 02BCE1802AD1; Mon, 5 May 2014 07:06:02 +0200 (CEST) Message-ID: <53671C39.7060805@pi.nu> Date: Mon, 05 May 2014 07:06:01 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" , "sfc@ietf.org" References: <94C682931C08B048B7A8645303FDC9F36F58B44EEF@PUEXCB1B.nanterre.francetelecom.fr> <15840_1398406976_5359FF40_15840_14055_1_5af784ba-d2f3-4684-ba30-1e4bcb8f9c3b@OPEXCLILH01.corporate.adroot.infra.ftgroup> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6F5984@szxema506-mbs.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645CFFA6E@dfweml701-chm.china.huawei.com> <0C1E7E86-07D7-45B0-B49D-391A2E6D8833@cisco.com> In-Reply-To: <0C1E7E86-07D7-45B0-B49D-391A2E6D8833@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/IgS5BIx8M4dlgE4P8etXkZK0q1U Cc: Med Boucadair , "Andrew G. Malis" , Ron Parker , Linda Dunbar Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 05:06:11 -0000 Carlos, On 2014-05-05 05:18, Carlos Pignataro (cpignata) wrote: > More importantly, there is really not full consensus (to my knowledge, > ADs please clarify otherwise) regardless the transitive nature of IPR > disclosures and their terms. The disclosure applies to > draft-quinn-sfc-problem-statement-02, and there is no explicit > disclosure for any version of draft-ietf-sfc-problem-statement. That > ought to be clarified. See for example the discussion at > http://www.ietf.org/mail-archive/web/ipr-wg/current/msg06187.html As a working group I think we need to be conservative and assume that a blanket IPR disclosure will be applicable to the working group document. After all there is only a very simple statement from the IPR holder to say that this is the case. But - yes I think from a legal point of view "transitveness" is a very messy issue. I think that the ADs and lawyers can say that they are not transitive, but as long as that is legally tested we simply don't know. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sun May 4 23:14:32 2014 Return-Path: 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 627F41A025D for ; Sun, 4 May 2014 23:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 U3C1e0CknCZJ for ; Sun, 4 May 2014 23:14:26 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB121A0258 for ; Sun, 4 May 2014 23:14:25 -0700 (PDT) Received: from [192.168.1.8] (unknown [119.95.153.210]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 42AE71802AD1; Mon, 5 May 2014 08:14:19 +0200 (CEST) Message-ID: <53672C3A.8020303@pi.nu> Date: Mon, 05 May 2014 08:14:18 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Songhaibin (A)" , "Jim Guichard (jguichar)" , "sfc@ietf.org" References: <5367062D.5040002@pi.nu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ZSfBGMEH1MZA0SqGJ9Lrss3zYHM Subject: Re: [sfc] WG acceptance of DC use case document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 06:14:28 -0000 Haibin, On 2014-05-05 05:48, Songhaibin (A) wrote: > Loa, > >> -----Original Message----- >> From: Loa Andersson [mailto:loa@pi.nu] >> Sent: Monday, May 05, 2014 11:32 AM >> To: Songhaibin (A); Jim Guichard (jguichar); sfc@ietf.org >> Subject: Re: [sfc] WG acceptance of DC use case document >> >> Haibin, >> >> I will let the the wg chairs respond exactly why the -02 text did go into the >> wg-doc. >> >> First, I have no problem with this procedure,; given that you do not have the >> opinion that these updtes should not have been made. The only drawback is >> that document history is a little bit harder to follow. >> >> I think that the wg chairs believe, as I do, that the call for adoption is part of >> the working group process and consensus reach within the call can be >> incorporated into the wg, either directly or via a new individual document. >> >> Secondly (personal opnion), I think it is a better practice: >> >> - not to update any document that is is in any type of consensus call >> (wg adoption, wglc or IETF LC), save the comments and agreements and >> update after the call; thus avoiding confusing which document version >> that is under discussion. >> - make the first version of the wg document the same as the document >> that was polled for adoption, and do the update quickly on the wg once >> the first version is published. >> - use the data tracker to capture what state the document is in > > I believe what you said here is the right way to do it. Make the first version of WG document the same with the individual draft version that was called for adoption, and then make any change according to WG consensus. > > -Haibin Yes - we agree - it is only that what was done in this case is allowed, not just optimal, as long as that it can be shown that the comments in the Call for Adoption has working group consensus and were correctly captured. /Loa > > >> /Loa >> >> >> >> >> On 2014-05-05 04:33, Songhaibin (A) wrote: >>> Dear SFC Chairs, >>> >>> I have one logistic question, while the object of this call for >>> adoption action is draft-kumar-sfc-dc-use-cases-01, why does the >>> working group document draft-ietf-sfc-dc-use-cases-00 have the same >>> text with draft-kumar-sfc-dc-use-cases-02? Did the WG call for the >>> adoption of draft-kumar-sfc-dc-use-cases-02? Or I missed that email from the >> list? >>> >>> Best Regards! >>> >>> -Haibin >>> >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard >>> (jguichar) >>> *Sent:* Sunday, May 04, 2014 7:35 PM >>> *To:* sfc@ietf.org >>> *Subject:* [sfc] WG acceptance of DC use case document >>> >>> Greetings: >>> >>> Thank you for your responses on the call for adoption of >>> draft-kumar-sfc-dc-use-cases. Overall there seems to be general >>> consensus that the document provides relevant content and is a good >>> baseline for documenting both SP and Enterprise/cloud use cases and >>> should serve as the basis for a WG document. >>> >>> While several folks have expressed concern that particular content is >>> currently missing from the document, please note that the omission of >>> content is normal process and the WG is expected to modify the >>> document until there is WG consensus that the content is solid and complete. >>> Therefore, if you believe there is content missing please have that >>> discussion either directly with the authors or (preferably) on the >>> mailing list so that all concerns become addressed and reflected (as >>> appropriate) within the document. >>> >>> Authors, please post a new version as draft-ietf-sfc-dc-use-cases-00. >>> >>> Jim & Thomas. >>> >>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon May 5 00:08:32 2014 Return-Path: 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 C5CCA1A026B for ; Mon, 5 May 2014 00:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 QA0sooh6etts for ; Mon, 5 May 2014 00:08:29 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id D90A71A0262 for ; Mon, 5 May 2014 00:08:28 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 4B9D637421F; Mon, 5 May 2014 09:08:24 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 29BC615807B; Mon, 5 May 2014 09:08:24 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Mon, 5 May 2014 09:08:23 +0200 From: To: Thomas Narten Date: Mon, 5 May 2014 09:08:19 +0200 Thread-Topic: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-03.txt) Thread-Index: Ac9mKYV6YnMQ1CoBSiib785bvU9+dACBLnZA Message-ID: <94C682931C08B048B7A8645303FDC9F36F5B63D0E4@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36F544849C9@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.30.105721 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/7uwIUZM6527RH9yDfrfqGP0WFiM Cc: "sfc@ietf.org" Subject: Re: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-03.txt) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 07:08:30 -0000 Thomas, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Thomas Narten [mailto:narten@us.ibm.com] >Envoy=E9=A0: vendredi 2 mai 2014 19:10 >=C0=A0: BOUCADAIR Mohamed IMT/OLN >Cc=A0: sfc@ietf.org >Objet=A0: Re: [sfc] Remove Section 3 from the problem statement (was RE: I= -D >Action: draft-ietf-sfc-problem-statement-03.txt) > >A few comments on this topic. > >At Tue, 1 Apr 2014 13:42:23 +0200, wrote: >> >> Dear all, >> >> I raised this point to the co-authors but I prefer to raise it also in >> the mailing list. >> >> I suggest to remove Section 3 from the draft >> http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-03#section-3= , >> because it goes beyond the problem discussion. That section is more a >> discussion that should be hosted in a framework document. > >I think we should be careful about being too strict about "problem >only" on the problem statement and not allowing any discussion about >solution direction. The entire point of SFC (and indeed any WG problem >statement) is to layout the problem and/or "pain points", but also to >show the general direction of a solution. [Med] I agree on those.=20 If we end up with a document >that only outlines the problems, but provides no hint as to what sort >of solution direction is being contemplated, we have done a disservice >to the reader. [Med] Disagree. The scope of a PS IMO is to discuss problems not hinting so= lutions. I think we need to be humble here: chaining won't solve all the pr= oblems listed in the PS: this is typically the case of the complications re= lated to the management of classification entries, inter-layer correlation = for diagnosis and troubleshooting, etc.=20 > >That said, we of course don't want so much in the solution direction >that it ends up restricting the architecture. But I don't think we are >anywhere close to that. And, even if we were, the architecture >document could overrule any such direction. The WG architecture >document is where the WG makes real decisions and adds detail to >them. [Med] So why including "hints" at the first place in a PS document?=20 > >> Furthermore, some of the points mentioned in that section are >> questionable such as the use of metadata and the need of control >> protocols, etc. Let's avoid mixing objectives and limit the scope of >> the PS I-D to the identification to the problems to be solved. > >We most certainly will be using metadata. I don't see how anyone who >can suggest we won't, given all the discussion so far on the >topic. Also, we will need some sort of control protocol (or management >protocol). Otherwise there is no way to coordinate the state carried >in SFC packets and the various SFs that process packets. What we >haven't worked out is the details of what that metadata looks like >(that's a solution) or what the protocol/management protocols will >look like (again a solution -- plus per the charter, we have at best >only a vague idea of what this might entail). But this is normal for a >WG at this stage of existence. [Med] This is a typical discussion for an architecture document.=20 From nobody Mon May 5 00:08:52 2014 Return-Path: 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 139AD1A0278 for ; Mon, 5 May 2014 00:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 7tx8qGqZdwWv for ; Mon, 5 May 2014 00:08:48 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id DD72B1A026A for ; Mon, 5 May 2014 00:08:47 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 611BD374226; Mon, 5 May 2014 09:08:44 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 4A00EC8064; Mon, 5 May 2014 09:08:44 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Mon, 5 May 2014 09:08:43 +0200 From: To: Thomas Narten , "sfc@ietf.org" Date: Mon, 5 May 2014 09:08:43 +0200 Thread-Topic: [sfc] WG Last Call for SFC Problem Statement Thread-Index: Ac9mSRexqL0O1F/JTpCR+hra+PHuHgB5AfXw Message-ID: <94C682931C08B048B7A8645303FDC9F36F5B63D0E5@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.5.4.13918 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/36A6IWhzO1PND66JsNbBWpMLp5I Subject: Re: [sfc] WG Last Call for SFC Problem Statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 07:08:49 -0000 Hi Thomas, See inline. Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas Narten >Envoy=E9=A0: vendredi 2 mai 2014 22:56 >=C0=A0: sfc@ietf.org >Objet=A0: [sfc] WG Last Call for SFC Problem Statement > >This note begins a 2-week WG Last Call on >draft-ietf-sfc-problem-statement-05.txt. > >There is one outstanding issue that remains, but we can use the LC to >clarify what the WG wants to do. [Med] There is also this one: http://www.ietf.org/mail-archive/web/sfc/curr= ent/msg01772.html. > >Section 3 contains a description that explains the general approach >SFC will use as a solution. There was a request to remove that section >back in January, but there was no consensus to do so. Indeed, there >was also significant support to leave it in, [Med] As far as I know there is no such discussion since the adoption of th= e document as a WG item other than the one I initiated.=20 and that does not appear >to have changed. > >The request came up again in the context of the IPR disclosure >(https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddr= aft- >ietf-sfc-problem-statement); >see my comments on that thread. While we can remove Section 3 in the >hope that it mitigates the IPR concern, doing so would seem to have >little (if any) practical benefit w.r.t. IPR. [Med] That's not the point. The point is to have a PS document that is solu= tion neutral. Claiming an IPR on a document that is supposed to be a PS doc= ument means that document does not only discuss problem but includes also s= olutions.=20 It is, of course, >however the WG's decision as to the dispostion of Section 3. > >Substantive comments to the list please, editorial comments can go >directly to the authors. > >Thomas & Jim > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Mon May 5 00:21:28 2014 Return-Path: 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 D13E01A026A for ; Mon, 5 May 2014 00:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 TKRtTseN50dy for ; Mon, 5 May 2014 00:21:23 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 80EF01A0164 for ; Mon, 5 May 2014 00:21:23 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 578A322C261; Mon, 5 May 2014 09:21:19 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 3AB9D27C053; Mon, 5 May 2014 09:21:19 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Mon, 5 May 2014 09:21:18 +0200 From: To: Thomas Narten Date: Mon, 5 May 2014 09:21:17 +0200 Thread-Topic: [sfc] IPR related to draft-ietf-sfc-problem-statement Thread-Index: Ac9mKX0bfdTQ2aLcSzCdFsmps/KA3ACB2n7w Message-ID: <94C682931C08B048B7A8645303FDC9F36F5B63D0F9@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36F58B44EEF@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.5.4.222419 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/zO2aJW2cjQrf0FK9zwlSIVe-24k Cc: "sfc@ietf.org" Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 07:21:27 -0000 VGhvbWFzLA0KDQpJdCBpcyBub3QgdXAgdG8gbWUgdG8gYXNzZXNzIHRoZSB2YWxpZGl0eSBvZiBh biBJUFIgZGlzY2xvc3VyZS4NCg0KVGhlIG1haW4gcG9pbnQgaXMgdG8gcmV2aXNpdCB0aGUgZHJh ZnQgdG8gbWFrZSBoYXJkIHRvIGFwcGx5IGFuIElQUiBvbiBpdDogdGhpcyBtZWFucyBleGNsdWRl IGFueSBzb2x1dGlvbiBkaXNjdXNzaW9uIChpLmUuIHNlY3Rpb24gMykuIA0KDQpDaGVlcnMsDQpN ZWQNCg0KPi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPkRlwqA6IFRob21hcyBOYXJ0ZW4g W21haWx0bzpuYXJ0ZW5AdXMuaWJtLmNvbV0NCj5FbnZvecOpwqA6IHZlbmRyZWRpIDIgbWFpIDIw MTQgMTk6MTENCj7DgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xODQo+Q2PCoDogc2ZjQGll dGYub3JnDQo+T2JqZXTCoDogUmU6IFtzZmNdIElQUiByZWxhdGVkIHRvIGRyYWZ0LWlldGYtc2Zj LXByb2JsZW0tc3RhdGVtZW50DQo+DQo+TGV0IG1lIHRyeSB0byBzcGxpdCB0aGlzIHRocmVhZCBp bnRvIHR3byBkaWZmZXJlbnQgcGllY2VzLg0KPg0KPkF0IFRodSwgMjQgQXByIDIwMTQgMDg6Mjc6 MjAgKzAyMDAsIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCj4NCj4+IFdo ZW4gY2hlY2tpbmcgdGhlIHRyYWNrZXIsIEkgZm91bmQgdGhlcmUgaXMgYW4gSVBSIGRpc2Nsb3N1 cmUgZm9yIHRoZQ0KPnByb2JsZW0NCj4+IHN0YXRlbWVudCBkb2N1bWVudDoNCj4+DQo+PiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci9zZWFyY2gvP29wdGlvbj1kb2N1bWVudF9zZWFy Y2gmaWQ9DQo+PiBkcmFmdC1pZXRmLXNmYy1wcm9ibGVtLXN0YXRlbWVudA0KPj4NCj4+IEnKvG0g c3VycHJpc2VkIHRvIHNlZSBzdWNoIGRpc2Nsb3N1cmUgZm9yIGEgZG9jdW1lbnQgdGhhdCBpcyBz dXBwb3NlZCB0bw0KPj4gZGVzY3JpYmUgb25seSBwcm9ibGVtcyAoZXhjZXB0IHNlY3Rpb24gMyku DQo+DQo+UGVyc29uYWxseSwgSSdtIHN1cnByaXNlZCB0b28uIEJ1dCBkb2Vzbid0IG1hdHRlci4N Cj4NCj5NYWtpbmcgYW4gSVBSIGRpc2Nsb3N1cmUgaXMgYSBsZWdhbCBkZWNpc2lvbiwgbm90IGFu IGVuZ2luZWVyaW5nDQo+b25lLiBUaGUgSUVURiBpcyBxdWl0ZSBjbGVhciBhYm91dCBJUFIgLS0g YmV0dGVyIHRvIGJlIHNhZmUgYW5kDQo+ZGlzY2xvc2UsIHJhdGhlciB0aGFuIG5vdC4gQW5kIGlu IG15IGV4cGVyaWVuY2UsIElQUiBkaXNjbG9zdXJlcw0KPmFsd2F5cyBoYXZlIGFuIGV4cGxpY2l0 IG9yIGltcGxpY2l0IHVzZSBvZiB0aGUgd29yZCAibWF5IiB0byBpbmRpY2F0ZQ0KPnRoYXQgSVBS ICJtYXkiIGFwcGx5LiBXaGV0aGVyIElQUiBkb2VzIGFjdHVhbGx5IGFwcGx5IHRvIHNwZWNpZmlj DQo+dGVjaG5vbG9neSBpcyBhIG51YW5jZWQgZGlzY3Vzc2lvbiBhbmQgb25lIGludm9sdmluZyBs YXd5ZXJzIGFuZCB0aGUNCj5jb3VydHMuIERpZmZlcmVudCBwZW9wbGUgd2lsbCBoYXZlIGRpZmZl cmVudCBvcGluaW9ucy4NCj4NCj4+IEnKvG0gcmUtaXRlcmF0aW5nIG15IGNvbW1lbnQgdG8gcmVt b3ZlIHNlY3Rpb24gMyBmcm9tIHRoZSBQUyBkcmFmdCBhcyBpdA0KPnNlZW1zDQo+PiB0aGlzIGlz IHRoZSBvbmx5IHBhcnQgdGhhdCBpcyBjbG9zZSB0byB0aGUgc29sdXRpb24gcGFydCB0aGFuIHRo ZSBwcm9ibGVtDQo+PiBkaXNjdXNzaW9uLg0KPg0KPkl0J3MgaGFyZCB0byBzZWUgaG93IHJlbW92 aW5nIHNlY3Rpb24gMyB3aWxsIGhhdmUgYW55IGltcGFjdCBvbiBJUFINCj5yZWxhdGVkIHRvIFNG Qy4gRmlyc3QsIHJlbW92aW5nIHRoZSBzZWN0aW9uIHdpbGwgbm90IG5lY2Vzc2FyaWx5IGxlYWQN Cj50byB0aGUgZGlzY2xvc3VyZSBzdGF0ZW1lbnQgYmVpbmcgcmVtb3ZlZCAoc2VlIGFib3ZlKS4N Cj4NCj5TZWNvbmQsIGlmIHRoZXJlIGFjdHVhbGx5IGlzIGluIGZhY3QgSVBSIHRoYXQgYXBwbGll cyB0byBTRkMsIHRoYXQNCj53aWxsIGJlY29tZSBjbGVhciB3aGVuIHdlIGRldmVsb3Agc29sdXRp b25zLCBhbmQgYWRkaXRpb25hbCBzcGVjaWZpYw0KPmRpc2Nsb3N1cmVzIHdpbGwgbmVlZCB0byBi ZSBtYWRlIHRoZW4uIChNYWtpbmcgYSBkaXNjbG9zdXJlIGZvciBvbmUNCj5kb2N1bWVudCBpc24n dCBlbm91Z2ggLS0gZGlzY2xvc3VyZXMgbmVlZCB0byBiZSBtYWRlIGZvciBldmVyeQ0KPmRvY3Vt ZW50IHRvIHdoaWNoIElQUiBtaWdodCBhcHBseS4pIFRodXMsIHR3ZWFraW5nIHRoZSBwcm9ibGVt DQo+c3RhdGVtZW50IGluIGFuIGF0dGVtcHQgdG8gYXZvaWQgYW4gSVBSIGRpc2Nsb3N1cmUgc2Vl bXMgbW9yZSBsaWtlDQo+d2lzaGZ1bCB0aGlua2luZyB0aGFuIHN1YnN0YW5jZS4gIEFueSBJUFIg dGhhdCBhcHBsaWVzIHRvIHRoZSBwcm9ibGVtDQo+c3RhdGVtZW50IHdpbGwgc3VyZWx5IGNvbWUg dXAgYWdhaW4gaW4gdGhlIGNvbnRleHQgb2Ygc3BlY2lmaWMgYQ0KPnNvbHV0aW9uLiBJTU8sIGl0 IHdvdWxkIGJlIG1vcmUgYXBwcm9wcmlhdGUgZm9yIHRoZSBXRyB0byBkaXNjdXNzIGhvdw0KPnRv IGhhbmRsZSBwb3RlbnRpYWwgSVBSIHdoZW4gZGlzY3Vzc2luZyBzcGVjaWZpYyBzb2x1dGlvbnMg LS0gd2hlbiB3ZQ0KPmNhbiBoYXZlIGEgZGlzY3Vzc2lvbiBpbiB0aGUgY29udGV4dCBvZiBzcGVj aWZpYyB0ZWNobmljYWwgYXBwcm9hY2hlcw0KPnRoYXQgYXJlIGJlaW5nIGNvbnNpZGVyZWQuDQo+ DQo+QSBudW1iZXIgb2YgZm9sayBvbiB0aGlzIHRocmVhZCBoYXZlIGFkZGVkIGEgIisxIi4gSXQg d291bGQgYmUgaGVscGZ1bA0KPnRvIGdldCBhZGRpdGlvbmFsIGNsYXJpdHkgYXMgdG8gd2hldGhl ciB0aGUgYWdyZWVtZW50IGlzIGFib3V0IHRoZQ0KPnN1cnByaXNlIGF0IHRoZSBJUFIgc3RhdGVt ZW50IGFuZCBhIGRlc2lyZSB0byB0cnkgYW5kIGF2b2lkIGhhdmluZyB0aGUNCj5wcm9ibGVtIHN0 YXRlbWVudCBkb2N1bWVudCBoYXZlIGFuIElQUiBkaXNjbG9zdXJlIHN0YXRlbWVudCBhc3NvY2lh dGVkDQo+d2l0aCBpdCwgb3Igd2hldGhlciB0aGVyZSBpcyBhIHN1cHBvcnQgdG8gcmVtb3ZlIHNl Y3Rpb24gMyBmb3Igb3RoZXINCj5yZWFzb25zIHRoYW4gdGhlIElQUiBkaXNjbG9zdXJlICh0aGVy ZSBoYXZlIGJlZW4gZWFybGllci9zZXBhcmF0ZQ0KPnRocmVhZHMgb24gdGhpcyBxdWVzdGlvbiku DQo+DQo+VGhvbWFzDQo+DQo+Pg0KPj4gQ2hlZXJzLA0KPj4NCj4+IE1lZA0KPj4NCj4+DQo+PiBb MiAgPHRleHQvcGxhaW47IHVzLWFzY2lpICg3Yml0KT5dDQo+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4gc2Zj QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K DQo= From nobody Mon May 5 04:39:03 2014 Return-Path: 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 EE0AE1A02F8 for ; Mon, 5 May 2014 04:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 6mIzvU5qTiWA for ; Mon, 5 May 2014 04:38:59 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id CF9BC1A02F2 for ; Mon, 5 May 2014 04:38:58 -0700 (PDT) Received: from [192.168.1.112] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id BEEF22790BAB; Mon, 5 May 2014 07:38:54 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_27D55A57-3AFA-4728-8EAF-76041F6DC51C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Thomas Nadeau In-Reply-To: Date: Mon, 5 May 2014 07:38:43 -0400 Message-Id: <18FEF860-9708-4254-AAEE-8AE9AAECA85F@lucidvision.com> References: <94C682931C08B048B7A8645303FDC9F36F58B44EEF@PUEXCB1B.nanterre.francetelecom.fr> <5364908A.30704@pi.nu> To: "Andrew G. Malis" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/J1QcZgNBX0lG8jTwp8LDIEV2ffQ Cc: Thomas Narten , "mohamed.boucadair@orange.com" , Ron Parker , "sfc@ietf.org" , Loa Andersson Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 11:39:01 -0000 --Apple-Mail=_27D55A57-3AFA-4728-8EAF-76041F6DC51C Content-Type: multipart/alternative; boundary="Apple-Mail=_EA8DF886-75E1-496A-B85E-58BCE4F37A54" --Apple-Mail=_EA8DF886-75E1-496A-B85E-58BCE4F37A54 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii That is a bit of a red herring, isn't it? If the entire = technology/ies is/are encumbered, shouldn't we look at that issue on the = whole? Simply removing a paragraph from one problem statement isn't = going to properly address that issue. Frankly, IPR claims on problem = statements are useless other than they indicate there is IPR hiding = elsewhere. Where IPR claims will really matter is around the solutions. = Based on the claim in question, it is highly likely that there is IPR in = this space. I'd venture that there is anyways given that many = proprietary implementations have existed for some time. Given that, the = question is one of what terms are they under and are they agreeable to = the IETF for the solutions? =20 --Tom > I agree with Loa - RAND on a problem statement implies that the entire = technology is possibly encumbered. It would be best if the draft could = be revised such that the IPR claim no longer applies, if that's even = possible. That said, it's difficult to recommend specific changes = without knowing why the IPR claim was made. Looking at the patent = itself, "Creating distributed proxy configurations" at = http://www.google.com/patents/US7200679 and looking at Figure 3 and = Claim 1 in particular, the implication to me is that it's the entire = technology that's being claimed. If that's the case, then our choices to = look to be: >=20 > - Accept that the entire technology is encumbered with a RAND claim, = and continue on. >=20 > - Drop the entire effort. >=20 > - Ask the claimant to fill in section V.C. of the IPR claim, or = otherwise clarify exactly what they are claiming. >=20 > - Ask the claimant to change their claim from RAND licensing to free = licensing with reciprocity. >=20 > Cheers, > Andy >=20 > On Sat, May 3, 2014 at 2:45 AM, Loa Andersson wrote: > Folks, >=20 >=20 > On 2014-05-02 22:47, Thomas Narten wrote: > 1) Accept it as it is > Right. And this is what happens in practice with most IPR disclosures > these days. I'll just note that there have been some 45 disclosures in > the IETF so far this year. For all of 2013, there were some 279. >=20 > I think the issue is not that most IPR disclosures does not lead to = any > action at all. >=20 > For FRAND statements there is no problems to accept it as it is; = however > this is not FRAND but RAND. >=20 > /Loa >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail=_EA8DF886-75E1-496A-B85E-58BCE4F37A54 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

That is a bit of a red herring, = isn't it?  If the entire technology/ies is/are encumbered, = shouldn't we look at that issue on the whole?  Simply removing a = paragraph from one problem statement isn't going to properly address = that issue.  Frankly, IPR claims on problem statements are useless = other than they indicate there is IPR hiding elsewhere. Where IPR claims = will really matter is around the solutions. Based on the claim in = question, it is highly likely that there is IPR in this space. I'd = venture that there is anyways given that many proprietary = implementations have existed for some time. Given that, the question is = one of what terms are they under and are they agreeable to the IETF for = the solutions?  

= --Tom



I agree with Loa - RAND on a problem = statement implies that the entire technology is possibly encumbered. It = would be best if the draft could be revised such that the IPR claim no = longer applies, if that's even possible. That said, it's difficult to = recommend specific changes without knowing why the IPR claim was made. = Looking at the patent itself, "Creating distributed proxy = configurations" at http://www.google.com/pat= ents/US7200679 and looking at Figure 3 and Claim 1 in particular, = the implication to me is that it's the entire technology that's being = claimed. If that's the case, then our choices to look to be:

- Accept that the entire technology is encumbered with a = RAND claim, and continue on.

- Drop the entire = effort.

- Ask the claimant to fill in section = V.C. of the IPR claim, or otherwise clarify exactly what they are = claiming.

- Ask the claimant to change their claim from RAND = licensing to free licensing with = reciprocity.

Cheers,
Andy

On Sat, May 3, 2014 = at 2:45 AM, Loa Andersson <loa@pi.nu> = wrote:
Folks,


On 2014-05-02 22:47, Thomas Narten wrote:
1) Accept it as it is
Right. And this is what happens in practice with most IPR = disclosures
these days. I'll just note that there have been some 45 disclosures = in
the IETF so far this year. For all of 2013, there were some 279.

I think the issue is not that most IPR disclosures does not lead to = any
action at all.

For FRAND statements there is no problems to accept it as it is; = however
this is not FRAND but RAND.

/Loa

_______________________________________________
sfc mailing = list
sfc@ietf.org
https://www.ietf.org/mail= man/listinfo/sfc

= --Apple-Mail=_EA8DF886-75E1-496A-B85E-58BCE4F37A54-- --Apple-Mail=_27D55A57-3AFA-4728-8EAF-76041F6DC51C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTZ3hDAAoJEPcO+I7eiUJZWXMP/RUMAvPfuMxJuIR23zg+p/6K ZjPoklfw4nTxYRBrKGJCcSb4uhQpH2TAbFcmRgWFBgN9aJnXSkAdNly1dLRvpwOz 3j3CqZDvcOVxqYNSnZPIFcHP5Ce9JwrYu9KXzyt1dLsy9duzgw1hwmTbGtBEmdLs YrLVcJsIXYFtMnqfD2aP+jCDxu5O81Y+tcdcNVT8zw5RZYqYVqvE1zKrMFWDC/WO UBZBjljTzZ3+wAK0M85ybzG8zSB4+/v7Cpy3f26VLsHEsIROFCXzEfDF6LRfVf7x 5LLr+RS0BMbQI4FYEciLPqe52ZfDb/O4PQFee/Waefw0kIILbVZE/6OtFxzktEKt YhBjFUEAHfcI6YeTDREs5BmFS09KY3BLLOiDBEKnIaSxRCD0fHFtCvFCxIoIF1DF uRJoJ+LZHtqslKYjIBZJ0SGstU0q3lEX1clhnop0UCp8SQ3JQXSXQwF0xtzaF3DU TCpuUOp4EWEpzgxoJDxLa9mpRtMtKt6NFURaAjvPf/noYX1rXf8x4mBbZoBMH2WB aLCIxSEbLzwWGaLOibCcAeybI26mEdJkNbR2wOv+ylVwzLIZxbxfzfXQbkXXJut/ m2w0/VU7kgz4Sh9ZZy2EPhvKeBuRK+cvnV+QIc+BXxUrIm/WrazfGlZ1yl6DK/8F i7qIZbpKK87uatgGM3KJ =r7ny -----END PGP SIGNATURE----- --Apple-Mail=_27D55A57-3AFA-4728-8EAF-76041F6DC51C-- From nobody Mon May 5 06:24:18 2014 Return-Path: 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 8447C1A00DF for ; Mon, 5 May 2014 06:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RP_MATCHES_RCVD=-0.651] 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 3QpR4by1ydMI for ; Mon, 5 May 2014 06:24:14 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id E38951A0309 for ; Mon, 5 May 2014 06:24:13 -0700 (PDT) Received: from [192.168.1.8] (unknown [119.95.153.210]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id BEFE51802AD1; Mon, 5 May 2014 15:24:07 +0200 (CEST) Message-ID: <536790F5.30804@pi.nu> Date: Mon, 05 May 2014 15:24:05 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Thomas Nadeau , "Andrew G. Malis" References: <94C682931C08B048B7A8645303FDC9F36F58B44EEF@PUEXCB1B.nanterre.francetelecom.fr> <5364908A.30704@pi.nu> <18FEF860-9708-4254-AAEE-8AE9AAECA85F@lucidvision.com> In-Reply-To: <18FEF860-9708-4254-AAEE-8AE9AAECA85F@lucidvision.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/BbAOrxijrxOlz5IZJ4Wnnb4u9e4 Cc: Thomas Narten , "mohamed.boucadair@orange.com" , "sfc@ietf.org" , Ron Parker Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 13:24:16 -0000 Tom, Well, and I can't really make heads and tails of it! If we are going down a path were we know that there are an IPR holder does not tell us what his IPR applies to or what in their mind is a reasonable fee for implementing. Normally I agree that IPRs are useless, in this case I'm not sure. It could be that disclose against the problem statement is a way to announce that it is a blanket IPR, all implementations are effected. I hope there is some duck paddling going on to figure out. /Loa On 2014-05-05 13:38, Thomas Nadeau wrote: > > That is a bit of a red herring, isn't it? If the entire technology/ies > is/are encumbered, shouldn't we look at that issue on the whole? Simply > removing a paragraph from one problem statement isn't going to properly > address that issue. Frankly, IPR claims on problem statements are > useless other than they indicate there is IPR hiding elsewhere. Where > IPR claims will really matter is around the solutions. Based on the > claim in question, it is highly likely that there is IPR in this space. > I'd venture that there is anyways given that many proprietary > implementations have existed for some time. Given that, the question is > one of what terms are they under and are they agreeable to the IETF for > the solutions? > > --Tom > > > >> I agree with Loa - RAND on a problem statement implies that the entire >> technology is possibly encumbered. It would be best if the draft could >> be revised such that the IPR claim no longer applies, if that's even >> possible. That said, it's difficult to recommend specific changes >> without knowing why the IPR claim was made. Looking at the patent >> itself, "Creating distributed proxy configurations" at >> http://www.google.com/patents/US7200679 and looking at Figure 3 and >> Claim 1 in particular, the implication to me is that it's the entire >> technology that's being claimed. If that's the case, then our choices >> to look to be: >> >> - Accept that the entire technology is encumbered with a RAND claim, >> and continue on. >> >> - Drop the entire effort. >> >> - Ask the claimant to fill in section V.C. of the IPR claim, or >> otherwise clarify exactly what they are claiming. >> >> - Ask the claimant to change their claim from RAND licensing to free >> licensing with reciprocity. >> >> Cheers, >> Andy >> >> On Sat, May 3, 2014 at 2:45 AM, Loa Andersson > > wrote: >> >> Folks, >> >> >> On 2014-05-02 22:47, Thomas Narten wrote: >> >> 1) Accept it as it is >> >> Right. And this is what happens in practice with most IPR >> disclosures >> these days. I'll just note that there have been some 45 >> disclosures in >> the IETF so far this year. For all of 2013, there were some 279. >> >> >> I think the issue is not that most IPR disclosures does not lead >> to any >> action at all. >> >> For FRAND statements there is no problems to accept it as it is; >> however >> this is not FRAND but RAND. >> >> /Loa >> >> _______________________________________________ >> 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 > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon May 5 06:56:28 2014 Return-Path: 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 A55251A0359 for ; Mon, 5 May 2014 06:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 Cr3cpewkVurK for ; Mon, 5 May 2014 06:56:24 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id D685C1A0320 for ; Mon, 5 May 2014 06:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4198; q=dns/txt; s=iport; t=1399298180; x=1400507780; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=L7kHmAVKXRKQxDNBb32AzQDtndWeajMPv8SXxcek/TI=; b=krNcWYzgmCIs12GcPBH5ZZMPWeFLaoeZIy7ySIPenPbTx6r0LK4CG1Wm fhAzTT/yKRac1Fu0HjJYywDVCE/+W7MIIyyDfiySyVo0BjIS3+fwhfAbH Z+44helo5iFLfWT7F49PUTTVHYQfu6cudsiBOj1uuziyDRxyC7RlAwqdx c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwHADOYZ1OtJV2d/2dsb2JhbABZgwZPWKovAQIFAZJRhzuBGBZ0giUBAQEDAQEBAWQHBgUFCwIBCA4EBiMEBycLFAMOAgQOBRuIHggNyzAXhVaIJSQzB4MqgRUEiU2PZ4E8kTiBdYE/gW5B X-IronPort-AV: E=Sophos;i="4.97,988,1389744000"; d="scan'208";a="41097980" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 05 May 2014 13:56:20 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s45DuK1x028848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 May 2014 13:56:20 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Mon, 5 May 2014 08:56:19 -0500 From: "Carlos Pignataro (cpignata)" To: Med Boucadair Thread-Topic: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-03.txt) Thread-Index: AQHPZimKixrrxjIbyEuFSbffeW5SbZsx6RSAgAByDYA= Date: Mon, 5 May 2014 13:56:19 +0000 Message-ID: <6A61338C-B2C0-4875-97AC-4E09E7C82EC3@cisco.com> References: <94C682931C08B048B7A8645303FDC9F36F544849C9@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F5B63D0E4@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F5B63D0E4@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.210.5] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/jhIHXaDk2dCp04DxGactEB43j6o Cc: Thomas Narten , "sfc@ietf.org" Subject: Re: [sfc] Remove Section 3 from the problem statement (was RE: I-D Action: draft-ietf-sfc-problem-statement-03.txt) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 13:56:25 -0000 Hi, Med, Please see inline two small comments in the context of the WGLC of this doc= ument. On May 5, 2014, at 3:08 AM, mohamed.boucadair@orange.com wrote: > Thomas, >=20 > Please see inline. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : Thomas Narten [mailto:narten@us.ibm.com] >> Envoy=E9 : vendredi 2 mai 2014 19:10 >> =C0 : BOUCADAIR Mohamed IMT/OLN >> Cc : sfc@ietf.org >> Objet : Re: [sfc] Remove Section 3 from the problem statement (was RE: I= -D >> Action: draft-ietf-sfc-problem-statement-03.txt) >>=20 >> A few comments on this topic. >>=20 >> At Tue, 1 Apr 2014 13:42:23 +0200, wrote: >>>=20 >>> Dear all, >>>=20 >>> I raised this point to the co-authors but I prefer to raise it also in >>> the mailing list. >>>=20 >>> I suggest to remove Section 3 from the draft >>> http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-03#section-= 3, >>> because it goes beyond the problem discussion. That section is more a >>> discussion that should be hosted in a framework document. >>=20 >> I think we should be careful about being too strict about "problem >> only" on the problem statement and not allowing any discussion about >> solution direction. The entire point of SFC (and indeed any WG problem >> statement) is to layout the problem and/or "pain points", but also to >> show the general direction of a solution. >=20 > [Med] I agree on those.=20 >=20 > If we end up with a document >> that only outlines the problems, but provides no hint as to what sort >> of solution direction is being contemplated, we have done a disservice >> to the reader. >=20 > [Med] Disagree. The scope of a PS IMO is to discuss problems not hinting = solutions. I think we need to be humble here: chaining won't solve all the = problems listed in the PS: this is typically the case of the complications = related to the management of classification entries, inter-layer correlatio= n for diagnosis and troubleshooting, etc.=20 >=20 I agree with part of this statement, but I see the conclusion differently. = A Problem Statement (spelling it out to avoid aliasing with PS =3D=3D Propo= sed Standard) document ought to constrain and focus the problem space. I ag= ree with being humble. Now, to me, that's what Section 3 does: bounds, fram= es, and scopes the problem statement. >>=20 >> That said, we of course don't want so much in the solution direction >> that it ends up restricting the architecture. But I don't think we are >> anywhere close to that. And, even if we were, the architecture >> document could overrule any such direction. The WG architecture >> document is where the WG makes real decisions and adds detail to >> them. >=20 > [Med] So why including "hints" at the first place in a PS document?=20 >=20 Summarizing the WG thinking in how the problem is seen is useful (and commo= n). Otherwise we have a hand-waving document, IMHO. Thanks, Carlos. >>=20 >>> Furthermore, some of the points mentioned in that section are >>> questionable such as the use of metadata and the need of control >>> protocols, etc. Let's avoid mixing objectives and limit the scope of >>> the PS I-D to the identification to the problems to be solved. >>=20 >> We most certainly will be using metadata. I don't see how anyone who >> can suggest we won't, given all the discussion so far on the >> topic. Also, we will need some sort of control protocol (or management >> protocol). Otherwise there is no way to coordinate the state carried >> in SFC packets and the various SFs that process packets. What we >> haven't worked out is the details of what that metadata looks like >> (that's a solution) or what the protocol/management protocols will >> look like (again a solution -- plus per the charter, we have at best >> only a vague idea of what this might entail). But this is normal for a >> WG at this stage of existence. >=20 > [Med] This is a typical discussion for an architecture document.=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Mon May 5 08:59:55 2014 Return-Path: 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 0FD6A1A038D for ; Mon, 5 May 2014 08:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 zMwAmAFDBL3W for ; Mon, 5 May 2014 08:59:52 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 881681A02EF for ; Mon, 5 May 2014 08:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11310; q=dns/txt; s=iport; t=1399305588; x=1400515188; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=bwKaSrLrcXnWDu7KSZBzBVdvsd/Q9HeurmDrZBe9mC4=; b=EmpcIF6kXfn6LrAZKsmusICBJLjTZQZfKg4A3EbjfkkPVU2VUIMPhQOZ UYBKoVG/XLVkXjpN/MiKjJzfN//NkOFpr5VXtkBaaBwzJVBWtFb21dFiT QLVE0BWmFlU8dLOUnog2bId80UHW6t7FC73WtHYDXFd/J7FutrWw8P5Cp A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwHAAi1Z1OtJV2c/2dsb2JhbABZgkJET1iqMAECBQGaDIEYFnSCJQEBAQQdEEEbAgEIEQMBAQEoBzIUCQgCBAESiEHLZheFVogaEQE/FwGEPwSZNJJ0gzSBdjk X-IronPort-AV: E=Sophos; i="4.97,989,1389744000"; d="scan'208,217"; a="41132707" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP; 05 May 2014 15:59:47 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s45FxluF016885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 May 2014 15:59:47 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.229]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Mon, 5 May 2014 10:59:46 -0500 From: "Jim Guichard (jguichar)" To: "Songhaibin (A)" , "sfc@ietf.org" Thread-Topic: WG acceptance of DC use case document Thread-Index: AQHPZ4zZmOCxvX5ZJUmDR/KJEmbqkZsxO/8wgAD7t4A= Date: Mon, 5 May 2014 15:59:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.43.180] Content-Type: multipart/alternative; boundary="_000_CF8D2A44203C6jguicharciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/_H-y9tu9i3fGkclmsrTpeke-yB4 Subject: Re: [sfc] WG acceptance of DC use case document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 15:59:54 -0000 --_000_CF8D2A44203C6jguicharciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Haibin, We used the latest version of the document. The authors indicated that the = changes were either editorial or in response to discussion points from the = mailing list. Having reviewed the diffs, they do not appear to be controver= sial; however, as always, if anyone disagrees please raise the specifics on= the mailing list. From: "Songhaibin (A)" > Date: Sunday, May 4, 2014 at 10:33 PM To: Jim Guichard >, "sfc@ietf= .org" > Subject: RE: WG acceptance of DC use case document Dear SFC Chairs, I have one logistic question, while the object of this call for adoption ac= tion is draft-kumar-sfc-dc-use-cases-01, why does the working group documen= t draft-ietf-sfc-dc-use-cases-00 have the same text with draft-kumar-sfc-dc= -use-cases-02? Did the WG call for the adoption of draft-kumar-sfc-dc-use-c= ases-02? Or I missed that email from the list? Best Regards! -Haibin From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Sunday, May 04, 2014 7:35 PM To: sfc@ietf.org Subject: [sfc] WG acceptance of DC use case document Greetings: Thank you for your responses on the call for adoption of draft-kumar-sfc-dc= -use-cases. Overall there seems to be general consensus that the document p= rovides relevant content and is a good baseline for documenting both SP and= Enterprise/cloud use cases and should serve as the basis for a WG document= . While several folks have expressed concern that particular content is curre= ntly missing from the document, please note that the omission of content is= normal process and the WG is expected to modify the document until there i= s WG consensus that the content is solid and complete. Therefore, if you be= lieve there is content missing please have that discussion either directly = with the authors or (preferably) on the mailing list so that all concerns b= ecome addressed and reflected (as appropriate) within the document. Authors, please post a new version as draft-ietf-sfc-dc-use-cases-00. Jim & Thomas. --_000_CF8D2A44203C6jguicharciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Haibin,

We used the latest version of the document. The authors indicated that= the changes were either editorial or in response to discussion points from= the mailing list. Having reviewed the diffs, they do not appear to be cont= roversial; however, as always, if anyone disagrees please raise the specifics on the mailing list. 

From: "Songhaibin (A)" &l= t;haibin.song@huawei.com><= br> Date: Sunday, May 4, 2014 at 10:33 = PM
To: Jim Guichard <jguichar@cisco.com>, "sfc@ietf.org" <s= fc@ietf.org>
Subject: RE: WG acceptance of DC us= e case document

Dear SFC Chairs,

 <= /span>

I have one logisti= c question, while the object of this call for adoption action is draft-kuma= r-sfc-dc-use-cases-01, why does the working group document draft-ietf-sfc-dc-use-cases-00 have the same text with draf= t-kumar-sfc-dc-use-cases-02? Did the WG call for the adoption of draft-kuma= r-sfc-dc-use-cases-02? Or I missed that email from the list?

 

Best Regards!

-Haibin

 <= /span>

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Sunday, May 04, 2014 7:35 PM
To: sfc@ietf.org
Subject: [sfc] WG acceptance of DC use case document

 

Greetings:<= /p>

 

Thank you for your responses = on the call for adoption of draft-kumar-sfc-dc-use-cases. Overall there see= ms to be general consensus that the document provides relevant content and is a good baseline for documenting both SP a= nd Enterprise/cloud use cases and should serve as the basis for a WG docume= nt.

 

While several folks have expr= essed concern that particular content is currently missing from the documen= t, please note that the omission of content is normal process and the WG is expected to modify the document until ther= e is WG consensus that the content is solid and complete. Therefore, if you= believe there is content missing please have that discussion either direct= ly with the authors or (preferably) on the mailing list so that all concerns become addressed and reflected (a= s appropriate) within the document.

 

Authors, please post a new ve= rsion as draft-ietf-sfc-dc-use-cases-00.

 

Jim & Thomas.<= /span>

 

 

 --_000_CF8D2A44203C6jguicharciscocom_-- From nobody Mon May 5 09:42:18 2014 Return-Path: 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 5FF7A1A03EE for ; Mon, 5 May 2014 09:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 o7jvi6ODODtM for ; Mon, 5 May 2014 09:42:14 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 87F621A03ED for ; Mon, 5 May 2014 09:42:14 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-ae-53677077d874 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F8.64.07420.77077635; Mon, 5 May 2014 13:05:27 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0174.001; Mon, 5 May 2014 12:42:08 -0400 From: David Allan I To: "mohamed.boucadair@orange.com" , "Thomas Narten" Thread-Topic: [sfc] IPR related to draft-ietf-sfc-problem-statement Thread-Index: Ac9fhj7PPNW+anohTi+gTFNE6u4L6QGxL8SAAIJI+IAACvbUkA== Date: Mon, 5 May 2014 16:42:08 +0000 Message-ID: References: <94C682931C08B048B7A8645303FDC9F36F58B44EEF@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F5B63D0F9@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F5B63D0F9@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyuXRPlG55QXqwwd+7OhaH3z5ltzjRN5XF 4smDrewOzB5Llvxk8mh5dpLN49y1PuYA5igum5TUnMyy1CJ9uwSujPaJq9gLNmhVrLpyj7GB cYlmFyMnh4SAicSLhsesELaYxIV769m6GLk4hASOMkq8PHaFGcJZxijx6vgCNpAqNgEDiT3/ vzCC2CICGRIXt8wBs5kFFCUe3frNBGILCzhJHJt1ig2ixlni6a9mJgjbSeLQqYtAQzk4WARU JCY9cQMJ8wr4SlzatR5q10VGiRPLHzGDJDgFYiQ2/mxkB7EZga77fmoNE8QucYlbT+YzQVwt ILFkz3lmCFtU4uXjf1DfKElMWnqOFWQXs4CmxPpd+jBnTul+yA6xV1Di5MwnLBMYxWYhmToL oWMWko5ZSDoWMLKsYuQoLU4ty003MtjECIybYxJsujsY97y0PMQowMGoxMPb6ZIeLMSaWFZc mXuIUZqDRUmct+BLbLCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxt1XArhYGDoESw0mzl0/ NebUE/9vTscZOXZzPiqVYF734ftO0yO3+fdNyupoPf7w6hRBj4KMoyotJxkC35n895Vs9y/K msNQuFP6gKpJg753RFsqm+GbZZxxL5LKJJ4maG5py0937WG4Hdr1QFjej2N6mdWkrgNWwqd/ frlx7a5O6sFe+5dGSizFGYmGWsxFxYkAhscA53wCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/tvhIgqYfn2zu6yJkyA9L27ei52w Cc: "sfc@ietf.org" Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 16:42:17 -0000 SGk6DQoNCldvdWxkIG5vdCByZW1vdmluZyB0aGUgc2VjdGlvbiBiZSBzaW1wbHkga2lja2luZyB0 aGUgY2FuIGRvd24gdGhlIHJvYWQ/ICBTaW1wbHkgZGVmZXJyaW5nIG9wZW5pbmcgdGhlIGJveCB3 aXRoIHRoZSBjYXQgaW4gaXQuLi4uDQoNCkF0IGxlYXN0IHRoYXQgaXMgaG93IGl0IGxvb2tzIGZy b20gaGVyZS4uLg0KRA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2ZjIFtt YWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tDQpTZW50OiBNb25kYXksIE1heSAwNSwgMjAxNCAxMjoyMSBBTQ0KVG86IFRo b21hcyBOYXJ0ZW4NCkNjOiBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBJUFIgcmVs YXRlZCB0byBkcmFmdC1pZXRmLXNmYy1wcm9ibGVtLXN0YXRlbWVudA0KDQpUaG9tYXMsDQoNCkl0 IGlzIG5vdCB1cCB0byBtZSB0byBhc3Nlc3MgdGhlIHZhbGlkaXR5IG9mIGFuIElQUiBkaXNjbG9z dXJlLg0KDQpUaGUgbWFpbiBwb2ludCBpcyB0byByZXZpc2l0IHRoZSBkcmFmdCB0byBtYWtlIGhh cmQgdG8gYXBwbHkgYW4gSVBSIG9uIGl0OiB0aGlzIG1lYW5zIGV4Y2x1ZGUgYW55IHNvbHV0aW9u IGRpc2N1c3Npb24gKGkuZS4gc2VjdGlvbiAzKS4gDQoNCkNoZWVycywNCk1lZA0KDQo+LS0tLS1N ZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+RGXCoDogVGhvbWFzIE5hcnRlbiBbbWFpbHRvOm5hcnRl bkB1cy5pYm0uY29tXSBFbnZvecOpwqA6IHZlbmRyZWRpIDIgbWFpIA0KPjIwMTQgMTk6MTEgw4DC oDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTiBDY8KgOiBzZmNAaWV0Zi5vcmcgT2JqZXTCoDog UmU6IA0KPltzZmNdIElQUiByZWxhdGVkIHRvIGRyYWZ0LWlldGYtc2ZjLXByb2JsZW0tc3RhdGVt ZW50DQo+DQo+TGV0IG1lIHRyeSB0byBzcGxpdCB0aGlzIHRocmVhZCBpbnRvIHR3byBkaWZmZXJl bnQgcGllY2VzLg0KPg0KPkF0IFRodSwgMjQgQXByIDIwMTQgMDg6Mjc6MjAgKzAyMDAsIDxtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCj4NCj4+IFdoZW4gY2hlY2tpbmcgdGhl IHRyYWNrZXIsIEkgZm91bmQgdGhlcmUgaXMgYW4gSVBSIGRpc2Nsb3N1cmUgZm9yIHRoZQ0KPnBy b2JsZW0NCj4+IHN0YXRlbWVudCBkb2N1bWVudDoNCj4+DQo+PiBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2lwci9zZWFyY2gvP29wdGlvbj1kb2N1bWVudF9zZWFyY2gmaWQ9DQo+PiBkcmFm dC1pZXRmLXNmYy1wcm9ibGVtLXN0YXRlbWVudA0KPj4NCj4+IEnKvG0gc3VycHJpc2VkIHRvIHNl ZSBzdWNoIGRpc2Nsb3N1cmUgZm9yIGEgZG9jdW1lbnQgdGhhdCBpcyBzdXBwb3NlZCANCj4+IHRv IGRlc2NyaWJlIG9ubHkgcHJvYmxlbXMgKGV4Y2VwdCBzZWN0aW9uIDMpLg0KPg0KPlBlcnNvbmFs bHksIEknbSBzdXJwcmlzZWQgdG9vLiBCdXQgZG9lc24ndCBtYXR0ZXIuDQo+DQo+TWFraW5nIGFu IElQUiBkaXNjbG9zdXJlIGlzIGEgbGVnYWwgZGVjaXNpb24sIG5vdCBhbiBlbmdpbmVlcmluZyBv bmUuIA0KPlRoZSBJRVRGIGlzIHF1aXRlIGNsZWFyIGFib3V0IElQUiAtLSBiZXR0ZXIgdG8gYmUg c2FmZSBhbmQgZGlzY2xvc2UsIA0KPnJhdGhlciB0aGFuIG5vdC4gQW5kIGluIG15IGV4cGVyaWVu Y2UsIElQUiBkaXNjbG9zdXJlcyBhbHdheXMgaGF2ZSBhbiANCj5leHBsaWNpdCBvciBpbXBsaWNp dCB1c2Ugb2YgdGhlIHdvcmQgIm1heSIgdG8gaW5kaWNhdGUgdGhhdCBJUFIgIm1heSIgDQo+YXBw bHkuIFdoZXRoZXIgSVBSIGRvZXMgYWN0dWFsbHkgYXBwbHkgdG8gc3BlY2lmaWMgdGVjaG5vbG9n eSBpcyBhIA0KPm51YW5jZWQgZGlzY3Vzc2lvbiBhbmQgb25lIGludm9sdmluZyBsYXd5ZXJzIGFu ZCB0aGUgY291cnRzLiBEaWZmZXJlbnQgDQo+cGVvcGxlIHdpbGwgaGF2ZSBkaWZmZXJlbnQgb3Bp bmlvbnMuDQo+DQo+PiBJyrxtIHJlLWl0ZXJhdGluZyBteSBjb21tZW50IHRvIHJlbW92ZSBzZWN0 aW9uIDMgZnJvbSB0aGUgUFMgZHJhZnQgYXMgDQo+PiBpdA0KPnNlZW1zDQo+PiB0aGlzIGlzIHRo ZSBvbmx5IHBhcnQgdGhhdCBpcyBjbG9zZSB0byB0aGUgc29sdXRpb24gcGFydCB0aGFuIHRoZSAN Cj4+IHByb2JsZW0gZGlzY3Vzc2lvbi4NCj4NCj5JdCdzIGhhcmQgdG8gc2VlIGhvdyByZW1vdmlu ZyBzZWN0aW9uIDMgd2lsbCBoYXZlIGFueSBpbXBhY3Qgb24gSVBSIA0KPnJlbGF0ZWQgdG8gU0ZD LiBGaXJzdCwgcmVtb3ZpbmcgdGhlIHNlY3Rpb24gd2lsbCBub3QgbmVjZXNzYXJpbHkgbGVhZCAN Cj50byB0aGUgZGlzY2xvc3VyZSBzdGF0ZW1lbnQgYmVpbmcgcmVtb3ZlZCAoc2VlIGFib3ZlKS4N Cj4NCj5TZWNvbmQsIGlmIHRoZXJlIGFjdHVhbGx5IGlzIGluIGZhY3QgSVBSIHRoYXQgYXBwbGll cyB0byBTRkMsIHRoYXQgd2lsbCANCj5iZWNvbWUgY2xlYXIgd2hlbiB3ZSBkZXZlbG9wIHNvbHV0 aW9ucywgYW5kIGFkZGl0aW9uYWwgc3BlY2lmaWMgDQo+ZGlzY2xvc3VyZXMgd2lsbCBuZWVkIHRv IGJlIG1hZGUgdGhlbi4gKE1ha2luZyBhIGRpc2Nsb3N1cmUgZm9yIG9uZSANCj5kb2N1bWVudCBp c24ndCBlbm91Z2ggLS0gZGlzY2xvc3VyZXMgbmVlZCB0byBiZSBtYWRlIGZvciBldmVyeSBkb2N1 bWVudCANCj50byB3aGljaCBJUFIgbWlnaHQgYXBwbHkuKSBUaHVzLCB0d2Vha2luZyB0aGUgcHJv YmxlbSBzdGF0ZW1lbnQgaW4gYW4gDQo+YXR0ZW1wdCB0byBhdm9pZCBhbiBJUFIgZGlzY2xvc3Vy ZSBzZWVtcyBtb3JlIGxpa2Ugd2lzaGZ1bCB0aGlua2luZyANCj50aGFuIHN1YnN0YW5jZS4gIEFu eSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoZSBwcm9ibGVtIHN0YXRlbWVudCB3aWxsIA0KPnN1cmVs eSBjb21lIHVwIGFnYWluIGluIHRoZSBjb250ZXh0IG9mIHNwZWNpZmljIGEgc29sdXRpb24uIElN TywgaXQgDQo+d291bGQgYmUgbW9yZSBhcHByb3ByaWF0ZSBmb3IgdGhlIFdHIHRvIGRpc2N1c3Mg aG93IHRvIGhhbmRsZSBwb3RlbnRpYWwgDQo+SVBSIHdoZW4gZGlzY3Vzc2luZyBzcGVjaWZpYyBz b2x1dGlvbnMgLS0gd2hlbiB3ZSBjYW4gaGF2ZSBhIGRpc2N1c3Npb24gDQo+aW4gdGhlIGNvbnRl eHQgb2Ygc3BlY2lmaWMgdGVjaG5pY2FsIGFwcHJvYWNoZXMgdGhhdCBhcmUgYmVpbmcgDQo+Y29u c2lkZXJlZC4NCj4NCj5BIG51bWJlciBvZiBmb2xrIG9uIHRoaXMgdGhyZWFkIGhhdmUgYWRkZWQg YSAiKzEiLiBJdCB3b3VsZCBiZSBoZWxwZnVsIA0KPnRvIGdldCBhZGRpdGlvbmFsIGNsYXJpdHkg YXMgdG8gd2hldGhlciB0aGUgYWdyZWVtZW50IGlzIGFib3V0IHRoZSANCj5zdXJwcmlzZSBhdCB0 aGUgSVBSIHN0YXRlbWVudCBhbmQgYSBkZXNpcmUgdG8gdHJ5IGFuZCBhdm9pZCBoYXZpbmcgdGhl IA0KPnByb2JsZW0gc3RhdGVtZW50IGRvY3VtZW50IGhhdmUgYW4gSVBSIGRpc2Nsb3N1cmUgc3Rh dGVtZW50IGFzc29jaWF0ZWQgDQo+d2l0aCBpdCwgb3Igd2hldGhlciB0aGVyZSBpcyBhIHN1cHBv cnQgdG8gcmVtb3ZlIHNlY3Rpb24gMyBmb3Igb3RoZXIgDQo+cmVhc29ucyB0aGFuIHRoZSBJUFIg ZGlzY2xvc3VyZSAodGhlcmUgaGF2ZSBiZWVuIGVhcmxpZXIvc2VwYXJhdGUgDQo+dGhyZWFkcyBv biB0aGlzIHF1ZXN0aW9uKS4NCj4NCj5UaG9tYXMNCj4NCj4+DQo+PiBDaGVlcnMsDQo+Pg0KPj4g TWVkDQo+Pg0KPj4NCj4+IFsyICA8dGV4dC9wbGFpbjsgdXMtYXNjaWkgKDdiaXQpPl0NCj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBzZmMgbWFp bGluZyBsaXN0DQo+PiBzZmNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Mon May 5 10:41:55 2014 Return-Path: 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 D564F1A03EC for ; Mon, 5 May 2014 10:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 ASphXQg5kYT1 for ; Mon, 5 May 2014 10:41:52 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id E89421A03E2 for ; Mon, 5 May 2014 10:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1531; q=dns/txt; s=iport; t=1399311708; x=1400521308; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=kUICReyn6qzbjFwe0Axn19tWRkV48wOKI3UcvcSjXz8=; b=I3l8QngecCBFVVRFbuFLpbQVYCRBi2AR2RmmTvFknaxePNjlD2PjWNxt nuB9l2eNEUB12hVlhtlkJ9mOhSoEQz4/IrO/+Z4FkcBPknr62eQ9PhBw2 1Lfvw8zlFAHw4W3xg3rqLkd97N/jtJ6XoWVkfShnszG0MzqnHE5ppHGDs 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0HAEXMZ1OtJA2L/2dsb2JhbABZgwZPUQfFXhZ0giUBAQEDATo9EgIBGiQQMhcECgIEHAsHiB4ICAXLbReSA4EVBJk0gTyROIM0bYFC X-IronPort-AV: E=Sophos;i="4.97,990,1389744000"; d="scan'208";a="41156392" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-1.cisco.com with ESMTP; 05 May 2014 17:41:48 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s45HfmRg001400 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 5 May 2014 17:41:48 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.67]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Mon, 5 May 2014 12:41:48 -0500 From: "Paul Quinn (paulq)" To: "" Thread-Topic: New Version Notification for draft-quinn-sfc-arch-05.txt Thread-Index: AQHPaIfarkMZcB0ak0qMpN0Eo35H0w== Date: Mon, 5 May 2014 17:41:47 +0000 Message-ID: <5A389ED0-86BF-4F6B-A367-5C1512C9D589@cisco.com> References: <20140505173129.23329.89665.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.231] Content-Type: text/plain; charset="us-ascii" Content-ID: <7810158444911C4598620A86A7C9C9F1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/m14uZVgSbO3ZskIGQoz1hRoIyQg Subject: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 17:41:54 -0000 Folks, A new version of the architecture draft has been submitted. This version r= eflect comments from the community, and welcomes a new co-editor: Joel Halp= ern. As always, comments and suggestions are encouraged! Thanks Paul >=20 >=20 > A new version of I-D, draft-quinn-sfc-arch-05.txt > has been successfully submitted by Paul Quinn and posted to the > IETF repository. >=20 > Name: draft-quinn-sfc-arch > Revision: 05 > Title: Service Function Chaining (SFC) Architecture > Document date: 2014-05-05 > Group: Individual Submission > Pages: 31 > URL: http://www.ietf.org/internet-drafts/draft-quinn-sfc-arch-= 05.txt > Status: https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/ > Htmlized: http://tools.ietf.org/html/draft-quinn-sfc-arch-05 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-quinn-sfc-arch-0= 5 >=20 > Abstract: > This document describes an architecture for the specification, > creation, and ongoing maintenance of Service Function Chains (SFC) in > a network. It includes architectural concepts, principles, and > components used in the construction of composite services through > deployment of SFCs. This document does not propose solutions, > protocols, or extensions to existing protocols. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Mon May 5 11:12:55 2014 Return-Path: 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 28BC61A03A5 for ; Mon, 5 May 2014 11:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 mupW6fbD4k5v for ; Mon, 5 May 2014 11:12:46 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 137AB1A02DE for ; Mon, 5 May 2014 11:12:46 -0700 (PDT) Received: from [192.168.1.8] (unknown [119.95.153.210]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 2ED8D1800905; Mon, 5 May 2014 20:12:39 +0200 (CEST) Message-ID: <5367D495.1030600@pi.nu> Date: Mon, 05 May 2014 20:12:37 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: David Allan I , "mohamed.boucadair@orange.com" , Thomas Narten References: <94C682931C08B048B7A8645303FDC9F36F58B44EEF@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F5B63D0F9@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/O2Zx-ljMnrbRikYldohYkBqhyzE Cc: "sfc@ietf.org" Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 18:12:50 -0000 Dave, The issue is if there is a cat in the boc, is there? /Loa On 2014-05-05 18:42, David Allan I wrote: > Hi: > > Would not removing the section be simply kicking the can down the road? Simply deferring opening the box with the cat in it.... > > At least that is how it looks from here... > D > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com > Sent: Monday, May 05, 2014 12:21 AM > To: Thomas Narten > Cc: sfc@ietf.org > Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement > > Thomas, > > It is not up to me to assess the validity of an IPR disclosure. > > The main point is to revisit the draft to make hard to apply an IPR on it: this means exclude any solution discussion (i.e. section 3). > > Cheers, > Med > >> -----Message d'origine----- >> De : Thomas Narten [mailto:narten@us.ibm.com] Envoyé : vendredi 2 mai >> 2014 19:11 À : BOUCADAIR Mohamed IMT/OLN Cc : sfc@ietf.org Objet : Re: >> [sfc] IPR related to draft-ietf-sfc-problem-statement >> >> Let me try to split this thread into two different pieces. >> >> At Thu, 24 Apr 2014 08:27:20 +0200, wrote: >> >>> When checking the tracker, I found there is an IPR disclosure for the >> problem >>> statement document: >>> >>> https://datatracker.ietf.org/ipr/search/?option=document_search&id= >>> draft-ietf-sfc-problem-statement >>> >>> Iʼm surprised to see such disclosure for a document that is supposed >>> to describe only problems (except section 3). >> >> Personally, I'm surprised too. But doesn't matter. >> >> Making an IPR disclosure is a legal decision, not an engineering one. >> The IETF is quite clear about IPR -- better to be safe and disclose, >> rather than not. And in my experience, IPR disclosures always have an >> explicit or implicit use of the word "may" to indicate that IPR "may" >> apply. Whether IPR does actually apply to specific technology is a >> nuanced discussion and one involving lawyers and the courts. Different >> people will have different opinions. >> >>> Iʼm re-iterating my comment to remove section 3 from the PS draft as >>> it >> seems >>> this is the only part that is close to the solution part than the >>> problem discussion. >> >> It's hard to see how removing section 3 will have any impact on IPR >> related to SFC. First, removing the section will not necessarily lead >> to the disclosure statement being removed (see above). >> >> Second, if there actually is in fact IPR that applies to SFC, that will >> become clear when we develop solutions, and additional specific >> disclosures will need to be made then. (Making a disclosure for one >> document isn't enough -- disclosures need to be made for every document >> to which IPR might apply.) Thus, tweaking the problem statement in an >> attempt to avoid an IPR disclosure seems more like wishful thinking >> than substance. Any IPR that applies to the problem statement will >> surely come up again in the context of specific a solution. IMO, it >> would be more appropriate for the WG to discuss how to handle potential >> IPR when discussing specific solutions -- when we can have a discussion >> in the context of specific technical approaches that are being >> considered. >> >> A number of folk on this thread have added a "+1". It would be helpful >> to get additional clarity as to whether the agreement is about the >> surprise at the IPR statement and a desire to try and avoid having the >> problem statement document have an IPR disclosure statement associated >> with it, or whether there is a support to remove section 3 for other >> reasons than the IPR disclosure (there have been earlier/separate >> threads on this question). >> >> Thomas >> >>> >>> Cheers, >>> >>> Med >>> >>> >>> [2 ] >>> _______________________________________________ >>> 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 mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon May 5 11:33:37 2014 Return-Path: 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 7D9AD1A0434 for ; Mon, 5 May 2014 11:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vlRE359oTWFW for ; Mon, 5 May 2014 11:33:32 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id D7D8B1A042A for ; Mon, 5 May 2014 11:33:31 -0700 (PDT) X-AuditID: c6180641-f799b6d000000b0f-f7-5367881c143e Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 68.8B.02831.C1887635; Mon, 5 May 2014 14:46:21 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Mon, 5 May 2014 14:33:26 -0400 From: David Allan I To: Loa Andersson , "mohamed.boucadair@orange.com" , Thomas Narten Thread-Topic: [sfc] IPR related to draft-ietf-sfc-problem-statement Thread-Index: Ac9fhj7PPNW+anohTi+gTFNE6u4L6QGxL8SAAIJI+IAACvbUkAALyIyAAAg1WiA= Date: Mon, 5 May 2014 18:33:25 +0000 Message-ID: References: <94C682931C08B048B7A8645303FDC9F36F58B44EEF@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F5B63D0F9@PUEXCB1B.nanterre.francetelecom.fr> <5367D495.1030600@pi.nu> In-Reply-To: <5367D495.1030600@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyuXSPn65sR3qwwfZ7jBb/5s5htjj89im7 xYm+qSwWTx5sZXdg8Viy5CeTR8uzk2wes6a3sXmcu9bHHMASxWWTkpqTWZZapG+XwJWxZeU/ loJ1thXvDlxkbmB8Yt3FyMkhIWAicWTLKiYIW0ziwr31bF2MXBxCAkcZJSatewvlLGOU2Ngw kQWkik3AQGLP/y+MIAkRgUZGiScLr7OCJJgFFCUe3foNNkpYwEni2KxTbCC2iICzxNNfzUBx DiDbT+LkmzqQMIuAisTp3d3sIDavgK/E6V8bGCGWbWCS2NOxAGwOp4CqxJHtbxlBbEag876f WsMEsUtc4taT+VBnC0gs2XOeGcIWlXj5+B8rhK0kMWnpOVaQvcwCmhLrd+nDnDml+yHUXkGJ kzOfsExgFJuFZOoshI5ZSDpmIelYwMiyipGjtDi1LDfdyHATIzCajkmwOe5gXPDJ8hCjAAej Eg+vpFN6sBBrYllxZe4hRmkOFiVx3vRPscFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGFeJ x7g6zZ4iV5ZR+U+zftG3ZQt9ma7d157pN1liwt3+knnXXXLY7K5NFKrc7Hdqun9QRFzvLu6+ kzqTXimEF99i00nOVviwYuOZO5+82HrVg//+PLhGX/XlrI6L3F8WOK9UFw6yqs8xSeQ1sg9y yN1Yp1eoOev742Mzm3LmT9IJU/qz9qXeBSWW4oxEQy3mouJEAP5I3WGHAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Txi4aPb5ZY87QeOHZaKtVtbaW3A Cc: "sfc@ietf.org" Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 18:33:34 -0000 SEkgTG9hOg0KDQpJIHdhcyB0aGlua2luZyBvZiBTY2hyw7ZkaW5nZXIuLi4uDQpodHRwOi8vZW4u d2lraXBlZGlhLm9yZy93aWtpL1NjaHIlQzMlQjZkaW5nZXInc19jYXQgDQoNCldlIGFyZSBzaW1w bHkgZGVmZXJyaW5nIHRoZSBkZXRlcm1pbmF0aW9uIG9mIElQUiByZWxldmFuY2UsIGFzIHByZXN1 bWFibHkgaWYgdGhlIElQUiB3YXMgY2xhaW1lZCB0byBwb3NzaWJseSBhcHBseSBpbiB0aGUgcHJv YmxlbSBzdGF0ZW1lbnQsIGl0IGxpa2VseSAibWF5IiBhcHBseSB0byBkZXJpdmF0aXZlIHdvcmtz Li4uDQoNClNvIGV4Y2x1ZGluZyB0ZXh0IGZyb20gdGhlIGRyYWZ0IGRvZXMgbm90IG1ha2UgdGhl IElQUiBnbyBhd2F5LCBhbmQgaWYgdGhlIGRlbGV0ZWQgc2VjdGlvbiB3YXMgd2hhdCB0aGUgSVBS IGFjdHVhbGx5IGFwcGxpZWQgdG8sIGl0IGxlYXZlcyBpdCBpbiBzb21lIGxpbWJvIGluZGV0ZXJt aW5hdGUgc3RhdGUgdy5yLnQuIFNGQyBhbmQgaWYgaXQgZGlkIG5vdCByZXNvbHZlIHRoZSBJUFIg aXNzdWUgdGhlbiB3aGF0IGRvIHdlIGRvPyAgQWxsIHdlIGtub3cgaXMgd2UndmUgaGFkIHNvbWUg dmFndWUgc2hvdCBhY3Jvc3Mgb3VyIGJvdyBzYWlsaW5nIGluIGEgZm9nLi4uLg0KDQpNeSBvcGlu aW9uIHdhcyBmcm9tIHRoZSBQT1Ygb2YgdGhlIElQUiBpc3N1ZSwgZGVsZXRpbmcgdGV4dCBmcm9t IHRoZSBkcmFmdCB3YXMgYW4gYWRtaW5pc3RyYXRpdmUgZXhwZWRpZW50IHRoYXQgYWN0dWFsbHkg ZGlkIG5vdGhpbmcuLi4NCg0KQW5kIHdoaWxlIG5vdCBiZWluZyBhIGxhd3llciwgSSB3b3VsZCBv YnNlcnZlIHRoYXQgb25lIGRvZXMgbm90ICJidWlsZCIgcHJvYmxlbSBzdGF0ZW1lbnRzLCBzbyBw cm92aW5nIGluZnJpbmdlbWVudCBpcyBzb21ld2hhdCBkaWZmaWN1bHQuIA0KDQpEYXZlDQoNCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTG9hIEFuZGVyc3NvbiBbbWFpbHRv OmxvYUBwaS5udV0gDQpTZW50OiBNb25kYXksIE1heSAwNSwgMjAxNCAxMToxMyBBTQ0KVG86IERh dmlkIEFsbGFuIEk7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IFRob21hcyBOYXJ0ZW4N CkNjOiBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBJUFIgcmVsYXRlZCB0byBkcmFm dC1pZXRmLXNmYy1wcm9ibGVtLXN0YXRlbWVudA0KDQpEYXZlLA0KDQpUaGUgaXNzdWUgaXMgaWYg dGhlcmUgaXMgYSBjYXQgaW4gdGhlIGJvYywgaXMgdGhlcmU/DQoNCi9Mb2ENCg0KT24gMjAxNC0w NS0wNSAxODo0MiwgRGF2aWQgQWxsYW4gSSB3cm90ZToNCj4gSGk6DQo+DQo+IFdvdWxkIG5vdCBy ZW1vdmluZyB0aGUgc2VjdGlvbiBiZSBzaW1wbHkga2lja2luZyB0aGUgY2FuIGRvd24gdGhlIHJv YWQ/ICBTaW1wbHkgZGVmZXJyaW5nIG9wZW5pbmcgdGhlIGJveCB3aXRoIHRoZSBjYXQgaW4gaXQu Li4uDQo+DQo+IEF0IGxlYXN0IHRoYXQgaXMgaG93IGl0IGxvb2tzIGZyb20gaGVyZS4uLg0KPiBE DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHNmYyBbbWFpbHRvOnNm Yy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgDQo+IG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20NCj4gU2VudDogTW9uZGF5LCBNYXkgMDUsIDIwMTQgMTI6MjEgQU0NCj4gVG86IFRo b21hcyBOYXJ0ZW4NCj4gQ2M6IHNmY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NmY10gSVBS IHJlbGF0ZWQgdG8gZHJhZnQtaWV0Zi1zZmMtcHJvYmxlbS1zdGF0ZW1lbnQNCj4NCj4gVGhvbWFz LA0KPg0KPiBJdCBpcyBub3QgdXAgdG8gbWUgdG8gYXNzZXNzIHRoZSB2YWxpZGl0eSBvZiBhbiBJ UFIgZGlzY2xvc3VyZS4NCj4NCj4gVGhlIG1haW4gcG9pbnQgaXMgdG8gcmV2aXNpdCB0aGUgZHJh ZnQgdG8gbWFrZSBoYXJkIHRvIGFwcGx5IGFuIElQUiBvbiBpdDogdGhpcyBtZWFucyBleGNsdWRl IGFueSBzb2x1dGlvbiBkaXNjdXNzaW9uIChpLmUuIHNlY3Rpb24gMykuDQo+DQo+IENoZWVycywN Cj4gTWVkDQo+DQo+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+IERlIDogVGhvbWFz IE5hcnRlbiBbbWFpbHRvOm5hcnRlbkB1cy5pYm0uY29tXSBFbnZvecOpIDogdmVuZHJlZGkgMiBt YWkNCj4+IDIwMTQgMTk6MTEgw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOIENjIDogc2Zj QGlldGYub3JnIE9iamV0IDogUmU6DQo+PiBbc2ZjXSBJUFIgcmVsYXRlZCB0byBkcmFmdC1pZXRm LXNmYy1wcm9ibGVtLXN0YXRlbWVudA0KPj4NCj4+IExldCBtZSB0cnkgdG8gc3BsaXQgdGhpcyB0 aHJlYWQgaW50byB0d28gZGlmZmVyZW50IHBpZWNlcy4NCj4+DQo+PiBBdCBUaHUsIDI0IEFwciAy MDE0IDA4OjI3OjIwICswMjAwLCA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4gd3JvdGU6 DQo+Pg0KPj4+IFdoZW4gY2hlY2tpbmcgdGhlIHRyYWNrZXIsIEkgZm91bmQgdGhlcmUgaXMgYW4g SVBSIGRpc2Nsb3N1cmUgZm9yIA0KPj4+IHRoZQ0KPj4gcHJvYmxlbQ0KPj4+IHN0YXRlbWVudCBk b2N1bWVudDoNCj4+Pg0KPj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByL3NlYXJj aC8/b3B0aW9uPWRvY3VtZW50X3NlYXJjaCZpZD0NCj4+PiBkcmFmdC1pZXRmLXNmYy1wcm9ibGVt LXN0YXRlbWVudA0KPj4+DQo+Pj4gScq8bSBzdXJwcmlzZWQgdG8gc2VlIHN1Y2ggZGlzY2xvc3Vy ZSBmb3IgYSBkb2N1bWVudCB0aGF0IGlzIHN1cHBvc2VkIA0KPj4+IHRvIGRlc2NyaWJlIG9ubHkg cHJvYmxlbXMgKGV4Y2VwdCBzZWN0aW9uIDMpLg0KPj4NCj4+IFBlcnNvbmFsbHksIEknbSBzdXJw cmlzZWQgdG9vLiBCdXQgZG9lc24ndCBtYXR0ZXIuDQo+Pg0KPj4gTWFraW5nIGFuIElQUiBkaXNj bG9zdXJlIGlzIGEgbGVnYWwgZGVjaXNpb24sIG5vdCBhbiBlbmdpbmVlcmluZyBvbmUuDQo+PiBU aGUgSUVURiBpcyBxdWl0ZSBjbGVhciBhYm91dCBJUFIgLS0gYmV0dGVyIHRvIGJlIHNhZmUgYW5k IGRpc2Nsb3NlLCANCj4+IHJhdGhlciB0aGFuIG5vdC4gQW5kIGluIG15IGV4cGVyaWVuY2UsIElQ UiBkaXNjbG9zdXJlcyBhbHdheXMgaGF2ZSBhbiANCj4+IGV4cGxpY2l0IG9yIGltcGxpY2l0IHVz ZSBvZiB0aGUgd29yZCAibWF5IiB0byBpbmRpY2F0ZSB0aGF0IElQUiAibWF5Ig0KPj4gYXBwbHku IFdoZXRoZXIgSVBSIGRvZXMgYWN0dWFsbHkgYXBwbHkgdG8gc3BlY2lmaWMgdGVjaG5vbG9neSBp cyBhIA0KPj4gbnVhbmNlZCBkaXNjdXNzaW9uIGFuZCBvbmUgaW52b2x2aW5nIGxhd3llcnMgYW5k IHRoZSBjb3VydHMuIA0KPj4gRGlmZmVyZW50IHBlb3BsZSB3aWxsIGhhdmUgZGlmZmVyZW50IG9w aW5pb25zLg0KPj4NCj4+PiBJyrxtIHJlLWl0ZXJhdGluZyBteSBjb21tZW50IHRvIHJlbW92ZSBz ZWN0aW9uIDMgZnJvbSB0aGUgUFMgZHJhZnQgYXMgDQo+Pj4gaXQNCj4+IHNlZW1zDQo+Pj4gdGhp cyBpcyB0aGUgb25seSBwYXJ0IHRoYXQgaXMgY2xvc2UgdG8gdGhlIHNvbHV0aW9uIHBhcnQgdGhh biB0aGUgDQo+Pj4gcHJvYmxlbSBkaXNjdXNzaW9uLg0KPj4NCj4+IEl0J3MgaGFyZCB0byBzZWUg aG93IHJlbW92aW5nIHNlY3Rpb24gMyB3aWxsIGhhdmUgYW55IGltcGFjdCBvbiBJUFIgDQo+PiBy ZWxhdGVkIHRvIFNGQy4gRmlyc3QsIHJlbW92aW5nIHRoZSBzZWN0aW9uIHdpbGwgbm90IG5lY2Vz c2FyaWx5IGxlYWQgDQo+PiB0byB0aGUgZGlzY2xvc3VyZSBzdGF0ZW1lbnQgYmVpbmcgcmVtb3Zl ZCAoc2VlIGFib3ZlKS4NCj4+DQo+PiBTZWNvbmQsIGlmIHRoZXJlIGFjdHVhbGx5IGlzIGluIGZh Y3QgSVBSIHRoYXQgYXBwbGllcyB0byBTRkMsIHRoYXQgDQo+PiB3aWxsIGJlY29tZSBjbGVhciB3 aGVuIHdlIGRldmVsb3Agc29sdXRpb25zLCBhbmQgYWRkaXRpb25hbCBzcGVjaWZpYyANCj4+IGRp c2Nsb3N1cmVzIHdpbGwgbmVlZCB0byBiZSBtYWRlIHRoZW4uIChNYWtpbmcgYSBkaXNjbG9zdXJl IGZvciBvbmUgDQo+PiBkb2N1bWVudCBpc24ndCBlbm91Z2ggLS0gZGlzY2xvc3VyZXMgbmVlZCB0 byBiZSBtYWRlIGZvciBldmVyeSANCj4+IGRvY3VtZW50IHRvIHdoaWNoIElQUiBtaWdodCBhcHBs eS4pIFRodXMsIHR3ZWFraW5nIHRoZSBwcm9ibGVtIA0KPj4gc3RhdGVtZW50IGluIGFuIGF0dGVt cHQgdG8gYXZvaWQgYW4gSVBSIGRpc2Nsb3N1cmUgc2VlbXMgbW9yZSBsaWtlIA0KPj4gd2lzaGZ1 bCB0aGlua2luZyB0aGFuIHN1YnN0YW5jZS4gIEFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoZSBw cm9ibGVtIA0KPj4gc3RhdGVtZW50IHdpbGwgc3VyZWx5IGNvbWUgdXAgYWdhaW4gaW4gdGhlIGNv bnRleHQgb2Ygc3BlY2lmaWMgYSANCj4+IHNvbHV0aW9uLiBJTU8sIGl0IHdvdWxkIGJlIG1vcmUg YXBwcm9wcmlhdGUgZm9yIHRoZSBXRyB0byBkaXNjdXNzIGhvdyANCj4+IHRvIGhhbmRsZSBwb3Rl bnRpYWwgSVBSIHdoZW4gZGlzY3Vzc2luZyBzcGVjaWZpYyBzb2x1dGlvbnMgLS0gd2hlbiB3ZSAN Cj4+IGNhbiBoYXZlIGEgZGlzY3Vzc2lvbiBpbiB0aGUgY29udGV4dCBvZiBzcGVjaWZpYyB0ZWNo bmljYWwgYXBwcm9hY2hlcyANCj4+IHRoYXQgYXJlIGJlaW5nIGNvbnNpZGVyZWQuDQo+Pg0KPj4g QSBudW1iZXIgb2YgZm9sayBvbiB0aGlzIHRocmVhZCBoYXZlIGFkZGVkIGEgIisxIi4gSXQgd291 bGQgYmUgDQo+PiBoZWxwZnVsIHRvIGdldCBhZGRpdGlvbmFsIGNsYXJpdHkgYXMgdG8gd2hldGhl ciB0aGUgYWdyZWVtZW50IGlzIA0KPj4gYWJvdXQgdGhlIHN1cnByaXNlIGF0IHRoZSBJUFIgc3Rh dGVtZW50IGFuZCBhIGRlc2lyZSB0byB0cnkgYW5kIGF2b2lkIA0KPj4gaGF2aW5nIHRoZSBwcm9i bGVtIHN0YXRlbWVudCBkb2N1bWVudCBoYXZlIGFuIElQUiBkaXNjbG9zdXJlIA0KPj4gc3RhdGVt ZW50IGFzc29jaWF0ZWQgd2l0aCBpdCwgb3Igd2hldGhlciB0aGVyZSBpcyBhIHN1cHBvcnQgdG8g cmVtb3ZlIA0KPj4gc2VjdGlvbiAzIGZvciBvdGhlciByZWFzb25zIHRoYW4gdGhlIElQUiBkaXNj bG9zdXJlICh0aGVyZSBoYXZlIGJlZW4gDQo+PiBlYXJsaWVyL3NlcGFyYXRlIHRocmVhZHMgb24g dGhpcyBxdWVzdGlvbikuDQo+Pg0KPj4gVGhvbWFzDQo+Pg0KPj4+DQo+Pj4gQ2hlZXJzLA0KPj4+ DQo+Pj4gTWVkDQo+Pj4NCj4+Pg0KPj4+IFsyICA8dGV4dC9wbGFpbjsgdXMtYXNjaWkgKDdiaXQp Pl0NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+PiBzZmNAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZmMgbWFpbGluZyBsaXN0DQo+IHNmY0BpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZmMgbWFpbGlu ZyBsaXN0DQo+IHNmY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYw0KPg0KDQotLSANCg0KDQpMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAg ICAgICAgZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KU2VuaW9yIE1QTFMgRXhwZXJ0ICAg ICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnUNCkh1YXdlaSBUZWNobm9sb2dpZXMgKGNv bnN1bHRhbnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0K From nobody Mon May 5 13:44:18 2014 Return-Path: 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 B7DE21A0161 for ; Mon, 5 May 2014 13:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 yZ0ugAg-orvL for ; Mon, 5 May 2014 13:44:15 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id A10BE1A0114 for ; Mon, 5 May 2014 13:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1687; q=dns/txt; s=iport; t=1399322652; x=1400532252; h=from:to:subject:date:message-id:mime-version; bh=Aig33F1DS3hpZuhj+zfYo8Uobyl/E4aR9H/DWpSz5Ig=; b=IdGH9XMoX7/8uWYljFppNMGl/LfKqLzvVoR+WbXSu9pWTn3b1r0R3Gl/ MK0jzb4vEOIfyOIHmeylIsHlQjiFhn/37rRcD/Hz+PilAhhD6Q5CkhcV1 Rai3ULZAsbpWeSnhO2YLLSMUA8Znt/nCAvjuPSqCUKcaCotHIbeG+XjOe A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtQGAG33Z1OtJA2I/2dsb2JhbABZgkJEgSeqNAUBmyYWdIIcEB1uAQsBdCcEiFSYdrRPF4VWjUIEmTSSdIM0gi8 X-IronPort-AV: E=Sophos;i="4.97,991,1389744000"; d="scan'208,217";a="322529262" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-7.cisco.com with ESMTP; 05 May 2014 20:44:08 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s45Ki8g7018439 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 5 May 2014 20:44:08 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.229]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Mon, 5 May 2014 15:44:07 -0500 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: WG acceptance of mobility use case document Thread-Index: AQHPaKLB6nYtXs3x6EaagCg/DC+0aA== Date: Mon, 5 May 2014 20:44:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.43.180] Content-Type: multipart/alternative; boundary="_000_CF8D705320424jguicharciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/0JsHqAx2dGy_pXzIQONO20BxSQw Subject: [sfc] WG acceptance of mobility use case document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 20:44:16 -0000 --_000_CF8D705320424jguicharciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings: Thank you for your responses on the call for adoption of draft-haeffner-sfc= -use-case-mobility. There is general consensus that the document provides a= good baseline for documenting mobility use cases and should serve as the b= asis for a WG document. Authors, please post a new version as draft-ietf-sfc-use-case-mobility-00. Jim & Thomas. --_000_CF8D705320424jguicharciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Greetings:

Thank you for your responses on the call for adoption of draft-haeffne= r-sfc-use-case-mobility. There is general consensus that the document provi= des a good baseline for documenting mobility use cases and should serve as = the basis for a WG document.

Authors, please post a new version as draft-ietf-sfc-use-case-mobility= -00.

Jim & Thomas.


--_000_CF8D705320424jguicharciscocom_-- From nobody Mon May 5 23:00:53 2014 Return-Path: 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 8B4381A0251 for ; Mon, 5 May 2014 23:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 Zx0_aoNI6g_c for ; Mon, 5 May 2014 23:00:48 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 547B21A0246 for ; Mon, 5 May 2014 23:00:48 -0700 (PDT) Received: from [192.168.1.8] (unknown [119.95.153.210]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id F20DE1800905; Tue, 6 May 2014 08:00:41 +0200 (CEST) Message-ID: <53687A87.6040104@pi.nu> Date: Tue, 06 May 2014 08:00:39 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: David Allan I , "mohamed.boucadair@orange.com" , Thomas Narten References: <94C682931C08B048B7A8645303FDC9F36F58B44EEF@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F5B63D0F9@PUEXCB1B.nanterre.francetelecom.fr> <5367D495.1030600@pi.nu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/PqUDKavK6dJfuOZPP64LlVSxSJ8 Cc: "sfc@ietf.org" Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 06:00:51 -0000 Dave, Yes I understood the Schrödinger analogy... What i meant was that in a Schrödinger experiment we know that there is a cat in the box, we just need to find if it is alive or dead. Of course a real cat could have died of other reasons than decaying atom. In our case we need also decide if there is a cat from the beginning. a. live cat b.1 cat dead due detected radioactivity b.2 cat dead of other reasons c. no cat In our cases I think a. corresponds to a live and kicking cat, an IPR where everyone implementing will have to pay fees to do so. b.1 would correspond to the situation where we just accept the IPR as is and the IPR holder tries but fail draw licensing fees from implementers b.2 would correspond to the case where we accept the IPR, but the IPR holder does not try to draw licensing fees c. would correspond to the situation where the IPR holder more precisely declare the scope of the IPR - the entire technology or just some part of it I would wish for the IPR holder to come back to us and tell us what the scope is. Yes - I agree that some type of consensus should be called soon, or the problem booted upstairs. /Loa On 2014-05-05 20:33, David Allan I wrote: > HI Loa: > > I was thinking of Schrödinger.... > http://en.wikipedia.org/wiki/Schr%C3%B6dinger's_cat > > We are simply deferring the determination of IPR relevance, as presumably if the IPR was claimed to possibly apply in the problem statement, it likely "may" apply to derivative works... > > So excluding text from the draft does not make the IPR go away, and if the deleted section was what the IPR actually applied to, it leaves it in some limbo indeterminate state w.r.t. SFC and if it did not resolve the IPR issue then what do we do? All we know is we've had some vague shot across our bow sailing in a fog.... > > My opinion was from the POV of the IPR issue, deleting text from the draft was an administrative expedient that actually did nothing... > > And while not being a lawyer, I would observe that one does not "build" problem statements, so proving infringement is somewhat difficult. > > Dave > > > > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Monday, May 05, 2014 11:13 AM > To: David Allan I; mohamed.boucadair@orange.com; Thomas Narten > Cc: sfc@ietf.org > Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement > > Dave, > > The issue is if there is a cat in the boc, is there? > > /Loa > > On 2014-05-05 18:42, David Allan I wrote: >> Hi: >> >> Would not removing the section be simply kicking the can down the road? Simply deferring opening the box with the cat in it.... >> >> At least that is how it looks from here... >> D >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >> mohamed.boucadair@orange.com >> Sent: Monday, May 05, 2014 12:21 AM >> To: Thomas Narten >> Cc: sfc@ietf.org >> Subject: Re: [sfc] IPR related to draft-ietf-sfc-problem-statement >> >> Thomas, >> >> It is not up to me to assess the validity of an IPR disclosure. >> >> The main point is to revisit the draft to make hard to apply an IPR on it: this means exclude any solution discussion (i.e. section 3). >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Thomas Narten [mailto:narten@us.ibm.com] Envoyé : vendredi 2 mai >>> 2014 19:11 À : BOUCADAIR Mohamed IMT/OLN Cc : sfc@ietf.org Objet : Re: >>> [sfc] IPR related to draft-ietf-sfc-problem-statement >>> >>> Let me try to split this thread into two different pieces. >>> >>> At Thu, 24 Apr 2014 08:27:20 +0200, wrote: >>> >>>> When checking the tracker, I found there is an IPR disclosure for >>>> the >>> problem >>>> statement document: >>>> >>>> https://datatracker.ietf.org/ipr/search/?option=document_search&id= >>>> draft-ietf-sfc-problem-statement >>>> >>>> Iʼm surprised to see such disclosure for a document that is supposed >>>> to describe only problems (except section 3). >>> >>> Personally, I'm surprised too. But doesn't matter. >>> >>> Making an IPR disclosure is a legal decision, not an engineering one. >>> The IETF is quite clear about IPR -- better to be safe and disclose, >>> rather than not. And in my experience, IPR disclosures always have an >>> explicit or implicit use of the word "may" to indicate that IPR "may" >>> apply. Whether IPR does actually apply to specific technology is a >>> nuanced discussion and one involving lawyers and the courts. >>> Different people will have different opinions. >>> >>>> Iʼm re-iterating my comment to remove section 3 from the PS draft as >>>> it >>> seems >>>> this is the only part that is close to the solution part than the >>>> problem discussion. >>> >>> It's hard to see how removing section 3 will have any impact on IPR >>> related to SFC. First, removing the section will not necessarily lead >>> to the disclosure statement being removed (see above). >>> >>> Second, if there actually is in fact IPR that applies to SFC, that >>> will become clear when we develop solutions, and additional specific >>> disclosures will need to be made then. (Making a disclosure for one >>> document isn't enough -- disclosures need to be made for every >>> document to which IPR might apply.) Thus, tweaking the problem >>> statement in an attempt to avoid an IPR disclosure seems more like >>> wishful thinking than substance. Any IPR that applies to the problem >>> statement will surely come up again in the context of specific a >>> solution. IMO, it would be more appropriate for the WG to discuss how >>> to handle potential IPR when discussing specific solutions -- when we >>> can have a discussion in the context of specific technical approaches >>> that are being considered. >>> >>> A number of folk on this thread have added a "+1". It would be >>> helpful to get additional clarity as to whether the agreement is >>> about the surprise at the IPR statement and a desire to try and avoid >>> having the problem statement document have an IPR disclosure >>> statement associated with it, or whether there is a support to remove >>> section 3 for other reasons than the IPR disclosure (there have been >>> earlier/separate threads on this question). >>> >>> Thomas >>> >>>> >>>> Cheers, >>>> >>>> Med >>>> >>>> >>>> [2 ] >>>> _______________________________________________ >>>> 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 mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue May 6 07:21:48 2014 Return-Path: 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 C84651A035C; Tue, 6 May 2014 07:21:44 -0700 (PDT) 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] 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 NqQffDAHEZYB; Tue, 6 May 2014 07:21:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2991A029E; Tue, 6 May 2014 07:21:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140506142142.962.94402.idtracker@ietfa.amsl.com> Date: Tue, 06 May 2014 07:21:42 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/W7G2Opjlp45H0NIs3tTSupm6e7I Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 14:21:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining Working Group of the IETF. Title : Service Function Chaining Use Cases in Mobile Networks Authors : Walter Haeffner Jeffrey Napper Martin Stiemerling Diego R. Lopez Jim Uttaro Filename : draft-ietf-sfc-use-case-mobility-00.txt Pages : 23 Date : 2014-05-06 Abstract: This document provides some exemplary use cases for service function chaining in mobile service provider networks. The objective of this draft is not to cover all conceivable service chains in detail. Rather, the intention is to localize and explain the application domain of service chaining within mobile networks as far as it is required to complement the problem statement and framework statements of the working group. Service function chains typically reside in a LAN segment which links the mobile access network to the actual application platforms located in the carrier's datacenters or somewhere else in the Internet. Service function chains ensure a fair distribution of network resources according to agreed service policies, enhance the performance of service delivery, take care of security and privacy or support application and business support platforms. General considerations and specific use cases are presented in this document to demonstrate the different technical requirements of these goals for service function chaining in mobile service provider networks. The specification of service function chaining for mobile networks must take into account an interaction between service function chains and the 3GPP Policy and Charging Control (PCC) environment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 6 15:39:16 2014 Return-Path: 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 B6B9A1A0660 for ; Tue, 6 May 2014 15:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 JnrSLfo2Bb1X for ; Tue, 6 May 2014 15:39:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0567D1A03D7 for ; Tue, 6 May 2014 15:39:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDW79941; Tue, 06 May 2014 22:39:05 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 6 May 2014 23:37:27 +0100 Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 6 May 2014 23:39:02 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml704-chm.china.huawei.com ([169.254.6.56]) with mapi id 14.03.0158.001; Tue, 6 May 2014 15:38:52 -0700 From: Lucy yong To: "Paul Quinn (paulq)" , "Joel M. Halpern" Thread-Topic: Comments on RE: New Version Notification for draft-quinn-sfc-arch-05.txt Thread-Index: AQHPaIfarkMZcB0ak0qMpN0Eo35H05s0D0DQ Date: Tue, 6 May 2014 22:38:51 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453757B4@dfweml701-chm.china.huawei.com> References: <20140505173129.23329.89665.idtracker@ietfa.amsl.com> <5A389ED0-86BF-4F6B-A367-5C1512C9D589@cisco.com> In-Reply-To: <5A389ED0-86BF-4F6B-A367-5C1512C9D589@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.140.254] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D453757B4dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/gEk2vLjSNCl_lKMJdeB0wtmlSSw Cc: Lucy yong , "sfc@ietf.org" Subject: [sfc] Comments on RE: New Version Notification for draft-quinn-sfc-arch-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 22:39:13 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D453757B4dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul and Joe, This version expends a lot. The writing is clear. Here are some comments and suggestions: * In introduction, statement "No IANA registry is required to store t= he identity of SFs." Is it important or necessary to state this? If yes, wh= y? * The term of "Service Node" is defined; but the doc. does not descri= be its relationship to other architecture components specified in section 4= . Does it mean that a service node has to contain SF(s), SFF, NF or some of= these components? For example, could a SN only have a SF, i.e. not co-loca= te with SFF/NF? BTW, the service node is barely used in text, which make ha= rd to picture its roles. * Does the architecture allow that passing SFC encapsulated packets b= etween a SF and its associated SFF go through NF or not? * If the SFC architecture allows branching as described, it is good t= o show a branching example in figure 1. BTW, the last sentence in sec. 2.2 = should be moved to sec. 2.1 and state that is the third example in figure 1= . * Section 4 describes core SFC arch components. Classification is sta= ted as a core SFC arch component and is a logical component, and "as a cons= equence of the classification decision, the appropriate SFC encapsulation i= s imposed on the data prior to forwarding along the SFP." However, is does = not illustrate this component in figure 2, which makes unclear how this com= ponent relates to other component in this figure or described in the text. = Suggest illustrating this component in figure 2 and/or describe it in text. * In Section 4.3, don't know why show SFF table here. Does that mean = that all SFs in the table associate to the same SFF? The text and table is = quite misleading. The SFP of SFC may result SFs on multiple SFFs. The table= on each SFF only maintains the SFs in a SFP associated to it. * Statement about stateful SFF mixes with SFC proxy function. It shou= ld be distinct. * SFC architecture should work in multi-tenant environment where indi= vidual tenant may use SFCs. Should we add some clarification on that? * Does the SFC architecture impose some security consideration? State= ment in section 11 seems weak. * Overlay network and SFC network mean the same in this doc, is that = right? May be good to state out clearly or use one term through the doc. Cheers, Lucy -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Monday, May 05, 2014 12:42 PM To: Subject: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-05.tx= t Folks, A new version of the architecture draft has been submitted. This version r= eflect comments from the community, and welcomes a new co-editor: Joel Halp= ern. As always, comments and suggestions are encouraged! Thanks Paul > > > A new version of I-D, draft-quinn-sfc-arch-05.txt has been > successfully submitted by Paul Quinn and posted to the IETF > repository. > > Name: draft-quinn-sfc-arch > Revision: 05 > Title: Service Function Chaining (SFC) Architecture > Document date: 2014-05-05 > Group: Individual Submission > Pages: 31 > URL: http://www.ietf.org/internet-drafts/draft-quinn-sfc-arch-= 05.txt > Status: https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/ > Htmlized: http://tools.ietf.org/html/draft-quinn-sfc-arch-05 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-quinn-sfc-arch-0= 5 > > Abstract: > This document describes an architecture for the specification, > creation, and ongoing maintenance of Service Function Chains (SFC) in > a network. It includes architectural concepts, principles, and > components used in the construction of composite services through > deployment of SFCs. This document does not propose solutions, > protocols, or extensions to existing protocols. > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.iet= f.org. > > The IETF Secretariat > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_2691CE0099834E4A9C5044EEC662BB9D453757B4dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Paul and Joe,
 
This version expends a lot. The writing is clear.
 
Here are some comments and suggestions:
 
  • In introduction, statement "No IANA registry is required to store = the identity of SFs." Is it important or necessary to state this? If y= es, why?
 
  • The term of "Service Node" is defined; but the doc. does not = describe its relationship to other architecture components specified in sec= tion 4. Does it mean that a service node has to contain SF(s), SFF, NF or s= ome of these components? For example, could a SN only have a SF, i.e. not co-locate with SFF/NF? BTW, the service node = is barely used in text, which make hard to picture its roles.
 
  • Does the architecture allow that passing SFC encapsulated packets betwe= en a SF and its associated SFF go through NF or not?
 
  • If the SFC architecture allows branching as described, it is good to sh= ow a branching example in figure 1. BTW, the last sentence in sec. 2.2 shou= ld be moved to sec. 2.1 and state that is the third example in figure 1.
 
  • Section 4 describes core SFC arch components. Classification is stated = as a core SFC arch component and is a logical component, and "as a con= sequence of the classification decision, the appropriate SFC encapsulation = is imposed on the data prior to forwarding along the SFP." However, is does not illustrate this component in figu= re 2, which makes unclear how this component relates to other component in = this figure or described in the text. Suggest illustrating this component i= n figure 2 and/or describe it in text.
 
  • In Section 4.3, don't know why show SFF table here. Does that mean that= all SFs in the table associate to the same SFF? The text and table is quit= e misleading. The SFP of SFC may result SFs on multiple SFFs. The table on = each SFF only maintains the SFs in a SFP associated to it.
 
  • Statement about stateful SFF mixes with SFC proxy function. It should b= e distinct.
 
  • SFC architecture should work in multi-tenant environment where individu= al tenant may use SFCs. Should we add some clarification on that?
 
  • Does the SFC architecture impose some security consideration? Statement= in section 11 seems weak.
 
  • Overlay network and SFC network mean the same in this doc, is that righ= t? May be good to state out clearly or use one term through the doc.
    •  
     
    Cheers,
    Lucy
     
    -----Original Message-----
    From: sfc [mailto:sfc-bounces@ietf.= org] On Behalf Of Paul Quinn (paulq)
    Sent: Monday, May 05, 2014 12:42 PM
    To: <sfc@ietf.org>
    Subject: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-05.tx= t
     
    Folks,
     
    A new version of the architecture draft has been submitted.  This= version reflect comments from the community, and welcomes a new co-editor:= Joel Halpern.
     
    As always, comments and suggestions are encouraged!
     
    Thanks
    Paul
     
    >
    >
    > A new version of I-D, draft-quinn-sfc-arch-05.txt has been
    > successfully submitted by Paul Quinn and posted to the IETF
    > repository.
    >
    > Name:         draft-quinn= -sfc-arch
    > Revision:     05
    > Title:          = ;      Service Function Chaining (SFC) Architectur= e
    > Document date:        2014-05-= 05
    > Group:          = ;      Individual Submission
    > Pages:          = ;      31
    > URL:          &= nbsp; http://www.ietf.org/internet-drafts/draft-quinn-sfc-arch-05.txt<= /div>
    >
    > Abstract:
    >   This document describes an architecture for the speci= fication,
    >   creation, and ongoing maintenance of Service Function= Chains (SFC) in
    >   a network.  It includes architectural concepts, = principles, and
    >   components used in the construction of composite serv= ices through
    >   deployment of SFCs.  This document does not prop= ose solutions,
    >   protocols, or extensions to existing protocols.
    >
    >
    >
    >
    > Please note that it may take a couple of minutes from the time of=
    > submission until the htmlized version and diff are available at t= ools.ietf.org.
    >
    > The IETF Secretariat
    >
     
    _______________________________________________
    sfc mailing list
     
     --_000_2691CE0099834E4A9C5044EEC662BB9D453757B4dfweml701chmchi_-- From nobody Tue May 6 23:24:32 2014 Return-Path: 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 89DEE1A024E for ; Tue, 6 May 2014 23:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 M2C8ALXqCT3Z for ; Tue, 6 May 2014 23:24:28 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 79E691A064D for ; Tue, 6 May 2014 23:24:28 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id l4so669810lbv.6 for ; Tue, 06 May 2014 23:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=uFY8iFnAxewcXz/Unuwpu7jTxOSuF33O8tX11poJx0o=; b=aHHnUb+sN0Ke8gsxJKiROGz/kqDc0P30zkRo4Gwk4gNz+BmQS/ypPnyxb+bUh/OVS0 lQB4xpr60DRfkG4yT2Xq8IEx9amWRND6d7ztsgKlkEwnulEnZwk+qxRfCEEZeMjtXkcu g9Zjnai+EpoZWlgNI5Q+3VuLDtbhTm+t7UVwwnUOA9bqeakuzEtw/yDCkKVreLo4U1Dm k0fVi00z66T9wGr1bgwFhkwm8W//DNVA8eLBLEU6NqrKejk5lXNHhLNbasBiW3itVsfr nBvIJCUepLHNqyGpR5LbVZ33o+qYaPi21g9slGBGxtzl9K8qL2BfkcdBKNpf20XtVM6a xU9Q== X-Received: by 10.112.128.231 with SMTP id nr7mr38407921lbb.9.1399443863654; Tue, 06 May 2014 23:24:23 -0700 (PDT) Received: from [192.168.250.146] ([194.100.71.98]) by mx.google.com with ESMTPSA id k2sm16077937lbm.23.2014.05.06.23.24.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 May 2014 23:24:22 -0700 (PDT) Message-ID: <5369D194.8050801@gmail.com> Date: Wed, 07 May 2014 09:24:20 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: sfc@ietf.org References: <20140506142142.962.94402.idtracker@ietfa.amsl.com> In-Reply-To: <20140506142142.962.94402.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/azNqRulkn3lTj1DIo7kVxyauGGk Subject: [sfc] Few comments on draft-ietf-sfc-use-case-mobility-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 06:24:30 -0000 Hi, This is a small set of nits for Section 2.1 but I'd like to see them discussed & corrected. See the mail I sent earlier on the same topic when the document was still an individual I-D: http://www.ietf.org/mail-archive/web/sfc/current/msg01253.html - Jouni 5/6/2014 5:21 PM, internet-drafts@ietf.org kirjoitti: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Service Function Chaining Working Group of the IETF. > > Title : Service Function Chaining Use Cases in Mobile Networks > Authors : Walter Haeffner > Jeffrey Napper > Martin Stiemerling > Diego R. Lopez > Jim Uttaro > Filename : draft-ietf-sfc-use-case-mobility-00.txt > Pages : 23 > Date : 2014-05-06 From nobody Wed May 7 03:59:27 2014 Return-Path: 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 1543A1A06C9 for ; Wed, 7 May 2014 03:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 hUZb0pYEa4Wv for ; Wed, 7 May 2014 03:59:24 -0700 (PDT) Received: from mailout04.vodafone.com (mailout04.vodafone.com [195.232.224.73]) by ietfa.amsl.com (Postfix) with ESMTP id EB51B1A06CA for ; Wed, 7 May 2014 03:59:23 -0700 (PDT) Received: from mailint04.vodafone.com (localhost [127.0.0.1]) by mailout04.vodafone.com (Postfix) with ESMTP id 79D9080A45 for ; Wed, 7 May 2014 12:59:15 +0200 (CEST) Received: from VOEXC05W.internal.vodafone.com (voexc05w.dc-ratingen.de [145.230.101.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint04.vodafone.com (Postfix) with ESMTPS id 69F5580A14; Wed, 7 May 2014 12:59:15 +0200 (CEST) Received: from AVOEXC04W.internal.vodafone.com (145.230.15.142) by VOEXC05W.internal.vodafone.com (145.230.101.25) with Microsoft SMTP Server (TLS) id 14.3.146.2; Wed, 7 May 2014 12:59:15 +0200 Received: from VOEXM20W.internal.vodafone.com ([169.254.4.132]) by AVOEXC04W.internal.vodafone.com ([145.230.15.142]) with mapi id 14.03.0146.002; Wed, 7 May 2014 12:59:13 +0200 From: "Haeffner, Walter, Vodafone DE" To: Jouni Korhonen , "sfc@ietf.org" Thread-Topic: [sfc] Few comments on draft-ietf-sfc-use-case-mobility-00 Thread-Index: AQHPab0Hct6L0tPUlUuePdJwfYeh45s06aWA Date: Wed, 7 May 2014 10:59:13 +0000 Message-ID: References: <20140506142142.962.94402.idtracker@ietfa.amsl.com> <5369D194.8050801@gmail.com> In-Reply-To: <5369D194.8050801@gmail.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: 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/0_w4WPTH1hZ4adaDFUKoTPOYOxg Cc: "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" Subject: Re: [sfc] Few comments on draft-ietf-sfc-use-case-mobility-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 10:59:26 -0000 Referring to your February 21st email link below: Hi Jouni, Sorry, I missed that part. Only added TDF function. To keep it simple I sug= gest: 1.) to delete .... "as well as control plane" and just refer to user plan= e, leaving away any control stuff and write The radio-based IP traffic between the UE and the eNB is encrypted accordin= g 3GPP standards. Between eNB, S-GW, P-GW user plane IP packets are encap= sulated in 3GPP-specific tunnels. =20 2.) Accept. For the moment I propose to add a sentence for clarification: In some mobile carrier networks the 3GPP specific tunnels between eNB and S= -GW are even additionally IPSec-encrypted. More precisely, IPSec originates= /terminates at the eNB and on the other side at an IPSec-GW often placed ju= st in front of the S-GW. For more details see [TS.29.281], [TS.29.274] an= d [TS33.210]. Any suggestions for a better wording? Kind regards,=20 Walter -----Urspr=FCngliche Nachricht----- Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Jouni Korhonen Gesendet: Mittwoch, 7. Mai 2014 08:24 An: sfc@ietf.org Betreff: [sfc] Few comments on draft-ietf-sfc-use-case-mobility-00 Hi, This is a small set of nits for Section 2.1 but I'd like to see them discus= sed & corrected. See the mail I sent earlier on the same topic when the doc= ument was still an individual I-D: http://www.ietf.org/mail-archive/web/sfc/current/msg01253.html - Jouni 5/6/2014 5:21 PM, internet-drafts@ietf.org kirjoitti: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Service Function Chaining Working Grou= p of the IETF. > > Title : Service Function Chaining Use Cases in Mobile = Networks > Authors : Walter Haeffner > Jeffrey Napper > Martin Stiemerling > Diego R. Lopez > Jim Uttaro > Filename : draft-ietf-sfc-use-case-mobility-00.txt > Pages : 23 > Date : 2014-05-06 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From Tomy.Ng@team.telstra.com Wed May 7 00:22:52 2014 Return-Path: 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 D4EE01A016D for ; Wed, 7 May 2014 00:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no 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 fpAaKvu8zIpm for ; Wed, 7 May 2014 00:22:51 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 2767A1A065D for ; Wed, 7 May 2014 00:22:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,1001,1389704400"; d="scan'208,217";a="188224805" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipocni.tcif.telstra.com.au with ESMTP; 07 May 2014 17:22:47 +1000 X-IronPort-AV: E=McAfee;i="5600,1067,7430"; a="229161859" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipccni.tcif.telstra.com.au with ESMTP; 07 May 2014 17:22:43 +1000 Received: from WSMSG3103V.srv.dir.telstra.com ([172.49.40.139]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Wed, 7 May 2014 17:22:43 +1000 From: "Ng, Tomy" To: Qiong , "Pham, Chuong D" Date: Wed, 7 May 2014 17:22:42 +1000 Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: Ac9nyxw3j9b7gTYtQtu5YBZKK5TjxgB+bufQ Message-ID: References: <5351B460.5040709@joelhalpern.com> <5602569641FB314FB4D9AD5659D41B9C2C1B0AA05D@WSMSG3154V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_DE51876A0B79C24589A3AF4BB0EB64EF951619DAEEWSMSG3103Vsrv_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/CfBcf1LwRjFduRL0ftEjbl1Z6ls X-Mailman-Approved-At: Wed, 07 May 2014 08:12:12 -0700 Cc: "Joel M. Halpern" , "Jim Guichard \(jguichar\)" , "Haeffner, Walter, Vodafone DE" , "sfc@ietf.org" , "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 07:26:15 -0000 --_000_DE51876A0B79C24589A3AF4BB0EB64EF951619DAEEWSMSG3103Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpBZ3JlZSB3aXRoIENodW9uZ+KAmXMgdmlld3BvaW50IGFuZCBJIGRpc2FwcHJv dmUgdGhlIGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQuDQoNCkNoZWVycw0KDQpUb215DQouLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLg0KDQpPbiBXZWQsIEFwciAz MCwgMjAxNCBhdCA3OjM1IEFNLCBQaGFtLCBDaHVvbmcgRCA8Q2h1b25nLkQuUGhhbUB0ZWFtLnRl bHN0cmEuY29tPG1haWx0bzpDaHVvbmcuRC5QaGFtQHRlYW0udGVsc3RyYS5jb20+PiB3cm90ZToN ClNlcGFyYXRlIGRyYWZ0cyBmb3IgcG9ja2V0cyBvZiBlbnZpcm9ubWVudHMgd2lsbCBtb3N0IGxp a2VseSBvdmVybG9vayB0aGUgb3Bwb3J0dW5pdGllcyBmb3IgaWRlbnRpZnlpbmcgY29tbW9uYWxp dGllcywgc3luZXJnaWVzIGFuZCByZXVzZSBmYWN0b3JzIGJldHdlZW4gc2ltaWxhciB1c2UgY2Fz ZXMgZm9yIGRpZmZlcmVudCBlbnZpcm9ubWVudHMuIFRoaXMgaXMgdGhlIHBhaW5mdWwgc2l0dWF0 aW9uIHRvZGF5IHdoZXJlIHNpbG9zIGV4aXN0IHdoaWxlIGF0IHRoaXMgcG9pbnQgaW4gdGltZSB3 aGVyZSBNb2JpbGUsIEZpeGVkIEJyb2FkYmFuZCBhbmQgRGF0YSBDZW50cmUgYXJlIHNlZWluZyBz dHJvbmcgZm9yY2VzIHRvd2FyZHMgY29udmVyZ2VuY2Ugd2l0aCBTRE4sIE5GViBhbmQgQ2xvdWQg dGVjaG5vbG9naWVzLg0KDQpBbiBvdmVyYWxsIGRyYWZ0IHN1Y2ggYXMgZHJhZnQtbGl1IG9yIHNp bWlsYXIgbXVzdCBleGlzdCBhcyBhIGNvbW1vbiByZWZlcmVuY2UgcG9pbnQgZm9yIG1vcmUgZGV0 YWlsZWQgbGV2ZWwgZHJhZnRzIGFkZHJlc3NpbmcgdXNlIGNhc2VzIGZvciBzcGVjaWZpYy9wb2Nr ZXRzIG9mIGVudmlyb25tZW50cyB3aGlsZSBhbGxvd2luZyBmb3IgZnV0dXJlIG1pZ3JhdGlvbi9j b252ZXJnZW5jZS4NCg0KVW5sZXNzIGRyYWZ0LWt1bWFyIGNvLWV4aXN0cyB3aXRoIGhpZ2ggbGV2 ZWwgZHJhZnQtbGl1LCBJIHNlZSBtb3JlIGhhcm0gaW4gZGl2ZXJnZW5jZSByYXRoZXIgdGhhbiBi ZW5lZml0cyB0aGVyZWZvcmUgSSBkaXNhcHByb3ZlLg0KDQpSZWdhcmRzLA0KQ2h1b25nDQoNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEhhZWZmbmVyLCBXYWx0ZXIsIFZvZGFm b25lIERFIFttYWlsdG86d2FsdGVyLmhhZWZmbmVyQHZvZGFmb25lLmNvbTxtYWlsdG86d2FsdGVy LmhhZWZmbmVyQHZvZGFmb25lLmNvbT5dDQpTZW50OiBXZWRuZXNkYXksIDMwIEFwcmlsIDIwMTQg Mjo1NiBBTQ0KVG86IEpvZWwgTS4gSGFscGVybjsgSmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IHNm Y0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KQ2M6IEplZmZyZXkgTmFwcGVyIChqZW5h cHBlcikgKGplbmFwcGVyQGNpc2NvLmNvbTxtYWlsdG86amVuYXBwZXJAY2lzY28uY29tPikNClN1 YmplY3Q6IFJlOiBbc2ZjXSBDYWxsIGZvciBhZG9wdGlvbiBvZiBkcmFmdC1rdW1hci1zZmMtZGMt dXNlLWNhc2VzLTAxDQoNCkkgYWxzbyBzdXBwb3J0IHRoaXMgZHJhZnQuIEJlaW5nIG9uIERDIGxl dmVsIHRoaXMgZHJhZnQgd2lsbCBjb21wbGVtZW50IHRoZSBvdGhlciB1c2UgY2FzZSBkcmFmdHMu IEJlc2lkZSB0eXBpY2FsIEZXIG9yIERQSSBldGMuIHRoZXJlIHNob3VsZCBiZSBub3QgdGhhdCBt dWNoIG92ZXJsYXAgd2l0aCB0aGUgbW9yZSBjYXJyaWVyIHNlcnZpY2VzIG9yaWVudGVkIHVzZSBj YXNlIGRyYWZ0cy4NCg0KQ2hlZXJzLCBXYWx0ZXINCg0KDQotLS0tLVVyc3Byw7xuZ2xpY2hlIE5h Y2hyaWNodC0tLS0tDQpWb246IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzpzZmMtYm91bmNlc0BpZXRmLm9yZz5dIEltIEF1ZnRyYWcgdm9uIEpvZWwgTS4gSGFscGVybg0K R2VzZW5kZXQ6IFNhbXN0YWcsIDE5LiBBcHJpbCAyMDE0IDAxOjI1DQpBbjogSmltIEd1aWNoYXJk IChqZ3VpY2hhcik7IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KQmV0cmVmZjog UmU6IFtzZmNdIENhbGwgZm9yIGFkb3B0aW9uIG9mIGRyYWZ0LWt1bWFyLXNmYy1kYy11c2UtY2Fz ZXMtMDENCg0KSSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgYnkgdGhlIHdvcmtp bmcgZ3JvdXAuICBJdCBpcyBhIGdvb2Qgc3RhcnRpbmcgcG9pbnQgZm9yIGFkZHJlc3NpbmcgdGhl IG1hdGVyaWFsIGl0IGNvdmVycywgYW5kIHRoZSB3b3JraW5nIGdyb3VwIHNob3VsZCBjb3ZlciB0 aGF0IG1hdGVyaWFsLg0KDQpZb3VycywNCkpvZWwNCg0KT24gNC8xOC8xNCwgNjozMSBQTSwgSmlt IEd1aWNoYXJkIChqZ3VpY2hhcikgd3JvdGU6DQo+IERlYXIgV0c6DQo+DQo+IFRoaXMgbWVzc2Fn ZSBiZWdpbnMgYSB0d28gd2VlayBjYWxsIGZvciBXRyBhZG9wdGlvbiBvZiB0aGUgZG9jdW1lbnQN Cj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1rdW1hci1zZmMtZGMtdXNlLWNhc2VzLTAx LnR4dCBlbmRpbmcgMm5kDQo+IE1heSAyMDE0Lg0KPg0KPiBQbGVhc2UgcmVzcG9uZCB0byB0aGUg U0ZDIG1haWxpbmcgbGlzdCB3aXRoIGFueSBzdGF0ZW1lbnRzIG9mIGFwcHJvdmFsDQo+IG9yIGRp c2FwcHJvdmFsLg0KPg0KPiBQbGVhc2Ugbm90ZToNCj4NCj4gIDEuIFRoaXMgaXMgbm90IFdHIExh c3QgQ2FsbC4gVGhlIGRvY3VtZW50IGlzIG5vdCBmaW5hbCwgYW5kIHRoZSBXRyBpcw0KPiAgICAg ZXhwZWN0ZWQgdG8gbW9kaWZ5IHRoZSBkb2N1bWVudCdzIGNvbnRlbnQgdW50aWwgdGhlcmUgaXMg V0cNCj4gICAgIGNvbnNlbnN1cyB0aGF0IHRoZSBjb250ZW50IGlzIHNvbGlkLiBUaGVyZWZvcmUs IHBsZWFzZSBkb24ndCBvcHBvc2UNCj4gICAgIGFkb3B0aW9uIGp1c3QgYmVjYXVzZSB5b3Ugd2Fu dCB0byBzZWUgY2hhbmdlcyB0byBpdHMgY29udGVudC4NCj4gIDIuIElmIHlvdSBoYXZlIG9iamVj dGlvbnMgdG8gYWRvcHRpb24gb2YgdGhlIGRvY3VtZW50LCBwbGVhc2Ugc3RhdGUNCj4gICAgIHlv dXIgcmVhc29ucyB3aHksIGFuZCBleHBsYWluIHdoYXQgaXQgd291bGQgdGFrZSB0byBhZGRyZXNz IHlvdXINCj4gICAgIGNvbmNlcm5zLg0KPiAgMy4gSWYgeW91IGhhdmUgaXNzdWVzIHdpdGggdGhl IGNvbnRlbnQsIGJ5IGFsbCBtZWFucyByYWlzZSB0aG9zZSBpc3N1ZXMNCj4gICAgIGFuZCB3ZSBj YW4gYmVnaW4gYSBkaWFsb2cgYWJvdXQgaG93IGJlc3QgdG8gYWRkcmVzcyB0aGVtLg0KPg0KPg0K Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBz ZmMgbWFpbGluZyBsaXN0DQo+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0K c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNm Y0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoN Cg0KDQotLQ0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K UWlvbmcgU3VuDQpDaGluYSBUZWxlY29tIEJlaWppbmcgUmVzZWFyY2ggSW5zdGl0dXRlDQoNCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo= --_000_DE51876A0B79C24589A3AF4BB0EB64EF951619DAEEWSMSG3103Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGku TXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi QmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3 Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t PjwvaGVhZD48Ym9keSBsYW5nPUVOLUFVIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFz cz1Xb3JkU2VjdGlvbjE+PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5I aSBBbGwsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+QWdyZWUg d2l0aCZuYnNwO0NodW9uZ+KAmXMgdmlld3BvaW50IGFuZCBJIGRpc2FwcHJvdmUgdGhlIGFkb3B0 aW9uIG9mIHRoaXMgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIic+Q2hlZXJzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+ VG9teTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdp bi1ib3R0b206MTIuMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5PbiBXZWQsIEFwciAzMCwgMjAxNCBhdCA3 OjM1IEFNLCBQaGFtLCBDaHVvbmcgRCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkNodW9uZy5ELlBoYW1A dGVhbS50ZWxzdHJhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkNodW9uZy5ELlBoYW1AdGVhbS50ZWxz dHJhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5T ZXBhcmF0ZSBkcmFmdHMgZm9yIHBvY2tldHMgb2YgZW52aXJvbm1lbnRzIHdpbGwgbW9zdCBsaWtl bHkgb3Zlcmxvb2sgdGhlIG9wcG9ydHVuaXRpZXMgZm9yIGlkZW50aWZ5aW5nIGNvbW1vbmFsaXRp ZXMsIHN5bmVyZ2llcyBhbmQgcmV1c2UgZmFjdG9ycyBiZXR3ZWVuIHNpbWlsYXIgdXNlIGNhc2Vz IGZvciBkaWZmZXJlbnQgZW52aXJvbm1lbnRzLiBUaGlzIGlzIHRoZSBwYWluZnVsIHNpdHVhdGlv biB0b2RheSB3aGVyZSBzaWxvcyBleGlzdCB3aGlsZSBhdCB0aGlzIHBvaW50IGluIHRpbWUgd2hl cmUgTW9iaWxlLCBGaXhlZCBCcm9hZGJhbmQgYW5kIERhdGEgQ2VudHJlIGFyZSBzZWVpbmcgc3Ry b25nIGZvcmNlcyB0b3dhcmRzIGNvbnZlcmdlbmNlIHdpdGggU0ROLCBORlYgYW5kIENsb3VkIHRl Y2hub2xvZ2llcy48YnI+PGJyPkFuIG92ZXJhbGwgZHJhZnQgc3VjaCBhcyBkcmFmdC1saXUgb3Ig c2ltaWxhciBtdXN0IGV4aXN0IGFzIGEgY29tbW9uIHJlZmVyZW5jZSBwb2ludCBmb3IgbW9yZSBk ZXRhaWxlZCBsZXZlbCBkcmFmdHMgYWRkcmVzc2luZyB1c2UgY2FzZXMgZm9yIHNwZWNpZmljL3Bv Y2tldHMgb2YgZW52aXJvbm1lbnRzIHdoaWxlIGFsbG93aW5nIGZvciBmdXR1cmUgbWlncmF0aW9u L2NvbnZlcmdlbmNlLjxicj48YnI+VW5sZXNzIGRyYWZ0LWt1bWFyIGNvLWV4aXN0cyB3aXRoIGhp Z2ggbGV2ZWwgZHJhZnQtbGl1LCBJIHNlZSBtb3JlIGhhcm0gaW4gZGl2ZXJnZW5jZSByYXRoZXIg dGhhbiBiZW5lZml0cyB0aGVyZWZvcmUgSSBkaXNhcHByb3ZlLjxicj48YnI+UmVnYXJkcyw8YnI+ Q2h1b25nPG86cD48L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48YnI+PGJy Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPkZyb206IEhhZWZmbmVyLCBXYWx0ZXIsIFZv ZGFmb25lIERFIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOndhbHRlci5oYWVmZm5lckB2b2RhZm9u ZS5jb20iPndhbHRlci5oYWVmZm5lckB2b2RhZm9uZS5jb208L2E+XTxicj5TZW50OiBXZWRuZXNk YXksIDMwIEFwcmlsIDIwMTQgMjo1NiBBTTxicj5UbzogSm9lbCBNLiBIYWxwZXJuOyBKaW0gR3Vp Y2hhcmQgKGpndWljaGFyKTsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYu b3JnPC9hPjxicj5DYzogSmVmZnJleSBOYXBwZXIgKGplbmFwcGVyKSAoPGEgaHJlZj0ibWFpbHRv OmplbmFwcGVyQGNpc2NvLmNvbSI+amVuYXBwZXJAY2lzY28uY29tPC9hPik8YnI+U3ViamVjdDog UmU6IFtzZmNdIENhbGwgZm9yIGFkb3B0aW9uIG9mIGRyYWZ0LWt1bWFyLXNmYy1kYy11c2UtY2Fz ZXMtMDE8YnI+PGJyPkkgYWxzbyBzdXBwb3J0IHRoaXMgZHJhZnQuIEJlaW5nIG9uIERDIGxldmVs IHRoaXMgZHJhZnQgd2lsbCBjb21wbGVtZW50IHRoZSBvdGhlciB1c2UgY2FzZSBkcmFmdHMuIEJl c2lkZSB0eXBpY2FsIEZXIG9yIERQSSBldGMuIHRoZXJlIHNob3VsZCBiZSBub3QgdGhhdCBtdWNo IG92ZXJsYXAgd2l0aCB0aGUgbW9yZSBjYXJyaWVyIHNlcnZpY2VzIG9yaWVudGVkIHVzZSBjYXNl IGRyYWZ0cy48YnI+PGJyPkNoZWVycywgV2FsdGVyPGJyPjxicj48YnI+LS0tLS1VcnNwcsO8bmds aWNoZSBOYWNocmljaHQtLS0tLTxicj5Wb246IHNmYyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpz ZmMtYm91bmNlc0BpZXRmLm9yZyI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBJbSBBdWZ0cmFn IHZvbiBKb2VsIE0uIEhhbHBlcm48YnI+R2VzZW5kZXQ6IFNhbXN0YWcsIDE5LiBBcHJpbCAyMDE0 IDAxOjI1PGJyPkFuOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgPGEgaHJlZj0ibWFpbHRvOnNm Y0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj5CZXRyZWZmOiBSZTogW3NmY10gQ2FsbCBm b3IgYWRvcHRpb24gb2YgZHJhZnQta3VtYXItc2ZjLWRjLXVzZS1jYXNlcy0wMTxicj48YnI+SSBz dXBwb3J0IGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAuICZu YnNwO0l0IGlzIGEgZ29vZCBzdGFydGluZyBwb2ludCBmb3IgYWRkcmVzc2luZyB0aGUgbWF0ZXJp YWwgaXQgY292ZXJzLCBhbmQgdGhlIHdvcmtpbmcgZ3JvdXAgc2hvdWxkIGNvdmVyIHRoYXQgbWF0 ZXJpYWwuPGJyPjxicj5Zb3Vycyw8YnI+Sm9lbDxicj48YnI+T24gNC8xOC8xNCwgNjozMSBQTSwg SmltIEd1aWNoYXJkIChqZ3VpY2hhcikgd3JvdGU6PGJyPiZndDsgRGVhciBXRzo8YnI+Jmd0Ozxi cj4mZ3Q7IFRoaXMgbWVzc2FnZSBiZWdpbnMgYSB0d28gd2VlayBjYWxsIGZvciBXRyBhZG9wdGlv biBvZiB0aGUgZG9jdW1lbnQ8YnI+Jmd0OyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2lk L2RyYWZ0LWt1bWFyLXNmYy1kYy11c2UtY2FzZXMtMDEudHh0IiB0YXJnZXQ9Il9ibGFuayI+aHR0 cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1rdW1hci1zZmMtZGMtdXNlLWNhc2VzLTAxLnR4dDwv YT4gZW5kaW5nIDJuZDxicj4mZ3Q7IE1heSAyMDE0Ljxicj4mZ3Q7PGJyPiZndDsgUGxlYXNlIHJl c3BvbmQgdG8gdGhlIFNGQyBtYWlsaW5nIGxpc3Qgd2l0aCBhbnkgc3RhdGVtZW50cyBvZiBhcHBy b3ZhbDxicj4mZ3Q7IG9yIGRpc2FwcHJvdmFsLjxicj4mZ3Q7PGJyPiZndDsgUGxlYXNlIG5vdGU6 PGJyPiZndDs8YnI+Jmd0OyAmbmJzcDsxLiBUaGlzIGlzIG5vdCBXRyBMYXN0IENhbGwuIFRoZSBk b2N1bWVudCBpcyBub3QgZmluYWwsIGFuZCB0aGUgV0cgaXM8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7 IGV4cGVjdGVkIHRvIG1vZGlmeSB0aGUgZG9jdW1lbnQncyBjb250ZW50IHVudGlsIHRoZXJlIGlz IFdHPGJyPiZndDsgJm5ic3A7ICZuYnNwOyBjb25zZW5zdXMgdGhhdCB0aGUgY29udGVudCBpcyBz b2xpZC4gVGhlcmVmb3JlLCBwbGVhc2UgZG9uJ3Qgb3Bwb3NlPGJyPiZndDsgJm5ic3A7ICZuYnNw OyBhZG9wdGlvbiBqdXN0IGJlY2F1c2UgeW91IHdhbnQgdG8gc2VlIGNoYW5nZXMgdG8gaXRzIGNv bnRlbnQuPGJyPiZndDsgJm5ic3A7Mi4gSWYgeW91IGhhdmUgb2JqZWN0aW9ucyB0byBhZG9wdGlv biBvZiB0aGUgZG9jdW1lbnQsIHBsZWFzZSBzdGF0ZTxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgeW91 ciByZWFzb25zIHdoeSwgYW5kIGV4cGxhaW4gd2hhdCBpdCB3b3VsZCB0YWtlIHRvIGFkZHJlc3Mg eW91cjxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgY29uY2VybnMuPGJyPiZndDsgJm5ic3A7My4gSWYg eW91IGhhdmUgaXNzdWVzIHdpdGggdGhlIGNvbnRlbnQsIGJ5IGFsbCBtZWFucyByYWlzZSB0aG9z ZSBpc3N1ZXM8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7IGFuZCB3ZSBjYW4gYmVnaW4gYSBkaWFsb2cg YWJvdXQgaG93IGJlc3QgdG8gYWRkcmVzcyB0aGVtLjxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0Ozxi cj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy PiZndDsgc2ZjIG1haWxpbmcgbGlzdDxicj4mZ3Q7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5v cmciPnNmY0BpZXRmLm9yZzwvYT48YnI+Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxicj4mZ3Q7PGJyPjxicj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5zZmMgbWFpbGluZyBsaXN0PGJy PjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnI+PGJy Pjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5z ZmMgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRm Lm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZmMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYzwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29O b3JtYWw+PGJyPjxiciBjbGVhcj1hbGw+PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+LS0gPGJyPj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT08YnI+UWlvbmcgU3VuPGJyPkNoaW5hIFRlbGVjb20gQmVpamlu ZyBSZXNlYXJjaCBJbnN0aXR1dGU8YnI+PGJyPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5 PjwvaHRtbD4= --_000_DE51876A0B79C24589A3AF4BB0EB64EF951619DAEEWSMSG3103Vsrv_-- From nobody Wed May 7 09:40:04 2014 Return-Path: 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 E22581A0368 for ; Wed, 7 May 2014 09:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 r1dxftw-bKn1 for ; Wed, 7 May 2014 09:39:58 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7311A02BE for ; Wed, 7 May 2014 09:39:57 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id p9so1752124lbv.39 for ; Wed, 07 May 2014 09:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bojn/zUj9PVOrg062utPklWTRnWK0lDlrd6pvK+94lk=; b=wKm8yKLMw+Ogar0KUPbaOBLVw4IqXGIwQX3ZwzdOgK3FJa6doNcgUZsElcD84sI5Q2 xhd/gCuxD53ZRp4+CO+zY0/C9KK19qfgPKJZ1BxfEC6n0k6ulv8VnIkdstGsqoRTSneF bI26YQxU9f7ChKFXrRQhbG2POA70/5189rua7heaB82XjqtqjD5AwILO1JY2sqRNEYVt g1/8FQQm77dPcdVB9hZpBccCUwZ4yx5RTt7WJjTjjIuyIbpYHH9qp3FMJ883emHZvW8f XPWth2meqKubkcx5f1W1zbjF5GW/l31eGdZtci7ihepPh8X2Ob6dxEfaIeF8hy3CYmqy Y08w== MIME-Version: 1.0 X-Received: by 10.112.135.39 with SMTP id pp7mr14890571lbb.29.1399480793228; Wed, 07 May 2014 09:39:53 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Wed, 7 May 2014 09:39:53 -0700 (PDT) In-Reply-To: <5369D194.8050801@gmail.com> References: <20140506142142.962.94402.idtracker@ietfa.amsl.com> <5369D194.8050801@gmail.com> Date: Wed, 7 May 2014 11:39:53 -0500 Message-ID: From: Behcet Sarikaya To: Jouni Korhonen Content-Type: multipart/alternative; boundary=089e01228d1a8d779304f8d2033d Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/PdCDBqjEBqrKKSXhHrPeOUotI54 Cc: "sfc@ietf.org" Subject: Re: [sfc] Few comments on draft-ietf-sfc-use-case-mobility-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 16:40:01 -0000 --089e01228d1a8d779304f8d2033d Content-Type: text/plain; charset=UTF-8 Also I had a comment at this message: http://www.ietf.org/mail-archive/web/sfc/current/msg01906.html Behcet On Wed, May 7, 2014 at 1:24 AM, Jouni Korhonen wrote: > > Hi, > > This is a small set of nits for Section 2.1 but I'd like to see them > discussed & corrected. See the mail I sent earlier on the same topic when > the document was still an individual I-D: > http://www.ietf.org/mail-archive/web/sfc/current/msg01253.html > > - Jouni > > > 5/6/2014 5:21 PM, internet-drafts@ietf.org kirjoitti: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Service Function Chaining Working >> Group of the IETF. >> >> Title : Service Function Chaining Use Cases in Mobile >> Networks >> Authors : Walter Haeffner >> Jeffrey Napper >> Martin Stiemerling >> Diego R. Lopez >> Jim Uttaro >> Filename : draft-ietf-sfc-use-case-mobility-00.txt >> Pages : 23 >> Date : 2014-05-06 >> > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --089e01228d1a8d779304f8d2033d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Be= hcet


    On Wed,= May 7, 2014 at 1:24 AM, Jouni Korhonen <jouni.nospam@gmail.com&g= t; wrote:

    Hi,

    This is a small set of nits for Section 2.1 but I'd like to see them di= scussed & corrected. See the mail I sent earlier on the same topic when= the document was still an individual I-D:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/mail-<= /u>archive/web/sfc/current/msg01253.html

    - Jouni


    5/6/2014 5:21 PM, internet-drafts@ietf.org kirjoitti:

    A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
    =C2=A0 This draft is a work item of the Service Function Chaining Working G= roup of the IETF.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = : Service Function Chaining Use Cases in Mobile Networks
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Wal= ter Haeffner
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Jeffrey Napper
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Martin Stiemerling
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Diego R. Lopez
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Jim Uttaro
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet= f-sfc-use-case-mobility-00.txt
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 23 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2014-05-06

    _______________________________________________
    sfc mailing list
    sfc@ietf.org
    htt= ps://www.ietf.org/mailman/listinfo/sfc

    --089e01228d1a8d779304f8d2033d-- From nobody Wed May 7 23:05:40 2014 Return-Path: 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 120971A04A8 for ; Wed, 7 May 2014 23:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Bq3Gy1n6tE9n for ; Wed, 7 May 2014 23:05:34 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id 7D93D1A04A2 for ; Wed, 7 May 2014 23:05:34 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id p9so2808230lbv.39 for ; Wed, 07 May 2014 23:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=dcEFDAPrfnbq5L5tM7sTjXUGJgDlBo3UvXR5iFdoy7g=; b=T24uRLDcXIebvECw3zZE1GWjJCfX5QICDiKqor7xSrEqR95aHerYX2b3qqDsWuxmo+ nFqle42pvrWIWTfhnKYVNvborL8VUvopbLNpP18dRYLZx1/CGX43HCvzondySFa+sudF fotYm5OeMmJTGqFW2dFGXnWHlKa/7ap9ABaXT4ww8jPspyz23MBKIiAv8DXeIyxKNkV5 JaKbpnZREtguyQ5zfOyPLPGiBgbzphucg4gdGI696oRd7uuAIJrgTHxmSy4AkAGpF8+s FtZHlhonZH4fj2FoBTfAjvydVcVMgHwEx1p0plPJDiWI1HxpinwfnIDDd/FaGDfg2Nr5 1lhw== X-Received: by 10.112.141.130 with SMTP id ro2mr1215652lbb.42.1399529129404; Wed, 07 May 2014 23:05:29 -0700 (PDT) Received: from [10.17.0.95] ([83.150.126.201]) by mx.google.com with ESMTPSA id k2sm19457928lbm.23.2014.05.07.23.05.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 May 2014 23:05:28 -0700 (PDT) Message-ID: <536B1EA7.9000906@gmail.com> Date: Thu, 08 May 2014 09:05:27 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Haeffner, Walter, Vodafone DE" , "sfc@ietf.org" References: <20140506142142.962.94402.idtracker@ietfa.amsl.com> <5369D194.8050801@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/T6zdIAsnmp98qxcC5KUh_rJXFaw Cc: "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" Subject: Re: [sfc] Few comments on draft-ietf-sfc-use-case-mobility-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 06:05:37 -0000 Walter, Looks better now. I would propose the following wording, which only changes the place of GTP spec reference from what you proposed below: The radio-based IP traffic between the UE and the eNB is encrypted according 3GPP standards. Between eNB, S-GW, P-GW user plane IP packets are encapsulated in 3GPP-specific tunnels [TS.29.281], [TS.29.274]. In some mobile carrier networks the 3GPP specific tunnels between eNB and S-GW are even additionally IPSec-encrypted. More precisely, IPSec originates/terminates at the eNB and on the other side at an IPSec-GW often placed just in front of the S-GW. For more details see and [TS33.210]. - Jouni 5/7/2014 1:59 PM, Haeffner, Walter, Vodafone DE kirjoitti: > Referring to your February 21st email link below: > > Hi Jouni, > > Sorry, I missed that part. Only added TDF function. To keep it simple I suggest: > > 1.) to delete .... "as well as control plane" and just refer to user plane, leaving away any control stuff and write > > The radio-based IP traffic between the UE and the eNB is encrypted according 3GPP standards. Between eNB, S-GW, P-GW user plane IP packets are encapsulated in 3GPP-specific tunnels. > > 2.) Accept. For the moment I propose to add a sentence for clarification: > > In some mobile carrier networks the 3GPP specific tunnels between eNB and S-GW are even additionally IPSec-encrypted. More precisely, IPSec originates/terminates at the eNB and on the other side at an IPSec-GW often placed just in front of the S-GW. For more details see [TS.29.281], [TS.29.274] and [TS33.210]. > > Any suggestions for a better wording? > > Kind regards, > Walter > > -----Ursprüngliche Nachricht----- > Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Jouni Korhonen > Gesendet: Mittwoch, 7. Mai 2014 08:24 > An: sfc@ietf.org > Betreff: [sfc] Few comments on draft-ietf-sfc-use-case-mobility-00 > > > Hi, > > This is a small set of nits for Section 2.1 but I'd like to see them discussed & corrected. See the mail I sent earlier on the same topic when the document was still an individual I-D: > http://www.ietf.org/mail-archive/web/sfc/current/msg01253.html > > - Jouni > > > 5/6/2014 5:21 PM, internet-drafts@ietf.org kirjoitti: >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Service Function Chaining Working Group of the IETF. >> >> Title : Service Function Chaining Use Cases in Mobile Networks >> Authors : Walter Haeffner >> Jeffrey Napper >> Martin Stiemerling >> Diego R. Lopez >> Jim Uttaro >> Filename : draft-ietf-sfc-use-case-mobility-00.txt >> Pages : 23 >> Date : 2014-05-06 > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Fri May 9 01:02:57 2014 Return-Path: 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 373161A0208 for ; Fri, 9 May 2014 01:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 S-lsHFOYyIHU for ; Fri, 9 May 2014 01:02:53 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 756271A0206 for ; Fri, 9 May 2014 01:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7433; q=dns/txt; s=iport; t=1399622569; x=1400832169; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5jpaGu1wqbob2SMTPeStcahdlCtVxHiVbCUb7tFHgpc=; b=LpCD13OI5GLxJzt0Xjg2cgKgf+2u41F4Ly1wQkF3cbCOYd7AMTR8bAbI Hs3XEGivWMz10/9QCtVwo7zzn03/+wv/oj5d7xBs96GZ9Q5Mc3Ql86ljt WlgZuFp12gKPyQG0mc9MSzuWN8wp6OtgDM/U2bWaSYAPpb5uC2aUDW1+G Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAEuLbFOtJA2M/2dsb2JhbABZgkJET1i9fAGHOwGBFBZ0giUBAQEEAQEBawsQAgEIEQMBAigHIQYLFAkIAgQBDQUJiCQDEQ3KOw2GMxeMO4FGAQE+DQQHBoQ6BJdQgXKNG4VhgUKBdG2BCTk X-IronPort-AV: E=Sophos;i="4.97,1016,1389744000"; d="scan'208,217";a="320552674" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP; 09 May 2014 08:02:37 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s4982aZu027278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 May 2014 08:02:36 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.127]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Fri, 9 May 2014 03:02:35 -0500 From: "Jeffrey Napper (jenapper)" To: "sarikaya@ieee.org" , Jouni Korhonen Thread-Topic: [sfc] Few comments on draft-ietf-sfc-use-case-mobility-00 Thread-Index: AQHPab0FxSFWgwp8u0+v3SmJ4gjlbJs1pkiAgAK1n4A= Date: Fri, 9 May 2014 08:02:34 +0000 Message-ID: References: <20140506142142.962.94402.idtracker@ietfa.amsl.com> <5369D194.8050801@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.194.244] Content-Type: multipart/alternative; boundary="_000_CF92507A16626jenapperciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ywYkKEY5JOp4fm116YekFhWc5sc Cc: "sfc@ietf.org" Subject: Re: [sfc] Few comments on draft-ietf-sfc-use-case-mobility-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 08:02:55 -0000 --_000_CF92507A16626jenapperciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Behcet, Sorry for not replying. I don't believe the spec specifically states that t= he NAT should be before the Gi-LAN, rather that it should be after P-GW. It= would be difficult to correlate the IP-CAN session that identifies the sub= scriber session with the address after NAT as the TDF is supposed to. Cheers, Jeff From: Behcet Sarikaya > Reply-To: "sarikaya@ieee.org" > Date: Wednesday, May 7, 2014 at 6:39 PM To: Jouni Korhonen > Cc: "sfc@ietf.org" > Subject: Re: [sfc] Few comments on draft-ietf-sfc-use-case-mobility-00 Also I had a comment at this message: http://www.ietf.org/mail-archive/web/sfc/current/msg01906.html Behcet On Wed, May 7, 2014 at 1:24 AM, Jouni Korhonen > wrote: Hi, This is a small set of nits for Section 2.1 but I'd like to see them discus= sed & corrected. See the mail I sent earlier on the same topic when the doc= ument was still an individual I-D: http://www.ietf.org/mail-archive/web/sfc/current/msg01253.html - Jouni 5/6/2014 5:21 PM, internet-drafts@ietf.org= kirjoitti: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Service Function Chaining Working Group = of the IETF. Title : Service Function Chaining Use Cases in Mobile Ne= tworks Authors : Walter Haeffner Jeffrey Napper Martin Stiemerling Diego R. Lopez Jim Uttaro Filename : draft-ietf-sfc-use-case-mobility-00.txt Pages : 23 Date : 2014-05-06 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_CF92507A16626jenapperciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <61748F2EAC5AAA45A82ED779EFBC610B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
    Hello Behcet,

    Sorry for not replying. I don't believe the spec specifically states t= hat the NAT should be before the Gi-LAN, rather that it should be after P-G= W. It would be difficult to correlate the IP-CAN session that identifies th= e subscriber session with the address after NAT as the TDF is supposed to.

    Cheers,
    Jeff

    From: Behcet Sarikaya <sarikaya2012@gmail.com>
    Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org>
    Date: Wednesday, May 7, 2014 at 6:3= 9 PM
    To: Jouni Korhonen <jouni.nospam@gmail.com>
    Cc: "sfc@ietf.org" <sfc@ietf.= org>
    Subject: Re: [sfc] Few comments on = draft-ietf-sfc-use-case-mobility-00

    Behcet


    On Wed, May 7, 2014 at 1:24 AM, Jouni Korhonen <= span dir=3D"ltr"> <jouni.nospa= m@gmail.com> wrote:

    Hi,

    This is a small set of nits for Section 2.1 but I'd like to see them discus= sed & corrected. See the mail I sent earlier on the same topic when the= document was still an individual I-D:
            http://www.ietf.org/mail-archive/web/sfc/current/msg01253.htm= l

    - Jouni


    5/6/2014 5:21 PM, internet-drafts@ietf.org kirjoitti:

    A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
      This draft is a work item of the Service Function Chaining Working G= roup of the IETF.

             Title           = : Service Function Chaining Use Cases in Mobile Networks
             Authors         : Wal= ter Haeffner
                         = ;      Jeffrey Napper
                         = ;      Martin Stiemerling
                         = ;      Diego R. Lopez
                         = ;      Jim Uttaro
            Filename        : draft-iet= f-sfc-use-case-mobility-00.txt
            Pages           : 23         Date            := 2014-05-06

    _______________________________________________
    sfc mailing list
    sfc@ietf.org
    htt= ps://www.ietf.org/mailman/listinfo/sfc

     --_000_CF92507A16626jenapperciscocom_-- From nobody Fri May 9 01:32:41 2014 Return-Path: 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 9EBA31A0041 for ; Fri, 9 May 2014 01:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] 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 97CGvfHt35Gj for ; Fri, 9 May 2014 01:32:36 -0700 (PDT) Received: from mailout10.vodafone.com (mailout10.vodafone.com [195.232.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF9D1A0029 for ; Fri, 9 May 2014 01:32:35 -0700 (PDT) Received: from mailint10.vodafone.com (localhost [127.0.0.1]) by mailout10.vodafone.com (Postfix) with ESMTP id F03A4301FE8 for ; Fri, 9 May 2014 10:32:27 +0200 (CEST) Received: from VOEXC02W.internal.vodafone.com (voexc02w.dc-ratingen.de [145.230.101.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint10.vodafone.com (Postfix) with ESMTPS id DC0F1301C19; Fri, 9 May 2014 10:32:27 +0200 (CEST) Received: from VOEXC20W.internal.vodafone.com (145.230.103.125) by VOEXC02W.internal.vodafone.com (145.230.101.22) with Microsoft SMTP Server (TLS) id 14.3.146.2; Fri, 9 May 2014 10:32:26 +0200 Received: from VOEXM20W.internal.vodafone.com ([169.254.4.132]) by VOEXC20W.internal.vodafone.com ([145.230.103.125]) with mapi id 14.03.0146.002; Fri, 9 May 2014 10:32:25 +0200 From: "Haeffner, Walter, Vodafone DE" To: "Jeffrey Napper (jenapper)" , "sarikaya@ieee.org" , Jouni Korhonen Thread-Topic: [sfc] Few comments on draft-ietf-sfc-use-case-mobility-00 Thread-Index: AQHPab0Hct6L0tPUlUuePdJwfYeh45s1MPCAgAKUIACAACHeUA== Date: Fri, 9 May 2014 08:32:24 +0000 Message-ID: References: <20140506142142.962.94402.idtracker@ietfa.amsl.com> <5369D194.8050801@gmail.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_C8C844F84E550E43865561FAE10471853E9F8C54VOEXM20Winterna_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/J45uKkg1QtBhvYF3GgVh9i_sjwo Cc: "sfc@ietf.org" Subject: Re: [sfc] Few comments on draft-ietf-sfc-use-case-mobility-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 08:32:39 -0000 --_000_C8C844F84E550E43865561FAE10471853E9F8C54VOEXM20Winterna_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Behcet, Agree with Jeff. Typically NAT/FW is combined and is placed at the boarder = to the Internet (context). The original picture (1) shouldn't suggest any = sequential order of service functions but should only categorize them in th= ree functional types. In the recent version we reformulated the wording to = be more precise. In DSL networks CG-NAT or v4v6-NAT is often placed one hop behind (or even = within) the BNG because no further service function will follow. Regards, Walter Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Jeffrey Napper (jenap= per) Gesendet: Freitag, 9. Mai 2014 10:03 An: sarikaya@ieee.org; Jouni Korhonen Cc: sfc@ietf.org Betreff: Re: [sfc] Few comments on draft-ietf-sfc-use-case-mobility-00 Hello Behcet, Sorry for not replying. I don't believe the spec specifically states that t= he NAT should be before the Gi-LAN, rather that it should be after P-GW. It= would be difficult to correlate the IP-CAN session that identifies the sub= scriber session with the address after NAT as the TDF is supposed to. Cheers, Jeff From: Behcet Sarikaya > Reply-To: "sarikaya@ieee.org" > Date: Wednesday, May 7, 2014 at 6:39 PM To: Jouni Korhonen > Cc: "sfc@ietf.org" > Subject: Re: [sfc] Few comments on draft-ietf-sfc-use-case-mobility-00 Also I had a comment at this message: http://www.ietf.org/mail-archive/web/sfc/current/msg01906.html Behcet On Wed, May 7, 2014 at 1:24 AM, Jouni Korhonen > wrote: Hi, This is a small set of nits for Section 2.1 but I'd like to see them discus= sed & corrected. See the mail I sent earlier on the same topic when the doc= ument was still an individual I-D: http://www.ietf.org/mail-archive/web/sfc/current/msg01253.html - Jouni 5/6/2014 5:21 PM, internet-drafts@ietf.org= kirjoitti: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Service Function Chaining Working Group = of the IETF. Title : Service Function Chaining Use Cases in Mobile Ne= tworks Authors : Walter Haeffner Jeffrey Napper Martin Stiemerling Diego R. Lopez Jim Uttaro Filename : draft-ietf-sfc-use-case-mobility-00.txt Pages : 23 Date : 2014-05-06 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_C8C844F84E550E43865561FAE10471853E9F8C54VOEXM20Winterna_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Behcet,

     <= /p>

    Agree with Jeff. Typicall= y NAT/FW is combined and is placed at the boarder to the Internet (context)= .  The original picture (1) shouldn’t suggest any sequential order of service functions but should only categorize them in three functi= onal types. In the recent version we reformulated the wording to be more pr= ecise.

     <= /p>

    In DSL networks CG-NAT or= v4v6-NAT is often placed one hop behind (or even within) the BNG because n= o further service function will follow.

     <= /p>

    Regards, Walter

     

    Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Jeffrey Napper (jenapper)
    Gesendet: Freitag, 9. Mai 2014 10:03
    An: sarikaya@ieee.org; Jouni Korhonen
    Cc: sfc@ietf.org
    Betreff: Re: [sfc] Few comments on draft-ietf-sfc-use-case-mobility-= 00

     

    Hello Behcet,

     

    Sorry for not replying. I d= on't believe the spec specifically states that the NAT should be before the= Gi-LAN, rather that it should be after P-GW. It would be difficult to correlate the IP-CAN session that identifies the subscriber s= ession with the address after NAT as the TDF is supposed to.

     

    Cheers,

    Jeff

     

    From: Behcet Sarikaya <sarikaya2012@gmail.com>
    Reply-To: "sarikaya@ieee.o= rg" <sarikaya@ieee.org= >
    Date: Wednesday, May 7, 2014 at 6:39 PM
    To: Jouni Korhonen <jou= ni.nospam@gmail.com>
    Cc: "sfc@ietf.org" <= ;sfc@ietf.org>
    Subject: Re: [sfc] Few comments on draft-ietf-sfc-use-case-mobility-= 00

     

    Behcet

     

    On Wed, May 7, 2014 at 1:24= AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


    Hi,

    This is a small set of nits for Section 2.1 but I'd like to see them discus= sed & corrected. See the mail I sent earlier on the same topic when the= document was still an individual I-D:
            http://www.ietf.org/mail-archive/web/sfc/current/msg01253.html

    - Jouni


    5/6/2014 5:21 PM, internet-drafts@ietf.org kirjoitti:


    A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
      This draft is a work item of the Service Function Chaining Working G= roup of the IETF.

             Title           = : Service Function Chaining Use Cases in Mobile Networks
             Authors         : Wal= ter Haeffner
                         = ;      Jeffrey Napper
                         = ;      Martin Stiemerling
                         = ;      Diego R. Lopez
                         = ;      Jim Uttaro
            Filename        : draft-iet= f-sfc-use-case-mobility-00.txt
            Pages           : 23         Date            := 2014-05-06


    _______________________________________________
    sfc mailing list
    sfc@ietf.org
    htt= ps://www.ietf.org/mailman/listinfo/sfc

     

    --_000_C8C844F84E550E43865561FAE10471853E9F8C54VOEXM20Winterna_-- From nobody Fri May 9 02:49:47 2014 Return-Path: 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 3FB3C1A0241 for ; Fri, 9 May 2014 02:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.356 X-Spam-Level: * X-Spam-Status: No, score=1.356 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 wm-zFvhDqZBw for ; Fri, 9 May 2014 02:49:44 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id 324951A023F for ; Fri, 9 May 2014 02:49:44 -0700 (PDT) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id s499ncxk003956 for ; Fri, 9 May 2014 18:49:38 +0900 Received: from mfs6.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 92A64E01C5 for ; Fri, 9 May 2014 18:49:38 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 7553EE01C4 for ; Fri, 9 May 2014 18:49:38 +0900 (JST) Received: from [IPv6:::1] ([129.60.13.28]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id s499nWME012070 for ; Fri, 9 May 2014 18:49:38 +0900 Message-ID: <536CA4F0.5050403@lab.ntt.co.jp> Date: Fri, 09 May 2014 18:50:40 +0900 From: Shunsuke Homma User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 References: <5351B460.5040709@joelhalpern.com> <5602569641FB314FB4D9AD5659D41B9C2C1B0AA05D@WSMSG3154V.srv.dir.telstra.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit To: sfc@ietf.org X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/fawnGyq2RaoWZoTiV6wiGa17W7w Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 09:49:46 -0000 I support this draft. IMO, for the most part of service functions which are contained in SFC chain would be installed in DCs, so this draft can cover the general use case for SFC. Regards, Shunsuke (2014/05/07 16:22), Ng, Tomy wrote: > Hi All, > > Agree with Chuong’s viewpoint and I disapprove the adoption of this draft. > > Cheers > > Tomy > > ............................................... > > On Wed, Apr 30, 2014 at 7:35 AM, Pham, Chuong D > > > wrote: > > Separate drafts for pockets of environments will most likely overlook > the opportunities for identifying commonalities, synergies and reuse > factors between similar use cases for different environments. This is > the painful situation today where silos exist while at this point in > time where Mobile, Fixed Broadband and Data Centre are seeing strong > forces towards convergence with SDN, NFV and Cloud technologies. > > An overall draft such as draft-liu or similar must exist as a common > reference point for more detailed level drafts addressing use cases for > specific/pockets of environments while allowing for future > migration/convergence. > > Unless draft-kumar co-exists with high level draft-liu, I see more harm > in divergence rather than benefits therefore I disapprove. > > Regards, > Chuong > > > > -----Original Message----- > From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com > ] > Sent: Wednesday, 30 April 2014 2:56 AM > To: Joel M. Halpern; Jim Guichard (jguichar); sfc@ietf.org > > Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com > ) > Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 > > I also support this draft. Being on DC level this draft will complement > the other use case drafts. Beside typical FW or DPI etc. there should be > not that much overlap with the more carrier services oriented use case > drafts. > > Cheers, Walter > > > -----Ursprüngliche Nachricht----- > Von: sfc [mailto:sfc-bounces@ietf.org ] Im > Auftrag von Joel M. Halpern > Gesendet: Samstag, 19. April 2014 01:25 > An: Jim Guichard (jguichar); sfc@ietf.org > Betreff: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 > > I support adoption of this document by the working group. It is a good > starting point for addressing the material it covers, and the working > group should cover that material. > > Yours, > Joel > > On 4/18/14, 6:31 PM, Jim Guichard (jguichar) wrote: > > Dear WG: > > > > This message begins a two week call for WG adoption of the document > > http://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd > > May 2014. > > > > Please respond to the SFC mailing list with any statements of approval > > or disapproval. > > > > Please note: > > > > 1. This is not WG Last Call. The document is not final, and the WG is > > expected to modify the document's content until there is WG > > consensus that the content is solid. Therefore, please don't oppose > > adoption just because you want to see changes to its content. > > 2. If you have objections to adoption of the document, please state > > your reasons why, and explain what it would take to address your > > concerns. > > 3. If you have issues with the content, by all means raise those issues > > and we can begin a dialog about how best to address them. > > > > > > > > _______________________________________________ > > 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 mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > > -- > ============================================== > Qiong Sun > China Telecom Beijing Research Institute > > =============================================== > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > -- ---------------------------------- Shunsuke Homma TEL: +81 422 59 3486 FAX: +81 422 60 7460 NTT Network Service System Labs. Musashino city, Tokyo, Japan ---------------------------------- From nobody Fri May 9 08:37:44 2014 Return-Path: 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 5BBE51A002F for ; Fri, 9 May 2014 08:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 nD5JiM1O_Ims for ; Fri, 9 May 2014 08:37:41 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id AD1871A0008 for ; Fri, 9 May 2014 08:37:40 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id mc6so580814lab.30 for ; Fri, 09 May 2014 08:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wZsD6jx0Q9dHqlsjUSn0hCWNZKogdsS2P27HUrvcF/c=; b=XE//9AjOJzfMAfjl7YSNzUbf5OJzYRVThvK2ZZtVECVHvoUFwOqAX1yoK7LJ12s69r 0W1w/YwsqvD8POSZdXQcm/nqtTqeKE4NZKaEXuqaAcnT2qGGnvU4xxzzWobCNZT1zKN7 sThFNobAYts+JGybkhO4OaUAVoIggWHo6lb/yyZIiSDBcTJpwwdpGD7c9SvSB9klBvRR i+HiQP4YlYaQRk1/dTzvtNMD51+vojU6r7sK/2MvQAlC68fGhLvTDOl4E4rhqfQEA02H +kYgZuvtJ1kV4NxuOefVQI7SyuggcGOgsgsibKyD2BVJmkn7qlNFHIVwjcT+o9HuwE91 9t1Q== MIME-Version: 1.0 X-Received: by 10.152.4.201 with SMTP id m9mr1903358lam.50.1399649854889; Fri, 09 May 2014 08:37:34 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Fri, 9 May 2014 08:37:34 -0700 (PDT) In-Reply-To: References: <20140506142142.962.94402.idtracker@ietfa.amsl.com> <5369D194.8050801@gmail.com> Date: Fri, 9 May 2014 10:37:34 -0500 Message-ID: From: Behcet Sarikaya To: "Jeffrey Napper (jenapper)" Content-Type: multipart/alternative; boundary=089e013d1c4c6920d804f8f9607b Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/TvL6zk4D9YF3sMO23dTF9MMG-CE Cc: Jouni Korhonen , "sfc@ietf.org" Subject: Re: [sfc] Few comments on draft-ietf-sfc-use-case-mobility-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 15:37:42 -0000 --089e013d1c4c6920d804f8f9607b Content-Type: text/plain; charset=UTF-8 Hello Jeff, On Fri, May 9, 2014 at 3:02 AM, Jeffrey Napper (jenapper) < jenapper@cisco.com> wrote: > Hello Behcet, > > Sorry for not replying. I don't believe the spec specifically states > that the NAT should be before the Gi-LAN, rather that it should be after > P-GW. > Yes, so both are possible. > It would be difficult to correlate the IP-CAN session that identifies the > subscriber session with the address after NAT as the TDF is supposed to. > > Yes, so NAT should be the last service function to execute but that is a solution, there are other solutions. I discussed these in a recent draft: http://tools.ietf.org/id/draft-sarikaya-sfc-address-sharing-in-sfc-00.txt Regards, Behcet > Cheers, > Jeff > > From: Behcet Sarikaya > Reply-To: "sarikaya@ieee.org" > Date: Wednesday, May 7, 2014 at 6:39 PM > To: Jouni Korhonen > Cc: "sfc@ietf.org" > Subject: Re: [sfc] Few comments on draft-ietf-sfc-use-case-mobility-00 > > Also I had a comment at this message: > > http://www.ietf.org/mail-archive/web/sfc/current/msg01906.html > > Behcet > > > On Wed, May 7, 2014 at 1:24 AM, Jouni Korhonen wrote: > >> >> Hi, >> >> This is a small set of nits for Section 2.1 but I'd like to see them >> discussed & corrected. See the mail I sent earlier on the same topic when >> the document was still an individual I-D: >> http://www.ietf.org/mail-archive/web/sfc/current/msg01253.html >> >> - Jouni >> >> >> 5/6/2014 5:21 PM, internet-drafts@ietf.org kirjoitti: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Service Function Chaining Working >>> Group of the IETF. >>> >>> Title : Service Function Chaining Use Cases in Mobile >>> Networks >>> Authors : Walter Haeffner >>> Jeffrey Napper >>> Martin Stiemerling >>> Diego R. Lopez >>> Jim Uttaro >>> Filename : draft-ietf-sfc-use-case-mobility-00.txt >>> Pages : 23 >>> Date : 2014-05-06 >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > > --089e013d1c4c6920d804f8f9607b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hello Jeff,


    On Fri, May 9, 2014 at 3:02 AM, Jeffrey Napper (jenapper= ) <jenapper@cisco.com> wrote:
    Hello Behcet,

    Sorry for not replying. I don't believe the spec specifically stat= es that the NAT should be before the Gi-LAN, rather that it should be after= P-GW.

    Yes, so both are possib= le.
    =C2=A0
    It would be difficult to correlate the IP-CAN session that identifies = the subscriber session with the address after NAT as the TDF is supposed to.


    Yes, so NAT should be= the last service function to execute but that is a solution, there are oth= er solutions.

    Regards,

    Behcet
    <= div>
    Cheers,
    Jeff

    From: Behcet Sarikaya <sarikaya2012@gmail.com= >
    Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org> Date: Wednesday, May 7, 2014 at 6:3= 9 PM
    To: Jouni Korhonen <jouni.nospam@gmail.com&= gt;
    Cc: "sfc@ietf.org" <sfc@ietf.org>
    Subject: Re: [sfc] Few comments on = draft-ietf-sfc-use-case-mobility-00

    Behcet


    On Wed, May 7, 2014 at 1:24 AM, Jouni Korhonen <= span dir=3D"ltr"> <jouni.nospa= m@gmail.com> wrote:

    Hi,

    This is a small set of nits for Section 2.1 but I'd like to see them di= scussed & corrected. See the mail I sent earlier on the same topic when= the document was still an individual I-D:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/mail-archive/web/sfc/current/msg01253.htm= l

    - Jouni


    5/6/2014 5:21 PM, internet-drafts@ietf.org kirjoitti:

    A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
    =C2=A0 This draft is a work item of the Service Function Chaining Working G= roup of the IETF.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = : Service Function Chaining Use Cases in Mobile Networks
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Wal= ter Haeffner
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Jeffrey Napper
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Martin Stiemerling
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Diego R. Lopez
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Jim Uttaro
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet= f-sfc-use-case-mobility-00.txt
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 23 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2014-05-06

    _______________________________________________
    sfc mailing list
    sfc@ietf.org
    htt= ps://www.ietf.org/mailman/listinfo/sfc

    --089e013d1c4c6920d804f8f9607b-- From nobody Fri May 9 13:30:19 2014 Return-Path: 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 BA4231A00B5 for ; Fri, 9 May 2014 13:30:17 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 j6SusEfph_gA for ; Fri, 9 May 2014 13:30:15 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id A70901A00F4 for ; Fri, 9 May 2014 13:30:14 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-5d-536cebb10aee Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 85.07.07420.1BBEC635; Fri, 9 May 2014 16:52:33 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Fri, 9 May 2014 16:30:08 -0400 From: Dave Hood To: "sfc@ietf.org" Thread-Topic: EW/NS traffic: comments on draft-ietf-sfc-dc-use-cases-00 Thread-Index: Ac9rw29KTW62nWZuQxWGwjboCf6BVQ== Date: Fri, 9 May 2014 20:30:07 +0000 Message-ID: <8D15A2BAF93E9C49AB037A0647E5FA643F3E6BFF@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_8D15A2BAF93E9C49AB037A0647E5FA643F3E6BFFeusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyuXSPn+7G1znBBo19khZPHmxld2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvfHJ1gLWgMq/m17wtbAONuti5GDQ0LAROL2FqEuRk4gU0zi wr31bCC2kMBRRolJL/W6GLmA7GWMEivm/AZLsAloSDy5NJkJxBYRUJQ493ICC4gtLOAksfnz OnaIuLvE7p//WUHmiwjoSey5wgRisgioSHSfkQOp4BXwlXi9YQ0ziM0ItPb7qTVgE5kFxCVu PZnPBHGOgMSSPeeZIWxRiZeP/7FC2EoSc15fY4aoz5dYcGwzG8RMQYmTM5+wTGAUmoVk1Cwk ZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZVjBylxalluelGBpsYgSF/TIJNdwfj npeWhxgFOBiVeHgVlucEC7EmlhVX5h5ilOZgURLnLfgSGywkkJ5YkpqdmlqQWhRfVJqTWnyI kYmDU6qBse6r099ivikLTzemik59Yd23zDt90+OlPE2vRDxjf+u6dbifF6qwjGS3XNg58fNB lXXJRpl796eKSF7xceP4ucp9XfDknM/6r+0uzC5jtS64Yq3RczqsbmNh8KqeI9Pfr5u/72rM 1KwHK5TdLnaWOQUdTrBiPnXeyv/17K9vGRb3HvT59CzCUImlOCPRUIu5qDgRAOBhSWlaAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/f-mHMu1KfsbfDTyjyP5njMinDfQ Subject: [sfc] EW/NS traffic: comments on draft-ietf-sfc-dc-use-cases-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 20:30:17 -0000 --_000_8D15A2BAF93E9C49AB037A0647E5FA643F3E6BFFeusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry to join the conversation late; despite good intentions wrt its predec= essors, I only just read this draft. I am accustomed to think of E-W and N-S dimensions as applicable to control= or signaling traffic, but not in the data plane. The ideas are used pretty= widely in this draft, so I was interested to understand what they really m= eant. NS traffic is initially introduced with the idea that it terminates somewhe= re outside the DC. Already, this raises my eyebrows: 1. It forces our view of DCs to be physical rather than virtual. Also tr= ue of endpoints. 2. It feels as if it violates layering. At the layer implied by item 1, = an endpoint will usually be external from the DC, but once the external VPN= is properly connected, I would expect that the endpoint would now be insid= e trust domain. Then further on, we talk about EW traffic, and the distinction appears to b= e that NS crosses trust domain boundaries, while EW traffic remains within = a single trust domain. 3. By that interpretation, our given user flow is going to change direct= ion after it gets through the access firewall. 4. But we also show several FWs in the service chain, which recognizes t= hat trust domains may be nested. What direction do we assume for flows thro= ugh intermediate trust domains? I see nothing in the text that relies heavily on a distinction. But if the = distinction between EW and NS is really important to the model, could we ha= ve a crisp definition, please? And if not, could we consider eliminating th= e concept? Thanks, Dave --_000_8D15A2BAF93E9C49AB037A0647E5FA643F3E6BFFeusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Sorry to join the conversation lat= e; despite good intentions wrt its predecessors, I only just read this draf= t.

     

    I am accustomed to think of E-W an= d N-S dimensions as applicable to control or signaling traffic, but not in = the data plane. The ideas are used pretty widely in this draft, so I was interested to understand what they really meant.

     

    NS traffic is initially introduced= with the idea that it terminates somewhere outside the DC. Already, this r= aises my eyebrows:

    1.  &n= bsp; It forces our view of DCs = to be physical rather than virtual. Also true of endpoints.

    2.  &n= bsp; It feels as if it violates= layering. At the layer implied by item 1, an endpoint will usually be exte= rnal from the DC, but once the external VPN is properly connected, I would expect that the endpoint would now be inside <some&g= t; trust domain.

    Then further on, we talk about EW = traffic, and the distinction appears to be that NS crosses trust domain bou= ndaries, while EW traffic remains within a single trust domain.

    3.  &n= bsp; By that interpretation, ou= r given user flow is going to change direction after it gets through the ac= cess firewall.

    4.  &n= bsp; But we also show several F= Ws in the service chain, which recognizes that trust domains may be nested.= What direction do we assume for flows through intermediate trust domains?

    I see nothing in the text that rel= ies heavily on a distinction. But if the distinction between EW and NS is r= eally important to the model, could we have a crisp definition, please? And if not, could we consider eliminating the concept?<= /span>

     

    Thanks,

    Dave

    --_000_8D15A2BAF93E9C49AB037A0647E5FA643F3E6BFFeusaamb105erics_-- From nobody Sat May 10 14:28:51 2014 Return-Path: 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 046E01A00DE for ; Sat, 10 May 2014 14:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 q9900qqH2Gs8 for ; Sat, 10 May 2014 14:28:48 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 74B731A00D7 for ; Sat, 10 May 2014 14:28:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4672; q=dns/txt; s=iport; t=1399757323; x=1400966923; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=Yj+MGJpiAcHwNKVD11np7O5t3ZvbR2jwfVTIDTotyKs=; b=dhDR4DdNmJJsSo48CK29/omiI6uzuvKiCsaX3f8TehO3Dve1PAAgBAmo lRzGVTfFwvdPb7Fg4Zh5MW33rb1kC4Ge+8U08X+LHAqssnxpALzsOXv7R h2KXJ6YQr7WYCvhFvM1yVDAMbiOXCBZCjixrOkhdnKNEHlU9PuyoPcpP1 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0VAACZblOtJV2b/2dsb2JhbABPCoJCRE9YhAW4VIh+AYEXFnSCJQECBA5GESYBCAQNAwECKDkUCQgBAQQBEohBDc9sF412SxiEQASZSIE8kUuDNoIv X-IronPort-AV: E=Sophos;i="4.97,1025,1389744000"; d="scan'208,217";a="42756775" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP; 10 May 2014 21:28:42 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s4ALSg84011708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 10 May 2014 21:28:42 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.21]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Sat, 10 May 2014 16:28:42 -0500 From: "Reinaldo Penno (repenno)" To: Nicolas BOUTHORS , "sfc@ietf.org" Thread-Topic: [sfc] Question on draft-penno-sfc-yang-00 Thread-Index: Ac8igcbGKXLfHO8XQpiN9ZcY6YgpGxKBEZsA Date: Sat, 10 May 2014 21:28:41 +0000 Message-ID: In-Reply-To: <76B41B8FACE1514795D30EC137FF391D3DFA66@LILAS.jungle.qosmos.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.118.143] Content-Type: multipart/alternative; boundary="_000_CF93E802B8C3repennociscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/0omjm-vWNesy9g4oXf0hpB_dWms Subject: Re: [sfc] Question on draft-penno-sfc-yang-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 21:28:50 -0000 --_000_CF93E802B8C3repennociscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We updated the draft based on comments and implementation experience. http://tools.ietf.org/html/draft-penno-sfc-yang-01 Thanks, Reinaldo From: Nicolas BOUTHORS > Date: Wednesday, February 5, 2014 at 8:18 AM To: "sfc@ietf.org" > Subject: [sfc] Question on draft-penno-sfc-yang-00 The model uses an IP address as a way to identify a Service Function. I ass= ume that this address is for management and control point of view. Otherwise it raises a couple of questions - A service function could be reachable via different IP addresses as the t= raffic comes from different directions. Would this be in line with the specification of the service-function-chain= container ? - Also a service function for example responsible to load balance traffic = to other virtual service functions could be best attached to a set of IP addresses on a private subnet. So th= ese addresses might not be usable for say a management application to locate the service function. So if those addresses are for management and control purposes, where should= the addresses used to route the traffic fit in the model? --_000_CF93E802B8C3repennociscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
    Hi,

    We updated the draft based on comments and implementation experience.<= /div>


    Thanks,

    Reinaldo

    From: Nicolas BOUTHORS <Nicolas.BOUTHORS@qosmos.com>=
    Date: Wednesday, February 5, 2014 a= t 8:18 AM
    To: "sfc@ietf.org" <sfc@ietf.= org>
    Subject: [sfc] Question on draft-pe= nno-sfc-yang-00

    The model uses an IP address as a way to identify a Service Function= . I assume that this address is for management and control point of view.

    Otherwise it raises a couple of questions

    - A service function could be reachable via different IP addresses as = the traffic comes from different directions. 
    Would this be  in line with the specification of the service-function-chain <= /span>container<= span style=3D"line-height: 16px; font-size: 10pt;"> ?

    - Also  a service function = for example responsible to load balance traffic to other virtual service fu= nctions 
    could be best attached to a set of IP addresses on a private subnet. &= nbsp;So these addresses might not be usable 
    for say a management application to locate the service function.

    So if those addresses are for management and control purposes, where s= hould the addresses used to route the traffic fit in the model? 
     --_000_CF93E802B8C3repennociscocom_-- From nobody Sun May 11 17:42:41 2014 Return-Path: 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 C46D11A03AA for ; Sun, 11 May 2014 17:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, 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 67QP4j-p6YTq for ; Sun, 11 May 2014 17:42:35 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9791A03B4 for ; Sun, 11 May 2014 17:42:26 -0700 (PDT) X-AuditID: c6180641-f799b6d000000b0f-be-536fc73fd29a Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 06.22.02831.F37CF635; Sun, 11 May 2014 20:53:51 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Sun, 11 May 2014 20:42:19 -0400 From: Dave Hood To: "sfc@ietf.org" Thread-Topic: Gen rqts comments on draft-ietf-sfc-dc-use-cases-00 Thread-Index: Ac9tM+kN5VF9RhhITqeEVOSvnOntWA== Date: Mon, 12 May 2014 00:42:18 +0000 Message-ID: <8D15A2BAF93E9C49AB037A0647E5FA643F3E7754@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_8D15A2BAF93E9C49AB037A0647E5FA643F3E7754eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyuXRPiK798fxgg7ZjWhZPHmxld2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvLf/9kL9q1grLhyaSFrA+ORyYxdjJwcEgImEhMm/2KGsMUk Ltxbz9bFyMUhJHCUUWL7ve/MEM5yRokJLd/ZQKrYBDQknlyazARiiwgoSpx7OYEFxBYWsJE4 ePAHC0TcUeJd+292CFtP4u68bjCbRUBVouf5GjCbV8BX4lPXWbArGIE2fz+1Bmwms4C4xK0n 85kgLhKQWLLnPNR1ohIvH/9jhbCVJOa8vsYMUZ8v0XhpARPETEGJkzOfsExgFJqFZNQsJGWz kJRBxHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYwcpcWpZbnpRoabGIHhf0yCzXEH44JP locYBTgYlXh4F+zKDxZiTSwrrsw9xCjNwaIkzpv+KTZYSCA9sSQ1OzW1ILUovqg0J7X4ECMT B6dUA+OijUalq2MtG39oCHwp/Khpft71VeaM4stWwcuFr28LOigqwRw5q81oAScb6yON3x27 PCz2tqqazBX1UDZ+7Hv3/w3jJepe1dOf+iT11/jofbze+u8kw8MF3FmNHVxnLJqaul68/lrp fbty49/TTgt9C9u/2egfPJdefWdz9/qnzJzH5jDrb1RiKc5INNRiLipOBAAm3K7sYAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/BNI1opDvc-ND34hld4EwWpmiSis Subject: [sfc] Gen rqts comments on draft-ietf-sfc-dc-use-cases-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 00:42:39 -0000 --_000_8D15A2BAF93E9C49AB037A0647E5FA643F3E7754eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A few observations on the proposed requirements: GR1. SFC polices MUST be applicable at the edges - network elements as we= ll as the workloads. A good requirement specifies that 1) someone must do 2) something and 3) th= ere should be a way to confirm whether 1 has done 2 or not. How would we te= st this requirement? GR2. SFC policies MUST be applicable to either Ingress or Egress traffic. Ingress and egress are not well-defined. From the viewpoint of an SFC, the = classifier is always an ingress point, and the conclusion of the service ch= ain is always an egress point. Bidirectional flows are important, but if this requirement is meant to intr= oduce that topic, it is wide of the mark. GR3. SFC MUST support virtual as well as physical SNs. This is written as if physical SNs were primary, with virtual an afterthoug= ht. While recognizing the differences, it is probably better to grant them = logical equivalence. Or if one is to be regarded as primary, surely it woul= d be the virtual SN? GR4. SFC SHOULD support the ability to mix virtual and physical SNs in th= e same SFC. Ok GR5. SFC SNs MUST be deployable L2 or L3 hop away from each other or from= the SFC starting entity. Not clear what is actually being asked for here. The first sentence in DB-3= actually states the requirement more crisply. GR6. SFC traffic MUST be allowed to follow paths not constrained by the u= nderlying static network topology. We are always tied to underlying topology, just as a zero-G space environme= nt is still subject to the laws of gravity. Even within a DC, and certainly= between DCs, there will always be better ways and worse ways of physically= arranging the virtual SNs (ie static network topology constraints). The problem statement draft describes this better. A reqirement might bette= r be written something along the lines that SFs [do we need SNs in the inte= nded abstraction?] should be nodes in a virtual full-mesh topology, maybe a= ccompanied with a requirement to be able to create new virtual topology nod= es (ie instantiate new virtual SNs) on demand (see comment on GR11 below). = Admittedly, this goes beyond the implications of the text describing fig 1,= but still seems appropriate. GR7. SFC SNs MUST be able to derive the tenant identification without bei= ng tied to the underlying topology SNs, rather than SFs? Derive, rather than being told? And the point about u= nderlying topology seems to preclude the continued use of physical boxes wi= th hard wiring that might already be in place. GR8. SFCs MUST support the ability to pass metadata among the SNs or betw= een the SNs and the network elements. It doesn't say so, but presumably the metadata is associated with a particu= lar [set of] flows. As written, this could be done with information conveye= d out of band, at the time of flow allocation or per-packet. Are all of the= se options intended to be left open for later resolution? GR9. A composite SFC SHOULD be achievable by way of joining sub SFCs, bra= nching to sub SFCs where necessary. Is branching the only option? Why not nesting? GR10. SFCs SHOULD NOT require SNAT inside the SFs to attract traffic back = to them This seems like a fine-grained requirement that addresses only one small as= pect of a larger issue, namely visibility of bidirectional flows. Are we co= ntent to chip away at the problem without considering it in its entirety? GR11. SFCs SHOULD have the ability to choose SN instances dynamically, at = the time of forwarding traffic to them. The last phrase is at best redundant but probably incorrect (appears to dem= and just-in-time; why not *prior to* forwarding traffic?). Also, although it is not justified by the use cases, one might hope for the= ability to instantiate or destroy instances of at least some kinds of SN/S= F on demand. GR12. An OAM mechanism to easily troublshoot as well as validate the paths= traversed by the SFCs SHOULD be supported. Given the expected intelligent controller, would we regard it as a sufficie= nt response for the controller to be able to report its choices? Or would w= e expect some form of traceroute in the data path itself? And speaking of intelligent controllers, BTW, the drawbacks clause 4 appear= s to be written with the intent to preclude the use of VLANs. As to scalabi= lity, VLANs might suffice for small to moderate enterprises. The argument i= s really based on the assumption of manual configuration. Given intelligenc= e in the SFC controller, VLANs are one of many ways in which one could cons= truct a valid solution. If we really intend to preclude VLANs, there needs = to be a better argument than is presented. Dave --_000_8D15A2BAF93E9C49AB037A0647E5FA643F3E7754eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    A few observations on the proposed= requirements:

     

    GR1.   = SFC polices MUST be applicable at the edges - network elements as well as t= he workloads.

     =

    A good = requirement specifies that 1) someone must do 2) something and 3) there sho= uld be a way to confirm whether 1 has done 2 or not. How would we test this requirement?

     =

    GR2.   = SFC policies MUST be applicable to either Ingress or Egress traffic.

     =

    Ingress= and egress are not well-defined. From the viewpoint of an SFC, the classif= ier is always an ingress point, and the conclusion of the service chain is always an egress point.

    &n= bsp;

    Bidirec= tional flows are important, but if this requirement is meant to introduce t= hat topic, it is wide of the mark.

     =

    GR3.   = SFC MUST support virtual as well as physical SNs.

     =

    This is= written as if physical SNs were primary, with virtual an afterthought. Whi= le recognizing the differences, it is probably better to grant them logical equivalence. Or if one is to be regarded as primary, surely i= t would be the virtual SN?

     =

    GR4.   = SFC SHOULD support the ability to mix virtual and physical SNs in the same = SFC.

    Ok

     =

    GR5.   = SFC SNs MUST be deployable L2 or L3 hop away from each other or from the SF= C starting entity.

     =

    Not cle= ar what is actually being asked for here. The first sentence in DB-3 actual= ly states the requirement more crisply.

     =

    GR6.   = SFC traffic MUST be allowed to follow paths not constrained by the underlyi= ng static network topology.

     =

    We are = always tied to underlying topology, just as a zero-G space environment is s= till subject to the laws of gravity. Even within a DC, and certainly between DCs, there will always be better ways and worse ways of = physically arranging the virtual SNs (ie static network topology constraint= s).

    &n= bsp;

    The pro= blem statement draft describes this better. A reqirement might better be wr= itten something along the lines that SFs [do we need SNs in the intended abstraction?] should be nodes in a virtual full-mesh topology= , maybe accompanied with a requirement to be able to create new virtual top= ology nodes (ie instantiate new virtual SNs) on demand (see comment on GR11= below). Admittedly, this goes beyond the implications of the text describing fig 1, but still seems appropriate= .

    &n= bsp;

    GR7.   = SFC SNs MUST be able to derive the tenant identification without being tied= to the underlying topology

     =

    SNs, ra= ther than SFs? Derive, rather than being told? And the point about underlyi= ng topology seems to preclude the continued use of physical boxes with hard wiring that might already be in place.

     =

    GR8.   = SFCs MUST support the ability to pass metadata among the SNs or between the= SNs and the network elements.

     =

    It does= n’t say so, but presumably the metadata is associated with a particul= ar [set of] flows. As written, this could be done with information conveyed out of band, at the time of flow allocation or per-packet. Are al= l of these options intended to be left open for later resolution?

     =

    GR9.   = A composite SFC SHOULD be achievable by way of joining sub SFCs, branching = to sub SFCs where necessary.

     =

    Is bran= ching the only option? Why not nesting?

     =

    GR10.  SFCs = SHOULD NOT require SNAT inside the SFs to attract traffic back to them=

    &n= bsp;

    This se= ems like a fine-grained requirement that addresses only one small aspect of= a larger issue, namely visibility of bidirectional flows. Are we content to chip away at the problem without considering it in its e= ntirety?

     =

    GR11.  SFCs = SHOULD have the ability to choose SN instances dynamically, at the time of = forwarding traffic to them.

     =

    The las= t phrase is at best redundant but probably incorrect (appears to demand jus= t-in-time; why not *prior to* forwarding traffic?).

    Also, a= lthough it is not justified by the use cases, one might hope for the abilit= y to instantiate or destroy instances of at least some kinds of SN/SF on demand.

     =

    GR12.  An OA= M mechanism to easily troublshoot as well as validate the paths traversed b= y the SFCs SHOULD be supported.

     =

    Given t= he expected intelligent controller, would we regard it as a sufficient resp= onse for the controller to be able to report its choices? Or would we expect some form of traceroute in the data path itself?

     

    And speaking of intelligent contro= llers, BTW, the drawbacks clause 4 appears to be written with the intent to= preclude the use of VLANs. As to scalability, VLANs might suffice for small to moderate enterprises. The argument is really based on= the assumption of manual configuration. Given intelligence in the SFC cont= roller, VLANs are one of many ways in which one could construct a valid sol= ution. If we really intend to preclude VLANs, there needs to be a better argument than is presented.

     

    Dave

    --_000_8D15A2BAF93E9C49AB037A0647E5FA643F3E7754eusaamb105erics_-- From nobody Sun May 11 18:07:07 2014 Return-Path: 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 A2D9E1A03AA for ; Sun, 11 May 2014 18:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 iMr4D3t2xtS2 for ; Sun, 11 May 2014 18:07:03 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 75D321A03AE for ; Sun, 11 May 2014 18:07:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 059C515A9; Sun, 11 May 2014 18:06:58 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-10.clppva.east.verizon.net [70.106.135.10]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 0C68215A8; Sun, 11 May 2014 18:06:56 -0700 (PDT) Message-ID: <53701EAF.4020100@joelhalpern.com> Date: Sun, 11 May 2014 21:06:55 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Dave Hood , "sfc@ietf.org" References: <8D15A2BAF93E9C49AB037A0647E5FA643F3E7754@eusaamb105.ericsson.se> In-Reply-To: <8D15A2BAF93E9C49AB037A0647E5FA643F3E7754@eusaamb105.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/L62PZqkl3UmxLOSMr2bGSnPwJBo Subject: Re: [sfc] Gen rqts comments on draft-ietf-sfc-dc-use-cases-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 01:07:05 -0000 It strikes me that the solution to many of the issue Dave raises would be to remove the requirements from this document (as I have suggested in other documents). Describe the use, but don't try to figure out to properly describe the requirements in the use case document. Yours, Joel On 5/11/14, 8:42 PM, Dave Hood wrote: > A few observations on the proposed requirements: > > GR1. SFC polices MUST be applicable at the edges - network elements as > well as the workloads. > > A good requirement specifies that 1) someone must do 2) something and 3) > there should be a way to confirm whether 1 has done 2 or not. How would > we test this requirement? > > GR2. SFC policies MUST be applicable to either Ingress or Egress traffic. > > Ingress and egress are not well-defined. From the viewpoint of an SFC, > the classifier is always an ingress point, and the conclusion of the > service chain is always an egress point. > > Bidirectional flows are important, but if this requirement is meant to > introduce that topic, it is wide of the mark. > > GR3. SFC MUST support virtual as well as physical SNs. > > This is written as if physical SNs were primary, with virtual an > afterthought. While recognizing the differences, it is probably better > to grant them logical equivalence. Or if one is to be regarded as > primary, surely it would be the virtual SN? > > GR4. SFC SHOULD support the ability to mix virtual and physical SNs in > the same SFC. > > Ok > > GR5. SFC SNs MUST be deployable L2 or L3 hop away from each other or > from the SFC starting entity. > > Not clear what is actually being asked for here. The first sentence in > DB-3 actually states the requirement more crisply. > > GR6. SFC traffic MUST be allowed to follow paths not constrained by > the underlying static network topology. > > We are always tied to underlying topology, just as a zero-G space > environment is still subject to the laws of gravity. Even within a DC, > and certainly between DCs, there will always be better ways and worse > ways of physically arranging the virtual SNs (ie static network topology > constraints). > > The problem statement draft describes this better. A reqirement might > better be written something along the lines that SFs [do we need SNs in > the intended abstraction?] should be nodes in a virtual full-mesh > topology, maybe accompanied with a requirement to be able to create new > virtual topology nodes (ie instantiate new virtual SNs) on demand (see > comment on GR11 below). Admittedly, this goes beyond the implications of > the text describing fig 1, but still seems appropriate. > > GR7. SFC SNs MUST be able to derive the tenant identification without > being tied to the underlying topology > > SNs, rather than SFs? Derive, rather than being told? And the point > about underlying topology seems to preclude the continued use of > physical boxes with hard wiring that might already be in place. > > GR8. SFCs MUST support the ability to pass metadata among the SNs or > between the SNs and the network elements. > > It doesn’t say so, but presumably the metadata is associated with a > particular [set of] flows. As written, this could be done with > information conveyed out of band, at the time of flow allocation or > per-packet. Are all of these options intended to be left open for later > resolution? > > GR9. A composite SFC SHOULD be achievable by way of joining sub SFCs, > branching to sub SFCs where necessary. > > Is branching the only option? Why not nesting? > > GR10. SFCs SHOULD NOT require SNAT inside the SFs to attract traffic > back to them > > This seems like a fine-grained requirement that addresses only one small > aspect of a larger issue, namely visibility of bidirectional flows. Are > we content to chip away at the problem without considering it in its > entirety? > > GR11. SFCs SHOULD have the ability to choose SN instances dynamically, > at the time of forwarding traffic to them. > > The last phrase is at best redundant but probably incorrect (appears to > demand just-in-time; why not **prior to** forwarding traffic?). > > Also, although it is not justified by the use cases, one might hope for > the ability to instantiate or destroy instances of at least some kinds > of SN/SF on demand. > > GR12. An OAM mechanism to easily troublshoot as well as validate the > paths traversed by the SFCs SHOULD be supported. > > Given the expected intelligent controller, would we regard it as a > sufficient response for the controller to be able to report its choices? > Or would we expect some form of traceroute in the data path itself? > > And speaking of intelligent controllers, BTW, the drawbacks clause 4 > appears to be written with the intent to preclude the use of VLANs. As > to scalability, VLANs might suffice for small to moderate enterprises. > The argument is really based on the assumption of manual configuration. > Given intelligence in the SFC controller, VLANs are one of many ways in > which one could construct a valid solution. If we really intend to > preclude VLANs, there needs to be a better argument than is presented. > > Dave > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon May 12 15:17:43 2014 Return-Path: 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 5B6B51A078D for ; Mon, 12 May 2014 15:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 jnrZWP7Bs4oa for ; Mon, 12 May 2014 15:17:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4309A1A0767 for ; Mon, 12 May 2014 15:17:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEB73653; Mon, 12 May 2014 22:17:15 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 12 May 2014 23:15:41 +0100 Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 12 May 2014 23:17:14 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml706-chm.china.huawei.com ([169.254.8.2]) with mapi id 14.03.0158.001; Mon, 12 May 2014 15:17:04 -0700 From: Linda Dunbar To: "Ng, Tomy" , Qiong , "Pham, Chuong D" Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 Thread-Index: AQHPW1X8U8UhsrhhTUWWEhfLxMVVkZsvyRbNgAV/2wCACF1ZUA== Date: Mon, 12 May 2014 22:17:04 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D088B4@dfweml701-chm.china.huawei.com> References: <5351B460.5040709@joelhalpern.com> <5602569641FB314FB4D9AD5659D41B9C2C1B0AA05D@WSMSG3154V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.182] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D088B4dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/a90V805lRfGE-BGXFP7ZhC-wiPw Cc: "Jim Guichard \(jguichar\)" , "Haeffner, Walter, Vodafone DE" , "Joel M. Halpern" , "sfc@ietf.org" , "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 22:17:32 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645D088B4dfweml701chmchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIGdpdmVuIGV4cGxpY2l0IGNvbW1lbnRzIHRvIHRoZSBkcmFmdCwgeWV0IG5vdCByZWNl aXZpbmcgYW55IHJlcGx5IGZyb20gdGhlIGF1dGhvcnMuDQpTcGVjaWZpY2FsbHk6DQoNCg0KLSAg ICAgICAgICBUaGUg4oCcQURD4oCdIGluIHRoZSBkcmFmdCBpcyBtb3JlIGxpa2UgY29udmVudGlv bmFsIExvYWQgQmFsYW5jZS4gU2luY2UgdGhpcyB1c2UgY2FzZSBpcyBhYm91dCBnZW5lcmFsIERh dGEgQ2VudGVyIHVzZSBjYXNlLCB3ZSBzaG91bGQgdXNlIHRoZSBjb252ZW50aW9uYWwgdGVybWlu b2xvZ3kuDQoNCg0KDQotICAgICAgICAgIEkgY2Fu4oCZdCBzZWUgaG93IHRoZSBleGFtcGxlcyBs aXN0ZWQgaW4gU2VjdGlvbiAzIGRyaXZlIHRoZSByZXF1aXJlbWVudCBsaXN0ZWQgaW4gU2VjdGlv biA1LiBUaGUgcmVxdWlyZW1lbnQgbGlzdGVkIGluIFNlY3Rpb24gNSBhcmUgc28gZ2VuZXJhbCwg dGhhdCB5b3UgZG9u4oCZdCBuZWVkIHRob3NlIGV4YW1wbGVzIGxpc3RlZCBpbiBTZWN0aW9uIDMu DQoNCg0KDQotICAgICAgICAgIFNpbmNlIHRoaXMgaXMgYSB1c2UgY2FzZSBkcmFmdCwgbm90IHJl cXVpcmVtZW50IGRyYWZ0LCB0aGlzIGRyYWZ0IHNob3VsZCBvbmx5IGxpc3QgZG93biB0aGUgcmVx dWlyZW1lbnQgZHJpdmVuIGJ5IHRoZSBleGFtcGxlcy4NCg0KSSBzZWUgdGhhdCB0aGUga2V5IHJl cXVpcmVtZW50IGRyaXZlbiBieSB0aGUgZXhhbXBsZXMgaW4gU2VjdGlvbiAzIGlzIHRvIGFsbG93 IHRob3NlIFNlcnZpY2UgRnVuY3Rpb25zIHRvIGJlIGxvY2F0ZWQgIGFueXdoZXJlIChpLmUuIG5v dCBuZWNlc3NhcmlseSBvbiB0aGUgZGF0YSBwYXRoKS4gVGhlcmVmb3JlLCB0aGUga2V5IHJlcXVp cmVtZW50IHNob3VsZCBiZSBuZWVkaW5nIGR5bmFtaWMgc3RlZXJpbmcgcG9saWNpZXMgdG8gU2Vy dmljZSBOb2Rlcywgcm91dGVycywgYW5kIHN3aXRjaGVzDQoNCkxpbmRhDQoNCg0KRnJvbTogc2Zj IFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBOZywgVG9teQ0KU2Vu dDogV2VkbmVzZGF5LCBNYXkgMDcsIDIwMTQgMjoyMyBBTQ0KVG86IFFpb25nOyBQaGFtLCBDaHVv bmcgRA0KQ2M6IEpvZWwgTS4gSGFscGVybjsgSmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IEhhZWZm bmVyLCBXYWx0ZXIsIFZvZGFmb25lIERFOyBzZmNAaWV0Zi5vcmc7IEplZmZyZXkgTmFwcGVyIChq ZW5hcHBlcikgKGplbmFwcGVyQGNpc2NvLmNvbSkNClN1YmplY3Q6IFJlOiBbc2ZjXSBDYWxsIGZv ciBhZG9wdGlvbiBvZiBkcmFmdC1rdW1hci1zZmMtZGMtdXNlLWNhc2VzLTAxDQoNCkhpIEFsbCwN Cg0KQWdyZWUgd2l0aCBDaHVvbmfigJlzIHZpZXdwb2ludCBhbmQgSSBkaXNhcHByb3ZlIHRoZSBh ZG9wdGlvbiBvZiB0aGlzIGRyYWZ0Lg0KDQpDaGVlcnMNCg0KVG9teQ0KLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4NCg0KT24gV2VkLCBBcHIgMzAsIDIwMTQg YXQgNzozNSBBTSwgUGhhbSwgQ2h1b25nIEQgPENodW9uZy5ELlBoYW1AdGVhbS50ZWxzdHJhLmNv bTxtYWlsdG86Q2h1b25nLkQuUGhhbUB0ZWFtLnRlbHN0cmEuY29tPj4gd3JvdGU6DQpTZXBhcmF0 ZSBkcmFmdHMgZm9yIHBvY2tldHMgb2YgZW52aXJvbm1lbnRzIHdpbGwgbW9zdCBsaWtlbHkgb3Zl cmxvb2sgdGhlIG9wcG9ydHVuaXRpZXMgZm9yIGlkZW50aWZ5aW5nIGNvbW1vbmFsaXRpZXMsIHN5 bmVyZ2llcyBhbmQgcmV1c2UgZmFjdG9ycyBiZXR3ZWVuIHNpbWlsYXIgdXNlIGNhc2VzIGZvciBk aWZmZXJlbnQgZW52aXJvbm1lbnRzLiBUaGlzIGlzIHRoZSBwYWluZnVsIHNpdHVhdGlvbiB0b2Rh eSB3aGVyZSBzaWxvcyBleGlzdCB3aGlsZSBhdCB0aGlzIHBvaW50IGluIHRpbWUgd2hlcmUgTW9i aWxlLCBGaXhlZCBCcm9hZGJhbmQgYW5kIERhdGEgQ2VudHJlIGFyZSBzZWVpbmcgc3Ryb25nIGZv cmNlcyB0b3dhcmRzIGNvbnZlcmdlbmNlIHdpdGggU0ROLCBORlYgYW5kIENsb3VkIHRlY2hub2xv Z2llcy4NCg0KQW4gb3ZlcmFsbCBkcmFmdCBzdWNoIGFzIGRyYWZ0LWxpdSBvciBzaW1pbGFyIG11 c3QgZXhpc3QgYXMgYSBjb21tb24gcmVmZXJlbmNlIHBvaW50IGZvciBtb3JlIGRldGFpbGVkIGxl dmVsIGRyYWZ0cyBhZGRyZXNzaW5nIHVzZSBjYXNlcyBmb3Igc3BlY2lmaWMvcG9ja2V0cyBvZiBl bnZpcm9ubWVudHMgd2hpbGUgYWxsb3dpbmcgZm9yIGZ1dHVyZSBtaWdyYXRpb24vY29udmVyZ2Vu Y2UuDQoNClVubGVzcyBkcmFmdC1rdW1hciBjby1leGlzdHMgd2l0aCBoaWdoIGxldmVsIGRyYWZ0 LWxpdSwgSSBzZWUgbW9yZSBoYXJtIGluIGRpdmVyZ2VuY2UgcmF0aGVyIHRoYW4gYmVuZWZpdHMg dGhlcmVmb3JlIEkgZGlzYXBwcm92ZS4NCg0KUmVnYXJkcywNCkNodW9uZw0KDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBIYWVmZm5lciwgV2FsdGVyLCBWb2RhZm9uZSBERSBb bWFpbHRvOndhbHRlci5oYWVmZm5lckB2b2RhZm9uZS5jb208bWFpbHRvOndhbHRlci5oYWVmZm5l ckB2b2RhZm9uZS5jb20+XQ0KU2VudDogV2VkbmVzZGF5LCAzMCBBcHJpbCAyMDE0IDI6NTYgQU0N ClRvOiBKb2VsIE0uIEhhbHBlcm47IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBzZmNAaWV0Zi5v cmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCkNjOiBKZWZmcmV5IE5hcHBlciAoamVuYXBwZXIpIChq ZW5hcHBlckBjaXNjby5jb208bWFpbHRvOmplbmFwcGVyQGNpc2NvLmNvbT4pDQpTdWJqZWN0OiBS ZTogW3NmY10gQ2FsbCBmb3IgYWRvcHRpb24gb2YgZHJhZnQta3VtYXItc2ZjLWRjLXVzZS1jYXNl cy0wMQ0KDQpJIGFsc28gc3VwcG9ydCB0aGlzIGRyYWZ0LiBCZWluZyBvbiBEQyBsZXZlbCB0aGlz IGRyYWZ0IHdpbGwgY29tcGxlbWVudCB0aGUgb3RoZXIgdXNlIGNhc2UgZHJhZnRzLiBCZXNpZGUg dHlwaWNhbCBGVyBvciBEUEkgZXRjLiB0aGVyZSBzaG91bGQgYmUgbm90IHRoYXQgbXVjaCBvdmVy bGFwIHdpdGggdGhlIG1vcmUgY2FycmllciBzZXJ2aWNlcyBvcmllbnRlZCB1c2UgY2FzZSBkcmFm dHMuDQoNCkNoZWVycywgV2FsdGVyDQoNCg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQt LS0tLQ0KVm9uOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmc+XSBJbSBBdWZ0cmFnIHZvbiBKb2VsIE0uIEhhbHBlcm4NCkdlc2VuZGV0 OiBTYW1zdGFnLCAxOS4gQXByaWwgMjAxNCAwMToyNQ0KQW46IEppbSBHdWljaGFyZCAoamd1aWNo YXIpOyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCkJldHJlZmY6IFJlOiBbc2Zj XSBDYWxsIGZvciBhZG9wdGlvbiBvZiBkcmFmdC1rdW1hci1zZmMtZGMtdXNlLWNhc2VzLTAxDQoN Ckkgc3VwcG9ydCBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IGJ5IHRoZSB3b3JraW5nIGdyb3Vw LiAgSXQgaXMgYSBnb29kIHN0YXJ0aW5nIHBvaW50IGZvciBhZGRyZXNzaW5nIHRoZSBtYXRlcmlh bCBpdCBjb3ZlcnMsIGFuZCB0aGUgd29ya2luZyBncm91cCBzaG91bGQgY292ZXIgdGhhdCBtYXRl cmlhbC4NCg0KWW91cnMsDQpKb2VsDQoNCk9uIDQvMTgvMTQsIDY6MzEgUE0sIEppbSBHdWljaGFy ZCAoamd1aWNoYXIpIHdyb3RlOg0KPiBEZWFyIFdHOg0KPg0KPiBUaGlzIG1lc3NhZ2UgYmVnaW5z IGEgdHdvIHdlZWsgY2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgdGhlIGRvY3VtZW50DQo+IGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQta3VtYXItc2ZjLWRjLXVzZS1jYXNlcy0wMS50eHQgZW5k aW5nIDJuZA0KPiBNYXkgMjAxNC4NCj4NCj4gUGxlYXNlIHJlc3BvbmQgdG8gdGhlIFNGQyBtYWls aW5nIGxpc3Qgd2l0aCBhbnkgc3RhdGVtZW50cyBvZiBhcHByb3ZhbA0KPiBvciBkaXNhcHByb3Zh bC4NCj4NCj4gUGxlYXNlIG5vdGU6DQo+DQo+ICAxLiBUaGlzIGlzIG5vdCBXRyBMYXN0IENhbGwu IFRoZSBkb2N1bWVudCBpcyBub3QgZmluYWwsIGFuZCB0aGUgV0cgaXMNCj4gICAgIGV4cGVjdGVk IHRvIG1vZGlmeSB0aGUgZG9jdW1lbnQncyBjb250ZW50IHVudGlsIHRoZXJlIGlzIFdHDQo+ICAg ICBjb25zZW5zdXMgdGhhdCB0aGUgY29udGVudCBpcyBzb2xpZC4gVGhlcmVmb3JlLCBwbGVhc2Ug ZG9uJ3Qgb3Bwb3NlDQo+ICAgICBhZG9wdGlvbiBqdXN0IGJlY2F1c2UgeW91IHdhbnQgdG8gc2Vl IGNoYW5nZXMgdG8gaXRzIGNvbnRlbnQuDQo+ICAyLiBJZiB5b3UgaGF2ZSBvYmplY3Rpb25zIHRv IGFkb3B0aW9uIG9mIHRoZSBkb2N1bWVudCwgcGxlYXNlIHN0YXRlDQo+ICAgICB5b3VyIHJlYXNv bnMgd2h5LCBhbmQgZXhwbGFpbiB3aGF0IGl0IHdvdWxkIHRha2UgdG8gYWRkcmVzcyB5b3VyDQo+ ICAgICBjb25jZXJucy4NCj4gIDMuIElmIHlvdSBoYXZlIGlzc3VlcyB3aXRoIHRoZSBjb250ZW50 LCBieSBhbGwgbWVhbnMgcmFpc2UgdGhvc2UgaXNzdWVzDQo+ICAgICBhbmQgd2UgY2FuIGJlZ2lu IGEgZGlhbG9nIGFib3V0IGhvdyBiZXN0IHRvIGFkZHJlc3MgdGhlbS4NCj4NCj4NCj4NCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2ZjIG1haWxp bmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRm Lm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQoNCg0KLS0N Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClFpb25nIFN1 bg0KQ2hpbmEgVGVsZWNvbSBCZWlqaW5nIFJlc2VhcmNoIEluc3RpdHV0ZQ0KDQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K --_000_4A95BA014132FF49AE685FAB4B9F17F645D088B4dfweml701chmchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0Fj ZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYu TXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDow aW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVm dDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDAN Cgl7bXNvLWxpc3QtaWQ6MjA1NzM4NzA1OTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6LTEyOTMxMjM3MiAxNTg4NzM4Nzc2IDY3Njk4NjkxIDY3Njk4Njkz IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30N CkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6U2ltU3VuOw0K CW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCm9sDQoJe21hcmdpbi1i b3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBoYXZlIGdpdmVuIGV4cGxpY2l0IGNvbW1lbnRzIHRvIHRo ZSBkcmFmdCwgeWV0IG5vdCByZWNlaXZpbmcgYW55IHJlcGx5IGZyb20gdGhlIGF1dGhvcnMuDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U3BlY2lmaWNhbGx5OjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5UaGUg4oCcQURD4oCdIGluIHRoZSBkcmFmdCBpcyBtb3JlIGxpa2UgY29udmVudGlvbmFs IExvYWQgQmFsYW5jZS4gU2luY2UgdGhpcyB1c2UgY2FzZSBpcyBhYm91dCBnZW5lcmFsIERhdGEg Q2VudGVyIHVzZSBjYXNlLCB3ZSBzaG91bGQgdXNlIHRoZSBjb252ZW50aW9uYWwNCiB0ZXJtaW5v bG9neS4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQt aW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGNhbuKAmXQgc2VlIGhvdyB0aGUgZXhh bXBsZXMgbGlzdGVkIGluIFNlY3Rpb24gMyBkcml2ZSB0aGUgcmVxdWlyZW1lbnQgbGlzdGVkIGlu IFNlY3Rpb24gNS4gVGhlIHJlcXVpcmVtZW50IGxpc3RlZCBpbiBTZWN0aW9uIDUgYXJlIHNvIGdl bmVyYWwsIHRoYXQNCiB5b3UgZG9u4oCZdCBuZWVkIHRob3NlIGV4YW1wbGVzIGxpc3RlZCBpbiBT ZWN0aW9uIDMuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0 ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2luY2UgdGhpcyBpcyBhIHVzZSBj YXNlIGRyYWZ0LCBub3QgcmVxdWlyZW1lbnQgZHJhZnQsIHRoaXMgZHJhZnQgc2hvdWxkIG9ubHkg bGlzdCBkb3duIHRoZSByZXF1aXJlbWVudCBkcml2ZW4gYnkgdGhlIGV4YW1wbGVzLg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBzZWUgdGhhdCB0aGUga2V5IHJlcXVpcmVt ZW50IGRyaXZlbiBieSB0aGUgZXhhbXBsZXMgaW4gU2VjdGlvbiAzIGlzIHRvIGFsbG93IHRob3Nl IFNlcnZpY2UgRnVuY3Rpb25zIHRvIGJlIGxvY2F0ZWQgJm5ic3A7YW55d2hlcmUgKGkuZS4NCiBu b3QgbmVjZXNzYXJpbHkgb24gdGhlIGRhdGEgcGF0aCkuIFRoZXJlZm9yZSwgdGhlIGtleSByZXF1 aXJlbWVudCBzaG91bGQgYmUgbmVlZGluZyBkeW5hbWljIHN0ZWVyaW5nIHBvbGljaWVzIHRvIFNl cnZpY2UgTm9kZXMsIHJvdXRlcnMsIGFuZCBzd2l0Y2hlczwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MaW5kYTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzZmMgW21haWx0bzpz ZmMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TmcsIFRvbXk8YnI+DQo8 Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXkgMDcsIDIwMTQgMjoyMyBBTTxicj4NCjxiPlRvOjwv Yj4gUWlvbmc7IFBoYW0sIENodW9uZyBEPGJyPg0KPGI+Q2M6PC9iPiBKb2VsIE0uIEhhbHBlcm47 IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBIYWVmZm5lciwgV2FsdGVyLCBWb2RhZm9uZSBERTsg c2ZjQGlldGYub3JnOyBKZWZmcmV5IE5hcHBlciAoamVuYXBwZXIpIChqZW5hcHBlckBjaXNjby5j b20pPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2ZjXSBDYWxsIGZvciBhZG9wdGlvbiBvZiBk cmFmdC1rdW1hci1zZmMtZGMtdXNlLWNhc2VzLTAxPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t QVUiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhpIEFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFncmVlIHdpdGgmbmJzcDtDaHVv bmfigJlzIHZpZXdwb2ludCBhbmQgSSBkaXNhcHByb3ZlIHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRy YWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUFVIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Q2hlZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Ub215PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1B VSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1BVSI+T24gV2VkLCBBcHIgMzAsIDIwMTQgYXQgNzozNSBBTSwgUGhhbSwgQ2h1 b25nIEQgJmx0OzxhIGhyZWY9Im1haWx0bzpDaHVvbmcuRC5QaGFtQHRlYW0udGVsc3RyYS5jb20i IHRhcmdldD0iX2JsYW5rIj5DaHVvbmcuRC5QaGFtQHRlYW0udGVsc3RyYS5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1BVSI+U2VwYXJhdGUgZHJhZnRzIGZvciBwb2NrZXRzIG9mIGVudmlyb25tZW50cyB3 aWxsIG1vc3QgbGlrZWx5IG92ZXJsb29rIHRoZSBvcHBvcnR1bml0aWVzIGZvciBpZGVudGlmeWlu ZyBjb21tb25hbGl0aWVzLCBzeW5lcmdpZXMgYW5kIHJldXNlIGZhY3RvcnMgYmV0d2VlbiBzaW1p bGFyIHVzZSBjYXNlcyBmb3IgZGlmZmVyZW50IGVudmlyb25tZW50cy4gVGhpcyBpcyB0aGUgcGFp bmZ1bA0KIHNpdHVhdGlvbiB0b2RheSB3aGVyZSBzaWxvcyBleGlzdCB3aGlsZSBhdCB0aGlzIHBv aW50IGluIHRpbWUgd2hlcmUgTW9iaWxlLCBGaXhlZCBCcm9hZGJhbmQgYW5kIERhdGEgQ2VudHJl IGFyZSBzZWVpbmcgc3Ryb25nIGZvcmNlcyB0b3dhcmRzIGNvbnZlcmdlbmNlIHdpdGggU0ROLCBO RlYgYW5kIENsb3VkIHRlY2hub2xvZ2llcy48YnI+DQo8YnI+DQpBbiBvdmVyYWxsIGRyYWZ0IHN1 Y2ggYXMgZHJhZnQtbGl1IG9yIHNpbWlsYXIgbXVzdCBleGlzdCBhcyBhIGNvbW1vbiByZWZlcmVu Y2UgcG9pbnQgZm9yIG1vcmUgZGV0YWlsZWQgbGV2ZWwgZHJhZnRzIGFkZHJlc3NpbmcgdXNlIGNh c2VzIGZvciBzcGVjaWZpYy9wb2NrZXRzIG9mIGVudmlyb25tZW50cyB3aGlsZSBhbGxvd2luZyBm b3IgZnV0dXJlIG1pZ3JhdGlvbi9jb252ZXJnZW5jZS48YnI+DQo8YnI+DQpVbmxlc3MgZHJhZnQt a3VtYXIgY28tZXhpc3RzIHdpdGggaGlnaCBsZXZlbCBkcmFmdC1saXUsIEkgc2VlIG1vcmUgaGFy bSBpbiBkaXZlcmdlbmNlIHJhdGhlciB0aGFuIGJlbmVmaXRzIHRoZXJlZm9yZSBJIGRpc2FwcHJv dmUuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQpDaHVvbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIj48 YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IEhhZWZmbmVy LCBXYWx0ZXIsIFZvZGFmb25lIERFIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOndhbHRlci5oYWVm Zm5lckB2b2RhZm9uZS5jb20iPndhbHRlci5oYWVmZm5lckB2b2RhZm9uZS5jb208L2E+XTxicj4N ClNlbnQ6IFdlZG5lc2RheSwgMzAgQXByaWwgMjAxNCAyOjU2IEFNPGJyPg0KVG86IEpvZWwgTS4g SGFscGVybjsgSmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0 Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQpDYzogSmVmZnJleSBOYXBwZXIgKGplbmFwcGVy KSAoPGEgaHJlZj0ibWFpbHRvOmplbmFwcGVyQGNpc2NvLmNvbSI+amVuYXBwZXJAY2lzY28uY29t PC9hPik8YnI+DQpTdWJqZWN0OiBSZTogW3NmY10gQ2FsbCBmb3IgYWRvcHRpb24gb2YgZHJhZnQt a3VtYXItc2ZjLWRjLXVzZS1jYXNlcy0wMTxicj4NCjxicj4NCkkgYWxzbyBzdXBwb3J0IHRoaXMg ZHJhZnQuIEJlaW5nIG9uIERDIGxldmVsIHRoaXMgZHJhZnQgd2lsbCBjb21wbGVtZW50IHRoZSBv dGhlciB1c2UgY2FzZSBkcmFmdHMuIEJlc2lkZSB0eXBpY2FsIEZXIG9yIERQSSBldGMuIHRoZXJl IHNob3VsZCBiZSBub3QgdGhhdCBtdWNoIG92ZXJsYXAgd2l0aCB0aGUgbW9yZSBjYXJyaWVyIHNl cnZpY2VzIG9yaWVudGVkIHVzZSBjYXNlIGRyYWZ0cy48YnI+DQo8YnI+DQpDaGVlcnMsIFdhbHRl cjxicj4NCjxicj4NCjxicj4NCi0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS08YnI+ DQpWb246IHNmYyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+ c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBJbSBBdWZ0cmFnIHZvbiBKb2VsIE0uIEhhbHBlcm48 YnI+DQpHZXNlbmRldDogU2Ftc3RhZywgMTkuIEFwcmlsIDIwMTQgMDE6MjU8YnI+DQpBbjogSmlt IEd1aWNoYXJkIChqZ3VpY2hhcik7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0Bp ZXRmLm9yZzwvYT48YnI+DQpCZXRyZWZmOiBSZTogW3NmY10gQ2FsbCBmb3IgYWRvcHRpb24gb2Yg ZHJhZnQta3VtYXItc2ZjLWRjLXVzZS1jYXNlcy0wMTxicj4NCjxicj4NCkkgc3VwcG9ydCBhZG9w dGlvbiBvZiB0aGlzIGRvY3VtZW50IGJ5IHRoZSB3b3JraW5nIGdyb3VwLiAmbmJzcDtJdCBpcyBh IGdvb2Qgc3RhcnRpbmcgcG9pbnQgZm9yIGFkZHJlc3NpbmcgdGhlIG1hdGVyaWFsIGl0IGNvdmVy cywgYW5kIHRoZSB3b3JraW5nIGdyb3VwIHNob3VsZCBjb3ZlciB0aGF0IG1hdGVyaWFsLjxicj4N Cjxicj4NCllvdXJzLDxicj4NCkpvZWw8YnI+DQo8YnI+DQpPbiA0LzE4LzE0LCA2OjMxIFBNLCBK aW0gR3VpY2hhcmQgKGpndWljaGFyKSB3cm90ZTo8YnI+DQomZ3Q7IERlYXIgV0c6PGJyPg0KJmd0 Ozxicj4NCiZndDsgVGhpcyBtZXNzYWdlIGJlZ2lucyBhIHR3byB3ZWVrIGNhbGwgZm9yIFdHIGFk b3B0aW9uIG9mIHRoZSBkb2N1bWVudDxicj4NCiZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRm Lm9yZy9pZC9kcmFmdC1rdW1hci1zZmMtZGMtdXNlLWNhc2VzLTAxLnR4dCIgdGFyZ2V0PSJfYmxh bmsiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1rdW1hci1zZmMtZGMtdXNlLWNhc2Vz LTAxLnR4dDwvYT4gZW5kaW5nIDJuZDxicj4NCiZndDsgTWF5IDIwMTQuPGJyPg0KJmd0Ozxicj4N CiZndDsgUGxlYXNlIHJlc3BvbmQgdG8gdGhlIFNGQyBtYWlsaW5nIGxpc3Qgd2l0aCBhbnkgc3Rh dGVtZW50cyBvZiBhcHByb3ZhbDxicj4NCiZndDsgb3IgZGlzYXBwcm92YWwuPGJyPg0KJmd0Ozxi cj4NCiZndDsgUGxlYXNlIG5vdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7MS4gVGhpcyBp cyBub3QgV0cgTGFzdCBDYWxsLiBUaGUgZG9jdW1lbnQgaXMgbm90IGZpbmFsLCBhbmQgdGhlIFdH IGlzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IGV4cGVjdGVkIHRvIG1vZGlmeSB0aGUgZG9jdW1l bnQncyBjb250ZW50IHVudGlsIHRoZXJlIGlzIFdHPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IGNv bnNlbnN1cyB0aGF0IHRoZSBjb250ZW50IGlzIHNvbGlkLiBUaGVyZWZvcmUsIHBsZWFzZSBkb24n dCBvcHBvc2U8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgYWRvcHRpb24ganVzdCBiZWNhdXNlIHlv dSB3YW50IHRvIHNlZSBjaGFuZ2VzIHRvIGl0cyBjb250ZW50Ljxicj4NCiZndDsgJm5ic3A7Mi4g SWYgeW91IGhhdmUgb2JqZWN0aW9ucyB0byBhZG9wdGlvbiBvZiB0aGUgZG9jdW1lbnQsIHBsZWFz ZSBzdGF0ZTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB5b3VyIHJlYXNvbnMgd2h5LCBhbmQgZXhw bGFpbiB3aGF0IGl0IHdvdWxkIHRha2UgdG8gYWRkcmVzcyB5b3VyPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7IGNvbmNlcm5zLjxicj4NCiZndDsgJm5ic3A7My4gSWYgeW91IGhhdmUgaXNzdWVzIHdp dGggdGhlIGNvbnRlbnQsIGJ5IGFsbCBtZWFucyByYWlzZSB0aG9zZSBpc3N1ZXM8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDsgYW5kIHdlIGNhbiBiZWdpbiBhIGRpYWxvZyBhYm91dCBob3cgYmVzdCB0 byBhZGRyZXNzIHRoZW0uPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsg c2ZjIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+ c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zZmMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnI+DQomZ3Q7PGJyPg0KPGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzZmMgbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8 L2E+PGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpzZmMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNm Y0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tQVUiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUFVIj4tLSA8YnI+DQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KUWlvbmcgU3VuPGJyPg0K Q2hpbmEgVGVsZWNvbSBCZWlqaW5nIFJlc2VhcmNoIEluc3RpdHV0ZTxicj4NCjxicj4NCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4A95BA014132FF49AE685FAB4B9F17F645D088B4dfweml701chmchi_-- From nobody Tue May 13 01:32:40 2014 Return-Path: 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 B6D2C1A01C3 for ; Tue, 13 May 2014 01:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 FKgH4Q_AGiIz for ; Tue, 13 May 2014 01:32:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1107B1A004B for ; Tue, 13 May 2014 01:32:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGS13812; Tue, 13 May 2014 08:32:28 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 13 May 2014 09:30:49 +0100 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 13 May 2014 09:32:22 +0100 Received: from SZXEML522-MBX.china.huawei.com ([169.254.2.182]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.03.0158.001; Tue, 13 May 2014 16:32:15 +0800 From: Guanxiaoran To: "sfc@ietf.org" Thread-Topic: Dataplane Metadata vs. Shared Metadata Thread-Index: Ac9uhdeFa7tL1+NgTOyMIuuF7l3xrw== Date: Tue, 13 May 2014 08:32:14 +0000 Message-ID: <2C5AD5728DB9B24189E3A93140E457863B485FBD@szxeml522-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.39] Content-Type: multipart/alternative; boundary="_000_2C5AD5728DB9B24189E3A93140E457863B485FBDszxeml522mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/er8AzTp8hxyI5S8mX4WyGDhNawU Subject: [sfc] Dataplane Metadata vs. Shared Metadata X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 08:32:38 -0000 --_000_2C5AD5728DB9B24189E3A93140E457863B485FBDszxeml522mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I found there're different usage definitions of the metadata. I've copied t= hese below for your convenience. Could anyone explain what's the difference between them? Or is there any po= ssible new explanation of the metadata? Thanks, Ran From: draft-quinn-sfc-arch-05.txt 4.7. Shared Metadata Sharing metadata allows the network to provide network-derived information to the SFs, SF-to-SF information exchange and the sharing of service-derived information to the network. This component is optional. SFC infrastructure enables the exchange of this shared data along the SFP. The shared metadata serves several possible roles within the SFC architecture: o Allows elements that typically operate as ships-in-the-night to exchange information. o Encodes information about the network and/or data for post- service forwarding. o Creates an identifier used for policy binding by SFs. o Context information can be derived in several ways: * External sources * Network node classification * Service function classification From: draft-ietf-sfc-problem-statement-05.txt 3.4. Dataplane Metadata Data plane metadata provides the ability to exchange information between logical classification points and service functions (and vice versa) and between service functions. As such metadata is not used as forwarding information to deliver packets along the service overlay. Metadata can include the result of antecedent classification and/or information from external sources. Service functions utilize metadata, as required, for localized policy decisions. In addition to sharing of information, the use of metadata addresses several of the issues raised in section 2, most notably the de- coupling of policy from the topology, and the need for per-service classification (and re-classification). A common approach to service metadata creates a common foundation for interoperability between service functions, regardless of vendor. --_000_2C5AD5728DB9B24189E3A93140E457863B485FBDszxeml522mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi,<= o:p>

    I fo= und there’re different usage definitions of the metadata. I’ve = copied these below for your convenience.

    Coul= d anyone explain what’s the difference between them? Or is there any = possible new explanation of the metadata?

    Than= ks,

    Ran<= o:p>

     

     

    From: draft-quinn-sfc-arch-05.txt

    4.7.  Shared Metadata

     

       Sharing metadata allows the netw= ork to provide network-derived

       information to the SFs, SF-to-SF= information exchange and the sharing

       of service-derived information t= o the network.  This component is

       optional.  SFC infrastructu= re enables the exchange of this shared

       data along the SFP.  The sh= ared metadata serves several possible

       roles within the SFC architectur= e:

     

       o  Allows elements that typ= ically operate as ships-in-the-night to

          exchange infor= mation.

     

       o  Encodes information abou= t the network and/or data for post-

          service forwar= ding.

     

       o  Creates an identifier us= ed for policy binding by SFs.

     

       o  Context information can = be derived in several ways:

     

          *  External sources

     

          *  Network node classifi= cation

     

          *  Service function clas= sification

     

    From: draft-ietf-sfc-problem-statement-05.txt<= /span>

    3.4.  Dataplane Metadata=

     

       Data plane metadata provides the= ability to exchange information

       between logical classification p= oints and service functions (and vice

       versa) and between service funct= ions.  As such metadata is not used

       as forwarding information to del= iver packets along the service

       overlay.

     

       Metadata can include the result = of antecedent classification and/or

       information from external source= s.  Service functions utilize

       metadata, as required, for local= ized policy decisions.

     

       In addition to sharing of inform= ation, the use of metadata addresses

       several of the issues raised in = section 2, most notably the de-

       coupling of policy from the topo= logy, and the need for per-service

       classification (and re-classific= ation).

     

       A common approach to service met= adata creates a common foundation for

       interoperability b= etween service functions, regardless of vendor.=

    --_000_2C5AD5728DB9B24189E3A93140E457863B485FBDszxeml522mbxchi_-- From nobody Wed May 14 15:02:52 2014 Return-Path: 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 0FA361A02D7; Wed, 14 May 2014 15:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 4pPJyBxmMPxi; Wed, 14 May 2014 15:02:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 76B121A01FB; Wed, 14 May 2014 15:02:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGT93917; Wed, 14 May 2014 22:02:40 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 14 May 2014 23:01:41 +0100 Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 14 May 2014 23:02:39 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml705-chm.china.huawei.com ([169.254.7.19]) with mapi id 14.03.0158.001; Wed, 14 May 2014 15:02:33 -0700 From: Linda Dunbar To: "Black, David" , "tsvwg@ietf.org" , "tsv-area@ietf.org" Thread-Topic: Fragmentation and Path MTU text in nvo3 dataplane reqts draft Thread-Index: Ac9vtnHd0ZAyZrcySACl53YRIUspEwACH6cQ Date: Wed, 14 May 2014 22:02:33 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D09D6D@dfweml701-chm.china.huawei.com> References: <8D3D17ACE214DC429325B2B98F3AE712076C55B7B1@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C55B7B1@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.155] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/vzHUVJZ4j2lsXsMw26ClrraPMjI Cc: "sfc@ietf.org" Subject: Re: [sfc] Fragmentation and Path MTU text in nvo3 dataplane reqts draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 22:02:50 -0000 I think that the "fragmentation and path MTU text" should be seriously disc= ussed in SFC WG that is considering Service Chain Header format.=20 I've heard people mentioning encoding the explicit Service Chain path as me= tadata to the data packet header for some scenarios where head-end SC class= ifier node determines the chain path dynamically.=20 Just imagine having IPv6 addresses encoded in the packet header to show exp= licit service chain path, which can be very long. =20 Cheers, Linda -----Original Message----- From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of Black, David Sent: Wednesday, May 14, 2014 3:53 PM To: tsvwg@ietf.org; tsv-area@ietf.org Subject: Fragmentation and Path MTU text in nvo3 dataplane reqts draft Over in the nvo3 WG, draft-ietf-nvo3-dataplane-requirements-03 contains som= e text on dealing with the fragmentation and MTU effects of tunnels. I thought I'd ask for some early review of this text, given recent IESG exc= itement around fragmentation and Path MTU topics in another draft: http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation/ball= ot/=20 I believe that the nvo3 draft is in better shape in these areas. Nonethele= ss, I've included its current text on fragmentation and path MTU below, and= (on behalf of the draft authors and nvo3 WG chairs) I'm looking for input = on what that text should say and why. In nvo3 terminology, an overlay network is an inner network that is tunnele= d over an outer underlay network. The nvo3 WG also uses "Tenant System" as= the term for a sender/receiver of network traffic because multi-tenancy is= an important motivation for the WG's activities in network virtualization. -------------------------------------- 3.5. Path MTU The tunnel overlay header can cause the MTU of the path to the egress tunnel endpoint to be exceeded. =20 IP fragmentation SHOULD be avoided for performance reasons. =20 The interface MTU as seen by a Tenant System SHOULD be adjusted such that no fragmentation is needed. This can be achieved by configuration or be discovered dynamically. =20 Either of the following options MUST be supported: =20 o Classical ICMP-based MTU Path Discovery [RFC1191] [RFC1981] or Extended MTU Path Discovery techniques such as defined in [RFC4821] =20 o Segmentation and reassembly support from the overlay layer operations without relying on the Tenant Systems to know about the end-to-end MTU =20 o The underlay network MAY be designed in such a way that the MTU can accommodate the extra tunnel overhead. -------------------------------------- Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From nobody Wed May 14 20:46:39 2014 Return-Path: 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 E81551A0213; Wed, 14 May 2014 20:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 ND1cvAQF1TRD; Wed, 14 May 2014 20:46:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27EBA1A01E8; Wed, 14 May 2014 20:46:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGU09750; Thu, 15 May 2014 03:46:25 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 May 2014 04:45:25 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 May 2014 04:46:24 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Thu, 15 May 2014 11:46:13 +0800 From: Xuxiaohu To: Linda Dunbar , "Black, David" , "tsvwg@ietf.org" , "tsv-area@ietf.org" Thread-Topic: [sfc] Fragmentation and Path MTU text in nvo3 dataplane reqts draft Thread-Index: Ac9vtnHd0ZAyZrcySACl53YRIUspEwACH6cQAAisYSA= Date: Thu, 15 May 2014 03:46:13 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082721AF@NKGEML512-MBS.china.huawei.com> References: <8D3D17ACE214DC429325B2B98F3AE712076C55B7B1@MX15A.corp.emc.com> <4A95BA014132FF49AE685FAB4B9F17F645D09D6D@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D09D6D@dfweml701-chm.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/0N0hmEleWePTD69CZEKlzgVsiUo Cc: "spring@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] Fragmentation and Path MTU text in nvo3 dataplane reqts draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 03:46:37 -0000 DQoNCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IHNmYyBbbWFpbHRvOnNm Yy1ib3VuY2VzQGlldGYub3JnXSDku6PooaggTGluZGEgRHVuYmFyDQo+IOWPkemAgeaXtumXtDog MjAxNOW5tDXmnIgxNeaXpSA2OjAzDQo+IOaUtuS7tuS6ujogQmxhY2ssIERhdmlkOyB0c3Z3Z0Bp ZXRmLm9yZzsgdHN2LWFyZWFAaWV0Zi5vcmcNCj4g5oqE6YCBOiBzZmNAaWV0Zi5vcmcNCj4g5Li7 6aKYOiBSZTogW3NmY10gRnJhZ21lbnRhdGlvbiBhbmQgUGF0aCBNVFUgdGV4dCBpbiBudm8zIGRh dGFwbGFuZSByZXF0cyBkcmFmdA0KPiANCj4gSSB0aGluayB0aGF0IHRoZSAiZnJhZ21lbnRhdGlv biBhbmQgcGF0aCBNVFUgdGV4dCIgc2hvdWxkIGJlIHNlcmlvdXNseSBkaXNjdXNzZWQNCj4gaW4g U0ZDIFdHIHRoYXQgaXMgY29uc2lkZXJpbmcgU2VydmljZSBDaGFpbiBIZWFkZXIgZm9ybWF0Lg0K PiANCj4gSSd2ZSBoZWFyZCBwZW9wbGUgbWVudGlvbmluZyBlbmNvZGluZyB0aGUgZXhwbGljaXQg U2VydmljZSBDaGFpbiBwYXRoIGFzDQo+IG1ldGFkYXRhIHRvIHRoZSBkYXRhIHBhY2tldCBoZWFk ZXIgZm9yIHNvbWUgc2NlbmFyaW9zIHdoZXJlIGhlYWQtZW5kIFNDDQo+IGNsYXNzaWZpZXIgbm9k ZSBkZXRlcm1pbmVzIHRoZSBjaGFpbiBwYXRoIGR5bmFtaWNhbGx5Lg0KDQpUbyBhbGxvdyB0aGUg Y2xhc3NpZmllciB0byBkZXRlcm1pbmUgdGhlIHNlcnZpY2UgcGF0aCBkeW5hbWljYWxseSwgd2h5 IG5vdCBkaXJlY3RseSBlbmNvZGluZyB0aGUgZXhwbGljaXQgc2VydmljZSBwYXRoIGluZm9ybWF0 aW9uIHdpdGhpbiB0aGUgU1IgKHNvdXJjZSByb3V0aW5nIG9yIHNlZ21lbnQgcm91dGluZykgaGVh ZGVyIChzZWUgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtc3ByaW5nLXNmYy11 c2UtY2FzZS0wMCksIGVzcGVjaWFsbHkgdGhlIE1QTFMgbGFiZWwgc3RhY2sgYmFzZWQgU1IgaGVh ZGVyIGlmIE1UVSBpcyBzdGlsbCBhIGNvbmNlcm4/IA0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUN Cg0KPiBKdXN0IGltYWdpbmUgaGF2aW5nIElQdjYgYWRkcmVzc2VzIGVuY29kZWQgaW4gdGhlIHBh Y2tldCBoZWFkZXIgdG8gc2hvdw0KPiBleHBsaWNpdCBzZXJ2aWNlIGNoYWluIHBhdGgsIHdoaWNo IGNhbiBiZSB2ZXJ5IGxvbmcuDQoNCg0KPiBDaGVlcnMsDQo+IA0KPiBMaW5kYQ0KPiANCj4gDQo+ IA0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHRzdi1hcmVh IFttYWlsdG86dHN2LWFyZWEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJsYWNrLCBE YXZpZA0KPiBTZW50OiBXZWRuZXNkYXksIE1heSAxNCwgMjAxNCAzOjUzIFBNDQo+IFRvOiB0c3Z3 Z0BpZXRmLm9yZzsgdHN2LWFyZWFAaWV0Zi5vcmcNCj4gU3ViamVjdDogRnJhZ21lbnRhdGlvbiBh bmQgUGF0aCBNVFUgdGV4dCBpbiBudm8zIGRhdGFwbGFuZSByZXF0cyBkcmFmdA0KPiANCj4gPFdH IGNoYWlyIGhhdCBvZmY+DQo+IA0KPiBPdmVyIGluIHRoZSBudm8zIFdHLCBkcmFmdC1pZXRmLW52 bzMtZGF0YXBsYW5lLXJlcXVpcmVtZW50cy0wMyBjb250YWlucw0KPiBzb21lIHRleHQgb24gZGVh bGluZyB3aXRoIHRoZSBmcmFnbWVudGF0aW9uIGFuZCBNVFUgZWZmZWN0cyBvZiB0dW5uZWxzLg0K PiBJIHRob3VnaHQgSSdkIGFzayBmb3Igc29tZSBlYXJseSByZXZpZXcgb2YgdGhpcyB0ZXh0LCBn aXZlbiByZWNlbnQgSUVTRyBleGNpdGVtZW50DQo+IGFyb3VuZCBmcmFnbWVudGF0aW9uIGFuZCBQ YXRoIE1UVSB0b3BpY3MgaW4gYW5vdGhlciBkcmFmdDoNCj4gDQo+IGh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pcHNlY21lLWlrZXYyLWZyYWdtZW50YXRpb24vYmFs bG90Lw0KPiANCj4gSSBiZWxpZXZlIHRoYXQgdGhlIG52bzMgZHJhZnQgaXMgaW4gYmV0dGVyIHNo YXBlIGluIHRoZXNlIGFyZWFzLiAgTm9uZXRoZWxlc3MsIEkndmUNCj4gaW5jbHVkZWQgaXRzIGN1 cnJlbnQgdGV4dCBvbiBmcmFnbWVudGF0aW9uIGFuZCBwYXRoIE1UVSBiZWxvdywgYW5kIChvbiBi ZWhhbGYNCj4gb2YgdGhlIGRyYWZ0IGF1dGhvcnMgYW5kIG52bzMgV0cgY2hhaXJzKSBJJ20gbG9v a2luZyBmb3IgaW5wdXQgb24gd2hhdCB0aGF0IHRleHQNCj4gc2hvdWxkIHNheSBhbmQgd2h5Lg0K PiANCj4gSW4gbnZvMyB0ZXJtaW5vbG9neSwgYW4gb3ZlcmxheSBuZXR3b3JrIGlzIGFuIGlubmVy IG5ldHdvcmsgdGhhdCBpcyB0dW5uZWxlZA0KPiBvdmVyIGFuIG91dGVyIHVuZGVybGF5IG5ldHdv cmsuICBUaGUgbnZvMyBXRyBhbHNvIHVzZXMgIlRlbmFudCBTeXN0ZW0iIGFzDQo+IHRoZSB0ZXJt IGZvciBhIHNlbmRlci9yZWNlaXZlciBvZiBuZXR3b3JrIHRyYWZmaWMgYmVjYXVzZSBtdWx0aS10 ZW5hbmN5IGlzIGFuDQo+IGltcG9ydGFudCBtb3RpdmF0aW9uIGZvciB0aGUgV0cncyBhY3Rpdml0 aWVzIGluIG5ldHdvcmsgdmlydHVhbGl6YXRpb24uDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gMy41LiBQYXRoIE1UVQ0KPiANCj4gICAgICAgIFRo ZSB0dW5uZWwgb3ZlcmxheSBoZWFkZXIgY2FuIGNhdXNlIHRoZSBNVFUgb2YgdGhlIHBhdGggdG8g dGhlDQo+ICAgICAgICBlZ3Jlc3MgdHVubmVsIGVuZHBvaW50IHRvIGJlIGV4Y2VlZGVkLg0KPiAN Cj4gICAgICAgIElQIGZyYWdtZW50YXRpb24gU0hPVUxEIGJlIGF2b2lkZWQgZm9yIHBlcmZvcm1h bmNlIHJlYXNvbnMuDQo+IA0KPiAgICAgICAgVGhlIGludGVyZmFjZSBNVFUgYXMgc2VlbiBieSBh IFRlbmFudCBTeXN0ZW0gU0hPVUxEIGJlIGFkanVzdGVkDQo+IHN1Y2gNCj4gICAgICAgIHRoYXQg bm8gZnJhZ21lbnRhdGlvbiBpcyBuZWVkZWQuIFRoaXMgY2FuIGJlIGFjaGlldmVkIGJ5DQo+ICAg ICAgICBjb25maWd1cmF0aW9uIG9yIGJlIGRpc2NvdmVyZWQgZHluYW1pY2FsbHkuDQo+IA0KPiAg ICAgICAgRWl0aGVyIG9mIHRoZSBmb2xsb3dpbmcgb3B0aW9ucyBNVVNUIGJlIHN1cHBvcnRlZDoN Cj4gDQo+ICAgICAgICAgICBvIENsYXNzaWNhbCBJQ01QLWJhc2VkIE1UVSBQYXRoIERpc2NvdmVy eSBbUkZDMTE5MV0gW1JGQzE5ODFdIG9yDQo+ICAgICAgICAgICAgIEV4dGVuZGVkIE1UVSBQYXRo IERpc2NvdmVyeSB0ZWNobmlxdWVzIHN1Y2ggYXMgZGVmaW5lZCBpbg0KPiAgICAgICAgICAgICBb UkZDNDgyMV0NCj4gDQo+ICAgICAgICAgICBvIFNlZ21lbnRhdGlvbiBhbmQgcmVhc3NlbWJseSBz dXBwb3J0IGZyb20gdGhlIG92ZXJsYXkgbGF5ZXINCj4gICAgICAgICAgICAgb3BlcmF0aW9ucyB3 aXRob3V0IHJlbHlpbmcgb24gdGhlIFRlbmFudCBTeXN0ZW1zIHRvIGtub3cgYWJvdXQNCj4gICAg ICAgICAgICAgdGhlIGVuZC10by1lbmQgTVRVDQo+IA0KPiAgICAgICAgICAgbyBUaGUgdW5kZXJs YXkgbmV0d29yayBNQVkgYmUgZGVzaWduZWQgaW4gc3VjaCBhIHdheSB0aGF0IHRoZQ0KPiBNVFUN Cj4gICAgICAgICAgICAgY2FuIGFjY29tbW9kYXRlIHRoZSBleHRyYSB0dW5uZWwgb3ZlcmhlYWQu DQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gPC9X RyBjaGFpciBoYXQgb2ZmPg0KPiANCj4gVGhhbmtzLA0KPiAtLURhdmlkDQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRGF2aWQgTC4gQmxh Y2ssIERpc3Rpbmd1aXNoZWQgRW5naW5lZXINCj4gRU1DIENvcnBvcmF0aW9uLCAxNzYgU291dGgg U3QuLCBIb3BraW50b24sIE1BwqAgMDE3NDgNCj4gKzEgKDUwOCkgMjkzLTc5NTPCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgRkFYOiArMSAoNTA4KSAyOTMtNzc4Ng0KPiBkYXZpZC5ibGFja0BlbWMu Y29twqDCoMKgwqDCoMKgwqAgTW9iaWxlOiArMSAoOTc4KSAzOTQtNzc1NA0KPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZmMgbWFpbGluZyBs aXN0DQo+IHNmY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0K From nobody Thu May 15 01:34:57 2014 Return-Path: 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 D47EA1A0417 for ; Thu, 15 May 2014 01:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 E_i0shCkeKr7 for ; Thu, 15 May 2014 01:34:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E95111A0407 for ; Thu, 15 May 2014 01:34:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGU32339; Thu, 15 May 2014 08:34:45 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 May 2014 09:33:26 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 May 2014 09:34:25 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Thu, 15 May 2014 16:34:20 +0800 From: "Songhaibin (A)" To: "sfc@ietf.org" Thread-Topic: legacy service function support Thread-Index: Ac9wGHcZ4YAz9nbpSim2k14rPOG0SA== Date: Thu, 15 May 2014 08:34:19 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/hcOowVPl8jcnWXC4JKtL79NomCk Subject: [sfc] legacy service function support X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 08:34:56 -0000 Dear guys, Problems on how to support legacy service function instances, especially no= n-transparent service function instances become important. In the following draft http://tools.ietf.org/id/draft-song-sfc-legacy-sf-mapping-01.txt we describe some mapping methods for the terminating node (SFE in our draft= ) to terminate the SFC header and then send the packet to service function = instance and then re-encapsulate SFC header to the original packet after re= ceiving that packet from the service function instance. But for non-transparent SFIs, using a mapping mechanism to identify the ori= ginal SFC header become more complicated. One way might be using the contro= l plane to get the packet header mapping relationship and then notify the t= erminating node (SFE), which helps SFE to identify the original SFC header.= Any other thoughts on this? Another concern is about whether there is per packet meta data. If there is= , we need to identify each packet for the decapsulation and re-encapsulatio= n. And for each packet, we need a way to identify it.=20 But if there are SFIs doing packet combination or fragmentation, then what = shall we do with the SFC header in the terminating node (SFE)? Combine the = meta data part or what? I also noticed that a new section 7 of http://tools.ietf.org/id/draft-quinn= -sfc-arch-05.txt has a brief introduction of legacy SFI support. And in ano= ther architecture draft http://tools.ietf.org/id/draft-jiang-sfc-arch-01.tx= t, it also mentions about legacy service function support. I think people a= gree that the legacy SFI support is in scope of the architecture and the ne= xt step work. Best Regards! -Haibin From nobody Thu May 15 06:51:52 2014 Return-Path: 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 4C4801A00B3 for ; Thu, 15 May 2014 06:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 CqemADnhhfWX for ; Thu, 15 May 2014 06:51:33 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C8421A008D for ; Thu, 15 May 2014 06:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16307; q=dns/txt; s=iport; t=1400161886; x=1401371486; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uXE2bmxMGx3D5usuJ2K548zLAL/ntjOKQqQ8gAzDCVk=; b=S77hs5JktKRwWvvpvpyQuQIv6C5Z0oIe97OrfCsf4LSU7ZA8SxaYXMLN PzWq9AmWKRo+UIFDzoS7xOewC+5uAb9lvBvXQd/O4/DIHdH0zwpLIcmr+ hO5EtmRT0E7KZ7yMZozLABhG0oZPofV4RE1EARggkCxcf33CRpTwfZpnN 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAJ/FdFOtJV2c/2dsb2JhbABQCYJCRIEnxRgBgRAWdIImAQEEcgUCEAIBCBItBzIUAw4CBA4FiEHRGheNc1sHgyuBFQSZUZMUgzaCMA X-IronPort-AV: E=Sophos;i="4.97,1059,1389744000"; d="scan'208,217";a="325223976" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 15 May 2014 13:51:25 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s4FDpPZM018376 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 May 2014 13:51:25 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Thu, 15 May 2014 08:51:24 -0500 From: "Paul Quinn (paulq)" To: Lucy yong Thread-Topic: Comments on RE: New Version Notification for draft-quinn-sfc-arch-05.txt Thread-Index: AQHPaIfarkMZcB0ak0qMpN0Eo35H05s0D0DQgA39BYA= Date: Thu, 15 May 2014 13:51:24 +0000 Message-ID: References: <20140505173129.23329.89665.idtracker@ietfa.amsl.com> <5A389ED0-86BF-4F6B-A367-5C1512C9D589@cisco.com> <2691CE0099834E4A9C5044EEC662BB9D453757B4@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453757B4@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.231] Content-Type: multipart/alternative; boundary="_000_ED88DD49A6DF4F6CB313A4EFD493A8B5ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ueKcu7VsDwzXTaU-ZSQHC35rBy4 Cc: "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Comments on RE: New Version Notification for draft-quinn-sfc-arch-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 13:51:39 -0000 --_000_ED88DD49A6DF4F6CB313A4EFD493A8B5ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Lucy, Thank you for the comments, please see inline. Paul On May 6, 2014, at 6:38 PM, Lucy yong > wrote: Hi Paul and Joe, This version expends a lot. The writing is clear. Here are some comments and suggestions: * In introduction, statement "No IANA registry is required to store the= identity of SFs." Is it important or necessary to state this? If yes, why? PQ> We are clarifying that there is no implication of a SF registry. * The term of "Service Node" is defined; but the doc. does not describe= its relationship to other architecture components specified in section 4. = Does it mean that a service node has to contain SF(s), SFF, NF or some of t= hese components? For example, could a SN only have a SF, i.e. not co-locate= with SFF/NF? BTW, the service node is barely used in text, which make hard= to picture its roles. PQ> All the components are logical, and therefore and be combined as neede= d by an implementor. You do raise a good point about a SN though. I tend = to think of it as an optimization used for implementation, we=92ll review h= ow to present it in the draft. * Does the architecture allow that passing SFC encapsulated packets bet= ween a SF and its associated SFF go through NF or not? PQ> I don=92t understand the question. Packets go NF <=97> SFF <=97> SF. * If the SFC architecture allows branching as described, it is good to = show a branching example in figure 1. BTW, the last sentence in sec. 2.2 sh= ould be moved to sec. 2.1 and state that is the third example in figure 1. PQ> Figure 1 simply uses a linear depiction of the path. If it=92s confus= ing one of the figure can be reoriented to explicitly depict branching. Al= so, that sentence will be moved, thanks for catching it. * Section 4 describes core SFC arch components. Classification is state= d as a core SFC arch component and is a logical component, and "as a conseq= uence of the classification decision, the appropriate SFC encapsulation is = imposed on the data prior to forwarding along the SFP." However, is does no= t illustrate this component in figure 2, which makes unclear how this compo= nent relates to other component in this figure or described in the text. Su= ggest illustrating this component in figure 2 and/or describe it in text. PQ> Do you have any suggested text and/or a updates to the figure? * In Section 4.3, don't know why show SFF table here. Does that mean th= at all SFs in the table associate to the same SFF? The text and table is qu= ite misleading. The SFP of SFC may result SFs on multiple SFFs. The table o= n each SFF only maintains the SFs in a SFP associated to it. PQ> This table is simply a conceptual representation of how service forwar= ding is maintained at the SFFs. SFID details, including which SFF they are = associated with, could be maintained separately at each SFF. We do not want= to impose how they are implemented. * Statement about stateful SFF mixes with SFC proxy function. It should= be distinct. PQ> There is a dedicated =93SFC Proxy=94 subsection, so it is a distinct (= logical) component. * SFC architecture should work in multi-tenant environment where indivi= dual tenant may use SFCs. Should we add some clarification on that? PQ> That is a broad statement, there=92s nothing in this draft the preclud= es, or assumes for that matter, multi-tenancy. Are there specific areas yo= u=92d like to see addressed, or sections added? * Does the SFC architecture impose some security consideration? Stateme= nt in section 11 seems weak. PQ> We will update this section. * Overlay network and SFC network mean the same in this doc, is that ri= ght? May be good to state out clearly or use one term through the doc. PQ> Yes and no: the SFC network is an overlay but it introduces a new topo= logy due to the service chain. Thanks Paul --_000_ED88DD49A6DF4F6CB313A4EFD493A8B5ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Lucy,

    Thank you for the comments, please see inline.

    Paul

    On May 6, 2014, at 6:38 PM, Lucy yong <lucy.yong@huawei.com> wrote:

    Hi Paul and Joe,
     
    This version expends a lot. The writing is clear.
     
    Here are some comments and suggestions:
     
    • In introduction, statement "No IANA registry is required to store = the identity of SFs." Is it important or necessary to state this? If y= es, why?

    PQ>  We are clarifying that there is no implication of a SF re= gistry.  



     
    • The term of "Service Node" is defined; but the doc. does not = describe its relationship to other architecture components specified in sec= tion 4. Does it mean that a service node has to contain SF(s), SFF, NF or s= ome of these components? For example, could a SN only have a SF, i.e. not co-locate with SFF/NF? BTW, the service node= is barely used in text, which make hard to picture its roles.

    PQ>  All the components are logical, and therefore and be comb= ined as needed by an implementor.  You do raise a good point about a S= N though.  I tend to think of it as an optimization used for implement= ation, we=92ll review how to present it in the draft.



     
    • Does the architecture allow that passing SFC encapsulated packets betwe= en a SF and its associated SFF go through NF or not?

    PQ>  I don=92t understand the question.  Packets go NF &l= t;=97> SFF <=97> SF.



     
    • If the SFC architecture allows branching as described, it is good to sh= ow a branching example in figure 1. BTW, the last sentence in sec. 2.2 shou= ld be moved to sec. 2.1 and state that is the third example in figure 1.

    PQ>  Figure 1 simply uses a linear depiction of the path. &nbs= p;If it=92s confusing one of the figure can be reoriented to explicitly dep= ict branching.  Also, that sentence will be moved, thanks for catching= it.



     
    • Section 4 describes core SFC arch components. Classification is stated = as a core SFC arch component and is a logical component, and "as a con= sequence of the classification decision, the appropriate SFC encapsulation = is imposed on the data prior to forwarding along the SFP." However, is does not illustrate this component in fig= ure 2, which makes unclear how this component relates to other component in= this figure or described in the text. Suggest illustrating this component = in figure 2 and/or describe it in text.

    PQ>  Do you have any suggested text and/or a updates to the fi= gure?



     
    • In Section 4.3, don't know why show SFF table here. Does that mean that= all SFs in the table associate to the same SFF? The text and table is quit= e misleading. The SFP of SFC may result SFs on multiple SFFs. The table on = each SFF only maintains the SFs in a SFP associated to it.

    PQ>  This table is simply a conceptual representation of how serv= ice forwarding is maintained at the SFFs. SFID details, including which SFF= they are associated with, could be maintained separately at each SFF. We do not want to impose how they are implemented.=


     
    • Statement about stateful SFF mixes with SFC proxy function. It should b= e distinct.

    PQ>  There is a dedicated =93SFC Proxy=94 subsection, so it is= a distinct (logical) component.



     
    • SFC architecture should work in multi-tenant environment where individu= al tenant may use SFCs. Should we add some clarification on that?
     

    PQ>  That is a broad statement, there=92s nothing in this draf= t the precludes, or assumes for that matter, multi-tenancy.  Are there= specific areas you=92d like to see addressed, or sections added?



    • Does the SFC architecture impose some security consideration? Statement= in section 11 seems weak.

    PQ>  We will update this section.


     
    • Overlay network and SFC network mean the same in this doc, is that righ= t? May be good to state out clearly or use one term through the doc.


    PQ>  Yes and no: the SFC network is an overlay but it introduc= es a new topology due to the service chain.


    Thanks
    Paul

    --_000_ED88DD49A6DF4F6CB313A4EFD493A8B5ciscocom_-- From nobody Thu May 15 09:41:30 2014 Return-Path: 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 4F2B61A02E0 for ; Thu, 15 May 2014 09:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 Vw6WS7ZgPSga for ; Thu, 15 May 2014 09:41:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 867CC1A00C2 for ; Thu, 15 May 2014 09:41:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEE66541; Thu, 15 May 2014 16:41:14 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 May 2014 17:40:34 +0100 Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 May 2014 17:41:13 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml704-chm.china.huawei.com ([169.254.6.56]) with mapi id 14.03.0158.001; Thu, 15 May 2014 09:41:03 -0700 From: Lucy yong To: "Paul Quinn (paulq)" Thread-Topic: Comments on RE: New Version Notification for draft-quinn-sfc-arch-05.txt Thread-Index: AQHPaIfarkMZcB0ak0qMpN0Eo35H05s0D0DQgA39BYD//9mS8A== Date: Thu, 15 May 2014 16:41:03 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D45378694@dfweml701-chm.china.huawei.com> References: <20140505173129.23329.89665.idtracker@ietfa.amsl.com> <5A389ED0-86BF-4F6B-A367-5C1512C9D589@cisco.com> <2691CE0099834E4A9C5044EEC662BB9D453757B4@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.181] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D45378694dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/dJCwVziF9Hdxyp1Ej8D7wiD_UNU Cc: "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Comments on RE: New Version Notification for draft-quinn-sfc-arch-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 16:41:29 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D45378694dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul and Joel, I propose the following figure for figure 2 to show Classification Function= described in section 4.5. +---------------+ +----------------+ +----------------+ |Classification | | SFC-aware | | SFC-unaware | | Function | |Service Function| |Service Function| ++----------+---+ +-------+--------+ +-------+--------+ | | | | | SFC Encapsulation SFC Encapsulation No SFC Encapsulation ^ | | | Original | | +---------+ Traffic +-----------+ | +--------------|SFC Proxy| | | | | +---------+ .~.~.~,. +--+----+---+----+ / \ | SF Forwarder | | Original | | (SFF) | | Network | +-------+--------+ \.~.~.~.~/ | SFC Encapsulation | +-------+--------+ | SFC Network | | Forwarder (NF) | +----------------+ | Network Overlay Transport | _,....._ ,-' `-. / `. | Network | `. / `.__ _,-' `'''' I'll send my other response on your feedbacks in another email. Regards, Lucy From: Paul Quinn (paulq) [mailto:paulq@cisco.com] Sent: Thursday, May 15, 2014 8:51 AM To: Lucy yong Cc: Joel M. Halpern; sfc@ietf.org Subject: Re: Comments on RE: New Version Notification for draft-quinn-sfc-a= rch-05.txt Lucy, Thank you for the comments, please see inline. Paul On May 6, 2014, at 6:38 PM, Lucy yong > wrote: Hi Paul and Joe, This version expends a lot. The writing is clear. Here are some comments and suggestions: * In introduction, statement "No IANA registry is required to store= the identity of SFs." Is it important or necessary to state this? If yes, = why? PQ> We are clarifying that there is no implication of a SF registry. * The term of "Service Node" is defined; but the doc. does not desc= ribe its relationship to other architecture components specified in section= 4. Does it mean that a service node has to contain SF(s), SFF, NF or some = of these components? For example, could a SN only have a SF, i.e. not co-lo= cate with SFF/NF? BTW, the service node is barely used in text, which make = hard to picture its roles. PQ> All the components are logical, and therefore and be combined as neede= d by an implementor. You do raise a good point about a SN though. I tend = to think of it as an optimization used for implementation, we'll review how= to present it in the draft. * Does the architecture allow that passing SFC encapsulated packets= between a SF and its associated SFF go through NF or not? PQ> I don't understand the question. Packets go NF <-> SFF <-> SF. * If the SFC architecture allows branching as described, it is good= to show a branching example in figure 1. BTW, the last sentence in sec. 2.= 2 should be moved to sec. 2.1 and state that is the third example in figure= 1. PQ> Figure 1 simply uses a linear depiction of the path. If it's confusin= g one of the figure can be reoriented to explicitly depict branching. Also= , that sentence will be moved, thanks for catching it. * Section 4 describes core SFC arch components. Classification is s= tated as a core SFC arch component and is a logical component, and "as a co= nsequence of the classification decision, the appropriate SFC encapsulation= is imposed on the data prior to forwarding along the SFP." However, is doe= s not illustrate this component in figure 2, which makes unclear how this c= omponent relates to other component in this figure or described in the text= . Suggest illustrating this component in figure 2 and/or describe it in tex= t. PQ> Do you have any suggested text and/or a updates to the figure? * In Section 4.3, don't know why show SFF table here. Does that mea= n that all SFs in the table associate to the same SFF? The text and table i= s quite misleading. The SFP of SFC may result SFs on multiple SFFs. The tab= le on each SFF only maintains the SFs in a SFP associated to it. PQ> This table is simply a conceptual representation of how service forwar= ding is maintained at the SFFs. SFID details, including which SFF they are = associated with, could be maintained separately at each SFF. We do not want= to impose how they are implemented. * Statement about stateful SFF mixes with SFC proxy function. It sh= ould be distinct. PQ> There is a dedicated "SFC Proxy" subsection, so it is a distinct (logi= cal) component. * SFC architecture should work in multi-tenant environment where in= dividual tenant may use SFCs. Should we add some clarification on that? PQ> That is a broad statement, there's nothing in this draft the precludes= , or assumes for that matter, multi-tenancy. Are there specific areas you'= d like to see addressed, or sections added? * Does the SFC architecture impose some security consideration? Sta= tement in section 11 seems weak. PQ> We will update this section. * Overlay network and SFC network mean the same in this doc, is tha= t right? May be good to state out clearly or use one term through the doc. PQ> Yes and no: the SFC network is an overlay but it introduces a new topo= logy due to the service chain. Thanks Paul --_000_2691CE0099834E4A9C5044EEC662BB9D45378694dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Paul and Joel,

     <= /p>

    I propose the following f= igure for figure 2 to show Classification Function described in section 4.5= .

     <= /p>

        +----= -----------+    +----------------+  &n= bsp;   +----------------+

        |Classifi= cation |    |   SFC-aware    | = ;     |  SFC-unaware   |

        | Functio= n      |    |Service Function| = ;     |Service Function|

        ++= ;----------+---+    +-------+--------+&n= bsp;     +-------+--------+

         |&n= bsp;         |   &nb= sp;            |&nbs= p;            &= nbsp;         |

         | S= FC Encapsulation   SFC Encapsulation     No S= FC Encapsulation

         ^&n= bsp;         |   &nb= sp;            |&nbs= p;            &= nbsp;         |

       Original &= nbsp;   |         &n= bsp;      |      &nb= sp;           +------= ---+

       Traffic &n= bsp;    +-----------+    |  = ; +--------------|SFC Proxy|

         |&n= bsp;            = ;         |    |&nbs= p;  |           = ;   +---------+

        .~.~.~,.&= nbsp;            = 3;--+----+---+----+

       /  &n= bsp;     \        &n= bsp;   | SF Forwarder   |

      | Original | &nb= sp;         |   &nbs= p;  (SFF)     |

      | Network  |&nbs= p;          +-------+-= -------+

       \.~.~.~.~/ = ;            &n= bsp;      |

        &nbs= p;            &= nbsp;       SFC Encapsulation

        &nbs= p;            &= nbsp;           &nbs= p;   |

        &nbs= p;            &= nbsp;       +-------+--------+

        &nbs= p;            &= nbsp;       | SFC Network    |=

        &nbs= p;            &= nbsp;       | Forwarder (NF) |

        &nbs= p;            &= nbsp;       +----------------+

        &nbs= p;            &= nbsp;           &nbs= p;   |

        &nbs= p;            &= nbsp;    Network Overlay Transport

        &nbs= p;            &= nbsp;            &nb= sp;  |

        &nbs= p;            &= nbsp;            _,.= ...._

        &nbs= p;            &= nbsp;         ,-'   =      `-.

        &nbs= p;            &= nbsp;        /    &n= bsp;         `.

        &nbs= p;            &= nbsp;       |     Network=     |

        &nbs= p;            &= nbsp;       `.     &= nbsp;       /

        &nbs= p;            &= nbsp;         `.__   = ;  _,-'

        &nbs= p;            &= nbsp;           &nbs= p; `''''

     

    I’ll send my other = response on your feedbacks in another email.

     <= /p>

    Regards,

    Lucy

     <= /p>

    From: Paul Qui= nn (paulq) [mailto:paulq@cisco.com]
    Sent: Thursday, May 15, 2014 8:51 AM
    To: Lucy yong
    Cc: Joel M. Halpern; sfc@ietf.org
    Subject: Re: Comments on RE: New Version Notification for draft-quin= n-sfc-arch-05.txt

     

    Lucy,

     

    Thank you for the comments, please see inline.<= /o:p>

     

    Paul

     

    On May 6, 2014, at 6:38 PM, Lucy yong <lucy.yong@huawei.com> wrote:



    Hi Paul and Joe,

     

    This version expends a lot. The writing is clear.

     

    Here are some comments and suggestions:

     

    ·         In introduction, statement "No IANA registry is required to = store the identity of SFs." Is it important or necessary to state this= ? If yes, why?

     

    PQ>  We are clarifying that there is no impl= ication of a SF registry.  

     

     



     

    ·         The term of "Service Node" is defined; but the doc. doe= s not describe its relationship to other architecture components specified = in section 4. Does it mean that a service node has to contain SF(s), SFF, NF or some of these components? For example, co= uld a SN only have a SF, i.e. not co-locate with SFF/NF? BTW, the service n= ode is barely used in text, which make hard to picture its roles.

     

    PQ>  All the components are logical, and the= refore and be combined as needed by an implementor.  You do raise a go= od point about a SN though.  I tend to think of it as an optimization = used for implementation, we’ll review how to present it in the draft.

     

     



     

    ·         Does the architecture allow that passing SFC encapsulated packets= between a SF and its associated SFF go through NF or not?

     

    PQ>  I don’t understand the question. =  Packets go NF <—> SFF <—> SF.

     

     



     

    ·         If the SFC architecture allows branching as described, it is good= to show a branching example in figure 1. BTW, the last sentence in sec. 2.= 2 should be moved to sec. 2.1 and state that is the third example in figure 1.

     

    PQ>  Figure 1 simply uses a linear depiction= of the path.  If it’s confusing one of the figure can be reorie= nted to explicitly depict branching.  Also, that sentence will be move= d, thanks for catching it.

     

     



     

    ·         Section 4 describes core SFC arch components. Classification is s= tated as a core SFC arch component and is a logical component, and "as= a consequence of the classification decision, the appropriate SFC encapsulation is imposed on the data prior to forwardi= ng along the SFP." However, is does not illustrate this component in f= igure 2, which makes unclear how this component relates to other component = in this figure or described in the text. Suggest illustrating this component in figure 2 and/or describe it in text= .

     

    PQ>  Do you have any suggested text and/or a= updates to the figure?

     

     



     

    ·         In Section 4.3, don't know why show SFF table here. Does that mea= n that all SFs in the table associate to the same SFF? The text and table i= s quite misleading. The SFP of SFC may result SFs on multiple SFFs. The table on each SFF only maintains the = SFs in a SFP associated to it.

     

    PQ>  This table is simply = a conceptual representation of how service forwarding is maintained at the = SFFs. SFID details, including which SFF they are associated with, could be maintained separately at each SFF. We do not want to impose how they ar= e implemented.

     

     

     

    ·         Statement about stateful SFF mixes with SFC proxy function. It sh= ould be distinct.

     

    PQ>  There is a dedicated “SFC Proxy&#= 8221; subsection, so it is a distinct (logical) component.

     

     



     

    ·         SFC architecture should work in multi-tenant environment where in= dividual tenant may use SFCs. Should we add some clarification on that?

     

     

    PQ>  That is a broad statement, there’= s nothing in this draft the precludes, or assumes for that matter, multi-te= nancy.  Are there specific areas you’d like to see addressed, or= sections added?

     

     



    ·         Does the SFC architecture impose some security consideration? Sta= tement in section 11 seems weak.

     

    PQ>  We will update this section.=

     



     

    ·         Overlay network and SFC network mean the same in this doc, is tha= t right? May be good to state out clearly or use one term through the doc.<= o:p>

     

     

    PQ>  Yes and no: the SFC network is an overl= ay but it introduces a new topology due to the service chain.

     

     

    Thanks

    Paul

     

    --_000_2691CE0099834E4A9C5044EEC662BB9D45378694dfweml701chmchi_-- From nobody Thu May 15 12:21:52 2014 Return-Path: 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 D0AA11A01F0 for ; Thu, 15 May 2014 12:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 xn8nmjYw7bP0 for ; Thu, 15 May 2014 12:21:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A24131A005A for ; Thu, 15 May 2014 12:21:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEE74380; Thu, 15 May 2014 19:21:33 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 May 2014 20:20:31 +0100 Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 May 2014 20:21:32 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml705-chm.china.huawei.com ([169.254.7.19]) with mapi id 14.03.0158.001; Thu, 15 May 2014 12:21:20 -0700 From: Lucy yong To: "Paul Quinn (paulq)" Thread-Topic: Comments on RE: New Version Notification for draft-quinn-sfc-arch-05.txt Thread-Index: AQHPaIfarkMZcB0ak0qMpN0Eo35H05s0D0DQgA39BYD///eFwA== Date: Thu, 15 May 2014 19:21:19 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D45378713@dfweml701-chm.china.huawei.com> References: <20140505173129.23329.89665.idtracker@ietfa.amsl.com> <5A389ED0-86BF-4F6B-A367-5C1512C9D589@cisco.com> <2691CE0099834E4A9C5044EEC662BB9D453757B4@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.134.113] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D45378713dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/mDVeTe3WCUbo15aur1_AcioEO40 Cc: "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Comments on RE: New Version Notification for draft-quinn-sfc-arch-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 19:21:47 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D45378713dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul and Joel, Thank you for the reply. Please see inline below. [snip] * In introduction, statement "No IANA registry is required to store= the identity of SFs." Is it important or necessary to state this? If yes, = why? PQ> We are clarifying that there is no implication of a SF registry. [Lucy] Yes. Why is this clarifying necessary? * The term of "Service Node" is defined; but the doc. does not desc= ribe its relationship to other architecture components specified in section= 4. Does it mean that a service node has to contain SF(s), SFF, NF or some = of these components? For example, could a SN only have a SF, i.e. not co-lo= cate with SFF/NF? BTW, the service node is barely used in text, which make = hard to picture its roles. PQ> All the components are logical, and therefore and be combined as neede= d by an implementor. You do raise a good point about a SN though. I tend = to think of it as an optimization used for implementation, we'll review how= to present it in the draft. [Lucy] Good. * Does the architecture allow that passing SFC encapsulated packets= between a SF and its associated SFF go through NF or not? PQ> I don't understand the question. Packets go NF <-> SFF <-> SF. [Lucy] * If the SFC architecture allows branching as described, it is good= to show a branching example in figure 1. BTW, the last sentence in sec. 2.= 2 should be moved to sec. 2.1 and state that is the third example in figure= 1. PQ> Figure 1 simply uses a linear depiction of the path. If it's confusin= g one of the figure can be reoriented to explicitly depict branching. Also= , that sentence will be moved, thanks for catching it. [Lucy] IMO: since branching is allowed in the arch and figure 1 gives sever= al SFC examples, it is better to show branching case as well. * Section 4 describes core SFC arch components. Classification is s= tated as a core SFC arch component and is a logical component, and "as a co= nsequence of the classification decision, the appropriate SFC encapsulation= is imposed on the data prior to forwarding along the SFP." However, is doe= s not illustrate this component in figure 2, which makes unclear how this c= omponent relates to other component in this figure or described in the text= . Suggest illustrating this component in figure 2 and/or describe it in tex= t. PQ> Do you have any suggested text and/or a updates to the figure? [Lucy] proposed in another mail. * In Section 4.3, don't know why show SFF table here. Does that mea= n that all SFs in the table associate to the same SFF? The text and table i= s quite misleading. The SFP of SFC may result SFs on multiple SFFs. The tab= le on each SFF only maintains the SFs in a SFP associated to it. PQ> This table is simply a conceptual representation of how service forwar= ding is maintained at the SFFs. SFID details, including which SFF they are = associated with, could be maintained separately at each SFF. We do not want= to impose how they are implemented. [Lucy] I see. Suggest "The SF columns of this table may come from different= SFFs." to be replaced by "The SFs in this table may be on same or differen= t SFFs". * Statement about stateful SFF mixes with SFC proxy function. It sh= ould be distinct. PQ> There is a dedicated "SFC Proxy" subsection, so it is a distinct (logi= cal) component. [Lucy] text: The SFF component has the following primary responsibilities: ... 3. Maintaining flow state: In some cases, the SFF may be stateful. It creates flows and stores flow-centric information. When traffic arrives after being steered through an SFC-unaware SF, the SFF must perform re-classification of traffic to determine the SFP. A state-full SFF simplifies such classification to a flow lookup. [Lucy] comment: if SFC proxy is used in b/w SFF and SFC-unaware SF, the SFF= can treat the SF as a SFC-aware SF, isn't it? Not sure why SFF must perfor= m re-classification as described in text. * SFC architecture should work in multi-tenant environment where in= dividual tenant may use SFCs. Should we add some clarification on that? PQ> That is a broad statement, there's nothing in this draft the precludes= , or assumes for that matter, multi-tenancy. Are there specific areas you'= d like to see addressed, or sections added? [Lucy] In DC, a SF may be used by several SFCs that may belong to different= tenant networks, is this valid use case? If yes, NF component need to main= tain the state about SFP/tenant network mapping, right? Suggest to add some= text in section 4.4 to cover that. * Does the SFC architecture impose some security consideration? Sta= tement in section 11 seems weak. PQ> We will update this section. [Lucy] Good. * Overlay network and SFC network mean the same in this doc, is tha= t right? May be good to state out clearly or use one term through the doc. PQ> Yes and no: the SFC network is an overlay but it introduces a new topo= logy due to the service chain. [Lucy] Agree. Maybe consider using "SFC network" through the doc, and state= about in SFC network definition. Thanks, Lucy Thanks Paul --_000_2691CE0099834E4A9C5044EEC662BB9D45378713dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Paul and Joel,

     <= /p>

    Thank you for the reply. = Please see inline below.

     <= /p>

    [snip]

    ·         In introduction, statement "No IANA registry is required to = store the identity of SFs." Is it important or necessary to state this= ? If yes, why?

     

    PQ>  We are clarifying that there is no impl= ication of a SF registry.  

    [Lucy] Yes. Why is = this clarifying necessary?

     

     

    ·         The term of "Service Node" is defined; but the doc. doe= s not describe its relationship to other architecture components specified = in section 4. Does it mean that a service node has to contain SF(s), SFF, NF or some of these components? For example, co= uld a SN only have a SF, i.e. not co-locate with SFF/NF? BTW, the service n= ode is barely used in text, which make hard to picture its roles.

     

    PQ>  All the components are logical, and the= refore and be combined as needed by an implementor.  You do raise a go= od point about a SN though.  I tend to think of it as an optimization = used for implementation, we’ll review how to present it in the draft.

    [Lucy] Good.

     

     



     

    ·         Does the architecture allow that passing SFC encapsulated packets= between a SF and its associated SFF go through NF or not?

     

    PQ>  I don’t understand the question. =  Packets go NF <—> SFF <—> SF.

    [Lucy]

     

     



     

    ·         If the SFC architecture allows branching as described, it is good= to show a branching example in figure 1. BTW, the last sentence in sec. 2.= 2 should be moved to sec. 2.1 and state that is the third example in figure 1.

     

    PQ>  Figure 1 simply uses a linear depiction= of the path.  If it’s confusing one of the figure can be reorie= nted to explicitly depict branching.  Also, that sentence will be move= d, thanks for catching it.

    [Lucy] IMO: since b= ranching is allowed in the arch and figure 1 gives several SFC examples, it= is better to show branching case as well.

     

     



     

    ·         Section 4 describes core SFC arch components. Classification is s= tated as a core SFC arch component and is a logical component, and "as= a consequence of the classification decision, the appropriate SFC encapsulation is imposed on the data prior to forwardi= ng along the SFP." However, is does not illustrate this component in f= igure 2, which makes unclear how this component relates to other component = in this figure or described in the text. Suggest illustrating this component in figure 2 and/or describe it in text= .

     

    PQ>  Do you have any suggested text and/or a= updates to the figure?

    [Lucy] proposed in = another mail.

     

     



     

    ·         In Section 4.3, don't know why show SFF table here. Does that mea= n that all SFs in the table associate to the same SFF? The text and table i= s quite misleading. The SFP of SFC may result SFs on multiple SFFs. The table on each SFF only maintains the = SFs in a SFP associated to it.

     

    PQ>  This table is simply = a conceptual representation of how service forwarding is maintained at the = SFFs. SFID details, including which SFF they are associated with, could be maintained separately at each SFF. We do not want to impose how they ar= e implemented.

    [Lucy] I see. Sugge= st “The SF columns of this table may come from different SFFs.”= to be replaced by “The SFs in this table may be on same or different SFFs”.

     <= /p>

     

     

     

    ·         Statement about stateful SFF mixes with SFC proxy function. It sh= ould be distinct.

     

    PQ>  There is a dedicated “SFC Proxy&#= 8221; subsection, so it is a distinct (logical) component.

    [Lucy] text:

       The SFF component has the following prim= ary responsibilities:

    …<= /b>

       3.  Mainta= ining flow state: In some cases, the SFF may be stateful.=

        &nbs= p;  It creates flows and stores flow-centric inform= ation.  When

      &nbs= p;    traffic arrives after being steered through an SFC-una= ware SF,

      &nbs= p;    the SFF must perform re-classification of traffic to d= etermine

      &nbs= p;    the SFP.  A state-full SFF simplifies such classi= fication to a

           flow look= up.


    [Lucy] comment: if SFC proxy is used in b/w SFF and SFC-unaware SF, t= he SFF can treat the SF as a SFC-aware SF, isn’t it? Not sure why SFF= must perform re-classification as described in text.

     

    ·         SFC architecture should work in multi-tenant environment where in= dividual tenant may use SFCs. Should we add some clarification on that?

     

     

    PQ>  That is a broad statement, there’= s nothing in this draft the precludes, or assumes for that matter, multi-te= nancy.  Are there specific areas you’d like to see addressed, or= sections added?

    [Lucy] In DC, a SF = may be used by several SFCs that may belong to different tenant networks, i= s this valid use case? If yes, NF component need to maintain the state about SFP/tenant network mapping, right? Suggest to add some tex= t in section 4.4 to cover that.

     

     



    ·         Does the SFC architecture impose some security consideration? Sta= tement in section 11 seems weak.

     

    PQ>  We will update this section.=

    [Lucy] Good.=

     



     

    ·         Overlay network and SFC network mean the same in this doc, is tha= t right? May be good to state out clearly or use one term through the doc.<= o:p>

     

     

    PQ>  Yes and no: the SFC network is an overl= ay but it introduces a new topology due to the service chain.

    [Lucy] Agree. Maybe= consider using “SFC network” through the doc, and state about = in SFC network definition.

     

    Thanks,<= /span>

    Lucy=

     

     

    Thanks

    Paul

     

    --_000_2691CE0099834E4A9C5044EEC662BB9D45378713dfweml701chmchi_-- From nobody Fri May 16 07:47:30 2014 Return-Path: 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 62B6F1A0255 for ; Fri, 16 May 2014 07:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 8dM2-lzyKXLs for ; Fri, 16 May 2014 07:47:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF511A028E for ; Fri, 16 May 2014 07:47:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEF48160; Fri, 16 May 2014 14:47:01 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 16 May 2014 15:46:18 +0100 Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 16 May 2014 15:46:59 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml703-chm.china.huawei.com ([169.254.5.104]) with mapi id 14.03.0158.001; Fri, 16 May 2014 07:46:42 -0700 From: Linda Dunbar To: "Paul Quinn (paulq)" , Lucy yong Thread-Topic: Comments on RE: New Version Notification for draft-quinn-sfc-arch-05.txt Thread-Index: AQHPaIfarkMZcB0ak0qMpN0Eo35H05s0D0DQgA39BYCAAU1AQA== Date: Fri, 16 May 2014 14:46:41 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D0AEAB@dfweml701-chm.china.huawei.com> References: <20140505173129.23329.89665.idtracker@ietfa.amsl.com> <5A389ED0-86BF-4F6B-A367-5C1512C9D589@cisco.com> <2691CE0099834E4A9C5044EEC662BB9D453757B4@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.197] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D0AEABdfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/pPKZpWmHBBnYm0nJ1C50GQ2Tak4 Cc: "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Comments on RE: New Version Notification for draft-quinn-sfc-arch-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 14:47:27 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645D0AEABdfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Paul, From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Section 4 describes core SFC arch components. Classification is stated as = a core SFC arch component and is a logical component, and "as a consequence= of the classification decision, the appropriate SFC encapsulation is impos= ed on the data prior to forwarding along the SFP." However, is does not ill= ustrate this component in figure 2, which makes unclear how this component = relates to other component in this figure or described in the text. Suggest= illustrating this component in figure 2 and/or describe it in text. PQ> Do you have any suggested text and/or a updates to the figure? [Linda] I suggest using this figure from http://datatracker.ietf.org/doc/dr= aft-dunbar-sfc-legacy-l4-l7-chain-architecture/ |1 ----- |n |21 ---- |2m +---+---+ +---+---+ +-+---+ +--+-----+ | SF#1 | |SF#n | |SF#i1| |SF#im | | | | | | | | | +---+---+ +---+---+ +--+--+ +--+--+--+ : : : : : : : : : : \ / \ / +--------------+ +--------+ +---------+ -- >| Chain | | SFF | ------ | SFF | ----> |classifier | |Node-1 | | Node-i | +--------------+ +----+---+ +----+--+-+ \ | / \ | SFC Encapsulation / \ | / ,. ......................................._ ,-' `-. / `. | Network | `. / `.__.................................. _,-' Linda --_000_4A95BA014132FF49AE685FAB4B9F17F645D0AEABdfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Paul,

     <= /p>

     <= /p>

    From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)

     Section 4 describes core SF= C arch components. Classification is stated as a core SFC arch component an= d is a logical component, and "as a consequence of the classification decision, the appropriate SFC encapsulation is impos= ed on the data prior to forwarding along the SFP." However, is does no= t illustrate this component in figure 2, which makes unclear how this compo= nent relates to other component in this figure or described in the text. Suggest illustrating this component in fi= gure 2 and/or describe it in text.

     

    PQ>  Do you have any suggested text and/or a= updates to the figure?

     <= /p>

    [Linda] I suggest using t= his figure from http://datatracker.ietf.org/doc/draft-dunbar-sfc-legacy-l4-l7-chain-archite= cture/

     <= /p>

     <= /p>

     

       &= nbsp;           &nbs= p;     |1  -----   |n   &= nbsp;    |21   ---- |2m

       &= nbsp;           &nbs= p; +---+---+   +---+---+   += ;-+---+   +--+-----+

       &= nbsp;           &nbs= p; | SF#1  |   |SF#n   |   |SF#i1|  = ; |SF#im   |

       &= nbsp;           &nbs= p; |       |   |   &= nbsp;   |   |     |   |&n= bsp;       |

       &= nbsp;           &nbs= p; +---+---+   +---+---+   += ;--+--+   +--+--+--+

       &= nbsp;           &nbs= p;     :        = ;   :          :&nbs= p;        :  :

       &= nbsp;           &nbs= p;     :        = ;   :          :&nbs= p;        :  :

       &= nbsp;           &nbs= p;     \       =   /            = \       /

        = +--------------+   +--------+   &n= bsp;         +---------+

    -- >| Chain = ;       |   | SFF   = |   ------    | SFF     | ---= ->

        = |classifier    |   |Node-1  |  &nbs= p;          | Node-i  |

        = +--------------+   +----+---+  &nbs= p;          +----+--&#= 43;-+

       &= nbsp;           &nbs= p;  \         |  &nb= sp;            =       / 

       &= nbsp;           &nbs= p;   \        | SFC Encap= sulation  /

       &= nbsp;           &nbs= p;    \       |  &nb= sp;            =     /

    ,. ......................................._<= /o:p>

    ,-'       &nbs= p;             =             &nb= sp;      `-.

    /        =             &nb= sp;            =              `.=

    |        =             &nb= sp; Network          &nbs= p;        |

    `.        = ;            &n= bsp;            = ;            /<= /o:p>

    `.__.................................. _,-'<= /o:p>

     <= /p>

     

     


    Linda

     

     

    --_000_4A95BA014132FF49AE685FAB4B9F17F645D0AEABdfweml701chmchi_-- From nobody Mon May 19 10:28:06 2014 Return-Path: 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 BC8E11A03A1 for ; Mon, 19 May 2014 10:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 j9KedPwew7kD for ; Mon, 19 May 2014 10:27:56 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A092F1A03BE for ; Mon, 19 May 2014 10:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3377; q=dns/txt; s=iport; t=1400520449; x=1401730049; h=from:to:subject:date:message-id:mime-version; bh=01IL8uKd2kByssOP8nNxvumVd+h+E4uRoaDR5Pwevmo=; b=VWi28X+Lx9M3Rb488KZIJLwPXs5XeaY1VoOD5hR9y/1pvf8JCcT3Dt/0 RHBgw0SRLGtUY600E1PdcH1pQ2tmgCjEkfAZb/ZxegQQrc/SxDphwtiyd ecTL4NkDKmeZHNtKbAuu6Q0DJ2Mq5wnfCKDAvEpHZx4tDeHPPW8djUtPg 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoIAEA+elOtJA2E/2dsb2JhbABZgkJEUVipUQEBAQEBAQUBgmWOR4oWFnSCLB1RHQEMdCcEiFQNnjWzYheFVY1CBJlagT2RXYM3gjA X-IronPort-AV: E=Sophos;i="4.98,868,1392163200"; d="scan'208,217";a="326093832" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-7.cisco.com with ESMTP; 19 May 2014 17:27:13 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s4JHRD1b032310 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 19 May 2014 17:27:13 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.6]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Mon, 19 May 2014 12:27:13 -0500 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: Call for WG adoption of draft-krishnan-sfc-long-lived-flow-use-cases-02 Thread-Index: AQHPc4eSykZPlflU0EC0wgJp+qFV4Q== Date: Mon, 19 May 2014 17:27:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.82.238.235] Content-Type: multipart/alternative; boundary="_000_CF9F96D920AD1jguicharciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/zcI0NnSD-VBLBz8UjoOzJv2K64w Subject: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived-flow-use-cases-02 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 17:27:59 -0000 --_000_CF9F96D920AD1jguicharciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Greetings WG: This message begins a two week call for WG adoption of draft-krishnan-sfc-l= ong-lived-flow-use-cases-02 [http://datatracker.ietf.org/doc/draft-krishnan= -sfc-long-lived-flow-use-cases/] ending June 2nd 2014. The draft highlights a number of use cases specific to long lived flows and= appears to compliment our already adopted use case documents. Please respo= nd to the SFC mailing list with any statements of approval or disapproval. As always, please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document=92s content until there is WG consensus that = the content is solid. Therefore, please don=92t oppose adoption just becaus= e you want to see changes to its content. 2. If you have objections to adoption of the document, please state your= reasons why, and explain what it would take to address your concerns. 3. If you have issues with the content, by all means raise those issues = and we can begin a dialog about how best to address them. --_000_CF9F96D920AD1jguicharciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
    Greetings WG:

    This message begins a two week call for WG adoption of draft-krishnan-= sfc-long-lived-flow-use-cases-02 [http://datatracker.ietf.or= g/doc/draft-krishnan-sfc-long-lived-flow-use-cases/] ending June 2nd 2014.

    The draft highlights a number of use cases specific to long lived flow= s and appears to compliment our already adopted use case documents. Please = respond to the SFC mailing list with any statements of approval or disappro= val.

    As always, please note:
    1. This is not WG Last Call. The document is not final, and the W= G is expected to modify the document=92s content until there is WG consensu= s that the content is solid. Therefore, please don=92t oppose adoption just because you want to see changes to its= content.
    2. If you have objections to adop= tion of the document, please state your reasons why, and explain what it wo= uld take to address your concerns.
    3. If yo= u have issues with the content, by all means raise those issues and we can = begin a dialog about how best to address them. 
    --_000_CF9F96D920AD1jguicharciscocom_-- From nobody Wed May 21 10:53:18 2014 Return-Path: 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 E3D081A07AE for ; Wed, 21 May 2014 10:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 Dh_8wy4IQPbu for ; Wed, 21 May 2014 10:53:10 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E12AD1A06CE for ; Wed, 21 May 2014 10:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4396; q=dns/txt; s=iport; t=1400694776; x=1401904376; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9/WTLAk5dJf/pTAzFzAjywcSzVZU7iHT6rlKjjIyDKI=; b=LVsYwb2vgryIpKuZT5UnI8ZSSmaWt1rz1CuUTfDh342OZWJ81vPybq/I 8mu033ZqFVqAW1YW05E30zu0/NDEwpdzntRSx6ps3AfdTaaYUN4UmoMnx tfk/PdnSrt4xNmpTespVoYvCepiCpGb94qErQ7suwrXu4e1NGjUHNYIgX Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUFAE3nfFOtJV2Q/2dsb2JhbABZgkJHUksNrFCOToFCAYc6AYEMFnSCJgEBBAEBARpRCxACAQgEOwcnCxQRAgQOBYhBDdY5F45OB4MrgRUEmW6BPZFngXiBQIIw X-IronPort-AV: E=Sophos; i="4.98,881,1392163200"; d="scan'208,217"; a="45932593" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-3.cisco.com with ESMTP; 21 May 2014 17:52:55 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s4LHqt7D022619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 21 May 2014 17:52:55 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Wed, 21 May 2014 12:52:55 -0500 From: "Paul Quinn (paulq)" To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived-flow-use-cases-02 Thread-Index: AQHPc4eSykZPlflU0EC0wgJp+qFV4ZtLp7YA Date: Wed, 21 May 2014 17:52:54 +0000 Message-ID: <343665D1-F90F-4457-BAC0-5BD598E71A12@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.231] Content-Type: multipart/alternative; boundary="_000_343665D1F90F4457BAC05BD598E71A12ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/4Zy1VRZoRFAHUvPT7qY5-96s7Tw Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived-flow-use-cases-02 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 17:53:13 -0000 --_000_343665D1F90F4457BAC05BD598E71A12ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Jim, I support the adoption of this draft. Paul On May 19, 2014, at 1:27 PM, Jim Guichard (jguichar) > wrote: Greetings WG: This message begins a two week call for WG adoption of draft-krishnan-sfc-l= ong-lived-flow-use-cases-02 [http://datatracker.ietf.org/doc/draft-krishnan= -sfc-long-lived-flow-use-cases/] ending June 2nd 2014. The draft highlights a number of use cases specific to long lived flows and= appears to compliment our already adopted use case documents. Please respo= nd to the SFC mailing list with any statements of approval or disapproval. As always, please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document=92s content until there is WG consensus that = the content is solid. Therefore, please don=92t oppose adoption just becaus= e you want to see changes to its content. 2. If you have objections to adoption of the document, please state your= reasons why, and explain what it would take to address your concerns. 3. If you have issues with the content, by all means raise those issues = and we can begin a dialog about how best to address them. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_343665D1F90F4457BAC05BD598E71A12ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <131612E79D0E344E9FE86CE0878FF35E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Jim,

    I support the adoption of this draft.

    Paul

    On May 19, 2014, at 1:27 PM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:

    Greetings WG:

    This message begins a two week call for WG adoption of draft-krishnan-= sfc-long-lived-flow-use-cases-02 [http://datatracker.ietf.or= g/doc/draft-krishnan-sfc-long-lived-flow-use-cases/] ending June 2nd 2014.

    The draft highlights a number of use cases specific to long lived flow= s and appears to compliment our already adopted use case documents. Please = respond to the SFC mailing list with any statements of approval or disappro= val.

    As always, please note:
    1. This is not WG Last Call. The document is not final, and the W= G is expected to modify the document=92s content until there is WG consensu= s that the content is solid. Therefore, please don=92t oppose adoption just because you want to see changes to its= content.
    2. If you have objections to adop= tion of the document, please state your reasons why, and explain what it wo= uld take to address your concerns.
    3. If yo= u have issues with the content, by all means raise those issues and we can = begin a dialog about how best to address them. 
    _______________________________________________
    sfc mailing list
    sfc@ietf.org
    https://www.ietf.org/mailman/listinfo/sfc

    --_000_343665D1F90F4457BAC05BD598E71A12ciscocom_-- From nobody Thu May 22 02:37:41 2014 Return-Path: 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 1402A1A004E for ; Thu, 22 May 2014 02:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 x9SeHgBmlat0 for ; Thu, 22 May 2014 02:37:37 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id EB5FF1A007E for ; Thu, 22 May 2014 02:37:36 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N5Y00K2GYQ1BH@tid.hi.inet> for sfc@ietf.org; Thu, 22 May 2014 11:37:32 +0200 (MEST) Received: from dequeue_removeroute (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 66.F9.03703.C55CD735; Thu, 22 May 2014 11:37:32 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N5Y00K5EYQKBH@tid.hi.inet> for sfc@ietf.org; Thu, 22 May 2014 11:37:32 +0200 (MEST) Received: from EX10-MB1-MAD.hi.inet ([169.254.1.173]) by EX10-HTCAS6-MAD.hi.inet ([::1]) with mapi id 14.03.0158.001; Thu, 22 May 2014 11:37:32 +0200 Date: Thu, 22 May 2014 09:37:55 +0000 From: "Diego R. Lopez" In-reply-to: X-Originating-IP: [10.95.64.115] To: "sfc@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_yoEPGF/Y2Yk+RSxYZNggzA)" Content-language: en-US Accept-Language: en-US, es-ES Thread-topic: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived-flow-use-cases-02 Thread-index: AQHPc4eSykZPlflU0EC0wgJp+qFV4ZtMOlOA X-AuditID: 0a5f4068-f79636d000000e77-99-537dc55c1607 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsXCFe/ApRtztDbY4GGTgsWTB1vZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcW7tQpaCHcYVC6bvZm1gPKzTxcjJISFgIrHy5ldmCFtM4sK9 9WxdjFwcQgIHGSU+L7/CDOF8Y5S4d2YKlDOTUWLT37dgLSwCqhJfJl5nBbHZgOxHzb/ZQWxh gRiJH+/7WUBsTgEDifenp0GtUJD4c+4xWFxEQFHi3MsJQDYHB6+ApcTUn1ogYV4BQYkfk++B lTALREusvNTPCmGLSzS33gSLMwrISrybP58VYkysxMHz/5khbCOJC3dvsUCsEpBYsuc81FpR iZeP/4HVCwnoS0w/d4xlAqPoLCTrZiFZNwvJOggb6INz85khbG2JZQtfQ9n6Ehu/nGWEsM0k fjw/wISsZgEjxypGseKkosz0jJLcxMycdANDvYxMvcy81JJNjJC4y9jBuHynyiFGAQ5GJR7e B9dqgoVYE8uKK3MPMUpwMCuJ8AYdrg0W4k1JrKxKLcqPLyrNSS0+xCjNwaIkzhv3uihASCA9 sSQ1OzW1ILUIJsvEwSnVwLhYRvLqeq4tr5/sb92YF8vzg9WsYNamF7c/uDkf2nXPYlaISt7W N49ua/YfTi60mGOrIfB297pDF5i6yy8++lRzImbORMemJgeFou6ZjNF/A8pypH9+V5p3rdJs mt2Kullhp9+H8xYe/DrBpvBD73yhSZt0E0WrW9dGT+Vd0P/cYsnUW88LNZcrsRRnJBpqMRcV JwIA6LvXaLcCAAA= References: Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/_Ngk6xCOMDU55S5YfEQ8AF89KVQ Subject: Re: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived-flow-use-cases-02 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 09:37:40 -0000 --Boundary_(ID_yoEPGF/Y2Yk+RSxYZNggzA) Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: quoted-printable As co-author, I support the adoption, as you could expect... Be goode, On 19 May 2014, at 19:27 , Jim Guichard (jguichar) > wrote: Greetings WG: This message begins a two week call for WG adoption of draft-krishnan-sfc-l= ong-lived-flow-use-cases-02 [http://datatracker.ietf.org/doc/draft-krishnan= -sfc-long-lived-flow-use-cases/] ending June 2nd 2014. The draft highlights a number of use cases specific to long lived flows and= appears to compliment our already adopted use case documents. Please respo= nd to the SFC mailing list with any statements of approval or disapproval. As always, please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document=92s content until there is WG consensus that = the content is solid. Therefore, please don=92t oppose adoption just becaus= e you want to see changes to its content. 2. If you have objections to adoption of the document, please state your= reasons why, and explain what it would take to address your concerns. 3. If you have issues with the content, by all means raise those issues = and we can begin a dialog about how best to address them. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_yoEPGF/Y2Yk+RSxYZNggzA) Content-id: <7676D6875D321E428B40C60DC4DDCF7F@hi.inet> Content-type: text/html; charset=Windows-1252 Content-transfer-encoding: quoted-printable As co-author, I support the adoption, as you could expect...

    Be goode,

    On 19 May 2014, at 19:27 , Jim Guichard (jguichar) <jguichar@cisco.com> wrote:

    Greetings WG:

    This message begins a two week call for WG adoption of draft-krishnan-= sfc-long-lived-flow-use-cases-02 [http://datatracker.ietf.or= g/doc/draft-krishnan-sfc-long-lived-flow-use-cases/] ending June 2nd 2014.

    The draft highlights a number of use cases specific to long lived flow= s and appears to compliment our already adopted use case documents. Please = respond to the SFC mailing list with any statements of approval or disappro= val.

    As always, please note:
    1. This is not WG Last Call. The document is not final, and the WG is= expected to modify the document=92s content until there is WG consensus th= at the content is solid. Therefore, please don=92t oppose adoption just because you want to see changes to its conten= t.
    2. If you have objections to adoption of the document, = please state your reasons why, and explain what it would take to address yo= ur concerns.
    3. If you have issues with the content, by al= l means raise those issues and we can begin a dialog about how best to addr= ess them. 
    _______________________________________________
    sfc mailing list
    sfc@ietf.org
    https://www.ietf.org/mailman/listinfo/sfc


    --
    "Esta vez no fallaremos, Doctor Infierno"

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

    e-mail: diego@tid.es
    Tel:    +34 913 129 041
    Mobile: +34 682 051 091
    -----------------------------------------



    Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo.
    This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
    http://www.tid.es/ES/PAGINAS/disclaimer.aspx
     --Boundary_(ID_yoEPGF/Y2Yk+RSxYZNggzA)-- From nobody Thu May 22 12:09:22 2014 Return-Path: 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 B801D1A0158 for ; Thu, 22 May 2014 12:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 oJKy8zHxFLRt for ; Thu, 22 May 2014 12:09:18 -0700 (PDT) Received: from smtp1.riverbed.com (smtp1.riverbed.com [208.70.196.45]) by ietfa.amsl.com (Postfix) with ESMTP id 93C231A0276 for ; Thu, 22 May 2014 12:09:18 -0700 (PDT) Received: from unknown (HELO 365EXCH-HUB-P3.nbttech.com) ([10.16.4.1]) by smtp1.riverbed.com with ESMTP; 22 May 2014 12:09:17 -0700 Received: from SFO1EXC-MBXP06.nbttech.com ([fe80::14e0:71aa:8def:2df5]) by 365EXCH-HUB-P3.nbttech.com ([::1]) with mapi id 14.02.0328.009; Thu, 22 May 2014 12:09:17 -0700 From: Kevin Glavin To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived-flow-use-cases-02 Thread-Index: AQHPdfFTykZPlflU0EC0wgJp+qFV4Q== Date: Thu, 22 May 2014 19:09:17 +0000 Message-ID: <9EA32E60D7600C43B6FE22876DF564C8496A95AE@SFO1EXC-MBXP06.nbttech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.205.254] Content-Type: multipart/alternative; boundary="_000_9EA32E60D7600C43B6FE22876DF564C8496A95AESFO1EXCMBXP06nb_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/kkLRAEn19e4e52figtUDjLv9EBM Subject: Re: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived-flow-use-cases-02 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 19:09:20 -0000 --_000_9EA32E60D7600C43B6FE22876DF564C8496A95AESFO1EXCMBXP06nb_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I support adaption of this draft. Kevin From: "Jim Guichard (jguichar)" > Date: Monday, May 19, 2014 10:27 AM To: "sfc@ietf.org" > Subject: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived-flow-u= se-cases-02 Greetings WG: This message begins a two week call for WG adoption of draft-krishnan-sfc-l= ong-lived-flow-use-cases-02 [http://datatracker.ietf.org/doc/draft-krishnan= -sfc-long-lived-flow-use-cases/] ending June 2nd 2014. The draft highlights a number of use cases specific to long lived flows and= appears to compliment our already adopted use case documents. Please respo= nd to the SFC mailing list with any statements of approval or disapproval. As always, please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document=92s content until there is WG consensus that = the content is solid. Therefore, please don=92t oppose adoption just becaus= e you want to see changes to its content. 2. If you have objections to adoption of the document, please state your= reasons why, and explain what it would take to address your concerns. 3. If you have issues with the content, by all means raise those issues = and we can begin a dialog about how best to address them. --_000_9EA32E60D7600C43B6FE22876DF564C8496A95AESFO1EXCMBXP06nb_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9E9CC93153FCF04B8E98DE87EBA67EFF@riverbed.com> Content-Transfer-Encoding: quoted-printable
    I support adaption of this draft. 

    Kevin


    From: "Jim Guichard (jguichar)= " <jguichar@cisco.com>=
    Date: Monday, May 19, 2014 10:27 AM=
    To: "sfc@ietf.org" <sfc@ietf.= org>
    Subject: [sfc] Call for WG adoption= of draft-krishnan-sfc-long-lived-flow-use-cases-02

    Greetings WG:

    This message begins a two week call for WG adoption of draft-krishnan-= sfc-long-lived-flow-use-cases-02 [http://datatracker.ietf.or= g/doc/draft-krishnan-sfc-long-lived-flow-use-cases/] ending June 2nd 2014.

    The draft highlights a number of use cases specific to long lived flow= s and appears to compliment our already adopted use case documents. Please = respond to the SFC mailing list with any statements of approval or disappro= val.

    As always, please note:
    1. This is not WG Last Call. The document is not final, and the = WG is expected to modify the document=92s content until there is WG consens= us that the content is solid. Therefore, please don=92t oppose adoption just because you want to see changes to its= content.
    2. If you have objections to ado= ption of the document, please state your reasons why, and explain what it w= ould take to address your concerns.
    3. If = you have issues with the content, by all means raise those issues and we ca= n begin a dialog about how best to address them. 
    --_000_9EA32E60D7600C43B6FE22876DF564C8496A95AESFO1EXCMBXP06nb_-- From nobody Thu May 22 17:00:45 2014 Return-Path: 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 D4A1F1A02A3 for ; Thu, 22 May 2014 17:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 So5qgSwwLnKx for ; Thu, 22 May 2014 17:00:40 -0700 (PDT) Received: from mailout01.vodafone.com (mailout01.vodafone.com [195.232.224.70]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ED381A0295 for ; Thu, 22 May 2014 17:00:39 -0700 (PDT) Received: from mailint01.vodafone.com (localhost [127.0.0.1]) by mailout01.vodafone.com (Postfix) with ESMTP id 031282E1F02 for ; Fri, 23 May 2014 02:00:35 +0200 (CEST) Received: from VOEXC05W.internal.vodafone.com (voexc05w.dc-ratingen.de [145.230.101.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint01.vodafone.com (Postfix) with ESMTPS id E8FE22E082B; Fri, 23 May 2014 02:00:34 +0200 (CEST) Received: from AVOEXH03W.internal.vodafone.com (145.230.15.141) by VOEXC05W.internal.vodafone.com (145.230.101.25) with Microsoft SMTP Server (TLS) id 14.3.146.2; Fri, 23 May 2014 02:00:34 +0200 Received: from VOEXM19W.internal.vodafone.com ([169.254.3.34]) by AVOEXH03W.internal.vodafone.com ([145.230.15.141]) with mapi id 14.03.0181.006; Fri, 23 May 2014 02:00:34 +0200 From: "Haeffner, Walter, Vodafone DE" To: Kevin Glavin , Jim Guichard , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived-flow-use-cases-02 Thread-Index: AQHPdfFTykZPlflU0EC0wgJp+qFV4ZtNSCa6 Date: Fri, 23 May 2014 00:00:32 +0000 Message-ID: References: <9EA32E60D7600C43B6FE22876DF564C8496A95AE@SFO1EXC-MBXP06.nbttech.com> In-Reply-To: <9EA32E60D7600C43B6FE22876DF564C8496A95AE@SFO1EXC-MBXP06.nbttech.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_C8C844F84E550E43865561FAE10471853EA3C403VOEXM19Winterna_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/-TPOpjhC9gTOokhU6jEf1AvPu8A Subject: Re: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived-flow-use-cases-02 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 00:00:43 -0000 --_000_C8C844F84E550E43865561FAE10471853EA3C403VOEXM19Winterna_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Also support this draft - Walter Gesendet mit meinem HTC ----- Reply message ----- Von: "Kevin Glavin" An: "Jim Guichard (jguichar)" , "sfc@ietf.org" Betreff: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived-flow-u= se-cases-02 Datum: Do., Mai 22, 2014 21:09 I support adaption of this draft. Kevin From: "Jim Guichard (jguichar)" > Date: Monday, May 19, 2014 10:27 AM To: "sfc@ietf.org" > Subject: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived-flow-u= se-cases-02 Greetings WG: This message begins a two week call for WG adoption of draft-krishnan-sfc-l= ong-lived-flow-use-cases-02 [http://datatracker.ietf.org/doc/draft-krishnan= -sfc-long-lived-flow-use-cases/] ending June 2nd 2014. The draft highlights a number of use cases specific to long lived flows and= appears to compliment our already adopted use case documents. Please respo= nd to the SFC mailing list with any statements of approval or disapproval. As always, please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document=92s content until there is WG consensus that = the content is solid. Therefore, please don=92t oppose adoption just becaus= e you want to see changes to its content. 2. If you have objections to adoption of the document, please state your= reasons why, and explain what it would take to address your concerns. 3. If you have issues with the content, by all means raise those issues = and we can begin a dialog about how best to address them. --_000_C8C844F84E550E43865561FAE10471853EA3C403VOEXM19Winterna_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
    Also support this draft - Walter

    Gesendet mit meinem HTC

    ----- Reply message -----
    Von: "Kevin Glavin" <Kevin.Glavin@riverbed.com>
    An: "Jim Guichard (jguichar)" <jguichar@cisco.com>, "s= fc@ietf.org" <sfc@ietf.org>
    Betreff: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived-flow-u= se-cases-02
    Datum: Do., Mai 22, 2014 21:09

    I support adaption of this draft. 

    Kevin


    From: "Jim Guichard (jguichar)= " <jguichar@cisco.com>=
    Date: Monday, May 19, 2014 10:27 AM=
    To: "sfc@ietf.org" <sfc@ietf.= org>
    Subject: [sfc] Call for WG adoption= of draft-krishnan-sfc-long-lived-flow-use-cases-02

    Greetings WG:

    This message begins a two week call for WG adoption of draft-krishnan-= sfc-long-lived-flow-use-cases-02 [http://datatracker.ietf.or= g/doc/draft-krishnan-sfc-long-lived-flow-use-cases/] ending June 2nd 2014.

    The draft highlights a number of use cases specific to long lived flow= s and appears to compliment our already adopted use case documents. Please = respond to the SFC mailing list with any statements of approval or disappro= val.

    As always, please note:
    1. This is not WG Last Call. The document is not final, and the WG is= expected to modify the document=92s content until there is WG consensus th= at the content is solid. Therefore, please don=92t oppose adoption just because you want to see changes to its conten= t.
    2. If you have objections to adoption of the document, = please state your reasons why, and explain what it would take to address yo= ur concerns.
    3. If you have issues with the content, by al= l means raise those issues and we can begin a dialog about how best to addr= ess them. 
    --_000_C8C844F84E550E43865561FAE10471853EA3C403VOEXM19Winterna_-- From nobody Mon May 26 01:43:28 2014 Return-Path: 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 9D6291A0069 for ; Mon, 26 May 2014 01:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 ROiIQo_A33hn for ; Mon, 26 May 2014 01:43:24 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C23061A0053 for ; Mon, 26 May 2014 01:43:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5071; q=dns/txt; s=iport; t=1401093801; x=1402303401; h=from:to:subject:date:message-id:mime-version; bh=eSqdiKJJKaNa1GVgQZ/8c5fWrgd5yaU/DidlF0Jriz0=; b=AO1LCayqLejU+sCWgrjaaz9Nc9zgcVGPEYGd8q3Jj389Lty24aa382Tx bESS0GsRe70JiH3kwbSXn3gdjuKH6GenC6OEJUo2MMboQcJDlAFV7GKqt 1XoqbyXBBadjhjyDbM4yWNcTyhh1ED4utEbAnD+CQF7czXubU3mkJ/irS Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcFAPD9glOtJA2J/2dsb2JhbABZgkJFUlisa4wniHyBDxZ0giUBAgQdUR0BCAQNAwECKDkUCQoEARKIQg3XIheOQR6EOgSZc4E9kWqBeIFAgi8 X-IronPort-AV: E=Sophos;i="4.98,911,1392163200"; d="scan'208,217";a="327936531" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-6.cisco.com with ESMTP; 26 May 2014 08:43:20 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s4Q8hKJZ011191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 26 May 2014 08:43:20 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.180]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Mon, 26 May 2014 03:43:20 -0500 From: "Jeffrey Napper (jenapper)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived-flow-use-cases-02 Thread-Index: AQHPeL6Lk1Qmv9Zq6ku4JGLaPhHsXw== Date: Mon, 26 May 2014 08:43:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.198.157] Content-Type: multipart/alternative; boundary="_000_CFA8CB27178F2jenapperciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/-preP4bPTUd8ZWe_vHLvZAAHVEo Subject: Re: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived-flow-use-cases-02 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 08:43:26 -0000 --_000_CFA8CB27178F2jenapperciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I support adoption of this draft. I think it provides a use case with disti= nct needs. Cheers, Jeff From: "Jim Guichard (jguichar)" > Date: Monday, May 19, 2014 at 7:27 PM To: "sfc@ietf.org" > Subject: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived-flow-u= se-cases-02 Greetings WG: This message begins a two week call for WG adoption of draft-krishnan-sfc-l= ong-lived-flow-use-cases-02 [http://datatracker.ietf.org/doc/draft-krishnan= -sfc-long-lived-flow-use-cases/] ending June 2nd 2014. The draft highlights a number of use cases specific to long lived flows and= appears to compliment our already adopted use case documents. Please respo= nd to the SFC mailing list with any statements of approval or disapproval. As always, please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document=92s content until there is WG consensus that = the content is solid. Therefore, please don=92t oppose adoption just becaus= e you want to see changes to its content. 2. If you have objections to adoption of the document, please state your= reasons why, and explain what it would take to address your concerns. 3. If you have issues with the content, by all means raise those issues = and we can begin a dialog about how best to address them. --_000_CFA8CB27178F2jenapperciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
    I support adoption of this draft. I think it provides a use case with = distinct needs.

    Cheers,
    Jeff

    From: "Jim Guichard (jguichar)= " <jguichar@cisco.com>=
    Date: Monday, May 19, 2014 at 7:27 = PM
    To: "sfc@ietf.org" <sfc@ietf.= org>
    Subject: [sfc] Call for WG adoption= of draft-krishnan-sfc-long-lived-flow-use-cases-02

    Greetings WG:

    This message begins a two week call for WG adoption of draft-krishnan-= sfc-long-lived-flow-use-cases-02 [http://datatracker.ietf.or= g/doc/draft-krishnan-sfc-long-lived-flow-use-cases/] ending June 2nd 2014.

    The draft highlights a number of use cases specific to long lived flow= s and appears to compliment our already adopted use case documents. Please = respond to the SFC mailing list with any statements of approval or disappro= val.

    As always, please note:
    1. This is not WG Last Call. The document is not final, and the W= G is expected to modify the document=92s content until there is WG consensu= s that the content is solid. Therefore, please don=92t oppose adoption just because you want to see changes to its= content.
    2. If you have objections to adop= tion of the document, please state your reasons why, and explain what it wo= uld take to address your concerns.
    3. If yo= u have issues with the content, by all means raise those issues and we can = begin a dialog about how best to address them. 
    --_000_CFA8CB27178F2jenapperciscocom_-- From nobody Wed May 28 02:33:16 2014 Return-Path: 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 EDB131A0897 for ; Wed, 28 May 2014 02:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 3xTkrEbuwAkI for ; Wed, 28 May 2014 02:33:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6525B1A0041 for ; Wed, 28 May 2014 02:33:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHI01641; Wed, 28 May 2014 09:33:07 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 May 2014 10:32:33 +0100 Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 May 2014 10:33:04 +0100 Received: from SZXEMA509-MBX.china.huawei.com ([169.254.1.216]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Wed, 28 May 2014 17:33:01 +0800 From: "Hongyu Li (Julio)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-liu-sfc-use-cases-06.txt Thread-Index: AQHPek4McHl2dDc5XkWdgAgYCFGA55tVuezg Date: Wed, 28 May 2014 09:33:00 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97EA2236E@SZXEMA509-MBX.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.114.234] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/XJrKbE-VC8LVaEKDpSX3YSuyiaI Subject: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-06.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 09:33:15 -0000 SGkgYWxsLA0KDQpJbiB0aGUgcmV2aXNpb24sIHdlIGhhdmUgYWRkZWQgYSBuZXcgdXNlIGNhc2Us IGluIHdoaWNoIGEgU0ZDIG5ldHdvcmsgcHJvdmlkZXMgc2VydmljZSBjaGFpbmluZyB0byBib3Ro IG1vYmlsZSBhbmQgZml4ZWQgYnJvYWRiYW5kIG5ldHdvcmtzLiBUaGlzIGlzIGEgdHlwaWNhbCBj YXNlIHRoYXQgaXMgY292ZXJpbmcgZGlmZmVyZW50IG5ldHdvcmsgdHlwZXMuDQoNCkNvbW1lbnRz IGFyZSB3ZWxjb21lLg0KDQpDaGVlcnMsDQpIb25neXUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBXZWRuZXNkYXksIE1heSAyOCwgMjAxNCA0OjIzIFBNDQpU bzogUWlvbmcgU3VuOyBKaWFmZW5nIFpodTsgQ2hhbmdjaGVuZyBIdWFuZzsgTmljb2xhaSBMZXlt YW5uOyBIb25neXUgTGkgKEp1bGlvKTsgTGl1c2h1Y2hlbmcgKFdpbGwpOyBRaW9uZyBTdW47IFBl bmcgSGU7IENoYW5nY2hlbmcgSHVhbmc7IE1vaGFtZWQgQm91Y2FkYWlyOyBaaGVuIENhbzsgTmlj b2xhaSBMZXltYW5uOyBIdWFuZ3lvbmcgKE9saXZlcik7IE1vaGFtZWQgQm91Y2FkYWlyOyBQZW5n IEhlOyBDaHVvbmcgUGhhbTsgWmhlbiBDYW87IEppYWZlbmcgWmh1OyBMaXVzaHVjaGVuZyAoV2ls bCk7IEhvbmd5dSBMaSAoSnVsaW8pOyBDaHVvbmcgUGhhbTsgSHVhbmd5b25nIChPbGl2ZXIpDQpT dWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpdS1zZmMtdXNlLWNh c2VzLTA2LnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1saXUtc2ZjLXVzZS1j YXNlcy0wNi50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBXaWxsKFNodWNo ZW5nKSBMaXUgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJh ZnQtbGl1LXNmYy11c2UtY2FzZXMNClJldmlzaW9uOgkwNg0KVGl0bGU6CQlTZXJ2aWNlIEZ1bmN0 aW9uIENoYWluaW5nIChTRkMpIFVzZSBDYXNlcw0KRG9jdW1lbnQgZGF0ZToJMjAxNC0wNS0yNg0K R3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMjINClVSTDogICAgICAgICAg ICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1saXUtc2ZjLXVzZS1j YXNlcy0wNi50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1saXUtc2ZjLXVzZS1jYXNlcy8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saXUtc2ZjLXVzZS1jYXNlcy0wNg0KRGlmZjogICAgICAg ICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWxpdS1zZmMtdXNlLWNh c2VzLTA2DQoNCkFic3RyYWN0Og0KICAgVGhlIGRlbGl2ZXJ5IG9mIHZhbHVlLWFkZGVkIHNlcnZp Y2VzIHJlbGllcyBvbiB0aGUgaW52b2NhdGlvbiBvZg0KICAgYWR2YW5jZWQgU2VydmljZSBGdW5j dGlvbnMgaW4gYSBzZXF1ZW50aWFsIG9yZGVyLiAgVGhpcyBtZWNoYW5pc20gaXMNCiAgIGNhbGxl ZCBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIChTRkMpLiAgVGhlIHNldCBvZiBpbnZvbHZlZCBT ZXJ2aWNlDQogICBGdW5jdGlvbnMgYW5kIHRoZWlyIG9yZGVyIGRlcGVuZHMgb24gdGhlIHNlcnZp Y2UgY29udGV4dC4NCg0KICAgVGhpcyBkb2N1bWVudCBwcmVzZW50cyBhIHNldCBvZiB1c2UgY2Fz ZXMgb2YgU2VydmljZSBGdW5jdGlvbg0KICAgQ2hhaW5pbmcgKFNGQykuDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXpl ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRo ZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Wed May 28 05:54:07 2014 Return-Path: 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 23F981A0383 for ; Wed, 28 May 2014 05:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 oh9loGOSoCtM for ; Wed, 28 May 2014 05:54:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8215E1A037D for ; Wed, 28 May 2014 05:54:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHI22361; Wed, 28 May 2014 12:53:57 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 May 2014 13:53:25 +0100 Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 May 2014 13:53:56 +0100 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.3]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Wed, 28 May 2014 20:53:53 +0800 From: "Liushucheng (Will)" To: "sfc@ietf.org" Thread-Topic: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-06.txt Thread-Index: AQHPek4McHl2dDc5XkWdgAgYCFGA55tVuezggAA4dAA= Date: Wed, 28 May 2014 12:53:53 +0000 Message-ID: References: <6EB34CB5D82C4645B826C56144826EA97EA2236E@SZXEMA509-MBX.china.huawei.com> In-Reply-To: <6EB34CB5D82C4645B826C56144826EA97EA2236E@SZXEMA509-MBX.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.65.177] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/F2I36y3KJuIhrDtAC8ENs996tqA Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-06.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 12:54:05 -0000 Hi all, Besides, we've also added two pointers in the ends of sections of mobile an= d DC, referring to the two WG drafts. Cheers, Will > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Hongyu Li (Julio) > Sent: Wednesday, May 28, 2014 5:33 PM > To: sfc@ietf.org > Subject: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-0= 6.txt >=20 > Hi all, >=20 > In the revision, we have added a new use case, in which a SFC network pro= vides > service chaining to both mobile and fixed broadband networks. This is a t= ypical > case that is covering different network types. >=20 > Comments are welcome. >=20 > Cheers, > Hongyu >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, May 28, 2014 4:23 PM > To: Qiong Sun; Jiafeng Zhu; Changcheng Huang; Nicolai Leymann; Hongyu Li > (Julio); Liushucheng (Will); Qiong Sun; Peng He; Changcheng Huang; Mohame= d > Boucadair; Zhen Cao; Nicolai Leymann; Huangyong (Oliver); Mohamed > Boucadair; Peng He; Chuong Pham; Zhen Cao; Jiafeng Zhu; Liushucheng (Will= ); > Hongyu Li (Julio); Chuong Pham; Huangyong (Oliver) > Subject: New Version Notification for draft-liu-sfc-use-cases-06.txt >=20 >=20 > A new version of I-D, draft-liu-sfc-use-cases-06.txt has been successfull= y > submitted by Will(Shucheng) Liu and posted to the IETF repository. >=20 > Name: draft-liu-sfc-use-cases > Revision: 06 > Title: Service Function Chaining (SFC) Use Cases > Document date: 2014-05-26 > Group: Individual Submission > Pages: 22 > URL: > http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-06.txt > Status: https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/ > Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-06 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-case= s-06 >=20 > Abstract: > The delivery of value-added services relies on the invocation of > advanced Service Functions in a sequential order. This mechanism is > called Service Function Chaining (SFC). The set of involved Service > Functions and their order depends on the service context. >=20 > This document presents a set of use cases of Service Function > Chaining (SFC). >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed May 28 07:58:33 2014 Return-Path: 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 A2E131A0153 for ; Wed, 28 May 2014 07:58:32 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 OWJgptEcNi6O for ; Wed, 28 May 2014 07:58:31 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57AE71A035B for ; Wed, 28 May 2014 07:58:29 -0700 (PDT) Received: from pps.filterd (m0048193 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s4SE5QNa013581; Wed, 28 May 2014 07:58:24 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1m440vgp8m-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 May 2014 07:58:24 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 28 May 2014 07:58:23 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::a540:dc22:25c4:398e]) by HQ1WP-EXHUB01.corp.brocade.com ([fe80::55ee:533:4b9d:a097%12]) with mapi; Wed, 28 May 2014 07:58:23 -0700 From: ramki Krishnan To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Date: Wed, 28 May 2014 07:58:24 -0700 Thread-Topic: Call for WG adoption of draft-krishnan-sfc-long-lived-flow-use-cases-02 Thread-Index: AQHPc4eSykZPlflU0EC0wgJp+qFV4ZtWI2bg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2C00500579CHQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-05-28_04:2014-05-28,2014-05-28,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1405280182 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/9m8dOtFO3oY-VPlg_78ZC6uVVlQ Subject: Re: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived-flow-use-cases-02 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 14:58:32 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2C00500579CHQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support as co-author. Thanks, Ramki From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, May 19, 2014 10:27 AM To: sfc@ietf.org Subject: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived-flow-u= se-cases-02 Greetings WG: This message begins a two week call for WG adoption of draft-krishnan-sfc-l= ong-lived-flow-use-cases-02 [http://datatracker.ietf.org/doc/draft-krishnan= -sfc-long-lived-flow-use-cases/] ending June 2nd 2014. The draft highlights a number of use cases specific to long lived flows and= appears to compliment our already adopted use case documents. Please respo= nd to the SFC mailing list with any statements of approval or disapproval. As always, please note: 1. This is not WG Last Call. The document is not final, and the WG is exp= ected to modify the document's content until there is WG consensus that the= content is solid. Therefore, please don't oppose adoption just because you= want to see changes to its content. 2. If you have objections to adoption of the document, please state your = reasons why, and explain what it would take to address your concerns. 3. If you have issues with the content, by all means raise those issues a= nd we can begin a dialog about how best to address them. --_000_C7634EB63EFD984A978DFB46EA5174F2C00500579CHQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Support a= s co-author.

     

    Thanks,

    Ramki

     

    From:= sfc= [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)<= br>Sent: Monday, May 19, 2014 10:27 AM
    To: sfc@ietf.orgSubject: [sfc] Call for WG adoption of draft-krishnan-sfc-long-live= d-flow-use-cases-02

    <= o:p> 

    Greetings WG:=

     

    This message begins a two week call f= or WG adoption of draft-krishnan-sfc-long-lived-flow-use-cases-02 [http://datatracker.ietf.org/doc/draft-krishnan-sfc-long-lived-flow-= use-cases/] ending June 2nd 2014.

     

    The draft highlights a number of use cases specific to long live= d flows and appears to compliment our already adopted use case documents. P= lease respond to the SFC mailing list with any statements of approval or di= sapproval.

    &= nbsp;

    As always, pleas= e note:

    1. This is not WG Last Call. The document is not final, an= d the WG is expected to modify the document’s content until there is = WG consensus that the content is solid. Therefore, please don’t oppos= e adoption just because you want to see changes to its content.<= /span>
    2. If you have objections to a= doption of the document, please state your reasons why, and explain what it= would take to address your concerns.
    3. If you have issues with the content, by all means rai= se those issues and we can begin a dialog about how best to address them.&n= bsp;
    = --_000_C7634EB63EFD984A978DFB46EA5174F2C00500579CHQ1EXCH01corp_-- From nobody Wed May 28 12:22:35 2014 Return-Path: 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 5B1DB1A0225 for ; Wed, 28 May 2014 12:22:30 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 UcTCihdnc_us for ; Wed, 28 May 2014 12:22:26 -0700 (PDT) Received: from hub021-ca-4.exch021.serverdata.net (hub021-ca-4.exch021.serverdata.net [64.78.22.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D64271A0643 for ; Wed, 28 May 2014 12:22:26 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.03.0174.001; Wed, 28 May 2014 12:22:23 -0700 From: Ron Parker To: ramki Krishnan , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: Call for WG adoption of draft-krishnan-sfc-long-lived-flow-use-cases-02 Thread-Index: AQHPc4eSykZPlflU0EC0wgJp+qFV4ZtWI2bggABJicA= Date: Wed, 28 May 2014 19:22:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A83570AMBX021W3CA2exch_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/PEtTWh4dCkrT0urDm4f53HD8OUc Subject: Re: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived-flow-use-cases-02 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 19:22:30 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A83570AMBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support adoption of this draft by the SFC WG. It is very well written a= nd provides excellent use cases that further the value of an SFC approach. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of ramki Krishnan Sent: Wednesday, May 28, 2014 10:58 AM To: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived-fl= ow-use-cases-02 Support as co-author. Thanks, Ramki From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, May 19, 2014 10:27 AM To: sfc@ietf.org Subject: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived-flow-u= se-cases-02 Greetings WG: This message begins a two week call for WG adoption of draft-krishnan-sfc-l= ong-lived-flow-use-cases-02 [http://datatracker.ietf.org/doc/draft-krishnan= -sfc-long-lived-flow-use-cases/] ending June 2nd 2014. The draft highlights a number of use cases specific to long lived flows and= appears to compliment our already adopted use case documents. Please respo= nd to the SFC mailing list with any statements of approval or disapproval. As always, please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document's content until there is WG consensus that th= e content is solid. Therefore, please don't oppose adoption just because yo= u want to see changes to its content. 2. If you have objections to adoption of the document, please state your= reasons why, and explain what it would take to address your concerns. 3. If you have issues with the content, by all means raise those issues = and we can begin a dialog about how best to address them. --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A83570AMBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    I support adoption of thi= s draft by the SFC WG.   It is very well written and provides exc= ellent use cases that further the value of an SFC approach.

     <= /p>

       Ron

     <= /p>

     <= /p>

    From: sfc [m= ailto:sfc-bounces@ietf.org] On Behalf Of ramki Krishnan
    Sent: Wednesday, May 28, 2014 10:58 AM
    To: Jim Guichard (jguichar); sfc@ietf.org
    Subject: Re: [sfc] Call for WG adoption of draft-krishnan-sfc-long-l= ived-flow-use-cases-02

     

    Support as co-author.

     <= /p>

    Thanks,=

    Ramki

     <= /p>

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
    Sent: Monday, May 19, 2014 10:27 AM
    To: sfc@ietf.org
    Subject: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived= -flow-use-cases-02

     

    Greetings WG:

     

    This message begins a two w= eek call for WG adoption of draft-krishnan-sfc-long-lived-flow-use-cases-02= [http://datatracker.ietf.org/doc/draft-krishnan-sfc-long-li= ved-flow-use-cases/] ending June 2nd 2014.

     

    The draft highlights a numb= er of use cases specific to long lived flows and appears to compliment our = already adopted use case documents. Please respond to the SFC mailing list with any statements of approval or disapproval.

     

    As always, please note:

    1. This is not WG Last Call. The document is not final, and the W= G is expected to modify the document’s content until there is WG cons= ensus that the content is solid. Therefore, please don’t oppose adoption just because you want to see changes to its content.
    2. If you have objections to adoption of the document, please sta= te your reasons why, and explain what it would take to address your concern= s.
    3. If you have issues with the content, by all means raise those = issues and we can begin a dialog about how best to address them. =
    --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A83570AMBX021W3CA2exch_-- From nobody Wed May 28 12:34:53 2014 Return-Path: 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 CA0931A065F for ; Wed, 28 May 2014 12:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 JHpL3HmQXA6A for ; Wed, 28 May 2014 12:34:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CC4D1A042D for ; Wed, 28 May 2014 12:34:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHI51638; Wed, 28 May 2014 19:34:44 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 May 2014 20:34:11 +0100 Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 May 2014 20:34:43 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml703-chm.china.huawei.com ([169.254.5.144]) with mapi id 14.03.0158.001; Wed, 28 May 2014 12:34:31 -0700 From: Linda Dunbar To: "Paul Quinn (paulq)" , "Joel M. Halpern" Thread-Topic: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 Thread-Index: Ac96q9igNYLhn/ifQS+CjPHej+3iVw== Date: Wed, 28 May 2014 19:34:31 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D274E3@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.251] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D274E3dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/jokxZGrwKi-uxlp7S-DDwHEsdzw Cc: "sfc@ietf.org" Subject: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 19:34:51 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645D274E3dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Paul and Joel, Does the Load Balancing Figure 5 (of draft-quinn-sfc-arch-05) assume that S= F1 is responsible for balancing traffic among the 3 instances of SF2, and S= F3 is responsible for balancing traffic among the 3 instances of SF4? Isn't it a single point of failure? Some service functions are Stateful, i.e. they may require packets from sam= e flows to traverse the same service function instance. For the Load Balanc= ing scheme described by Figure 5, do you assume that SF1 and SF3 will be re= sponsible for making sure that same flows go through the same service funct= ion instance? For the stateful service functions, if a flow is switched from SF-Instance-= X to SF-Instance-Y, the SF-Instance-Y needs to synchronize the states from = SF-Instance-X. Who is responsible for those states maintenance for the Load= Balancing described in Figure 5? Linda --_000_4A95BA014132FF49AE685FAB4B9F17F645D274E3dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Paul and Joel,

     

    Does the Load Balancing Figure 5 (of draft-quinn-sfc= -arch-05) assume that SF1 is responsible for balancing traffic among the 3 = instances of SF2, and SF3 is responsible for balancing traffic among the 3 = instances of SF4?

     

    Isn’t it a single point of failure?

     

    Some service functions are Stateful, i.e. they may r= equire packets from same flows to traverse the same service function instan= ce. For the Load Balancing scheme described by Figure 5, do you assume that= SF1 and SF3 will be responsible for making sure that same flows go through the same service function instance?=

     

    For the stateful service functions, if a flow is swi= tched from SF-Instance-X to SF-Instance-Y, the SF-Instance-Y needs to synch= ronize the states from SF-Instance-X. Who is responsible for those states m= aintenance for the Load Balancing described in Figure 5?

     

    Linda

     

    --_000_4A95BA014132FF49AE685FAB4B9F17F645D274E3dfweml701chmchi_-- From nobody Wed May 28 12:36:49 2014 Return-Path: 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 39CCA1A067E for ; Wed, 28 May 2014 12:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 6r-rgwmI-t5r for ; Wed, 28 May 2014 12:36:46 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B46371A0204 for ; Wed, 28 May 2014 12:36:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 4575E581410; Wed, 28 May 2014 12:36:43 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-10.clppva.east.verizon.net [70.106.135.10]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id A3351581411; Wed, 28 May 2014 12:36:37 -0700 (PDT) Message-ID: <53863AB8.8000006@joelhalpern.com> Date: Wed, 28 May 2014 15:36:24 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Linda Dunbar , "Paul Quinn (paulq)" References: <4A95BA014132FF49AE685FAB4B9F17F645D274E3@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D274E3@dfweml701-chm.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/M7VLSPkdotW8p6pVX0StOl7gKxM Cc: "sfc@ietf.org" Subject: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 19:36:48 -0000 No, that is not the intent of the figure. But we have been unable to draw a figure with the service functions and the load balancers that can actually fit on a page and be read. Yours, Joel On 5/28/14, 3:34 PM, Linda Dunbar wrote: > Paul and Joel, > > Does the Load Balancing Figure 5 (of draft-quinn-sfc-arch-05) assume > that SF1 is responsible for balancing traffic among the 3 instances of > SF2, and SF3 is responsible for balancing traffic among the 3 instances > of SF4? > > Isn’t it a single point of failure? > > Some service functions are Stateful, i.e. they may require packets from > same flows to traverse the same service function instance. For the Load > Balancing scheme described by Figure 5, do you assume that SF1 and SF3 > will be responsible for making sure that same flows go through the same > service function instance? > > For the stateful service functions, if a flow is switched from > SF-Instance-X to SF-Instance-Y, the SF-Instance-Y needs to synchronize > the states from SF-Instance-X. Who is responsible for those states > maintenance for the Load Balancing described in Figure 5? > > Linda > From nobody Wed May 28 13:48:51 2014 Return-Path: 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 1820D1A020B for ; Wed, 28 May 2014 13:48:48 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 DyMitauEpKO7 for ; Wed, 28 May 2014 13:48:45 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E5151A0171 for ; Wed, 28 May 2014 13:48:45 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-ba-5385f91ed85d Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 7E.76.11744.E19F5835; Wed, 28 May 2014 16:56:31 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Wed, 28 May 2014 16:48:39 -0400 From: Eric Gray To: Linda Dunbar , "Paul Quinn (paulq)" , "Joel M. Halpern" Thread-Topic: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 Thread-Index: Ac96q9igNYLhn/ifQS+CjPHej+3iVwACH40A Date: Wed, 28 May 2014 20:48:39 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF632ACF534@eusaamb107.ericsson.se> References: <4A95BA014132FF49AE685FAB4B9F17F645D274E3@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D274E3@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF632ACF534eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZXLonQVf+Z2uwwcT//BYfT71hsrjbMpHJ Yv+rpawWTx5sZXdg8ZjyeyOrR8uRt6weS5b8ZPI4N+U7YwBLFJdNSmpOZllqkb5dAlfG8ln7 mAo+h1dMuD2FuYGxyaeLkZNDQsBEYuO2ZywQtpjEhXvr2boYuTiEBI4yStw++oMZwlnOKHHz 4CVmkCo2AQ2JY3fWMoLYIgK1EpMvtYF1MwsoSjy69Zupi5GDQ1ggSmJJAwdESbTE3cv9rBC2 kcTbixuZQGwWAVWJS5Nvs4OU8wr4SnxcEwISFhIIlbjXfx5sIqdAmMTeb3PBNjEC3fb91Bom iE3iEreezGeCuFlAYsme88wQtqjEy8f/WCFsJYlJS8+xQtTnS3Tcfg42k1dAUOLkzCcsExhF ZyEZNQtJ2SwkZRBxHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0VI0dpcWpZbrqR4SZGYOwd k2Bz3MG44JPlIUYBDkYlHt4Hr1uDhVgTy4orcw8xSnOwKInz7rlWFSwkkJ5YkpqdmlqQWhRf VJqTWnyIkYmDU6qB0Xqzu47/jowt+Vc+q7SfOy3y6GSLkerD/KqyXYIzimMXdN0qWBXKuej/ 8RV+80Lv5u85nL289lYQv+lT/1TZ+xIbJugVBazNUbznErU3k+Puv5aqugVx1y9Epn7QKc6f z+qhnsj9YY7L0dmrZ36aq5D+/eGDaIaFn6a+kT68uOP86gKNSXt3NSuxFGckGmoxFxUnAgCA RtxvngIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/9t61TeoGo3lz_MCH95zm0czxJLA Cc: "sfc@ietf.org" Subject: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 20:48:48 -0000 --_000_48E1A67CB9CA044EADFEAB87D814BFF632ACF534eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Linda, As Joel pointed out in his separate response the figure is = not intended to indicate that there are points that are "responsible for balancing traffic.= " As I understand it, the purpose of the figure is to try to = shed some light on an idea that should be obvious but is very hard to illustrate. The idea is that - in order to support chaining of a set of= functions, when there are various forms of network elasticity (function redundancy or load-= sharing, or network path redundancy or load sharing for example), it must be possibl= e to pick a path that corresponds to the desired/intended function chain. This should be obvious. In the example in the figure, the role of SF3 (for example)= is to provide a point of convergence after the redundant/load-distributing service group sh= own as multiple instances of SF2. SF3 could also be part of a load-sharing, or redundant grou= p of multiple convergence points. But - at some point - a certain amount of complexity i= n an illustrative depiction significantly detracts from the intent of the illust= ration. It is even possible that this figure has already passed tha= t point. Can you suggest an easier way to illustrate the point? -- Eric From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Wednesday, May 28, 2014 3:35 PM To: Paul Quinn (paulq); Joel M. Halpern Cc: sfc@ietf.org Subject: [sfc] questions of "load balancing considerations" in the draft-qu= inn-sfc-arch-05 Paul and Joel, Does the Load Balancing Figure 5 (of draft-quinn-sfc-arch-05) assume that S= F1 is responsible for balancing traffic among the 3 instances of SF2, and S= F3 is responsible for balancing traffic among the 3 instances of SF4? Isn't it a single point of failure? Some service functions are Stateful, i.e. they may require packets from sam= e flows to traverse the same service function instance. For the Load Balanc= ing scheme described by Figure 5, do you assume that SF1 and SF3 will be re= sponsible for making sure that same flows go through the same service funct= ion instance? For the stateful service functions, if a flow is switched from SF-Instance-= X to SF-Instance-Y, the SF-Instance-Y needs to synchronize the states from = SF-Instance-X. Who is responsible for those states maintenance for the Load= Balancing described in Figure 5? Linda --_000_48E1A67CB9CA044EADFEAB87D814BFF632ACF534eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Linda,

     

       &nbs= p;            As Joe= l pointed out in his separate response the figure is not intended to

    indicate that there ar= e points that are “responsible for balancing traffic.”

     

       &nbs= p;            As I u= nderstand it, the purpose of the figure is to try to shed some light on

    an idea that should be= obvious but is very hard to illustrate.

     

       &nbs= p;            The id= ea is that – in order to support chaining of a set of functions, when

    there are various form= s of network elasticity (function redundancy or load-sharing,

    or network path redund= ancy or load sharing for example), it must be possible to

    pick a path that corre= sponds to the desired/intended function chain.

     

       &nbs= p;            This s= hould  be obvious.

     

       &nbs= p;            In the= example in the figure, the role of SF3 (for example) is to provide a

    point of convergence a= fter the redundant/load-distributing service group shown<= /p>

    as multiple instances = of SF2.

     

       &nbs= p;            SF3 co= uld also be part of a load-sharing, or redundant group of multiple

    convergence points.&nb= sp; But – at some point – a certain amount of complexity in an<= o:p>

    illustrative depiction= significantly detracts from the intent of the illustration.

     

       &nbs= p;            It is = even possible that this figure has already passed that point.

     

       &nbs= p;            Can yo= u suggest an easier way to illustrate the point?

     

    --

    Eric=

     

    From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar
    Sent: Wednesday, May 28, 2014 3:35 PM
    To: Paul Quinn (paulq); Joel M. Halpern
    Cc: sfc@ietf.org
    Subject: [sfc] questions of "load balancing considerations"= ; in the draft-quinn-sfc-arch-05

     

    Paul and Joel,

     

    Does the Load Balancing Figure 5 (of draft-quinn-sfc= -arch-05) assume that SF1 is responsible for balancing traffic among the 3 = instances of SF2, and SF3 is responsible for balancing traffic among the 3 = instances of SF4?

     

    Isn’t it a single point of failure?

     

    Some service functions are Stateful, i.e. they may r= equire packets from same flows to traverse the same service function instan= ce. For the Load Balancing scheme described by Figure 5, do you assume that= SF1 and SF3 will be responsible for making sure that same flows go through the same service function instance?=

     

    For the stateful service functions, if a flow is swi= tched from SF-Instance-X to SF-Instance-Y, the SF-Instance-Y needs to synch= ronize the states from SF-Instance-X. Who is responsible for those states m= aintenance for the Load Balancing described in Figure 5?

     

    Linda

     

    --_000_48E1A67CB9CA044EADFEAB87D814BFF632ACF534eusaamb107erics_-- From nobody Wed May 28 14:24:24 2014 Return-Path: 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 C579F1A022A for ; Wed, 28 May 2014 14:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 HLaBA3vMfyok for ; Wed, 28 May 2014 14:24:21 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12C8C1A0268 for ; Wed, 28 May 2014 14:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12059; q=dns/txt; s=iport; t=1401312258; x=1402521858; h=from:to:cc:subject:date:message-id:mime-version; bh=5HTO/JHbxvYtpHuaRMYbquoup8P+wrZOmsxv05JHnow=; b=CXeMBeKM6bcHgnpRiLSD09R4eoxYhYkUn7btjpNL/1odf/MJYhAHSTKi WAlKJmGrKgyRUAVq/HHKgpB/vda6GDV//dlv5L62F/DwhbZwr/a5CC52K iI350KNetPzFn3rW0+cr1pnx31F4PzsYqNSE7nV92bOMXSWOP1Xs5FXrE E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAIBThlOtJA2G/2dsb2JhbABagkJFUljCNoEPFnSCJQECBC1ECBIBCBEDAQIoORQJCgQBDQUbiCfYKheOQRGERwSZdZMngXiBQIIv X-IronPort-AV: E=Sophos;i="4.98,930,1392163200"; d="scan'208,217";a="328644309" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-8.cisco.com with ESMTP; 28 May 2014 21:24:17 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s4SLOGBa032501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 May 2014 21:24:16 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.121]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Wed, 28 May 2014 16:24:16 -0500 From: "Ken Gray (kegray)" To: Linda Dunbar , "Paul Quinn (paulq)" , "Joel M. Halpern" Thread-Topic: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 Thread-Index: AQHPerstNYLhn/ifQS+CjPHej+3iVw== Date: Wed, 28 May 2014 21:24:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.73.121] Content-Type: multipart/alternative; boundary="_000_CFABB7592DEF3kegrayciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/wEZ-hcf9AJO_LaX43ccnFgUF2aE Cc: "sfc@ietf.org" Subject: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 21:24:22 -0000 --_000_CFABB7592DEF3kegrayciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 to Joel =85 the picture would be ugly at best. We attempted a generic H= A/LB slide to make a point and even it was ugly =85such are the limitations= of ASCII art. In line =85 From: Linda Dunbar = > Date: Wednesday, May 28, 2014 3:34 PM To: "Paul Quinn (paulq)" >, "Joel M= . Halpern" > Cc: "sfc@ietf.org" > Subject: [sfc] questions of "load balancing considerations" in the draft-qu= inn-sfc-arch-05 Paul and Joel, Does the Load Balancing Figure 5 (of draft-quinn-sfc-arch-05) assume that S= F1 is responsible for balancing traffic among the 3 instances of SF2, and S= F3 is responsible for balancing traffic among the 3 instances of SF4? Document text below the picture says "Either through an imbedded acti= on in sf1 and sf3, or through external control, the service functions sf2 and sf4 are elastically expanded and con= tracted dynamically." Isn=92t it a single point of failure? Document text immediately subsequent to that picture and paragraph il= lustrates HA scenarios. Some service functions are Stateful, i.e. they may require packets from sam= e flows to traverse the same service function instance. For the Load Balanc= ing scheme described by Figure 5, do you assume that SF1 and SF3 will be re= sponsible for making sure that same flows go through the same service funct= ion instance? Again, the aforementioned text deliberately allows this responsibilit= y to be either imbedded in the elasticity-causing function or to be control= led externally or centrally. We don't get into the mechanics as these can = vary. While stateful/bidirectional does add an additional burden, it can b= e accommodated without an explosion of discrete chains. For example, it co= uld be handled "at allocation time" if elasticity is managed via a separate= entity and the individual allocations reflected through service chain cont= rol in the initial metadata bound to at the classification point in either = direction. OR, if the devices are working as a paired system (single vendo= r or ecosystem) with integrated elasticity, they could pass metadata betwee= n them when sf1 or sf3 does the initial dynamic allocation (affecting local= forwarding on it's partner). That's probably not an exhaustive list of wa= ys to solve the problem. 8^) The point of this section was that elasticity and HA should not cause= an inordinate explosion of discrete chains without recommending a particul= ar solution. That is, you shouldn't create unnecessary complexity where = it doesn't need to exist. For the stateful service functions, if a flow is switched from SF-Instance-= X to SF-Instance-Y, the SF-Instance-Y needs to synchronize the states from = SF-Instance-X. Who is responsible for those states maintenance for the Load= Balancing described in Figure 5? None of those entities exist in Figure 5. Can you re-phrase your que= stion from the figure? Linda --_000_CFABB7592DEF3kegrayciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
    +1 to Joel =85 the picture would be ugly at best.  We attempt= ed a generic HA/LB slide to make a point and even it was ugly =85such are t= he limitations of ASCII art.

    In line =85

    From: Linda Dunbar <linda.dunbar@huawei.com>
    Date: Wednesday, May 28, 2014 3:34 = PM
    To: "Paul Quinn (paulq)" = <paulq@cisco.com>, "Joel = M. Halpern" <jmh@joelhalpern= .com>
    Cc: "sfc@ietf.org" <sfc@ietf.= org>
    Subject: [sfc] questions of "l= oad balancing considerations" in the draft-quinn-sfc-arch-05

    Paul and Joel,

     

    Does the Load Balancing Figure 5 (of draft-quinn-sfc= -arch-05) assume that SF1 is responsible for balancing traffic among the 3 = instances of SF2, and SF3 is responsible for balancing traffic among the 3 = instances of SF4?

    <keg> Document text below the picture says "Either through = an imbedded action in sf1 and sf3, or through external
    control, the service functions sf2 and sf4 are elastically expanded&nb= sp;and contracted dynamically."

     

    Isn=92t it a single point of failure?

    <keg> Document text immediately subsequent to that picture and p= aragraph illustrates HA scenarios.

     

    Some service functions are Stateful, i.e. they may r= equire packets from same flows to traverse the same service function instan= ce. For the Load Balancing scheme described by Figure 5, do you assume that= SF1 and SF3 will be responsible for making sure that same flows go through the same service function instance?=


    <keg> Again, the aforementioned text deliberately allows this re= sponsibility to be either imbedded in the elasticity-causing function or to= be controlled externally or centrally.  We don't get into the mechani= cs as these can vary.  While stateful/bidirectional does add an additional burden, it can be accommodated without an explosion= of discrete chains.  For example, it could be handled "at alloca= tion time" if elasticity is managed via a separate entity and the indi= vidual allocations reflected through service chain control in the initial metadata bound to at the classification point in ei= ther direction.  OR, if the devices are working as a paired system (si= ngle vendor or ecosystem) with integrated elasticity, they could pass metad= ata between them when sf1 or sf3 does the initial dynamic allocation (affecting local forwarding on it's partner= ).  That's probably not an exhaustive list of ways to solve the proble= m.  8^)

    <keg> The point of this section was that elasticity and HA shoul= d not cause an inordinate explosion of discrete chains without recommending= a particular solution.  That is,  you shouldn't create unnecessa= ry  complexity where it doesn't need to exist.

     

    For the stateful service functions, if a flow is swi= tched from SF-Instance-X to SF-Instance-Y, the SF-Instance-Y needs to synch= ronize the states from SF-Instance-X. Who is responsible for those states m= aintenance for the Load Balancing described in Figure 5?

    <keg> None of those entities exist in Figure 5.  Can you re= -phrase your question from the figure? 

     

    Linda

     

     --_000_CFABB7592DEF3kegrayciscocom_-- From nobody Wed May 28 14:50:15 2014 Return-Path: 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 B1A311A06B4 for ; Wed, 28 May 2014 14:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 BfjKpop3lgj2 for ; Wed, 28 May 2014 14:50:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7D4D1A06A9 for ; Wed, 28 May 2014 14:50:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEQ49554; Wed, 28 May 2014 21:50:01 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 May 2014 22:49:31 +0100 Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 May 2014 22:50:00 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml706-chm.china.huawei.com ([169.254.8.4]) with mapi id 14.03.0158.001; Wed, 28 May 2014 14:49:48 -0700 From: Linda Dunbar To: "Ken Gray (kegray)" , "Paul Quinn (paulq)" , "Joel M. Halpern" Thread-Topic: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 Thread-Index: AQHPerstNYLhn/ifQS+CjPHej+3iV5tWg/Pg Date: Wed, 28 May 2014 21:49:48 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.154.26] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D2762Adfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/efVGWdo9sKFvkXHaYLRUz72sPxs Cc: "sfc@ietf.org" Subject: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 21:50:11 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645D2762Adfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Joel, Eric, and Ken, Thank you very much for the explanation. Based on what you said, the description on how "control entity push to the= sf1 nodes ..." should be removed from the text, specifically: "In this case, the control entity will push to the sf1 nodes, a table of sorts:[L1] sf2 with a series of next hops, and if needed some weighted = or other metrics (these could also be decided locally by some policy, but sf1 would need to be aware of expand/contract triggers and actions)." Should also change the sentence after the Figure 5 to "Either through an imbedded action in sf1 and sf3, the SFF nodes to which t= he multiple instances of SF2 or SF4 are attached, or through external control, the service functions sf2 and sf4 are elastically expanded and contracted dynamically." Linda From: Ken Gray (kegray) [mailto:kegray@cisco.com] Sent: Wednesday, May 28, 2014 4:24 PM To: Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern Cc: sfc@ietf.org Subject: Re: [sfc] questions of "load balancing considerations" in the draf= t-quinn-sfc-arch-05 +1 to Joel ... the picture would be ugly at best. We attempted a generic H= A/LB slide to make a point and even it was ugly ...such are the limitations= of ASCII art. In line ... From: Linda Dunbar = > Date: Wednesday, May 28, 2014 3:34 PM To: "Paul Quinn (paulq)" >, "Joel M= . Halpern" > Cc: "sfc@ietf.org" > Subject: [sfc] questions of "load balancing considerations" in the draft-qu= inn-sfc-arch-05 Paul and Joel, Does the Load Balancing Figure 5 (of draft-quinn-sfc-arch-05) assume that S= F1 is responsible for balancing traffic among the 3 instances of SF2, and S= F3 is responsible for balancing traffic among the 3 instances of SF4? Document text below the picture says "Either through an imbedded acti= on in sf1 and sf3, or through external control, the service functions sf2 and sf4 are elastically expanded and con= tracted dynamically." Isn't it a single point of failure? Document text immediately subsequent to that picture and paragraph il= lustrates HA scenarios. Some service functions are Stateful, i.e. they may require packets from sam= e flows to traverse the same service function instance. For the Load Balanc= ing scheme described by Figure 5, do you assume that SF1 and SF3 will be re= sponsible for making sure that same flows go through the same service funct= ion instance? Again, the aforementioned text deliberately allows this responsibilit= y to be either imbedded in the elasticity-causing function or to be control= led externally or centrally. We don't get into the mechanics as these can = vary. While stateful/bidirectional does add an additional burden, it can b= e accommodated without an explosion of discrete chains. For example, it co= uld be handled "at allocation time" if elasticity is managed via a separate= entity and the individual allocations reflected through service chain cont= rol in the initial metadata bound to at the classification point in either = direction. OR, if the devices are working as a paired system (single vendo= r or ecosystem) with integrated elasticity, they could pass metadata betwee= n them when sf1 or sf3 does the initial dynamic allocation (affecting local= forwarding on it's partner). That's probably not an exhaustive list of wa= ys to solve the problem. 8^) The point of this section was that elasticity and HA should not cause= an inordinate explosion of discrete chains without recommending a particul= ar solution. That is, you shouldn't create unnecessary complexity where = it doesn't need to exist. For the stateful service functions, if a flow is switched from SF-Instance-= X to SF-Instance-Y, the SF-Instance-Y needs to synchronize the states from = SF-Instance-X. Who is responsible for those states maintenance for the Load= Balancing described in Figure 5? None of those entities exist in Figure 5. Can you re-phrase your que= stion from the figure? Linda ________________________________ [L1]Require pushing policies to SF1 on how to load balance multiple instan= ces of SF2. SF1 may not have the capability to balance among multiple instances of SF2 --_000_4A95BA014132FF49AE685FAB4B9F17F645D2762Adfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Joel, Eric, and Ken, <= o:p>

     

    Thank you very much fo= r the explanation.

     

    Based on what you said= , the description on how “control entity  push to the sf1 nodes = …” should be removed from the text, specifically:

     

    “In this

       case, the c= ontrol entity will push to the sf1 nodes, a table of<= /p>

       so= rts:[L1]  sf2 with a series of next hops, and if needed some weighted or<= /span>

       other metrics (these could also be decided lo= cally by some policy,

       but sf1 would need to be aware of expand/cont= ract triggers and

       actions).”

     

     

    Should also change the= sentence after the Figure 5 to

     

    “Either through an imbedded action in sf1 and sf3, the SFF nodes to which the multiple instances of = SF2 or SF4 are attached, or through external

       control, the service functions sf2 and sf4 ar= e elastically expanded

       and contracted dynamically.” 

     

     

    Linda

    From: Ken Gray= (kegray) [mailto:kegray@cisco.com]
    Sent: Wednesday, May 28, 2014 4:24 PM
    To: Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern
    Cc: sfc@ietf.org
    Subject: Re: [sfc] questions of "load balancing considerations&= quot; in the draft-quinn-sfc-arch-05

     

    +1 t= o Joel … the picture would be ugly at best.  We attempted a gene= ric HA/LB slide to make a point and even it was ugly …such are the li= mitations of ASCII art.

    &nb= sp;

    In line = …

    &nb= sp;

    From: Linda Dunbar <linda.dunbar@huawei.com>
    Date: Wednesday, May 28, 2014 3:34 PM
    To: "Paul Quinn (paulq)" <paulq@cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.com>
    Cc: "sfc@ietf.org" <= ;sfc@ietf.org>
    Subject: [sfc] questions of "load balancing considerations"= ; in the draft-quinn-sfc-arch-05

    &nb= sp;

    Paul and Joel,

     =

    Does the Load Balancing = Figure 5 (of draft-quinn-sfc-arch-05) assume that SF1 is responsible for ba= lancing traffic among the 3 instances of SF2, and SF3 is responsible for ba= lancing traffic among the 3 instances of SF4?

    &nb= sp;

    <keg&= gt; Document text below the picture says "Either through an imbedded a= ction in sf1 and sf3, or through external

    control,= the service functions sf2 and sf4 are elastically expanded and contra= cted dynamically."

     =

    Isn’t it a single = point of failure?

    &nb= sp;

    <keg&= gt; Document text immediately subsequent to that picture and paragraph illu= strates HA scenarios.

     =

    Some service functions a= re Stateful, i.e. they may require packets from same flows to traverse the = same service function instance. For the Load Balancing scheme described by = Figure 5, do you assume that SF1 and SF3 will be responsible for making sure that same flows go through the sam= e service function instance?

    &nb= sp;

    <keg&= gt; Again, the aforementioned text deliberately allows this responsibility = to be either imbedded in the elasticity-causing function or to be controlle= d externally or centrally.  We don't get into the mechanics as these can vary.  While stateful/bidirectional does a= dd an additional burden, it can be accommodated without an explosion of dis= crete chains.  For example, it could be handled "at allocation ti= me" if elasticity is managed via a separate entity and the individual allocations reflected through service chain control in = the initial metadata bound to at the classification point in either directi= on.  OR, if the devices are working as a paired system (single vendor = or ecosystem) with integrated elasticity, they could pass metadata between them when sf1 or sf3 does the initial dyn= amic allocation (affecting local forwarding on it's partner).  That's = probably not an exhaustive list of ways to solve the problem.  8^)

    &nb= sp;

    <keg&= gt; The point of this section was that elasticity and HA should not cause a= n inordinate explosion of discrete chains without recommending a particular= solution.  That is,  you shouldn't create unnecessary  complexity where it doesn't need to exist.

     =

    For the stateful service= functions, if a flow is switched from SF-Instance-X to SF-Instance-Y, the = SF-Instance-Y needs to synchronize the states from SF-Instance-X. Who is re= sponsible for those states maintenance for the Load Balancing described in Figure 5?

    &nb= sp;

    <keg&= gt; None of those entities exist in Figure 5.  Can you re-phrase your = question from the figure? 

     =

    Linda<= /p>

     =

     [L1]Require pushing po= licies to SF1 on how to load balance multiple instances of SF2.

     

    SF1 may not have the capability to balance among multiple instances of SF2

    --_000_4A95BA014132FF49AE685FAB4B9F17F645D2762Adfweml701chmchi_-- From nobody Wed May 28 17:48:45 2014 Return-Path: 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 B5BEC1A081F for ; Wed, 28 May 2014 17:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 jFZoetG6gZoF for ; Wed, 28 May 2014 17:48:41 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86F491A07D0 for ; Wed, 28 May 2014 17:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24205; q=dns/txt; s=iport; t=1401324518; x=1402534118; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Z4W/MxRXM3ste8m/qaSEe3v6V2vFDXsEvAo8XlM8CEQ=; b=U/pMQFxd059Cyuam1DWe6gxWW5NDe1gxUMvAbGfOuj5bYi2rfZ+nDuPl tZ6QWicPg05TIB1Xisq36dxR8GsZYp8knHnZpPoBD7YCAmjUi6r+dyFnB 6cyic7Fxms2qKpoOO9ibYbnbNPcozu2rXMFlW/W1hYDdJUtScJexeIESD s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsFANyChlOtJV2a/2dsb2JhbABagkJFUsMQAYERFnSCJQEBAQQOHzgMCBACAQgRAwEBASEHBzIUCQgCBA4FG4gn2AkXBgEBjWc2HBEGAYMrgRUEhgGHVoweh2qLPYF4gUA X-IronPort-AV: E=Sophos; i="4.98,931,1392163200"; d="scan'208,217"; a="48128530" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP; 29 May 2014 00:48:37 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s4T0mawo019788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 May 2014 00:48:37 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.121]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Wed, 28 May 2014 19:48:36 -0500 From: "Ken Gray (kegray)" To: Linda Dunbar Thread-Topic: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 Thread-Index: AQHPerstNYLhn/ifQS+CjPHej+3iV5tWg/PggAA2Cec= Date: Thu, 29 May 2014 00:48:36 +0000 Message-ID: <16984558-2B4C-4873-AFC7-DCD2698CA745@cisco.com> References: , <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_169845582B4C4873AFC7DCD2698CA745ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/k64lsOuvMTeqp9xm0OdbtWSQr00 Cc: "Joel M. Halpern" , "Paul Quinn \(paulq\)" , "sfc@ietf.org" Subject: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 00:48:43 -0000 --_000_169845582B4C4873AFC7DCD2698CA745ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I don't see how you make the leap from the explanation of why it was irrele= vant to go into more detail in the section to the elimination of the very g= eneralized description accompanying the figure. Please use your own argume= nt to justify this and not infer any extra meaning from my answer to a diff= erent question. As to the second change, i disagree. Again, in general/broad strokes - fro= m the drawing and the text, it is unlikely that any special action would be= required on sf2 or sf4 - as they collapse in either direction to a single = logical next hop. Sent from my iPhone On May 28, 2014, at 5:49 PM, "Linda Dunbar" > wrote: Joel, Eric, and Ken, Thank you very much for the explanation. Based on what you said, the description on how =93control entity push to t= he sf1 nodes =85=94 should be removed from the text, specifically: =93In this case, the control entity will push to the sf1 nodes, a table of sorts:[L1] sf2 with a series of next hops, and if needed some weighted = or other metrics (these could also be decided locally by some policy, but sf1 would need to be aware of expand/contract triggers and actions).=94 Should also change the sentence after the Figure 5 to =93Either through an imbedded action in sf1 and sf3, the SFF nodes to which= the multiple instances of SF2 or SF4 are attached, or through external control, the service functions sf2 and sf4 are elastically expanded and contracted dynamically.=94 Linda From: Ken Gray (kegray) [mailto:kegray@cisco.com] Sent: Wednesday, May 28, 2014 4:24 PM To: Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern Cc: sfc@ietf.org Subject: Re: [sfc] questions of "load balancing considerations" in the draf= t-quinn-sfc-arch-05 +1 to Joel =85 the picture would be ugly at best. We attempted a generic H= A/LB slide to make a point and even it was ugly =85such are the limitations= of ASCII art. In line =85 From: Linda Dunbar = > Date: Wednesday, May 28, 2014 3:34 PM To: "Paul Quinn (paulq)" >, "Joel M= . Halpern" > Cc: "sfc@ietf.org" > Subject: [sfc] questions of "load balancing considerations" in the draft-qu= inn-sfc-arch-05 Paul and Joel, Does the Load Balancing Figure 5 (of draft-quinn-sfc-arch-05) assume that S= F1 is responsible for balancing traffic among the 3 instances of SF2, and S= F3 is responsible for balancing traffic among the 3 instances of SF4? Document text below the picture says "Either through an imbedded acti= on in sf1 and sf3, or through external control, the service functions sf2 and sf4 are elastically expanded and con= tracted dynamically." Isn=92t it a single point of failure? Document text immediately subsequent to that picture and paragraph il= lustrates HA scenarios. Some service functions are Stateful, i.e. they may require packets from sam= e flows to traverse the same service function instance. For the Load Balanc= ing scheme described by Figure 5, do you assume that SF1 and SF3 will be re= sponsible for making sure that same flows go through the same service funct= ion instance? Again, the aforementioned text deliberately allows this responsibilit= y to be either imbedded in the elasticity-causing function or to be control= led externally or centrally. We don't get into the mechanics as these can = vary. While stateful/bidirectional does add an additional burden, it can b= e accommodated without an explosion of discrete chains. For example, it co= uld be handled "at allocation time" if elasticity is managed via a separate= entity and the individual allocations reflected through service chain cont= rol in the initial metadata bound to at the classification point in either = direction. OR, if the devices are working as a paired system (single vendo= r or ecosystem) with integrated elasticity, they could pass metadata betwee= n them when sf1 or sf3 does the initial dynamic allocation (affecting local= forwarding on it's partner). That's probably not an exhaustive list of wa= ys to solve the problem. 8^) The point of this section was that elasticity and HA should not cause= an inordinate explosion of discrete chains without recommending a particul= ar solution. That is, you shouldn't create unnecessary complexity where = it doesn't need to exist. For the stateful service functions, if a flow is switched from SF-Instance-= X to SF-Instance-Y, the SF-Instance-Y needs to synchronize the states from = SF-Instance-X. Who is responsible for those states maintenance for the Load= Balancing described in Figure 5? None of those entities exist in Figure 5. Can you re-phrase your que= stion from the figure? Linda ________________________________ [L1]Require pushing policies to SF1 on how to load balance multiple instan= ces of SF2. SF1 may not have the capability to balance among multiple instances of SF2 --_000_169845582B4C4873AFC7DCD2698CA745ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
    I don't see how you make the leap from the explanation of why it was i= rrelevant to go into more detail in the section to the elimination of the v= ery generalized description accompanying the figure.  Please use your = own argument to justify this and not infer any extra meaning from my answer to a different question.

    As to the second change, i disagree.  Again, in general/broad str= okes - from the drawing and the text, it is unlikely that any special actio= n would be required on sf2 or sf4 - as they collapse in either direction to= a single logical next hop.

    Sent from my iPhone

    On May 28, 2014, at 5:49 PM, "Linda Dunbar" <linda.dunbar@huawei.com> wrote:

    Joel, Eric, and Ken, <= o:p>

     

    Thank you very much fo= r the explanation.

     

    Based on what you said= , the description on how =93control entity  push to the sf1 nodes =85= =94 should be removed from the text, specifically:

     

    =93In this

       case, the c= ontrol entity will push to the sf1 nodes, a table of<= /p>

       so= rts:[L1]  sf2 with a series of next hops, and if needed some weighted or<= /span>

       other metrics (these could also be decided lo= cally by some policy,

       but sf1 would need to be aware of expand/cont= ract triggers and

       actions).=94

     

     

    Should also change the= sentence after the Figure 5 to

     

    =93Either through an imbedded action in sf1 and sf3, the SFF nodes to which the multiple instances of = SF2 or SF4 are attached, or through external

       control, the service functions sf2 and sf4 ar= e elastically expanded

       and contracted dynamically.=94 

     

     

    Linda

    From: Ken Gray= (kegray) [mailto:kegray@cisco.com]
    Sent: Wednesday, May 28, 2014 4:24 PM
    To: Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern
    Cc: sfc@ietf.org
    Subject: Re: [sfc] questions of "load balancing considerations&= quot; in the draft-quinn-sfc-arch-05

     

    +1 t= o Joel =85 the picture would be ugly at best.  We attempted a generic = HA/LB slide to make a point and even it was ugly =85such are the limitation= s of ASCII art.

    &nb= sp;

    In line = =85

    &nb= sp;

    From: Linda Dunbar <linda.dunbar@huawei.com>
    Date: Wednesday, May 28, 2014 3:34 PM
    To: "Paul Quinn (paulq)" <paulq@cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.com>
    Cc: "sfc@ietf.org" <= ;sfc@ietf.org>
    Subject: [sfc] questions of "load balancing considerations"= ; in the draft-quinn-sfc-arch-05

    &nb= sp;

    Paul and Joel,

     =

    Does the Load Balancing = Figure 5 (of draft-quinn-sfc-arch-05) assume that SF1 is responsible for ba= lancing traffic among the 3 instances of SF2, and SF3 is responsible for ba= lancing traffic among the 3 instances of SF4?

    &nb= sp;

    <keg&= gt; Document text below the picture says "Either through an imbedded a= ction in sf1 and sf3, or through external

    control,= the service functions sf2 and sf4 are elastically expanded and contra= cted dynamically."

     =

    Isn=92t it a single poin= t of failure?

    &nb= sp;

    <keg&= gt; Document text immediately subsequent to that picture and paragraph illu= strates HA scenarios.

     =

    Some service functions a= re Stateful, i.e. they may require packets from same flows to traverse the = same service function instance. For the Load Balancing scheme described by = Figure 5, do you assume that SF1 and SF3 will be responsible for making sure that same flows go through the sam= e service function instance?

    &nb= sp;

    <keg&= gt; Again, the aforementioned text deliberately allows this responsibility = to be either imbedded in the elasticity-causing function or to be controlle= d externally or centrally.  We don't get into the mechanics as these can vary.  While stateful/bidirectional does a= dd an additional burden, it can be accommodated without an explosion of dis= crete chains.  For example, it could be handled "at allocation ti= me" if elasticity is managed via a separate entity and the individual allocations reflected through service chain control in = the initial metadata bound to at the classification point in either directi= on.  OR, if the devices are working as a paired system (single vendor = or ecosystem) with integrated elasticity, they could pass metadata between them when sf1 or sf3 does the initial dyn= amic allocation (affecting local forwarding on it's partner).  That's = probably not an exhaustive list of ways to solve the problem.  8^)

    &nb= sp;

    <keg&= gt; The point of this section was that elasticity and HA should not cause a= n inordinate explosion of discrete chains without recommending a particular= solution.  That is,  you shouldn't create unnecessary  complexity where it doesn't need to exist.

     =

    For the stateful service= functions, if a flow is switched from SF-Instance-X to SF-Instance-Y, the = SF-Instance-Y needs to synchronize the states from SF-Instance-X. Who is re= sponsible for those states maintenance for the Load Balancing described in Figure 5?

    &nb= sp;

    <keg&= gt; None of those entities exist in Figure 5.  Can you re-phrase your = question from the figure? 

     =

    Linda<= /p>

     =

     [L1]Require pu= shing policies to SF1 on how to load balance multiple instances of SF2.

     

    SF1 may not have the capability to balance among multiple instances of SF2

    --_000_169845582B4C4873AFC7DCD2698CA745ciscocom_-- From nobody Wed May 28 20:55:58 2014 Return-Path: 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 7251E1A076F for ; Wed, 28 May 2014 20:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 hokB-pp5iLgi for ; Wed, 28 May 2014 20:55:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811AF1A02F1 for ; Wed, 28 May 2014 20:55:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHJ02673; Thu, 29 May 2014 03:55:47 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 04:55:16 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 04:55:46 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.193]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Thu, 29 May 2014 11:55:35 +0800 From: Qin Wu To: "Ken Gray (kegray)" , Linda Dunbar Thread-Topic: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 Thread-Index: AQHPerst3UT4MK3T2kyQ1lwj4d3rd5tWAeoAgAAx9QCAALYxMA== Date: Thu, 29 May 2014 03:55:35 +0000 Message-ID: References: , <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> <16984558-2B4C-4873-AFC7-DCD2698CA745@cisco.com> In-Reply-To: <16984558-2B4C-4873-AFC7-DCD2698CA745@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.131] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA84546203nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/K90XON6ESoLThTRvN_He3TY1cdc Cc: "Joel M. Halpern" , "Paul Quinn \(paulq\)" , "sfc@ietf.org" Subject: [sfc] =?gb2312?b?tPC4tDogIHF1ZXN0aW9ucyBvZiAibG9hZCBiYWxhbmNpbmcg?= =?gb2312?b?Y29uc2lkZXJhdGlvbnMiIGluIHRoZSBkcmFmdC1xdWlubi1zZmMtYXJjaC0w?= =?gb2312?b?NQ==?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 03:55:56 -0000 --_000_B8F9A780D330094D99AF023C5877DABA84546203nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 WW91IGFyZSB0YWxraW5nIGFib3V0IHNlcnZpY2UgZnVuY3Rpb24gc2NhbGUgdXAgYW5kIGRvd24u DQpTaW5jZSBzZXJ2aWNlIG5vZGUgY2FuIGhvc3Qgb25lIG9yIG11bHRpcGxlIHNlcnZpY2UgZnVu Y3Rpb25zLCB3aHkgc2VydmljZSBub2RlIGNhbiBub3QgYmUgdXNlZCB0byBjb250cm9sIHNjYWxl IHVwIG9yIGRvd24gb2Ygc2VydmljZSBmdW5jdGlvbnMgaXQ/DQpUbyBhdm9pZCBzaGFyZSByaXNr IGZhaWx1cmUsIHNlcnZpY2Ugbm9kZSBjYW4gYmUgcHJldmlvdXMgc2VydmljZSBub2RlLCBlLmcu LCBpdCBjYW4gYmUgdGhlIG9uZSB0aGF0IGhvc3RzIHNmMSBvciBzZjMuDQpBbHNvIFNGRiBpcyBy ZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZyB0cmFmZmljIHRvIGFueSBjb25uZWN0ZWQgc2Vydmlj ZSBmdW5jdGlvbnMsIHdoeSBub3QgU0ZGIGNhbiBub3QgYmUgdXNlZCB0byBtYW5hZ2Ugc2NhbGUg dXAgb3IgZG93biBvZiBzZXJ2aWNlIGZ1bmN0aW9uLg0KQWxzbyBiYXNlZCBvbiBORlYgTUFOTyBh cmNoaXRlY3R1cmUsIHRoZXJlIGlzIHJlZmVyZW5jZSBwb2ludCBiZXR3ZWVuIE5GViBhbmQgTkZW IG1hbmFnZXIsIE5GViBtYW5hZ2VyIGFsc28gY2FuIGNvbnRyb2wgc2NhbGUgdXAgb3IgZG93biBv ZiBzZXJ2aWNlIGZ1bmN0aW9uLCBJIHRoaW5rIHRoaXMgY2FzZSBoYXMgYmVlbiBjb3ZlcmVkIGJ5 IKGwdGhyb3VnaCBleHRlcm5hbCBjb250cm9sobEgaW4gdGhlIGRyYWZ0Lg0KDQpVc2luZyBzZjEg dGhhdCBwcm92aWRlIGRlZGljYXRlZCBmaXJld2FsbCBzZXJ2aWNlIHRvIHByb3ZpZGUgbG9hZCBi YWxhbmNpbmcgZnVuY3Rpb25hbGl0eSBhcyB3ZWxsIGlzIGEgbGl0dGxlIGJpdCB3ZWlyZCB0byBt ZS4NCkxldCBtZSBrbm93IGlmIG15IHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdD8NCg0KUmVnYXJk cyENCi1RaW4NCreivP7Iyzogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddILT6se0g S2VuIEdyYXkgKGtlZ3JheSkNCreiy83KsbzkOiAyMDE0xOo11MIyOcjVIDg6NDkNCsrVvP7Iyzog TGluZGEgRHVuYmFyDQqzrcvNOiBKb2VsIE0uIEhhbHBlcm47IFBhdWwgUXVpbm4gKHBhdWxxKTsg c2ZjQGlldGYub3JnDQrW98ziOiBSZTogW3NmY10gcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2lu ZyBjb25zaWRlcmF0aW9ucyIgaW4gdGhlIGRyYWZ0LXF1aW5uLXNmYy1hcmNoLTA1DQoNCkkgZG9u J3Qgc2VlIGhvdyB5b3UgbWFrZSB0aGUgbGVhcCBmcm9tIHRoZSBleHBsYW5hdGlvbiBvZiB3aHkg aXQgd2FzIGlycmVsZXZhbnQgdG8gZ28gaW50byBtb3JlIGRldGFpbCBpbiB0aGUgc2VjdGlvbiB0 byB0aGUgZWxpbWluYXRpb24gb2YgdGhlIHZlcnkgZ2VuZXJhbGl6ZWQgZGVzY3JpcHRpb24gYWNj b21wYW55aW5nIHRoZSBmaWd1cmUuICBQbGVhc2UgdXNlIHlvdXIgb3duIGFyZ3VtZW50IHRvIGp1 c3RpZnkgdGhpcyBhbmQgbm90IGluZmVyIGFueSBleHRyYSBtZWFuaW5nIGZyb20gbXkgYW5zd2Vy IHRvIGEgZGlmZmVyZW50IHF1ZXN0aW9uLg0KDQpBcyB0byB0aGUgc2Vjb25kIGNoYW5nZSwgaSBk aXNhZ3JlZS4gIEFnYWluLCBpbiBnZW5lcmFsL2Jyb2FkIHN0cm9rZXMgLSBmcm9tIHRoZSBkcmF3 aW5nIGFuZCB0aGUgdGV4dCwgaXQgaXMgdW5saWtlbHkgdGhhdCBhbnkgc3BlY2lhbCBhY3Rpb24g d291bGQgYmUgcmVxdWlyZWQgb24gc2YyIG9yIHNmNCAtIGFzIHRoZXkgY29sbGFwc2UgaW4gZWl0 aGVyIGRpcmVjdGlvbiB0byBhIHNpbmdsZSBsb2dpY2FsIG5leHQgaG9wLg0KDQpTZW50IGZyb20g bXkgaVBob25lDQoNCk9uIE1heSAyOCwgMjAxNCwgYXQgNTo0OSBQTSwgIkxpbmRhIER1bmJhciIg PGxpbmRhLmR1bmJhckBodWF3ZWkuY29tPG1haWx0bzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbT4+ IHdyb3RlOg0KSm9lbCwgRXJpYywgYW5kIEtlbiwNCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3Ig dGhlIGV4cGxhbmF0aW9uLg0KDQpCYXNlZCBvbiB3aGF0IHlvdSBzYWlkLCB0aGUgZGVzY3JpcHRp b24gb24gaG93IKGwY29udHJvbCBlbnRpdHkgIHB1c2ggdG8gdGhlIHNmMSBub2RlcyChraGxIHNo b3VsZCBiZSByZW1vdmVkIGZyb20gdGhlIHRleHQsIHNwZWNpZmljYWxseToNCg0KobBJbiB0aGlz DQogICBjYXNlLCB0aGUgY29udHJvbCBlbnRpdHkgd2lsbCBwdXNoIHRvIHRoZSBzZjEgbm9kZXMs IGEgdGFibGUgb2YNCiAgIHNvcnRzOltMMV0gICBzZjIgd2l0aCBhIHNlcmllcyBvZiBuZXh0IGhv cHMsIGFuZCBpZiBuZWVkZWQgc29tZSB3ZWlnaHRlZCBvcg0KICAgb3RoZXIgbWV0cmljcyAodGhl c2UgY291bGQgYWxzbyBiZSBkZWNpZGVkIGxvY2FsbHkgYnkgc29tZSBwb2xpY3ksDQogICBidXQg c2YxIHdvdWxkIG5lZWQgdG8gYmUgYXdhcmUgb2YgZXhwYW5kL2NvbnRyYWN0IHRyaWdnZXJzIGFu ZA0KICAgYWN0aW9ucykuobENCg0KDQpTaG91bGQgYWxzbyBjaGFuZ2UgdGhlIHNlbnRlbmNlIGFm dGVyIHRoZSBGaWd1cmUgNSB0bw0KDQqhsEVpdGhlciB0aHJvdWdoIGFuIGltYmVkZGVkIGFjdGlv biBpbiBzZjEgYW5kIHNmMywgdGhlIFNGRiBub2RlcyB0byB3aGljaCB0aGUgbXVsdGlwbGUgaW5z dGFuY2VzIG9mIFNGMiBvciBTRjQgYXJlIGF0dGFjaGVkLCBvciB0aHJvdWdoIGV4dGVybmFsDQog ICBjb250cm9sLCB0aGUgc2VydmljZSBmdW5jdGlvbnMgc2YyIGFuZCBzZjQgYXJlIGVsYXN0aWNh bGx5IGV4cGFuZGVkDQogICBhbmQgY29udHJhY3RlZCBkeW5hbWljYWxseS6hsQ0KDQoNCkxpbmRh DQpGcm9tOiBLZW4gR3JheSAoa2VncmF5KSBbbWFpbHRvOmtlZ3JheUBjaXNjby5jb21dDQpTZW50 OiBXZWRuZXNkYXksIE1heSAyOCwgMjAxNCA0OjI0IFBNDQpUbzogTGluZGEgRHVuYmFyOyBQYXVs IFF1aW5uIChwYXVscSk7IEpvZWwgTS4gSGFscGVybg0KQ2M6IHNmY0BpZXRmLm9yZzxtYWlsdG86 c2ZjQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzZmNdIHF1ZXN0aW9ucyBvZiAibG9hZCBiYWxh bmNpbmcgY29uc2lkZXJhdGlvbnMiIGluIHRoZSBkcmFmdC1xdWlubi1zZmMtYXJjaC0wNQ0KDQor MSB0byBKb2VsIKGtIHRoZSBwaWN0dXJlIHdvdWxkIGJlIHVnbHkgYXQgYmVzdC4gIFdlIGF0dGVt cHRlZCBhIGdlbmVyaWMgSEEvTEIgc2xpZGUgdG8gbWFrZSBhIHBvaW50IGFuZCBldmVuIGl0IHdh cyB1Z2x5IKGtc3VjaCBhcmUgdGhlIGxpbWl0YXRpb25zIG9mIEFTQ0lJIGFydC4NCg0KSW4gbGlu ZSChrQ0KDQpGcm9tOiBMaW5kYSBEdW5iYXIgPGxpbmRhLmR1bmJhckBodWF3ZWkuY29tPG1haWx0 bzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbT4+DQpEYXRlOiBXZWRuZXNkYXksIE1heSAyOCwgMjAx NCAzOjM0IFBNDQpUbzogIlBhdWwgUXVpbm4gKHBhdWxxKSIgPHBhdWxxQGNpc2NvLmNvbTxtYWls dG86cGF1bHFAY2lzY28uY29tPj4sICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4u Y29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4NCkNjOiAic2ZjQGlldGYub3JnPG1haWx0 bzpzZmNAaWV0Zi5vcmc+IiA8c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KU3Vi amVjdDogW3NmY10gcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2luZyBjb25zaWRlcmF0aW9ucyIg aW4gdGhlIGRyYWZ0LXF1aW5uLXNmYy1hcmNoLTA1DQoNClBhdWwgYW5kIEpvZWwsDQoNCkRvZXMg dGhlIExvYWQgQmFsYW5jaW5nIEZpZ3VyZSA1IChvZiBkcmFmdC1xdWlubi1zZmMtYXJjaC0wNSkg YXNzdW1lIHRoYXQgU0YxIGlzIHJlc3BvbnNpYmxlIGZvciBiYWxhbmNpbmcgdHJhZmZpYyBhbW9u ZyB0aGUgMyBpbnN0YW5jZXMgb2YgU0YyLCBhbmQgU0YzIGlzIHJlc3BvbnNpYmxlIGZvciBiYWxh bmNpbmcgdHJhZmZpYyBhbW9uZyB0aGUgMyBpbnN0YW5jZXMgb2YgU0Y0Pw0KDQo8a2VnPiBEb2N1 bWVudCB0ZXh0IGJlbG93IHRoZSBwaWN0dXJlIHNheXMgIkVpdGhlciB0aHJvdWdoIGFuIGltYmVk ZGVkIGFjdGlvbiBpbiBzZjEgYW5kIHNmMywgb3IgdGhyb3VnaCBleHRlcm5hbA0KY29udHJvbCwg dGhlIHNlcnZpY2UgZnVuY3Rpb25zIHNmMiBhbmQgc2Y0IGFyZSBlbGFzdGljYWxseSBleHBhbmRl ZCBhbmQgY29udHJhY3RlZCBkeW5hbWljYWxseS4iDQoNCklzbqGvdCBpdCBhIHNpbmdsZSBwb2lu dCBvZiBmYWlsdXJlPw0KDQo8a2VnPiBEb2N1bWVudCB0ZXh0IGltbWVkaWF0ZWx5IHN1YnNlcXVl bnQgdG8gdGhhdCBwaWN0dXJlIGFuZCBwYXJhZ3JhcGggaWxsdXN0cmF0ZXMgSEEgc2NlbmFyaW9z Lg0KDQpTb21lIHNlcnZpY2UgZnVuY3Rpb25zIGFyZSBTdGF0ZWZ1bCwgaS5lLiB0aGV5IG1heSBy ZXF1aXJlIHBhY2tldHMgZnJvbSBzYW1lIGZsb3dzIHRvIHRyYXZlcnNlIHRoZSBzYW1lIHNlcnZp Y2UgZnVuY3Rpb24gaW5zdGFuY2UuIEZvciB0aGUgTG9hZCBCYWxhbmNpbmcgc2NoZW1lIGRlc2Ny aWJlZCBieSBGaWd1cmUgNSwgZG8geW91IGFzc3VtZSB0aGF0IFNGMSBhbmQgU0YzIHdpbGwgYmUg cmVzcG9uc2libGUgZm9yIG1ha2luZyBzdXJlIHRoYXQgc2FtZSBmbG93cyBnbyB0aHJvdWdoIHRo ZSBzYW1lIHNlcnZpY2UgZnVuY3Rpb24gaW5zdGFuY2U/DQoNCjxrZWc+IEFnYWluLCB0aGUgYWZv cmVtZW50aW9uZWQgdGV4dCBkZWxpYmVyYXRlbHkgYWxsb3dzIHRoaXMgcmVzcG9uc2liaWxpdHkg dG8gYmUgZWl0aGVyIGltYmVkZGVkIGluIHRoZSBlbGFzdGljaXR5LWNhdXNpbmcgZnVuY3Rpb24g b3IgdG8gYmUgY29udHJvbGxlZCBleHRlcm5hbGx5IG9yIGNlbnRyYWxseS4gIFdlIGRvbid0IGdl dCBpbnRvIHRoZSBtZWNoYW5pY3MgYXMgdGhlc2UgY2FuIHZhcnkuICBXaGlsZSBzdGF0ZWZ1bC9i aWRpcmVjdGlvbmFsIGRvZXMgYWRkIGFuIGFkZGl0aW9uYWwgYnVyZGVuLCBpdCBjYW4gYmUgYWNj b21tb2RhdGVkIHdpdGhvdXQgYW4gZXhwbG9zaW9uIG9mIGRpc2NyZXRlIGNoYWlucy4gIEZvciBl eGFtcGxlLCBpdCBjb3VsZCBiZSBoYW5kbGVkICJhdCBhbGxvY2F0aW9uIHRpbWUiIGlmIGVsYXN0 aWNpdHkgaXMgbWFuYWdlZCB2aWEgYSBzZXBhcmF0ZSBlbnRpdHkgYW5kIHRoZSBpbmRpdmlkdWFs IGFsbG9jYXRpb25zIHJlZmxlY3RlZCB0aHJvdWdoIHNlcnZpY2UgY2hhaW4gY29udHJvbCBpbiB0 aGUgaW5pdGlhbCBtZXRhZGF0YSBib3VuZCB0byBhdCB0aGUgY2xhc3NpZmljYXRpb24gcG9pbnQg aW4gZWl0aGVyIGRpcmVjdGlvbi4gIE9SLCBpZiB0aGUgZGV2aWNlcyBhcmUgd29ya2luZyBhcyBh IHBhaXJlZCBzeXN0ZW0gKHNpbmdsZSB2ZW5kb3Igb3IgZWNvc3lzdGVtKSB3aXRoIGludGVncmF0 ZWQgZWxhc3RpY2l0eSwgdGhleSBjb3VsZCBwYXNzIG1ldGFkYXRhIGJldHdlZW4gdGhlbSB3aGVu IHNmMSBvciBzZjMgZG9lcyB0aGUgaW5pdGlhbCBkeW5hbWljIGFsbG9jYXRpb24gKGFmZmVjdGlu ZyBsb2NhbCBmb3J3YXJkaW5nIG9uIGl0J3MgcGFydG5lcikuICBUaGF0J3MgcHJvYmFibHkgbm90 IGFuIGV4aGF1c3RpdmUgbGlzdCBvZiB3YXlzIHRvIHNvbHZlIHRoZSBwcm9ibGVtLiAgOF4pDQoN CjxrZWc+IFRoZSBwb2ludCBvZiB0aGlzIHNlY3Rpb24gd2FzIHRoYXQgZWxhc3RpY2l0eSBhbmQg SEEgc2hvdWxkIG5vdCBjYXVzZSBhbiBpbm9yZGluYXRlIGV4cGxvc2lvbiBvZiBkaXNjcmV0ZSBj aGFpbnMgd2l0aG91dCByZWNvbW1lbmRpbmcgYSBwYXJ0aWN1bGFyIHNvbHV0aW9uLiAgVGhhdCBp cywgIHlvdSBzaG91bGRuJ3QgY3JlYXRlIHVubmVjZXNzYXJ5ICBjb21wbGV4aXR5IHdoZXJlIGl0 IGRvZXNuJ3QgbmVlZCB0byBleGlzdC4NCg0KRm9yIHRoZSBzdGF0ZWZ1bCBzZXJ2aWNlIGZ1bmN0 aW9ucywgaWYgYSBmbG93IGlzIHN3aXRjaGVkIGZyb20gU0YtSW5zdGFuY2UtWCB0byBTRi1JbnN0 YW5jZS1ZLCB0aGUgU0YtSW5zdGFuY2UtWSBuZWVkcyB0byBzeW5jaHJvbml6ZSB0aGUgc3RhdGVz IGZyb20gU0YtSW5zdGFuY2UtWC4gV2hvIGlzIHJlc3BvbnNpYmxlIGZvciB0aG9zZSBzdGF0ZXMg bWFpbnRlbmFuY2UgZm9yIHRoZSBMb2FkIEJhbGFuY2luZyBkZXNjcmliZWQgaW4gRmlndXJlIDU/ DQoNCjxrZWc+IE5vbmUgb2YgdGhvc2UgZW50aXRpZXMgZXhpc3QgaW4gRmlndXJlIDUuICBDYW4g eW91IHJlLXBocmFzZSB5b3VyIHF1ZXN0aW9uIGZyb20gdGhlIGZpZ3VyZT8NCg0KTGluZGENCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KIFJlcXVpcmUgcHVzaGluZyBwb2xp Y2llcyB0byBTRjEgb24gaG93IHRvIGxvYWQgYmFsYW5jZSBtdWx0aXBsZSBpbnN0YW5jZXMgb2Yg U0YyLg0KDQoNCg0KU0YxIG1heSBub3QgaGF2ZSB0aGUgY2FwYWJpbGl0eSB0byBiYWxhbmNlIGFt b25nIG11bHRpcGxlIGluc3RhbmNlcyBvZiBTRjINCg== --_000_B8F9A780D330094D99AF023C5877DABA84546203nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

    You are talking about service function scale up and down.

    Since service node can host one or multiple service functions, wh= y service node can not be used to control scale up or down of service funct= ions it?

    To avoid share risk failure, service node can be previous service= node, e.g., it can be the one that hosts sf1 or sf3.

    Also SFF is responsible for delivering traffic to any connected s= ervice functions, why not SFF can not be used to manage scale up or down of= service function.

    Also based on NFV MANO architecture, there is reference point bet= ween NFV and NFV manager, NFV manager also can control scale up or down of = service function, I think this case has been covered by =A1=B0through external control=A1=B1 in the draft.

     

    Using sf1 that provide dedicated firewall service to provide load= balancing functionality as well is a little bit weird to me.

    Let me know if my understanding is correct?

     

    Regards!

    -Qin

    =B7=A2=BC=FE=C8=CB: sfc [ma= ilto:sfc-bounces@ietf.org] =B4=FA= =B1=ED Ken Gray (kegray)
    =B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA5=D4=C229=C8=D5 8:49
    =CA=D5=BC=FE=C8=CB: Linda Dunbar
    =B3=AD=CB=CD: Joel M. Halpern; Paul Quinn (paulq); sfc@ietf.org
    =D6=F7=CC=E2: Re: [sfc] questions of "load balancing considerations" in the d= raft-quinn-sfc-arch-05

     

    I don't see how you make the le= ap from the explanation of why it was irrelevant to go into more detail in = the section to the elimination of the very generalized description accompan= ying the figure.  Please use your own argument to justify this and not infer any extra meaning from my answer to= a different question.

     

    As to the second change, i disa= gree.  Again, in general/broad strokes - from the drawing and the text= , it is unlikely that any special action would be required on sf2 or sf4 - = as they collapse in either direction to a single logical next hop.

    Sent from my iPhone

    =
    On May 28, 2014, at 5:49 PM, "Linda Dunbar" <linda.dunbar@huawei.com> wrote:=

    Joel, E= ric, and Ken,

     <= /span>

    Thank y= ou very much for the explanation.

     <= /span>

    Based o= n what you said, the description on how =A1=B0control entity  push to = the sf1 nodes =A1=AD=A1=B1 should be removed from the text, specifically:

     <= /span>

    =A1=B0In this

       case, the c= ontrol entity will push to the sf1 nodes, a table of

    =    sorts:[L1]   sf2 with a series of next hops, and if needed some weighted or

       other metrics (these could als= o be decided locally by some policy,=

       but sf1 would need to be aware= of expand/contract triggers and

       actions).=A1=B1

     <= /span>

     <= /span>

    Should = also change the sentence after the Figure 5 to<= o:p>

     <= /span>

    =A1=B0Either through an imbedded action in = sf1 and sf3, the SFF nodes to which the multiple instances of = SF2 or SF4 are attached, or through external

       control, the service functions= sf2 and sf4 are elastically expanded

       and contracted dynamically.=A1= =B1 

     <= /span>

     <= /span>

    Linda

    From: Ken Gray (kegray) [mailto:kegray@cisco.com]
    Sent: Wednesday, May 28, 2014 4:24 PM
    To: Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern
    Cc: sfc@ietf.org
    Subject: Re: [sfc] questions of "load balancing considerations&= quot; in the draft-quinn-sfc-arch-05    =

     

    +1 to Joel =A1=AD the picture would be ugly at best.  We at= tempted a generic HA/LB slide to make a point and even it was ugly =A1=ADsu= ch are the limitations of ASCII art.=

     

    In line =A1=AD

     

    From: = Linda Dunbar <linda.dunbar@huawei.com>
    Date: Wednesday, May 28, 2014 3:34 PM
    To: "Paul Quinn (paulq)" <paulq@cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.com>
    Cc: "sfc@ietf.org" <= ;sfc@ietf.org>
    Subject: [sfc] questions of "load balancing considerations"= ; in the draft-quinn-sfc-arch-05

     

    Paul and = Joel,

     

    Does the = Load Balancing Figure 5 (of draft-quinn-sfc-arch-05) assume that SF1 is res= ponsible for balancing traffic among the 3 instances of SF2, and SF3 is res= ponsible for balancing traffic among the 3 instances of SF4?

     

    <keg> Document text below the picture says "Either throug= h an imbedded action in sf1 and sf3, or through external

    control, the service functions sf2 and sf4 are elastically expanded&= nbsp;and contracted dynamically."

     

    Isn=A1=AF= t it a single point of failure?

     

    <keg> Document text immediately subsequent to that picture and= paragraph illustrates HA scenarios.=

     

    Some serv= ice functions are Stateful, i.e. they may require packets from same flows t= o traverse the same service function instance. For the Load Balancing schem= e described by Figure 5, do you assume that SF1 and SF3 will be responsible for making sure that same flows go th= rough the same service function instance?<= /o:p>

     

    <keg> Again, the aforementioned text deliberately allows this = responsibility to be either imbedded in the elasticity-causing function or = to be controlled externally or centrally.  We don't get into the mechanics as these can vary.  While stateful/bidir= ectional does add an additional burden, it can be accommodated without an e= xplosion of discrete chains.  For example, it could be handled "a= t allocation time" if elasticity is managed via a separate entity and the individual allocations reflected through service= chain control in the initial metadata bound to at the classification point= in either direction.  OR, if the devices are working as a paired syst= em (single vendor or ecosystem) with integrated elasticity, they could pass metadata between them when sf1 or s= f3 does the initial dynamic allocation (affecting local forwarding on it's = partner).  That's probably not an exhaustive list of ways to solve the= problem.  8^)

     

    <keg> The point of this section was that elasticity and HA sho= uld not cause an inordinate explosion of discrete chains without recommendi= ng a particular solution.  That is,  you shouldn't create unnecessary  complexity where it doesn't need to exist.=

     

    For the s= tateful service functions, if a flow is switched from SF-Instance-X to SF-I= nstance-Y, the SF-Instance-Y needs to synchronize the states from SF-Instan= ce-X. Who is responsible for those states maintenance for the Load Balancing described in Figure 5?

     

    <keg> None of those entities exist in Figure 5.  Can you = re-phrase your question from the figure? <= o:p>

     

    Linda

     

     Require pushing p= olicies to SF1 on how to load balance multiple instances of SF2.

     

    SF1 may not have the capab= ility to balance among multiple instances of SF2

    --_000_B8F9A780D330094D99AF023C5877DABA84546203nkgeml501mbschi_-- From nobody Wed May 28 21:46:04 2014 Return-Path: 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 87C401A0305 for ; Wed, 28 May 2014 21:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 aV_rUl6_hxEX for ; Wed, 28 May 2014 21:46:01 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 235601A0696 for ; Wed, 28 May 2014 21:45:59 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id a108so20432678qge.8 for ; Wed, 28 May 2014 21:45:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Dd8ZyJ5Bgnxdg4Dkt/Lvj3JIl/Pvu46LE1HmN4t9a54=; b=uYTCchXta7ZO/N2QtdobqggxP+gTZIPnbIC/V4JILkW59rFozqQG8GY5OrpHW+F4wu mYXpXtbZDgV+fuoqMHMTopGtQlU5E2+yjfxz+S4y05w3gDq31e9VXYTmI/TxB19r5H4Z A3VuKucmw41k6KjRkSZi7Eo/VmI6wIBdX/30MVaBEL83sYk+5w0UAV9L5UGYEYbmcbCS zsHZ96xiEJ19rB03Qq974VS2soWoe/enfI13Y+3GD+OioGy5ORobhrSADIu22jDMrwmm kt+KKmlcpJO6QMek0fK1HMmpui+avjgTzAmyZxCFHgjYlbjBWCzaktnbs2gpPrvtlIt+ hwIA== X-Received: by 10.140.49.76 with SMTP id p70mr5853516qga.86.1401338754546; Wed, 28 May 2014 21:45:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.86.148 with HTTP; Wed, 28 May 2014 21:45:34 -0700 (PDT) In-Reply-To: <16984558-2B4C-4873-AFC7-DCD2698CA745@cisco.com> References: <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> <16984558-2B4C-4873-AFC7-DCD2698CA745@cisco.com> From: "Andrew G. Malis" Date: Thu, 29 May 2014 00:45:34 -0400 Message-ID: To: "Ken Gray (kegray)" Content-Type: multipart/alternative; boundary=001a11370a34acd24504fa829a1b Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Jl5_zNjreZgmvDvmC-CGwJzCiR0 Cc: "Joel M. Halpern" , "Paul Quinn \(paulq\)" , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 04:46:03 -0000 --001a11370a34acd24504fa829a1b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ken, I agree with Linda's second proposed change, because the control and actions could be in sf1 and sf3, or they could be in SFF nodes that forward packets from sf1 to sf2, and/or from sf3 to sf4. Cheers, Andy On Wed, May 28, 2014 at 8:48 PM, Ken Gray (kegray) wrote= : > I don't see how you make the leap from the explanation of why it was > irrelevant to go into more detail in the section to the elimination of th= e > very generalized description accompanying the figure. Please use your ow= n > argument to justify this and not infer any extra meaning from my answer t= o > a different question. > > As to the second change, i disagree. Again, in general/broad strokes - > from the drawing and the text, it is unlikely that any special action wou= ld > be required on sf2 or sf4 - as they collapse in either direction to a > single logical next hop. > > Sent from my iPhone > > On May 28, 2014, at 5:49 PM, "Linda Dunbar" > wrote: > > Joel, Eric, and Ken, > > > > Thank you very much for the explanation. > > > > Based on what you said, the description on how =E2=80=9Ccontrol entity p= ush to > the sf1 nodes =E2=80=A6=E2=80=9D should be removed from the text, specifi= cally: > > > > =E2=80=9CIn this > > case, the control entity will push to the sf1 nodes, a table of > > sorts:[L1] <#1464573527a48d1a__msocom_1> sf2 with a series of next > hops, and if needed some weighted or > > other metrics (these could also be decided locally by some policy, > > but sf1 would need to be aware of expand/contract triggers and > > actions).=E2=80=9D > > > > > > Should also change the sentence after the Figure 5 to > > > > =E2=80=9CEither through an imbedded action in sf1 and sf3, the SFF nodes = to which > the multiple instances of SF2 or SF4 are attached, or through external > > control, the service functions sf2 and sf4 are elastically expanded > > and contracted dynamically.=E2=80=9D > > > > > > Linda > > --001a11370a34acd24504fa829a1b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Ken,

    I agree with Linda's second pr= oposed change, because the control and actions could be in sf1 and sf3, or = they could be in SFF nodes that forward packets from sf1 to sf2, and/or fro= m sf3 to sf4.

    Cheers,
    Andy
    =
    On Wed, May 28, 2014 at 8:48 PM, Ken Gray (k= egray) <kegray@cisco.com> wrote:
    I don't see how you make the leap from the explanation of why it w= as irrelevant to go into more detail in the section to the elimination of t= he very generalized description accompanying the figure. =C2=A0Please use y= our own argument to justify this and not infer any extra meaning from my answer to a different question.

    As to the second change, i disagree. =C2=A0Again, in general/broad str= okes - from the drawing and the text, it is unlikely that any special actio= n would be required on sf2 or sf4 - as they collapse in either direction to= a single logical next hop.

    Sent from my iPhone

    On May 28, 2014, at 5:49 PM, "Linda Dunbar" <linda.dunbar@huawei.com>= wrote:

    Joel, Eric, and Ken, <= u>

    =C2=A0

    Thank you very much fo= r the explanation.

    =C2=A0

    Based on what you said= , the description on how =E2=80=9Ccontrol entity =C2=A0push to the sf1 node= s =E2=80=A6=E2=80=9D should be removed from the text, specifically:<= u>

    =C2=A0

    =E2=80=9CIn this

    =C2=A0=C2=A0 case, the control entity will push to the sf1 nodes, a table of<= /a>

    =C2=A0=C2=A0 sorts:[L1]=C2=A0 sf2 with a series of next hops, and if needed some weighted or

    =C2=A0=C2=A0 other metrics (these could also be decided lo= cally by some policy,

    =C2=A0=C2=A0 but sf1 would need to be aware of expand/cont= ract triggers and

    =C2=A0=C2=A0 actions).=E2=80=9D

    =C2=A0

    =C2=A0

    Should also change the= sentence after the Figure 5 to

    =C2=A0

    =E2=80=9CEither through an imbedded action in sf1 and sf3, the SFF nodes to which the multiple instances of = SF2 or SF4 are attached, or through external

    =C2=A0=C2=A0 control, the service functions sf2 and sf4 ar= e elastically expanded

    =C2=A0=C2=A0 and contracted dynamically.=E2=80=9D=C2=A0

    =C2=A0

    =C2=A0

    Linda


    --001a11370a34acd24504fa829a1b-- From nobody Thu May 29 06:17:08 2014 Return-Path: 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 897661A0901 for ; Thu, 29 May 2014 06:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 pmaFtbe2c7J1 for ; Thu, 29 May 2014 06:17:05 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE911A090A for ; Thu, 29 May 2014 06:17:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 7D0241C055D; Thu, 29 May 2014 06:17:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-218.clppva.east.verizon.net [70.106.135.218]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 6D3141C077E; Thu, 29 May 2014 06:16:46 -0700 (PDT) Message-ID: <53873333.80807@joelhalpern.com> Date: Thu, 29 May 2014 09:16:35 -0400 From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Qin Wu , "Ken Gray (kegray)" , Linda Dunbar References: , <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> <16984558-2B4C-4873-AFC7-DCD2698CA745@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/NxXDDWN8JqXLk9deATYSSIliF_g Cc: "Joel M. Halpern" , "Paul Quinn \(paulq\)" , "sfc@ietf.org" Subject: Re: [sfc] =?utf-8?b?562U5aSNOiAgcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2lu?= =?utf-8?q?g_considerations=22_in_the_draft-quinn-sfc-arch-05?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:17:07 -0000 I am not following your question. SFF can have a co-located load balancer. Or the load balancer can be transparently behind the SFF, using any number of mechanisms. We are not mandating where it is located. Yours, Joel On 5/28/14, 11:55 PM, Qin Wu wrote: > You are talking about service function scale up and down. > > Since service node can host one or multiple service functions, why > service node can not be used to control scale up or down of service > functions it? > > To avoid share risk failure, service node can be previous service node, > e.g., it can be the one that hosts sf1 or sf3. > > Also SFF is responsible for delivering traffic to any connected service > functions, why not SFF can not be used to manage scale up or down of > service function. > > Also based on NFV MANO architecture, there is reference point between > NFV and NFV manager, NFV manager also can control scale up or down of > service function, I think this case has been covered by “through > external control†in the draft. > > Using sf1 that provide dedicated firewall service to provide load > balancing functionality as well is a little bit weird to me. > > Let me know if my understanding is correct? > > Regards! > > -Qin > > *å‘件人:*sfc [mailto:sfc-bounces@ietf.org] *代表 *Ken Gray (kegray) > *å‘é€æ—¶é—´:*2014å¹´5月29æ—¥8:49 > *收件人:*Linda Dunbar > *抄é€:*Joel M. Halpern; Paul Quinn (paulq); sfc@ietf.org > *主题:*Re: [sfc] questions of "load balancing considerations" in the > draft-quinn-sfc-arch-05 > > I don't see how you make the leap from the explanation of why it was > irrelevant to go into more detail in the section to the elimination of > the very generalized description accompanying the figure. Please use > your own argument to justify this and not infer any extra meaning from > my answer to a different question. > > As to the second change, i disagree. Again, in general/broad strokes - > from the drawing and the text, it is unlikely that any special action > would be required on sf2 or sf4 - as they collapse in either direction > to a single logical next hop. > > Sent from my iPhone > > > On May 28, 2014, at 5:49 PM, "Linda Dunbar" > wrote: > > Joel, Eric, and Ken, > > Thank you very much for the explanation. > > Based on what you said, the description on how “control entity push > to the sf1 nodes …†should be removed from the text, specifically: > > “In this > > case, the control entity will push to the sf1 nodes, a table of > > sorts:[L1] <#_msocom_1> sf2 with a series of next hops, and if > needed some weighted or > > other metrics (these could also be decided locally by some policy, > > but sf1 would need to be aware of expand/contract triggers and > > actions).†> > Should also change the sentence after the Figure 5 to > > “Either through an imbedded action in sf1 and sf3, the SFF nodes to > which the multiple instances of SF2 or SF4 are attached, or through > external > > control, the service functions sf2 and sf4 are elastically expanded > > and contracted dynamically.†> > Linda > > *From:*Ken Gray (kegray) [mailto:kegray@cisco.com] > *Sent:* Wednesday, May 28, 2014 4:24 PM > *To:* Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern > *Cc:* sfc@ietf.org > *Subject:* Re: [sfc] questions of "load balancing considerations" in > the draft-quinn-sfc-arch-05 > > +1 to Joel … the picture would be ugly at best. We attempted a > generic HA/LB slide to make a point and even it was ugly …such are > the limitations of ASCII art. > > In line … > > *From: *Linda Dunbar > > *Date: *Wednesday, May 28, 2014 3:34 PM > *To: *"Paul Quinn (paulq)" >, "Joel M. Halpern" > > *Cc: *"sfc@ietf.org " > > *Subject: *[sfc] questions of "load balancing considerations" in the > draft-quinn-sfc-arch-05 > > Paul and Joel, > > Does the Load Balancing Figure 5 (of draft-quinn-sfc-arch-05) assume > that SF1 is responsible for balancing traffic among the 3 instances > of SF2, and SF3 is responsible for balancing traffic among the 3 > instances of SF4? > > Document text below the picture says "Either through an > imbedded action in sf1 and sf3, or through external > > control, the service functions sf2 and sf4 are elastically > expanded and contracted dynamically." > > Isn’t it a single point of failure? > > Document text immediately subsequent to that picture and > paragraph illustrates HA scenarios. > > Some service functions are Stateful, i.e. they may require packets > from same flows to traverse the same service function instance. For > the Load Balancing scheme described by Figure 5, do you assume that > SF1 and SF3 will be responsible for making sure that same flows go > through the same service function instance? > > Again, the aforementioned text deliberately allows this > responsibility to be either imbedded in the elasticity-causing > function or to be controlled externally or centrally. We don't get > into the mechanics as these can vary. While stateful/bidirectional > does add an additional burden, it can be accommodated without an > explosion of discrete chains. For example, it could be handled "at > allocation time" if elasticity is managed via a separate entity and > the individual allocations reflected through service chain control > in the initial metadata bound to at the classification point in > either direction. OR, if the devices are working as a paired system > (single vendor or ecosystem) with integrated elasticity, they could > pass metadata between them when sf1 or sf3 does the initial dynamic > allocation (affecting local forwarding on it's partner). That's > probably not an exhaustive list of ways to solve the problem. 8^) > > The point of this section was that elasticity and HA should > not cause an inordinate explosion of discrete chains without > recommending a particular solution. That is, you shouldn't create > unnecessary complexity where it doesn't need to exist. > > For the stateful service functions, if a flow is switched from > SF-Instance-X to SF-Instance-Y, the SF-Instance-Y needs to > synchronize the states from SF-Instance-X. Who is responsible for > those states maintenance for the Load Balancing described in Figure 5? > > None of those entities exist in Figure 5. Can you re-phrase > your question from the figure? > > Linda > > ------------------------------------------------------------------------ > > Require pushing policies to SF1 on how to load balance multiple > instances of SF2. > > SF1 may not have the capability to balance among multiple instances of SF2 > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu May 29 06:38:33 2014 Return-Path: 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 465071A0909 for ; Thu, 29 May 2014 06:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 yu6LwD5J7QMi for ; Thu, 29 May 2014 06:38:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C842D1A091D for ; Thu, 29 May 2014 06:38:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BER21976; Thu, 29 May 2014 13:38:20 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 14:37:45 +0100 Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 14:38:05 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml702-chm.china.huawei.com ([169.254.4.56]) with mapi id 14.03.0158.001; Thu, 29 May 2014 06:37:55 -0700 From: Lucy yong To: Linda Dunbar , "Paul Quinn (paulq)" , "Joel M. Halpern" Thread-Topic: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 Thread-Index: AQHPerstZMdFIdMJS0m2VpHCVd0MmJtW/V8AgACLj2A= Date: Thu, 29 May 2014 13:37:54 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453898BF@dfweml701-chm.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.138.124] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D453898BFdfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/FxxbpLrl_qxvtjqoKbQWcMy_ik0 Cc: "sfc@ietf.org" Subject: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:38:31 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D453898BFdfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Linda's point. The architecture should not direct to a partic= ular solution. Suggest replacing the paragraph " Either through an imbedded action in sf1= and sf3, or through external control, the service functions sf2 and sf4 ar= e elastically expanded and contracted dynamically. This would be represent= ed as one chain: s1->s2->s3->s4->s5,..." with the following paragraph after figure 5. Above figure would be represented as one chain: s1->s2->s3->s4->s5, but wit= h multiple paths (not as a number of chains equal to the factorial combinat= ion of potential end-to-end paths). The service functions sf2 and sf4 may b= e elastically expanded and contracted dynamically. The load distribution de= cision toward sf2 and sf4 may be localized or be pushed from control entity= into SFC network components or nodes. For example, s1, sff, or service nod= e. Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Wednesday, May 28, 2014 4:50 PM To: Ken Gray (kegray); Paul Quinn (paulq); Joel M. Halpern Cc: sfc@ietf.org Subject: Re: [sfc] questions of "load balancing considerations" in the draf= t-quinn-sfc-arch-05 Joel, Eric, and Ken, Thank you very much for the explanation. Based on what you said, the description on how "control entity push to the= sf1 nodes ..." should be removed from the text, specifically: "In this case, the control entity will push to the sf1 nodes, a table of sorts:[L1] sf2 with a series of next hops, and if needed some weighted= or other metrics (these could also be decided locally by some policy, but sf1 would need to be aware of expand/contract triggers and actions)." Should also change the sentence after the Figure 5 to "Either through an imbedded action in sf1 and sf3, the SFF nodes to which t= he multiple instances of SF2 or SF4 are attached, or through external control, the service functions sf2 and sf4 are elastically expanded and contracted dynamically." Linda From: Ken Gray (kegray) [mailto:kegray@cisco.com] Sent: Wednesday, May 28, 2014 4:24 PM To: Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern Cc: sfc@ietf.org Subject: Re: [sfc] questions of "load balancing considerations" in the draf= t-quinn-sfc-arch-05 +1 to Joel ... the picture would be ugly at best. We attempted a generic H= A/LB slide to make a point and even it was ugly ...such are the limitations= of ASCII art. In line ... From: Linda Dunbar = > Date: Wednesday, May 28, 2014 3:34 PM To: "Paul Quinn (paulq)" >, "Joel M= . Halpern" > Cc: "sfc@ietf.org" > Subject: [sfc] questions of "load balancing considerations" in the draft-qu= inn-sfc-arch-05 Paul and Joel, Does the Load Balancing Figure 5 (of draft-quinn-sfc-arch-05) assume that S= F1 is responsible for balancing traffic among the 3 instances of SF2, and S= F3 is responsible for balancing traffic among the 3 instances of SF4? Document text below the picture says "Either through an imbedded acti= on in sf1 and sf3, or through external control, the service functions sf2 and sf4 are elastically expanded and con= tracted dynamically." Isn't it a single point of failure? Document text immediately subsequent to that picture and paragraph il= lustrates HA scenarios. Some service functions are Stateful, i.e. they may require packets from sam= e flows to traverse the same service function instance. For the Load Balanc= ing scheme described by Figure 5, do you assume that SF1 and SF3 will be re= sponsible for making sure that same flows go through the same service funct= ion instance? Again, the aforementioned text deliberately allows this responsibilit= y to be either imbedded in the elasticity-causing function or to be control= led externally or centrally. We don't get into the mechanics as these can = vary. While stateful/bidirectional does add an additional burden, it can b= e accommodated without an explosion of discrete chains. For example, it co= uld be handled "at allocation time" if elasticity is managed via a separate= entity and the individual allocations reflected through service chain cont= rol in the initial metadata bound to at the classification point in either = direction. OR, if the devices are working as a paired system (single vendo= r or ecosystem) with integrated elasticity, they could pass metadata betwee= n them when sf1 or sf3 does the initial dynamic allocation (affecting local= forwarding on it's partner). That's probably not an exhaustive list of wa= ys to solve the problem. 8^) The point of this section was that elasticity and HA should not cause= an inordinate explosion of discrete chains without recommending a particul= ar solution. That is, you shouldn't create unnecessary complexity where = it doesn't need to exist. For the stateful service functions, if a flow is switched from SF-Instance-= X to SF-Instance-Y, the SF-Instance-Y needs to synchronize the states from = SF-Instance-X. Who is responsible for those states maintenance for the Load= Balancing described in Figure 5? None of those entities exist in Figure 5. Can you re-phrase your que= stion from the figure? Linda ________________________________ Require pushing policies to SF1 on how to load balance multiple instances = of SF2. SF1 may not have the capability to balance among multiple instances of SF2 --_000_2691CE0099834E4A9C5044EEC662BB9D453898BFdfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    I agree with Linda’= ;s point.  The architecture should not direct to a particular solution= .

     =

    Suggest replacing the pa= ragraph  “ Either through an imbedded action in sf1= and sf3, or through external control, the service functions sf2 and s= f4 are elastically expanded and contracted dynamically.  This w= ould be represented as one chain: s1->s2->s3->s4->s5,...”= ;

     =

    with the following parag= raph after figure 5.  

     

    Above figure would be = represented as one chain: s1->s2->s3->s4->s5, but with multiple= paths (not as a number of chains equal to the factorial combination of pot= ential end-to-end paths). The service functions sf2 and sf4 may be elasti= cally expanded and contracted dynamically. The load dis= tribution decision toward sf2 and sf4 may be localized or be pushed = from control entity into SFC network components or nodes. For example, s1, = sff, or service node.  

     

    Lucy

     

     

     

     

     

     

    From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar
    Sent: Wednesday, May 28, 2014 4:50 PM
    To: Ken Gray (kegray); Paul Quinn (paulq); Joel M. Halpern
    Cc: sfc@ietf.org
    Subject: Re: [sfc] questions of "load balancing considerations&= quot; in the draft-quinn-sfc-arch-05

     

    Joel, Eric, and Ken, <= o:p>

     

    Thank you very much fo= r the explanation.

     

    Based on what you said= , the description on how “control entity  push to the sf1 nodes = …” should be removed from the text, specifically:

     

    “In this

       case, the c= ontrol entity will push to the sf1 nodes, a table of<= /p>

       so= rts:[L= 1]   sf2 with a series of next hops, and if needed some weighted or<= /span>

       other metrics (these could also be decided lo= cally by some policy,

       but sf1 would need to be aware of expand/cont= ract triggers and

       actions).”

     

     

    Should also change the= sentence after the Figure 5 to

     

    “Either through an imbedded action in sf1 and sf3, the SFF nodes to which the multiple instances of = SF2 or SF4 are attached, or through external

       control, the service functions sf2 and sf4 ar= e elastically expanded

       and contracted dynamically.” 

     

     

    Linda

    From: Ken Gray= (kegray) [mailto:kegray@cisco.com]
    Sent: Wednesday, May 28, 2014 4:24 PM
    To: Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern
    Cc: sfc@ietf.org
    Subject: Re: [sfc] questions of "load balancing considerations&= quot; in the draft-quinn-sfc-arch-05

     

    +1 t= o Joel … the picture would be ugly at best.  We attempted a gene= ric HA/LB slide to make a point and even it was ugly …such are the li= mitations of ASCII art.

    &nb= sp;

    In line = …

    &nb= sp;

    From: Linda Dunbar <linda.dunbar@huawei.com>
    Date: Wednesday, May 28, 2014 3:34 PM
    To: "Paul Quinn (paulq)" <paulq@cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.com>
    Cc: "sfc@ietf.org" <= ;sfc@ietf.org>
    Subject: [sfc] questions of "load balancing considerations"= ; in the draft-quinn-sfc-arch-05

    &nb= sp;

    Paul and Joel,

     =

    Does the Load Balancing = Figure 5 (of draft-quinn-sfc-arch-05) assume that SF1 is responsible for ba= lancing traffic among the 3 instances of SF2, and SF3 is responsible for ba= lancing traffic among the 3 instances of SF4?

    &nb= sp;

    <keg&= gt; Document text below the picture says "Either through an imbedded a= ction in sf1 and sf3, or through external

    control,= the service functions sf2 and sf4 are elastically expanded and contra= cted dynamically."

     =

    Isn’t it a single = point of failure?

    &nb= sp;

    <keg&= gt; Document text immediately subsequent to that picture and paragraph illu= strates HA scenarios.

     =

    Some service functions a= re Stateful, i.e. they may require packets from same flows to traverse the = same service function instance. For the Load Balancing scheme described by = Figure 5, do you assume that SF1 and SF3 will be responsible for making sure that same flows go through the sam= e service function instance?

    &nb= sp;

    <keg&= gt; Again, the aforementioned text deliberately allows this responsibility = to be either imbedded in the elasticity-causing function or to be controlle= d externally or centrally.  We don't get into the mechanics as these can vary.  While stateful/bidirectional does a= dd an additional burden, it can be accommodated without an explosion of dis= crete chains.  For example, it could be handled "at allocation ti= me" if elasticity is managed via a separate entity and the individual allocations reflected through service chain control in = the initial metadata bound to at the classification point in either directi= on.  OR, if the devices are working as a paired system (single vendor = or ecosystem) with integrated elasticity, they could pass metadata between them when sf1 or sf3 does the initial dyn= amic allocation (affecting local forwarding on it's partner).  That's = probably not an exhaustive list of ways to solve the problem.  8^)

    &nb= sp;

    <keg&= gt; The point of this section was that elasticity and HA should not cause a= n inordinate explosion of discrete chains without recommending a particular= solution.  That is,  you shouldn't create unnecessary  complexity where it doesn't need to exist.

     =

    For the stateful service= functions, if a flow is switched from SF-Instance-X to SF-Instance-Y, the = SF-Instance-Y needs to synchronize the states from SF-Instance-X. Who is re= sponsible for those states maintenance for the Load Balancing described in Figure 5?

    &nb= sp;

    <keg&= gt; None of those entities exist in Figure 5.  Can you re-phrase your = question from the figure? 

     =

    Linda<= /p>

     =

     Require pushing policies to SF1 on how to load balance= multiple instances of SF2.

     

    SF1 may not have the capability to balance among multiple instances of SF2

    --_000_2691CE0099834E4A9C5044EEC662BB9D453898BFdfweml701chmchi_-- From nobody Thu May 29 06:57:33 2014 Return-Path: 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 74CE71A0943 for ; Thu, 29 May 2014 06:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.552 X-Spam-Level: X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 77vLP1Ym7WSr for ; Thu, 29 May 2014 06:57:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F7771A091C for ; Thu, 29 May 2014 06:57:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHK24690; Thu, 29 May 2014 13:57:13 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 14:56:37 +0100 Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 14:56:56 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml706-chm.china.huawei.com ([169.254.8.4]) with mapi id 14.03.0158.001; Thu, 29 May 2014 06:56:49 -0700 From: Lucy yong To: Joel Halpern Direct , Qin Wu , "Ken Gray (kegray)" , Linda Dunbar Thread-Topic: =?utf-8?B?W3NmY10g562U5aSNOiAgcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2luZyBj?= =?utf-8?Q?onsiderations"_in_the_draft-quinn-sfc-arch-05?= Thread-Index: AQHPevJ+bQj6qZJ1gUuJhU4xSPoA45tX/+KA//+T4OA= Date: Thu, 29 May 2014 13:56:48 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D45389906@dfweml701-chm.china.huawei.com> References: , <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> <16984558-2B4C-4873-AFC7-DCD2698CA745@cisco.com> <53873333.80807@joelhalpern.com> In-Reply-To: <53873333.80807@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.138.124] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/624PrXn7barl4aPdP5yCB3Y93aM Cc: "Joel M. Halpern" , "Paul Quinn \(paulq\)" , "sfc@ietf.org" Subject: Re: [sfc] =?utf-8?b?562U5aSNOiAgcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2lu?= =?utf-8?q?g_considerations=22_in_the_draft-quinn-sfc-arch-05?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:57:24 -0000 SGkgSm9lbCwNCg0KQSBsb2FkIGJhbGFuY2VyIGlzIG5lZWRlZCB0byBzdXBwb3J0IGVsYXN0aWMg ZXhwYW5zaW9uIG9mIGEgc2VydmljZSBmdW5jdGlvbiBhbHRob3VnaCBhIExCIGNhbiBiZSB0cmFu c3BhcmVudGx5IHRvIGEgU0ZDLiANCg0KSXQgaXMgZ29vZCB0byBtZW50aW9uIHRoaXMgaW4gc2Vj dGlvbiA2Lg0KDQpMdWN5ICAgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBz ZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvZWwgSGFscGVy biBEaXJlY3QNClNlbnQ6IFRodXJzZGF5LCBNYXkgMjksIDIwMTQgODoxNyBBTQ0KVG86IFFpbiBX dTsgS2VuIEdyYXkgKGtlZ3JheSk7IExpbmRhIER1bmJhcg0KQ2M6IEpvZWwgTS4gSGFscGVybjsg UGF1bCBRdWlubiAocGF1bHEpOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSDnrZTl pI06IHF1ZXN0aW9ucyBvZiAibG9hZCBiYWxhbmNpbmcgY29uc2lkZXJhdGlvbnMiIGluIHRoZSBk cmFmdC1xdWlubi1zZmMtYXJjaC0wNQ0KDQpJIGFtIG5vdCBmb2xsb3dpbmcgeW91ciBxdWVzdGlv bi4NClNGRiBjYW4gaGF2ZSBhIGNvLWxvY2F0ZWQgbG9hZCBiYWxhbmNlci4gIE9yIHRoZSBsb2Fk IGJhbGFuY2VyIGNhbiBiZSB0cmFuc3BhcmVudGx5IGJlaGluZCB0aGUgU0ZGLCB1c2luZyBhbnkg bnVtYmVyIG9mIG1lY2hhbmlzbXMuDQpXZSBhcmUgbm90IG1hbmRhdGluZyB3aGVyZSBpdCBpcyBs b2NhdGVkLg0KDQpZb3VycywNCkpvZWwNCg0KT24gNS8yOC8xNCwgMTE6NTUgUE0sIFFpbiBXdSB3 cm90ZToNCj4gWW91IGFyZSB0YWxraW5nIGFib3V0IHNlcnZpY2UgZnVuY3Rpb24gc2NhbGUgdXAg YW5kIGRvd24uDQo+DQo+IFNpbmNlIHNlcnZpY2Ugbm9kZSBjYW4gaG9zdCBvbmUgb3IgbXVsdGlw bGUgc2VydmljZSBmdW5jdGlvbnMsIHdoeSANCj4gc2VydmljZSBub2RlIGNhbiBub3QgYmUgdXNl ZCB0byBjb250cm9sIHNjYWxlIHVwIG9yIGRvd24gb2Ygc2VydmljZSANCj4gZnVuY3Rpb25zIGl0 Pw0KPg0KPiBUbyBhdm9pZCBzaGFyZSByaXNrIGZhaWx1cmUsIHNlcnZpY2Ugbm9kZSBjYW4gYmUg cHJldmlvdXMgc2VydmljZSANCj4gbm9kZSwgZS5nLiwgaXQgY2FuIGJlIHRoZSBvbmUgdGhhdCBo b3N0cyBzZjEgb3Igc2YzLg0KPg0KPiBBbHNvIFNGRiBpcyByZXNwb25zaWJsZSBmb3IgZGVsaXZl cmluZyB0cmFmZmljIHRvIGFueSBjb25uZWN0ZWQgDQo+IHNlcnZpY2UgZnVuY3Rpb25zLCB3aHkg bm90IFNGRiBjYW4gbm90IGJlIHVzZWQgdG8gbWFuYWdlIHNjYWxlIHVwIG9yIA0KPiBkb3duIG9m IHNlcnZpY2UgZnVuY3Rpb24uDQo+DQo+IEFsc28gYmFzZWQgb24gTkZWIE1BTk8gYXJjaGl0ZWN0 dXJlLCB0aGVyZSBpcyByZWZlcmVuY2UgcG9pbnQgYmV0d2VlbiANCj4gTkZWIGFuZCBORlYgbWFu YWdlciwgTkZWIG1hbmFnZXIgYWxzbyBjYW4gY29udHJvbCBzY2FsZSB1cCBvciBkb3duIG9mIA0K PiBzZXJ2aWNlIGZ1bmN0aW9uLCBJIHRoaW5rIHRoaXMgY2FzZSBoYXMgYmVlbiBjb3ZlcmVkIGJ5 IOKAnHRocm91Z2ggDQo+IGV4dGVybmFsIGNvbnRyb2zigJ0gaW4gdGhlIGRyYWZ0Lg0KPg0KPiBV c2luZyBzZjEgdGhhdCBwcm92aWRlIGRlZGljYXRlZCBmaXJld2FsbCBzZXJ2aWNlIHRvIHByb3Zp ZGUgbG9hZCANCj4gYmFsYW5jaW5nIGZ1bmN0aW9uYWxpdHkgYXMgd2VsbCBpcyBhIGxpdHRsZSBi aXQgd2VpcmQgdG8gbWUuDQo+DQo+IExldCBtZSBrbm93IGlmIG15IHVuZGVyc3RhbmRpbmcgaXMg Y29ycmVjdD8NCj4NCj4gUmVnYXJkcyENCj4NCj4gLVFpbg0KPg0KPiAq5Y+R5Lu25Lq6OipzZmMg W21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gKuS7o+ihqCAqS2VuIEdyYXkgKGtlZ3JheSkN Cj4gKuWPkemAgeaXtumXtDoqMjAxNOW5tDXmnIgyOeaXpTg6NDkNCj4gKuaUtuS7tuS6ujoqTGlu ZGEgRHVuYmFyDQo+ICrmioTpgIE6KkpvZWwgTS4gSGFscGVybjsgUGF1bCBRdWlubiAocGF1bHEp OyBzZmNAaWV0Zi5vcmcNCj4gKuS4u+mimDoqUmU6IFtzZmNdIHF1ZXN0aW9ucyBvZiAibG9hZCBi YWxhbmNpbmcgY29uc2lkZXJhdGlvbnMiIGluIHRoZQ0KPiBkcmFmdC1xdWlubi1zZmMtYXJjaC0w NQ0KPg0KPiBJIGRvbid0IHNlZSBob3cgeW91IG1ha2UgdGhlIGxlYXAgZnJvbSB0aGUgZXhwbGFu YXRpb24gb2Ygd2h5IGl0IHdhcyANCj4gaXJyZWxldmFudCB0byBnbyBpbnRvIG1vcmUgZGV0YWls IGluIHRoZSBzZWN0aW9uIHRvIHRoZSBlbGltaW5hdGlvbiBvZiANCj4gdGhlIHZlcnkgZ2VuZXJh bGl6ZWQgZGVzY3JpcHRpb24gYWNjb21wYW55aW5nIHRoZSBmaWd1cmUuICBQbGVhc2UgdXNlIA0K PiB5b3VyIG93biBhcmd1bWVudCB0byBqdXN0aWZ5IHRoaXMgYW5kIG5vdCBpbmZlciBhbnkgZXh0 cmEgbWVhbmluZyBmcm9tIA0KPiBteSBhbnN3ZXIgdG8gYSBkaWZmZXJlbnQgcXVlc3Rpb24uDQo+ DQo+IEFzIHRvIHRoZSBzZWNvbmQgY2hhbmdlLCBpIGRpc2FncmVlLiAgQWdhaW4sIGluIGdlbmVy YWwvYnJvYWQgc3Ryb2tlcyANCj4gLSBmcm9tIHRoZSBkcmF3aW5nIGFuZCB0aGUgdGV4dCwgaXQg aXMgdW5saWtlbHkgdGhhdCBhbnkgc3BlY2lhbCANCj4gYWN0aW9uIHdvdWxkIGJlIHJlcXVpcmVk IG9uIHNmMiBvciBzZjQgLSBhcyB0aGV5IGNvbGxhcHNlIGluIGVpdGhlciANCj4gZGlyZWN0aW9u IHRvIGEgc2luZ2xlIGxvZ2ljYWwgbmV4dCBob3AuDQo+DQo+IFNlbnQgZnJvbSBteSBpUGhvbmUN Cj4NCj4NCj4gT24gTWF5IDI4LCAyMDE0LCBhdCA1OjQ5IFBNLCAiTGluZGEgRHVuYmFyIiA8bGlu ZGEuZHVuYmFyQGh1YXdlaS5jb20gDQo+IDxtYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+ PiB3cm90ZToNCj4NCj4gICAgIEpvZWwsIEVyaWMsIGFuZCBLZW4sDQo+DQo+ICAgICBUaGFuayB5 b3UgdmVyeSBtdWNoIGZvciB0aGUgZXhwbGFuYXRpb24uDQo+DQo+ICAgICBCYXNlZCBvbiB3aGF0 IHlvdSBzYWlkLCB0aGUgZGVzY3JpcHRpb24gb24gaG93IOKAnGNvbnRyb2wgZW50aXR5ICBwdXNo DQo+ICAgICB0byB0aGUgc2YxIG5vZGVzIOKApuKAnSBzaG91bGQgYmUgcmVtb3ZlZCBmcm9tIHRo ZSB0ZXh0LCBzcGVjaWZpY2FsbHk6DQo+DQo+ICAgICDigJxJbiB0aGlzDQo+DQo+ICAgICAgICAg Y2FzZSwgdGhlIGNvbnRyb2wgZW50aXR5IHdpbGwgcHVzaCB0byB0aGUgc2YxIG5vZGVzLCBhIHRh YmxlIA0KPiBvZg0KPg0KPiAgICAgICAgIHNvcnRzOltMMV0gPCNfbXNvY29tXzE+IHNmMiB3aXRo IGEgc2VyaWVzIG9mIG5leHQgaG9wcywgYW5kIGlmDQo+ICAgICBuZWVkZWQgc29tZSB3ZWlnaHRl ZCBvcg0KPg0KPiAgICAgICAgIG90aGVyIG1ldHJpY3MgKHRoZXNlIGNvdWxkIGFsc28gYmUgZGVj aWRlZCBsb2NhbGx5IGJ5IHNvbWUgDQo+IHBvbGljeSwNCj4NCj4gICAgICAgICBidXQgc2YxIHdv dWxkIG5lZWQgdG8gYmUgYXdhcmUgb2YgZXhwYW5kL2NvbnRyYWN0IHRyaWdnZXJzIGFuZA0KPg0K PiAgICAgICAgIGFjdGlvbnMpLuKAnQ0KPg0KPiAgICAgU2hvdWxkIGFsc28gY2hhbmdlIHRoZSBz ZW50ZW5jZSBhZnRlciB0aGUgRmlndXJlIDUgdG8NCj4NCj4gICAgIOKAnEVpdGhlciB0aHJvdWdo IGFuIGltYmVkZGVkIGFjdGlvbiBpbiBzZjEgYW5kIHNmMywgdGhlIFNGRiBub2RlcyB0bw0KPiAg ICAgd2hpY2ggdGhlIG11bHRpcGxlIGluc3RhbmNlcyBvZiBTRjIgb3IgU0Y0IGFyZSBhdHRhY2hl ZCwgb3IgdGhyb3VnaA0KPiAgICAgZXh0ZXJuYWwNCj4NCj4gICAgICAgICBjb250cm9sLCB0aGUg c2VydmljZSBmdW5jdGlvbnMgc2YyIGFuZCBzZjQgYXJlIGVsYXN0aWNhbGx5IA0KPiBleHBhbmRl ZA0KPg0KPiAgICAgICAgIGFuZCBjb250cmFjdGVkIGR5bmFtaWNhbGx5LuKAnQ0KPg0KPiAgICAg TGluZGENCj4NCj4gICAgICpGcm9tOipLZW4gR3JheSAoa2VncmF5KSBbbWFpbHRvOmtlZ3JheUBj aXNjby5jb21dDQo+ICAgICAqU2VudDoqIFdlZG5lc2RheSwgTWF5IDI4LCAyMDE0IDQ6MjQgUE0N Cj4gICAgICpUbzoqIExpbmRhIER1bmJhcjsgUGF1bCBRdWlubiAocGF1bHEpOyBKb2VsIE0uIEhh bHBlcm4NCj4gICAgICpDYzoqIHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4g ICAgICpTdWJqZWN0OiogUmU6IFtzZmNdIHF1ZXN0aW9ucyBvZiAibG9hZCBiYWxhbmNpbmcgY29u c2lkZXJhdGlvbnMiIGluDQo+ICAgICB0aGUgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDUNCj4NCj4g ICAgICsxIHRvIEpvZWwg4oCmIHRoZSBwaWN0dXJlIHdvdWxkIGJlIHVnbHkgYXQgYmVzdC4gIFdl IGF0dGVtcHRlZCBhDQo+ICAgICBnZW5lcmljIEhBL0xCIHNsaWRlIHRvIG1ha2UgYSBwb2ludCBh bmQgZXZlbiBpdCB3YXMgdWdseSDigKZzdWNoIGFyZQ0KPiAgICAgdGhlIGxpbWl0YXRpb25zIG9m IEFTQ0lJIGFydC4NCj4NCj4gICAgIEluIGxpbmUg4oCmDQo+DQo+ICAgICAqRnJvbTogKkxpbmRh IER1bmJhciA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20NCj4gICAgIDxtYWlsdG86bGluZGEuZHVu YmFyQGh1YXdlaS5jb20+Pg0KPiAgICAgKkRhdGU6ICpXZWRuZXNkYXksIE1heSAyOCwgMjAxNCAz OjM0IFBNDQo+ICAgICAqVG86ICoiUGF1bCBRdWlubiAocGF1bHEpIiA8cGF1bHFAY2lzY28uY29t DQo+ICAgICA8bWFpbHRvOnBhdWxxQGNpc2NvLmNvbT4+LCAiSm9lbCBNLiBIYWxwZXJuIiA8am1o QGpvZWxoYWxwZXJuLmNvbQ0KPiAgICAgPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4NCj4g ICAgICpDYzogKiJzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+IiA8c2ZjQGlldGYu b3JnDQo+ICAgICA8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQo+ICAgICAqU3ViamVjdDogKltzZmNd IHF1ZXN0aW9ucyBvZiAibG9hZCBiYWxhbmNpbmcgY29uc2lkZXJhdGlvbnMiIGluIHRoZQ0KPiAg ICAgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDUNCj4NCj4gICAgIFBhdWwgYW5kIEpvZWwsDQo+DQo+ ICAgICBEb2VzIHRoZSBMb2FkIEJhbGFuY2luZyBGaWd1cmUgNSAob2YgZHJhZnQtcXVpbm4tc2Zj LWFyY2gtMDUpIGFzc3VtZQ0KPiAgICAgdGhhdCBTRjEgaXMgcmVzcG9uc2libGUgZm9yIGJhbGFu Y2luZyB0cmFmZmljIGFtb25nIHRoZSAzIGluc3RhbmNlcw0KPiAgICAgb2YgU0YyLCBhbmQgU0Yz IGlzIHJlc3BvbnNpYmxlIGZvciBiYWxhbmNpbmcgdHJhZmZpYyBhbW9uZyB0aGUgMw0KPiAgICAg aW5zdGFuY2VzIG9mIFNGND8NCj4NCj4gICAgIDxrZWc+IERvY3VtZW50IHRleHQgYmVsb3cgdGhl IHBpY3R1cmUgc2F5cyAiRWl0aGVyIHRocm91Z2ggYW4NCj4gICAgIGltYmVkZGVkIGFjdGlvbiBp biBzZjEgYW5kIHNmMywgb3IgdGhyb3VnaCBleHRlcm5hbA0KPg0KPiAgICAgY29udHJvbCwgdGhl IHNlcnZpY2UgZnVuY3Rpb25zIHNmMiBhbmQgc2Y0IGFyZSBlbGFzdGljYWxseQ0KPiAgICAgZXhw YW5kZWQgYW5kIGNvbnRyYWN0ZWQgZHluYW1pY2FsbHkuIg0KPg0KPiAgICAgSXNu4oCZdCBpdCBh IHNpbmdsZSBwb2ludCBvZiBmYWlsdXJlPw0KPg0KPiAgICAgPGtlZz4gRG9jdW1lbnQgdGV4dCBp bW1lZGlhdGVseSBzdWJzZXF1ZW50IHRvIHRoYXQgcGljdHVyZSBhbmQNCj4gICAgIHBhcmFncmFw aCBpbGx1c3RyYXRlcyBIQSBzY2VuYXJpb3MuDQo+DQo+ICAgICBTb21lIHNlcnZpY2UgZnVuY3Rp b25zIGFyZSBTdGF0ZWZ1bCwgaS5lLiB0aGV5IG1heSByZXF1aXJlIHBhY2tldHMNCj4gICAgIGZy b20gc2FtZSBmbG93cyB0byB0cmF2ZXJzZSB0aGUgc2FtZSBzZXJ2aWNlIGZ1bmN0aW9uIGluc3Rh bmNlLiBGb3INCj4gICAgIHRoZSBMb2FkIEJhbGFuY2luZyBzY2hlbWUgZGVzY3JpYmVkIGJ5IEZp Z3VyZSA1LCBkbyB5b3UgYXNzdW1lIHRoYXQNCj4gICAgIFNGMSBhbmQgU0YzIHdpbGwgYmUgcmVz cG9uc2libGUgZm9yIG1ha2luZyBzdXJlIHRoYXQgc2FtZSBmbG93cyBnbw0KPiAgICAgdGhyb3Vn aCB0aGUgc2FtZSBzZXJ2aWNlIGZ1bmN0aW9uIGluc3RhbmNlPw0KPg0KPiAgICAgPGtlZz4gQWdh aW4sIHRoZSBhZm9yZW1lbnRpb25lZCB0ZXh0IGRlbGliZXJhdGVseSBhbGxvd3MgdGhpcw0KPiAg ICAgcmVzcG9uc2liaWxpdHkgdG8gYmUgZWl0aGVyIGltYmVkZGVkIGluIHRoZSBlbGFzdGljaXR5 LWNhdXNpbmcNCj4gICAgIGZ1bmN0aW9uIG9yIHRvIGJlIGNvbnRyb2xsZWQgZXh0ZXJuYWxseSBv ciBjZW50cmFsbHkuICBXZSBkb24ndCBnZXQNCj4gICAgIGludG8gdGhlIG1lY2hhbmljcyBhcyB0 aGVzZSBjYW4gdmFyeS4gIFdoaWxlIHN0YXRlZnVsL2JpZGlyZWN0aW9uYWwNCj4gICAgIGRvZXMg YWRkIGFuIGFkZGl0aW9uYWwgYnVyZGVuLCBpdCBjYW4gYmUgYWNjb21tb2RhdGVkIHdpdGhvdXQg YW4NCj4gICAgIGV4cGxvc2lvbiBvZiBkaXNjcmV0ZSBjaGFpbnMuICBGb3IgZXhhbXBsZSwgaXQg Y291bGQgYmUgaGFuZGxlZCAiYXQNCj4gICAgIGFsbG9jYXRpb24gdGltZSIgaWYgZWxhc3RpY2l0 eSBpcyBtYW5hZ2VkIHZpYSBhIHNlcGFyYXRlIGVudGl0eSBhbmQNCj4gICAgIHRoZSBpbmRpdmlk dWFsIGFsbG9jYXRpb25zIHJlZmxlY3RlZCB0aHJvdWdoIHNlcnZpY2UgY2hhaW4gY29udHJvbA0K PiAgICAgaW4gdGhlIGluaXRpYWwgbWV0YWRhdGEgYm91bmQgdG8gYXQgdGhlIGNsYXNzaWZpY2F0 aW9uIHBvaW50IGluDQo+ICAgICBlaXRoZXIgZGlyZWN0aW9uLiAgT1IsIGlmIHRoZSBkZXZpY2Vz IGFyZSB3b3JraW5nIGFzIGEgcGFpcmVkIHN5c3RlbQ0KPiAgICAgKHNpbmdsZSB2ZW5kb3Igb3Ig ZWNvc3lzdGVtKSB3aXRoIGludGVncmF0ZWQgZWxhc3RpY2l0eSwgdGhleSBjb3VsZA0KPiAgICAg cGFzcyBtZXRhZGF0YSBiZXR3ZWVuIHRoZW0gd2hlbiBzZjEgb3Igc2YzIGRvZXMgdGhlIGluaXRp YWwgZHluYW1pYw0KPiAgICAgYWxsb2NhdGlvbiAoYWZmZWN0aW5nIGxvY2FsIGZvcndhcmRpbmcg b24gaXQncyBwYXJ0bmVyKS4gIFRoYXQncw0KPiAgICAgcHJvYmFibHkgbm90IGFuIGV4aGF1c3Rp dmUgbGlzdCBvZiB3YXlzIHRvIHNvbHZlIHRoZSBwcm9ibGVtLiAgOF4pDQo+DQo+ICAgICA8a2Vn PiBUaGUgcG9pbnQgb2YgdGhpcyBzZWN0aW9uIHdhcyB0aGF0IGVsYXN0aWNpdHkgYW5kIEhBIHNo b3VsZA0KPiAgICAgbm90IGNhdXNlIGFuIGlub3JkaW5hdGUgZXhwbG9zaW9uIG9mIGRpc2NyZXRl IGNoYWlucyB3aXRob3V0DQo+ICAgICByZWNvbW1lbmRpbmcgYSBwYXJ0aWN1bGFyIHNvbHV0aW9u LiAgVGhhdCBpcywgIHlvdSBzaG91bGRuJ3QgY3JlYXRlDQo+ICAgICB1bm5lY2Vzc2FyeSAgY29t cGxleGl0eSB3aGVyZSBpdCBkb2Vzbid0IG5lZWQgdG8gZXhpc3QuDQo+DQo+ICAgICBGb3IgdGhl IHN0YXRlZnVsIHNlcnZpY2UgZnVuY3Rpb25zLCBpZiBhIGZsb3cgaXMgc3dpdGNoZWQgZnJvbQ0K PiAgICAgU0YtSW5zdGFuY2UtWCB0byBTRi1JbnN0YW5jZS1ZLCB0aGUgU0YtSW5zdGFuY2UtWSBu ZWVkcyB0bw0KPiAgICAgc3luY2hyb25pemUgdGhlIHN0YXRlcyBmcm9tIFNGLUluc3RhbmNlLVgu IFdobyBpcyByZXNwb25zaWJsZSBmb3INCj4gICAgIHRob3NlIHN0YXRlcyBtYWludGVuYW5jZSBm b3IgdGhlIExvYWQgQmFsYW5jaW5nIGRlc2NyaWJlZCBpbiBGaWd1cmUgNT8NCj4NCj4gICAgIDxr ZWc+IE5vbmUgb2YgdGhvc2UgZW50aXRpZXMgZXhpc3QgaW4gRmlndXJlIDUuICBDYW4geW91IHJl LXBocmFzZQ0KPiAgICAgeW91ciBxdWVzdGlvbiBmcm9tIHRoZSBmaWd1cmU/DQo+DQo+ICAgICBM aW5kYQ0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+DQo+IFJlcXVpcmUgcHVzaGluZyBwb2xp Y2llcyB0byBTRjEgb24gaG93IHRvIGxvYWQgYmFsYW5jZSBtdWx0aXBsZSANCj4gaW5zdGFuY2Vz IG9mIFNGMi4NCj4NCj4gU0YxIG1heSBub3QgaGF2ZSB0aGUgY2FwYWJpbGl0eSB0byBiYWxhbmNl IGFtb25nIG11bHRpcGxlIGluc3RhbmNlcyBvZiANCj4gU0YyDQo+DQo+DQo+DQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWlsaW5nIGxp c3QNCj4gc2ZjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Thu May 29 06:58:45 2014 Return-Path: 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 3C8561A0938 for ; Thu, 29 May 2014 06:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 wi5XSdjNRL93 for ; Thu, 29 May 2014 06:58:40 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87D331A091C for ; Thu, 29 May 2014 06:58:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id C72E21C077E; Thu, 29 May 2014 06:58:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-218.clppva.east.verizon.net [70.106.135.218]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 7A6B11C055D; Thu, 29 May 2014 06:58:35 -0700 (PDT) Message-ID: <53873D0B.3040307@joelhalpern.com> Date: Thu, 29 May 2014 09:58:35 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Lucy yong , Linda Dunbar , "Paul Quinn (paulq)" , "Joel M. Halpern" References: <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D453898BF@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453898BF@dfweml701-chm.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/4gRana4Y0FYiXjp0nuwv_QVC5-M Cc: "sfc@ietf.org" Subject: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:58:42 -0000 I do not know what you are trying to tell the reader by the "but with multiple paths" proposed text in your suggested replacement text. The diagram is trying to show, and the text describes using a single service path. You can also achieve the same effect with multiple paths. Both approaches are currently supported by the architecture. Yours, Joel On 5/29/14, 9:37 AM, Lucy yong wrote: > I agree with Linda’s point. The architecture should not direct to a > particular solution. > > Suggest replacing the paragraph “ Either through an imbedded action in > sf1 and sf3, or through externalcontrol, the service functions sf2 and > sf4 are elastically expandedand contracted dynamically. This would be > represented as one chain:s1->s2->s3->s4->s5,...” > > with the following paragraph after figure 5. > > Above figure would be represented as one chain: s1->s2->s3->s4->s5, but > with multiple paths (not as a number of chains equal to the factorial > combination of potential end-to-end paths). The service functions sf2 > and sf4 may be elastically expandedand contracted dynamically. The load > distribution decision toward sf2 and sf4 may be localized or be pushed > from control entity into SFC network components or nodes. For example, > s1, sff, or service node. > > Lucy > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Linda Dunbar > *Sent:* Wednesday, May 28, 2014 4:50 PM > *To:* Ken Gray (kegray); Paul Quinn (paulq); Joel M. Halpern > *Cc:* sfc@ietf.org > *Subject:* Re: [sfc] questions of "load balancing considerations" in the > draft-quinn-sfc-arch-05 > > Joel, Eric, and Ken, > > Thank you very much for the explanation. > > Based on what you said, the description on how “control entity push to > the sf1 nodes …” should be removed from the text, specifically: > > “In this > > case, the control entity will push to the sf1 nodes, a table of > > sorts:[L1] <#_msocom_1> sf2 with a series of next hops, and if > needed some weighted or > > other metrics (these could also be decided locally by some policy, > > but sf1 would need to be aware of expand/contract triggers and > > actions).” > > Should also change the sentence after the Figure 5 to > > “Either through an imbedded action in sf1 and sf3, the SFF nodes to > which the multiple instances of SF2 or SF4 are attached, or through external > > control, the service functions sf2 and sf4 are elastically expanded > > and contracted dynamically.” > > Linda > > *From:*Ken Gray (kegray) [mailto:kegray@cisco.com] > *Sent:* Wednesday, May 28, 2014 4:24 PM > *To:* Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern > *Cc:* sfc@ietf.org > *Subject:* Re: [sfc] questions of "load balancing considerations" in the > draft-quinn-sfc-arch-05 > > +1 to Joel … the picture would be ugly at best. We attempted a generic > HA/LB slide to make a point and even it was ugly …such are the > limitations of ASCII art. > > In line … > > *From: *Linda Dunbar > > *Date: *Wednesday, May 28, 2014 3:34 PM > *To: *"Paul Quinn (paulq)" >, > "Joel M. Halpern" > > *Cc: *"sfc@ietf.org " > > *Subject: *[sfc] questions of "load balancing considerations" in the > draft-quinn-sfc-arch-05 > > Paul and Joel, > > Does the Load Balancing Figure 5 (of draft-quinn-sfc-arch-05) assume > that SF1 is responsible for balancing traffic among the 3 instances of > SF2, and SF3 is responsible for balancing traffic among the 3 instances > of SF4? > > Document text below the picture says "Either through an imbedded > action in sf1 and sf3, or through external > > control, the service functions sf2 and sf4 are elastically expanded and > contracted dynamically." > > Isn’t it a single point of failure? > > Document text immediately subsequent to that picture and paragraph > illustrates HA scenarios. > > Some service functions are Stateful, i.e. they may require packets from > same flows to traverse the same service function instance. For the Load > Balancing scheme described by Figure 5, do you assume that SF1 and SF3 > will be responsible for making sure that same flows go through the same > service function instance? > > Again, the aforementioned text deliberately allows this > responsibility to be either imbedded in the elasticity-causing function > or to be controlled externally or centrally. We don't get into the > mechanics as these can vary. While stateful/bidirectional does add an > additional burden, it can be accommodated without an explosion of > discrete chains. For example, it could be handled "at allocation time" > if elasticity is managed via a separate entity and the individual > allocations reflected through service chain control in the initial > metadata bound to at the classification point in either direction. OR, > if the devices are working as a paired system (single vendor or > ecosystem) with integrated elasticity, they could pass metadata between > them when sf1 or sf3 does the initial dynamic allocation (affecting > local forwarding on it's partner). That's probably not an exhaustive > list of ways to solve the problem. 8^) > > The point of this section was that elasticity and HA should not > cause an inordinate explosion of discrete chains without recommending a > particular solution. That is, you shouldn't create unnecessary > complexity where it doesn't need to exist. > > For the stateful service functions, if a flow is switched from > SF-Instance-X to SF-Instance-Y, the SF-Instance-Y needs to synchronize > the states from SF-Instance-X. Who is responsible for those states > maintenance for the Load Balancing described in Figure 5? > > None of those entities exist in Figure 5. Can you re-phrase your > question from the figure? > > Linda > > ------------------------------------------------------------------------ > > Require pushing policies to SF1 on how to load balance multiple > instances of SF2. > > SF1 may not have the capability to balance among multiple instances of SF2 > From nobody Thu May 29 07:05:10 2014 Return-Path: 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 4C7581A095B for ; Thu, 29 May 2014 07:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 fD-ZWxAn5N8S for ; Thu, 29 May 2014 07:05:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D85791A094F for ; Thu, 29 May 2014 07:05:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHK25246; Thu, 29 May 2014 14:04:56 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 15:04:24 +0100 Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 15:04:55 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml702-chm.china.huawei.com ([169.254.4.56]) with mapi id 14.03.0158.001; Thu, 29 May 2014 07:04:44 -0700 From: Lucy yong To: "Joel M. Halpern" , Linda Dunbar , "Paul Quinn (paulq)" Thread-Topic: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 Thread-Index: AQHPerstZMdFIdMJS0m2VpHCVd0MmJtW/V8AgACLj2CAAIMegP//i2jQ Date: Thu, 29 May 2014 14:04:43 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D45389936@dfweml701-chm.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D453898BF@dfweml701-chm.china.huawei.com> <53873D0B.3040307@joelhalpern.com> In-Reply-To: <53873D0B.3040307@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.138.124] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/8_cqnc9OiHVCY8wAmUa5AdDgTwE Cc: "sfc@ietf.org" Subject: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 14:05:09 -0000 Hi Joel, I did not create that sentence. It is from current doc. please check. IMO: it is a single SFC, but may be treated as one SFC path or multiple SFC= paths depending on the solutions. Yes, the architecture should allow both. Thanks, Lucy -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Thursday, May 29, 2014 8:59 AM To: Lucy yong; Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern Cc: sfc@ietf.org Subject: Re: [sfc] questions of "load balancing considerations" in the draf= t-quinn-sfc-arch-05 I do not know what you are trying to tell the reader by the "but with multi= ple paths" proposed text in your suggested replacement text. The diagram i= s trying to show, and the text describes using a single service=20 path. You can also achieve the same effect with multiple paths. Both=20 approaches are currently supported by the architecture. Yours, Joel On 5/29/14, 9:37 AM, Lucy yong wrote: > I agree with Linda's point. The architecture should not direct to a=20 > particular solution. > > Suggest replacing the paragraph " Either through an imbedded action=20 > in > sf1 and sf3, or through externalcontrol, the service functions sf2 and > sf4 are elastically expandedand contracted dynamically. This would be=20 > represented as one chain:s1->s2->s3->s4->s5,..." > > with the following paragraph after figure 5. > > Above figure would be represented as one chain: s1->s2->s3->s4->s5,=20 > but with multiple paths (not as a number of chains equal to the=20 > factorial combination of potential end-to-end paths). The service=20 > functions sf2 and sf4 may be elastically expandedand contracted=20 > dynamically. The load distribution decision toward sf2 and sf4 may be=20 > localized or be pushed from control entity into SFC network components=20 > or nodes. For example, s1, sff, or service node. > > Lucy > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Linda Dunbar > *Sent:* Wednesday, May 28, 2014 4:50 PM > *To:* Ken Gray (kegray); Paul Quinn (paulq); Joel M. Halpern > *Cc:* sfc@ietf.org > *Subject:* Re: [sfc] questions of "load balancing considerations" in=20 > the > draft-quinn-sfc-arch-05 > > Joel, Eric, and Ken, > > Thank you very much for the explanation. > > Based on what you said, the description on how "control entity push=20 > to the sf1 nodes ..." should be removed from the text, specifically: > > "In this > > case, the control entity will push to the sf1 nodes, a table of > > sorts:[L1] <#_msocom_1> sf2 with a series of next hops, and if=20 > needed some weighted or > > other metrics (these could also be decided locally by some policy, > > but sf1 would need to be aware of expand/contract triggers and > > actions)." > > Should also change the sentence after the Figure 5 to > > "Either through an imbedded action in sf1 and sf3, the SFF nodes to=20 > which the multiple instances of SF2 or SF4 are attached, or through=20 > external > > control, the service functions sf2 and sf4 are elastically=20 > expanded > > and contracted dynamically." > > Linda > > *From:*Ken Gray (kegray) [mailto:kegray@cisco.com] > *Sent:* Wednesday, May 28, 2014 4:24 PM > *To:* Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern > *Cc:* sfc@ietf.org > *Subject:* Re: [sfc] questions of "load balancing considerations" in=20 > the > draft-quinn-sfc-arch-05 > > +1 to Joel ... the picture would be ugly at best. We attempted a=20 > +generic > HA/LB slide to make a point and even it was ugly ...such are the=20 > limitations of ASCII art. > > In line ... > > *From: *Linda Dunbar > > *Date: *Wednesday, May 28, 2014 3:34 PM > *To: *"Paul Quinn (paulq)" >,=20 > "Joel M. Halpern" > > *Cc: *"sfc@ietf.org " > > *Subject: *[sfc] questions of "load balancing considerations" in the > draft-quinn-sfc-arch-05 > > Paul and Joel, > > Does the Load Balancing Figure 5 (of draft-quinn-sfc-arch-05) assume=20 > that SF1 is responsible for balancing traffic among the 3 instances of=20 > SF2, and SF3 is responsible for balancing traffic among the 3=20 > instances of SF4? > > Document text below the picture says "Either through an imbedded=20 > action in sf1 and sf3, or through external > > control, the service functions sf2 and sf4 are elastically expanded=20 > and contracted dynamically." > > Isn't it a single point of failure? > > Document text immediately subsequent to that picture and=20 > paragraph illustrates HA scenarios. > > Some service functions are Stateful, i.e. they may require packets=20 > from same flows to traverse the same service function instance. For=20 > the Load Balancing scheme described by Figure 5, do you assume that=20 > SF1 and SF3 will be responsible for making sure that same flows go=20 > through the same service function instance? > > Again, the aforementioned text deliberately allows this=20 > responsibility to be either imbedded in the elasticity-causing=20 > function or to be controlled externally or centrally. We don't get=20 > into the mechanics as these can vary. While stateful/bidirectional=20 > does add an additional burden, it can be accommodated without an=20 > explosion of discrete chains. For example, it could be handled "at alloc= ation time" > if elasticity is managed via a separate entity and the individual=20 > allocations reflected through service chain control in the initial=20 > metadata bound to at the classification point in either direction. =20 > OR, if the devices are working as a paired system (single vendor or > ecosystem) with integrated elasticity, they could pass metadata=20 > between them when sf1 or sf3 does the initial dynamic allocation=20 > (affecting local forwarding on it's partner). That's probably not an=20 > exhaustive list of ways to solve the problem. 8^) > > The point of this section was that elasticity and HA should not=20 > cause an inordinate explosion of discrete chains without recommending=20 > a particular solution. That is, you shouldn't create unnecessary > complexity where it doesn't need to exist. > > For the stateful service functions, if a flow is switched from=20 > SF-Instance-X to SF-Instance-Y, the SF-Instance-Y needs to synchronize=20 > the states from SF-Instance-X. Who is responsible for those states=20 > maintenance for the Load Balancing described in Figure 5? > > None of those entities exist in Figure 5. Can you re-phrase=20 > your question from the figure? > > Linda > > ---------------------------------------------------------------------- > -- > > Require pushing policies to SF1 on how to load balance multiple=20 > instances of SF2. > > SF1 may not have the capability to balance among multiple instances of=20 > SF2 > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Thu May 29 07:23:14 2014 Return-Path: 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 E372A1A0960 for ; Thu, 29 May 2014 07:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 DsrVJnUPl_Kk for ; Thu, 29 May 2014 07:23:09 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCBCD1A0948 for ; Thu, 29 May 2014 07:23:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 046811D26B4; Thu, 29 May 2014 07:23:06 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-218.clppva.east.verizon.net [70.106.135.218]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id D2EFB340423; Thu, 29 May 2014 07:23:02 -0700 (PDT) Message-ID: <538742C6.3020303@joelhalpern.com> Date: Thu, 29 May 2014 10:23:02 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Lucy yong , Linda Dunbar , "Paul Quinn (paulq)" References: <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D453898BF@dfweml701-chm.china.huawei.com> <53873D0B.3040307@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D45389936@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D45389936@dfweml701-chm.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Ny1ixjinHxfIgJbMc-PeVTLmf4Y Cc: "sfc@ietf.org" Subject: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 14:23:12 -0000 It looks like that text should be adjusted as you say. Yours, Joel On 5/29/14, 10:04 AM, Lucy yong wrote: > Hi Joel, > > I did not create that sentence. It is from current doc. please check. > IMO: it is a single SFC, but may be treated as one SFC path or multiple SFC paths depending on the solutions. Yes, the architecture should allow both. > > Thanks, > Lucy > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Thursday, May 29, 2014 8:59 AM > To: Lucy yong; Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern > Cc: sfc@ietf.org > Subject: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 > > I do not know what you are trying to tell the reader by the "but with multiple paths" proposed text in your suggested replacement text. The diagram is trying to show, and the text describes using a single service > path. You can also achieve the same effect with multiple paths. Both > approaches are currently supported by the architecture. > > Yours, > Joel > > On 5/29/14, 9:37 AM, Lucy yong wrote: >> I agree with Linda's point. The architecture should not direct to a >> particular solution. >> >> Suggest replacing the paragraph " Either through an imbedded action >> in >> sf1 and sf3, or through externalcontrol, the service functions sf2 and >> sf4 are elastically expandedand contracted dynamically. This would be >> represented as one chain:s1->s2->s3->s4->s5,..." >> >> with the following paragraph after figure 5. >> >> Above figure would be represented as one chain: s1->s2->s3->s4->s5, >> but with multiple paths (not as a number of chains equal to the >> factorial combination of potential end-to-end paths). The service >> functions sf2 and sf4 may be elastically expandedand contracted >> dynamically. The load distribution decision toward sf2 and sf4 may be >> localized or be pushed from control entity into SFC network components >> or nodes. For example, s1, sff, or service node. >> >> Lucy >> >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Linda Dunbar >> *Sent:* Wednesday, May 28, 2014 4:50 PM >> *To:* Ken Gray (kegray); Paul Quinn (paulq); Joel M. Halpern >> *Cc:* sfc@ietf.org >> *Subject:* Re: [sfc] questions of "load balancing considerations" in >> the >> draft-quinn-sfc-arch-05 >> >> Joel, Eric, and Ken, >> >> Thank you very much for the explanation. >> >> Based on what you said, the description on how "control entity push >> to the sf1 nodes ..." should be removed from the text, specifically: >> >> "In this >> >> case, the control entity will push to the sf1 nodes, a table of >> >> sorts:[L1] <#_msocom_1> sf2 with a series of next hops, and if >> needed some weighted or >> >> other metrics (these could also be decided locally by some policy, >> >> but sf1 would need to be aware of expand/contract triggers and >> >> actions)." >> >> Should also change the sentence after the Figure 5 to >> >> "Either through an imbedded action in sf1 and sf3, the SFF nodes to >> which the multiple instances of SF2 or SF4 are attached, or through >> external >> >> control, the service functions sf2 and sf4 are elastically >> expanded >> >> and contracted dynamically." >> >> Linda >> >> *From:*Ken Gray (kegray) [mailto:kegray@cisco.com] >> *Sent:* Wednesday, May 28, 2014 4:24 PM >> *To:* Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern >> *Cc:* sfc@ietf.org >> *Subject:* Re: [sfc] questions of "load balancing considerations" in >> the >> draft-quinn-sfc-arch-05 >> >> +1 to Joel ... the picture would be ugly at best. We attempted a >> +generic >> HA/LB slide to make a point and even it was ugly ...such are the >> limitations of ASCII art. >> >> In line ... >> >> *From: *Linda Dunbar > > >> *Date: *Wednesday, May 28, 2014 3:34 PM >> *To: *"Paul Quinn (paulq)" >, >> "Joel M. Halpern" > >> *Cc: *"sfc@ietf.org " > > >> *Subject: *[sfc] questions of "load balancing considerations" in the >> draft-quinn-sfc-arch-05 >> >> Paul and Joel, >> >> Does the Load Balancing Figure 5 (of draft-quinn-sfc-arch-05) assume >> that SF1 is responsible for balancing traffic among the 3 instances of >> SF2, and SF3 is responsible for balancing traffic among the 3 >> instances of SF4? >> >> Document text below the picture says "Either through an imbedded >> action in sf1 and sf3, or through external >> >> control, the service functions sf2 and sf4 are elastically expanded >> and contracted dynamically." >> >> Isn't it a single point of failure? >> >> Document text immediately subsequent to that picture and >> paragraph illustrates HA scenarios. >> >> Some service functions are Stateful, i.e. they may require packets >> from same flows to traverse the same service function instance. For >> the Load Balancing scheme described by Figure 5, do you assume that >> SF1 and SF3 will be responsible for making sure that same flows go >> through the same service function instance? >> >> Again, the aforementioned text deliberately allows this >> responsibility to be either imbedded in the elasticity-causing >> function or to be controlled externally or centrally. We don't get >> into the mechanics as these can vary. While stateful/bidirectional >> does add an additional burden, it can be accommodated without an >> explosion of discrete chains. For example, it could be handled "at allocation time" >> if elasticity is managed via a separate entity and the individual >> allocations reflected through service chain control in the initial >> metadata bound to at the classification point in either direction. >> OR, if the devices are working as a paired system (single vendor or >> ecosystem) with integrated elasticity, they could pass metadata >> between them when sf1 or sf3 does the initial dynamic allocation >> (affecting local forwarding on it's partner). That's probably not an >> exhaustive list of ways to solve the problem. 8^) >> >> The point of this section was that elasticity and HA should not >> cause an inordinate explosion of discrete chains without recommending >> a particular solution. That is, you shouldn't create unnecessary >> complexity where it doesn't need to exist. >> >> For the stateful service functions, if a flow is switched from >> SF-Instance-X to SF-Instance-Y, the SF-Instance-Y needs to synchronize >> the states from SF-Instance-X. Who is responsible for those states >> maintenance for the Load Balancing described in Figure 5? >> >> None of those entities exist in Figure 5. Can you re-phrase >> your question from the figure? >> >> Linda >> >> ---------------------------------------------------------------------- >> -- >> >> Require pushing policies to SF1 on how to load balance multiple >> instances of SF2. >> >> SF1 may not have the capability to balance among multiple instances of >> SF2 >> > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu May 29 07:24:52 2014 Return-Path: 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 A01F11A0960 for ; Thu, 29 May 2014 07:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 0Mrm78Uav4-c for ; Thu, 29 May 2014 07:24:47 -0700 (PDT) Received: from hub021-ca-2.exch021.serverdata.net (hub021-ca-2.exch021.serverdata.net [64.78.22.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1553B1A0950 for ; Thu, 29 May 2014 07:24:47 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0174.001; Thu, 29 May 2014 07:24:43 -0700 From: Ron Parker To: Lucy yong , Joel Halpern Direct , Qin Wu , "Ken Gray (kegray)" , Linda Dunbar Thread-Topic: =?utf-8?B?W3NmY10g562U5aSNOiAgcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2luZyBj?= =?utf-8?Q?onsiderations"_in_the_draft-quinn-sfc-arch-05?= Thread-Index: AQHPevHnnak294azIUGt2Xtd2dq4OZtX/+OAgAALPAD//5I4wA== Date: Thu, 29 May 2014 14:24:42 +0000 Message-ID: References: , <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> <16984558-2B4C-4873-AFC7-DCD2698CA745@cisco.com> <53873333.80807@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D45389906@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D45389906@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/7PBbI9J-gPaH43c5sIxaDbZ_h-8 Cc: "Joel M. Halpern" , "Paul Quinn \(paulq\)" , "sfc@ietf.org" Subject: Re: [sfc] =?utf-8?b?562U5aSNOiAgcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2lu?= =?utf-8?q?g_considerations=22_in_the_draft-quinn-sfc-arch-05?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 14:24:48 -0000 THVjeSwNCg0KV2hldGhlciBvciBub3QgZHluYW1pYyBleHBhbnNpb24gcmVxdWlyZXMgYSBsb2Fk IGJhbGFuY2VyIGlzIHNwZWNpZmljIHRvIHRoZSBhcmNoaXRlY3R1cmUgb2YgdGhhdCBzZXJ2aWNl IGZ1bmN0aW9uLiAgIFRoZXJlIGFyZSBhcmNoaXRlY3R1cmVzIHRoYXQgYXJlIGludGVybmFsbHkg bG9hZCBiYWxhbmNlZC4NCg0KICAgUm9uDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTHVj eSB5b25nDQpTZW50OiBUaHVyc2RheSwgTWF5IDI5LCAyMDE0IDk6NTcgQU0NClRvOiBKb2VsIEhh bHBlcm4gRGlyZWN0OyBRaW4gV3U7IEtlbiBHcmF5IChrZWdyYXkpOyBMaW5kYSBEdW5iYXINCkNj OiBKb2VsIE0uIEhhbHBlcm47IFBhdWwgUXVpbm4gKHBhdWxxKTsgc2ZjQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW3NmY10g562U5aSNOiBxdWVzdGlvbnMgb2YgImxvYWQgYmFsYW5jaW5nIGNvbnNp ZGVyYXRpb25zIiBpbiB0aGUgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDUNCg0KSGkgSm9lbCwNCg0K QSBsb2FkIGJhbGFuY2VyIGlzIG5lZWRlZCB0byBzdXBwb3J0IGVsYXN0aWMgZXhwYW5zaW9uIG9m IGEgc2VydmljZSBmdW5jdGlvbiBhbHRob3VnaCBhIExCIGNhbiBiZSB0cmFuc3BhcmVudGx5IHRv IGEgU0ZDLiANCg0KSXQgaXMgZ29vZCB0byBtZW50aW9uIHRoaXMgaW4gc2VjdGlvbiA2Lg0KDQpM dWN5ICAgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzZmMgW21haWx0bzpz ZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvZWwgSGFscGVybiBEaXJlY3QNClNl bnQ6IFRodXJzZGF5LCBNYXkgMjksIDIwMTQgODoxNyBBTQ0KVG86IFFpbiBXdTsgS2VuIEdyYXkg KGtlZ3JheSk7IExpbmRhIER1bmJhcg0KQ2M6IEpvZWwgTS4gSGFscGVybjsgUGF1bCBRdWlubiAo cGF1bHEpOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSDnrZTlpI06IHF1ZXN0aW9u cyBvZiAibG9hZCBiYWxhbmNpbmcgY29uc2lkZXJhdGlvbnMiIGluIHRoZSBkcmFmdC1xdWlubi1z ZmMtYXJjaC0wNQ0KDQpJIGFtIG5vdCBmb2xsb3dpbmcgeW91ciBxdWVzdGlvbi4NClNGRiBjYW4g aGF2ZSBhIGNvLWxvY2F0ZWQgbG9hZCBiYWxhbmNlci4gIE9yIHRoZSBsb2FkIGJhbGFuY2VyIGNh biBiZSB0cmFuc3BhcmVudGx5IGJlaGluZCB0aGUgU0ZGLCB1c2luZyBhbnkgbnVtYmVyIG9mIG1l Y2hhbmlzbXMuDQpXZSBhcmUgbm90IG1hbmRhdGluZyB3aGVyZSBpdCBpcyBsb2NhdGVkLg0KDQpZ b3VycywNCkpvZWwNCg0KT24gNS8yOC8xNCwgMTE6NTUgUE0sIFFpbiBXdSB3cm90ZToNCj4gWW91 IGFyZSB0YWxraW5nIGFib3V0IHNlcnZpY2UgZnVuY3Rpb24gc2NhbGUgdXAgYW5kIGRvd24uDQo+ DQo+IFNpbmNlIHNlcnZpY2Ugbm9kZSBjYW4gaG9zdCBvbmUgb3IgbXVsdGlwbGUgc2VydmljZSBm dW5jdGlvbnMsIHdoeSANCj4gc2VydmljZSBub2RlIGNhbiBub3QgYmUgdXNlZCB0byBjb250cm9s IHNjYWxlIHVwIG9yIGRvd24gb2Ygc2VydmljZSANCj4gZnVuY3Rpb25zIGl0Pw0KPg0KPiBUbyBh dm9pZCBzaGFyZSByaXNrIGZhaWx1cmUsIHNlcnZpY2Ugbm9kZSBjYW4gYmUgcHJldmlvdXMgc2Vy dmljZSANCj4gbm9kZSwgZS5nLiwgaXQgY2FuIGJlIHRoZSBvbmUgdGhhdCBob3N0cyBzZjEgb3Ig c2YzLg0KPg0KPiBBbHNvIFNGRiBpcyByZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZyB0cmFmZmlj IHRvIGFueSBjb25uZWN0ZWQgDQo+IHNlcnZpY2UgZnVuY3Rpb25zLCB3aHkgbm90IFNGRiBjYW4g bm90IGJlIHVzZWQgdG8gbWFuYWdlIHNjYWxlIHVwIG9yIA0KPiBkb3duIG9mIHNlcnZpY2UgZnVu Y3Rpb24uDQo+DQo+IEFsc28gYmFzZWQgb24gTkZWIE1BTk8gYXJjaGl0ZWN0dXJlLCB0aGVyZSBp cyByZWZlcmVuY2UgcG9pbnQgYmV0d2VlbiANCj4gTkZWIGFuZCBORlYgbWFuYWdlciwgTkZWIG1h bmFnZXIgYWxzbyBjYW4gY29udHJvbCBzY2FsZSB1cCBvciBkb3duIG9mIA0KPiBzZXJ2aWNlIGZ1 bmN0aW9uLCBJIHRoaW5rIHRoaXMgY2FzZSBoYXMgYmVlbiBjb3ZlcmVkIGJ5IOKAnHRocm91Z2gg DQo+IGV4dGVybmFsIGNvbnRyb2zigJ0gaW4gdGhlIGRyYWZ0Lg0KPg0KPiBVc2luZyBzZjEgdGhh dCBwcm92aWRlIGRlZGljYXRlZCBmaXJld2FsbCBzZXJ2aWNlIHRvIHByb3ZpZGUgbG9hZCANCj4g YmFsYW5jaW5nIGZ1bmN0aW9uYWxpdHkgYXMgd2VsbCBpcyBhIGxpdHRsZSBiaXQgd2VpcmQgdG8g bWUuDQo+DQo+IExldCBtZSBrbm93IGlmIG15IHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdD8NCj4N Cj4gUmVnYXJkcyENCj4NCj4gLVFpbg0KPg0KPiAq5Y+R5Lu25Lq6OipzZmMgW21haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZ10gKuS7o+ihqCAqS2VuIEdyYXkgKGtlZ3JheSkNCj4gKuWPkemAgeaX tumXtDoqMjAxNOW5tDXmnIgyOeaXpTg6NDkNCj4gKuaUtuS7tuS6ujoqTGluZGEgRHVuYmFyDQo+ ICrmioTpgIE6KkpvZWwgTS4gSGFscGVybjsgUGF1bCBRdWlubiAocGF1bHEpOyBzZmNAaWV0Zi5v cmcNCj4gKuS4u+mimDoqUmU6IFtzZmNdIHF1ZXN0aW9ucyBvZiAibG9hZCBiYWxhbmNpbmcgY29u c2lkZXJhdGlvbnMiIGluIHRoZQ0KPiBkcmFmdC1xdWlubi1zZmMtYXJjaC0wNQ0KPg0KPiBJIGRv bid0IHNlZSBob3cgeW91IG1ha2UgdGhlIGxlYXAgZnJvbSB0aGUgZXhwbGFuYXRpb24gb2Ygd2h5 IGl0IHdhcyANCj4gaXJyZWxldmFudCB0byBnbyBpbnRvIG1vcmUgZGV0YWlsIGluIHRoZSBzZWN0 aW9uIHRvIHRoZSBlbGltaW5hdGlvbiBvZiANCj4gdGhlIHZlcnkgZ2VuZXJhbGl6ZWQgZGVzY3Jp cHRpb24gYWNjb21wYW55aW5nIHRoZSBmaWd1cmUuICBQbGVhc2UgdXNlIA0KPiB5b3VyIG93biBh cmd1bWVudCB0byBqdXN0aWZ5IHRoaXMgYW5kIG5vdCBpbmZlciBhbnkgZXh0cmEgbWVhbmluZyBm cm9tIA0KPiBteSBhbnN3ZXIgdG8gYSBkaWZmZXJlbnQgcXVlc3Rpb24uDQo+DQo+IEFzIHRvIHRo ZSBzZWNvbmQgY2hhbmdlLCBpIGRpc2FncmVlLiAgQWdhaW4sIGluIGdlbmVyYWwvYnJvYWQgc3Ry b2tlcw0KPiAtIGZyb20gdGhlIGRyYXdpbmcgYW5kIHRoZSB0ZXh0LCBpdCBpcyB1bmxpa2VseSB0 aGF0IGFueSBzcGVjaWFsIA0KPiBhY3Rpb24gd291bGQgYmUgcmVxdWlyZWQgb24gc2YyIG9yIHNm NCAtIGFzIHRoZXkgY29sbGFwc2UgaW4gZWl0aGVyIA0KPiBkaXJlY3Rpb24gdG8gYSBzaW5nbGUg bG9naWNhbCBuZXh0IGhvcC4NCj4NCj4gU2VudCBmcm9tIG15IGlQaG9uZQ0KPg0KPg0KPiBPbiBN YXkgMjgsIDIwMTQsIGF0IDU6NDkgUE0sICJMaW5kYSBEdW5iYXIiIDxsaW5kYS5kdW5iYXJAaHVh d2VpLmNvbSANCj4gPG1haWx0bzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbT4+IHdyb3RlOg0KPg0K PiAgICAgSm9lbCwgRXJpYywgYW5kIEtlbiwNCj4NCj4gICAgIFRoYW5rIHlvdSB2ZXJ5IG11Y2gg Zm9yIHRoZSBleHBsYW5hdGlvbi4NCj4NCj4gICAgIEJhc2VkIG9uIHdoYXQgeW91IHNhaWQsIHRo ZSBkZXNjcmlwdGlvbiBvbiBob3cg4oCcY29udHJvbCBlbnRpdHkgIHB1c2gNCj4gICAgIHRvIHRo ZSBzZjEgbm9kZXMg4oCm4oCdIHNob3VsZCBiZSByZW1vdmVkIGZyb20gdGhlIHRleHQsIHNwZWNp ZmljYWxseToNCj4NCj4gICAgIOKAnEluIHRoaXMNCj4NCj4gICAgICAgICBjYXNlLCB0aGUgY29u dHJvbCBlbnRpdHkgd2lsbCBwdXNoIHRvIHRoZSBzZjEgbm9kZXMsIGEgdGFibGUgDQo+IG9mDQo+ DQo+ICAgICAgICAgc29ydHM6W0wxXSA8I19tc29jb21fMT4gc2YyIHdpdGggYSBzZXJpZXMgb2Yg bmV4dCBob3BzLCBhbmQgaWYNCj4gICAgIG5lZWRlZCBzb21lIHdlaWdodGVkIG9yDQo+DQo+ICAg ICAgICAgb3RoZXIgbWV0cmljcyAodGhlc2UgY291bGQgYWxzbyBiZSBkZWNpZGVkIGxvY2FsbHkg Ynkgc29tZSANCj4gcG9saWN5LA0KPg0KPiAgICAgICAgIGJ1dCBzZjEgd291bGQgbmVlZCB0byBi ZSBhd2FyZSBvZiBleHBhbmQvY29udHJhY3QgdHJpZ2dlcnMgYW5kDQo+DQo+ICAgICAgICAgYWN0 aW9ucyku4oCdDQo+DQo+ICAgICBTaG91bGQgYWxzbyBjaGFuZ2UgdGhlIHNlbnRlbmNlIGFmdGVy IHRoZSBGaWd1cmUgNSB0bw0KPg0KPiAgICAg4oCcRWl0aGVyIHRocm91Z2ggYW4gaW1iZWRkZWQg YWN0aW9uIGluIHNmMSBhbmQgc2YzLCB0aGUgU0ZGIG5vZGVzIHRvDQo+ICAgICB3aGljaCB0aGUg bXVsdGlwbGUgaW5zdGFuY2VzIG9mIFNGMiBvciBTRjQgYXJlIGF0dGFjaGVkLCBvciB0aHJvdWdo DQo+ICAgICBleHRlcm5hbA0KPg0KPiAgICAgICAgIGNvbnRyb2wsIHRoZSBzZXJ2aWNlIGZ1bmN0 aW9ucyBzZjIgYW5kIHNmNCBhcmUgZWxhc3RpY2FsbHkgDQo+IGV4cGFuZGVkDQo+DQo+ICAgICAg ICAgYW5kIGNvbnRyYWN0ZWQgZHluYW1pY2FsbHku4oCdDQo+DQo+ICAgICBMaW5kYQ0KPg0KPiAg ICAgKkZyb206KktlbiBHcmF5IChrZWdyYXkpIFttYWlsdG86a2VncmF5QGNpc2NvLmNvbV0NCj4g ICAgICpTZW50OiogV2VkbmVzZGF5LCBNYXkgMjgsIDIwMTQgNDoyNCBQTQ0KPiAgICAgKlRvOiog TGluZGEgRHVuYmFyOyBQYXVsIFF1aW5uIChwYXVscSk7IEpvZWwgTS4gSGFscGVybg0KPiAgICAg KkNjOiogc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiAgICAgKlN1YmplY3Q6 KiBSZTogW3NmY10gcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2luZyBjb25zaWRlcmF0aW9ucyIg aW4NCj4gICAgIHRoZSBkcmFmdC1xdWlubi1zZmMtYXJjaC0wNQ0KPg0KPiAgICAgKzEgdG8gSm9l bCDigKYgdGhlIHBpY3R1cmUgd291bGQgYmUgdWdseSBhdCBiZXN0LiAgV2UgYXR0ZW1wdGVkIGEN Cj4gICAgIGdlbmVyaWMgSEEvTEIgc2xpZGUgdG8gbWFrZSBhIHBvaW50IGFuZCBldmVuIGl0IHdh cyB1Z2x5IOKApnN1Y2ggYXJlDQo+ICAgICB0aGUgbGltaXRhdGlvbnMgb2YgQVNDSUkgYXJ0Lg0K Pg0KPiAgICAgSW4gbGluZSDigKYNCj4NCj4gICAgICpGcm9tOiAqTGluZGEgRHVuYmFyIDxsaW5k YS5kdW5iYXJAaHVhd2VpLmNvbQ0KPiAgICAgPG1haWx0bzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNv bT4+DQo+ICAgICAqRGF0ZTogKldlZG5lc2RheSwgTWF5IDI4LCAyMDE0IDM6MzQgUE0NCj4gICAg ICpUbzogKiJQYXVsIFF1aW5uIChwYXVscSkiIDxwYXVscUBjaXNjby5jb20NCj4gICAgIDxtYWls dG86cGF1bHFAY2lzY28uY29tPj4sICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4u Y29tDQo+ICAgICA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+Pg0KPiAgICAgKkNjOiAqInNm Y0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNAaWV0Zi5vcmcNCj4gICAgIDxt YWlsdG86c2ZjQGlldGYub3JnPj4NCj4gICAgICpTdWJqZWN0OiAqW3NmY10gcXVlc3Rpb25zIG9m ICJsb2FkIGJhbGFuY2luZyBjb25zaWRlcmF0aW9ucyIgaW4gdGhlDQo+ICAgICBkcmFmdC1xdWlu bi1zZmMtYXJjaC0wNQ0KPg0KPiAgICAgUGF1bCBhbmQgSm9lbCwNCj4NCj4gICAgIERvZXMgdGhl IExvYWQgQmFsYW5jaW5nIEZpZ3VyZSA1IChvZiBkcmFmdC1xdWlubi1zZmMtYXJjaC0wNSkgYXNz dW1lDQo+ICAgICB0aGF0IFNGMSBpcyByZXNwb25zaWJsZSBmb3IgYmFsYW5jaW5nIHRyYWZmaWMg YW1vbmcgdGhlIDMgaW5zdGFuY2VzDQo+ICAgICBvZiBTRjIsIGFuZCBTRjMgaXMgcmVzcG9uc2li bGUgZm9yIGJhbGFuY2luZyB0cmFmZmljIGFtb25nIHRoZSAzDQo+ICAgICBpbnN0YW5jZXMgb2Yg U0Y0Pw0KPg0KPiAgICAgPGtlZz4gRG9jdW1lbnQgdGV4dCBiZWxvdyB0aGUgcGljdHVyZSBzYXlz ICJFaXRoZXIgdGhyb3VnaCBhbg0KPiAgICAgaW1iZWRkZWQgYWN0aW9uIGluIHNmMSBhbmQgc2Yz LCBvciB0aHJvdWdoIGV4dGVybmFsDQo+DQo+ICAgICBjb250cm9sLCB0aGUgc2VydmljZSBmdW5j dGlvbnMgc2YyIGFuZCBzZjQgYXJlIGVsYXN0aWNhbGx5DQo+ICAgICBleHBhbmRlZCBhbmQgY29u dHJhY3RlZCBkeW5hbWljYWxseS4iDQo+DQo+ICAgICBJc27igJl0IGl0IGEgc2luZ2xlIHBvaW50 IG9mIGZhaWx1cmU/DQo+DQo+ICAgICA8a2VnPiBEb2N1bWVudCB0ZXh0IGltbWVkaWF0ZWx5IHN1 YnNlcXVlbnQgdG8gdGhhdCBwaWN0dXJlIGFuZA0KPiAgICAgcGFyYWdyYXBoIGlsbHVzdHJhdGVz IEhBIHNjZW5hcmlvcy4NCj4NCj4gICAgIFNvbWUgc2VydmljZSBmdW5jdGlvbnMgYXJlIFN0YXRl ZnVsLCBpLmUuIHRoZXkgbWF5IHJlcXVpcmUgcGFja2V0cw0KPiAgICAgZnJvbSBzYW1lIGZsb3dz IHRvIHRyYXZlcnNlIHRoZSBzYW1lIHNlcnZpY2UgZnVuY3Rpb24gaW5zdGFuY2UuIEZvcg0KPiAg ICAgdGhlIExvYWQgQmFsYW5jaW5nIHNjaGVtZSBkZXNjcmliZWQgYnkgRmlndXJlIDUsIGRvIHlv dSBhc3N1bWUgdGhhdA0KPiAgICAgU0YxIGFuZCBTRjMgd2lsbCBiZSByZXNwb25zaWJsZSBmb3Ig bWFraW5nIHN1cmUgdGhhdCBzYW1lIGZsb3dzIGdvDQo+ICAgICB0aHJvdWdoIHRoZSBzYW1lIHNl cnZpY2UgZnVuY3Rpb24gaW5zdGFuY2U/DQo+DQo+ICAgICA8a2VnPiBBZ2FpbiwgdGhlIGFmb3Jl bWVudGlvbmVkIHRleHQgZGVsaWJlcmF0ZWx5IGFsbG93cyB0aGlzDQo+ICAgICByZXNwb25zaWJp bGl0eSB0byBiZSBlaXRoZXIgaW1iZWRkZWQgaW4gdGhlIGVsYXN0aWNpdHktY2F1c2luZw0KPiAg ICAgZnVuY3Rpb24gb3IgdG8gYmUgY29udHJvbGxlZCBleHRlcm5hbGx5IG9yIGNlbnRyYWxseS4g IFdlIGRvbid0IGdldA0KPiAgICAgaW50byB0aGUgbWVjaGFuaWNzIGFzIHRoZXNlIGNhbiB2YXJ5 LiAgV2hpbGUgc3RhdGVmdWwvYmlkaXJlY3Rpb25hbA0KPiAgICAgZG9lcyBhZGQgYW4gYWRkaXRp b25hbCBidXJkZW4sIGl0IGNhbiBiZSBhY2NvbW1vZGF0ZWQgd2l0aG91dCBhbg0KPiAgICAgZXhw bG9zaW9uIG9mIGRpc2NyZXRlIGNoYWlucy4gIEZvciBleGFtcGxlLCBpdCBjb3VsZCBiZSBoYW5k bGVkICJhdA0KPiAgICAgYWxsb2NhdGlvbiB0aW1lIiBpZiBlbGFzdGljaXR5IGlzIG1hbmFnZWQg dmlhIGEgc2VwYXJhdGUgZW50aXR5IGFuZA0KPiAgICAgdGhlIGluZGl2aWR1YWwgYWxsb2NhdGlv bnMgcmVmbGVjdGVkIHRocm91Z2ggc2VydmljZSBjaGFpbiBjb250cm9sDQo+ICAgICBpbiB0aGUg aW5pdGlhbCBtZXRhZGF0YSBib3VuZCB0byBhdCB0aGUgY2xhc3NpZmljYXRpb24gcG9pbnQgaW4N Cj4gICAgIGVpdGhlciBkaXJlY3Rpb24uICBPUiwgaWYgdGhlIGRldmljZXMgYXJlIHdvcmtpbmcg YXMgYSBwYWlyZWQgc3lzdGVtDQo+ICAgICAoc2luZ2xlIHZlbmRvciBvciBlY29zeXN0ZW0pIHdp dGggaW50ZWdyYXRlZCBlbGFzdGljaXR5LCB0aGV5IGNvdWxkDQo+ICAgICBwYXNzIG1ldGFkYXRh IGJldHdlZW4gdGhlbSB3aGVuIHNmMSBvciBzZjMgZG9lcyB0aGUgaW5pdGlhbCBkeW5hbWljDQo+ ICAgICBhbGxvY2F0aW9uIChhZmZlY3RpbmcgbG9jYWwgZm9yd2FyZGluZyBvbiBpdCdzIHBhcnRu ZXIpLiAgVGhhdCdzDQo+ICAgICBwcm9iYWJseSBub3QgYW4gZXhoYXVzdGl2ZSBsaXN0IG9mIHdh eXMgdG8gc29sdmUgdGhlIHByb2JsZW0uICA4XikNCj4NCj4gICAgIDxrZWc+IFRoZSBwb2ludCBv ZiB0aGlzIHNlY3Rpb24gd2FzIHRoYXQgZWxhc3RpY2l0eSBhbmQgSEEgc2hvdWxkDQo+ICAgICBu b3QgY2F1c2UgYW4gaW5vcmRpbmF0ZSBleHBsb3Npb24gb2YgZGlzY3JldGUgY2hhaW5zIHdpdGhv dXQNCj4gICAgIHJlY29tbWVuZGluZyBhIHBhcnRpY3VsYXIgc29sdXRpb24uICBUaGF0IGlzLCAg eW91IHNob3VsZG4ndCBjcmVhdGUNCj4gICAgIHVubmVjZXNzYXJ5ICBjb21wbGV4aXR5IHdoZXJl IGl0IGRvZXNuJ3QgbmVlZCB0byBleGlzdC4NCj4NCj4gICAgIEZvciB0aGUgc3RhdGVmdWwgc2Vy dmljZSBmdW5jdGlvbnMsIGlmIGEgZmxvdyBpcyBzd2l0Y2hlZCBmcm9tDQo+ICAgICBTRi1JbnN0 YW5jZS1YIHRvIFNGLUluc3RhbmNlLVksIHRoZSBTRi1JbnN0YW5jZS1ZIG5lZWRzIHRvDQo+ICAg ICBzeW5jaHJvbml6ZSB0aGUgc3RhdGVzIGZyb20gU0YtSW5zdGFuY2UtWC4gV2hvIGlzIHJlc3Bv bnNpYmxlIGZvcg0KPiAgICAgdGhvc2Ugc3RhdGVzIG1haW50ZW5hbmNlIGZvciB0aGUgTG9hZCBC YWxhbmNpbmcgZGVzY3JpYmVkIGluIEZpZ3VyZSA1Pw0KPg0KPiAgICAgPGtlZz4gTm9uZSBvZiB0 aG9zZSBlbnRpdGllcyBleGlzdCBpbiBGaWd1cmUgNS4gIENhbiB5b3UgcmUtcGhyYXNlDQo+ICAg ICB5b3VyIHF1ZXN0aW9uIGZyb20gdGhlIGZpZ3VyZT8NCj4NCj4gICAgIExpbmRhDQo+DQo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gLS0NCj4NCj4gUmVxdWlyZSBwdXNoaW5nIHBvbGljaWVzIHRvIFNGMSBv biBob3cgdG8gbG9hZCBiYWxhbmNlIG11bHRpcGxlIA0KPiBpbnN0YW5jZXMgb2YgU0YyLg0KPg0K PiBTRjEgbWF5IG5vdCBoYXZlIHRoZSBjYXBhYmlsaXR5IHRvIGJhbGFuY2UgYW1vbmcgbXVsdGlw bGUgaW5zdGFuY2VzIG9mDQo+IFNGMg0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZmMgbWFpbGluZyBsaXN0DQo+IHNmY0BpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxp bmcgbGlzdA0Kc2ZjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMNCg== From nobody Thu May 29 07:25:57 2014 Return-Path: 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 00FAB1A09A0 for ; Thu, 29 May 2014 07:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ViwU50DzLNtW for ; Thu, 29 May 2014 07:25:51 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D5831A0999 for ; Thu, 29 May 2014 07:25:41 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-51-5386f0c7150e Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 88.BC.11744.7C0F6835; Thu, 29 May 2014 10:33:12 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Thu, 29 May 2014 10:25:29 -0400 From: Eric Gray To: Linda Dunbar , "Ken Gray (kegray)" , "Paul Quinn (paulq)" , "Joel M. Halpern" Thread-Topic: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 Thread-Index: AQHPerstNYLhn/ifQS+CjPHej+3iV5tWg/PggAEJnTA= Date: Thu, 29 May 2014 14:25:29 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF632AD0288@eusaamb107.ericsson.se> References: <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPuO6JD23BBrt6OSw+nnrDZDFj+xwW i7stE5ks9r9aymrx5MFWdgdWjym/N7J6tBx5y+qxZMlPJo9zU74zBrBEcdmkpOZklqUW6dsl cGW0zD7MWPDepuLk1IesDYwPDboYOTkkBEwkVnWsZoawxSQu3FvP1sXIxSEkcJRRYuOs+ywg CSGB5YwSLbNMQGw2AQ2JY3fWMoIUiYDEG6/dYQJJMAsoSjy69RvMFhZIkJjS1ccGYosIJErM ednKDmFbSWz9ewOohoODRUBV4l9fOkiYV8BXonPXfyaIXZUSK/fMBGvlFAiTWPJjD1grI9Bx 30+tgVolLnHryXwmiKMFJJbsOQ/1gKjEy8f/WCFsJYmPv+ezQ9TrSdyYOoUNwtaWWLbwNTPE XkGJkzOfsExgFJuFZOwsJC2zkLTMQtKygJFlFSNHaXFqWW66keEmRmBcHZNgc9zBuOCT5SFG AQ5GJR7eB69bg4VYE8uKK3MPMUpzsCiJ8+65VhUsJJCeWJKanZpakFoUX1Sak1p8iJGJg1Oq gdHjyrOZ2j/3izhcijARXOAonTy7NumoruLjdQZrX6x79HRlzMGgIqFfF984dDF/U/gcMfHO 1e55TNzPuWr+P+7kiVWTuMQ+zzrqQ0l0w60H3DJOHxPOMcqpiJtvEgGaY3tmu55qkL/m6YD3 h/o+nxRaZG+l8o5HW/udzbn6CAXV059fnfW/qMRSnJFoqMVcVJwIAEz7Sh2MAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/EiVhnYC74aF54uwQ1nLRSLuxitw Cc: "sfc@ietf.org" Subject: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 14:25:55 -0000 Linda, A few points: 1) probably better not to use MS Word (assuming that is what you used) to a= dd=20 comments to your mail (not sure many people will be able to read them); bes= t to simply include your comment(s) directly. 2) being careful about providing text to ensure that the right context is i= ncluded can help to understand your point. 3) your comments appear (as Ken pointed out in a separate response) not to = be based on what any of us said; in fact, it looks like what you really m= ean is "based on my understanding of what you have said" as a way to make a separate= (but related) point. In your first point, a more complete context would be included if you quote= d this: "The load distribution decision will be localized (in general, although the= re might=20 be macro policy controlling that - which is out of scope for the sake of= a simple=20 example). In this case, the control entity will push to the sf1 nodes, = a table of sorts: sf2 with a series of next hops, and if needed some weighted or ot= her=20 metrics (these could also be decided locally by some policy, but sf1 wou= ld need=20 to be aware of expand/contract triggers and actions). sf1 would use loc= al logic --=20 hash, state table, etc. -- to distribute the chained packets to sf2." This is the entire paragraph, after the first two sentences. I believe the issue with this text is that the authors have improperly pare= nthesized=20 text, making the meaning of this paragraph self-contradictory and rather op= aque on first reading it. In fact, grammatically speaking the entire paragraph is a mess - and that d= oes not help in understanding it. The way I have puzzled it out, the text "[in] this case, the control entity= will push to the sf1 nodes, a table of [some sort: e.g. - ] sf2 with a series of nex= t hops, and=20 [(if needed)] some weighted or other metrics" applies to the text in parent= heses=20 in the preceding sentence (i.e. - "in general, although there might be [a] = macro=20 policy controlling that - ..."). In other words, "this case" refers to the= case where=20 a macro policy is used to control the "local decision" process. As you can see from the way I have hacked up the sentences in my effort to = make sense of them, and the amount of restructuring I think the text requires, i= t is my=20 opinion that the text needs a major rework. For one thing, the complex example given actually doesn't help and should n= ot be included. Assuming I have the meaning correct, I would replace the quoted text above = with: "In the example shown in Figure 5, the load distribution decision for SF2 i= s localized=20 at SF1 (though the decision may be affected by a macro policy provided in= some form by the control entity)." The rest of the previous text only adds confusion as a result of over-stati= ng the example. As a matter of personal preference, I would also use the word "embedded" as the better-known spelling of the word "imbedded" used in the first sentence (and possibly elsewhere in the draft). I agree with Ken that your second suggested change is incorrect. -- Eric =20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Wednesday, May 28, 2014 5:50 PM To: Ken Gray (kegray); Paul Quinn (paulq); Joel M. Halpern Cc: sfc@ietf.org Subject: Re: [sfc] questions of "load balancing considerations" in the draf= t-quinn-sfc-arch-05 Joel, Eric, and Ken,=20 Thank you very much for the explanation.=20 Based on what you said, the description on how "control entity =A0push to t= he sf1 nodes ." should be removed from the text, specifically: "In this =A0=A0 case, the control entity will push to the sf1 nodes, a table of =A0=A0 sorts:=A0 sf2 with a series of next hops, and if needed some weighte= d or =A0=A0 other metrics (these could also be decided locally by some policy, =A0=A0 but sf1 would need to be aware of expand/contract triggers and =A0=A0 actions)."=20 Should also change the sentence after the Figure 5 to "Either through an imbedded action in sf1 and sf3, the SFF nodes to which t= he multiple instances of SF2 or SF4 are attached, or through external =A0=A0 control, the service functions sf2 and sf4 are elastically expanded =A0=A0 and contracted dynamically."=A0=20 Linda From: Ken Gray (kegray) [mailto:kegray@cisco.com]=20 Sent: Wednesday, May 28, 2014 4:24 PM To: Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern Cc: sfc@ietf.org Subject: Re: [sfc] questions of "load balancing considerations" in the draf= t-quinn-sfc-arch-05 +1 to Joel . the picture would be ugly at best. =A0We attempted a generic H= A/LB slide to make a point and even it was ugly .such are the limitations o= f ASCII art. In line . From: Linda Dunbar Date: Wednesday, May 28, 2014 3:34 PM To: "Paul Quinn (paulq)" , "Joel M. Halpern" Cc: "sfc@ietf.org" Subject: [sfc] questions of "load balancing considerations" in the draft-qu= inn-sfc-arch-05 Paul and Joel,=20 =A0 Does the Load Balancing Figure 5 (of draft-quinn-sfc-arch-05) assume that S= F1 is responsible for balancing traffic among the 3 instances of SF2, and S= F3 is responsible for balancing traffic among the 3 instances of SF4? Document text below the picture says "Either through an imbedded acti= on in sf1 and sf3, or through external control, the service functions sf2 and sf4 are elastically expanded=A0and c= ontracted dynamically." =A0 Isn't it a single point of failure? Document text immediately subsequent to that picture and paragraph il= lustrates HA scenarios. =A0 Some service functions are Stateful, i.e. they may require packets from sam= e flows to traverse the same service function instance. For the Load Balanc= ing scheme described by Figure 5, do you assume that SF1 and SF3 will be re= sponsible for making sure that same flows go through the same service funct= ion instance? Again, the aforementioned text deliberately allows this responsibilit= y to be either imbedded in the elasticity-causing function or to be control= led externally or centrally. =A0We don't get into the mechanics as these ca= n vary. =A0While stateful/bidirectional does add an additional burden, it c= an be accommodated without an explosion of discrete chains. =A0For example,= it could be handled "at allocation time" if elasticity is managed via a se= parate entity and the individual allocations reflected through service chai= n control in the initial metadata bound to at the classification point in e= ither direction. =A0OR, if the devices are working as a paired system (sing= le vendor or ecosystem) with integrated elasticity, they could pass metadat= a between them when sf1 or sf3 does the initial dynamic allocation (affecti= ng local forwarding on it's partner). =A0That's probably not an exhaustive = list of ways to solve the problem. =A08^) The point of this section was that elasticity and HA should not cause= an inordinate explosion of discrete chains without recommending a particul= ar solution. =A0That is, =A0you shouldn't create unnecessary =A0complexity = where it doesn't need to exist. =A0 For the stateful service functions, if a flow is switched from SF-Instance-= X to SF-Instance-Y, the SF-Instance-Y needs to synchronize the states from = SF-Instance-X. Who is responsible for those states maintenance for the Load= Balancing described in Figure 5? None of those entities exist in Figure 5. =A0Can you re-phrase your q= uestion from the figure?=A0 =A0 Linda =A0 From nobody Thu May 29 07:31:17 2014 Return-Path: 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 905B91A014D for ; Thu, 29 May 2014 07:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 ePammDVrj7cT for ; Thu, 29 May 2014 07:31:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 613841A0960 for ; Thu, 29 May 2014 07:31:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BER26226; Thu, 29 May 2014 14:31:04 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 15:30:23 +0100 Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 15:30:54 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml706-chm.china.huawei.com ([169.254.8.4]) with mapi id 14.03.0158.001; Thu, 29 May 2014 07:30:47 -0700 From: Lucy yong To: "Joel M. Halpern" , Linda Dunbar , "Paul Quinn (paulq)" Thread-Topic: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 Thread-Index: AQHPerstZMdFIdMJS0m2VpHCVd0MmJtW/V8AgACLj2CAAIMegP//i2jQgAB7bQD//4sd8A== Date: Thu, 29 May 2014 14:30:47 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453899AC@dfweml701-chm.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D453898BF@dfweml701-chm.china.huawei.com> <53873D0B.3040307@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D45389936@dfweml701-chm.china.huawei.com> <538742C6.3020303@joelhalpern.com> In-Reply-To: <538742C6.3020303@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.138.124] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/tHkj4hw6gcDxnbFVJsnuIkr0ldU Cc: "sfc@ietf.org" Subject: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 14:31:15 -0000 Joel, Thanks. Regarding transparency, it may be good to state that a LB may be transparen= tly to a SFC or a SFC path. The former implies multiple SFC Paths; the latt= er is the single SFC path (of course a single SFC). Lucy -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Thursday, May 29, 2014 9:23 AM To: Lucy yong; Linda Dunbar; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: Re: [sfc] questions of "load balancing considerations" in the draf= t-quinn-sfc-arch-05 It looks like that text should be adjusted as you say. Yours, Joel On 5/29/14, 10:04 AM, Lucy yong wrote: > Hi Joel, > > I did not create that sentence. It is from current doc. please check. > IMO: it is a single SFC, but may be treated as one SFC path or multiple S= FC paths depending on the solutions. Yes, the architecture should allow bot= h. > > Thanks, > Lucy > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Thursday, May 29, 2014 8:59 AM > To: Lucy yong; Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern > Cc: sfc@ietf.org > Subject: Re: [sfc] questions of "load balancing considerations" in the=20 > draft-quinn-sfc-arch-05 > > I do not know what you are trying to tell the reader by the "but with mul= tiple paths" proposed text in your suggested replacement text. The diagram= is trying to show, and the text describes using a single service > path. You can also achieve the same effect with multiple paths. Both > approaches are currently supported by the architecture. > > Yours, > Joel > > On 5/29/14, 9:37 AM, Lucy yong wrote: >> I agree with Linda's point. The architecture should not direct to a=20 >> particular solution. >> >> Suggest replacing the paragraph " Either through an imbedded action=20 >> in >> sf1 and sf3, or through externalcontrol, the service functions sf2=20 >> and >> sf4 are elastically expandedand contracted dynamically. This would=20 >> be represented as one chain:s1->s2->s3->s4->s5,..." >> >> with the following paragraph after figure 5. >> >> Above figure would be represented as one chain: s1->s2->s3->s4->s5,=20 >> but with multiple paths (not as a number of chains equal to the=20 >> factorial combination of potential end-to-end paths). The service=20 >> functions sf2 and sf4 may be elastically expandedand contracted=20 >> dynamically. The load distribution decision toward sf2 and sf4 may be=20 >> localized or be pushed from control entity into SFC network=20 >> components or nodes. For example, s1, sff, or service node. >> >> Lucy >> >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Linda Dunbar >> *Sent:* Wednesday, May 28, 2014 4:50 PM >> *To:* Ken Gray (kegray); Paul Quinn (paulq); Joel M. Halpern >> *Cc:* sfc@ietf.org >> *Subject:* Re: [sfc] questions of "load balancing considerations" in=20 >> the >> draft-quinn-sfc-arch-05 >> >> Joel, Eric, and Ken, >> >> Thank you very much for the explanation. >> >> Based on what you said, the description on how "control entity push=20 >> to the sf1 nodes ..." should be removed from the text, specifically: >> >> "In this >> >> case, the control entity will push to the sf1 nodes, a table of >> >> sorts:[L1] <#_msocom_1> sf2 with a series of next hops, and if=20 >> needed some weighted or >> >> other metrics (these could also be decided locally by some=20 >> policy, >> >> but sf1 would need to be aware of expand/contract triggers and >> >> actions)." >> >> Should also change the sentence after the Figure 5 to >> >> "Either through an imbedded action in sf1 and sf3, the SFF nodes to=20 >> which the multiple instances of SF2 or SF4 are attached, or through=20 >> external >> >> control, the service functions sf2 and sf4 are elastically=20 >> expanded >> >> and contracted dynamically." >> >> Linda >> >> *From:*Ken Gray (kegray) [mailto:kegray@cisco.com] >> *Sent:* Wednesday, May 28, 2014 4:24 PM >> *To:* Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern >> *Cc:* sfc@ietf.org >> *Subject:* Re: [sfc] questions of "load balancing considerations" in=20 >> the >> draft-quinn-sfc-arch-05 >> >> +1 to Joel ... the picture would be ugly at best. We attempted a=20 >> +generic >> HA/LB slide to make a point and even it was ugly ...such are the=20 >> limitations of ASCII art. >> >> In line ... >> >> *From: *Linda Dunbar > > >> *Date: *Wednesday, May 28, 2014 3:34 PM >> *To: *"Paul Quinn (paulq)" > >, "Joel M. Halpern" > > >> *Cc: *"sfc@ietf.org " > > >> *Subject: *[sfc] questions of "load balancing considerations" in the >> draft-quinn-sfc-arch-05 >> >> Paul and Joel, >> >> Does the Load Balancing Figure 5 (of draft-quinn-sfc-arch-05) assume=20 >> that SF1 is responsible for balancing traffic among the 3 instances=20 >> of SF2, and SF3 is responsible for balancing traffic among the 3=20 >> instances of SF4? >> >> Document text below the picture says "Either through an=20 >> imbedded action in sf1 and sf3, or through external >> >> control, the service functions sf2 and sf4 are elastically expanded=20 >> and contracted dynamically." >> >> Isn't it a single point of failure? >> >> Document text immediately subsequent to that picture and=20 >> paragraph illustrates HA scenarios. >> >> Some service functions are Stateful, i.e. they may require packets=20 >> from same flows to traverse the same service function instance. For=20 >> the Load Balancing scheme described by Figure 5, do you assume that >> SF1 and SF3 will be responsible for making sure that same flows go=20 >> through the same service function instance? >> >> Again, the aforementioned text deliberately allows this=20 >> responsibility to be either imbedded in the elasticity-causing=20 >> function or to be controlled externally or centrally. We don't get=20 >> into the mechanics as these can vary. While stateful/bidirectional=20 >> does add an additional burden, it can be accommodated without an=20 >> explosion of discrete chains. For example, it could be handled "at allo= cation time" >> if elasticity is managed via a separate entity and the individual=20 >> allocations reflected through service chain control in the initial=20 >> metadata bound to at the classification point in either direction. >> OR, if the devices are working as a paired system (single vendor or >> ecosystem) with integrated elasticity, they could pass metadata=20 >> between them when sf1 or sf3 does the initial dynamic allocation=20 >> (affecting local forwarding on it's partner). That's probably not an=20 >> exhaustive list of ways to solve the problem. 8^) >> >> The point of this section was that elasticity and HA should not=20 >> cause an inordinate explosion of discrete chains without recommending=20 >> a particular solution. That is, you shouldn't create unnecessary >> complexity where it doesn't need to exist. >> >> For the stateful service functions, if a flow is switched from=20 >> SF-Instance-X to SF-Instance-Y, the SF-Instance-Y needs to=20 >> synchronize the states from SF-Instance-X. Who is responsible for=20 >> those states maintenance for the Load Balancing described in Figure 5? >> >> None of those entities exist in Figure 5. Can you re-phrase=20 >> your question from the figure? >> >> Linda >> >> --------------------------------------------------------------------- >> - >> -- >> >> Require pushing policies to SF1 on how to load balance multiple=20 >> instances of SF2. >> >> SF1 may not have the capability to balance among multiple instances=20 >> of >> SF2 >> > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu May 29 07:40:04 2014 Return-Path: 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 940C01A0A22 for ; Thu, 29 May 2014 07:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.552 X-Spam-Level: X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 c2dNENG1-nsg for ; Thu, 29 May 2014 07:39:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EA6C1A099C for ; Thu, 29 May 2014 07:39:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BER26798; Thu, 29 May 2014 14:39:45 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 15:39:13 +0100 Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 15:39:44 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml703-chm.china.huawei.com ([169.254.5.144]) with mapi id 14.03.0158.001; Thu, 29 May 2014 07:39:27 -0700 From: Lucy yong To: Ron Parker , Joel Halpern Direct , Qin Wu , "Ken Gray (kegray)" , Linda Dunbar Thread-Topic: =?utf-8?B?W3NmY10g562U5aSNOiAgcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2luZyBj?= =?utf-8?Q?onsiderations"_in_the_draft-quinn-sfc-arch-05?= Thread-Index: AQHPevJ+bQj6qZJ1gUuJhU4xSPoA45tX/+KA//+T4OCAAH8oAP//jLxw Date: Thu, 29 May 2014 14:39:27 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453899C2@dfweml701-chm.china.huawei.com> References: , <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> <16984558-2B4C-4873-AFC7-DCD2698CA745@cisco.com> <53873333.80807@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D45389906@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.138.124] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Yn4xwY0iqzfeZ5SF9IMj-nc37hc Cc: "Joel M. Halpern" , "Paul Quinn \(paulq\)" , "sfc@ietf.org" Subject: Re: [sfc] =?utf-8?b?562U5aSNOiAgcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2lu?= =?utf-8?q?g_considerations=22_in_the_draft-quinn-sfc-arch-05?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 14:39:59 -0000 SGkgUm9uLA0KDQpJIGFncmVlIHdpdGggd2hhdCB5b3Ugc2FpZC4gSWYgYSBzZXJ2aWNlIGZ1bmN0 aW9uIGR5bmFtaWMgZXhwYW5zaW9uIGlzIGltcGxlbWVudGVkIGFzIGNvbXBsZXRlbHkgaW50ZXJu YWwsIGkuZS4gbG9va3MgbGlrZSBvbmUgU0YgY29tcG9uZW50IGluIFNGQyBuZXR3b3JrcywgSU1P OiBTRkMgYXJjaGl0ZWN0dXJlIGRvZXMgbm90IG5lZWQgc3RlcCBpbnRvIHRoYXQgYW5kIGp1c3Qg dHJlYXQgaXQgYXMgb25lIFNGIGluc3RhbmNlIGluIFNGQyBuZXR3b3Jrcy4gVGhlcmUgYXJlIG90 aGVyIHNjZW5hcmlvcyB3aGVyZSBpbmRpdmlkdWFsIFNGIGluc3RhbmNlcyBleHBvc2UgdG8gdGhl IFNGQyBuZXR3b3JrLCBTRkMgYXJjaGl0ZWN0dXJlIG5lZWRzIHRvIGNvdmVyIHRoYXQuDQoNClRo YW5rcywNCkx1Y3kNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJvbiBQYXJr ZXIgW21haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tXSANClNlbnQ6IFRodXJz ZGF5LCBNYXkgMjksIDIwMTQgOToyNSBBTQ0KVG86IEx1Y3kgeW9uZzsgSm9lbCBIYWxwZXJuIERp cmVjdDsgUWluIFd1OyBLZW4gR3JheSAoa2VncmF5KTsgTGluZGEgRHVuYmFyDQpDYzogSm9lbCBN LiBIYWxwZXJuOyBQYXVsIFF1aW5uIChwYXVscSk7IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUkU6 IFtzZmNdIOetlOWkjTogcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2luZyBjb25zaWRlcmF0aW9u cyIgaW4gdGhlIGRyYWZ0LXF1aW5uLXNmYy1hcmNoLTA1DQoNCkx1Y3ksDQoNCldoZXRoZXIgb3Ig bm90IGR5bmFtaWMgZXhwYW5zaW9uIHJlcXVpcmVzIGEgbG9hZCBiYWxhbmNlciBpcyBzcGVjaWZp YyB0byB0aGUgYXJjaGl0ZWN0dXJlIG9mIHRoYXQgc2VydmljZSBmdW5jdGlvbi4gICBUaGVyZSBh cmUgYXJjaGl0ZWN0dXJlcyB0aGF0IGFyZSBpbnRlcm5hbGx5IGxvYWQgYmFsYW5jZWQuDQoNCiAg IFJvbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzZmMgW21haWx0bzpz ZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEx1Y3kgeW9uZw0KU2VudDogVGh1cnNk YXksIE1heSAyOSwgMjAxNCA5OjU3IEFNDQpUbzogSm9lbCBIYWxwZXJuIERpcmVjdDsgUWluIFd1 OyBLZW4gR3JheSAoa2VncmF5KTsgTGluZGEgRHVuYmFyDQpDYzogSm9lbCBNLiBIYWxwZXJuOyBQ YXVsIFF1aW5uIChwYXVscSk7IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzZmNdIOetlOWk jTogcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2luZyBjb25zaWRlcmF0aW9ucyIgaW4gdGhlIGRy YWZ0LXF1aW5uLXNmYy1hcmNoLTA1DQoNCkhpIEpvZWwsDQoNCkEgbG9hZCBiYWxhbmNlciBpcyBu ZWVkZWQgdG8gc3VwcG9ydCBlbGFzdGljIGV4cGFuc2lvbiBvZiBhIHNlcnZpY2UgZnVuY3Rpb24g YWx0aG91Z2ggYSBMQiBjYW4gYmUgdHJhbnNwYXJlbnRseSB0byBhIFNGQy4gDQoNCkl0IGlzIGdv b2QgdG8gbWVudGlvbiB0aGlzIGluIHNlY3Rpb24gNi4NCg0KTHVjeSAgIA0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBKb2VsIEhhbHBlcm4gRGlyZWN0DQpTZW50OiBUaHVyc2RheSwgTWF5IDI5 LCAyMDE0IDg6MTcgQU0NClRvOiBRaW4gV3U7IEtlbiBHcmF5IChrZWdyYXkpOyBMaW5kYSBEdW5i YXINCkNjOiBKb2VsIE0uIEhhbHBlcm47IFBhdWwgUXVpbm4gKHBhdWxxKTsgc2ZjQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW3NmY10g562U5aSNOiBxdWVzdGlvbnMgb2YgImxvYWQgYmFsYW5jaW5n IGNvbnNpZGVyYXRpb25zIiBpbiB0aGUgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDUNCg0KSSBhbSBu b3QgZm9sbG93aW5nIHlvdXIgcXVlc3Rpb24uDQpTRkYgY2FuIGhhdmUgYSBjby1sb2NhdGVkIGxv YWQgYmFsYW5jZXIuICBPciB0aGUgbG9hZCBiYWxhbmNlciBjYW4gYmUgdHJhbnNwYXJlbnRseSBi ZWhpbmQgdGhlIFNGRiwgdXNpbmcgYW55IG51bWJlciBvZiBtZWNoYW5pc21zLg0KV2UgYXJlIG5v dCBtYW5kYXRpbmcgd2hlcmUgaXQgaXMgbG9jYXRlZC4NCg0KWW91cnMsDQpKb2VsDQoNCk9uIDUv MjgvMTQsIDExOjU1IFBNLCBRaW4gV3Ugd3JvdGU6DQo+IFlvdSBhcmUgdGFsa2luZyBhYm91dCBz ZXJ2aWNlIGZ1bmN0aW9uIHNjYWxlIHVwIGFuZCBkb3duLg0KPg0KPiBTaW5jZSBzZXJ2aWNlIG5v ZGUgY2FuIGhvc3Qgb25lIG9yIG11bHRpcGxlIHNlcnZpY2UgZnVuY3Rpb25zLCB3aHkgDQo+IHNl cnZpY2Ugbm9kZSBjYW4gbm90IGJlIHVzZWQgdG8gY29udHJvbCBzY2FsZSB1cCBvciBkb3duIG9m IHNlcnZpY2UgDQo+IGZ1bmN0aW9ucyBpdD8NCj4NCj4gVG8gYXZvaWQgc2hhcmUgcmlzayBmYWls dXJlLCBzZXJ2aWNlIG5vZGUgY2FuIGJlIHByZXZpb3VzIHNlcnZpY2UgDQo+IG5vZGUsIGUuZy4s IGl0IGNhbiBiZSB0aGUgb25lIHRoYXQgaG9zdHMgc2YxIG9yIHNmMy4NCj4NCj4gQWxzbyBTRkYg aXMgcmVzcG9uc2libGUgZm9yIGRlbGl2ZXJpbmcgdHJhZmZpYyB0byBhbnkgY29ubmVjdGVkIA0K PiBzZXJ2aWNlIGZ1bmN0aW9ucywgd2h5IG5vdCBTRkYgY2FuIG5vdCBiZSB1c2VkIHRvIG1hbmFn ZSBzY2FsZSB1cCBvciANCj4gZG93biBvZiBzZXJ2aWNlIGZ1bmN0aW9uLg0KPg0KPiBBbHNvIGJh c2VkIG9uIE5GViBNQU5PIGFyY2hpdGVjdHVyZSwgdGhlcmUgaXMgcmVmZXJlbmNlIHBvaW50IGJl dHdlZW4gDQo+IE5GViBhbmQgTkZWIG1hbmFnZXIsIE5GViBtYW5hZ2VyIGFsc28gY2FuIGNvbnRy b2wgc2NhbGUgdXAgb3IgZG93biBvZiANCj4gc2VydmljZSBmdW5jdGlvbiwgSSB0aGluayB0aGlz IGNhc2UgaGFzIGJlZW4gY292ZXJlZCBieSDigJx0aHJvdWdoIA0KPiBleHRlcm5hbCBjb250cm9s 4oCdIGluIHRoZSBkcmFmdC4NCj4NCj4gVXNpbmcgc2YxIHRoYXQgcHJvdmlkZSBkZWRpY2F0ZWQg ZmlyZXdhbGwgc2VydmljZSB0byBwcm92aWRlIGxvYWQgDQo+IGJhbGFuY2luZyBmdW5jdGlvbmFs aXR5IGFzIHdlbGwgaXMgYSBsaXR0bGUgYml0IHdlaXJkIHRvIG1lLg0KPg0KPiBMZXQgbWUga25v dyBpZiBteSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3Q/DQo+DQo+IFJlZ2FyZHMhDQo+DQo+IC1R aW4NCj4NCj4gKuWPkeS7tuS6ujoqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddICrk u6PooaggKktlbiBHcmF5IChrZWdyYXkpDQo+ICrlj5HpgIHml7bpl7Q6KjIwMTTlubQ15pyIMjnm l6U4OjQ5DQo+ICrmlLbku7bkuro6KkxpbmRhIER1bmJhcg0KPiAq5oqE6YCBOipKb2VsIE0uIEhh bHBlcm47IFBhdWwgUXVpbm4gKHBhdWxxKTsgc2ZjQGlldGYub3JnDQo+ICrkuLvpopg6KlJlOiBb c2ZjXSBxdWVzdGlvbnMgb2YgImxvYWQgYmFsYW5jaW5nIGNvbnNpZGVyYXRpb25zIiBpbiB0aGUN Cj4gZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDUNCj4NCj4gSSBkb24ndCBzZWUgaG93IHlvdSBtYWtl IHRoZSBsZWFwIGZyb20gdGhlIGV4cGxhbmF0aW9uIG9mIHdoeSBpdCB3YXMgDQo+IGlycmVsZXZh bnQgdG8gZ28gaW50byBtb3JlIGRldGFpbCBpbiB0aGUgc2VjdGlvbiB0byB0aGUgZWxpbWluYXRp b24gb2YgDQo+IHRoZSB2ZXJ5IGdlbmVyYWxpemVkIGRlc2NyaXB0aW9uIGFjY29tcGFueWluZyB0 aGUgZmlndXJlLiAgUGxlYXNlIHVzZSANCj4geW91ciBvd24gYXJndW1lbnQgdG8ganVzdGlmeSB0 aGlzIGFuZCBub3QgaW5mZXIgYW55IGV4dHJhIG1lYW5pbmcgZnJvbSANCj4gbXkgYW5zd2VyIHRv IGEgZGlmZmVyZW50IHF1ZXN0aW9uLg0KPg0KPiBBcyB0byB0aGUgc2Vjb25kIGNoYW5nZSwgaSBk aXNhZ3JlZS4gIEFnYWluLCBpbiBnZW5lcmFsL2Jyb2FkIHN0cm9rZXMNCj4gLSBmcm9tIHRoZSBk cmF3aW5nIGFuZCB0aGUgdGV4dCwgaXQgaXMgdW5saWtlbHkgdGhhdCBhbnkgc3BlY2lhbCANCj4g YWN0aW9uIHdvdWxkIGJlIHJlcXVpcmVkIG9uIHNmMiBvciBzZjQgLSBhcyB0aGV5IGNvbGxhcHNl IGluIGVpdGhlciANCj4gZGlyZWN0aW9uIHRvIGEgc2luZ2xlIGxvZ2ljYWwgbmV4dCBob3AuDQo+ DQo+IFNlbnQgZnJvbSBteSBpUGhvbmUNCj4NCj4NCj4gT24gTWF5IDI4LCAyMDE0LCBhdCA1OjQ5 IFBNLCAiTGluZGEgRHVuYmFyIiA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20gDQo+IDxtYWlsdG86 bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+PiB3cm90ZToNCj4NCj4gICAgIEpvZWwsIEVyaWMsIGFu ZCBLZW4sDQo+DQo+ICAgICBUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB0aGUgZXhwbGFuYXRpb24u DQo+DQo+ICAgICBCYXNlZCBvbiB3aGF0IHlvdSBzYWlkLCB0aGUgZGVzY3JpcHRpb24gb24gaG93 IOKAnGNvbnRyb2wgZW50aXR5ICBwdXNoDQo+ICAgICB0byB0aGUgc2YxIG5vZGVzIOKApuKAnSBz aG91bGQgYmUgcmVtb3ZlZCBmcm9tIHRoZSB0ZXh0LCBzcGVjaWZpY2FsbHk6DQo+DQo+ICAgICDi gJxJbiB0aGlzDQo+DQo+ICAgICAgICAgY2FzZSwgdGhlIGNvbnRyb2wgZW50aXR5IHdpbGwgcHVz aCB0byB0aGUgc2YxIG5vZGVzLCBhIHRhYmxlIA0KPiBvZg0KPg0KPiAgICAgICAgIHNvcnRzOltM MV0gPCNfbXNvY29tXzE+IHNmMiB3aXRoIGEgc2VyaWVzIG9mIG5leHQgaG9wcywgYW5kIGlmDQo+ ICAgICBuZWVkZWQgc29tZSB3ZWlnaHRlZCBvcg0KPg0KPiAgICAgICAgIG90aGVyIG1ldHJpY3Mg KHRoZXNlIGNvdWxkIGFsc28gYmUgZGVjaWRlZCBsb2NhbGx5IGJ5IHNvbWUgDQo+IHBvbGljeSwN Cj4NCj4gICAgICAgICBidXQgc2YxIHdvdWxkIG5lZWQgdG8gYmUgYXdhcmUgb2YgZXhwYW5kL2Nv bnRyYWN0IHRyaWdnZXJzIGFuZA0KPg0KPiAgICAgICAgIGFjdGlvbnMpLuKAnQ0KPg0KPiAgICAg U2hvdWxkIGFsc28gY2hhbmdlIHRoZSBzZW50ZW5jZSBhZnRlciB0aGUgRmlndXJlIDUgdG8NCj4N Cj4gICAgIOKAnEVpdGhlciB0aHJvdWdoIGFuIGltYmVkZGVkIGFjdGlvbiBpbiBzZjEgYW5kIHNm MywgdGhlIFNGRiBub2RlcyB0bw0KPiAgICAgd2hpY2ggdGhlIG11bHRpcGxlIGluc3RhbmNlcyBv ZiBTRjIgb3IgU0Y0IGFyZSBhdHRhY2hlZCwgb3IgdGhyb3VnaA0KPiAgICAgZXh0ZXJuYWwNCj4N Cj4gICAgICAgICBjb250cm9sLCB0aGUgc2VydmljZSBmdW5jdGlvbnMgc2YyIGFuZCBzZjQgYXJl IGVsYXN0aWNhbGx5IA0KPiBleHBhbmRlZA0KPg0KPiAgICAgICAgIGFuZCBjb250cmFjdGVkIGR5 bmFtaWNhbGx5LuKAnQ0KPg0KPiAgICAgTGluZGENCj4NCj4gICAgICpGcm9tOipLZW4gR3JheSAo a2VncmF5KSBbbWFpbHRvOmtlZ3JheUBjaXNjby5jb21dDQo+ICAgICAqU2VudDoqIFdlZG5lc2Rh eSwgTWF5IDI4LCAyMDE0IDQ6MjQgUE0NCj4gICAgICpUbzoqIExpbmRhIER1bmJhcjsgUGF1bCBR dWlubiAocGF1bHEpOyBKb2VsIE0uIEhhbHBlcm4NCj4gICAgICpDYzoqIHNmY0BpZXRmLm9yZyA8 bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gICAgICpTdWJqZWN0OiogUmU6IFtzZmNdIHF1ZXN0aW9u cyBvZiAibG9hZCBiYWxhbmNpbmcgY29uc2lkZXJhdGlvbnMiIGluDQo+ICAgICB0aGUgZHJhZnQt cXVpbm4tc2ZjLWFyY2gtMDUNCj4NCj4gICAgICsxIHRvIEpvZWwg4oCmIHRoZSBwaWN0dXJlIHdv dWxkIGJlIHVnbHkgYXQgYmVzdC4gIFdlIGF0dGVtcHRlZCBhDQo+ICAgICBnZW5lcmljIEhBL0xC IHNsaWRlIHRvIG1ha2UgYSBwb2ludCBhbmQgZXZlbiBpdCB3YXMgdWdseSDigKZzdWNoIGFyZQ0K PiAgICAgdGhlIGxpbWl0YXRpb25zIG9mIEFTQ0lJIGFydC4NCj4NCj4gICAgIEluIGxpbmUg4oCm DQo+DQo+ICAgICAqRnJvbTogKkxpbmRhIER1bmJhciA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20N Cj4gICAgIDxtYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+Pg0KPiAgICAgKkRhdGU6ICpX ZWRuZXNkYXksIE1heSAyOCwgMjAxNCAzOjM0IFBNDQo+ICAgICAqVG86ICoiUGF1bCBRdWlubiAo cGF1bHEpIiA8cGF1bHFAY2lzY28uY29tDQo+ICAgICA8bWFpbHRvOnBhdWxxQGNpc2NvLmNvbT4+ LCAiSm9lbCBNLiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbQ0KPiAgICAgPG1haWx0bzpq bWhAam9lbGhhbHBlcm4uY29tPj4NCj4gICAgICpDYzogKiJzZmNAaWV0Zi5vcmcgPG1haWx0bzpz ZmNAaWV0Zi5vcmc+IiA8c2ZjQGlldGYub3JnDQo+ICAgICA8bWFpbHRvOnNmY0BpZXRmLm9yZz4+ DQo+ICAgICAqU3ViamVjdDogKltzZmNdIHF1ZXN0aW9ucyBvZiAibG9hZCBiYWxhbmNpbmcgY29u c2lkZXJhdGlvbnMiIGluIHRoZQ0KPiAgICAgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDUNCj4NCj4g ICAgIFBhdWwgYW5kIEpvZWwsDQo+DQo+ICAgICBEb2VzIHRoZSBMb2FkIEJhbGFuY2luZyBGaWd1 cmUgNSAob2YgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDUpIGFzc3VtZQ0KPiAgICAgdGhhdCBTRjEg aXMgcmVzcG9uc2libGUgZm9yIGJhbGFuY2luZyB0cmFmZmljIGFtb25nIHRoZSAzIGluc3RhbmNl cw0KPiAgICAgb2YgU0YyLCBhbmQgU0YzIGlzIHJlc3BvbnNpYmxlIGZvciBiYWxhbmNpbmcgdHJh ZmZpYyBhbW9uZyB0aGUgMw0KPiAgICAgaW5zdGFuY2VzIG9mIFNGND8NCj4NCj4gICAgIDxrZWc+ IERvY3VtZW50IHRleHQgYmVsb3cgdGhlIHBpY3R1cmUgc2F5cyAiRWl0aGVyIHRocm91Z2ggYW4N Cj4gICAgIGltYmVkZGVkIGFjdGlvbiBpbiBzZjEgYW5kIHNmMywgb3IgdGhyb3VnaCBleHRlcm5h bA0KPg0KPiAgICAgY29udHJvbCwgdGhlIHNlcnZpY2UgZnVuY3Rpb25zIHNmMiBhbmQgc2Y0IGFy ZSBlbGFzdGljYWxseQ0KPiAgICAgZXhwYW5kZWQgYW5kIGNvbnRyYWN0ZWQgZHluYW1pY2FsbHku Ig0KPg0KPiAgICAgSXNu4oCZdCBpdCBhIHNpbmdsZSBwb2ludCBvZiBmYWlsdXJlPw0KPg0KPiAg ICAgPGtlZz4gRG9jdW1lbnQgdGV4dCBpbW1lZGlhdGVseSBzdWJzZXF1ZW50IHRvIHRoYXQgcGlj dHVyZSBhbmQNCj4gICAgIHBhcmFncmFwaCBpbGx1c3RyYXRlcyBIQSBzY2VuYXJpb3MuDQo+DQo+ ICAgICBTb21lIHNlcnZpY2UgZnVuY3Rpb25zIGFyZSBTdGF0ZWZ1bCwgaS5lLiB0aGV5IG1heSBy ZXF1aXJlIHBhY2tldHMNCj4gICAgIGZyb20gc2FtZSBmbG93cyB0byB0cmF2ZXJzZSB0aGUgc2Ft ZSBzZXJ2aWNlIGZ1bmN0aW9uIGluc3RhbmNlLiBGb3INCj4gICAgIHRoZSBMb2FkIEJhbGFuY2lu ZyBzY2hlbWUgZGVzY3JpYmVkIGJ5IEZpZ3VyZSA1LCBkbyB5b3UgYXNzdW1lIHRoYXQNCj4gICAg IFNGMSBhbmQgU0YzIHdpbGwgYmUgcmVzcG9uc2libGUgZm9yIG1ha2luZyBzdXJlIHRoYXQgc2Ft ZSBmbG93cyBnbw0KPiAgICAgdGhyb3VnaCB0aGUgc2FtZSBzZXJ2aWNlIGZ1bmN0aW9uIGluc3Rh bmNlPw0KPg0KPiAgICAgPGtlZz4gQWdhaW4sIHRoZSBhZm9yZW1lbnRpb25lZCB0ZXh0IGRlbGli ZXJhdGVseSBhbGxvd3MgdGhpcw0KPiAgICAgcmVzcG9uc2liaWxpdHkgdG8gYmUgZWl0aGVyIGlt YmVkZGVkIGluIHRoZSBlbGFzdGljaXR5LWNhdXNpbmcNCj4gICAgIGZ1bmN0aW9uIG9yIHRvIGJl IGNvbnRyb2xsZWQgZXh0ZXJuYWxseSBvciBjZW50cmFsbHkuICBXZSBkb24ndCBnZXQNCj4gICAg IGludG8gdGhlIG1lY2hhbmljcyBhcyB0aGVzZSBjYW4gdmFyeS4gIFdoaWxlIHN0YXRlZnVsL2Jp ZGlyZWN0aW9uYWwNCj4gICAgIGRvZXMgYWRkIGFuIGFkZGl0aW9uYWwgYnVyZGVuLCBpdCBjYW4g YmUgYWNjb21tb2RhdGVkIHdpdGhvdXQgYW4NCj4gICAgIGV4cGxvc2lvbiBvZiBkaXNjcmV0ZSBj aGFpbnMuICBGb3IgZXhhbXBsZSwgaXQgY291bGQgYmUgaGFuZGxlZCAiYXQNCj4gICAgIGFsbG9j YXRpb24gdGltZSIgaWYgZWxhc3RpY2l0eSBpcyBtYW5hZ2VkIHZpYSBhIHNlcGFyYXRlIGVudGl0 eSBhbmQNCj4gICAgIHRoZSBpbmRpdmlkdWFsIGFsbG9jYXRpb25zIHJlZmxlY3RlZCB0aHJvdWdo IHNlcnZpY2UgY2hhaW4gY29udHJvbA0KPiAgICAgaW4gdGhlIGluaXRpYWwgbWV0YWRhdGEgYm91 bmQgdG8gYXQgdGhlIGNsYXNzaWZpY2F0aW9uIHBvaW50IGluDQo+ICAgICBlaXRoZXIgZGlyZWN0 aW9uLiAgT1IsIGlmIHRoZSBkZXZpY2VzIGFyZSB3b3JraW5nIGFzIGEgcGFpcmVkIHN5c3RlbQ0K PiAgICAgKHNpbmdsZSB2ZW5kb3Igb3IgZWNvc3lzdGVtKSB3aXRoIGludGVncmF0ZWQgZWxhc3Rp Y2l0eSwgdGhleSBjb3VsZA0KPiAgICAgcGFzcyBtZXRhZGF0YSBiZXR3ZWVuIHRoZW0gd2hlbiBz ZjEgb3Igc2YzIGRvZXMgdGhlIGluaXRpYWwgZHluYW1pYw0KPiAgICAgYWxsb2NhdGlvbiAoYWZm ZWN0aW5nIGxvY2FsIGZvcndhcmRpbmcgb24gaXQncyBwYXJ0bmVyKS4gIFRoYXQncw0KPiAgICAg cHJvYmFibHkgbm90IGFuIGV4aGF1c3RpdmUgbGlzdCBvZiB3YXlzIHRvIHNvbHZlIHRoZSBwcm9i bGVtLiAgOF4pDQo+DQo+ICAgICA8a2VnPiBUaGUgcG9pbnQgb2YgdGhpcyBzZWN0aW9uIHdhcyB0 aGF0IGVsYXN0aWNpdHkgYW5kIEhBIHNob3VsZA0KPiAgICAgbm90IGNhdXNlIGFuIGlub3JkaW5h dGUgZXhwbG9zaW9uIG9mIGRpc2NyZXRlIGNoYWlucyB3aXRob3V0DQo+ICAgICByZWNvbW1lbmRp bmcgYSBwYXJ0aWN1bGFyIHNvbHV0aW9uLiAgVGhhdCBpcywgIHlvdSBzaG91bGRuJ3QgY3JlYXRl DQo+ICAgICB1bm5lY2Vzc2FyeSAgY29tcGxleGl0eSB3aGVyZSBpdCBkb2Vzbid0IG5lZWQgdG8g ZXhpc3QuDQo+DQo+ICAgICBGb3IgdGhlIHN0YXRlZnVsIHNlcnZpY2UgZnVuY3Rpb25zLCBpZiBh IGZsb3cgaXMgc3dpdGNoZWQgZnJvbQ0KPiAgICAgU0YtSW5zdGFuY2UtWCB0byBTRi1JbnN0YW5j ZS1ZLCB0aGUgU0YtSW5zdGFuY2UtWSBuZWVkcyB0bw0KPiAgICAgc3luY2hyb25pemUgdGhlIHN0 YXRlcyBmcm9tIFNGLUluc3RhbmNlLVguIFdobyBpcyByZXNwb25zaWJsZSBmb3INCj4gICAgIHRo b3NlIHN0YXRlcyBtYWludGVuYW5jZSBmb3IgdGhlIExvYWQgQmFsYW5jaW5nIGRlc2NyaWJlZCBp biBGaWd1cmUgNT8NCj4NCj4gICAgIDxrZWc+IE5vbmUgb2YgdGhvc2UgZW50aXRpZXMgZXhpc3Qg aW4gRmlndXJlIDUuICBDYW4geW91IHJlLXBocmFzZQ0KPiAgICAgeW91ciBxdWVzdGlvbiBmcm9t IHRoZSBmaWd1cmU/DQo+DQo+ICAgICBMaW5kYQ0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+ DQo+IFJlcXVpcmUgcHVzaGluZyBwb2xpY2llcyB0byBTRjEgb24gaG93IHRvIGxvYWQgYmFsYW5j ZSBtdWx0aXBsZSANCj4gaW5zdGFuY2VzIG9mIFNGMi4NCj4NCj4gU0YxIG1heSBub3QgaGF2ZSB0 aGUgY2FwYWJpbGl0eSB0byBiYWxhbmNlIGFtb25nIG11bHRpcGxlIGluc3RhbmNlcyBvZg0KPiBT RjINCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpz ZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Thu May 29 07:41:25 2014 Return-Path: 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 A6AE81A0A22 for ; Thu, 29 May 2014 07:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 VDy-qsEw_iZI for ; Thu, 29 May 2014 07:41:20 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12FDF1A0979 for ; Thu, 29 May 2014 07:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7948; q=dns/txt; s=iport; t=1401374447; x=1402584047; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tDak0X+St9zRpIZZr1fDtHCfSY0AdzUlDix9m0QzzyM=; b=TsKy1MeKeS21AwmrZqyPzFjQoVdso6+xddpXwUz/pkrbny80+QjocWRj G4u2XlKyykScUPRUcchY+eHA66pdBgV903IoqjUo7Dk7EZ5oSC/hI417b RoWDMsXG2znJPL+oEDxsOdsW7j6vfid6IRjCTjSRUHl0NtmBiusaOMKo4 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAFNGh1OtJA2N/2dsb2JhbABZgweBKsI2AYELFnSCJQEBAQQ6NwgQAgEIEQMBAQEfCQcyFAkIAgQBDQUbiCfXfBeJM4ROAQFPB4RAAQONV4weh2uLPoF4gUCBdjk X-IronPort-AV: E=Sophos;i="4.98,934,1392163200"; d="scan'208";a="328832021" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-2.cisco.com with ESMTP; 29 May 2014 14:40:46 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s4TEekRT030551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 May 2014 14:40:46 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.121]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Thu, 29 May 2014 09:40:46 -0500 From: "Ken Gray (kegray)" To: Eric Gray , Linda Dunbar , "Paul Quinn (paulq)" , "Joel M. Halpern" Thread-Topic: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 Thread-Index: AQHPerstNYLhn/ifQS+CjPHej+3iV5tWg/PggAEJnTCAACWuAA== Date: Thu, 29 May 2014 14:40:45 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD0288@eusaamb107.ericsson.se> In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF632AD0288@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.73.121] Content-Type: text/plain; charset="us-ascii" Content-ID: <45C6F3EFD847D94AAC019DF875F7B344@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/9byhRZtDI2T3C9HvDkA_MdzqSdA Cc: "sfc@ietf.org" Subject: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 14:41:22 -0000 Yep, can see how it is a bit too "thick". I'm okay with your suggested simplification. On 5/29/14 10:25 AM, "Eric Gray" wrote: >Linda, > > A few points: >1) probably better not to use MS Word (assuming that is what you used) to >add=20 >comments to your mail (not sure many people will be able to read them); >best >to simply include your comment(s) directly. >2) being careful about providing text to ensure that the right context is >included >can help to understand your point. >3) your comments appear (as Ken pointed out in a separate response) not >to be > based on what any of us said; in fact, it looks like what you really >mean is "based > on my understanding of what you have said" as a way to make a >separate (but > related) point. > >In your first point, a more complete context would be included if you >quoted this: > >"The load distribution decision will be localized (in general, although >there might=20 > be macro policy controlling that - which is out of scope for the sake >of a simple=20 > example). In this case, the control entity will push to the sf1 >nodes, a table of > sorts: sf2 with a series of next hops, and if needed some weighted or >other=20 > metrics (these could also be decided locally by some policy, but sf1 >would need=20 > to be aware of expand/contract triggers and actions). sf1 would use >local logic --=20 > hash, state table, etc. -- to distribute the chained packets to sf2." > >This is the entire paragraph, after the first two sentences. > >I believe the issue with this text is that the authors have improperly >parenthesized=20 >text, making the meaning of this paragraph self-contradictory and rather >opaque >on first reading it. > >In fact, grammatically speaking the entire paragraph is a mess - and that >does not >help in understanding it. > >The way I have puzzled it out, the text "[in] this case, the control >entity will push >to the sf1 nodes, a table of [some sort: e.g. - ] sf2 with a series of >next hops, and=20 >[(if needed)] some weighted or other metrics" applies to the text in >parentheses=20 >in the preceding sentence (i.e. - "in general, although there might be >[a] macro=20 >policy controlling that - ..."). In other words, "this case" refers to >the case where=20 >a macro policy is used to control the "local decision" process. > >As you can see from the way I have hacked up the sentences in my effort >to make >sense of them, and the amount of restructuring I think the text requires, >it is my=20 >opinion that the text needs a major rework. > >For one thing, the complex example given actually doesn't help and should >not be >included. > >Assuming I have the meaning correct, I would replace the quoted text >above with: > >"In the example shown in Figure 5, the load distribution decision for SF2 >is localized=20 > at SF1 (though the decision may be affected by a macro policy provided >in some > form by the control entity)." > >The rest of the previous text only adds confusion as a result of >over-stating the >example. > >As a matter of personal preference, I would also use the word "embedded" >as >the better-known spelling of the word "imbedded" used in the first >sentence >(and possibly elsewhere in the draft). > >I agree with Ken that your second suggested change is incorrect. > >-- >Eric > =20 > > >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >Sent: Wednesday, May 28, 2014 5:50 PM >To: Ken Gray (kegray); Paul Quinn (paulq); Joel M. Halpern >Cc: sfc@ietf.org >Subject: Re: [sfc] questions of "load balancing considerations" in the >draft-quinn-sfc-arch-05 > >Joel, Eric, and Ken, > >Thank you very much for the explanation. > >Based on what you said, the description on how "control entity push to >the sf1 nodes ." should be removed from the text, specifically: > >"In this > case, the control entity will push to the sf1 nodes, a table of > sorts: sf2 with a series of next hops, and if needed some weighted or > other metrics (these could also be decided locally by some policy, > but sf1 would need to be aware of expand/contract triggers and > actions)."=20 > > >Should also change the sentence after the Figure 5 to > >"Either through an imbedded action in sf1 and sf3, the SFF nodes to which >the multiple instances of SF2 or SF4 are attached, or through external > control, the service functions sf2 and sf4 are elastically expanded > and contracted dynamically." > > >Linda >From: Ken Gray (kegray) [mailto:kegray@cisco.com] >Sent: Wednesday, May 28, 2014 4:24 PM >To: Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern >Cc: sfc@ietf.org >Subject: Re: [sfc] questions of "load balancing considerations" in the >draft-quinn-sfc-arch-05 > >+1 to Joel . the picture would be ugly at best. We attempted a generic >HA/LB slide to make a point and even it was ugly .such are the >limitations of ASCII art. > >In line . > >From: Linda Dunbar >Date: Wednesday, May 28, 2014 3:34 PM >To: "Paul Quinn (paulq)" , "Joel M. Halpern" > >Cc: "sfc@ietf.org" >Subject: [sfc] questions of "load balancing considerations" in the >draft-quinn-sfc-arch-05 > >Paul and Joel,=20 >=20 >Does the Load Balancing Figure 5 (of draft-quinn-sfc-arch-05) assume that >SF1 is responsible for balancing traffic among the 3 instances of SF2, >and SF3 is responsible for balancing traffic among the 3 instances of SF4? > > Document text below the picture says "Either through an imbedded >action in sf1 and sf3, or through external >control, the service functions sf2 and sf4 are elastically expanded and >contracted dynamically." >=20 >Isn't it a single point of failure? > > Document text immediately subsequent to that picture and paragraph >illustrates HA scenarios. >=20 >Some service functions are Stateful, i.e. they may require packets from >same flows to traverse the same service function instance. For the Load >Balancing scheme described by Figure 5, do you assume that SF1 and SF3 >will be responsible for making sure that same flows go through the same >service function instance? > > Again, the aforementioned text deliberately allows this >responsibility to be either imbedded in the elasticity-causing function >or to be controlled externally or centrally. We don't get into the >mechanics as these can vary. While stateful/bidirectional does add an >additional burden, it can be accommodated without an explosion of >discrete chains. For example, it could be handled "at allocation time" >if elasticity is managed via a separate entity and the individual >allocations reflected through service chain control in the initial >metadata bound to at the classification point in either direction. OR, >if the devices are working as a paired system (single vendor or >ecosystem) with integrated elasticity, they could pass metadata between >them when sf1 or sf3 does the initial dynamic allocation (affecting local >forwarding on it's partner). That's probably not an exhaustive list of >ways to solve the problem. 8^) > > The point of this section was that elasticity and HA should not >cause an inordinate explosion of discrete chains without recommending a >particular solution. That is, you shouldn't create unnecessary >complexity where it doesn't need to exist. >=20 >For the stateful service functions, if a flow is switched from >SF-Instance-X to SF-Instance-Y, the SF-Instance-Y needs to synchronize >the states from SF-Instance-X. Who is responsible for those states >maintenance for the Load Balancing described in Figure 5? > > None of those entities exist in Figure 5. Can you re-phrase your >question from the figure? >=20 >Linda >=20 From nobody Thu May 29 07:49:12 2014 Return-Path: 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 715D11A014E for ; Thu, 29 May 2014 07:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 lWaSyNZhmcx2 for ; Thu, 29 May 2014 07:49:09 -0700 (PDT) Received: from hub021-ca-3.exch021.serverdata.net (hub021-ca-3.exch021.serverdata.net [64.78.22.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58A551A0960 for ; Thu, 29 May 2014 07:49:09 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0174.001; Thu, 29 May 2014 07:49:05 -0700 From: Ron Parker To: Lucy yong , Joel Halpern Direct , Qin Wu , "Ken Gray (kegray)" , Linda Dunbar Thread-Topic: =?utf-8?B?W3NmY10g562U5aSNOiAgcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2luZyBj?= =?utf-8?Q?onsiderations"_in_the_draft-quinn-sfc-arch-05?= Thread-Index: AQHPevHnnak294azIUGt2Xtd2dq4OZtX/+OAgAALPAD//5I4wIAAebOA//+L/BA= Date: Thu, 29 May 2014 14:49:04 +0000 Message-ID: References: , <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> <16984558-2B4C-4873-AFC7-DCD2698CA745@cisco.com> <53873333.80807@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D45389906@dfweml701-chm.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D453899C2@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453899C2@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/-I3fN3qjowKYYCSJGgMMYHXO64A Cc: "Joel M. Halpern" , "Paul Quinn \(paulq\)" , "sfc@ietf.org" Subject: Re: [sfc] =?utf-8?b?562U5aSNOiAgcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2lu?= =?utf-8?q?g_considerations=22_in_the_draft-quinn-sfc-arch-05?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 14:49:11 -0000 SGksIEx1Y3kuDQoNCkkgYWdyZWUgYWJvdXQgdGhlIHZpZXcgb2YgMSBzZXJ2aWNlIGZ1bmN0aW9u IHZzLiBtdWx0aXBsZSBzZXJ2aWNlIGZ1bmN0aW9uIGluc3RhbmNlcy4gICBJbiB0aGUgbGF0dGVy IGNhc2UsIHBlcmhhcHMgd2UgY291bGQgZGVzY3JpYmUgaXQgbm90IGFzICJzZXJ2aWNlIGZ1bmN0 aW9uIGV4cGFuc2lvbiIsIGJ1dCByYXRoZXIgInNlcnZpY2UgZnVuY3Rpb24gaW5zdGFuY2Ugc2Vs ZWN0aW9uIi4NCg0KICAgUm9uDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTHVjeSB5b25n DQpTZW50OiBUaHVyc2RheSwgTWF5IDI5LCAyMDE0IDEwOjM5IEFNDQpUbzogUm9uIFBhcmtlcjsg Sm9lbCBIYWxwZXJuIERpcmVjdDsgUWluIFd1OyBLZW4gR3JheSAoa2VncmF5KTsgTGluZGEgRHVu YmFyDQpDYzogSm9lbCBNLiBIYWxwZXJuOyBQYXVsIFF1aW5uIChwYXVscSk7IHNmY0BpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtzZmNdIOetlOWkjTogcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2lu ZyBjb25zaWRlcmF0aW9ucyIgaW4gdGhlIGRyYWZ0LXF1aW5uLXNmYy1hcmNoLTA1DQoNCkhpIFJv biwNCg0KSSBhZ3JlZSB3aXRoIHdoYXQgeW91IHNhaWQuIElmIGEgc2VydmljZSBmdW5jdGlvbiBk eW5hbWljIGV4cGFuc2lvbiBpcyBpbXBsZW1lbnRlZCBhcyBjb21wbGV0ZWx5IGludGVybmFsLCBp LmUuIGxvb2tzIGxpa2Ugb25lIFNGIGNvbXBvbmVudCBpbiBTRkMgbmV0d29ya3MsIElNTzogU0ZD IGFyY2hpdGVjdHVyZSBkb2VzIG5vdCBuZWVkIHN0ZXAgaW50byB0aGF0IGFuZCBqdXN0IHRyZWF0 IGl0IGFzIG9uZSBTRiBpbnN0YW5jZSBpbiBTRkMgbmV0d29ya3MuIFRoZXJlIGFyZSBvdGhlciBz Y2VuYXJpb3Mgd2hlcmUgaW5kaXZpZHVhbCBTRiBpbnN0YW5jZXMgZXhwb3NlIHRvIHRoZSBTRkMg bmV0d29yaywgU0ZDIGFyY2hpdGVjdHVyZSBuZWVkcyB0byBjb3ZlciB0aGF0Lg0KDQpUaGFua3Ms DQpMdWN5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSb24gUGFya2VyIFtt YWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBN YXkgMjksIDIwMTQgOToyNSBBTQ0KVG86IEx1Y3kgeW9uZzsgSm9lbCBIYWxwZXJuIERpcmVjdDsg UWluIFd1OyBLZW4gR3JheSAoa2VncmF5KTsgTGluZGEgRHVuYmFyDQpDYzogSm9lbCBNLiBIYWxw ZXJuOyBQYXVsIFF1aW5uIChwYXVscSk7IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtzZmNd IOetlOWkjTogcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2luZyBjb25zaWRlcmF0aW9ucyIgaW4g dGhlIGRyYWZ0LXF1aW5uLXNmYy1hcmNoLTA1DQoNCkx1Y3ksDQoNCldoZXRoZXIgb3Igbm90IGR5 bmFtaWMgZXhwYW5zaW9uIHJlcXVpcmVzIGEgbG9hZCBiYWxhbmNlciBpcyBzcGVjaWZpYyB0byB0 aGUgYXJjaGl0ZWN0dXJlIG9mIHRoYXQgc2VydmljZSBmdW5jdGlvbi4gICBUaGVyZSBhcmUgYXJj aGl0ZWN0dXJlcyB0aGF0IGFyZSBpbnRlcm5hbGx5IGxvYWQgYmFsYW5jZWQuDQoNCiAgIFJvbg0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEx1Y3kgeW9uZw0KU2VudDogVGh1cnNkYXksIE1h eSAyOSwgMjAxNCA5OjU3IEFNDQpUbzogSm9lbCBIYWxwZXJuIERpcmVjdDsgUWluIFd1OyBLZW4g R3JheSAoa2VncmF5KTsgTGluZGEgRHVuYmFyDQpDYzogSm9lbCBNLiBIYWxwZXJuOyBQYXVsIFF1 aW5uIChwYXVscSk7IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzZmNdIOetlOWkjTogcXVl c3Rpb25zIG9mICJsb2FkIGJhbGFuY2luZyBjb25zaWRlcmF0aW9ucyIgaW4gdGhlIGRyYWZ0LXF1 aW5uLXNmYy1hcmNoLTA1DQoNCkhpIEpvZWwsDQoNCkEgbG9hZCBiYWxhbmNlciBpcyBuZWVkZWQg dG8gc3VwcG9ydCBlbGFzdGljIGV4cGFuc2lvbiBvZiBhIHNlcnZpY2UgZnVuY3Rpb24gYWx0aG91 Z2ggYSBMQiBjYW4gYmUgdHJhbnNwYXJlbnRseSB0byBhIFNGQy4gDQoNCkl0IGlzIGdvb2QgdG8g bWVudGlvbiB0aGlzIGluIHNlY3Rpb24gNi4NCg0KTHVjeSAgIA0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBKb2VsIEhhbHBlcm4gRGlyZWN0DQpTZW50OiBUaHVyc2RheSwgTWF5IDI5LCAyMDE0 IDg6MTcgQU0NClRvOiBRaW4gV3U7IEtlbiBHcmF5IChrZWdyYXkpOyBMaW5kYSBEdW5iYXINCkNj OiBKb2VsIE0uIEhhbHBlcm47IFBhdWwgUXVpbm4gKHBhdWxxKTsgc2ZjQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW3NmY10g562U5aSNOiBxdWVzdGlvbnMgb2YgImxvYWQgYmFsYW5jaW5nIGNvbnNp ZGVyYXRpb25zIiBpbiB0aGUgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDUNCg0KSSBhbSBub3QgZm9s bG93aW5nIHlvdXIgcXVlc3Rpb24uDQpTRkYgY2FuIGhhdmUgYSBjby1sb2NhdGVkIGxvYWQgYmFs YW5jZXIuICBPciB0aGUgbG9hZCBiYWxhbmNlciBjYW4gYmUgdHJhbnNwYXJlbnRseSBiZWhpbmQg dGhlIFNGRiwgdXNpbmcgYW55IG51bWJlciBvZiBtZWNoYW5pc21zLg0KV2UgYXJlIG5vdCBtYW5k YXRpbmcgd2hlcmUgaXQgaXMgbG9jYXRlZC4NCg0KWW91cnMsDQpKb2VsDQoNCk9uIDUvMjgvMTQs IDExOjU1IFBNLCBRaW4gV3Ugd3JvdGU6DQo+IFlvdSBhcmUgdGFsa2luZyBhYm91dCBzZXJ2aWNl IGZ1bmN0aW9uIHNjYWxlIHVwIGFuZCBkb3duLg0KPg0KPiBTaW5jZSBzZXJ2aWNlIG5vZGUgY2Fu IGhvc3Qgb25lIG9yIG11bHRpcGxlIHNlcnZpY2UgZnVuY3Rpb25zLCB3aHkgDQo+IHNlcnZpY2Ug bm9kZSBjYW4gbm90IGJlIHVzZWQgdG8gY29udHJvbCBzY2FsZSB1cCBvciBkb3duIG9mIHNlcnZp Y2UgDQo+IGZ1bmN0aW9ucyBpdD8NCj4NCj4gVG8gYXZvaWQgc2hhcmUgcmlzayBmYWlsdXJlLCBz ZXJ2aWNlIG5vZGUgY2FuIGJlIHByZXZpb3VzIHNlcnZpY2UgDQo+IG5vZGUsIGUuZy4sIGl0IGNh biBiZSB0aGUgb25lIHRoYXQgaG9zdHMgc2YxIG9yIHNmMy4NCj4NCj4gQWxzbyBTRkYgaXMgcmVz cG9uc2libGUgZm9yIGRlbGl2ZXJpbmcgdHJhZmZpYyB0byBhbnkgY29ubmVjdGVkIA0KPiBzZXJ2 aWNlIGZ1bmN0aW9ucywgd2h5IG5vdCBTRkYgY2FuIG5vdCBiZSB1c2VkIHRvIG1hbmFnZSBzY2Fs ZSB1cCBvciANCj4gZG93biBvZiBzZXJ2aWNlIGZ1bmN0aW9uLg0KPg0KPiBBbHNvIGJhc2VkIG9u IE5GViBNQU5PIGFyY2hpdGVjdHVyZSwgdGhlcmUgaXMgcmVmZXJlbmNlIHBvaW50IGJldHdlZW4g DQo+IE5GViBhbmQgTkZWIG1hbmFnZXIsIE5GViBtYW5hZ2VyIGFsc28gY2FuIGNvbnRyb2wgc2Nh bGUgdXAgb3IgZG93biBvZiANCj4gc2VydmljZSBmdW5jdGlvbiwgSSB0aGluayB0aGlzIGNhc2Ug aGFzIGJlZW4gY292ZXJlZCBieSDigJx0aHJvdWdoIA0KPiBleHRlcm5hbCBjb250cm9s4oCdIGlu IHRoZSBkcmFmdC4NCj4NCj4gVXNpbmcgc2YxIHRoYXQgcHJvdmlkZSBkZWRpY2F0ZWQgZmlyZXdh bGwgc2VydmljZSB0byBwcm92aWRlIGxvYWQgDQo+IGJhbGFuY2luZyBmdW5jdGlvbmFsaXR5IGFz IHdlbGwgaXMgYSBsaXR0bGUgYml0IHdlaXJkIHRvIG1lLg0KPg0KPiBMZXQgbWUga25vdyBpZiBt eSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3Q/DQo+DQo+IFJlZ2FyZHMhDQo+DQo+IC1RaW4NCj4N Cj4gKuWPkeS7tuS6ujoqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddICrku6Pooagg KktlbiBHcmF5IChrZWdyYXkpDQo+ICrlj5HpgIHml7bpl7Q6KjIwMTTlubQ15pyIMjnml6U4OjQ5 DQo+ICrmlLbku7bkuro6KkxpbmRhIER1bmJhcg0KPiAq5oqE6YCBOipKb2VsIE0uIEhhbHBlcm47 IFBhdWwgUXVpbm4gKHBhdWxxKTsgc2ZjQGlldGYub3JnDQo+ICrkuLvpopg6KlJlOiBbc2ZjXSBx dWVzdGlvbnMgb2YgImxvYWQgYmFsYW5jaW5nIGNvbnNpZGVyYXRpb25zIiBpbiB0aGUNCj4gZHJh ZnQtcXVpbm4tc2ZjLWFyY2gtMDUNCj4NCj4gSSBkb24ndCBzZWUgaG93IHlvdSBtYWtlIHRoZSBs ZWFwIGZyb20gdGhlIGV4cGxhbmF0aW9uIG9mIHdoeSBpdCB3YXMgDQo+IGlycmVsZXZhbnQgdG8g Z28gaW50byBtb3JlIGRldGFpbCBpbiB0aGUgc2VjdGlvbiB0byB0aGUgZWxpbWluYXRpb24gb2Yg DQo+IHRoZSB2ZXJ5IGdlbmVyYWxpemVkIGRlc2NyaXB0aW9uIGFjY29tcGFueWluZyB0aGUgZmln dXJlLiAgUGxlYXNlIHVzZSANCj4geW91ciBvd24gYXJndW1lbnQgdG8ganVzdGlmeSB0aGlzIGFu ZCBub3QgaW5mZXIgYW55IGV4dHJhIG1lYW5pbmcgZnJvbSANCj4gbXkgYW5zd2VyIHRvIGEgZGlm ZmVyZW50IHF1ZXN0aW9uLg0KPg0KPiBBcyB0byB0aGUgc2Vjb25kIGNoYW5nZSwgaSBkaXNhZ3Jl ZS4gIEFnYWluLCBpbiBnZW5lcmFsL2Jyb2FkIHN0cm9rZXMNCj4gLSBmcm9tIHRoZSBkcmF3aW5n IGFuZCB0aGUgdGV4dCwgaXQgaXMgdW5saWtlbHkgdGhhdCBhbnkgc3BlY2lhbCANCj4gYWN0aW9u IHdvdWxkIGJlIHJlcXVpcmVkIG9uIHNmMiBvciBzZjQgLSBhcyB0aGV5IGNvbGxhcHNlIGluIGVp dGhlciANCj4gZGlyZWN0aW9uIHRvIGEgc2luZ2xlIGxvZ2ljYWwgbmV4dCBob3AuDQo+DQo+IFNl bnQgZnJvbSBteSBpUGhvbmUNCj4NCj4NCj4gT24gTWF5IDI4LCAyMDE0LCBhdCA1OjQ5IFBNLCAi TGluZGEgRHVuYmFyIiA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20gDQo+IDxtYWlsdG86bGluZGEu ZHVuYmFyQGh1YXdlaS5jb20+PiB3cm90ZToNCj4NCj4gICAgIEpvZWwsIEVyaWMsIGFuZCBLZW4s DQo+DQo+ICAgICBUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB0aGUgZXhwbGFuYXRpb24uDQo+DQo+ ICAgICBCYXNlZCBvbiB3aGF0IHlvdSBzYWlkLCB0aGUgZGVzY3JpcHRpb24gb24gaG93IOKAnGNv bnRyb2wgZW50aXR5ICBwdXNoDQo+ICAgICB0byB0aGUgc2YxIG5vZGVzIOKApuKAnSBzaG91bGQg YmUgcmVtb3ZlZCBmcm9tIHRoZSB0ZXh0LCBzcGVjaWZpY2FsbHk6DQo+DQo+ICAgICDigJxJbiB0 aGlzDQo+DQo+ICAgICAgICAgY2FzZSwgdGhlIGNvbnRyb2wgZW50aXR5IHdpbGwgcHVzaCB0byB0 aGUgc2YxIG5vZGVzLCBhIHRhYmxlIA0KPiBvZg0KPg0KPiAgICAgICAgIHNvcnRzOltMMV0gPCNf bXNvY29tXzE+IHNmMiB3aXRoIGEgc2VyaWVzIG9mIG5leHQgaG9wcywgYW5kIGlmDQo+ICAgICBu ZWVkZWQgc29tZSB3ZWlnaHRlZCBvcg0KPg0KPiAgICAgICAgIG90aGVyIG1ldHJpY3MgKHRoZXNl IGNvdWxkIGFsc28gYmUgZGVjaWRlZCBsb2NhbGx5IGJ5IHNvbWUgDQo+IHBvbGljeSwNCj4NCj4g ICAgICAgICBidXQgc2YxIHdvdWxkIG5lZWQgdG8gYmUgYXdhcmUgb2YgZXhwYW5kL2NvbnRyYWN0 IHRyaWdnZXJzIGFuZA0KPg0KPiAgICAgICAgIGFjdGlvbnMpLuKAnQ0KPg0KPiAgICAgU2hvdWxk IGFsc28gY2hhbmdlIHRoZSBzZW50ZW5jZSBhZnRlciB0aGUgRmlndXJlIDUgdG8NCj4NCj4gICAg IOKAnEVpdGhlciB0aHJvdWdoIGFuIGltYmVkZGVkIGFjdGlvbiBpbiBzZjEgYW5kIHNmMywgdGhl IFNGRiBub2RlcyB0bw0KPiAgICAgd2hpY2ggdGhlIG11bHRpcGxlIGluc3RhbmNlcyBvZiBTRjIg b3IgU0Y0IGFyZSBhdHRhY2hlZCwgb3IgdGhyb3VnaA0KPiAgICAgZXh0ZXJuYWwNCj4NCj4gICAg ICAgICBjb250cm9sLCB0aGUgc2VydmljZSBmdW5jdGlvbnMgc2YyIGFuZCBzZjQgYXJlIGVsYXN0 aWNhbGx5IA0KPiBleHBhbmRlZA0KPg0KPiAgICAgICAgIGFuZCBjb250cmFjdGVkIGR5bmFtaWNh bGx5LuKAnQ0KPg0KPiAgICAgTGluZGENCj4NCj4gICAgICpGcm9tOipLZW4gR3JheSAoa2VncmF5 KSBbbWFpbHRvOmtlZ3JheUBjaXNjby5jb21dDQo+ICAgICAqU2VudDoqIFdlZG5lc2RheSwgTWF5 IDI4LCAyMDE0IDQ6MjQgUE0NCj4gICAgICpUbzoqIExpbmRhIER1bmJhcjsgUGF1bCBRdWlubiAo cGF1bHEpOyBKb2VsIE0uIEhhbHBlcm4NCj4gICAgICpDYzoqIHNmY0BpZXRmLm9yZyA8bWFpbHRv OnNmY0BpZXRmLm9yZz4NCj4gICAgICpTdWJqZWN0OiogUmU6IFtzZmNdIHF1ZXN0aW9ucyBvZiAi bG9hZCBiYWxhbmNpbmcgY29uc2lkZXJhdGlvbnMiIGluDQo+ICAgICB0aGUgZHJhZnQtcXVpbm4t c2ZjLWFyY2gtMDUNCj4NCj4gICAgICsxIHRvIEpvZWwg4oCmIHRoZSBwaWN0dXJlIHdvdWxkIGJl IHVnbHkgYXQgYmVzdC4gIFdlIGF0dGVtcHRlZCBhDQo+ICAgICBnZW5lcmljIEhBL0xCIHNsaWRl IHRvIG1ha2UgYSBwb2ludCBhbmQgZXZlbiBpdCB3YXMgdWdseSDigKZzdWNoIGFyZQ0KPiAgICAg dGhlIGxpbWl0YXRpb25zIG9mIEFTQ0lJIGFydC4NCj4NCj4gICAgIEluIGxpbmUg4oCmDQo+DQo+ ICAgICAqRnJvbTogKkxpbmRhIER1bmJhciA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20NCj4gICAg IDxtYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+Pg0KPiAgICAgKkRhdGU6ICpXZWRuZXNk YXksIE1heSAyOCwgMjAxNCAzOjM0IFBNDQo+ICAgICAqVG86ICoiUGF1bCBRdWlubiAocGF1bHEp IiA8cGF1bHFAY2lzY28uY29tDQo+ICAgICA8bWFpbHRvOnBhdWxxQGNpc2NvLmNvbT4+LCAiSm9l bCBNLiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbQ0KPiAgICAgPG1haWx0bzpqbWhAam9l bGhhbHBlcm4uY29tPj4NCj4gICAgICpDYzogKiJzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0 Zi5vcmc+IiA8c2ZjQGlldGYub3JnDQo+ICAgICA8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQo+ICAg ICAqU3ViamVjdDogKltzZmNdIHF1ZXN0aW9ucyBvZiAibG9hZCBiYWxhbmNpbmcgY29uc2lkZXJh dGlvbnMiIGluIHRoZQ0KPiAgICAgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDUNCj4NCj4gICAgIFBh dWwgYW5kIEpvZWwsDQo+DQo+ICAgICBEb2VzIHRoZSBMb2FkIEJhbGFuY2luZyBGaWd1cmUgNSAo b2YgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDUpIGFzc3VtZQ0KPiAgICAgdGhhdCBTRjEgaXMgcmVz cG9uc2libGUgZm9yIGJhbGFuY2luZyB0cmFmZmljIGFtb25nIHRoZSAzIGluc3RhbmNlcw0KPiAg ICAgb2YgU0YyLCBhbmQgU0YzIGlzIHJlc3BvbnNpYmxlIGZvciBiYWxhbmNpbmcgdHJhZmZpYyBh bW9uZyB0aGUgMw0KPiAgICAgaW5zdGFuY2VzIG9mIFNGND8NCj4NCj4gICAgIDxrZWc+IERvY3Vt ZW50IHRleHQgYmVsb3cgdGhlIHBpY3R1cmUgc2F5cyAiRWl0aGVyIHRocm91Z2ggYW4NCj4gICAg IGltYmVkZGVkIGFjdGlvbiBpbiBzZjEgYW5kIHNmMywgb3IgdGhyb3VnaCBleHRlcm5hbA0KPg0K PiAgICAgY29udHJvbCwgdGhlIHNlcnZpY2UgZnVuY3Rpb25zIHNmMiBhbmQgc2Y0IGFyZSBlbGFz dGljYWxseQ0KPiAgICAgZXhwYW5kZWQgYW5kIGNvbnRyYWN0ZWQgZHluYW1pY2FsbHkuIg0KPg0K PiAgICAgSXNu4oCZdCBpdCBhIHNpbmdsZSBwb2ludCBvZiBmYWlsdXJlPw0KPg0KPiAgICAgPGtl Zz4gRG9jdW1lbnQgdGV4dCBpbW1lZGlhdGVseSBzdWJzZXF1ZW50IHRvIHRoYXQgcGljdHVyZSBh bmQNCj4gICAgIHBhcmFncmFwaCBpbGx1c3RyYXRlcyBIQSBzY2VuYXJpb3MuDQo+DQo+ICAgICBT b21lIHNlcnZpY2UgZnVuY3Rpb25zIGFyZSBTdGF0ZWZ1bCwgaS5lLiB0aGV5IG1heSByZXF1aXJl IHBhY2tldHMNCj4gICAgIGZyb20gc2FtZSBmbG93cyB0byB0cmF2ZXJzZSB0aGUgc2FtZSBzZXJ2 aWNlIGZ1bmN0aW9uIGluc3RhbmNlLiBGb3INCj4gICAgIHRoZSBMb2FkIEJhbGFuY2luZyBzY2hl bWUgZGVzY3JpYmVkIGJ5IEZpZ3VyZSA1LCBkbyB5b3UgYXNzdW1lIHRoYXQNCj4gICAgIFNGMSBh bmQgU0YzIHdpbGwgYmUgcmVzcG9uc2libGUgZm9yIG1ha2luZyBzdXJlIHRoYXQgc2FtZSBmbG93 cyBnbw0KPiAgICAgdGhyb3VnaCB0aGUgc2FtZSBzZXJ2aWNlIGZ1bmN0aW9uIGluc3RhbmNlPw0K Pg0KPiAgICAgPGtlZz4gQWdhaW4sIHRoZSBhZm9yZW1lbnRpb25lZCB0ZXh0IGRlbGliZXJhdGVs eSBhbGxvd3MgdGhpcw0KPiAgICAgcmVzcG9uc2liaWxpdHkgdG8gYmUgZWl0aGVyIGltYmVkZGVk IGluIHRoZSBlbGFzdGljaXR5LWNhdXNpbmcNCj4gICAgIGZ1bmN0aW9uIG9yIHRvIGJlIGNvbnRy b2xsZWQgZXh0ZXJuYWxseSBvciBjZW50cmFsbHkuICBXZSBkb24ndCBnZXQNCj4gICAgIGludG8g dGhlIG1lY2hhbmljcyBhcyB0aGVzZSBjYW4gdmFyeS4gIFdoaWxlIHN0YXRlZnVsL2JpZGlyZWN0 aW9uYWwNCj4gICAgIGRvZXMgYWRkIGFuIGFkZGl0aW9uYWwgYnVyZGVuLCBpdCBjYW4gYmUgYWNj b21tb2RhdGVkIHdpdGhvdXQgYW4NCj4gICAgIGV4cGxvc2lvbiBvZiBkaXNjcmV0ZSBjaGFpbnMu ICBGb3IgZXhhbXBsZSwgaXQgY291bGQgYmUgaGFuZGxlZCAiYXQNCj4gICAgIGFsbG9jYXRpb24g dGltZSIgaWYgZWxhc3RpY2l0eSBpcyBtYW5hZ2VkIHZpYSBhIHNlcGFyYXRlIGVudGl0eSBhbmQN Cj4gICAgIHRoZSBpbmRpdmlkdWFsIGFsbG9jYXRpb25zIHJlZmxlY3RlZCB0aHJvdWdoIHNlcnZp Y2UgY2hhaW4gY29udHJvbA0KPiAgICAgaW4gdGhlIGluaXRpYWwgbWV0YWRhdGEgYm91bmQgdG8g YXQgdGhlIGNsYXNzaWZpY2F0aW9uIHBvaW50IGluDQo+ICAgICBlaXRoZXIgZGlyZWN0aW9uLiAg T1IsIGlmIHRoZSBkZXZpY2VzIGFyZSB3b3JraW5nIGFzIGEgcGFpcmVkIHN5c3RlbQ0KPiAgICAg KHNpbmdsZSB2ZW5kb3Igb3IgZWNvc3lzdGVtKSB3aXRoIGludGVncmF0ZWQgZWxhc3RpY2l0eSwg dGhleSBjb3VsZA0KPiAgICAgcGFzcyBtZXRhZGF0YSBiZXR3ZWVuIHRoZW0gd2hlbiBzZjEgb3Ig c2YzIGRvZXMgdGhlIGluaXRpYWwgZHluYW1pYw0KPiAgICAgYWxsb2NhdGlvbiAoYWZmZWN0aW5n IGxvY2FsIGZvcndhcmRpbmcgb24gaXQncyBwYXJ0bmVyKS4gIFRoYXQncw0KPiAgICAgcHJvYmFi bHkgbm90IGFuIGV4aGF1c3RpdmUgbGlzdCBvZiB3YXlzIHRvIHNvbHZlIHRoZSBwcm9ibGVtLiAg OF4pDQo+DQo+ICAgICA8a2VnPiBUaGUgcG9pbnQgb2YgdGhpcyBzZWN0aW9uIHdhcyB0aGF0IGVs YXN0aWNpdHkgYW5kIEhBIHNob3VsZA0KPiAgICAgbm90IGNhdXNlIGFuIGlub3JkaW5hdGUgZXhw bG9zaW9uIG9mIGRpc2NyZXRlIGNoYWlucyB3aXRob3V0DQo+ICAgICByZWNvbW1lbmRpbmcgYSBw YXJ0aWN1bGFyIHNvbHV0aW9uLiAgVGhhdCBpcywgIHlvdSBzaG91bGRuJ3QgY3JlYXRlDQo+ICAg ICB1bm5lY2Vzc2FyeSAgY29tcGxleGl0eSB3aGVyZSBpdCBkb2Vzbid0IG5lZWQgdG8gZXhpc3Qu DQo+DQo+ICAgICBGb3IgdGhlIHN0YXRlZnVsIHNlcnZpY2UgZnVuY3Rpb25zLCBpZiBhIGZsb3cg aXMgc3dpdGNoZWQgZnJvbQ0KPiAgICAgU0YtSW5zdGFuY2UtWCB0byBTRi1JbnN0YW5jZS1ZLCB0 aGUgU0YtSW5zdGFuY2UtWSBuZWVkcyB0bw0KPiAgICAgc3luY2hyb25pemUgdGhlIHN0YXRlcyBm cm9tIFNGLUluc3RhbmNlLVguIFdobyBpcyByZXNwb25zaWJsZSBmb3INCj4gICAgIHRob3NlIHN0 YXRlcyBtYWludGVuYW5jZSBmb3IgdGhlIExvYWQgQmFsYW5jaW5nIGRlc2NyaWJlZCBpbiBGaWd1 cmUgNT8NCj4NCj4gICAgIDxrZWc+IE5vbmUgb2YgdGhvc2UgZW50aXRpZXMgZXhpc3QgaW4gRmln dXJlIDUuICBDYW4geW91IHJlLXBocmFzZQ0KPiAgICAgeW91ciBxdWVzdGlvbiBmcm9tIHRoZSBm aWd1cmU/DQo+DQo+ICAgICBMaW5kYQ0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+DQo+IFJl cXVpcmUgcHVzaGluZyBwb2xpY2llcyB0byBTRjEgb24gaG93IHRvIGxvYWQgYmFsYW5jZSBtdWx0 aXBsZSANCj4gaW5zdGFuY2VzIG9mIFNGMi4NCj4NCj4gU0YxIG1heSBub3QgaGF2ZSB0aGUgY2Fw YWJpbGl0eSB0byBiYWxhbmNlIGFtb25nIG11bHRpcGxlIGluc3RhbmNlcyBvZg0KPiBTRjINCj4N Cj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlz dA0Kc2ZjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm Yw0K From nobody Thu May 29 08:30:43 2014 Return-Path: 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 E5E8B1A09E3 for ; Thu, 29 May 2014 08:30:39 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 oy9FwzVWOKJl for ; Thu, 29 May 2014 08:30:37 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FE3A1A09C8 for ; Thu, 29 May 2014 08:30:37 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-e5-53870004339a Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 0E.E0.11744.40007835; Thu, 29 May 2014 11:38:12 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Thu, 29 May 2014 11:30:31 -0400 From: Eric Gray To: Joel Halpern , "Paul Quinn (paulq) (paulq@cisco.com)" Thread-Topic: Figures in draft-quinn-sfc-arch-05 Thread-Index: Ac97S9R6mfocA+1iTpKXBfVlibSBgg== Date: Thu, 29 May 2014 15:30:30 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF632AD0443@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF632AD0443eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyuXRPoC4LQ3uwwePbUhb7Xy1ltXjyYCu7 A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXRefoxW8Gc9YwVZ9/fYWpg3D+dsYuRk0NC wESit2kdK4QtJnHh3nq2LkYuDiGBo4wSa39tYYJwljNKNKzczAJSxSagIXHszlqwbhGBDIlz qyYyg9jMAooSj279Bmrg4BAW0JaYfzMAosRA4sHibqhyPYkTk5cwgdgsAqoSU+5cBhvJK+Ar MfPrXbA4I9AR30+tYYIYKS5x68l8JojjBCSW7DnPDGGLSrx8/A/qaCWJj7/ns0PU50s8mrGe EWKmoMTJmU9YJjAKz0IyahaSsllIyiDiOhILdn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRo7S 4tSy3HQjw02MwEg5JsHmuINxwSfLQ4wCHIxKPLwPXrcGC7EmlhVX5h5ilOZgURLn3XOtKlhI ID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY+6LwItL3t26aiJQVntzTUbovfQTO3seGzCmy7EL r1sa9WHZyuuP3+zNrtW6yTozuX23glCHJftU7autbVXrRfZHffjsnjZNlnu2XUXbVw2xm/8P tx79t+qa5mNu81uciqf8/kjUvQ5yneN9ef75hF+eS7w+b427sO/GbAsbzY0sClNNG7esMFFi Kc5INNRiLipOBAAq2VW4dQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/PNuKELvz93o-BBmMMpKMIcM_pa8 Cc: "sfc@ietf.org" Subject: [sfc] Figures in draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 15:30:40 -0000 --_000_48E1A67CB9CA044EADFEAB87D814BFF632AD0443eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Paul/Joel, Pretty sure that Figures 5 and 6 don't actually fit the wid= th expected for an Internet Draft (Figure 5 is more than 80 characters wide and Figure 6 is wi= der still). Depending on how a reader tries to read the draft, this can= turn complicated illustrations into a _real_ fun time. :) Also, I am unsure what the figures are trying to convey wit= h some of "dotted lines" crossing the service functions. If the intent is to show that a ser= vice function is a virtual instance hosted by some network device, perhaps this will be bett= er shown in a separate figure and this aspect of Figures 5 and 6 can be eliminated? I would suggest replacing Figure 5 with a figure along the lines of: source +-----+ +-----+ | +-->| sf2 +--+ +-->| sf4 +--+ | | | | | | | | | | +------+--+ +-----+ +-->+-----+--+ +-----+ +->+-----+ | | sf1 | +-----+ | sf3 | +-----+ | sf5 | +->| +----->| sf2 +----->| |----->| sf4 +---->| |-+ | | | | | | | | | | | +------+--+ +-----+ +-->+-----+--+ +-----+ +->+-----+ | | +-----+ | | +-----+ | | +-->| sf2 +--+ +-->| sf4 +--+ +----+ | | | | | +-----+ +-----+ V destination Figure 5: Load Balancing (67 characters?) Similarly, I would suggest replacing Figure 6 with a figure= along the lines of: source | +-----+-+ +-----+-+ +---+ +-->| sf2 |-|+ +-->| sf4 |-|+ | +---|-->| | || +------>| | || | +------+|---+ +-----+ |+-->+-----+|---+ +-----+ |+-->+-----+ | | sf1 || +-----+ +--->| sf3 || +-----+ +--->| sf5 | +-->| +|------>| sf2 |+---->| ||------>| sf4 |+---->| |--+ | | || +---->| |-+ | || +---->| |-+ | | | | +------+|-|-+ +-----+ |+-->+-----+|-|-+ +-----+ |+-->+-----+ | | | | | +-----+ || | | | +-----+ || | | +------++ | +-->| sf2 |-|+ +-----++ | +-->| sf4 |-|+ +-----+ | | | sf1' | | +-->| | +--->| sf3'| | +-->| | +--->| sf5'| | +-->| +--+ | +-----+----->| |--+ | +-----+----->| |--+ | | | | | | | | | +------+----+ +-----+----+ +-----+ | | +--------+ | V destination Figure 6: Load Balancing and HA (72 characters?) In both cases, the figure has all the same connection compl= exity (fixed up in a few places), but seems to be less busy. -- Eric --_000_48E1A67CB9CA044EADFEAB87D814BFF632AD0443eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Paul/Joel,

     

            &nbs= p;       Pretty sure that Figures 5 and 6 don= ’t actually fit the width expected for an

    Internet Draft (Figure 5 is more than 80 characters = wide and Figure 6 is wider still).

     

            &nbs= p;       Depending on how a reader tries to r= ead the draft, this can turn complicated

    illustrations into a _real_ fun time.  <= span style=3D"font-family:Wingdings"> J

     

            &nbs= p;       Also, I am unsure what the figures a= re trying to convey with some of “dotted

    lines” crossing the service functions.  I= f the intent is to show that a service function is

    a virtual instance hosted by some network device, pe= rhaps this will be better shown

    in a separate figure and this aspect of Figures 5 an= d 6 can be eliminated?

     

    I would suggest replacing= Figure 5 with a figure along the lines of:

     

    sourc= e             &= #43;-----+          &= nbsp;        +-----+<= /span>

      = ;|            +-= ->| sf2 +--+        &nbs= p;   +-->| sf4 +--+

      = ;|            | = ;  |     |  |     &n= bsp;      |   |     = |  |

      = ;|  +------+--+   +-----+  +--&= gt;+-----+--+   +-----+  +->+= -----+

      = ;|  | sf1  |      +-----+ &= nbsp;    | sf3 |      +-----= 3;     | sf5 |

      = ;+->|      +----->| sf2 +-----&g= t;|     |----->| sf4 +---->|   = ;  |-+

      = ;   |      |    &nbs= p; |     |      | &n= bsp;   |      |     = |     |     | |

      = ;   +------+--+   +-----+ = ; +-->+-----+--+   +-----+  += ->+-----+ |

      = ;            &n= bsp;|   +-----+  |     &nbs= p;      |   +-----+  | &nbs= p;        |

      = ;            &n= bsp;+-->| sf2 +--+       =      +-->| sf4 +--+    &n= bsp;+----+

      = ;            &n= bsp;    |     |   &n= bsp;            &nbs= p;  |     |      &nb= sp; |

      = ;            &n= bsp;    +-----+     &n= bsp;            &nbs= p;+-----+        V

      = ;            &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p;     destination

     =

      = ;            &n= bsp;    Figure 5: Load Balancing

     

    (67 characters?)

     

            &nbs= p;       Similarly, I would suggest replacing= Figure 6 with a figure along the

    lines of:

     

       source
         |       &n=
bsp;       +-----+-+ &n=
bsp;            =
;     +-----+-+
     +---+        &nb=
sp;  +-->| sf2 |-|+      &nbs=
p;       +-->| sf4 |-|+=

     |           &#=
43;---|-->|     | ||     &n=
bsp;    +------>|     | ||
     |   +------+|---+   +-----&#=
43; |+-->+-----+|---+   +-----+ |+=
-->+-----+
     |   | sf1  ||      =
 +-----+ +--->| sf3 ||       &=
#43;-----+ +--->| sf5 |
     +-->|      +|------>| sf2=
 |+---->|     ||------>| sf4 |+---->|&=
nbsp;    |--+
     |   |      || +---->|&=
nbsp;    |-+    |    =
 || +---->|     |-+    | =
;    |  |
     |   +------+|-|-+   +-----&#=
43; |+-->+-----+|-|-+   +-----+ |+=
-->+-----+  |
     |           | =
| |   +-----+ ||       =
;   | | |   +-----+ ||    &=
nbsp;       |
     |   +------++ | +-->| sf2 |-|+&=
nbsp;  +-----++ | +-->| sf4 |-|+   &#=
43;-----+  |
     |   | sf1' |  | +-->|   &nb=
sp; | +--->| sf3'|  | +-->|     | &#=
43;--->| sf5'|  |
     +-->|      +--+ | &=
nbsp; +-----+----->|     |--+ | &nb=
sp; +-----+----->|     |--+
         |      | &=
nbsp;  |          &n=
bsp;     |     |    =
|            &n=
bsp;   |     |  |

         +------+----+  &nb=
sp;            =
 +-----+----+        &n=
bsp;       +-----+  |=

    

               =
;             &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;         |=

    

               =
;            &n=
bsp;            =
;            &n=
bsp;            =
; +--------+
    

               =
;            &n=
bsp;            =
;            &n=
bsp;            =
; |
    

               =
;            &n=
bsp;            &nbs=
p;            &=
nbsp;           &nbs=
p;V
    

               =
;            &n=
bsp;            =
;            &n=
bsp;        destination
    

     
    

               =
;         Figure 6: Load Balancing =
and HA
    

     
    

    (72 characters?)
    

     
    

            &nbs=
p;       In both cases, the figure has all th=
e same connection complexity (fixed up in a few
    

    places), but seems to be less busy.
    

     
    

    --
    

    Eric
    --_000_48E1A67CB9CA044EADFEAB87D814BFF632AD0443eusaamb107erics_-- From nobody Thu May 29 09:10:01 2014 Return-Path: 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 990B41A6FAC for ; Thu, 29 May 2014 09:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 1MDwL1iwLToh for ; Thu, 29 May 2014 09:09:57 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35E6C1A09C2 for ; Thu, 29 May 2014 09:09:57 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id lj1so603355pab.3 for ; Thu, 29 May 2014 09:09:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9QoF2VutqwaGW7rl9gZBK9F4nAg/e6mjwPwQ3VJNt1Q=; b=gue+JteHj+5g/JS9Lo5+AkX2MfZLT/3jDVOdsjY0b+LBnhWm+DIKi9BGySYGUhwp9g jCGlKpjj0zL3PGflgY1RAmtyOLTPU1g53IDb30Gwxd0e4LtuFVlaLo042dq2nNmnlSz2 lA5KBO4hBnzc9QlCdNtPdMAEdQTMxQlcAcAnnlurzXWFm+Mx3KYBe5/S9kJy9C5EurhI vMzNzs1MBRM8AuoTdrnN3hO3GmwlSmpbQJvwnmBL7TDP1nVEQGnNOhNbBSTfNWKUWrW4 Z09oaIhT0YaY9SbibDbXiWNEjCuZAzmS4QO+vovxGXvVgygw8ONs2/Dtzc+hHCzGCqHX +eEw== X-Received: by 10.68.211.195 with SMTP id ne3mr9740342pbc.121.1401379793252; Thu, 29 May 2014 09:09:53 -0700 (PDT) Received: from [192.168.1.94] ([157.22.28.27]) by mx.google.com with ESMTPSA id xk3sm1913368pbb.65.2014.05.29.09.09.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 09:09:52 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-690871F3-6E24-4993-B5C6-04CB15EF76CF Mime-Version: 1.0 (1.0) From: Sharon X-Mailer: iPad Mail (11D201) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> Date: Thu, 29 May 2014 09:09:50 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> To: Linda Dunbar Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/-1JsS4GubTix7nL95DT-dNeakms Cc: "Joel M. Halpern" , "Paul Quinn \(paulq\)" , "Ken Gray \(kegray\)" , "sfc@ietf.org" Subject: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 16:09:59 -0000 --Apple-Mail-690871F3-6E24-4993-B5C6-04CB15EF76CF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable "the SFF nodes to which the multiple instances of SF2 or SF4 are attached" Can't the SFF node make a load balancing decision on instances not attached t= o it? In which case "the SFF node" is enough=20 Location A Location B Functions - SFF/NVE - Underlay - NVE/SFF - Functions The load balancing KPI decisions (and the invariant that keeps states consis= tent) May be known in Location A for SFs in location B where A/B are different rac= ks or goes. KPIs that are factored in can include both those of the Underlay network and= the chain. --szb > On May 28, 2014, at 14:49, Linda Dunbar wrote: >=20 > Joel, Eric, and Ken, > =20 > Thank you very much for the explanation. > =20 > Based on what you said, the description on how =E2=80=9Ccontrol entity pu= sh to the sf1 nodes =E2=80=A6=E2=80=9D should be removed from the text, spec= ifically: > =20 > =E2=80=9CIn this > case, the control entity will push to the sf1 nodes, a table of > sorts:[L1] sf2 with a series of next hops, and if needed some weighted= or > other metrics (these could also be decided locally by some policy, > but sf1 would need to be aware of expand/contract triggers and > actions).=E2=80=9D > =20 > =20 > Should also change the sentence after the Figure 5 to > =20 > =E2=80=9CEither through an imbedded action in sf1 and sf3, the SFF nodes t= o which the multiple instances of SF2 or SF4 are attached, or through extern= al > control, the service functions sf2 and sf4 are elastically expanded > and contracted dynamically.=E2=80=9D=20 > =20 > =20 > Linda > From: Ken Gray (kegray) [mailto:kegray@cisco.com]=20 > Sent: Wednesday, May 28, 2014 4:24 PM > To: Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern > Cc: sfc@ietf.org > Subject: Re: [sfc] questions of "load balancing considerations" in the dra= ft-quinn-sfc-arch-05 > =20 > +1 to Joel =E2=80=A6 the picture would be ugly at best. We attempted a ge= neric HA/LB slide to make a point and even it was ugly =E2=80=A6such are the= limitations of ASCII art. > =20 > In line =E2=80=A6 > =20 > From: Linda Dunbar > Date: Wednesday, May 28, 2014 3:34 PM > To: "Paul Quinn (paulq)" , "Joel M. Halpern" > Cc: "sfc@ietf.org" > Subject: [sfc] questions of "load balancing considerations" in the draft-q= uinn-sfc-arch-05 > =20 > Paul and Joel, > =20 > Does the Load Balancing Figure 5 (of draft-quinn-sfc-arch-05) assume that S= F1 is responsible for balancing traffic among the 3 instances of SF2, and SF3= is responsible for balancing traffic among the 3 instances of SF4? > =20 > Document text below the picture says "Either through an imbedded act= ion in sf1 and sf3, or through external > control, the service functions sf2 and sf4 are elastically expanded and co= ntracted dynamically." > =20 > Isn=E2=80=99t it a single point of failure? > =20 > Document text immediately subsequent to that picture and paragraph i= llustrates HA scenarios. > =20 > Some service functions are Stateful, i.e. they may require packets from sa= me flows to traverse the same service function instance. For the Load Balanc= ing scheme described by Figure 5, do you assume that SF1 and SF3 will be res= ponsible for making sure that same flows go through the same service functio= n instance? > =20 > Again, the aforementioned text deliberately allows this responsibili= ty to be either imbedded in the elasticity-causing function or to be control= led externally or centrally. We don't get into the mechanics as these can v= ary. While stateful/bidirectional does add an additional burden, it can be a= ccommodated without an explosion of discrete chains. For example, it could b= e handled "at allocation time" if elasticity is managed via a separate entit= y and the individual allocations reflected through service chain control in t= he initial metadata bound to at the classification point in either direction= . OR, if the devices are working as a paired system (single vendor or ecosy= stem) with integrated elasticity, they could pass metadata between them when= sf1 or sf3 does the initial dynamic allocation (affecting local forwarding o= n it's partner). That's probably not an exhaustive list of ways to solve th= e problem. 8^) > =20 > The point of this section was that elasticity and HA should not caus= e an inordinate explosion of discrete chains without recommending a particul= ar solution. That is, you shouldn't create unnecessary complexity where i= t doesn't need to exist. > =20 > For the stateful service functions, if a flow is switched from SF-Instance= -X to SF-Instance-Y, the SF-Instance-Y needs to synchronize the states from S= F-Instance-X. Who is responsible for those states maintenance for the Load B= alancing described in Figure 5? > =20 > None of those entities exist in Figure 5. Can you re-phrase your qu= estion from the figure?=20 > =20 > Linda > =20 > [L1]Require pushing policies to SF1 on how to load balance multiple insta= nces of SF2. >=20 > =20 >=20 > SF1 may not have the capability to balance among multiple instances of SF2= >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail-690871F3-6E24-4993-B5C6-04CB15EF76CF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    "the SFF nodes to which t= he multiple instances of SF2 or SF4 are attached"

    Can't the SFF node make a load balancing de= cision on instances not attached to it?
    In which case "the SFF node" is enough 
    <= br>
    Location A               &n= bsp;                     &= nbsp;                 Location B
    Functions - SFF/NVE - Underlay - NVE/SFF - Functions

    The load balancing KPI decisions (and the invariant that keeps stat= es consistent)
    May be known in Location A for SFs in location B wh= ere A/B are different racks or goes.
    KPIs that are factored in can= include both those of the Underlay network and the chain.

    --szb

    On May 28, 2014, at 14:49, L= inda Dunbar <linda.dunbar@huaw= ei.com> wrote:

    =

    Joel, Eric, and Ken,

     

    Thank you very much for= the explanation.

     

    Based on what you said,= the description on how =E2=80=9Ccontrol entity  push to the sf1 nodes =E2= =80=A6=E2=80=9D should be removed from the text, specifically:

     

    =E2=80=9CIn this

       case, the co= ntrol entity will push to the sf1 nodes, a table of

       sort= s:[L1]  sf2 with a series of next hops, and if needed some weighted or

       other metrics (these could also be decided loca= lly by some policy,

       but sf1 would need to be aware of expand/contra= ct triggers and

       actions).=E2=80=9D

     

     

    Should also change the s= entence after the Figure 5 to

     

    =E2=80=9CEither through an imbedded action in sf1 and sf3, the SFF nodes to which the multiple instances of S= F2 or SF4 are attached, or through external

       control, the service functions sf2 and sf4 are e= lastically expanded

       and contracted dynamically.=E2=80=9D 

     

     

    Linda=

    From: Ken Gray (k= egray) [mailto:kegray@cisco.com]
    Sent: Wednesday, May 28, 2014 4:24 PM
    To: Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern
    Cc: sfc@ietf.org
    Subject: Re: [sfc] questions of "load balancing considerations" in th= e draft-quinn-sfc-arch-05

     

    +1 to Joe= l =E2=80=A6 the picture would be ugly at best.  We attempted a generic H= A/LB slide to make a point and even it was ugly =E2=80=A6such are the limita= tions of ASCII art.

    &nbs= p;

    In line =E2= =80=A6

    &nbs= p;

    From: Linda Dunbar <linda.dunbar@huawei.com>
    Date: Wednesday, May 28, 2014 3:34 PM
    To: "Paul Quinn (paulq)" <paulq= @cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.com>
    Cc: "sfc@ietf.org" <sfc@ietf.org>
    Subject: [sfc] questions of "load balancing considerations" in the dr= aft-quinn-sfc-arch-05

    &nbs= p;

    Paul and Joel,

     <= /p>

    Does the Load Balancing Fi= gure 5 (of draft-quinn-sfc-arch-05) assume that SF1 is responsible for balan= cing traffic among the 3 instances of SF2, and SF3 is responsible for balanc= ing traffic among the 3 instances of SF4?

    &nbs= p;

    <keg&g= t; Document text below the picture says "Either through an imbedded action i= n sf1 and sf3, or through external

    control, t= he service functions sf2 and sf4 are elastically expanded and contracte= d dynamically."

     <= /p>

    Isn=E2=80=99t it a single= point of failure?

    &nbs= p;

    <keg&g= t; Document text immediately subsequent to that picture and paragraph illust= rates HA scenarios.

     <= /p>

    Some service functions ar= e Stateful, i.e. they may require packets from same flows to traverse the sa= me service function instance. For the Load Balancing scheme described by Fig= ure 5, do you assume that SF1 and SF3 will be responsible for making sure that same flows go through the same= service function instance?

    &nbs= p;

    <keg&g= t; Again, the aforementioned text deliberately allows this responsibility to= be either imbedded in the elasticity-causing function or to be controlled e= xternally or centrally.  We don't get into the mechanics as these can vary.  While stateful/bidirectional does ad= d an additional burden, it can be accommodated without an explosion of discr= ete chains.  For example, it could be handled "at allocation time" if e= lasticity is managed via a separate entity and the individual allocations reflected through service chain control in t= he initial metadata bound to at the classification point in either direction= .  OR, if the devices are working as a paired system (single vendor or e= cosystem) with integrated elasticity, they could pass metadata between them when sf1 or sf3 does the initial dyna= mic allocation (affecting local forwarding on it's partner).  That's pr= obably not an exhaustive list of ways to solve the problem.  8^)

    &nbs= p;

    <keg&g= t; The point of this section was that elasticity and HA should not cause an i= nordinate explosion of discrete chains without recommending a particular sol= ution.  That is,  you shouldn't create unnecessary  complexity where it doesn't need to exist.

     <= /p>

    For the stateful service f= unctions, if a flow is switched from SF-Instance-X to SF-Instance-Y, the SF-= Instance-Y needs to synchronize the states from SF-Instance-X. Who is respon= sible for those states maintenance for the Load Balancing described in Figure 5?

    &nbs= p;

    <keg&g= t; None of those entities exist in Figure 5.  Can you re-phrase your qu= estion from the figure? 

     <= /p>

    Linda

     <= /p>

     [L1]Require pushing= policies to SF1 on how to load balance multiple instances of SF2.

     

    SF1 may not have the capability to balance among multiple instances of SF2

    _______________________________________________=
    sfc mailing list
    s= fc@ietf.org
    https://www.ietf.org/mailman/listinfo/sfc
    = --Apple-Mail-690871F3-6E24-4993-B5C6-04CB15EF76CF-- From nobody Thu May 29 10:16:42 2014 Return-Path: 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 F15161A018C for ; Thu, 29 May 2014 10:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 BmoFWEbDe1py for ; Thu, 29 May 2014 10:16:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A8491A0254 for ; Thu, 29 May 2014 10:16:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHK37931; Thu, 29 May 2014 17:16:26 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 18:15:30 +0100 Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 18:16:01 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml702-chm.china.huawei.com ([169.254.4.56]) with mapi id 14.03.0158.001; Thu, 29 May 2014 10:15:50 -0700 From: Linda Dunbar To: "Ken Gray (kegray)" , Eric Gray , "Paul Quinn (paulq)" , "Joel M. Halpern" Thread-Topic: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 Thread-Index: AQHPerstNYLhn/ifQS+CjPHej+3iV5tWg/PggAEJnTCAACWuAIAAF//Q Date: Thu, 29 May 2014 17:15:49 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D28D8E@dfweml701-chm.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD0288@eusaamb107.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.251] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D28D8Edfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/eq6PIe_8P-AJ3BL10dZrHipSSPo Cc: "sfc@ietf.org" Subject: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 17:16:38 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645D28D8Edfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eric and Ken: The current text explicitly says " sf1 would use local logic -- hash, stat= e table, etc. -- to distribute the chained packets to sf2.". To me this is= not generic description. Why it has to be sf1 to choose which instance of = sf2 for the chain? What if the decision is on SFF node? If you want to make the text generic, I suggest removing the text on how SF= 1 having local logic to choose SF2, like: "In the example shown in Figure 5, the load distribution decision for SF2 c= an be localized at nodes to which SF2 is connected (though the decision may be affected by a macro policy provided in some fo= rm by the control entity)." "The load distribution decision will be localized (in general, although the= re might be macro policy controlling that" Linda -----Original Message----- From: Ken Gray (kegray) [mailto:kegray@cisco.com] Sent: Thursday, May 29, 2014 9:41 AM To: Eric Gray; Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern Cc: sfc@ietf.org Subject: Re: [sfc] questions of "load balancing considerations" in the draf= t-quinn-sfc-arch-05 Yep, can see how it is a bit too "thick". I'm okay with your suggested sim= plification. On 5/29/14 10:25 AM, "Eric Gray" > wrote: >Linda, > > A few points: >1) probably better not to use MS Word (assuming that is what you used) >to add comments to your mail (not sure many people will be able to read >them); best to simply include your comment(s) directly. >2) being careful about providing text to ensure that the right context >is included can help to understand your point. >3) your comments appear (as Ken pointed out in a separate response) not >to be > based on what any of us said; in fact, it looks like what you >really mean is "based > on my understanding of what you have said" as a way to make a >separate (but > related) point. > >In your first point, a more complete context would be included if you >quoted this: > >"The load distribution decision will be localized (in general, although >there might > be macro policy controlling that - which is out of scope for the >sake of a simple > example). In this case, the control entity will push to the sf1 >nodes, a table of > sorts: sf2 with a series of next hops, and if needed some weighted >or other > metrics (these could also be decided locally by some policy, but sf1 >would need > to be aware of expand/contract triggers and actions). sf1 would use >local logic -- > hash, state table, etc. -- to distribute the chained packets to sf2." > >This is the entire paragraph, after the first two sentences. > >I believe the issue with this text is that the authors have improperly >parenthesized text, making the meaning of this paragraph >self-contradictory and rather opaque on first reading it. > >In fact, grammatically speaking the entire paragraph is a mess - and >that does not help in understanding it. > >The way I have puzzled it out, the text "[in] this case, the control >entity will push to the sf1 nodes, a table of [some sort: e.g. - ] sf2 >with a series of next hops, and [(if needed)] some weighted or other >metrics" applies to the text in parentheses in the preceding sentence >(i.e. - "in general, although there might be [a] macro policy >controlling that - ..."). In other words, "this case" refers to the >case where a macro policy is used to control the "local decision" >process. > >As you can see from the way I have hacked up the sentences in my effort >to make sense of them, and the amount of restructuring I think the text >requires, it is my opinion that the text needs a major rework. > >For one thing, the complex example given actually doesn't help and >should not be included. > >Assuming I have the meaning correct, I would replace the quoted text >above with: > >"In the example shown in Figure 5, the load distribution decision for >SF2 is localized > at SF1 (though the decision may be affected by a macro policy >provided in some form by the control entity)." > >The rest of the previous text only adds confusion as a result of >over-stating the example. > >As a matter of personal preference, I would also use the word "embedded" >as >the better-known spelling of the word "imbedded" used in the first >sentence (and possibly elsewhere in the draft). > >I agree with Ken that your second suggested change is incorrect. > >-- >Eric > > > >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >Sent: Wednesday, May 28, 2014 5:50 PM >To: Ken Gray (kegray); Paul Quinn (paulq); Joel M. Halpern >Cc: sfc@ietf.org >Subject: Re: [sfc] questions of "load balancing considerations" in the >draft-quinn-sfc-arch-05 > >Joel, Eric, and Ken, > >Thank you very much for the explanation. > >Based on what you said, the description on how "control entity push to >the sf1 nodes ." should be removed from the text, specifically: > >"In this > case, the control entity will push to the sf1 nodes, a table of > sorts: sf2 with a series of next hops, and if needed some weighted or > other metrics (these could also be decided locally by some policy, > but sf1 would need to be aware of expand/contract triggers and > actions)." > > >Should also change the sentence after the Figure 5 to > >"Either through an imbedded action in sf1 and sf3, the SFF nodes to >which the multiple instances of SF2 or SF4 are attached, or through extern= al > control, the service functions sf2 and sf4 are elastically expanded > and contracted dynamically." > > >Linda >From: Ken Gray (kegray) [mailto:kegray@cisco.com] >Sent: Wednesday, May 28, 2014 4:24 PM >To: Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern >Cc: sfc@ietf.org >Subject: Re: [sfc] questions of "load balancing considerations" in the >draft-quinn-sfc-arch-05 > >+1 to Joel . the picture would be ugly at best. We attempted a generic >HA/LB slide to make a point and even it was ugly .such are the >limitations of ASCII art. > >In line . > >From: Linda Dunbar > >Date: Wednesday, May 28, 2014 3:34 PM >To: "Paul Quinn (paulq)" >, "Joel = M. Halpern" >> >Cc: "sfc@ietf.org" = > >Subject: [sfc] questions of "load balancing considerations" in the >draft-quinn-sfc-arch-05 > >Paul and Joel, > >Does the Load Balancing Figure 5 (of draft-quinn-sfc-arch-05) assume >that >SF1 is responsible for balancing traffic among the 3 instances of SF2, >and SF3 is responsible for balancing traffic among the 3 instances of SF4? > > Document text below the picture says "Either through an imbedded >action in sf1 and sf3, or through external control, the service >functions sf2 and sf4 are elastically expanded and contracted >dynamically." > >Isn't it a single point of failure? > > Document text immediately subsequent to that picture and >paragraph illustrates HA scenarios. > >Some service functions are Stateful, i.e. they may require packets from >same flows to traverse the same service function instance. For the Load >Balancing scheme described by Figure 5, do you assume that SF1 and SF3 >will be responsible for making sure that same flows go through the same >service function instance? > > Again, the aforementioned text deliberately allows this >responsibility to be either imbedded in the elasticity-causing function >or to be controlled externally or centrally. We don't get into the >mechanics as these can vary. While stateful/bidirectional does add an >additional burden, it can be accommodated without an explosion of >discrete chains. For example, it could be handled "at allocation time" >if elasticity is managed via a separate entity and the individual >allocations reflected through service chain control in the initial >metadata bound to at the classification point in either direction. OR, >if the devices are working as a paired system (single vendor or >ecosystem) with integrated elasticity, they could pass metadata between >them when sf1 or sf3 does the initial dynamic allocation (affecting >local forwarding on it's partner). That's probably not an exhaustive >list of ways to solve the problem. 8^) > > The point of this section was that elasticity and HA should not >cause an inordinate explosion of discrete chains without recommending a >particular solution. That is, you shouldn't create unnecessary >complexity where it doesn't need to exist. > >For the stateful service functions, if a flow is switched from >SF-Instance-X to SF-Instance-Y, the SF-Instance-Y needs to synchronize >the states from SF-Instance-X. Who is responsible for those states >maintenance for the Load Balancing described in Figure 5? > > None of those entities exist in Figure 5. Can you re-phrase your >question from the figure? > >Linda > --_000_4A95BA014132FF49AE685FAB4B9F17F645D28D8Edfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Eric and Ken:
     
    The current text explicitly says " sf1 would use local logic --&n= bsp; hash, state table, etc. -- to distribute the chained packets to sf2.&q= uot;.  To me this is not generic description. Why it has to be sf1 to = choose which instance of sf2 for the chain? What if the decision is on SFF node?  
     
     
    If you want to make the text generic, I suggest removing the text on h= ow SF1 having local logic to choose SF2, like:
     
    "In the example shown in Figure 5, the load distribution decision= for SF2 can be localized at nodes to which SF2 is connected
    (though the decision may be affected by a macro policy provided in som= e  form by the control entity)."
     
     
    "The load distribution decision will be localized (in general, al= though there might
       be macro policy controlling that”
     
    Linda
     
    -----Original Message-----
    From: Ken Gray (kegray) [mailto:kegray@= cisco.com]
    Sent: Thursday, May 29, 2014 9:41 AM
    To: Eric Gray; Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern
    Cc: sfc@ietf.org
    Subject: Re: [sfc] questions of "load balancing considerations" i= n the draft-quinn-sfc-arch-05
     
    Yep, can see how it is a bit too "thick".  I'm okay wit= h your suggested simplification.
     
    On 5/29/14 10:25 AM, "Eric Gray" <eric.gray@ericsson.com> wrote:
     
    >Linda,
    >
    >       A few points:
    >1) probably better not to use MS Word (assuming that is what you u= sed)
    >to add comments to your mail (not sure many people will be able to= read
    >them); best to simply include your comment(s) directly.
    >2) being careful about providing text to ensure that the right con= text
    >is included can help to understand your point.
    >3) your comments appear (as Ken pointed out in a separate response= ) not
    >to be
    >     based on what any of us said; in fact, it= looks like what you
    >really mean is "based
    >     on my understanding of what you have said= " as a way to make a
    >separate (but
    >     related) point.
    >
    >In your first point, a more complete context would be included if = you
    >quoted this:
    >
    >"The load distribution decision will be localized (in general= , although
    >there might
    >   be macro policy controlling that - which is out of sc= ope for the
    >sake of a simple
    >   example).  In this case, the control entity will= push to the sf1
    >nodes, a table of
    >   sorts: sf2 with a series of next hops, and if needed = some weighted
    >or other
    >   metrics (these could also be decided locally by some = policy, but sf1
    >would need
    >   to be aware of expand/contract triggers and actions).=   sf1 would use
    >local logic --
    >   hash, state table, etc. -- to distribute the chained = packets to sf2."
    >
    >This is the entire paragraph, after the first two sentences.
    >
    >I believe the issue with this text is that the authors have improp= erly
    >parenthesized text, making the meaning of this paragraph
    >self-contradictory and rather opaque on first reading it.
    >
    >In fact, grammatically speaking the entire paragraph is a mess - a= nd
    >that does not help in understanding it.
    >
    >The way I have puzzled it out, the text "[in] this case, the = control
    >entity will push to the sf1 nodes, a table of [some sort: e.g.&nbs= p; - ] sf2
    >with a series of next hops, and [(if needed)] some weighted or oth= er
    >metrics" applies to the text in parentheses in the preceding = sentence
    >(i.e. - "in general, although there might be [a] macro policy=
    >controlling that - ...").  In other words, "this ca= se" refers to the
    >case where a macro policy is used to control the "local decis= ion"
    >process.
    >
    >As you can see from the way I have hacked up the sentences in my e= ffort
    >to make sense of them, and the amount of restructuring I think the= text
    >requires, it is my opinion that the text needs a major rework.
    >
    >For one thing, the complex example given actually doesn't help and=
    >should not be included.
    >
    >Assuming I have the meaning correct, I would replace the quoted te= xt
    >above with:
    >
    >"In the example shown in Figure 5, the load distribution deci= sion for
    >SF2 is localized
    >  at SF1 (though the decision may be affected by a macro poli= cy
    >provided in some  form by the control entity)."
    >
    >The rest of the previous text only adds confusion as a result of <= /div>
    >over-stating the example.
    >
    >As a matter of personal preference, I would also use the word &quo= t;embedded"
    >as
    >the better-known spelling of the word "imbedded" used in= the first
    >sentence (and possibly elsewhere in the draft).
    >
    >I agree with Ken that your second suggested change is incorrect.
    >
    >--
    >Eric
    > 
    >
    >
    >From: sfc [mailto:sfc-boun= ces@ietf.org] On Behalf Of Linda Dunbar
    >Sent: Wednesday, May 28, 2014 5:50 PM
    >To: Ken Gray (kegray); Paul Quinn (paulq); Joel M. Halpern
    >Subject: Re: [sfc] questions of "load balancing consideration= s" in the
    >draft-quinn-sfc-arch-05
    >
    >Joel, Eric, and Ken,
    >
    >Thank you very much for the explanation.
    >
    >Based on what you said, the description on how "control entit= y  push to
    >the sf1 nodes ." should be removed from the text, specificall= y:
    >
    >"In this
    >   case, the control entity will push to the sf1 nodes, = a table of
    >   sorts:  sf2 with a series of next hops, and if n= eeded some weighted or
    >   other metrics (these could also be decided locally by= some policy,
    >   but sf1 would need to be aware of expand/contract tri= ggers and
    >   actions)."
    >
    >
    >Should also change the sentence after the Figure 5 to
    >
    >"Either through an imbedded action in sf1 and sf3, the SFF no= des to
    >which the multiple instances of SF2 or SF4 are attached, or throug= h external
    >   control, the service functions sf2 and sf4 are elasti= cally expanded
    >   and contracted dynamically."
    >
    >
    >Linda
    >From: Ken Gray (kegray) [mailt= o:kegray@cisco.com]
    >Sent: Wednesday, May 28, 2014 4:24 PM
    >To: Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern
    >Subject: Re: [sfc] questions of "load balancing consideration= s" in the
    >draft-quinn-sfc-arch-05
    >
    >+1 to Joel . the picture would be ugly at best.  We attem= pted a generic
    >HA/LB slide to make a point and even it was ugly .such are the
    >limitations of ASCII art.
    >
    >In line .
    >
    >From: Linda Dunbar <= linda.dunbar@huawei.com>
    >Date: Wednesday, May 28, 2014 3:34 PM
    >To: "Paul Quinn (paulq)" <paulq@cisco.com>, "Joel M. Halpern"
    >Subject: [sfc] questions of "load balancing considerations&qu= ot; in the
    >draft-quinn-sfc-arch-05
    >
    >Paul and Joel,
    >
    >Does the Load Balancing Figure 5 (of draft-quinn-sfc-arch-05) assu= me
    >that
    >SF1 is responsible for balancing traffic among the 3 instances of = SF2,
    >and SF3 is responsible for balancing traffic among the 3 instances= of SF4?
    >
    ><keg> Document text below the picture says "Either thro= ugh an imbedded
    >action in sf1 and sf3, or through external control, the service
    >functions sf2 and sf4 are elastically expanded and contracted
    >dynamically."
    >
    >Isn't it a single point of failure?
    >
    ><keg> Document text immediately subsequent to that picture a= nd
    >paragraph illustrates HA scenarios.
    >
    >Some service functions are Stateful, i.e. they may require packets= from
    >same flows to traverse the same service function instance. For the= Load
    >Balancing scheme described by Figure 5, do you assume that SF1 and= SF3
    >will be responsible for making sure that same flows go through the= same
    >service function instance?
    >
    ><keg> Again, the aforementioned text deliberately allows thi= s
    >responsibility to be either imbedded in the elasticity-causing fun= ction
    >or to be controlled externally or centrally.  We don't get in= to the
    >mechanics as these can vary.  While stateful/bidirectional do= es add an
    >additional burden, it can be accommodated without an explosion of =
    >discrete chains.  For example, it could be handled "at a= llocation time"
    >if elasticity is managed via a separate entity and the individual =
    >allocations reflected through service chain control in the initial=
    >metadata bound to at the classification point in either direction.=   OR,
    >if the devices are working as a paired system (single vendor or
    >ecosystem) with integrated elasticity, they could pass metadata be= tween
    >them when sf1 or sf3 does the initial dynamic allocation (affectin= g
    >local forwarding on it's partner).  That's probably not an ex= haustive
    >list of ways to solve the problem.  8^)
    >
    ><keg> The point of this section was that elasticity and HA s= hould not
    >cause an inordinate explosion of discrete chains without recommend= ing a
    >particular solution.  That is,  you shouldn't create unn= ecessary
    >complexity where it doesn't need to exist.
    >
    >For the stateful service functions, if a flow is switched from
    >SF-Instance-X to SF-Instance-Y, the SF-Instance-Y needs to synchro= nize
    >the states from SF-Instance-X. Who is responsible for those states=
    >maintenance for the Load Balancing described in Figure 5?
    >
    ><keg> None of those entities exist in Figure 5.  Can yo= u re-phrase your
    >question from the figure?
    >
    >Linda
    >
     
     
    --_000_4A95BA014132FF49AE685FAB4B9F17F645D28D8Edfweml701chmchi_-- From nobody Thu May 29 10:33:31 2014 Return-Path: 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 AB47A1A018C for ; Thu, 29 May 2014 10:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.552 X-Spam-Level: X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 YQvXGoK2H2_w for ; Thu, 29 May 2014 10:33:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB87E1A016C for ; Thu, 29 May 2014 10:33:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHK38761; Thu, 29 May 2014 17:33:21 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 18:32:49 +0100 Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 18:33:20 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml702-chm.china.huawei.com ([169.254.4.56]) with mapi id 14.03.0158.001; Thu, 29 May 2014 10:33:12 -0700 From: Lucy yong To: Ron Parker , Joel Halpern Direct , Qin Wu , "Ken Gray (kegray)" , Linda Dunbar Thread-Topic: =?utf-8?B?W3NmY10g562U5aSNOiAgcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2luZyBj?= =?utf-8?Q?onsiderations"_in_the_draft-quinn-sfc-arch-05?= Thread-Index: AQHPevJ+bQj6qZJ1gUuJhU4xSPoA45tX/+KA//+T4OCAAH8oAP//jLxwgAB6EgD//7ZnwA== Date: Thu, 29 May 2014 17:33:11 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D45389AF4@dfweml701-chm.china.huawei.com> References: , <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> <16984558-2B4C-4873-AFC7-DCD2698CA745@cisco.com> <53873333.80807@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D45389906@dfweml701-chm.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D453899C2@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.138.124] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/XzyhpB7YjFzUWztQcWikrpOhDPk Cc: "Joel M. Halpern" , "Paul Quinn \(paulq\)" , "sfc@ietf.org" Subject: Re: [sfc] =?utf-8?b?562U5aSNOiAgcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2lu?= =?utf-8?q?g_considerations=22_in_the_draft-quinn-sfc-arch-05?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 17:33:29 -0000 SGkgUm9uLA0KDQpBZ3JlZS4gSG9wZSB0aGF0IGVkaXRvcnMgYWRkcmVzcyB0aGF0IGluIG5leHQg dmVyc2lvbi4NCg0KSW4gYWRkaXRpb24sIHRoZSB3b3JkICJub2RlIiBpcyB1c2VkIG1hbnkgdGlt ZXMgYW5kIGluY29uc2lzdGVudGx5IGluIGN1cnJlbnQgdmVyc2lvbi4gSG9wZSB0aGF0IHdpbGwg YmUgZml4ZWQgYXMgd2VsbC4NCg0KVGhhbmtzLA0KTHVjeQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBSb24gUGFya2VyIFttYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5l dHdvcmtzLmNvbV0gDQpTZW50OiBUaHVyc2RheSwgTWF5IDI5LCAyMDE0IDk6NDkgQU0NClRvOiBM dWN5IHlvbmc7IEpvZWwgSGFscGVybiBEaXJlY3Q7IFFpbiBXdTsgS2VuIEdyYXkgKGtlZ3JheSk7 IExpbmRhIER1bmJhcg0KQ2M6IEpvZWwgTS4gSGFscGVybjsgUGF1bCBRdWlubiAocGF1bHEpOyBz ZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbc2ZjXSDnrZTlpI06IHF1ZXN0aW9ucyBvZiAibG9h ZCBiYWxhbmNpbmcgY29uc2lkZXJhdGlvbnMiIGluIHRoZSBkcmFmdC1xdWlubi1zZmMtYXJjaC0w NQ0KDQpIaSwgTHVjeS4NCg0KSSBhZ3JlZSBhYm91dCB0aGUgdmlldyBvZiAxIHNlcnZpY2UgZnVu Y3Rpb24gdnMuIG11bHRpcGxlIHNlcnZpY2UgZnVuY3Rpb24gaW5zdGFuY2VzLiAgIEluIHRoZSBs YXR0ZXIgY2FzZSwgcGVyaGFwcyB3ZSBjb3VsZCBkZXNjcmliZSBpdCBub3QgYXMgInNlcnZpY2Ug ZnVuY3Rpb24gZXhwYW5zaW9uIiwgYnV0IHJhdGhlciAic2VydmljZSBmdW5jdGlvbiBpbnN0YW5j ZSBzZWxlY3Rpb24iLg0KDQogICBSb24NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMdWN5 IHlvbmcNClNlbnQ6IFRodXJzZGF5LCBNYXkgMjksIDIwMTQgMTA6MzkgQU0NClRvOiBSb24gUGFy a2VyOyBKb2VsIEhhbHBlcm4gRGlyZWN0OyBRaW4gV3U7IEtlbiBHcmF5IChrZWdyYXkpOyBMaW5k YSBEdW5iYXINCkNjOiBKb2VsIE0uIEhhbHBlcm47IFBhdWwgUXVpbm4gKHBhdWxxKTsgc2ZjQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW3NmY10g562U5aSNOiBxdWVzdGlvbnMgb2YgImxvYWQgYmFs YW5jaW5nIGNvbnNpZGVyYXRpb25zIiBpbiB0aGUgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDUNCg0K SGkgUm9uLA0KDQpJIGFncmVlIHdpdGggd2hhdCB5b3Ugc2FpZC4gSWYgYSBzZXJ2aWNlIGZ1bmN0 aW9uIGR5bmFtaWMgZXhwYW5zaW9uIGlzIGltcGxlbWVudGVkIGFzIGNvbXBsZXRlbHkgaW50ZXJu YWwsIGkuZS4gbG9va3MgbGlrZSBvbmUgU0YgY29tcG9uZW50IGluIFNGQyBuZXR3b3JrcywgSU1P OiBTRkMgYXJjaGl0ZWN0dXJlIGRvZXMgbm90IG5lZWQgc3RlcCBpbnRvIHRoYXQgYW5kIGp1c3Qg dHJlYXQgaXQgYXMgb25lIFNGIGluc3RhbmNlIGluIFNGQyBuZXR3b3Jrcy4gVGhlcmUgYXJlIG90 aGVyIHNjZW5hcmlvcyB3aGVyZSBpbmRpdmlkdWFsIFNGIGluc3RhbmNlcyBleHBvc2UgdG8gdGhl IFNGQyBuZXR3b3JrLCBTRkMgYXJjaGl0ZWN0dXJlIG5lZWRzIHRvIGNvdmVyIHRoYXQuDQoNClRo YW5rcywNCkx1Y3kNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJvbiBQYXJr ZXIgW21haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tXQ0KU2VudDogVGh1cnNk YXksIE1heSAyOSwgMjAxNCA5OjI1IEFNDQpUbzogTHVjeSB5b25nOyBKb2VsIEhhbHBlcm4gRGly ZWN0OyBRaW4gV3U7IEtlbiBHcmF5IChrZWdyYXkpOyBMaW5kYSBEdW5iYXINCkNjOiBKb2VsIE0u IEhhbHBlcm47IFBhdWwgUXVpbm4gKHBhdWxxKTsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSRTog W3NmY10g562U5aSNOiBxdWVzdGlvbnMgb2YgImxvYWQgYmFsYW5jaW5nIGNvbnNpZGVyYXRpb25z IiBpbiB0aGUgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDUNCg0KTHVjeSwNCg0KV2hldGhlciBvciBu b3QgZHluYW1pYyBleHBhbnNpb24gcmVxdWlyZXMgYSBsb2FkIGJhbGFuY2VyIGlzIHNwZWNpZmlj IHRvIHRoZSBhcmNoaXRlY3R1cmUgb2YgdGhhdCBzZXJ2aWNlIGZ1bmN0aW9uLiAgIFRoZXJlIGFy ZSBhcmNoaXRlY3R1cmVzIHRoYXQgYXJlIGludGVybmFsbHkgbG9hZCBiYWxhbmNlZC4NCg0KICAg Um9uDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNmYyBbbWFpbHRvOnNm Yy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTHVjeSB5b25nDQpTZW50OiBUaHVyc2Rh eSwgTWF5IDI5LCAyMDE0IDk6NTcgQU0NClRvOiBKb2VsIEhhbHBlcm4gRGlyZWN0OyBRaW4gV3U7 IEtlbiBHcmF5IChrZWdyYXkpOyBMaW5kYSBEdW5iYXINCkNjOiBKb2VsIE0uIEhhbHBlcm47IFBh dWwgUXVpbm4gKHBhdWxxKTsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NmY10g562U5aSN OiBxdWVzdGlvbnMgb2YgImxvYWQgYmFsYW5jaW5nIGNvbnNpZGVyYXRpb25zIiBpbiB0aGUgZHJh ZnQtcXVpbm4tc2ZjLWFyY2gtMDUNCg0KSGkgSm9lbCwNCg0KQSBsb2FkIGJhbGFuY2VyIGlzIG5l ZWRlZCB0byBzdXBwb3J0IGVsYXN0aWMgZXhwYW5zaW9uIG9mIGEgc2VydmljZSBmdW5jdGlvbiBh bHRob3VnaCBhIExCIGNhbiBiZSB0cmFuc3BhcmVudGx5IHRvIGEgU0ZDLiANCg0KSXQgaXMgZ29v ZCB0byBtZW50aW9uIHRoaXMgaW4gc2VjdGlvbiA2Lg0KDQpMdWN5ICAgDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEpvZWwgSGFscGVybiBEaXJlY3QNClNlbnQ6IFRodXJzZGF5LCBNYXkgMjks IDIwMTQgODoxNyBBTQ0KVG86IFFpbiBXdTsgS2VuIEdyYXkgKGtlZ3JheSk7IExpbmRhIER1bmJh cg0KQ2M6IEpvZWwgTS4gSGFscGVybjsgUGF1bCBRdWlubiAocGF1bHEpOyBzZmNAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbc2ZjXSDnrZTlpI06IHF1ZXN0aW9ucyBvZiAibG9hZCBiYWxhbmNpbmcg Y29uc2lkZXJhdGlvbnMiIGluIHRoZSBkcmFmdC1xdWlubi1zZmMtYXJjaC0wNQ0KDQpJIGFtIG5v dCBmb2xsb3dpbmcgeW91ciBxdWVzdGlvbi4NClNGRiBjYW4gaGF2ZSBhIGNvLWxvY2F0ZWQgbG9h ZCBiYWxhbmNlci4gIE9yIHRoZSBsb2FkIGJhbGFuY2VyIGNhbiBiZSB0cmFuc3BhcmVudGx5IGJl aGluZCB0aGUgU0ZGLCB1c2luZyBhbnkgbnVtYmVyIG9mIG1lY2hhbmlzbXMuDQpXZSBhcmUgbm90 IG1hbmRhdGluZyB3aGVyZSBpdCBpcyBsb2NhdGVkLg0KDQpZb3VycywNCkpvZWwNCg0KT24gNS8y OC8xNCwgMTE6NTUgUE0sIFFpbiBXdSB3cm90ZToNCj4gWW91IGFyZSB0YWxraW5nIGFib3V0IHNl cnZpY2UgZnVuY3Rpb24gc2NhbGUgdXAgYW5kIGRvd24uDQo+DQo+IFNpbmNlIHNlcnZpY2Ugbm9k ZSBjYW4gaG9zdCBvbmUgb3IgbXVsdGlwbGUgc2VydmljZSBmdW5jdGlvbnMsIHdoeSANCj4gc2Vy dmljZSBub2RlIGNhbiBub3QgYmUgdXNlZCB0byBjb250cm9sIHNjYWxlIHVwIG9yIGRvd24gb2Yg c2VydmljZSANCj4gZnVuY3Rpb25zIGl0Pw0KPg0KPiBUbyBhdm9pZCBzaGFyZSByaXNrIGZhaWx1 cmUsIHNlcnZpY2Ugbm9kZSBjYW4gYmUgcHJldmlvdXMgc2VydmljZSANCj4gbm9kZSwgZS5nLiwg aXQgY2FuIGJlIHRoZSBvbmUgdGhhdCBob3N0cyBzZjEgb3Igc2YzLg0KPg0KPiBBbHNvIFNGRiBp cyByZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZyB0cmFmZmljIHRvIGFueSBjb25uZWN0ZWQgDQo+ IHNlcnZpY2UgZnVuY3Rpb25zLCB3aHkgbm90IFNGRiBjYW4gbm90IGJlIHVzZWQgdG8gbWFuYWdl IHNjYWxlIHVwIG9yIA0KPiBkb3duIG9mIHNlcnZpY2UgZnVuY3Rpb24uDQo+DQo+IEFsc28gYmFz ZWQgb24gTkZWIE1BTk8gYXJjaGl0ZWN0dXJlLCB0aGVyZSBpcyByZWZlcmVuY2UgcG9pbnQgYmV0 d2VlbiANCj4gTkZWIGFuZCBORlYgbWFuYWdlciwgTkZWIG1hbmFnZXIgYWxzbyBjYW4gY29udHJv bCBzY2FsZSB1cCBvciBkb3duIG9mIA0KPiBzZXJ2aWNlIGZ1bmN0aW9uLCBJIHRoaW5rIHRoaXMg Y2FzZSBoYXMgYmVlbiBjb3ZlcmVkIGJ5IOKAnHRocm91Z2ggDQo+IGV4dGVybmFsIGNvbnRyb2zi gJ0gaW4gdGhlIGRyYWZ0Lg0KPg0KPiBVc2luZyBzZjEgdGhhdCBwcm92aWRlIGRlZGljYXRlZCBm aXJld2FsbCBzZXJ2aWNlIHRvIHByb3ZpZGUgbG9hZCANCj4gYmFsYW5jaW5nIGZ1bmN0aW9uYWxp dHkgYXMgd2VsbCBpcyBhIGxpdHRsZSBiaXQgd2VpcmQgdG8gbWUuDQo+DQo+IExldCBtZSBrbm93 IGlmIG15IHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdD8NCj4NCj4gUmVnYXJkcyENCj4NCj4gLVFp bg0KPg0KPiAq5Y+R5Lu25Lq6OipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gKuS7 o+ihqCAqS2VuIEdyYXkgKGtlZ3JheSkNCj4gKuWPkemAgeaXtumXtDoqMjAxNOW5tDXmnIgyOeaX pTg6NDkNCj4gKuaUtuS7tuS6ujoqTGluZGEgRHVuYmFyDQo+ICrmioTpgIE6KkpvZWwgTS4gSGFs cGVybjsgUGF1bCBRdWlubiAocGF1bHEpOyBzZmNAaWV0Zi5vcmcNCj4gKuS4u+mimDoqUmU6IFtz ZmNdIHF1ZXN0aW9ucyBvZiAibG9hZCBiYWxhbmNpbmcgY29uc2lkZXJhdGlvbnMiIGluIHRoZQ0K PiBkcmFmdC1xdWlubi1zZmMtYXJjaC0wNQ0KPg0KPiBJIGRvbid0IHNlZSBob3cgeW91IG1ha2Ug dGhlIGxlYXAgZnJvbSB0aGUgZXhwbGFuYXRpb24gb2Ygd2h5IGl0IHdhcyANCj4gaXJyZWxldmFu dCB0byBnbyBpbnRvIG1vcmUgZGV0YWlsIGluIHRoZSBzZWN0aW9uIHRvIHRoZSBlbGltaW5hdGlv biBvZiANCj4gdGhlIHZlcnkgZ2VuZXJhbGl6ZWQgZGVzY3JpcHRpb24gYWNjb21wYW55aW5nIHRo ZSBmaWd1cmUuICBQbGVhc2UgdXNlIA0KPiB5b3VyIG93biBhcmd1bWVudCB0byBqdXN0aWZ5IHRo aXMgYW5kIG5vdCBpbmZlciBhbnkgZXh0cmEgbWVhbmluZyBmcm9tIA0KPiBteSBhbnN3ZXIgdG8g YSBkaWZmZXJlbnQgcXVlc3Rpb24uDQo+DQo+IEFzIHRvIHRoZSBzZWNvbmQgY2hhbmdlLCBpIGRp c2FncmVlLiAgQWdhaW4sIGluIGdlbmVyYWwvYnJvYWQgc3Ryb2tlcw0KPiAtIGZyb20gdGhlIGRy YXdpbmcgYW5kIHRoZSB0ZXh0LCBpdCBpcyB1bmxpa2VseSB0aGF0IGFueSBzcGVjaWFsIA0KPiBh Y3Rpb24gd291bGQgYmUgcmVxdWlyZWQgb24gc2YyIG9yIHNmNCAtIGFzIHRoZXkgY29sbGFwc2Ug aW4gZWl0aGVyIA0KPiBkaXJlY3Rpb24gdG8gYSBzaW5nbGUgbG9naWNhbCBuZXh0IGhvcC4NCj4N Cj4gU2VudCBmcm9tIG15IGlQaG9uZQ0KPg0KPg0KPiBPbiBNYXkgMjgsIDIwMTQsIGF0IDU6NDkg UE0sICJMaW5kYSBEdW5iYXIiIDxsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbSANCj4gPG1haWx0bzps aW5kYS5kdW5iYXJAaHVhd2VpLmNvbT4+IHdyb3RlOg0KPg0KPiAgICAgSm9lbCwgRXJpYywgYW5k IEtlbiwNCj4NCj4gICAgIFRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHRoZSBleHBsYW5hdGlvbi4N Cj4NCj4gICAgIEJhc2VkIG9uIHdoYXQgeW91IHNhaWQsIHRoZSBkZXNjcmlwdGlvbiBvbiBob3cg 4oCcY29udHJvbCBlbnRpdHkgIHB1c2gNCj4gICAgIHRvIHRoZSBzZjEgbm9kZXMg4oCm4oCdIHNo b3VsZCBiZSByZW1vdmVkIGZyb20gdGhlIHRleHQsIHNwZWNpZmljYWxseToNCj4NCj4gICAgIOKA nEluIHRoaXMNCj4NCj4gICAgICAgICBjYXNlLCB0aGUgY29udHJvbCBlbnRpdHkgd2lsbCBwdXNo IHRvIHRoZSBzZjEgbm9kZXMsIGEgdGFibGUgDQo+IG9mDQo+DQo+ICAgICAgICAgc29ydHM6W0wx XSA8I19tc29jb21fMT4gc2YyIHdpdGggYSBzZXJpZXMgb2YgbmV4dCBob3BzLCBhbmQgaWYNCj4g ICAgIG5lZWRlZCBzb21lIHdlaWdodGVkIG9yDQo+DQo+ICAgICAgICAgb3RoZXIgbWV0cmljcyAo dGhlc2UgY291bGQgYWxzbyBiZSBkZWNpZGVkIGxvY2FsbHkgYnkgc29tZSANCj4gcG9saWN5LA0K Pg0KPiAgICAgICAgIGJ1dCBzZjEgd291bGQgbmVlZCB0byBiZSBhd2FyZSBvZiBleHBhbmQvY29u dHJhY3QgdHJpZ2dlcnMgYW5kDQo+DQo+ICAgICAgICAgYWN0aW9ucyku4oCdDQo+DQo+ICAgICBT aG91bGQgYWxzbyBjaGFuZ2UgdGhlIHNlbnRlbmNlIGFmdGVyIHRoZSBGaWd1cmUgNSB0bw0KPg0K PiAgICAg4oCcRWl0aGVyIHRocm91Z2ggYW4gaW1iZWRkZWQgYWN0aW9uIGluIHNmMSBhbmQgc2Yz LCB0aGUgU0ZGIG5vZGVzIHRvDQo+ICAgICB3aGljaCB0aGUgbXVsdGlwbGUgaW5zdGFuY2VzIG9m IFNGMiBvciBTRjQgYXJlIGF0dGFjaGVkLCBvciB0aHJvdWdoDQo+ICAgICBleHRlcm5hbA0KPg0K PiAgICAgICAgIGNvbnRyb2wsIHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyBzZjIgYW5kIHNmNCBhcmUg ZWxhc3RpY2FsbHkgDQo+IGV4cGFuZGVkDQo+DQo+ICAgICAgICAgYW5kIGNvbnRyYWN0ZWQgZHlu YW1pY2FsbHku4oCdDQo+DQo+ICAgICBMaW5kYQ0KPg0KPiAgICAgKkZyb206KktlbiBHcmF5IChr ZWdyYXkpIFttYWlsdG86a2VncmF5QGNpc2NvLmNvbV0NCj4gICAgICpTZW50OiogV2VkbmVzZGF5 LCBNYXkgMjgsIDIwMTQgNDoyNCBQTQ0KPiAgICAgKlRvOiogTGluZGEgRHVuYmFyOyBQYXVsIFF1 aW5uIChwYXVscSk7IEpvZWwgTS4gSGFscGVybg0KPiAgICAgKkNjOiogc2ZjQGlldGYub3JnIDxt YWlsdG86c2ZjQGlldGYub3JnPg0KPiAgICAgKlN1YmplY3Q6KiBSZTogW3NmY10gcXVlc3Rpb25z IG9mICJsb2FkIGJhbGFuY2luZyBjb25zaWRlcmF0aW9ucyIgaW4NCj4gICAgIHRoZSBkcmFmdC1x dWlubi1zZmMtYXJjaC0wNQ0KPg0KPiAgICAgKzEgdG8gSm9lbCDigKYgdGhlIHBpY3R1cmUgd291 bGQgYmUgdWdseSBhdCBiZXN0LiAgV2UgYXR0ZW1wdGVkIGENCj4gICAgIGdlbmVyaWMgSEEvTEIg c2xpZGUgdG8gbWFrZSBhIHBvaW50IGFuZCBldmVuIGl0IHdhcyB1Z2x5IOKApnN1Y2ggYXJlDQo+ ICAgICB0aGUgbGltaXRhdGlvbnMgb2YgQVNDSUkgYXJ0Lg0KPg0KPiAgICAgSW4gbGluZSDigKYN Cj4NCj4gICAgICpGcm9tOiAqTGluZGEgRHVuYmFyIDxsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbQ0K PiAgICAgPG1haWx0bzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbT4+DQo+ICAgICAqRGF0ZTogKldl ZG5lc2RheSwgTWF5IDI4LCAyMDE0IDM6MzQgUE0NCj4gICAgICpUbzogKiJQYXVsIFF1aW5uIChw YXVscSkiIDxwYXVscUBjaXNjby5jb20NCj4gICAgIDxtYWlsdG86cGF1bHFAY2lzY28uY29tPj4s ICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tDQo+ICAgICA8bWFpbHRvOmpt aEBqb2VsaGFscGVybi5jb20+Pg0KPiAgICAgKkNjOiAqInNmY0BpZXRmLm9yZyA8bWFpbHRvOnNm Y0BpZXRmLm9yZz4iIDxzZmNAaWV0Zi5vcmcNCj4gICAgIDxtYWlsdG86c2ZjQGlldGYub3JnPj4N Cj4gICAgICpTdWJqZWN0OiAqW3NmY10gcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2luZyBjb25z aWRlcmF0aW9ucyIgaW4gdGhlDQo+ICAgICBkcmFmdC1xdWlubi1zZmMtYXJjaC0wNQ0KPg0KPiAg ICAgUGF1bCBhbmQgSm9lbCwNCj4NCj4gICAgIERvZXMgdGhlIExvYWQgQmFsYW5jaW5nIEZpZ3Vy ZSA1IChvZiBkcmFmdC1xdWlubi1zZmMtYXJjaC0wNSkgYXNzdW1lDQo+ICAgICB0aGF0IFNGMSBp cyByZXNwb25zaWJsZSBmb3IgYmFsYW5jaW5nIHRyYWZmaWMgYW1vbmcgdGhlIDMgaW5zdGFuY2Vz DQo+ICAgICBvZiBTRjIsIGFuZCBTRjMgaXMgcmVzcG9uc2libGUgZm9yIGJhbGFuY2luZyB0cmFm ZmljIGFtb25nIHRoZSAzDQo+ICAgICBpbnN0YW5jZXMgb2YgU0Y0Pw0KPg0KPiAgICAgPGtlZz4g RG9jdW1lbnQgdGV4dCBiZWxvdyB0aGUgcGljdHVyZSBzYXlzICJFaXRoZXIgdGhyb3VnaCBhbg0K PiAgICAgaW1iZWRkZWQgYWN0aW9uIGluIHNmMSBhbmQgc2YzLCBvciB0aHJvdWdoIGV4dGVybmFs DQo+DQo+ICAgICBjb250cm9sLCB0aGUgc2VydmljZSBmdW5jdGlvbnMgc2YyIGFuZCBzZjQgYXJl IGVsYXN0aWNhbGx5DQo+ICAgICBleHBhbmRlZCBhbmQgY29udHJhY3RlZCBkeW5hbWljYWxseS4i DQo+DQo+ICAgICBJc27igJl0IGl0IGEgc2luZ2xlIHBvaW50IG9mIGZhaWx1cmU/DQo+DQo+ICAg ICA8a2VnPiBEb2N1bWVudCB0ZXh0IGltbWVkaWF0ZWx5IHN1YnNlcXVlbnQgdG8gdGhhdCBwaWN0 dXJlIGFuZA0KPiAgICAgcGFyYWdyYXBoIGlsbHVzdHJhdGVzIEhBIHNjZW5hcmlvcy4NCj4NCj4g ICAgIFNvbWUgc2VydmljZSBmdW5jdGlvbnMgYXJlIFN0YXRlZnVsLCBpLmUuIHRoZXkgbWF5IHJl cXVpcmUgcGFja2V0cw0KPiAgICAgZnJvbSBzYW1lIGZsb3dzIHRvIHRyYXZlcnNlIHRoZSBzYW1l IHNlcnZpY2UgZnVuY3Rpb24gaW5zdGFuY2UuIEZvcg0KPiAgICAgdGhlIExvYWQgQmFsYW5jaW5n IHNjaGVtZSBkZXNjcmliZWQgYnkgRmlndXJlIDUsIGRvIHlvdSBhc3N1bWUgdGhhdA0KPiAgICAg U0YxIGFuZCBTRjMgd2lsbCBiZSByZXNwb25zaWJsZSBmb3IgbWFraW5nIHN1cmUgdGhhdCBzYW1l IGZsb3dzIGdvDQo+ICAgICB0aHJvdWdoIHRoZSBzYW1lIHNlcnZpY2UgZnVuY3Rpb24gaW5zdGFu Y2U/DQo+DQo+ICAgICA8a2VnPiBBZ2FpbiwgdGhlIGFmb3JlbWVudGlvbmVkIHRleHQgZGVsaWJl cmF0ZWx5IGFsbG93cyB0aGlzDQo+ICAgICByZXNwb25zaWJpbGl0eSB0byBiZSBlaXRoZXIgaW1i ZWRkZWQgaW4gdGhlIGVsYXN0aWNpdHktY2F1c2luZw0KPiAgICAgZnVuY3Rpb24gb3IgdG8gYmUg Y29udHJvbGxlZCBleHRlcm5hbGx5IG9yIGNlbnRyYWxseS4gIFdlIGRvbid0IGdldA0KPiAgICAg aW50byB0aGUgbWVjaGFuaWNzIGFzIHRoZXNlIGNhbiB2YXJ5LiAgV2hpbGUgc3RhdGVmdWwvYmlk aXJlY3Rpb25hbA0KPiAgICAgZG9lcyBhZGQgYW4gYWRkaXRpb25hbCBidXJkZW4sIGl0IGNhbiBi ZSBhY2NvbW1vZGF0ZWQgd2l0aG91dCBhbg0KPiAgICAgZXhwbG9zaW9uIG9mIGRpc2NyZXRlIGNo YWlucy4gIEZvciBleGFtcGxlLCBpdCBjb3VsZCBiZSBoYW5kbGVkICJhdA0KPiAgICAgYWxsb2Nh dGlvbiB0aW1lIiBpZiBlbGFzdGljaXR5IGlzIG1hbmFnZWQgdmlhIGEgc2VwYXJhdGUgZW50aXR5 IGFuZA0KPiAgICAgdGhlIGluZGl2aWR1YWwgYWxsb2NhdGlvbnMgcmVmbGVjdGVkIHRocm91Z2gg c2VydmljZSBjaGFpbiBjb250cm9sDQo+ICAgICBpbiB0aGUgaW5pdGlhbCBtZXRhZGF0YSBib3Vu ZCB0byBhdCB0aGUgY2xhc3NpZmljYXRpb24gcG9pbnQgaW4NCj4gICAgIGVpdGhlciBkaXJlY3Rp b24uICBPUiwgaWYgdGhlIGRldmljZXMgYXJlIHdvcmtpbmcgYXMgYSBwYWlyZWQgc3lzdGVtDQo+ ICAgICAoc2luZ2xlIHZlbmRvciBvciBlY29zeXN0ZW0pIHdpdGggaW50ZWdyYXRlZCBlbGFzdGlj aXR5LCB0aGV5IGNvdWxkDQo+ICAgICBwYXNzIG1ldGFkYXRhIGJldHdlZW4gdGhlbSB3aGVuIHNm MSBvciBzZjMgZG9lcyB0aGUgaW5pdGlhbCBkeW5hbWljDQo+ICAgICBhbGxvY2F0aW9uIChhZmZl Y3RpbmcgbG9jYWwgZm9yd2FyZGluZyBvbiBpdCdzIHBhcnRuZXIpLiAgVGhhdCdzDQo+ICAgICBw cm9iYWJseSBub3QgYW4gZXhoYXVzdGl2ZSBsaXN0IG9mIHdheXMgdG8gc29sdmUgdGhlIHByb2Js ZW0uICA4XikNCj4NCj4gICAgIDxrZWc+IFRoZSBwb2ludCBvZiB0aGlzIHNlY3Rpb24gd2FzIHRo YXQgZWxhc3RpY2l0eSBhbmQgSEEgc2hvdWxkDQo+ICAgICBub3QgY2F1c2UgYW4gaW5vcmRpbmF0 ZSBleHBsb3Npb24gb2YgZGlzY3JldGUgY2hhaW5zIHdpdGhvdXQNCj4gICAgIHJlY29tbWVuZGlu ZyBhIHBhcnRpY3VsYXIgc29sdXRpb24uICBUaGF0IGlzLCAgeW91IHNob3VsZG4ndCBjcmVhdGUN Cj4gICAgIHVubmVjZXNzYXJ5ICBjb21wbGV4aXR5IHdoZXJlIGl0IGRvZXNuJ3QgbmVlZCB0byBl eGlzdC4NCj4NCj4gICAgIEZvciB0aGUgc3RhdGVmdWwgc2VydmljZSBmdW5jdGlvbnMsIGlmIGEg ZmxvdyBpcyBzd2l0Y2hlZCBmcm9tDQo+ICAgICBTRi1JbnN0YW5jZS1YIHRvIFNGLUluc3RhbmNl LVksIHRoZSBTRi1JbnN0YW5jZS1ZIG5lZWRzIHRvDQo+ICAgICBzeW5jaHJvbml6ZSB0aGUgc3Rh dGVzIGZyb20gU0YtSW5zdGFuY2UtWC4gV2hvIGlzIHJlc3BvbnNpYmxlIGZvcg0KPiAgICAgdGhv c2Ugc3RhdGVzIG1haW50ZW5hbmNlIGZvciB0aGUgTG9hZCBCYWxhbmNpbmcgZGVzY3JpYmVkIGlu IEZpZ3VyZSA1Pw0KPg0KPiAgICAgPGtlZz4gTm9uZSBvZiB0aG9zZSBlbnRpdGllcyBleGlzdCBp biBGaWd1cmUgNS4gIENhbiB5b3UgcmUtcGhyYXNlDQo+ICAgICB5b3VyIHF1ZXN0aW9uIGZyb20g dGhlIGZpZ3VyZT8NCj4NCj4gICAgIExpbmRhDQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0NCj4N Cj4gUmVxdWlyZSBwdXNoaW5nIHBvbGljaWVzIHRvIFNGMSBvbiBob3cgdG8gbG9hZCBiYWxhbmNl IG11bHRpcGxlIA0KPiBpbnN0YW5jZXMgb2YgU0YyLg0KPg0KPiBTRjEgbWF5IG5vdCBoYXZlIHRo ZSBjYXBhYmlsaXR5IHRvIGJhbGFuY2UgYW1vbmcgbXVsdGlwbGUgaW5zdGFuY2VzIG9mDQo+IFNG Mg0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBzZmMgbWFpbGluZyBsaXN0DQo+IHNmY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNm Y0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGlu ZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQo= From nobody Thu May 29 10:40:39 2014 Return-Path: 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 7B9D11A0499 for ; Thu, 29 May 2014 10:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 4rSSiDxWbOZQ for ; Thu, 29 May 2014 10:40:36 -0700 (PDT) Received: from omzsmtpe01.verizonbusiness.com (omzsmtpe01.verizonbusiness.com [199.249.25.210]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE7F21A0449 for ; Thu, 29 May 2014 10:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=dave.mcdysan@verizon.com; q=dns/txt; s=corp; t=1401385232; x=1432921232; h=from:to:date:subject:message-id:mime-version; bh=1if42CqQ85yYp3jOldTSeDATiCy/n/V/eg1ou2wHxtg=; b=ozzoF+eB+nFxhJaKo7ISlWyRL993Oa7WQWdzwIJdjLceecrqO163TCZf NZk32kHG718yadqeR14pc/2QWNhccOOGVWP5Em1TJsp5MDn8hdiO8rmwS Z7xRP/oiKVnS8rkvABp/+TFsSFGtX139twXQn5JuD5VXzKT4CtWncApuc E=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by omzsmtpe01.verizonbusiness.com with ESMTP; 29 May 2014 17:40:17 +0000 From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.98,935,1392163200"; d="scan'208,217";a="733547519" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi03.verizon.com with ESMTP; 29 May 2014 17:40:17 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([166.68.59.148]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Thu, 29 May 2014 13:40:17 -0400 To: "sfc@ietf.org" Date: Thu, 29 May 2014 13:40:14 -0400 Thread-Topic: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived-flow-use-cases-02 Thread-Index: Ac97ZQ2O95ya+M4sRn+252esY1l5Cg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CFACE9288BBD5davemcdysanoneverizoncom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/tDk02bB9FrX8_b_hMCrhwlaJH6k Subject: Re: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived-flow-use-cases-02 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 17:40:38 -0000 --_000_CFACE9288BBD5davemcdysanoneverizoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Support. Dave From: "Jim Guichard (jguichar)" > Date: Monday, May 19, 2014 1:27 PM To: "sfc@ietf.org" > Subject: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived-flow-u= se-cases-02 Greetings WG: This message begins a two week call for WG adoption of draft-krishnan-sfc-l= ong-lived-flow-use-cases-02 [http://datatracker.ietf.org/doc/draft-krishnan= -sfc-long-lived-flow-use-cases/] ending June 2nd 2014. The draft highlights a number of use cases specific to long lived flows and= appears to compliment our already adopted use case documents. Please respo= nd to the SFC mailing list with any statements of approval or disapproval. As always, please note: 1. This is not WG Last Call. The document is not final, and the WG is exp= ected to modify the document=92s content until there is WG consensus that t= he content is solid. Therefore, please don=92t oppose adoption just because= you want to see changes to its content. 2. If you have objections to adoption of the document, please state your = reasons why, and explain what it would take to address your concerns. 3. If you have issues with the content, by all means raise those issues a= nd we can begin a dialog about how best to address them. --_000_CFACE9288BBD5davemcdysanoneverizoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
    Support.

    Dave

    From: "Jim Guichard (jguichar)" <jguichar@cisco.com>
    Da= te: Monday, May 19, 2014 1:27 PM
    To: "sfc@ietf.org" = <sfc@ietf.org>
    Subject: [sfc] Call for WG adoption of draft-kris= hnan-sfc-long-lived-flow-use-cases-02

    G= reetings WG:

    This message begins a two week call f= or WG adoption of draft-krishnan-sfc-long-lived-flow-use-cases-02 [http://datatracker.ietf.org/doc/draft-krishnan-sfc-long-lived-flow-= use-cases/] ending June 2nd 2014.

    The draft highlights a numb= er of use cases specific to long lived flows and appears to compliment our = already adopted use case documents. Please respond to the SFC mailing list = with any statements of approval or disapproval.

    As= always, please note:
      This is not WG Last Call. The document is not final, and the WG= is expected to modify the document=92s content until there is WG consensus= that the content is solid. Therefore, please don=92t oppose adoption just because you want to see changes to its= content.
    1. If you have objections to ado= ption of the document, please state your reasons why, and explain what it w= ould take to address your concerns.
    2. If = you have issues with the content, by all means raise those issues and we ca= n begin a dialog about how best to address them. 
     --_000_CFACE9288BBD5davemcdysanoneverizoncom_-- From nobody Thu May 29 10:43:17 2014 Return-Path: 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 2BD331A048A for ; Thu, 29 May 2014 10:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 h8QD5dslr1uh for ; Thu, 29 May 2014 10:43:13 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BD701A0449 for ; Thu, 29 May 2014 10:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24502; q=dns/txt; s=iport; t=1401385389; x=1402594989; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3fYDggdf3NylpNtSf9k6Lz2kPRaDFfSA9X7sSh0P2CQ=; b=Uw9QnaAN6ihUOCcRu46CBXafUgIauHjv8mXOwROp7qehb5p38L4jJNfu hTEDzOA13W63mv6Ef2y//sdK1W99xpsvnQtPbetoFXtbKoJuxbMkJpQF5 atmSSu/OJBzhn46w31jeEBnyraB2cemqxEy5zuT570XWReMJB+29W0Spx w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAHVxh1OtJA2M/2dsb2JhbABZgkJFUljCNgGBDRZ0giUBAQEEJwZMEAIBCBEEAQELFgcHMhQJCAEBBAENBQiIOtdXF44hMQYBgyuBFQStHoM4gi8 X-IronPort-AV: E=Sophos;i="4.98,935,1392163200"; d="scan'208,217";a="328937537" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP; 29 May 2014 17:43:02 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s4THh2oH026529 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 May 2014 17:43:02 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.121]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Thu, 29 May 2014 12:43:01 -0500 From: "Jakob Heitz (jheitz)" To: Eric Gray , Joel Halpern , "Paul Quinn (paulq)" Thread-Topic: Figures in draft-quinn-sfc-arch-05 Thread-Index: Ac97S9R6mfocA+1iTpKXBfVlibSBggAGJh5A Date: Thu, 29 May 2014 17:43:01 +0000 Message-ID: <075DE01702BBC249BE1357EFD20DCFE556E2EC@xmb-aln-x02.cisco.com> References: <48E1A67CB9CA044EADFEAB87D814BFF632AD0443@eusaamb107.ericsson.se> In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF632AD0443@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.165.107] Content-Type: multipart/alternative; boundary="_000_075DE01702BBC249BE1357EFD20DCFE556E2ECxmbalnx02ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/hVN8EiVMPj1JU3W7l5ksr0N-QoQ Cc: "sfc@ietf.org" Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 17:43:16 -0000 --_000_075DE01702BBC249BE1357EFD20DCFE556E2ECxmbalnx02ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You could turn the whole picture right by 90 degrees. If you don't like top to bottom instead of left to right, make a note that = it's in landscape. --Jakob From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray Sent: Thursday, May 29, 2014 8:31 AM To: Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: [sfc] Figures in draft-quinn-sfc-arch-05 Paul/Joel, Pretty sure that Figures 5 and 6 don't actually fit the wid= th expected for an Internet Draft (Figure 5 is more than 80 characters wide and Figure 6 is wi= der still). Depending on how a reader tries to read the draft, this can= turn complicated illustrations into a _real_ fun time. :) Also, I am unsure what the figures are trying to convey wit= h some of "dotted lines" crossing the service functions. If the intent is to show that a ser= vice function is a virtual instance hosted by some network device, perhaps this will be bett= er shown in a separate figure and this aspect of Figures 5 and 6 can be eliminated? I would suggest replacing Figure 5 with a figure along the lines of: source +-----+ +-----+ | +-->| sf2 +--+ +-->| sf4 +--+ | | | | | | | | | | +------+--+ +-----+ +-->+-----+--+ +-----+ +->+-----+ | | sf1 | +-----+ | sf3 | +-----+ | sf5 | +->| +----->| sf2 +----->| |----->| sf4 +---->| |-+ | | | | | | | | | | | +------+--+ +-----+ +-->+-----+--+ +-----+ +->+-----+ | | +-----+ | | +-----+ | | +-->| sf2 +--+ +-->| sf4 +--+ +----+ | | | | | +-----+ +-----+ V destination Figure 5: Load Balancing (67 characters?) Similarly, I would suggest replacing Figure 6 with a figure= along the lines of: source | +-----+-+ +-----+-+ +---+ +-->| sf2 |-|+ +-->| sf4 |-|+ | +---|-->| | || +------>| | || | +------+|---+ +-----+ |+-->+-----+|---+ +-----+ |+-->+-----+ | | sf1 || +-----+ +--->| sf3 || +-----+ +--->| sf5 | +-->| +|------>| sf2 |+---->| ||------>| sf4 |+---->| |--+ | | || +---->| |-+ | || +---->| |-+ | | | | +------+|-|-+ +-----+ |+-->+-----+|-|-+ +-----+ |+-->+-----+ | | | | | +-----+ || | | | +-----+ || | | +------++ | +-->| sf2 |-|+ +-----++ | +-->| sf4 |-|+ +-----+ | | | sf1' | | +-->| | +--->| sf3'| | +-->| | +--->| sf5'| | +-->| +--+ | +-----+----->| |--+ | +-----+----->| |--+ | | | | | | | | | +------+----+ +-----+----+ +-----+ | | +--------+ | V destination Figure 6: Load Balancing and HA (72 characters?) In both cases, the figure has all the same connection compl= exity (fixed up in a few places), but seems to be less busy. -- Eric --_000_075DE01702BBC249BE1357EFD20DCFE556E2ECxmbalnx02ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    You could turn the whole picture right by = 90 degrees.

    If you don’t like top to bottom inst= ead of left to right, make a note that it’s in landscape.<= /span>

     

    --Jakob

     

    From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Eric Gray
    Sent: Thursday, May 29, 2014 8:31 AM
    To: Joel Halpern; Paul Quinn (paulq)
    Cc: sfc@ietf.org
    Subject: [sfc] Figures in draft-quinn-sfc-arch-05    <= /p>

     

    Paul/Joel,

     

            &nbs= p;       Pretty sure that Figures 5 and 6 don= ’t actually fit the width expected for an

    Internet Draft (Figure 5 is more than 80 characters = wide and Figure 6 is wider still).

     

            &nbs= p;       Depending on how a reader tries to r= ead the draft, this can turn complicated

    illustrations into a _real_ fun time.  <= span style=3D"font-family:Wingdings"> J

     

            &nbs= p;       Also, I am unsure what the figures a= re trying to convey with some of “dotted

    lines” crossing the service functions.  I= f the intent is to show that a service function is

    a virtual instance hosted by some network device, pe= rhaps this will be better shown

    in a separate figure and this aspect of Figures 5 an= d 6 can be eliminated?

     

    I would suggest replacing= Figure 5 with a figure along the lines of:

     

    source &nbs= p;           +--= ---+           &= nbsp;       +-----+=

      = ;|            +-= ->| sf2 +--+        &nbs= p;   +-->| sf4 +--+

      = ;|            | = ;  |     |  |     &n= bsp;      |   |     = |  |

      = ;|  +------+--+   +-----+  +--&= gt;+-----+--+   +-----+  +->+= -----+

      = ;|  | sf1  |      +-----+ &= nbsp;    | sf3 |      +-----= 3;     | sf5 |

      = ;+->|      +----->| sf2 +-----&g= t;|     |----->| sf4 +---->|   = ;  |-+

      = ;   |      |    &nbs= p; |     |      | &n= bsp;   |      |     = |     |     | |

      = ;   +------+--+   +-----+ = ; +-->+-----+--+   +-----+  += ->+-----+ |

      = ;            &n= bsp;|   +-----+  |     &nbs= p;      |   +-----+  | &nbs= p;        |

      = ;            &n= bsp;+-->| sf2 +--+       =      +-->| sf4 +--+    &n= bsp;+----+

      = ;            &n= bsp;    |     |   &n= bsp;            &nbs= p;  |     |      &nb= sp; |

      = ;            &n= bsp;    +-----+     &n= bsp;            &nbs= p;+-----+        V

      = ;            &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p;     destination

     =

      = ;            &n= bsp;    Figure 5: Load Balancing

     

    (67 characters?)

     

            &nbs= p;       Similarly, I would suggest replacing= Figure 6 with a figure along the

    lines of:

     

       source
         |       &n=
bsp;       +-----+-+ &n=
bsp;            =
;     +-----+-+
     +---+        &nb=
sp;  +-->| sf2 |-|+      &nbs=
p;       +-->| sf4 |-|+=

     |           &#=
43;---|-->|     | ||     &n=
bsp;    +------>|     | ||
     |   +------+|---+   +-----&#=
43; |+-->+-----+|---+   +-----+ |+=
-->+-----+
     |   | sf1  ||      =
 +-----+ +--->| sf3 ||       &=
#43;-----+ +--->| sf5 |
     +-->|      +|------>| sf2=
 |+---->|     ||------>| sf4 |+---->|&=
nbsp;    |--+
     |   |      || +---->|&=
nbsp;    |-+    |    =
 || +---->|     |-+    | =
;    |  |
     |   +------+|-|-+   +-----&#=
43; |+-->+-----+|-|-+   +-----+ |+=
-->+-----+  |
     |           | =
| |   +-----+ ||       =
;   | | |   +-----+ ||    &=
nbsp;       |
     |   +------++ | +-->| sf2 |-|+&=
nbsp;  +-----++ | +-->| sf4 |-|+   &#=
43;-----+  |
     |   | sf1' |  | +-->|   &nb=
sp; | +--->| sf3'|  | +-->|     | &#=
43;--->| sf5'|  |
     +-->|      +--+ | &=
nbsp; +-----+----->|     |--+ | &nb=
sp; +-----+----->|     |--+
         |      | &=
nbsp;  |          &n=
bsp;     |     |    =
|            &n=
bsp;   |     |  |

         +------+----+  &nb=
sp;            =
 +-----+----+        &n=
bsp;       +-----+  |=

    

               =
;             &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;         |=

    

               =
;            &n=
bsp;            =
;            &n=
bsp;            =
; +--------+
    

               =
;            &n=
bsp;            =
;            &n=
bsp;            =
; |
    

               =
;            &n=
bsp;            &nbs=
p;            &=
nbsp;           &nbs=
p;V
    

               =
;            &n=
bsp;            =
;            &n=
bsp;        destination
    

     
    

               =
;         Figure 6: Load Balancing =
and HA
    

     
    

    (72 characters?)
    

     
    

            &nbs=
p;       In both cases, the figure has all th=
e same connection complexity (fixed up in a few
    

    places), but seems to be less busy.
    

     
    

    --
    

    Eric
    --_000_075DE01702BBC249BE1357EFD20DCFE556E2ECxmbalnx02ciscocom_-- From nobody Thu May 29 10:54:35 2014 Return-Path: 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 589561A018A for ; Thu, 29 May 2014 10:54:34 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 r6sXzgHWh6cm for ; Thu, 29 May 2014 10:54:32 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACED81A0164 for ; Thu, 29 May 2014 10:54:31 -0700 (PDT) X-AuditID: c618062d-f79be6d000006b89-6e-5387242c4dba Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id FC.1D.27529.C2427835; Thu, 29 May 2014 14:12:28 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Thu, 29 May 2014 13:54:25 -0400 From: Eric Gray To: "Jakob Heitz (jheitz)" , Joel Halpern , "Paul Quinn (paulq)" Thread-Topic: Figures in draft-quinn-sfc-arch-05 Thread-Index: Ac97S9R6mfocA+1iTpKXBfVlibSBggAGJh5AAACjtcA= Date: Thu, 29 May 2014 17:54:24 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF632AD07D6@eusaamb107.ericsson.se> References: <48E1A67CB9CA044EADFEAB87D814BFF632AD0443@eusaamb107.ericsson.se> <075DE01702BBC249BE1357EFD20DCFE556E2EC@xmb-aln-x02.cisco.com> In-Reply-To: <075DE01702BBC249BE1357EFD20DCFE556E2EC@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF632AD07D6eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZXLonRFdHpT3Y4FuHssXbTY1sFvtfLWW1 ePJgK7sDs8eU3xtZPZYs+ckUwBTFZZOSmpNZllqkb5fAlfF7w3XWgi1nGSumvJnC3sC4YBNj FyMnh4SAicSu439YIGwxiQv31rN1MXJxCAkcZZS41LGAGSQhJLCcUWLqvXwQm01AQ+LYnbWM IEUiAo2MEvvbP7KCJJgFFCUe3frNBGILC+hLbGt7zAZiiwgYSDxY3M0IYVtJ3Ds/AWwoi4Cq RPe6g2A1vAK+Euv/rmCCWNbHKPF7NthFnALeEps3TQCLMwJd9/3UGiaIXeISt57MZ4K4WkBi yZ7zzBC2qMTLx/9YIWwliY+/57ND1OdLvLrdDLVLUOLkzCcsExhFZyEZNQtJ2SwkZRBxHYkF uz+xQdjaEssWvmaGsc8ceMyELL6AkX0VI0dpcWpZbrqRwSZGYJQdk2DT3cG456XlIUYBDkYl Hl4F1vZgIdbEsuLK3EOM0hwsSuK82jergoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw5lS8 6c3k4tOYczySSeH76jLD1l9r111PWffB6oc4a2Fu4ebZSufW7Bf5fTf0ksneb5ZXSm+0+6+Q 3ylr91uvNnGX//5w9aPnfpnln669uXPJMoObNcHPJPouzFMpOJr45vbZSZcbt6hUv7rE49i/ j5NT6cn159OLQhqOVaZKp4eKKQV1XgxrUmIpzkg01GIuKk4EAAgIf5eTAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/7OHXgCWVNbXrCC_A8foUkHrycL0 Cc: "sfc@ietf.org" Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 17:54:34 -0000 --_000_48E1A67CB9CA044EADFEAB87D814BFF632AD07D6eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HaHa, funny man. :) From: Jakob Heitz (jheitz) [mailto:jheitz@cisco.com] Sent: Thursday, May 29, 2014 1:43 PM To: Eric Gray; Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: RE: Figures in draft-quinn-sfc-arch-05 Importance: High You could turn the whole picture right by 90 degrees. If you don't like top to bottom instead of left to right, make a note that = it's in landscape. --Jakob From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray Sent: Thursday, May 29, 2014 8:31 AM To: Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: [sfc] Figures in draft-quinn-sfc-arch-05 Paul/Joel, Pretty sure that Figures 5 and 6 don't actually fit the wid= th expected for an Internet Draft (Figure 5 is more than 80 characters wide and Figure 6 is wi= der still). Depending on how a reader tries to read the draft, this can= turn complicated illustrations into a _real_ fun time. :) Also, I am unsure what the figures are trying to convey wit= h some of "dotted lines" crossing the service functions. If the intent is to show that a ser= vice function is a virtual instance hosted by some network device, perhaps this will be bett= er shown in a separate figure and this aspect of Figures 5 and 6 can be eliminated? I would suggest replacing Figure 5 with a figure along the lines of: source +-----+ +-----+ | +-->| sf2 +--+ +-->| sf4 +--+ | | | | | | | | | | +------+--+ +-----+ +-->+-----+--+ +-----+ +->+-----+ | | sf1 | +-----+ | sf3 | +-----+ | sf5 | +->| +----->| sf2 +----->| |----->| sf4 +---->| |-+ | | | | | | | | | | | +------+--+ +-----+ +-->+-----+--+ +-----+ +->+-----+ | | +-----+ | | +-----+ | | +-->| sf2 +--+ +-->| sf4 +--+ +----+ | | | | | +-----+ +-----+ V destination Figure 5: Load Balancing (67 characters?) Similarly, I would suggest replacing Figure 6 with a figure= along the lines of: source | +-----+-+ +-----+-+ +---+ +-->| sf2 |-|+ +-->| sf4 |-|+ | +---|-->| | || +------>| | || | +------+|---+ +-----+ |+-->+-----+|---+ +-----+ |+-->+-----+ | | sf1 || +-----+ +--->| sf3 || +-----+ +--->| sf5 | +-->| +|------>| sf2 |+---->| ||------>| sf4 |+---->| |--+ | | || +---->| |-+ | || +---->| |-+ | | | | +------+|-|-+ +-----+ |+-->+-----+|-|-+ +-----+ |+-->+-----+ | | | | | +-----+ || | | | +-----+ || | | +------++ | +-->| sf2 |-|+ +-----++ | +-->| sf4 |-|+ +-----+ | | | sf1' | | +-->| | +--->| sf3'| | +-->| | +--->| sf5'| | +-->| +--+ | +-----+----->| |--+ | +-----+----->| |--+ | | | | | | | | | +------+----+ +-----+----+ +-----+ | | +--------+ | V destination Figure 6: Load Balancing and HA (72 characters?) In both cases, the figure has all the same connection compl= exity (fixed up in a few places), but seems to be less busy. -- Eric --_000_48E1A67CB9CA044EADFEAB87D814BFF632AD07D6eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    HaHa, funny man. = J

     

    From: Jakob He= itz (jheitz) [mailto:jheitz@cisco.com]
    Sent: Thursday, May 29, 2014 1:43 PM
    To: Eric Gray; Joel Halpern; Paul Quinn (paulq)
    Cc: sfc@ietf.org
    Subject: RE: Figures in draft-quinn-sfc-arch-05
    Importance: High

     

    You could turn the whole picture right by = 90 degrees.

    If you don’t like top to bottom inst= ead of left to right, make a note that it’s in landscape.<= /span>

     

    --Jakob

     

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray
    Sent: Thursday, May 29, 2014 8:31 AM
    To: Joel Halpern; Paul Quinn (paulq)
    Cc: sfc@ietf.org
    Subject: [sfc] Figures in draft-quinn-sfc-arch-05    <= /p>

     

    Paul/Joel,

     

            &nbs= p;       Pretty sure that Figures 5 and 6 don= ’t actually fit the width expected for an

    Internet Draft (Figure 5 is more than 80 characters = wide and Figure 6 is wider still).

     

            &nbs= p;       Depending on how a reader tries to r= ead the draft, this can turn complicated

    illustrations into a _real_ fun time.  <= span style=3D"font-family:Wingdings"> J

     

            &nbs= p;       Also, I am unsure what the figures a= re trying to convey with some of “dotted

    lines” crossing the service functions.  I= f the intent is to show that a service function is

    a virtual instance hosted by some network device, pe= rhaps this will be better shown

    in a separate figure and this aspect of Figures 5 an= d 6 can be eliminated?

     

    I would suggest replacing= Figure 5 with a figure along the lines of:

     

    source &nbs= p;           +--= ---+           &= nbsp;       +-----+=

      = ;|            +-= ->| sf2 +--+        &nbs= p;   +-->| sf4 +--+

      = ;|            | = ;  |     |  |     &n= bsp;      |   |     = |  |

      = ;|  +------+--+   +-----+  +--&= gt;+-----+--+   +-----+  +->+= -----+

      = ;|  | sf1  |      +-----+ &= nbsp;    | sf3 |      +-----= 3;     | sf5 |

      = ;+->|      +----->| sf2 +-----&g= t;|     |----->| sf4 +---->|   = ;  |-+

      = ;   |      |    &nbs= p; |     |      | &n= bsp;   |      |     = |     |     | |

      = ;   +------+--+   +-----+ = ; +-->+-----+--+   +-----+  += ->+-----+ |

      = ;            &n= bsp;|   +-----+  |     &nbs= p;      |   +-----+  | &nbs= p;        |

      = ;            &n= bsp;+-->| sf2 +--+       =      +-->| sf4 +--+    &n= bsp;+----+

      = ;            &n= bsp;    |     |   &n= bsp;            &nbs= p;  |     |      &nb= sp; |

      = ;            &n= bsp;    +-----+     &n= bsp;            &nbs= p;+-----+        V

      = ;            &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p;     destination

     =

      = ;            &n= bsp;    Figure 5: Load Balancing

     

    (67 characters?)

     

            &nbs= p;       Similarly, I would suggest replacing= Figure 6 with a figure along the

    lines of:

     

       source
         |       &n=
bsp;       +-----+-+ &n=
bsp;            =
;     +-----+-+
     +---+        &nb=
sp;  +-->| sf2 |-|+      &nbs=
p;       +-->| sf4 |-|+=

     |           &#=
43;---|-->|     | ||     &n=
bsp;    +------>|     | ||
     |   +------+|---+   +-----&#=
43; |+-->+-----+|---+   +-----+ |+=
-->+-----+
     |   | sf1  ||      =
 +-----+ +--->| sf3 ||       &=
#43;-----+ +--->| sf5 |
     +-->|      +|------>| sf2=
 |+---->|     ||------>| sf4 |+---->|&=
nbsp;    |--+
     |   |      || +---->|&=
nbsp;    |-+    |    =
 || +---->|     |-+    | =
;    |  |
     |   +------+|-|-+   +-----&#=
43; |+-->+-----+|-|-+   +-----+ |+=
-->+-----+  |
     |           | =
| |   +-----+ ||       =
;   | | |   +-----+ ||    &=
nbsp;       |
     |   +------++ | +-->| sf2 |-|+&=
nbsp;  +-----++ | +-->| sf4 |-|+   &#=
43;-----+  |
     |   | sf1' |  | +-->|   &nb=
sp; | +--->| sf3'|  | +-->|     | &#=
43;--->| sf5'|  |
     +-->|      +--+ | &=
nbsp; +-----+----->|     |--+ | &nb=
sp; +-----+----->|     |--+
         |      | &=
nbsp;  |          &n=
bsp;     |     |    =
|            &n=
bsp;   |     |  |

         +------+----+  &nb=
sp;            =
 +-----+----+        &n=
bsp;       +-----+  |=

    

               =
;             &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;         |=

    

               =
;            &n=
bsp;            =
;            &n=
bsp;            =
; +--------+
    

               =
;            &n=
bsp;            =
;            &n=
bsp;            =
; |
    

               =
;            &n=
bsp;            &nbs=
p;            &=
nbsp;           &nbs=
p;V
    

               =
;            &n=
bsp;            =
;            &n=
bsp;        destination
    

     
    

               =
;         Figure 6: Load Balancing =
and HA
    

     
    

    (72 characters?)
    

     
    

            &nbs=
p;       In both cases, the figure has all th=
e same connection complexity (fixed up in a few
    

    places), but seems to be less busy.
    

     
    

    --
    

    Eric
    --_000_48E1A67CB9CA044EADFEAB87D814BFF632AD07D6eusaamb107erics_-- From nobody Thu May 29 11:11:59 2014 Return-Path: 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 9510E1A0466 for ; Thu, 29 May 2014 11:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 C9n_Ja7DK_gO for ; Thu, 29 May 2014 11:11:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 749E51A0499 for ; Thu, 29 May 2014 11:11:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHK40587; Thu, 29 May 2014 18:11:45 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 19:11:10 +0100 Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 19:11:44 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml706-chm.china.huawei.com ([169.254.8.4]) with mapi id 14.03.0158.001; Thu, 29 May 2014 11:11:33 -0700 From: Lucy yong To: Eric Gray , "Jakob Heitz (jheitz)" , Joel Halpern , "Paul Quinn (paulq)" Thread-Topic: Figures in draft-quinn-sfc-arch-05 Thread-Index: Ac97S9R6mfocA+1iTpKXBfVlibSBggAGJh5AAACjtcAAAHRWQA== Date: Thu, 29 May 2014 18:11:33 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D45389B2C@dfweml701-chm.china.huawei.com> References: <48E1A67CB9CA044EADFEAB87D814BFF632AD0443@eusaamb107.ericsson.se> <075DE01702BBC249BE1357EFD20DCFE556E2EC@xmb-aln-x02.cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD07D6@eusaamb107.ericsson.se> In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF632AD07D6@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.138.124] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D45389B2Cdfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/NmyNMdlWytaGhZqHxx4N682OGq0 Cc: "sfc@ietf.org" Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 18:11:57 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D45389B2Cdfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For readability on these figures, propose: Figure 5: +-sf2-+ +-sf4-+ | | | | enter -->sf1-->-sf2->--sf3-->-sf4->--sf5--> exit | | | | +-sf2-+ +-sf4-+ Figure 6: +-sf2-+ +-sf4-+ | | | | enter -->{sf1|sf1'}-->-sf2->--{sf3|sf3'}-->-sf4->--{sf5}--> exit | | | | +-sf2-+ +-sf4-+ lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray Sent: Thursday, May 29, 2014 12:54 PM To: Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 HaHa, funny man. :) From: Jakob Heitz (jheitz) [mailto:jheitz@cisco.com] Sent: Thursday, May 29, 2014 1:43 PM To: Eric Gray; Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: RE: Figures in draft-quinn-sfc-arch-05 Importance: High You could turn the whole picture right by 90 degrees. If you don't like top to bottom instead of left to right, make a note that = it's in landscape. --Jakob From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray Sent: Thursday, May 29, 2014 8:31 AM To: Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: [sfc] Figures in draft-quinn-sfc-arch-05 Paul/Joel, Pretty sure that Figures 5 and 6 don't actually fit the wid= th expected for an Internet Draft (Figure 5 is more than 80 characters wide and Figure 6 is wi= der still). Depending on how a reader tries to read the draft, this can= turn complicated illustrations into a _real_ fun time. :) Also, I am unsure what the figures are trying to convey wit= h some of "dotted lines" crossing the service functions. If the intent is to show that a ser= vice function is a virtual instance hosted by some network device, perhaps this will be bett= er shown in a separate figure and this aspect of Figures 5 and 6 can be eliminated? I would suggest replacing Figure 5 with a figure along the lines of: source +-----+ +-----+ | +-->| sf2 +--+ +-->| sf4 +--+ | | | | | | | | | | +------+--+ +-----+ +-->+-----+--+ +-----+ +->+-----+ | | sf1 | +-----+ | sf3 | +-----+ | sf5 | +->| +----->| sf2 +----->| |----->| sf4 +---->| |-+ | | | | | | | | | | | +------+--+ +-----+ +-->+-----+--+ +-----+ +->+-----+ | | +-----+ | | +-----+ | | +-->| sf2 +--+ +-->| sf4 +--+ +----+ | | | | | +-----+ +-----+ V destination Figure 5: Load Balancing (67 characters?) Similarly, I would suggest replacing Figure 6 with a figure= along the lines of: source | +-----+-+ +-----+-+ +---+ +-->| sf2 |-|+ +-->| sf4 |-|+ | +---|-->| | || +------>| | || | +------+|---+ +-----+ |+-->+-----+|---+ +-----+ |+-->+-----+ | | sf1 || +-----+ +--->| sf3 || +-----+ +--->| sf5 | +-->| +|------>| sf2 |+---->| ||------>| sf4 |+---->| |--+ | | || +---->| |-+ | || +---->| |-+ | | | | +------+|-|-+ +-----+ |+-->+-----+|-|-+ +-----+ |+-->+-----+ | | | | | +-----+ || | | | +-----+ || | | +------++ | +-->| sf2 |-|+ +-----++ | +-->| sf4 |-|+ +-----+ | | | sf1' | | +-->| | +--->| sf3'| | +-->| | +--->| sf5'| | +-->| +--+ | +-----+----->| |--+ | +-----+----->| |--+ | | | | | | | | | +------+----+ +-----+----+ +-----+ | | +--------+ | V destination Figure 6: Load Balancing and HA (72 characters?) In both cases, the figure has all the same connection compl= exity (fixed up in a few places), but seems to be less busy. -- Eric --_000_2691CE0099834E4A9C5044EEC662BB9D45389B2Cdfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    For readability on the= se figures, propose:

     

    Figure 5:

         = ;            &n= bsp;   +-sf2-+       +-= sf4-+

         = ;            &n= bsp;   |     |     &= nbsp; |     |

         = ;  enter -->sf1-->-sf2->--sf3-->-sf4->--sf5--> exit<= o:p>

         = ;            &n= bsp;   |     |     &= nbsp; |     |

         = ;            &n= bsp;   +-sf2-+       +-= sf4-+

    Figure 6:

     

         = ;            &n= bsp;       +-sf2-+   &= nbsp;          +-sf4-+=

         = ;            &n= bsp;       |     | &= nbsp;            |&n= bsp;    |

        enter --&g= t;{sf1|sf1'}-->-sf2->--{sf3|sf3'}-->-sf4->--{sf5}--> exit

         = ;            &n= bsp;       |     | &= nbsp;            |&n= bsp;    |

              = ;            &n= bsp;  +-sf2-+        &= nbsp;     +-sf4-+

     

    lucy=

    From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Eric Gray
    Sent: Thursday, May 29, 2014 12:54 PM
    To: Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq)
    Cc: sfc@ietf.org
    Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05

     

    HaHa, funny man. = J

     

    From: Jakob He= itz (jheitz) [mailto:jheitz@cisco.com]
    Sent: Thursday, May 29, 2014 1:43 PM
    To: Eric Gray; Joel Halpern; Paul Quinn (paulq)
    Cc:     sfc@ietf.org
    Subject: RE: Figures in draft-quinn-sfc-arch-05
    Importance: High

     

    You could turn the whole picture right by = 90 degrees.

    If you don’t like top to bottom inst= ead of left to right, make a note that it’s in landscape.<= /span>

     

    --Jakob

     

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray
    Sent: Thursday, May 29, 2014 8:31 AM
    To: Joel Halpern; Paul Quinn (paulq)
    Cc: sfc@ietf.org
    Subject: [sfc] Figures in draft-quinn-sfc-arch-05    <= /p>

     

    Paul/Joel,

     

            &nbs= p;       Pretty sure that Figures 5 and 6 don= ’t actually fit the width expected for an

    Internet Draft (Figure 5 is more than 80 characters = wide and Figure 6 is wider still).

     

            &nbs= p;       Depending on how a reader tries to r= ead the draft, this can turn complicated

    illustrations into a _real_ fun time.  <= span style=3D"font-family:Wingdings"> J

     

            &nbs= p;       Also, I am unsure what the figures a= re trying to convey with some of “dotted

    lines” crossing the service functions.  I= f the intent is to show that a service function is

    a virtual instance hosted by some network device, pe= rhaps this will be better shown

    in a separate figure and this aspect of Figures 5 an= d 6 can be eliminated?

     

    I would suggest replacing= Figure 5 with a figure along the lines of:

     

    source &nbs= p;           +--= ---+           &= nbsp;       +-----+=

      = ;|            +-= ->| sf2 +--+        &nbs= p;   +-->| sf4 +--+

      = ;|            | = ;  |     |  |     &n= bsp;      |   |     = |  |

      = ;|  +------+--+   +-----+  +--&= gt;+-----+--+   +-----+  +->+= -----+

      = ;|  | sf1  |      +-----+ &= nbsp;    | sf3 |      +-----= 3;     | sf5 |

      = ;+->|      +----->| sf2 +-----&g= t;|     |----->| sf4 +---->|   = ;  |-+

      = ;   |      |    &nbs= p; |     |      | &n= bsp;   |      |     = |     |     | |

      = ;   +------+--+   +-----+ = ; +-->+-----+--+   +-----+  += ->+-----+ |

      = ;            &n= bsp;|   +-----+  |     &nbs= p;      |   +-----+  | &nbs= p;        |

      = ;            &n= bsp;+-->| sf2 +--+       =      +-->| sf4 +--+    &n= bsp;+----+

      = ;            &n= bsp;    |     |   &n= bsp;            &nbs= p;  |     |      &nb= sp; |

      = ;            &n= bsp;    +-----+     &n= bsp;            &nbs= p;+-----+        V

      = ;            &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p;     destination

     =

      = ;            &n= bsp;    Figure 5: Load Balancing

     

    (67 characters?)

     

            &nbs= p;       Similarly, I would suggest replacing= Figure 6 with a figure along the

    lines of:

     

       source
         |       &n=
bsp;       +-----+-+ &n=
bsp;            =
;     +-----+-+
     +---+        &nb=
sp;  +-->| sf2 |-|+      &nbs=
p;       +-->| sf4 |-|+=

     |           &#=
43;---|-->|     | ||     &n=
bsp;    +------>|     | ||
     |   +------+|---+   +-----&#=
43; |+-->+-----+|---+   +-----+ |+=
-->+-----+
     |   | sf1  ||      =
 +-----+ +--->| sf3 ||       &=
#43;-----+ +--->| sf5 |
     +-->|      +|------>| sf2=
 |+---->|     ||------>| sf4 |+---->|&=
nbsp;    |--+
     |   |      || +---->|&=
nbsp;    |-+    |    =
 || +---->|     |-+    | =
;    |  |
     |   +------+|-|-+   +-----&#=
43; |+-->+-----+|-|-+   +-----+ |+=
-->+-----+  |
     |           | =
| |   +-----+ ||       =
;   | | |   +-----+ ||    &=
nbsp;       |
     |   +------++ | +-->| sf2 |-|+&=
nbsp;  +-----++ | +-->| sf4 |-|+   &#=
43;-----+  |
     |   | sf1' |  | +-->|   &nb=
sp; | +--->| sf3'|  | +-->|     | &#=
43;--->| sf5'|  |
     +-->|      +--+ | &=
nbsp; +-----+----->|     |--+ | &nb=
sp; +-----+----->|     |--+
         |      | &=
nbsp;  |          &n=
bsp;     |     |    =
|            &n=
bsp;   |     |  |

         +------+----+  &nb=
sp;            =
 +-----+----+        &n=
bsp;       +-----+  |=

    

               =
;             &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;         |=

    

               =
;            &n=
bsp;            =
;            &n=
bsp;            =
; +--------+
    

               =
;            &n=
bsp;            =
;            &n=
bsp;            =
; |
    

               =
;            &n=
bsp;            &nbs=
p;            &=
nbsp;           &nbs=
p;V
    

               =
;            &n=
bsp;            =
;            &n=
bsp;        destination
    

     
    

               =
;         Figure 6: Load Balancing =
and HA
    

     
    

    (72 characters?)
    

     
    

            &nbs=
p;       In both cases, the figure has all th=
e same connection complexity (fixed up in a few
    

    places), but seems to be less busy.
    

     
    

    --
    

    Eric
    --_000_2691CE0099834E4A9C5044EEC662BB9D45389B2Cdfweml701chmchi_-- From nobody Thu May 29 11:25:34 2014 Return-Path: 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 23EDA1A09F4 for ; Thu, 29 May 2014 11:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.552 X-Spam-Level: X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 jkwc38WslF6U for ; Thu, 29 May 2014 11:25:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE63F1A0537 for ; Thu, 29 May 2014 11:25:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHK41190; Thu, 29 May 2014 18:25:23 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 19:24:48 +0100 Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 19:25:22 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml702-chm.china.huawei.com ([169.254.4.56]) with mapi id 14.03.0158.001; Thu, 29 May 2014 11:25:13 -0700 From: Linda Dunbar To: Ron Parker , Lucy yong , Joel Halpern Direct , "Qin Wu" , "Ken Gray (kegray)" Thread-Topic: =?utf-8?B?W3NmY10g562U5aSNOiAgcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2luZyBj?= =?utf-8?Q?onsiderations"_in_the_draft-quinn-sfc-arch-05?= Thread-Index: AQHPe0BRDziN4IeWG0agBGFnpOD0S5tYCoIAgAAHzACAAAQfgIAAArAA///EhFA= Date: Thu, 29 May 2014 18:25:12 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D28EAF@dfweml701-chm.china.huawei.com> References: , <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> <16984558-2B4C-4873-AFC7-DCD2698CA745@cisco.com> <53873333.80807@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D45389906@dfweml701-chm.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D453899C2@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.251] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/LgCG0L4ZzNAiWnXNd8TNxqLfpvg Cc: "Joel M. Halpern" , "Paul Quinn \(paulq\)" , "sfc@ietf.org" Subject: Re: [sfc] =?utf-8?b?562U5aSNOiAgcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2lu?= =?utf-8?q?g_considerations=22_in_the_draft-quinn-sfc-arch-05?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 18:25:32 -0000 SXQgd291bGQgYmUgc28gbXVjaCBlYXNpZXIgdG8gZm9ybWFsbHkgaW50cm9kdWNlIHRoZSBjb25j ZXB0IG9mICJTZXJ2aWNlIEZ1bmN0aW9uIEluc3RhbmNlIiBpbiBTRkMuIEZvciBleGFtcGxlOg0K DQoiU2VydmljZSBGdW5jdGlvbiBJbnN0YW5jZTogT25lIGluc3RhbnRpYXRpb24gb2YgYSBzZXJ2 aWNlIGZ1bmN0aW9uLg0KT25lIHNlcnZpY2UgZnVuY3Rpb24gY291bGQgaGF2ZSBtdWx0aXBsZSBp ZGVudGljYWwgaW5zdGFuY2VzLg0KIA0KRm9yIGEgc2VydmljZSBmdW5jdGlvbiB3aXRoIGRpZmZl cmVudCBmdW5jdGlvbmFsIGluc3RhbnRpYXRpb25zLCBlLmcuIG9uZSBpbnN0YW50aWF0aW9uIGFw cGxpZXMgcG9saWN5LXNldC1BIChOQVQ0NC1BKSBhbmQgb3RoZXIgYXBwbGllcyBwb2xpY3ktc2V0 LUIgKE5BVDQ0LUIpLCB0aGV5IGFyZSBjb25zaWRlcmVkIGFzIHR3byBkaWZmZXJlbnQgc2Vydmlj ZSBmdW5jdGlvbnMuIg0KDQpTb21lIFNlcnZpY2UgRnVuY3Rpb24gSW5zdGFuY2VzIGFyZSB2aXNp YmxlIHRvIFNlcnZpY2UgQ2hhaW4gUGF0aC4gU29tZXRpbWVzIGEgY29sbGVjdGlvbiBvZiBzZXJ2 aWNlIGZ1bmN0aW9uIGluc3RhbmNlcyBjYW4gYXBwZWFyIGFzIG9uZSBzaW5nbGUgZW50aXR5IHRv IHRoZSBTZXJ2aWNlIENoYWluIFBhdGguIg0KDQoNCkxpbmRhIA0KDQoNCiAgIA0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUm9uIFBhcmtlciBbbWFpbHRvOlJvbl9QYXJrZXJA YWZmaXJtZWRuZXR3b3Jrcy5jb21dIA0KU2VudDogVGh1cnNkYXksIE1heSAyOSwgMjAxNCA5OjQ5 IEFNDQpUbzogTHVjeSB5b25nOyBKb2VsIEhhbHBlcm4gRGlyZWN0OyBRaW4gV3U7IEtlbiBHcmF5 IChrZWdyYXkpOyBMaW5kYSBEdW5iYXINCkNjOiBKb2VsIE0uIEhhbHBlcm47IFBhdWwgUXVpbm4g KHBhdWxxKTsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW3NmY10g562U5aSNOiBxdWVzdGlv bnMgb2YgImxvYWQgYmFsYW5jaW5nIGNvbnNpZGVyYXRpb25zIiBpbiB0aGUgZHJhZnQtcXVpbm4t c2ZjLWFyY2gtMDUNCg0KSGksIEx1Y3kuDQoNCkkgYWdyZWUgYWJvdXQgdGhlIHZpZXcgb2YgMSBz ZXJ2aWNlIGZ1bmN0aW9uIHZzLiBtdWx0aXBsZSBzZXJ2aWNlIGZ1bmN0aW9uIGluc3RhbmNlcy4g ICBJbiB0aGUgbGF0dGVyIGNhc2UsIHBlcmhhcHMgd2UgY291bGQgZGVzY3JpYmUgaXQgbm90IGFz ICJzZXJ2aWNlIGZ1bmN0aW9uIGV4cGFuc2lvbiIsIGJ1dCByYXRoZXIgInNlcnZpY2UgZnVuY3Rp b24gaW5zdGFuY2Ugc2VsZWN0aW9uIi4NCg0KICAgUm9uDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgTHVjeSB5b25nDQpTZW50OiBUaHVyc2RheSwgTWF5IDI5LCAyMDE0IDEwOjM5IEFNDQpU bzogUm9uIFBhcmtlcjsgSm9lbCBIYWxwZXJuIERpcmVjdDsgUWluIFd1OyBLZW4gR3JheSAoa2Vn cmF5KTsgTGluZGEgRHVuYmFyDQpDYzogSm9lbCBNLiBIYWxwZXJuOyBQYXVsIFF1aW5uIChwYXVs cSk7IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzZmNdIOetlOWkjTogcXVlc3Rpb25zIG9m ICJsb2FkIGJhbGFuY2luZyBjb25zaWRlcmF0aW9ucyIgaW4gdGhlIGRyYWZ0LXF1aW5uLXNmYy1h cmNoLTA1DQoNCkhpIFJvbiwNCg0KSSBhZ3JlZSB3aXRoIHdoYXQgeW91IHNhaWQuIElmIGEgc2Vy dmljZSBmdW5jdGlvbiBkeW5hbWljIGV4cGFuc2lvbiBpcyBpbXBsZW1lbnRlZCBhcyBjb21wbGV0 ZWx5IGludGVybmFsLCBpLmUuIGxvb2tzIGxpa2Ugb25lIFNGIGNvbXBvbmVudCBpbiBTRkMgbmV0 d29ya3MsIElNTzogU0ZDIGFyY2hpdGVjdHVyZSBkb2VzIG5vdCBuZWVkIHN0ZXAgaW50byB0aGF0 IGFuZCBqdXN0IHRyZWF0IGl0IGFzIG9uZSBTRiBpbnN0YW5jZSBpbiBTRkMgbmV0d29ya3MuIFRo ZXJlIGFyZSBvdGhlciBzY2VuYXJpb3Mgd2hlcmUgaW5kaXZpZHVhbCBTRiBpbnN0YW5jZXMgZXhw b3NlIHRvIHRoZSBTRkMgbmV0d29yaywgU0ZDIGFyY2hpdGVjdHVyZSBuZWVkcyB0byBjb3ZlciB0 aGF0Lg0KDQpUaGFua3MsDQpMdWN5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBSb24gUGFya2VyIFttYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbV0NClNl bnQ6IFRodXJzZGF5LCBNYXkgMjksIDIwMTQgOToyNSBBTQ0KVG86IEx1Y3kgeW9uZzsgSm9lbCBI YWxwZXJuIERpcmVjdDsgUWluIFd1OyBLZW4gR3JheSAoa2VncmF5KTsgTGluZGEgRHVuYmFyDQpD YzogSm9lbCBNLiBIYWxwZXJuOyBQYXVsIFF1aW5uIChwYXVscSk7IHNmY0BpZXRmLm9yZw0KU3Vi amVjdDogUkU6IFtzZmNdIOetlOWkjTogcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2luZyBjb25z aWRlcmF0aW9ucyIgaW4gdGhlIGRyYWZ0LXF1aW5uLXNmYy1hcmNoLTA1DQoNCkx1Y3ksDQoNCldo ZXRoZXIgb3Igbm90IGR5bmFtaWMgZXhwYW5zaW9uIHJlcXVpcmVzIGEgbG9hZCBiYWxhbmNlciBp cyBzcGVjaWZpYyB0byB0aGUgYXJjaGl0ZWN0dXJlIG9mIHRoYXQgc2VydmljZSBmdW5jdGlvbi4g ICBUaGVyZSBhcmUgYXJjaGl0ZWN0dXJlcyB0aGF0IGFyZSBpbnRlcm5hbGx5IGxvYWQgYmFsYW5j ZWQuDQoNCiAgIFJvbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzZmMg W21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEx1Y3kgeW9uZw0KU2Vu dDogVGh1cnNkYXksIE1heSAyOSwgMjAxNCA5OjU3IEFNDQpUbzogSm9lbCBIYWxwZXJuIERpcmVj dDsgUWluIFd1OyBLZW4gR3JheSAoa2VncmF5KTsgTGluZGEgRHVuYmFyDQpDYzogSm9lbCBNLiBI YWxwZXJuOyBQYXVsIFF1aW5uIChwYXVscSk7IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtz ZmNdIOetlOWkjTogcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2luZyBjb25zaWRlcmF0aW9ucyIg aW4gdGhlIGRyYWZ0LXF1aW5uLXNmYy1hcmNoLTA1DQoNCkhpIEpvZWwsDQoNCkEgbG9hZCBiYWxh bmNlciBpcyBuZWVkZWQgdG8gc3VwcG9ydCBlbGFzdGljIGV4cGFuc2lvbiBvZiBhIHNlcnZpY2Ug ZnVuY3Rpb24gYWx0aG91Z2ggYSBMQiBjYW4gYmUgdHJhbnNwYXJlbnRseSB0byBhIFNGQy4gDQoN Ckl0IGlzIGdvb2QgdG8gbWVudGlvbiB0aGlzIGluIHNlY3Rpb24gNi4NCg0KTHVjeSAgIA0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2VsIEhhbHBlcm4gRGlyZWN0DQpTZW50OiBUaHVyc2Rh eSwgTWF5IDI5LCAyMDE0IDg6MTcgQU0NClRvOiBRaW4gV3U7IEtlbiBHcmF5IChrZWdyYXkpOyBM aW5kYSBEdW5iYXINCkNjOiBKb2VsIE0uIEhhbHBlcm47IFBhdWwgUXVpbm4gKHBhdWxxKTsgc2Zj QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NmY10g562U5aSNOiBxdWVzdGlvbnMgb2YgImxvYWQg YmFsYW5jaW5nIGNvbnNpZGVyYXRpb25zIiBpbiB0aGUgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDUN Cg0KSSBhbSBub3QgZm9sbG93aW5nIHlvdXIgcXVlc3Rpb24uDQpTRkYgY2FuIGhhdmUgYSBjby1s b2NhdGVkIGxvYWQgYmFsYW5jZXIuICBPciB0aGUgbG9hZCBiYWxhbmNlciBjYW4gYmUgdHJhbnNw YXJlbnRseSBiZWhpbmQgdGhlIFNGRiwgdXNpbmcgYW55IG51bWJlciBvZiBtZWNoYW5pc21zLg0K V2UgYXJlIG5vdCBtYW5kYXRpbmcgd2hlcmUgaXQgaXMgbG9jYXRlZC4NCg0KWW91cnMsDQpKb2Vs DQoNCk9uIDUvMjgvMTQsIDExOjU1IFBNLCBRaW4gV3Ugd3JvdGU6DQo+IFlvdSBhcmUgdGFsa2lu ZyBhYm91dCBzZXJ2aWNlIGZ1bmN0aW9uIHNjYWxlIHVwIGFuZCBkb3duLg0KPg0KPiBTaW5jZSBz ZXJ2aWNlIG5vZGUgY2FuIGhvc3Qgb25lIG9yIG11bHRpcGxlIHNlcnZpY2UgZnVuY3Rpb25zLCB3 aHkgDQo+IHNlcnZpY2Ugbm9kZSBjYW4gbm90IGJlIHVzZWQgdG8gY29udHJvbCBzY2FsZSB1cCBv ciBkb3duIG9mIHNlcnZpY2UgDQo+IGZ1bmN0aW9ucyBpdD8NCj4NCj4gVG8gYXZvaWQgc2hhcmUg cmlzayBmYWlsdXJlLCBzZXJ2aWNlIG5vZGUgY2FuIGJlIHByZXZpb3VzIHNlcnZpY2UgDQo+IG5v ZGUsIGUuZy4sIGl0IGNhbiBiZSB0aGUgb25lIHRoYXQgaG9zdHMgc2YxIG9yIHNmMy4NCj4NCj4g QWxzbyBTRkYgaXMgcmVzcG9uc2libGUgZm9yIGRlbGl2ZXJpbmcgdHJhZmZpYyB0byBhbnkgY29u bmVjdGVkIA0KPiBzZXJ2aWNlIGZ1bmN0aW9ucywgd2h5IG5vdCBTRkYgY2FuIG5vdCBiZSB1c2Vk IHRvIG1hbmFnZSBzY2FsZSB1cCBvciANCj4gZG93biBvZiBzZXJ2aWNlIGZ1bmN0aW9uLg0KPg0K PiBBbHNvIGJhc2VkIG9uIE5GViBNQU5PIGFyY2hpdGVjdHVyZSwgdGhlcmUgaXMgcmVmZXJlbmNl IHBvaW50IGJldHdlZW4gDQo+IE5GViBhbmQgTkZWIG1hbmFnZXIsIE5GViBtYW5hZ2VyIGFsc28g Y2FuIGNvbnRyb2wgc2NhbGUgdXAgb3IgZG93biBvZiANCj4gc2VydmljZSBmdW5jdGlvbiwgSSB0 aGluayB0aGlzIGNhc2UgaGFzIGJlZW4gY292ZXJlZCBieSDigJx0aHJvdWdoIA0KPiBleHRlcm5h bCBjb250cm9s4oCdIGluIHRoZSBkcmFmdC4NCj4NCj4gVXNpbmcgc2YxIHRoYXQgcHJvdmlkZSBk ZWRpY2F0ZWQgZmlyZXdhbGwgc2VydmljZSB0byBwcm92aWRlIGxvYWQgDQo+IGJhbGFuY2luZyBm dW5jdGlvbmFsaXR5IGFzIHdlbGwgaXMgYSBsaXR0bGUgYml0IHdlaXJkIHRvIG1lLg0KPg0KPiBM ZXQgbWUga25vdyBpZiBteSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3Q/DQo+DQo+IFJlZ2FyZHMh DQo+DQo+IC1RaW4NCj4NCj4gKuWPkeS7tuS6ujoqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0 Zi5vcmddICrku6PooaggKktlbiBHcmF5IChrZWdyYXkpDQo+ICrlj5HpgIHml7bpl7Q6KjIwMTTl ubQ15pyIMjnml6U4OjQ5DQo+ICrmlLbku7bkuro6KkxpbmRhIER1bmJhcg0KPiAq5oqE6YCBOipK b2VsIE0uIEhhbHBlcm47IFBhdWwgUXVpbm4gKHBhdWxxKTsgc2ZjQGlldGYub3JnDQo+ICrkuLvp opg6KlJlOiBbc2ZjXSBxdWVzdGlvbnMgb2YgImxvYWQgYmFsYW5jaW5nIGNvbnNpZGVyYXRpb25z IiBpbiB0aGUNCj4gZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDUNCj4NCj4gSSBkb24ndCBzZWUgaG93 IHlvdSBtYWtlIHRoZSBsZWFwIGZyb20gdGhlIGV4cGxhbmF0aW9uIG9mIHdoeSBpdCB3YXMgDQo+ IGlycmVsZXZhbnQgdG8gZ28gaW50byBtb3JlIGRldGFpbCBpbiB0aGUgc2VjdGlvbiB0byB0aGUg ZWxpbWluYXRpb24gb2YgDQo+IHRoZSB2ZXJ5IGdlbmVyYWxpemVkIGRlc2NyaXB0aW9uIGFjY29t cGFueWluZyB0aGUgZmlndXJlLiAgUGxlYXNlIHVzZSANCj4geW91ciBvd24gYXJndW1lbnQgdG8g anVzdGlmeSB0aGlzIGFuZCBub3QgaW5mZXIgYW55IGV4dHJhIG1lYW5pbmcgZnJvbSANCj4gbXkg YW5zd2VyIHRvIGEgZGlmZmVyZW50IHF1ZXN0aW9uLg0KPg0KPiBBcyB0byB0aGUgc2Vjb25kIGNo YW5nZSwgaSBkaXNhZ3JlZS4gIEFnYWluLCBpbiBnZW5lcmFsL2Jyb2FkIHN0cm9rZXMNCj4gLSBm cm9tIHRoZSBkcmF3aW5nIGFuZCB0aGUgdGV4dCwgaXQgaXMgdW5saWtlbHkgdGhhdCBhbnkgc3Bl Y2lhbCANCj4gYWN0aW9uIHdvdWxkIGJlIHJlcXVpcmVkIG9uIHNmMiBvciBzZjQgLSBhcyB0aGV5 IGNvbGxhcHNlIGluIGVpdGhlciANCj4gZGlyZWN0aW9uIHRvIGEgc2luZ2xlIGxvZ2ljYWwgbmV4 dCBob3AuDQo+DQo+IFNlbnQgZnJvbSBteSBpUGhvbmUNCj4NCj4NCj4gT24gTWF5IDI4LCAyMDE0 LCBhdCA1OjQ5IFBNLCAiTGluZGEgRHVuYmFyIiA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20gDQo+ IDxtYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+PiB3cm90ZToNCj4NCj4gICAgIEpvZWws IEVyaWMsIGFuZCBLZW4sDQo+DQo+ICAgICBUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB0aGUgZXhw bGFuYXRpb24uDQo+DQo+ICAgICBCYXNlZCBvbiB3aGF0IHlvdSBzYWlkLCB0aGUgZGVzY3JpcHRp b24gb24gaG93IOKAnGNvbnRyb2wgZW50aXR5ICBwdXNoDQo+ICAgICB0byB0aGUgc2YxIG5vZGVz IOKApuKAnSBzaG91bGQgYmUgcmVtb3ZlZCBmcm9tIHRoZSB0ZXh0LCBzcGVjaWZpY2FsbHk6DQo+ DQo+ICAgICDigJxJbiB0aGlzDQo+DQo+ICAgICAgICAgY2FzZSwgdGhlIGNvbnRyb2wgZW50aXR5 IHdpbGwgcHVzaCB0byB0aGUgc2YxIG5vZGVzLCBhIHRhYmxlIA0KPiBvZg0KPg0KPiAgICAgICAg IHNvcnRzOltMMV0gPCNfbXNvY29tXzE+IHNmMiB3aXRoIGEgc2VyaWVzIG9mIG5leHQgaG9wcywg YW5kIGlmDQo+ICAgICBuZWVkZWQgc29tZSB3ZWlnaHRlZCBvcg0KPg0KPiAgICAgICAgIG90aGVy IG1ldHJpY3MgKHRoZXNlIGNvdWxkIGFsc28gYmUgZGVjaWRlZCBsb2NhbGx5IGJ5IHNvbWUgDQo+ IHBvbGljeSwNCj4NCj4gICAgICAgICBidXQgc2YxIHdvdWxkIG5lZWQgdG8gYmUgYXdhcmUgb2Yg ZXhwYW5kL2NvbnRyYWN0IHRyaWdnZXJzIGFuZA0KPg0KPiAgICAgICAgIGFjdGlvbnMpLuKAnQ0K Pg0KPiAgICAgU2hvdWxkIGFsc28gY2hhbmdlIHRoZSBzZW50ZW5jZSBhZnRlciB0aGUgRmlndXJl IDUgdG8NCj4NCj4gICAgIOKAnEVpdGhlciB0aHJvdWdoIGFuIGltYmVkZGVkIGFjdGlvbiBpbiBz ZjEgYW5kIHNmMywgdGhlIFNGRiBub2RlcyB0bw0KPiAgICAgd2hpY2ggdGhlIG11bHRpcGxlIGlu c3RhbmNlcyBvZiBTRjIgb3IgU0Y0IGFyZSBhdHRhY2hlZCwgb3IgdGhyb3VnaA0KPiAgICAgZXh0 ZXJuYWwNCj4NCj4gICAgICAgICBjb250cm9sLCB0aGUgc2VydmljZSBmdW5jdGlvbnMgc2YyIGFu ZCBzZjQgYXJlIGVsYXN0aWNhbGx5IA0KPiBleHBhbmRlZA0KPg0KPiAgICAgICAgIGFuZCBjb250 cmFjdGVkIGR5bmFtaWNhbGx5LuKAnQ0KPg0KPiAgICAgTGluZGENCj4NCj4gICAgICpGcm9tOipL ZW4gR3JheSAoa2VncmF5KSBbbWFpbHRvOmtlZ3JheUBjaXNjby5jb21dDQo+ICAgICAqU2VudDoq IFdlZG5lc2RheSwgTWF5IDI4LCAyMDE0IDQ6MjQgUE0NCj4gICAgICpUbzoqIExpbmRhIER1bmJh cjsgUGF1bCBRdWlubiAocGF1bHEpOyBKb2VsIE0uIEhhbHBlcm4NCj4gICAgICpDYzoqIHNmY0Bp ZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gICAgICpTdWJqZWN0OiogUmU6IFtzZmNd IHF1ZXN0aW9ucyBvZiAibG9hZCBiYWxhbmNpbmcgY29uc2lkZXJhdGlvbnMiIGluDQo+ICAgICB0 aGUgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDUNCj4NCj4gICAgICsxIHRvIEpvZWwg4oCmIHRoZSBw aWN0dXJlIHdvdWxkIGJlIHVnbHkgYXQgYmVzdC4gIFdlIGF0dGVtcHRlZCBhDQo+ICAgICBnZW5l cmljIEhBL0xCIHNsaWRlIHRvIG1ha2UgYSBwb2ludCBhbmQgZXZlbiBpdCB3YXMgdWdseSDigKZz dWNoIGFyZQ0KPiAgICAgdGhlIGxpbWl0YXRpb25zIG9mIEFTQ0lJIGFydC4NCj4NCj4gICAgIElu IGxpbmUg4oCmDQo+DQo+ICAgICAqRnJvbTogKkxpbmRhIER1bmJhciA8bGluZGEuZHVuYmFyQGh1 YXdlaS5jb20NCj4gICAgIDxtYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+Pg0KPiAgICAg KkRhdGU6ICpXZWRuZXNkYXksIE1heSAyOCwgMjAxNCAzOjM0IFBNDQo+ICAgICAqVG86ICoiUGF1 bCBRdWlubiAocGF1bHEpIiA8cGF1bHFAY2lzY28uY29tDQo+ICAgICA8bWFpbHRvOnBhdWxxQGNp c2NvLmNvbT4+LCAiSm9lbCBNLiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbQ0KPiAgICAg PG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4NCj4gICAgICpDYzogKiJzZmNAaWV0Zi5vcmcg PG1haWx0bzpzZmNAaWV0Zi5vcmc+IiA8c2ZjQGlldGYub3JnDQo+ICAgICA8bWFpbHRvOnNmY0Bp ZXRmLm9yZz4+DQo+ICAgICAqU3ViamVjdDogKltzZmNdIHF1ZXN0aW9ucyBvZiAibG9hZCBiYWxh bmNpbmcgY29uc2lkZXJhdGlvbnMiIGluIHRoZQ0KPiAgICAgZHJhZnQtcXVpbm4tc2ZjLWFyY2gt MDUNCj4NCj4gICAgIFBhdWwgYW5kIEpvZWwsDQo+DQo+ICAgICBEb2VzIHRoZSBMb2FkIEJhbGFu Y2luZyBGaWd1cmUgNSAob2YgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDUpIGFzc3VtZQ0KPiAgICAg dGhhdCBTRjEgaXMgcmVzcG9uc2libGUgZm9yIGJhbGFuY2luZyB0cmFmZmljIGFtb25nIHRoZSAz IGluc3RhbmNlcw0KPiAgICAgb2YgU0YyLCBhbmQgU0YzIGlzIHJlc3BvbnNpYmxlIGZvciBiYWxh bmNpbmcgdHJhZmZpYyBhbW9uZyB0aGUgMw0KPiAgICAgaW5zdGFuY2VzIG9mIFNGND8NCj4NCj4g ICAgIDxrZWc+IERvY3VtZW50IHRleHQgYmVsb3cgdGhlIHBpY3R1cmUgc2F5cyAiRWl0aGVyIHRo cm91Z2ggYW4NCj4gICAgIGltYmVkZGVkIGFjdGlvbiBpbiBzZjEgYW5kIHNmMywgb3IgdGhyb3Vn aCBleHRlcm5hbA0KPg0KPiAgICAgY29udHJvbCwgdGhlIHNlcnZpY2UgZnVuY3Rpb25zIHNmMiBh bmQgc2Y0IGFyZSBlbGFzdGljYWxseQ0KPiAgICAgZXhwYW5kZWQgYW5kIGNvbnRyYWN0ZWQgZHlu YW1pY2FsbHkuIg0KPg0KPiAgICAgSXNu4oCZdCBpdCBhIHNpbmdsZSBwb2ludCBvZiBmYWlsdXJl Pw0KPg0KPiAgICAgPGtlZz4gRG9jdW1lbnQgdGV4dCBpbW1lZGlhdGVseSBzdWJzZXF1ZW50IHRv IHRoYXQgcGljdHVyZSBhbmQNCj4gICAgIHBhcmFncmFwaCBpbGx1c3RyYXRlcyBIQSBzY2VuYXJp b3MuDQo+DQo+ICAgICBTb21lIHNlcnZpY2UgZnVuY3Rpb25zIGFyZSBTdGF0ZWZ1bCwgaS5lLiB0 aGV5IG1heSByZXF1aXJlIHBhY2tldHMNCj4gICAgIGZyb20gc2FtZSBmbG93cyB0byB0cmF2ZXJz ZSB0aGUgc2FtZSBzZXJ2aWNlIGZ1bmN0aW9uIGluc3RhbmNlLiBGb3INCj4gICAgIHRoZSBMb2Fk IEJhbGFuY2luZyBzY2hlbWUgZGVzY3JpYmVkIGJ5IEZpZ3VyZSA1LCBkbyB5b3UgYXNzdW1lIHRo YXQNCj4gICAgIFNGMSBhbmQgU0YzIHdpbGwgYmUgcmVzcG9uc2libGUgZm9yIG1ha2luZyBzdXJl IHRoYXQgc2FtZSBmbG93cyBnbw0KPiAgICAgdGhyb3VnaCB0aGUgc2FtZSBzZXJ2aWNlIGZ1bmN0 aW9uIGluc3RhbmNlPw0KPg0KPiAgICAgPGtlZz4gQWdhaW4sIHRoZSBhZm9yZW1lbnRpb25lZCB0 ZXh0IGRlbGliZXJhdGVseSBhbGxvd3MgdGhpcw0KPiAgICAgcmVzcG9uc2liaWxpdHkgdG8gYmUg ZWl0aGVyIGltYmVkZGVkIGluIHRoZSBlbGFzdGljaXR5LWNhdXNpbmcNCj4gICAgIGZ1bmN0aW9u IG9yIHRvIGJlIGNvbnRyb2xsZWQgZXh0ZXJuYWxseSBvciBjZW50cmFsbHkuICBXZSBkb24ndCBn ZXQNCj4gICAgIGludG8gdGhlIG1lY2hhbmljcyBhcyB0aGVzZSBjYW4gdmFyeS4gIFdoaWxlIHN0 YXRlZnVsL2JpZGlyZWN0aW9uYWwNCj4gICAgIGRvZXMgYWRkIGFuIGFkZGl0aW9uYWwgYnVyZGVu LCBpdCBjYW4gYmUgYWNjb21tb2RhdGVkIHdpdGhvdXQgYW4NCj4gICAgIGV4cGxvc2lvbiBvZiBk aXNjcmV0ZSBjaGFpbnMuICBGb3IgZXhhbXBsZSwgaXQgY291bGQgYmUgaGFuZGxlZCAiYXQNCj4g ICAgIGFsbG9jYXRpb24gdGltZSIgaWYgZWxhc3RpY2l0eSBpcyBtYW5hZ2VkIHZpYSBhIHNlcGFy YXRlIGVudGl0eSBhbmQNCj4gICAgIHRoZSBpbmRpdmlkdWFsIGFsbG9jYXRpb25zIHJlZmxlY3Rl ZCB0aHJvdWdoIHNlcnZpY2UgY2hhaW4gY29udHJvbA0KPiAgICAgaW4gdGhlIGluaXRpYWwgbWV0 YWRhdGEgYm91bmQgdG8gYXQgdGhlIGNsYXNzaWZpY2F0aW9uIHBvaW50IGluDQo+ICAgICBlaXRo ZXIgZGlyZWN0aW9uLiAgT1IsIGlmIHRoZSBkZXZpY2VzIGFyZSB3b3JraW5nIGFzIGEgcGFpcmVk IHN5c3RlbQ0KPiAgICAgKHNpbmdsZSB2ZW5kb3Igb3IgZWNvc3lzdGVtKSB3aXRoIGludGVncmF0 ZWQgZWxhc3RpY2l0eSwgdGhleSBjb3VsZA0KPiAgICAgcGFzcyBtZXRhZGF0YSBiZXR3ZWVuIHRo ZW0gd2hlbiBzZjEgb3Igc2YzIGRvZXMgdGhlIGluaXRpYWwgZHluYW1pYw0KPiAgICAgYWxsb2Nh dGlvbiAoYWZmZWN0aW5nIGxvY2FsIGZvcndhcmRpbmcgb24gaXQncyBwYXJ0bmVyKS4gIFRoYXQn cw0KPiAgICAgcHJvYmFibHkgbm90IGFuIGV4aGF1c3RpdmUgbGlzdCBvZiB3YXlzIHRvIHNvbHZl IHRoZSBwcm9ibGVtLiAgOF4pDQo+DQo+ICAgICA8a2VnPiBUaGUgcG9pbnQgb2YgdGhpcyBzZWN0 aW9uIHdhcyB0aGF0IGVsYXN0aWNpdHkgYW5kIEhBIHNob3VsZA0KPiAgICAgbm90IGNhdXNlIGFu IGlub3JkaW5hdGUgZXhwbG9zaW9uIG9mIGRpc2NyZXRlIGNoYWlucyB3aXRob3V0DQo+ICAgICBy ZWNvbW1lbmRpbmcgYSBwYXJ0aWN1bGFyIHNvbHV0aW9uLiAgVGhhdCBpcywgIHlvdSBzaG91bGRu J3QgY3JlYXRlDQo+ICAgICB1bm5lY2Vzc2FyeSAgY29tcGxleGl0eSB3aGVyZSBpdCBkb2Vzbid0 IG5lZWQgdG8gZXhpc3QuDQo+DQo+ICAgICBGb3IgdGhlIHN0YXRlZnVsIHNlcnZpY2UgZnVuY3Rp b25zLCBpZiBhIGZsb3cgaXMgc3dpdGNoZWQgZnJvbQ0KPiAgICAgU0YtSW5zdGFuY2UtWCB0byBT Ri1JbnN0YW5jZS1ZLCB0aGUgU0YtSW5zdGFuY2UtWSBuZWVkcyB0bw0KPiAgICAgc3luY2hyb25p emUgdGhlIHN0YXRlcyBmcm9tIFNGLUluc3RhbmNlLVguIFdobyBpcyByZXNwb25zaWJsZSBmb3IN Cj4gICAgIHRob3NlIHN0YXRlcyBtYWludGVuYW5jZSBmb3IgdGhlIExvYWQgQmFsYW5jaW5nIGRl c2NyaWJlZCBpbiBGaWd1cmUgNT8NCj4NCj4gICAgIDxrZWc+IE5vbmUgb2YgdGhvc2UgZW50aXRp ZXMgZXhpc3QgaW4gRmlndXJlIDUuICBDYW4geW91IHJlLXBocmFzZQ0KPiAgICAgeW91ciBxdWVz dGlvbiBmcm9tIHRoZSBmaWd1cmU/DQo+DQo+ICAgICBMaW5kYQ0KPg0KPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+IC0tDQo+DQo+IFJlcXVpcmUgcHVzaGluZyBwb2xpY2llcyB0byBTRjEgb24gaG93IHRvIGxv YWQgYmFsYW5jZSBtdWx0aXBsZSANCj4gaW5zdGFuY2VzIG9mIFNGMi4NCj4NCj4gU0YxIG1heSBu b3QgaGF2ZSB0aGUgY2FwYWJpbGl0eSB0byBiYWxhbmNlIGFtb25nIG11bHRpcGxlIGluc3RhbmNl cyBvZg0KPiBTRjINCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNm Y0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGlu ZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K c2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYw0K From nobody Thu May 29 12:48:30 2014 Return-Path: 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 D91251A063F for ; Thu, 29 May 2014 12:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 oPysuS2o4y5A for ; Thu, 29 May 2014 12:48:27 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1716D1A063B for ; Thu, 29 May 2014 12:48:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 3D458660520; Thu, 29 May 2014 12:48:23 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (aptilo2-usaa.ericsson.net [129.192.185.163]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 47C4E1C077E; Thu, 29 May 2014 12:48:22 -0700 (PDT) Message-ID: <53878F04.40909@joelhalpern.com> Date: Thu, 29 May 2014 15:48:20 -0400 From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Sharon , Linda Dunbar References: <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/rvdiQWSoAPDRZI6Tk1uUHIYO-Lw Cc: "Joel M. Halpern" , "Paul Quinn \(paulq\)" , "Ken Gray \(kegray\)" , "sfc@ietf.org" Subject: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 19:48:29 -0000 I am not at all sure I am following your diagram. An SFF is concerned with forwarding packets to (and handling packets from) its attached SFs. If you want the SFF to also affect downstream processing, for example by changing the service path the packet is on, then you need a classifier co-located with the SFF. Yours, Joel On 5/29/14, 12:09 PM, Sharon wrote: > "the SFF nodes to which the multiple instances of SF2 or SF4 are attached" > > Can't the SFF node make a load balancing decision on instances not > attached to it? > In which case "the SFF node" is enough > > Location A Location B > Functions - SFF/NVE - Underlay - NVE/SFF - Functions > > The load balancing KPI decisions (and the invariant that keeps states > consistent) > May be known in Location A for SFs in location B where A/B are different > racks or goes. > KPIs that are factored in can include both those of the Underlay network > and the chain. > > --szb > > On May 28, 2014, at 14:49, Linda Dunbar > wrote: > >> Joel, Eric, and Ken, >> >> Thank you very much for the explanation. >> >> Based on what you said, the description on how “control entity push >> to the sf1 nodes …†should be removed from the text, specifically: >> >> “In this >> >> case, the control entity will push to the sf1 nodes, a table of >> >> sorts:[L1] <#_msocom_1> sf2 with a series of next hops, and if >> needed some weighted or >> >> other metrics (these could also be decided locally by some policy, >> >> but sf1 would need to be aware of expand/contract triggers and >> >> actions).†>> >> Should also change the sentence after the Figure 5 to >> >> “Either through an imbedded action in sf1 and sf3, the SFF nodes to >> which the multiple instances of SF2 or SF4 are attached, or through >> external >> >> control, the service functions sf2 and sf4 are elastically expanded >> >> and contracted dynamically.†>> >> Linda >> >> *From:*Ken Gray (kegray) [mailto:kegray@cisco.com] >> *Sent:* Wednesday, May 28, 2014 4:24 PM >> *To:* Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern >> *Cc:* sfc@ietf.org >> *Subject:* Re: [sfc] questions of "load balancing considerations" in >> the draft-quinn-sfc-arch-05 >> >> +1 to Joel … the picture would be ugly at best. We attempted a >> generic HA/LB slide to make a point and even it was ugly …such are the >> limitations of ASCII art. >> >> In line … >> >> *From: *Linda Dunbar > > >> *Date: *Wednesday, May 28, 2014 3:34 PM >> *To: *"Paul Quinn (paulq)" >, >> "Joel M. Halpern" > >> *Cc: *"sfc@ietf.org " > > >> *Subject: *[sfc] questions of "load balancing considerations" in the >> draft-quinn-sfc-arch-05 >> >> Paul and Joel, >> >> Does the Load Balancing Figure 5 (of draft-quinn-sfc-arch-05) assume >> that SF1 is responsible for balancing traffic among the 3 instances of >> SF2, and SF3 is responsible for balancing traffic among the 3 >> instances of SF4? >> >> Document text below the picture says "Either through an imbedded >> action in sf1 and sf3, or through external >> >> control, the service functions sf2 and sf4 are elastically >> expanded and contracted dynamically." >> >> Isn’t it a single point of failure? >> >> Document text immediately subsequent to that picture and >> paragraph illustrates HA scenarios. >> >> Some service functions are Stateful, i.e. they may require packets >> from same flows to traverse the same service function instance. For >> the Load Balancing scheme described by Figure 5, do you assume that >> SF1 and SF3 will be responsible for making sure that same flows go >> through the same service function instance? >> >> Again, the aforementioned text deliberately allows this >> responsibility to be either imbedded in the elasticity-causing >> function or to be controlled externally or centrally. We don't get >> into the mechanics as these can vary. While stateful/bidirectional >> does add an additional burden, it can be accommodated without an >> explosion of discrete chains. For example, it could be handled "at >> allocation time" if elasticity is managed via a separate entity and >> the individual allocations reflected through service chain control in >> the initial metadata bound to at the classification point in either >> direction. OR, if the devices are working as a paired system (single >> vendor or ecosystem) with integrated elasticity, they could pass >> metadata between them when sf1 or sf3 does the initial dynamic >> allocation (affecting local forwarding on it's partner). That's >> probably not an exhaustive list of ways to solve the problem. 8^) >> >> The point of this section was that elasticity and HA should not >> cause an inordinate explosion of discrete chains without recommending >> a particular solution. That is, you shouldn't create unnecessary >> complexity where it doesn't need to exist. >> >> For the stateful service functions, if a flow is switched from >> SF-Instance-X to SF-Instance-Y, the SF-Instance-Y needs to synchronize >> the states from SF-Instance-X. Who is responsible for those states >> maintenance for the Load Balancing described in Figure 5? >> >> None of those entities exist in Figure 5. Can you re-phrase >> your question from the figure? >> >> Linda >> >> ------------------------------------------------------------------------ >> >> [L1] <#_msoanchor_1>Require pushing policies to SF1 on how to load >> balance multiple instances of SF2. >> >> SF1 may not have the capability to balance among multiple instances of >> SF2 >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc From nobody Thu May 29 12:57:54 2014 Return-Path: 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 269B11A6EEF for ; Thu, 29 May 2014 12:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 8Z51uB3WYCuo for ; Thu, 29 May 2014 12:57:48 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97E5D1A6EED for ; Thu, 29 May 2014 12:57:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id D49672405A5; Thu, 29 May 2014 12:57:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (aptilo2-usaa.ericsson.net [129.192.185.163]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id E75D7240440; Thu, 29 May 2014 12:57:43 -0700 (PDT) Message-ID: <53879137.7010900@joelhalpern.com> Date: Thu, 29 May 2014 15:57:43 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Linda Dunbar , Ron Parker , Lucy yong , Qin Wu , "Ken Gray (kegray)" References: , <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> <16984558-2B4C-4873-AFC7-DCD2698CA745@cisco.com> <53873333.80807@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D45389906@dfweml701-chm.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D453899C2@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645D28EAF@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D28EAF@dfweml701-chm.china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/JJNbU0eZ_RPWHAIozuySMWLuej8 Cc: "Paul Quinn \(paulq\)" , "sfc@ietf.org" Subject: Re: [sfc] =?utf-8?b?562U5aSNOiAgcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2lu?= =?utf-8?q?g_considerations=22_in_the_draft-quinn-sfc-arch-05?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 19:57:50 -0000 the problem I have with the definition you propose for Service Function Instance is that what is an instance will depend upon where you look. What management, and particularly what virtual machine monitoring and management, sees as an instance has to be a single image running on a single VM. But what Service Chaining sees as an instance may be one such thing, or may be a cluster of such things organized in such a way as to present a single view to the service chaining infrastructure. Thus, trying to define Service Function Instance, and then talk explicitly about such instances in service chaining, gets very difficult. We are likely to end up with a definition that says that a service function instance may be made up of multiple software instances. Such a definition seems likely to cause more confusion than it solves. If we can come up with a definition that allows for the range of deployments, and does not itself further confuse the readers, then I am happy to add such a term definition and usage in the document. Yours, Joel On 5/29/14, 2:25 PM, Linda Dunbar wrote: > It would be so much easier to formally introduce the concept of > "Service Function Instance" in SFC. For example: > > "Service Function Instance: One instantiation of a service function. > One service function could have multiple identical instances. > > For a service function with different functional instantiations, e.g. > one instantiation applies policy-set-A (NAT44-A) and other applies > policy-set-B (NAT44-B), they are considered as two different service > functions." > > Some Service Function Instances are visible to Service Chain Path. > Sometimes a collection of service function instances can appear as > one single entity to the Service Chain Path." > > > Linda > > > > > -----Original Message----- From: Ron Parker > [mailto:Ron_Parker@affirmednetworks.com] Sent: Thursday, May 29, 2014 > 9:49 AM To: Lucy yong; Joel Halpern Direct; Qin Wu; Ken Gray > (kegray); Linda Dunbar Cc: Joel M. Halpern; Paul Quinn (paulq); > sfc@ietf.org Subject: RE: [sfc] ç­”å¤: questions of "load balancing > considerations" in the draft-quinn-sfc-arch-05 > > Hi, Lucy. > > I agree about the view of 1 service function vs. multiple service > function instances. In the latter case, perhaps we could describe > it not as "service function expansion", but rather "service function > instance selection". > > Ron > > > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On > Behalf Of Lucy yong Sent: Thursday, May 29, 2014 10:39 AM To: Ron > Parker; Joel Halpern Direct; Qin Wu; Ken Gray (kegray); Linda Dunbar > Cc: Joel M. Halpern; Paul Quinn (paulq); sfc@ietf.org Subject: Re: > [sfc] ç­”å¤: questions of "load balancing considerations" in the > draft-quinn-sfc-arch-05 > > Hi Ron, > > I agree with what you said. If a service function dynamic expansion > is implemented as completely internal, i.e. looks like one SF > component in SFC networks, IMO: SFC architecture does not need step > into that and just treat it as one SF instance in SFC networks. There > are other scenarios where individual SF instances expose to the SFC > network, SFC architecture needs to cover that. > > Thanks, Lucy > > -----Original Message----- From: Ron Parker > [mailto:Ron_Parker@affirmednetworks.com] Sent: Thursday, May 29, 2014 > 9:25 AM To: Lucy yong; Joel Halpern Direct; Qin Wu; Ken Gray > (kegray); Linda Dunbar Cc: Joel M. Halpern; Paul Quinn (paulq); > sfc@ietf.org Subject: RE: [sfc] ç­”å¤: questions of "load balancing > considerations" in the draft-quinn-sfc-arch-05 > > Lucy, > > Whether or not dynamic expansion requires a load balancer is specific > to the architecture of that service function. There are > architectures that are internally load balanced. > > Ron > > > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On > Behalf Of Lucy yong Sent: Thursday, May 29, 2014 9:57 AM To: Joel > Halpern Direct; Qin Wu; Ken Gray (kegray); Linda Dunbar Cc: Joel M. > Halpern; Paul Quinn (paulq); sfc@ietf.org Subject: Re: [sfc] ç­”å¤: > questions of "load balancing considerations" in the > draft-quinn-sfc-arch-05 > > Hi Joel, > > A load balancer is needed to support elastic expansion of a service > function although a LB can be transparently to a SFC. > > It is good to mention this in section 6. > > Lucy > > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On > Behalf Of Joel Halpern Direct Sent: Thursday, May 29, 2014 8:17 AM > To: Qin Wu; Ken Gray (kegray); Linda Dunbar Cc: Joel M. Halpern; Paul > Quinn (paulq); sfc@ietf.org Subject: Re: [sfc] ç­”å¤: questions of "load > balancing considerations" in the draft-quinn-sfc-arch-05 > > I am not following your question. SFF can have a co-located load > balancer. Or the load balancer can be transparently behind the SFF, > using any number of mechanisms. We are not mandating where it is > located. > > Yours, Joel > > On 5/28/14, 11:55 PM, Qin Wu wrote: >> You are talking about service function scale up and down. >> >> Since service node can host one or multiple service functions, why >> service node can not be used to control scale up or down of >> service functions it? >> >> To avoid share risk failure, service node can be previous service >> node, e.g., it can be the one that hosts sf1 or sf3. >> >> Also SFF is responsible for delivering traffic to any connected >> service functions, why not SFF can not be used to manage scale up >> or down of service function. >> >> Also based on NFV MANO architecture, there is reference point >> between NFV and NFV manager, NFV manager also can control scale up >> or down of service function, I think this case has been covered by >> “through external control†in the draft. >> >> Using sf1 that provide dedicated firewall service to provide load >> balancing functionality as well is a little bit weird to me. >> >> Let me know if my understanding is correct? >> >> Regards! >> >> -Qin >> >> *å‘件人:*sfc [mailto:sfc-bounces@ietf.org] *代表 *Ken Gray (kegray) *å‘é€æ—¶ >> é—´:*2014å¹´5月29æ—¥8:49 *收件人:*Linda Dunbar *抄é€:*Joel M. Halpern; Paul >> Quinn (paulq); sfc@ietf.org *主题:*Re: [sfc] questions of "load >> balancing considerations" in the draft-quinn-sfc-arch-05 >> >> I don't see how you make the leap from the explanation of why it >> was irrelevant to go into more detail in the section to the >> elimination of the very generalized description accompanying the >> figure. Please use your own argument to justify this and not infer >> any extra meaning from my answer to a different question. >> >> As to the second change, i disagree. Again, in general/broad >> strokes - from the drawing and the text, it is unlikely that any >> special action would be required on sf2 or sf4 - as they collapse >> in either direction to a single logical next hop. >> >> Sent from my iPhone >> >> >> On May 28, 2014, at 5:49 PM, "Linda Dunbar" >> > wrote: >> >> Joel, Eric, and Ken, >> >> Thank you very much for the explanation. >> >> Based on what you said, the description on how “control entity >> push to the sf1 nodes …†should be removed from the text, >> specifically: >> >> “In this >> >> case, the control entity will push to the sf1 nodes, a table of >> >> sorts:[L1] <#_msocom_1> sf2 with a series of next hops, and if >> needed some weighted or >> >> other metrics (these could also be decided locally by some policy, >> >> but sf1 would need to be aware of expand/contract triggers and >> >> actions).†>> >> Should also change the sentence after the Figure 5 to >> >> “Either through an imbedded action in sf1 and sf3, the SFF nodes >> to which the multiple instances of SF2 or SF4 are attached, or >> through external >> >> control, the service functions sf2 and sf4 are elastically >> expanded >> >> and contracted dynamically.†>> >> Linda >> >> *From:*Ken Gray (kegray) [mailto:kegray@cisco.com] *Sent:* >> Wednesday, May 28, 2014 4:24 PM *To:* Linda Dunbar; Paul Quinn >> (paulq); Joel M. Halpern *Cc:* sfc@ietf.org >> *Subject:* Re: [sfc] questions of "load balancing considerations" >> in the draft-quinn-sfc-arch-05 >> >> +1 to Joel … the picture would be ugly at best. We attempted a >> generic HA/LB slide to make a point and even it was ugly …such are >> the limitations of ASCII art. >> >> In line … >> >> *From: *Linda Dunbar > > *Date: *Wednesday, May 28, 2014 >> 3:34 PM *To: *"Paul Quinn (paulq)" > >, "Joel M. Halpern" > > *Cc: *"sfc@ietf.org >> " > >> *Subject: *[sfc] questions of "load balancing considerations" in >> the draft-quinn-sfc-arch-05 >> >> Paul and Joel, >> >> Does the Load Balancing Figure 5 (of draft-quinn-sfc-arch-05) >> assume that SF1 is responsible for balancing traffic among the 3 >> instances of SF2, and SF3 is responsible for balancing traffic >> among the 3 instances of SF4? >> >> Document text below the picture says "Either through an >> imbedded action in sf1 and sf3, or through external >> >> control, the service functions sf2 and sf4 are elastically expanded >> and contracted dynamically." >> >> Isn’t it a single point of failure? >> >> Document text immediately subsequent to that picture and >> paragraph illustrates HA scenarios. >> >> Some service functions are Stateful, i.e. they may require packets >> from same flows to traverse the same service function instance. >> For the Load Balancing scheme described by Figure 5, do you assume >> that SF1 and SF3 will be responsible for making sure that same >> flows go through the same service function instance? >> >> Again, the aforementioned text deliberately allows this >> responsibility to be either imbedded in the elasticity-causing >> function or to be controlled externally or centrally. We don't >> get into the mechanics as these can vary. While >> stateful/bidirectional does add an additional burden, it can be >> accommodated without an explosion of discrete chains. For example, >> it could be handled "at allocation time" if elasticity is managed >> via a separate entity and the individual allocations reflected >> through service chain control in the initial metadata bound to at >> the classification point in either direction. OR, if the devices >> are working as a paired system (single vendor or ecosystem) with >> integrated elasticity, they could pass metadata between them when >> sf1 or sf3 does the initial dynamic allocation (affecting local >> forwarding on it's partner). That's probably not an exhaustive >> list of ways to solve the problem. 8^) >> >> The point of this section was that elasticity and HA should >> not cause an inordinate explosion of discrete chains without >> recommending a particular solution. That is, you shouldn't >> create unnecessary complexity where it doesn't need to exist. >> >> For the stateful service functions, if a flow is switched from >> SF-Instance-X to SF-Instance-Y, the SF-Instance-Y needs to >> synchronize the states from SF-Instance-X. Who is responsible for >> those states maintenance for the Load Balancing described in Figure >> 5? >> >> None of those entities exist in Figure 5. Can you re-phrase >> your question from the figure? >> >> Linda >> >> ---------------------------------------------------------------------- >> >> -- >> >> Require pushing policies to SF1 on how to load balance multiple >> instances of SF2. >> >> SF1 may not have the capability to balance among multiple instances >> of SF2 >> >> >> >> _______________________________________________ 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 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 > From nobody Thu May 29 13:06:50 2014 Return-Path: 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 6A84E1A0644 for ; Thu, 29 May 2014 13:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no 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 7LMFepI7JGLq for ; Thu, 29 May 2014 13:06:28 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36F921A04B1 for ; Thu, 29 May 2014 13:06:28 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id z60so2575358qgd.32 for ; Thu, 29 May 2014 13:06:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5rjkp7LBnW88M1rTLuXzWHQAxV/UAcyET40p3LzPvMU=; b=Hs6ObnPsNx9z/QeAWy1Vk/s+Xnw+NsjBEK6j05nPTdxqzIHjauUoPWbJiSzQqziOjn bZi8igdqnFbYO8veg77soq+3XXHZ5MN38inCQ5OGVuRQI2M7pQCseDyT4JfvmDPM3nDF ABIghdCReteeC0FN26VXD3URLAFt3TUWSdfoW4QXopTA30IQUWQEoN6zZL0i0tXatFQ6 Lf3Ha07UV07dO1cmbpF/jQMJQMufgFUD8uE8hW9AmnyYVmNYTv2kLF2ACt4i0zKPvxdF nPmLFRB4F4zWWdaIKHZfKs/XwxpYw0w2QejGs7i+qhvBTUPcfIS+jJXQT9SeT+89jwpf Anxg== X-Received: by 10.140.20.144 with SMTP id 16mr13100225qgj.114.1401393983858; Thu, 29 May 2014 13:06:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.86.148 with HTTP; Thu, 29 May 2014 13:06:03 -0700 (PDT) In-Reply-To: <53879137.7010900@joelhalpern.com> References: <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> <16984558-2B4C-4873-AFC7-DCD2698CA745@cisco.com> <53873333.80807@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D45389906@dfweml701-chm.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D453899C2@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645D28EAF@dfweml701-chm.china.huawei.com> <53879137.7010900@joelhalpern.com> From: "Andrew G. Malis" Date: Thu, 29 May 2014 16:06:03 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a11c12632992ba504fa8f766b Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/TC6Q6S09sezMwoWfTxwg54OTmzY Cc: "Ken Gray \(kegray\)" , "sfc@ietf.org" , Lucy yong , Linda Dunbar , "Paul Quinn \(paulq\)" , Ron Parker , Qin Wu Subject: Re: [sfc] =?utf-8?b?562U5aSNOiBxdWVzdGlvbnMgb2YgImxvYWQgYmFsYW5jaW5n?= =?utf-8?q?_considerations=22_in_the_draft-quinn-sfc-arch-05?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 20:06:29 -0000 --001a11c12632992ba504fa8f766b Content-Type: text/plain; charset=UTF-8 Joel, I disagree, I really don't see it as confusing at all. We're all in agreement that there will be cases where a service function is split among multiple hardware and/or software entities that can work in parallel, or else there wouldn't be a section on load sharing. How else would one describe these entities if not as "Service Function Instances"? Cheers, Andy On Thu, May 29, 2014 at 3:57 PM, Joel M. Halpern wrote: > the problem I have with the definition you propose for Service Function > Instance is that what is an instance will depend upon where you look. > What management, and particularly what virtual machine monitoring and > management, sees as an instance has to be a single image running on a > single VM. > But what Service Chaining sees as an instance may be one such thing, or > may be a cluster of such things organized in such a way as to present a > single view to the service chaining infrastructure. > > Thus, trying to define Service Function Instance, and then talk explicitly > about such instances in service chaining, gets very difficult. We are > likely to end up with a definition that says that a service function > instance may be made up of multiple software instances. Such a definition > seems likely to cause more confusion than it solves. > > If we can come up with a definition that allows for the range of > deployments, and does not itself further confuse the readers, then I am > happy to add such a term definition and usage in the document. > > Yours, > Joel > > > On 5/29/14, 2:25 PM, Linda Dunbar wrote: > >> It would be so much easier to formally introduce the concept of >> "Service Function Instance" in SFC. For example: >> >> "Service Function Instance: One instantiation of a service function. >> One service function could have multiple identical instances. >> >> For a service function with different functional instantiations, e.g. >> one instantiation applies policy-set-A (NAT44-A) and other applies >> policy-set-B (NAT44-B), they are considered as two different service >> functions." >> >> Some Service Function Instances are visible to Service Chain Path. >> Sometimes a collection of service function instances can appear as >> one single entity to the Service Chain Path." >> >> >> Linda >> >> --001a11c12632992ba504fa8f766b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Joel,

    I disagree, I really don't se= e it as confusing at all. We're all in agreement that there will be cas= es where a service function is split among multiple hardware and/or softwar= e entities that can work in parallel, or else there wouldn't be a secti= on on load sharing. How else would one describe these entities if not as &q= uot;Service Function Instances"?

    Cheers,
    Andy

    On Thu, May 29, 2014 at 3:57 PM, Joel M= . Halpern <jmh@joelhalpern.com> wrote:
    the problem I have with the definition you p= ropose for Service Function Instance is that what is an instance will depen= d upon where you look.
    What management, and particularly what virtual machine monitoring and manag= ement, sees as an instance has to be a single image running on a single VM.=
    But what Service Chaining sees as an instance may be one such thing, or may= be a cluster of such things organized in such a way as to present a single= view to the service chaining infrastructure.

    Thus, trying to define Service Function Instance, and then talk explicitly = about such instances in service chaining, gets very difficult. =C2=A0We are= likely to end up with a definition that says that a service function insta= nce may be made up of multiple software instances. =C2=A0Such a definition = seems likely to cause more confusion than it solves.

    If we can come up with a definition that allows for the range of deployment= s, and does not itself further confuse the readers, then I am happy to add = such a term definition and usage in the document.

    Yours,
    Joel


    On 5/29/14, 2:25 PM, Linda Dunbar wrote:
    It would be so much easier to formally introduce the concept of
    "Service Function Instance" in SFC. For example:

    "Service Function Instance: One instantiation of a service function. One service function could have multiple identical instances.

    For a service function with different functional instantiations, e.g.
    one instantiation applies policy-set-A (NAT44-A) and other applies
    policy-set-B (NAT44-B), they are considered as two different service
    functions."

    Some Service Function Instances are visible to Service Chain Path.
    Sometimes a collection of service function instances can appear as
    one single entity to the Service Chain Path."


    Linda

    --001a11c12632992ba504fa8f766b-- From nobody Thu May 29 13:13:41 2014 Return-Path: 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 E5C421A064F for ; Thu, 29 May 2014 13:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 zecBvTS6yKJK for ; Thu, 29 May 2014 13:13:37 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C1861A0693 for ; Thu, 29 May 2014 13:13:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4937B240756; Thu, 29 May 2014 13:13:32 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (aptilo2-usaa.ericsson.net [129.192.185.163]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id EFBE4240636; Thu, 29 May 2014 13:13:30 -0700 (PDT) Message-ID: <538794E9.7020306@joelhalpern.com> Date: Thu, 29 May 2014 16:13:29 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Andrew G. Malis" References: <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> <16984558-2B4C-4873-AFC7-DCD2698CA745@cisco.com> <53873333.80807@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D45389906@dfweml701-chm.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D453899C2@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645D28EAF@dfweml701-chm.china.huawei.com> <53879137.7010900@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/LqGaSNS9d2McH4XRzdkOXRaT6VU Cc: "Ken Gray \(kegray\)" , "sfc@ietf.org" , Lucy yong , Linda Dunbar , "Paul Quinn \(paulq\)" , Ron Parker , Qin Wu Subject: Re: [sfc] =?utf-8?b?562U5aSNOiBxdWVzdGlvbnMgb2YgImxvYWQgYmFsYW5jaW5n?= =?utf-8?q?_considerations=22_in_the_draft-quinn-sfc-arch-05?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 20:13:38 -0000 If the service chain splits, that is one case. But it is also quite acceptable and within what has been discussed for the service chain (or more specifically the service path) not to split at all. Rather, what hangs off of the SFF is a suitable load balancer (or balancers) and multiple service function instances. That balancing is not visible to service chaining (although it is certainly visible to management. The point of such a deployment is that there is no change to the service paths as that collective service function scales in or out as direct by management, or as caused by failures, or ... If we insist that the service paths within such a deployment are different, we are requiring larger scale visiblity of such events. Yours, Joel On 5/29/14, 4:06 PM, Andrew G. Malis wrote: > Joel, > > I disagree, I really don't see it as confusing at all. We're all in > agreement that there will be cases where a service function is split > among multiple hardware and/or software entities that can work in > parallel, or else there wouldn't be a section on load sharing. How else > would one describe these entities if not as "Service Function Instances"? > > Cheers, > Andy > > On Thu, May 29, 2014 at 3:57 PM, Joel M. Halpern > wrote: > > the problem I have with the definition you propose for Service > Function Instance is that what is an instance will depend upon where > you look. > What management, and particularly what virtual machine monitoring > and management, sees as an instance has to be a single image running > on a single VM. > But what Service Chaining sees as an instance may be one such thing, > or may be a cluster of such things organized in such a way as to > present a single view to the service chaining infrastructure. > > Thus, trying to define Service Function Instance, and then talk > explicitly about such instances in service chaining, gets very > difficult. We are likely to end up with a definition that says that > a service function instance may be made up of multiple software > instances. Such a definition seems likely to cause more confusion > than it solves. > > If we can come up with a definition that allows for the range of > deployments, and does not itself further confuse the readers, then I > am happy to add such a term definition and usage in the document. > > Yours, > Joel > > > On 5/29/14, 2:25 PM, Linda Dunbar wrote: > > It would be so much easier to formally introduce the concept of > "Service Function Instance" in SFC. For example: > > "Service Function Instance: One instantiation of a service function. > One service function could have multiple identical instances. > > For a service function with different functional instantiations, > e.g. > one instantiation applies policy-set-A (NAT44-A) and other applies > policy-set-B (NAT44-B), they are considered as two different service > functions." > > Some Service Function Instances are visible to Service Chain Path. > Sometimes a collection of service function instances can appear as > one single entity to the Service Chain Path." > > > Linda > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu May 29 13:24:54 2014 Return-Path: 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 034A21A0404 for ; Thu, 29 May 2014 13:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no 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 C2kfDJdRL5bE for ; Thu, 29 May 2014 13:24:49 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C82F1A00E5 for ; Thu, 29 May 2014 13:24:49 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id i50so2641629qgf.35 for ; Thu, 29 May 2014 13:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5col4rpn+0nxleCv0fwtqLSvtct68sGGNiYbPM6Noz0=; b=VpL3wMcWKm66gEeyilsKtDTc4Pt37fGfQgVzy8e7N8M3wPRzH4ffkSzb5hZFBH2tW1 LPDU8PAWZyO7DVrbRxlBhk0MM4rmpyTO0FNIlRKK2wzi2yVXcLQSP3oRNlM/GDfK2Xct xf+CbqYaAp0guMEiI+CwiWzBnAA7fHizkucsctdXX6RxEBlf8teT517a54IgXXhcHViF knn1tDgFMStpr1hjPqA1miceQJ3Fm4qy8U2139NcyAHEmM+U+jQOvv6IamNAVX8+isHj qhh6JOqgdlNGVMWs5g1Uf7eb2FP9Eh3zT+sFuae7NYNuWP27THwUxdiMMVNGRzGf1ZgM gSgw== X-Received: by 10.140.34.228 with SMTP id l91mr13163749qgl.85.1401395084725; Thu, 29 May 2014 13:24:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.86.148 with HTTP; Thu, 29 May 2014 13:24:24 -0700 (PDT) In-Reply-To: <538794E9.7020306@joelhalpern.com> References: <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> <16984558-2B4C-4873-AFC7-DCD2698CA745@cisco.com> <53873333.80807@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D45389906@dfweml701-chm.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D453899C2@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645D28EAF@dfweml701-chm.china.huawei.com> <53879137.7010900@joelhalpern.com> <538794E9.7020306@joelhalpern.com> From: "Andrew G. Malis" Date: Thu, 29 May 2014 16:24:24 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a11c100103730ce04fa8fb86e Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/z654lc1SVPDNsfb88VNaM1ki9Pc Cc: "Ken Gray \(kegray\)" , "sfc@ietf.org" , Lucy yong , Linda Dunbar , "Paul Quinn \(paulq\)" , Ron Parker , Qin Wu Subject: Re: [sfc] =?utf-8?b?562U5aSNOiBxdWVzdGlvbnMgb2YgImxvYWQgYmFsYW5jaW5n?= =?utf-8?q?_considerations=22_in_the_draft-quinn-sfc-arch-05?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 20:24:51 -0000 --001a11c100103730ce04fa8fb86e Content-Type: text/plain; charset=UTF-8 Joel, I think we're in violent agreement. There's no insistence that the multiple instances need to be visible to the service chain path, indeed Linda's definition includes "Some Service Function Instances are visible to Service Chain Path. Sometimes a collection of service function instances can appear as one single entity to the Service Chain Path." This part o the definition might be better and more simply phrased as "A collection of Service Function Instances may appear as one entity or as multiple entities in the Service Chain Path." Cheers, Andy On Thu, May 29, 2014 at 4:13 PM, Joel M. Halpern wrote: > If the service chain splits, that is one case. > But it is also quite acceptable and within what has been discussed for the > service chain (or more specifically the service path) not to split at all. > Rather, what hangs off of the SFF is a suitable load balancer (or > balancers) and multiple service function instances. That balancing is not > visible to service chaining (although it is certainly visible to > management. The point of such a deployment is that there is no change to > the service paths as that collective service function scales in or out as > direct by management, or as caused by failures, or ... > > If we insist that the service paths within such a deployment are > different, we are requiring larger scale visiblity of such events. > > Yours, > Joel > > > On 5/29/14, 4:06 PM, Andrew G. Malis wrote: > >> Joel, >> >> I disagree, I really don't see it as confusing at all. We're all in >> agreement that there will be cases where a service function is split >> among multiple hardware and/or software entities that can work in >> parallel, or else there wouldn't be a section on load sharing. How else >> would one describe these entities if not as "Service Function Instances"? >> >> Cheers, >> Andy >> >> On Thu, May 29, 2014 at 3:57 PM, Joel M. Halpern > > wrote: >> >> the problem I have with the definition you propose for Service >> Function Instance is that what is an instance will depend upon where >> you look. >> What management, and particularly what virtual machine monitoring >> and management, sees as an instance has to be a single image running >> on a single VM. >> But what Service Chaining sees as an instance may be one such thing, >> or may be a cluster of such things organized in such a way as to >> present a single view to the service chaining infrastructure. >> >> Thus, trying to define Service Function Instance, and then talk >> explicitly about such instances in service chaining, gets very >> difficult. We are likely to end up with a definition that says that >> a service function instance may be made up of multiple software >> instances. Such a definition seems likely to cause more confusion >> than it solves. >> >> If we can come up with a definition that allows for the range of >> deployments, and does not itself further confuse the readers, then I >> am happy to add such a term definition and usage in the document. >> >> Yours, >> Joel >> >> >> On 5/29/14, 2:25 PM, Linda Dunbar wrote: >> >> It would be so much easier to formally introduce the concept of >> "Service Function Instance" in SFC. For example: >> >> "Service Function Instance: One instantiation of a service >> function. >> One service function could have multiple identical instances. >> >> For a service function with different functional instantiations, >> e.g. >> one instantiation applies policy-set-A (NAT44-A) and other applies >> policy-set-B (NAT44-B), they are considered as two different >> service >> functions." >> >> Some Service Function Instances are visible to Service Chain Path. >> Sometimes a collection of service function instances can appear as >> one single entity to the Service Chain Path." >> >> >> Linda >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> >> --001a11c100103730ce04fa8fb86e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Joel,

    I think we're in violent agre= ement. There's no insistence that the multiple instances need to be vis= ible to the service chain path, indeed Linda's definition includes &quo= t;Some Service Function Instances are visible to Service Chain Path.=C2= =A0Sometimes a collection of service function instances can appe= ar as=C2=A0one single entity to the Service Chain Path." Th= is part o the definition might be better and more simply phrased as "<= /span>A collection of Service Function Instances may appear as=C2=A0one entity or as multiple entities in the Service Chain Path."=

    Cheers,
    Andy=


    On Thu,= May 29, 2014 at 4:13 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
    If the service chain splits, that is one cas= e.
    But it is also quite acceptable and within what has been discussed for the = service chain (or more specifically the service path) not to split at all. = =C2=A0Rather, what hangs off of the SFF is a suitable load balancer (or bal= ancers) and multiple service function instances. =C2=A0That balancing is no= t visible to service chaining (although it is certainly visible to manageme= nt. =C2=A0The point of such a deployment is that there is no change to the = service paths as that collective service function scales in or out as direc= t by management, or as caused by failures, or ...

    If we insist that the service paths within such a deployment are different,= we are requiring larger scale visiblity of such events.

    Yours,
    Joel


    On 5/29/14, 4:06 PM, Andrew G. Malis wrote:
    Joel,

    I disagree, I really don't see it as confusing at all. We're all in=
    agreement that there will be cases where a service function is split
    among multiple hardware and/or software entities that can work in
    parallel, or else there wouldn't be a section on load sharing. How else=
    would one describe these entities if not as "Service Function Instance= s"?

    Cheers,
    Andy

    On Thu, May 29, 2014 at 3:57 PM, Joel M. Halpern <jmh@joelhalpern.com
    <mailto:jmh@joe= lhalpern.com>> wrote:

    =C2=A0 =C2=A0 the problem I have with the definition you propose for Servic= e
    =C2=A0 =C2=A0 Function Instance is that what is an instance will depend upo= n where
    =C2=A0 =C2=A0 you look.
    =C2=A0 =C2=A0 What management, and particularly what virtual machine monito= ring
    =C2=A0 =C2=A0 and management, sees as an instance has to be a single image = running
    =C2=A0 =C2=A0 on a single VM.
    =C2=A0 =C2=A0 But what Service Chaining sees as an instance may be one such= thing,
    =C2=A0 =C2=A0 or may be a cluster of such things organized in such a way as= to
    =C2=A0 =C2=A0 present a single view to the service chaining infrastructure.=

    =C2=A0 =C2=A0 Thus, trying to define Service Function Instance, and then ta= lk
    =C2=A0 =C2=A0 explicitly about such instances in service chaining, gets ver= y
    =C2=A0 =C2=A0 difficult. =C2=A0We are likely to end up with a definition th= at says that
    =C2=A0 =C2=A0 a service function instance may be made up of multiple softwa= re
    =C2=A0 =C2=A0 instances. =C2=A0Such a definition seems likely to cause more= confusion
    =C2=A0 =C2=A0 than it solves.

    =C2=A0 =C2=A0 If we can come up with a definition that allows for the range= of
    =C2=A0 =C2=A0 deployments, and does not itself further confuse the readers,= then I
    =C2=A0 =C2=A0 am happy to add such a term definition and usage in the docum= ent.

    =C2=A0 =C2=A0 Yours,
    =C2=A0 =C2=A0 Joel


    =C2=A0 =C2=A0 On 5/29/14, 2:25 PM, Linda Dunbar wrote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 It would be so much easier to formally introduc= e the concept of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Service Function Instance" in SFC. F= or example:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Service Function Instance: One instantiat= ion of a service function.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 One service function could have multiple identi= cal instances.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 For a service function with different functiona= l instantiations,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 e.g.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 one instantiation applies policy-set-A (NAT44-A= ) and other applies
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 policy-set-B (NAT44-B), they are considered as = two different service
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 functions."

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Some Service Function Instances are visible to = Service Chain Path.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sometimes a collection of service function inst= ances can appear as
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 one single entity to the Service Chain Path.&qu= ot;


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Linda



    _______________________________________________
    sfc mailing list
    sfc@ietf.org
    htt= ps://www.ietf.org/mailman/listinfo/sfc


    --001a11c100103730ce04fa8fb86e-- From nobody Thu May 29 13:27:37 2014 Return-Path: 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 C139C1A04B1 for ; Thu, 29 May 2014 13:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 LiWFXeGj3veq for ; Thu, 29 May 2014 13:27:33 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCDF61A00E5 for ; Thu, 29 May 2014 13:27:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id EC6F61C055D; Thu, 29 May 2014 13:27:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (aptilo2-usaa.ericsson.net [129.192.185.163]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 5E5A0700C2A; Thu, 29 May 2014 13:27:22 -0700 (PDT) Message-ID: <53879825.5090809@joelhalpern.com> Date: Thu, 29 May 2014 16:27:17 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Andrew G. Malis" , "Joel M. Halpern" References: <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> <16984558-2B4C-4873-AFC7-DCD2698CA745@cisco.com> <53873333.80807@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D45389906@dfweml701-chm.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D453899C2@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645D28EAF@dfweml701-chm.china.huawei.com> <53879137.7010900@joelhalpern.com> <538794E9.7020306@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/IIol5ohpYMm8YN7LfMkMr2stQuM Cc: "Ken Gray \(kegray\)" , "sfc@ietf.org" , Lucy yong , Linda Dunbar , "Paul Quinn \(paulq\)" , Ron Parker , Qin Wu Subject: Re: [sfc] =?utf-8?b?562U5aSNOiBxdWVzdGlvbnMgb2YgImxvYWQgYmFsYW5jaW5n?= =?utf-8?q?_considerations=22_in_the_draft-quinn-sfc-arch-05?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 20:27:35 -0000 In that case, there would seem to be very few places, if any, in the document where we would use the term Service Function Instance. Yours, Joel On 5/29/14, 4:24 PM, Andrew G. Malis wrote: > Joel, > > I think we're in violent agreement. There's no insistence that the > multiple instances need to be visible to the service chain path, indeed > Linda's definition includes "Some Service Function Instances are visible > to Service Chain Path. Sometimes a collection of service function > instances can appear as one single entity to the Service Chain Path." > This part o the definition might be better and more simply phrased as "A > collection of Service Function Instances may appear as one entity or as > multiple entities in the Service Chain Path." > > Cheers, > Andy > > > On Thu, May 29, 2014 at 4:13 PM, Joel M. Halpern > wrote: > > If the service chain splits, that is one case. > But it is also quite acceptable and within what has been discussed > for the service chain (or more specifically the service path) not to > split at all. Rather, what hangs off of the SFF is a suitable load > balancer (or balancers) and multiple service function instances. > That balancing is not visible to service chaining (although it is > certainly visible to management. The point of such a deployment is > that there is no change to the service paths as that collective > service function scales in or out as direct by management, or as > caused by failures, or ... > > If we insist that the service paths within such a deployment are > different, we are requiring larger scale visiblity of such events. > > Yours, > Joel > > > On 5/29/14, 4:06 PM, Andrew G. Malis wrote: > > Joel, > > I disagree, I really don't see it as confusing at all. We're all in > agreement that there will be cases where a service function is split > among multiple hardware and/or software entities that can work in > parallel, or else there wouldn't be a section on load sharing. > How else > would one describe these entities if not as "Service Function > Instances"? > > Cheers, > Andy > > On Thu, May 29, 2014 at 3:57 PM, Joel M. Halpern > > >> wrote: > > the problem I have with the definition you propose for Service > Function Instance is that what is an instance will depend > upon where > you look. > What management, and particularly what virtual machine > monitoring > and management, sees as an instance has to be a single > image running > on a single VM. > But what Service Chaining sees as an instance may be one > such thing, > or may be a cluster of such things organized in such a way > as to > present a single view to the service chaining infrastructure. > > Thus, trying to define Service Function Instance, and then talk > explicitly about such instances in service chaining, gets very > difficult. We are likely to end up with a definition that > says that > a service function instance may be made up of multiple software > instances. Such a definition seems likely to cause more > confusion > than it solves. > > If we can come up with a definition that allows for the > range of > deployments, and does not itself further confuse the > readers, then I > am happy to add such a term definition and usage in the > document. > > Yours, > Joel > > > On 5/29/14, 2:25 PM, Linda Dunbar wrote: > > It would be so much easier to formally introduce the > concept of > "Service Function Instance" in SFC. For example: > > "Service Function Instance: One instantiation of a > service function. > One service function could have multiple identical > instances. > > For a service function with different functional > instantiations, > e.g. > one instantiation applies policy-set-A (NAT44-A) and > other applies > policy-set-B (NAT44-B), they are considered as two > different service > functions." > > Some Service Function Instances are visible to Service > Chain Path. > Sometimes a collection of service function instances > can appear as > one single entity to the Service Chain Path." > > > Linda > > > > _________________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/__listinfo/sfc > > > From nobody Thu May 29 13:45:47 2014 Return-Path: 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 4E91A1A06A2 for ; Thu, 29 May 2014 13:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no 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 PJmnClBD4S0N for ; Thu, 29 May 2014 13:45:25 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8223E1A00EA for ; Thu, 29 May 2014 13:45:25 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id q108so2704317qgd.33 for ; Thu, 29 May 2014 13:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rf1mmJmYk0KHSFBc7dX1j7hm9AlghdE34NyFoy6RP18=; b=r3mHAchJjpHdgnD6W7rwtSxPbh1IeRLmkiilsd6/QvXkx6xPxov/I6TCcOb4BCjsnj b8+/cvMWlCRhI/nQGoN+t9k+pRH/8BbmzI2hScFbBRgd/6uNO2QpWuBjacY+3lKhJAjt GOPXepQLhNdanzvrr3SbiATQHaoE8ond+UdvliCLpsw8EMU9ORbateOizHlAxym84zf+ zSiZV7VXv1bKz3bHiWw7vuNpXVQwCNVwvfYuIndzxH0HT9S/yVajYIc594pIsOFHfvWe SJAYpcOq1GNCBzxjZLj9dA/6+JhxJDe5j1zttLPol6O0l55kVwlvyX9SIUY9mbAWRBvW RJIQ== X-Received: by 10.224.135.66 with SMTP id m2mr14440114qat.55.1401396320954; Thu, 29 May 2014 13:45:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.86.148 with HTTP; Thu, 29 May 2014 13:45:00 -0700 (PDT) In-Reply-To: <53879825.5090809@joelhalpern.com> References: <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> <16984558-2B4C-4873-AFC7-DCD2698CA745@cisco.com> <53873333.80807@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D45389906@dfweml701-chm.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D453899C2@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645D28EAF@dfweml701-chm.china.huawei.com> <53879137.7010900@joelhalpern.com> <538794E9.7020306@joelhalpern.com> <53879825.5090809@joelhalpern.com> From: "Andrew G. Malis" Date: Thu, 29 May 2014 16:45:00 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a11c2e496e68d3304fa9001ec Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/wJQLwyYqbx-BWHc7zGsJj5vAFqc Cc: "Ken Gray \(kegray\)" , "sfc@ietf.org" , Lucy yong , Linda Dunbar , "Paul Quinn \(paulq\)" , Ron Parker , Qin Wu Subject: Re: [sfc] =?utf-8?b?562U5aSNOiBxdWVzdGlvbnMgb2YgImxvYWQgYmFsYW5jaW5n?= =?utf-8?q?_considerations=22_in_the_draft-quinn-sfc-arch-05?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 20:45:27 -0000 --001a11c2e496e68d3304fa9001ec Content-Type: text/plain; charset=UTF-8 Joel, Again, we're in agreement. It would most likely be confined to sections 1.2 (initial definition) and 6 (load balancing). Cheers, Andy On Thu, May 29, 2014 at 4:27 PM, Joel M. Halpern wrote: > In that case, there would seem to be very few places, if any, in the > document where we would use the term Service Function Instance. > > Yours, > Joel > > > On 5/29/14, 4:24 PM, Andrew G. Malis wrote: > >> Joel, >> >> I think we're in violent agreement. There's no insistence that the >> multiple instances need to be visible to the service chain path, indeed >> Linda's definition includes "Some Service Function Instances are visible >> to Service Chain Path. Sometimes a collection of service function >> instances can appear as one single entity to the Service Chain Path." >> This part o the definition might be better and more simply phrased as "A >> collection of Service Function Instances may appear as one entity or as >> multiple entities in the Service Chain Path." >> >> Cheers, >> Andy >> >> >> On Thu, May 29, 2014 at 4:13 PM, Joel M. Halpern > > wrote: >> >> If the service chain splits, that is one case. >> But it is also quite acceptable and within what has been discussed >> for the service chain (or more specifically the service path) not to >> split at all. Rather, what hangs off of the SFF is a suitable load >> balancer (or balancers) and multiple service function instances. >> That balancing is not visible to service chaining (although it is >> certainly visible to management. The point of such a deployment is >> that there is no change to the service paths as that collective >> service function scales in or out as direct by management, or as >> caused by failures, or ... >> >> If we insist that the service paths within such a deployment are >> different, we are requiring larger scale visiblity of such events. >> >> Yours, >> Joel >> >> >> On 5/29/14, 4:06 PM, Andrew G. Malis wrote: >> >> Joel, >> >> I disagree, I really don't see it as confusing at all. We're all >> in >> agreement that there will be cases where a service function is >> split >> among multiple hardware and/or software entities that can work in >> parallel, or else there wouldn't be a section on load sharing. >> How else >> would one describe these entities if not as "Service Function >> Instances"? >> >> Cheers, >> Andy >> >> On Thu, May 29, 2014 at 3:57 PM, Joel M. Halpern >> >> >> wrote: >> >> the problem I have with the definition you propose for >> Service >> Function Instance is that what is an instance will depend >> upon where >> you look. >> What management, and particularly what virtual machine >> monitoring >> and management, sees as an instance has to be a single >> image running >> on a single VM. >> But what Service Chaining sees as an instance may be one >> such thing, >> or may be a cluster of such things organized in such a way >> as to >> present a single view to the service chaining infrastructure. >> >> Thus, trying to define Service Function Instance, and then >> talk >> explicitly about such instances in service chaining, gets >> very >> difficult. We are likely to end up with a definition that >> says that >> a service function instance may be made up of multiple >> software >> instances. Such a definition seems likely to cause more >> confusion >> than it solves. >> >> If we can come up with a definition that allows for the >> range of >> deployments, and does not itself further confuse the >> readers, then I >> am happy to add such a term definition and usage in the >> document. >> >> Yours, >> Joel >> >> >> On 5/29/14, 2:25 PM, Linda Dunbar wrote: >> >> It would be so much easier to formally introduce the >> concept of >> "Service Function Instance" in SFC. For example: >> >> "Service Function Instance: One instantiation of a >> service function. >> One service function could have multiple identical >> instances. >> >> For a service function with different functional >> instantiations, >> e.g. >> one instantiation applies policy-set-A (NAT44-A) and >> other applies >> policy-set-B (NAT44-B), they are considered as two >> different service >> functions." >> >> Some Service Function Instances are visible to Service >> Chain Path. >> Sometimes a collection of service function instances >> can appear as >> one single entity to the Service Chain Path." >> >> >> Linda >> >> >> >> _________________________________________________ >> >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/__listinfo/sfc >> >> >> >> --001a11c2e496e68d3304fa9001ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Joel,

    Again, we're in agreement. It= would most likely be confined to sections 1.2 (initial definition) and 6 (= load balancing).

    Cheers,
    Andy


    On Thu, May 2= 9, 2014 at 4:27 PM, Joel M. Halpern <jmh@joelhalpern.com> = wrote:
    In that case, there would seem to be very fe= w places, if any, in the document where we would use the term Service Funct= ion Instance.

    Yours,
    Joel


    On 5/29/14, 4:24 PM, Andrew G. Malis wrote:
    Joel,

    I think we're in violent agreement. There's no insistence that the<= br> multiple instances need to be visible to the service chain path, indeed
    Linda's definition includes "Some Service Function Instances are v= isible
    to Service Chain Path. Sometimes a collection of service function
    instances can appear as one single entity to the Service Chain Path."<= br> This part o the definition might be better and more simply phrased as "= ;A
    collection of Service Function Instances may appear as one entity or as
    multiple entities in the Service Chain Path."

    Cheers,
    Andy


    On Thu, May 29, 2014 at 4:13 PM, Joel M. Halpern <jmh@joelhalpern.com
    <mailto:jmh@joe= lhalpern.com>> wrote:

    =C2=A0 =C2=A0 If the service chain splits, that is one case.
    =C2=A0 =C2=A0 But it is also quite acceptable and within what has been disc= ussed
    =C2=A0 =C2=A0 for the service chain (or more specifically the service path)= not to
    =C2=A0 =C2=A0 split at all. =C2=A0Rather, what hangs off of the SFF is a su= itable load
    =C2=A0 =C2=A0 balancer (or balancers) and multiple service function instanc= es.
    =C2=A0 =C2=A0 =C2=A0 That balancing is not visible to service chaining (alt= hough it is
    =C2=A0 =C2=A0 certainly visible to management. =C2=A0The point of such a de= ployment is
    =C2=A0 =C2=A0 that there is no change to the service paths as that collecti= ve
    =C2=A0 =C2=A0 service function scales in or out as direct by management, or= as
    =C2=A0 =C2=A0 caused by failures, or ...

    =C2=A0 =C2=A0 If we insist that the service paths within such a deployment = are
    =C2=A0 =C2=A0 different, we are requiring larger scale visiblity of such ev= ents.

    =C2=A0 =C2=A0 Yours,
    =C2=A0 =C2=A0 Joel


    =C2=A0 =C2=A0 On 5/29/14, 4:06 PM, Andrew G. Malis wrote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Joel,

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 I disagree, I really don't see it as confus= ing at all. We're all in
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 agreement that there will be cases where a serv= ice function is split
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 among multiple hardware and/or software entitie= s that can work in
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 parallel, or else there wouldn't be a secti= on on load sharing.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 How else
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 would one describe these entities if not as &qu= ot;Service Function
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Instances"?

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Andy

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, May 29, 2014 at 3:57 PM, Joel M. Halper= n
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>
    <= div>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>> w= rote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the problem I have with the= definition you propose for Service
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Function Instance is that w= hat is an instance will depend
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 upon where
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0you look.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0What management, and partic= ularly what virtual machine
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 monitoring
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and management, sees as an = instance has to be a single
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 image running
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0on a single VM.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0But what Service Chaining s= ees as an instance may be one
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 such thing,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0or may be a cluster of such= things organized in such a way
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 as to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0present a single view to th= e service chaining infrastructure.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thus, trying to define Serv= ice Function Instance, and then talk
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0explicitly about such insta= nces in service chaining, gets very
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0difficult. =C2=A0We are lik= ely to end up with a definition that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 says that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a service function instance= may be made up of multiple software
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0instances. =C2=A0Such a def= inition seems likely to cause more
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 confusion
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0than it solves.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If we can come up with a de= finition that allows for the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 range of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0deployments, and does not i= tself further confuse the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 readers, then I
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0am happy to add such a term= definition and usage in the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 document.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Yours,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Joel


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 5/29/14, 2:25 PM, Linda = Dunbar wrote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It would be s= o much easier to formally introduce the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 concept of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Service= Function Instance" in SFC. For example:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Service= Function Instance: One instantiation of a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 service function.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0One service f= unction could have multiple identical
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 instances.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For a service= function with different functional
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 instantiations,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e.g.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0one instantia= tion applies policy-set-A (NAT44-A) and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 other applies
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0policy-set-B = (NAT44-B), they are considered as two
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 different service
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0functions.&qu= ot;

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Some Service = Function Instances are visible to Service
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Chain Path.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sometimes a c= ollection of service function instances
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 can appear as
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0one single en= tity to the Service Chain Path."


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Linda



    =C2=A0 =C2=A0 =C2=A0 =C2=A0 ________________________________________= _________

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 sfc mailing list
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 sfc@ietf.org <mailto:sfc@ietf.org>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/__listinfo/s= fc
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailman/listinfo/s= fc>



    --001a11c2e496e68d3304fa9001ec-- From nobody Thu May 29 13:49:12 2014 Return-Path: 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 2618B1A06B8 for ; Thu, 29 May 2014 13:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 B88xBZmC1lko for ; Thu, 29 May 2014 13:49:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6BFF1A06AE for ; Thu, 29 May 2014 13:49:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BER45668; Thu, 29 May 2014 20:48:59 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 21:48:24 +0100 Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 21:48:56 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml706-chm.china.huawei.com ([169.254.8.4]) with mapi id 14.03.0158.001; Thu, 29 May 2014 13:48:44 -0700 From: Linda Dunbar To: Lucy yong , Eric Gray , "Jakob Heitz (jheitz)" , Joel Halpern , "Paul Quinn (paulq)" Thread-Topic: Figures in draft-quinn-sfc-arch-05 Thread-Index: Ac97S9R6mfocA+1iTpKXBfVlibSBggAGJh5AAACjtcAAAHRWQAAFiSTQ Date: Thu, 29 May 2014 20:48:43 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D290DA@dfweml701-chm.china.huawei.com> References: <48E1A67CB9CA044EADFEAB87D814BFF632AD0443@eusaamb107.ericsson.se> <075DE01702BBC249BE1357EFD20DCFE556E2EC@xmb-aln-x02.cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD07D6@eusaamb107.ericsson.se> <2691CE0099834E4A9C5044EEC662BB9D45389B2C@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D45389B2C@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.251] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D290DAdfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/7RqMR2Ds49o7oOjwr5xMtwkY_0k Cc: "sfc@ietf.org" Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 20:49:10 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645D290DAdfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I like the Figures drawn by Lucy. Actually why can't Figure 5 be simplified as enter -->{sf1}-->-{sf2|sf2'|sf2''}->--{sf3}-->-{sf4|sf4'|sf4''}->--{sf5= }--> exit ?? Linda From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong Sent: Thursday, May 29, 2014 1:12 PM To: Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 For readability on these figures, propose: Figure 5: +-sf2-+ +-sf4-+ | | | | enter -->sf1-->-sf2->--sf3-->-sf4->--sf5--> exit | | | | +-sf2-+ +-sf4-+ Figure 6: +-sf2-+ +-sf4-+ | | | | enter -->{sf1|sf1'}-->-sf2->--{sf3|sf3'}-->-sf4->--{sf5}--> exit | | | | +-sf2-+ +-sf4-+ lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray Sent: Thursday, May 29, 2014 12:54 PM To: Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 HaHa, funny man. :) From: Jakob Heitz (jheitz) [mailto:jheitz@cisco.com] Sent: Thursday, May 29, 2014 1:43 PM To: Eric Gray; Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: RE: Figures in draft-quinn-sfc-arch-05 Importance: High You could turn the whole picture right by 90 degrees. If you don't like top to bottom instead of left to right, make a note that = it's in landscape. --Jakob From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray Sent: Thursday, May 29, 2014 8:31 AM To: Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: [sfc] Figures in draft-quinn-sfc-arch-05 Paul/Joel, Pretty sure that Figures 5 and 6 don't actually fit the wid= th expected for an Internet Draft (Figure 5 is more than 80 characters wide and Figure 6 is wi= der still). Depending on how a reader tries to read the draft, this can= turn complicated illustrations into a _real_ fun time. :) Also, I am unsure what the figures are trying to convey wit= h some of "dotted lines" crossing the service functions. If the intent is to show that a ser= vice function is a virtual instance hosted by some network device, perhaps this will be bett= er shown in a separate figure and this aspect of Figures 5 and 6 can be eliminated? I would suggest replacing Figure 5 with a figure along the lines of: source +-----+ +-----+ | +-->| sf2 +--+ +-->| sf4 +--+ | | | | | | | | | | +------+--+ +-----+ +-->+-----+--+ +-----+ +->+-----+ | | sf1 | +-----+ | sf3 | +-----+ | sf5 | +->| +----->| sf2 +----->| |----->| sf4 +---->| |-+ | | | | | | | | | | | +------+--+ +-----+ +-->+-----+--+ +-----+ +->+-----+ | | +-----+ | | +-----+ | | +-->| sf2 +--+ +-->| sf4 +--+ +----+ | | | | | +-----+ +-----+ V destination Figure 5: Load Balancing (67 characters?) Similarly, I would suggest replacing Figure 6 with a figure= along the lines of: source | +-----+-+ +-----+-+ +---+ +-->| sf2 |-|+ +-->| sf4 |-|+ | +---|-->| | || +------>| | || | +------+|---+ +-----+ |+-->+-----+|---+ +-----+ |+-->+-----+ | | sf1 || +-----+ +--->| sf3 || +-----+ +--->| sf5 | +-->| +|------>| sf2 |+---->| ||------>| sf4 |+---->| |--+ | | || +---->| |-+ | || +---->| |-+ | | | | +------+|-|-+ +-----+ |+-->+-----+|-|-+ +-----+ |+-->+-----+ | | | | | +-----+ || | | | +-----+ || | | +------++ | +-->| sf2 |-|+ +-----++ | +-->| sf4 |-|+ +-----+ | | | sf1' | | +-->| | +--->| sf3'| | +-->| | +--->| sf5'| | +-->| +--+ | +-----+----->| |--+ | +-----+----->| |--+ | | | | | | | | | +------+----+ +-----+----+ +-----+ | | +--------+ | V destination Figure 6: Load Balancing and HA (72 characters?) In both cases, the figure has all the same connection compl= exity (fixed up in a few places), but seems to be less busy. -- Eric --_000_4A95BA014132FF49AE685FAB4B9F17F645D290DAdfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    I like the Figures dra= wn by Lucy.

     

    Actually why can’= ;t Figure 5 be simplified as

     

        enter --&g= t;{sf1}-->-{sf2|sf2’|sf2’’}->--{sf3}-->-{sf4|sf4= ’|sf4’’}->--{sf5}--> exit

     

    ??

     

    Linda

     

    From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Lucy yong
    Sent: Thursday, May 29, 2014 1:12 PM
    To: Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq= )
    Cc: sfc@ietf.org
    Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05

     

    For readability on the= se figures, propose:

     

    Figure 5:

         = ;            &n= bsp;   +-sf2-+       +-= sf4-+

         = ;            &n= bsp;   |     |     &= nbsp; |     |

         = ;  enter -->sf1-->-sf2->--sf3-->-sf4->--sf5--> exit<= o:p>

         = ;            &n= bsp;   |     |     &= nbsp; |     |

         = ;            &n= bsp;   +-sf2-+       +-= sf4-+

    Figure 6:

     

         = ;            &n= bsp;       +-sf2-+   &= nbsp;          +-sf4-+=

         = ;            &n= bsp;       |     | &= nbsp;            |&n= bsp;    |

        enter --&g= t;{sf1|sf1'}-->-sf2->--{sf3|sf3'}-->-sf4->--{sf5}--> exit

         = ;            &n= bsp;       |     | &= nbsp;            |&n= bsp;    |

              = ;            &n= bsp;  +-sf2-+        &= nbsp;     +-sf4-+=

     

    lucy=

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray
    Sent: Thursday, May 29, 2014 12:54 PM
    To: Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq)
    Cc: sfc@ietf.org
    Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05

     

    HaHa, funny man. = J

     

    From: Jakob He= itz (jheitz) [mailto:jheitz@cisco.com]
    Sent: Thursday, May 29, 2014 1:43 PM
    To: Eric Gray; Joel Halpern; Paul Quinn (paulq)
    Cc:     sfc@ietf.org
    Subject: RE: Figures in draft-quinn-sfc-arch-05
    Importance: High

     

    You could turn the whole picture right by = 90 degrees.

    If you don’t like top to bottom inst= ead of left to right, make a note that it’s in landscape.<= /span>

     

    --Jakob

     

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray
    Sent: Thursday, May 29, 2014 8:31 AM
    To: Joel Halpern; Paul Quinn (paulq)
    Cc: sfc@ietf.org
    Subject: [sfc] Figures in draft-quinn-sfc-arch-05    <= /p>

     

    Paul/Joel,

     

            &nbs= p;       Pretty sure that Figures 5 and 6 don= ’t actually fit the width expected for an

    Internet Draft (Figure 5 is more than 80 characters = wide and Figure 6 is wider still).

     

            &nbs= p;       Depending on how a reader tries to r= ead the draft, this can turn complicated

    illustrations into a _real_ fun time.  <= span style=3D"font-family:Wingdings"> J

     

            &nbs= p;       Also, I am unsure what the figures a= re trying to convey with some of “dotted

    lines” crossing the service functions.  I= f the intent is to show that a service function is

    a virtual instance hosted by some network device, pe= rhaps this will be better shown

    in a separate figure and this aspect of Figures 5 an= d 6 can be eliminated?

     

    I would suggest replacing= Figure 5 with a figure along the lines of:

     

    source &nbs= p;           +--= ---+           &= nbsp;       +-----+=

      = ;|            +-= ->| sf2 +--+        &nbs= p;   +-->| sf4 +--+

      = ;|            | = ;  |     |  |     &n= bsp;      |   |     = |  |

      = ;|  +------+--+   +-----+  +--&= gt;+-----+--+   +-----+  +->+= -----+

      = ;|  | sf1  |      +-----+ &= nbsp;    | sf3 |      +-----= 3;     | sf5 |

      = ;+->|      +----->| sf2 +-----&g= t;|     |----->| sf4 +---->|   = ;  |-+

      = ;   |      |    &nbs= p; |     |      | &n= bsp;   |      |     = |     |     | |

      = ;   +------+--+   +-----+ = ; +-->+-----+--+   +-----+  += ->+-----+ |

      = ;            &n= bsp;|   +-----+  |     &nbs= p;      |   +-----+  | &nbs= p;        |

      = ;            &n= bsp;+-->| sf2 +--+       =      +-->| sf4 +--+    &n= bsp;+----+

      = ;            &n= bsp;    |     |   &n= bsp;            &nbs= p;  |     |      &nb= sp; |

      = ;            &n= bsp;    +-----+     &n= bsp;            &nbs= p;+-----+        V

      = ;            &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p;     destination

     =

      = ;            &n= bsp;    Figure 5: Load Balancing

     

    (67 characters?)

     

            &nbs= p;       Similarly, I would suggest replacing= Figure 6 with a figure along the

    lines of:

     

       source
         |       &n=
bsp;       +-----+-+ &n=
bsp;            =
;     +-----+-+
     +---+        &nb=
sp;  +-->| sf2 |-|+      &nbs=
p;       +-->| sf4 |-|+=

     |           &#=
43;---|-->|     | ||     &n=
bsp;    +------>|     | ||
     |   +------+|---+   +-----&#=
43; |+-->+-----+|---+   +-----+ |+=
-->+-----+
     |   | sf1  ||      =
 +-----+ +--->| sf3 ||       &=
#43;-----+ +--->| sf5 |
     +-->|      +|------>| sf2=
 |+---->|     ||------>| sf4 |+---->|&=
nbsp;    |--+
     |   |      || +---->|&=
nbsp;    |-+    |    =
 || +---->|     |-+    | =
;    |  |
     |   +------+|-|-+   +-----&#=
43; |+-->+-----+|-|-+   +-----+ |+=
-->+-----+  |
     |           | =
| |   +-----+ ||       =
;   | | |   +-----+ ||    &=
nbsp;       |
     |   +------++ | +-->| sf2 |-|+&=
nbsp;  +-----++ | +-->| sf4 |-|+   &#=
43;-----+  |
     |   | sf1' |  | +-->|   &nb=
sp; | +--->| sf3'|  | +-->|     | &#=
43;--->| sf5'|  |
     +-->|      +--+ | &=
nbsp; +-----+----->|     |--+ | &nb=
sp; +-----+----->|     |--+
         |      | &=
nbsp;  |          &n=
bsp;     |     |    =
|            &n=
bsp;   |     |  |

         +------+----+  &nb=
sp;            =
 +-----+----+        &n=
bsp;       +-----+  |=

    

               =
;             &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;         |=

    

               =
;            &n=
bsp;            =
;            &n=
bsp;            =
; +--------+
    

               =
;            &n=
bsp;            =
;            &n=
bsp;            =
; |
    

               =
;            &n=
bsp;            &nbs=
p;            &=
nbsp;           &nbs=
p;V
    

               =
;            &n=
bsp;            =
;            &n=
bsp;        destination
    

     
    

               =
;         Figure 6: Load Balancing =
and HA
    

     
    

    (72 characters?)
    

     
    

            &nbs=
p;       In both cases, the figure has all th=
e same connection complexity (fixed up in a few
    

    places), but seems to be less busy.
    

     
    

    --
    

    Eric
    --_000_4A95BA014132FF49AE685FAB4B9F17F645D290DAdfweml701chmchi_-- From nobody Thu May 29 14:18:28 2014 Return-Path: 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 26CF11A0228 for ; Thu, 29 May 2014 14:18:27 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 A-OmrGucQYXO for ; Thu, 29 May 2014 14:18:23 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96A7B1A029F for ; Thu, 29 May 2014 14:18:23 -0700 (PDT) X-AuditID: c618062d-f79be6d000006b89-79-538753f338e2 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F3.39.27529.3F357835; Thu, 29 May 2014 17:36:19 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Thu, 29 May 2014 17:18:15 -0400 From: Eric Gray To: Linda Dunbar , Lucy yong , "Jakob Heitz (jheitz)" , Joel Halpern , "Paul Quinn (paulq)" Thread-Topic: Figures in draft-quinn-sfc-arch-05 Thread-Index: Ac97S9R6mfocA+1iTpKXBfVlibSBggAGJh5AAACjtcAAAHRWQAAFiSTQAAC3mqA= Date: Thu, 29 May 2014 21:18:14 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF632AD0AF6@eusaamb107.ericsson.se> References: <48E1A67CB9CA044EADFEAB87D814BFF632AD0443@eusaamb107.ericsson.se> <075DE01702BBC249BE1357EFD20DCFE556E2EC@xmb-aln-x02.cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD07D6@eusaamb107.ericsson.se> <2691CE0099834E4A9C5044EEC662BB9D45389B2C@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645D290DA@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D290DA@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF632AD0AF6eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZXLonXPdzcHuwwasl0hZvNzWyWdxtmchk sfHXIjaL/a+Wslo8ebCV3YHVY8rvjaweLUfesnosWfKTKYA5issmJTUnsyy1SN8ugSvj54Fv LAXbjzBV/F9t38DYMpupi5GTQ0LAROLYsyksELaYxIV769lAbCGBo4wSfQ+Yuxi5gOzljBJr n/wCa2AT0JA4dmctI4gtInCWUeLqSRMQm1lAUeLRrd9gNcIC+hLb2h6zQdQYSDxY3A1V7ydx ovEqmM0ioCpxesFTsBpeAV+JV3cXMEIse8UkcaNtEytIglMgTOLkz06w6xiBrvt+ag0TxDJx iVtP5kN9ICCxZM95ZghbVOLl43+sELaSxMff89m7GDmA6vMl5rzShNglKHFy5hOWCYyis5BM moVQNQtJFUSJjsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KkaO0OLUsN93IYBMjMPqOSbDp 7mDc89LyEKMAB6MSD68Ca3uwEGtiWXFl7iFGaQ4WJXFe7ZtVwUIC6YklqdmpqQWpRfFFpTmp xYcYmTg4pRoYUzZdD5Pmli1NCrz9jy1kUdHhZc8lLp3Y+Xmm+2k3Uf1WCQ81nomfdMVrffg/ Zl9RMbMs15JiO712U9mrhnuGKl4arJ6x3+tPKE16sGzJ0cCYJ6p6jVlNjaq3lU9uu8CQfuR8 QVfQ5s9bAniVnL+WnPfxO8nw3SPEwtHA8kLT9/pH0ouTPhYosRRnJBpqMRcVJwIAR3SNIZ8C AAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/lEhPi1plgre94vtPXo4xjFPiH_c Cc: "sfc@ietf.org" Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 21:18:27 -0000 --_000_48E1A67CB9CA044EADFEAB87D814BFF632AD0AF6eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Linda/Lucy, It's not a beauty contest. There are trade-offs associated= with using any of these approaches. If the authors decide to use Lucy's approach, they will nee= d to add a little bit more text to explain the notation (sf1|sf1' meaning two separate nodes providing the same service function, where packets may be processed by either) - as it is not as intuitive as if separate boxes are used in the= figure. Your suggestion would require even more additional text, as= it is (in effect) applying the same sort of notation recursively - especially if appl= ied to both figures 5 and 6. Either approach would be fine with me, provided the text to= make it clear what these figures mean is provided. For other folks - particularly those who understand things = better if they are clearly explained pictorially - having the need to add extra text = to make the picture itself more understandable may not work that well. I'm personally fine with any of the options discussed so fa= r, and am perfectly happy to let the Editors of the draft make whatever choice they prefer, for whatever reasons they prefer that (or those) choice(s). -- Eric From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Thursday, May 29, 2014 4:49 PM To: Lucy yong; Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (p= aulq) Cc: sfc@ietf.org Subject: RE: Figures in draft-quinn-sfc-arch-05 Importance: High I like the Figures drawn by Lucy. Actually why can't Figure 5 be simplified as enter -->{sf1}-->-{sf2|sf2'|sf2''}->--{sf3}-->-{sf4|sf4'|sf4''}->--{sf5= }--> exit ?? Linda From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong Sent: Thursday, May 29, 2014 1:12 PM To: Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 For readability on these figures, propose: Figure 5: +-sf2-+ +-sf4-+ | | | | enter -->sf1-->-sf2->--sf3-->-sf4->--sf5--> exit | | | | +-sf2-+ +-sf4-+ Figure 6: +-sf2-+ +-sf4-+ | | | | enter -->{sf1|sf1'}-->-sf2->--{sf3|sf3'}-->-sf4->--{sf5}--> exit | | | | +-sf2-+ +-sf4-+ lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray Sent: Thursday, May 29, 2014 12:54 PM To: Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 HaHa, funny man. :) From: Jakob Heitz (jheitz) [mailto:jheitz@cisco.com] Sent: Thursday, May 29, 2014 1:43 PM To: Eric Gray; Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: RE: Figures in draft-quinn-sfc-arch-05 Importance: High You could turn the whole picture right by 90 degrees. If you don't like top to bottom instead of left to right, make a note that = it's in landscape. --Jakob From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray Sent: Thursday, May 29, 2014 8:31 AM To: Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: [sfc] Figures in draft-quinn-sfc-arch-05 Paul/Joel, Pretty sure that Figures 5 and 6 don't actually fit the wid= th expected for an Internet Draft (Figure 5 is more than 80 characters wide and Figure 6 is wi= der still). Depending on how a reader tries to read the draft, this can= turn complicated illustrations into a _real_ fun time. :) Also, I am unsure what the figures are trying to convey wit= h some of "dotted lines" crossing the service functions. If the intent is to show that a ser= vice function is a virtual instance hosted by some network device, perhaps this will be bett= er shown in a separate figure and this aspect of Figures 5 and 6 can be eliminated? I would suggest replacing Figure 5 with a figure along the lines of: source +-----+ +-----+ | +-->| sf2 +--+ +-->| sf4 +--+ | | | | | | | | | | +------+--+ +-----+ +-->+-----+--+ +-----+ +->+-----+ | | sf1 | +-----+ | sf3 | +-----+ | sf5 | +->| +----->| sf2 +----->| |----->| sf4 +---->| |-+ | | | | | | | | | | | +------+--+ +-----+ +-->+-----+--+ +-----+ +->+-----+ | | +-----+ | | +-----+ | | +-->| sf2 +--+ +-->| sf4 +--+ +----+ | | | | | +-----+ +-----+ V destination Figure 5: Load Balancing (67 characters?) Similarly, I would suggest replacing Figure 6 with a figure= along the lines of: source | +-----+-+ +-----+-+ +---+ +-->| sf2 |-|+ +-->| sf4 |-|+ | +---|-->| | || +------>| | || | +------+|---+ +-----+ |+-->+-----+|---+ +-----+ |+-->+-----+ | | sf1 || +-----+ +--->| sf3 || +-----+ +--->| sf5 | +-->| +|------>| sf2 |+---->| ||------>| sf4 |+---->| |--+ | | || +---->| |-+ | || +---->| |-+ | | | | +------+|-|-+ +-----+ |+-->+-----+|-|-+ +-----+ |+-->+-----+ | | | | | +-----+ || | | | +-----+ || | | +------++ | +-->| sf2 |-|+ +-----++ | +-->| sf4 |-|+ +-----+ | | | sf1' | | +-->| | +--->| sf3'| | +-->| | +--->| sf5'| | +-->| +--+ | +-----+----->| |--+ | +-----+----->| |--+ | | | | | | | | | +------+----+ +-----+----+ +-----+ | | +--------+ | V destination Figure 6: Load Balancing and HA (72 characters?) In both cases, the figure has all the same connection compl= exity (fixed up in a few places), but seems to be less busy. -- Eric --_000_48E1A67CB9CA044EADFEAB87D814BFF632AD0AF6eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Linda/Lucy,=

     

       &nbs= p;            ItR= 17;s not a beauty contest.  There are trade-offs associated with using

    any of these approache= s.

     

       &nbs= p;            If the= authors decide to use Lucy’s approach, they will need to add a<= /o:p>

    little bit more text t= o explain the notation (sf1|sf1’ meaning two separate

    nodes providing the sa= me service function, where packets may be processed

    by either) – as = it is not as intuitive as if separate boxes are used in the figure.

     

       &nbs= p;            Your s= uggestion would require even more additional text, as it is (in<= /span>

    effect) applying the s= ame sort of notation recursively – especially if applied

    to both figures 5 and = 6.

     

       &nbs= p;            Either= approach would be fine with me, provided the text to make

    it clear what these fi= gures mean is provided.

     

       &nbs= p;            For ot= her folks – particularly those who understand things better if

    they are clearly expla= ined pictorially – having the need to add extra text to

    make the picture itsel= f more understandable may not work that well.

     

       &nbs= p;            I̵= 7;m personally fine with any of the options discussed so far, and am

    perfectly happy to let= the Editors of the draft make whatever choice they

    prefer, for whatever r= easons they prefer that (or those) choice(s).

     

    --

    Eric=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei.com]
    Sent: Thursday, May 29, 2014 4:49 PM
    To: Lucy yong; Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Q= uinn (paulq)
    Cc: sfc@ietf.org
    Subject: RE: Figures in draft-quinn-sfc-arch-05
    Importance: High

     

    I like the Figures dra= wn by Lucy.

     

    Actually why can’= ;t Figure 5 be simplified as

     

        enter --&g= t;{sf1}-->-{sf2|sf2’|sf2’’}->--{sf3}-->-{sf4|sf4= ’|sf4’’}->--{sf5}--> exit

     

    ??

     

    Linda

     

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong
    Sent: Thursday, May 29, 2014 1:12 PM
    To: Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq= )
    Cc: sfc@ietf.org
    Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05

     

    For readability on the= se figures, propose:

     

    Figure 5:

         = ;            &n= bsp;   +-sf2-+       +-= sf4-+

         = ;            &n= bsp;   |     |     &= nbsp; |     |

         = ;  enter -->sf1-->-sf2->--sf3-->-sf4->--sf5--> exit<= o:p>

         = ;            &n= bsp;   |     |     &= nbsp; |     |

         = ;            &n= bsp;   +-sf2-+       +-= sf4-+

    Figure 6:

     

         = ;            &n= bsp;       +-sf2-+   &= nbsp;          +-sf4-+=

         = ;            &n= bsp;       |     | &= nbsp;            |&n= bsp;    |

        enter --&g= t;{sf1|sf1'}-->-sf2->--{sf3|sf3'}-->-sf4->--{sf5}--> exit

         = ;            &n= bsp;       |     | &= nbsp;            |&n= bsp;    |

              = ;            &n= bsp;  +-sf2-+        &= nbsp;     +-sf4-+=

     

    lucy=

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray
    Sent: Thursday, May 29, 2014 12:54 PM
    To: Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq)
    Cc: sfc@ietf.org
    Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05

     

    HaHa, funny man. = J

     

    From: Jakob He= itz (jheitz) [mailto:jheitz@cisco.com]
    Sent: Thursday, May 29, 2014 1:43 PM
    To: Eric Gray; Joel Halpern; Paul Quinn (paulq)
    Cc:     sfc@ietf.org
    Subject: RE: Figures in draft-quinn-sfc-arch-05
    Importance: High

     

    You could turn the whole picture right by = 90 degrees.

    If you don’t like top to bottom inst= ead of left to right, make a note that it’s in landscape.<= /span>

     

    --Jakob

     

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray
    Sent: Thursday, May 29, 2014 8:31 AM
    To: Joel Halpern; Paul Quinn (paulq)
    Cc: sfc@ietf.org
    Subject: [sfc] Figures in draft-quinn-sfc-arch-05    <= /p>

     

    Paul/Joel,

     

            &nbs= p;       Pretty sure that Figures 5 and 6 don= ’t actually fit the width expected for an

    Internet Draft (Figure 5 is more than 80 characters = wide and Figure 6 is wider still).

     

            &nbs= p;       Depending on how a reader tries to r= ead the draft, this can turn complicated

    illustrations into a _real_ fun time.  <= span style=3D"font-family:Wingdings"> J

     

            &nbs= p;       Also, I am unsure what the figures a= re trying to convey with some of “dotted

    lines” crossing the service functions.  I= f the intent is to show that a service function is

    a virtual instance hosted by some network device, pe= rhaps this will be better shown

    in a separate figure and this aspect of Figures 5 an= d 6 can be eliminated?

     

    I would suggest replacing= Figure 5 with a figure along the lines of:

     

    source &nbs= p;           +--= ---+           &= nbsp;       +-----+=

      = ;|            +-= ->| sf2 +--+        &nbs= p;   +-->| sf4 +--+

      = ;|            | = ;  |     |  |     &n= bsp;      |   |     = |  |

      = ;|  +------+--+   +-----+  +--&= gt;+-----+--+   +-----+  +->+= -----+

      = ;|  | sf1  |      +-----+ &= nbsp;    | sf3 |      +-----= 3;     | sf5 |

      = ;+->|      +----->| sf2 +-----&g= t;|     |----->| sf4 +---->|   = ;  |-+

      = ;   |      |    &nbs= p; |     |      | &n= bsp;   |      |     = |     |     | |

      = ;   +------+--+   +-----+ = ; +-->+-----+--+   +-----+  += ->+-----+ |

      = ;            &n= bsp;|   +-----+  |     &nbs= p;      |   +-----+  | &nbs= p;        |

      = ;            &n= bsp;+-->| sf2 +--+       =      +-->| sf4 +--+    &n= bsp;+----+

      = ;            &n= bsp;    |     |   &n= bsp;            &nbs= p;  |     |      &nb= sp; |

      = ;            &n= bsp;    +-----+     &n= bsp;            &nbs= p;+-----+        V

      = ;            &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p;     destination

     =

      = ;            &n= bsp;    Figure 5: Load Balancing

     

    (67 characters?)

     

            &nbs= p;       Similarly, I would suggest replacing= Figure 6 with a figure along the

    lines of:

     

       source
         |       &n=
bsp;       +-----+-+ &n=
bsp;            =
;     +-----+-+
     +---+        &nb=
sp;  +-->| sf2 |-|+      &nbs=
p;       +-->| sf4 |-|+=

     |           &#=
43;---|-->|     | ||     &n=
bsp;    +------>|     | ||
     |   +------+|---+   +-----&#=
43; |+-->+-----+|---+   +-----+ |+=
-->+-----+
     |   | sf1  ||      =
 +-----+ +--->| sf3 ||       &=
#43;-----+ +--->| sf5 |
     +-->|      +|------>| sf2=
 |+---->|     ||------>| sf4 |+---->|&=
nbsp;    |--+
     |   |      || +---->|&=
nbsp;    |-+    |    =
 || +---->|     |-+    | =
;    |  |
     |   +------+|-|-+   +-----&#=
43; |+-->+-----+|-|-+   +-----+ |+=
-->+-----+  |
     |           | =
| |   +-----+ ||       =
;   | | |   +-----+ ||    &=
nbsp;       |
     |   +------++ | +-->| sf2 |-|+&=
nbsp;  +-----++ | +-->| sf4 |-|+   &#=
43;-----+  |
     |   | sf1' |  | +-->|   &nb=
sp; | +--->| sf3'|  | +-->|     | &#=
43;--->| sf5'|  |
     +-->|      +--+ | &=
nbsp; +-----+----->|     |--+ | &nb=
sp; +-----+----->|     |--+
         |      | &=
nbsp;  |          &n=
bsp;     |     |    =
|            &n=
bsp;   |     |  |

         +------+----+  &nb=
sp;            =
 +-----+----+        &n=
bsp;       +-----+  |=

    

               =
;             &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;         |=

    

               =
;            &n=
bsp;            =
;            &n=
bsp;            =
; +--------+
    

               =
;            &n=
bsp;            =
;            &n=
bsp;            =
; |
    

               =
;            &n=
bsp;            &nbs=
p;            &=
nbsp;           &nbs=
p;V
    

               =
;            &n=
bsp;            =
;            &n=
bsp;        destination
    

     
    

               =
;         Figure 6: Load Balancing =
and HA
    

     
    

    (72 characters?)
    

     
    

            &nbs=
p;       In both cases, the figure has all th=
e same connection complexity (fixed up in a few
    

    places), but seems to be less busy.
    

     
    

    --
    

    Eric
    --_000_48E1A67CB9CA044EADFEAB87D814BFF632AD0AF6eusaamb107erics_-- From nobody Thu May 29 14:23:39 2014 Return-Path: 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 DD8D81A08FF for ; Thu, 29 May 2014 14:23:31 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 wXGkiTvQVf-0 for ; Thu, 29 May 2014 14:23:28 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D7911A08AE for ; Thu, 29 May 2014 14:23:28 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-cd-538752b45801 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 16.D5.11744.4B257835; Thu, 29 May 2014 17:31:01 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Thu, 29 May 2014 17:23:23 -0400 From: Eric Gray To: Linda Dunbar , Lucy yong , "Jakob Heitz (jheitz)" , Joel Halpern , "Paul Quinn (paulq)" Thread-Topic: Figures in draft-quinn-sfc-arch-05 Thread-Index: Ac97S9R6mfocA+1iTpKXBfVlibSBggAGJh5AAACjtcAAAHRWQAAFiSTQAAEryZA= Date: Thu, 29 May 2014 21:23:21 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF632AD0B1B@eusaamb107.ericsson.se> References: <48E1A67CB9CA044EADFEAB87D814BFF632AD0443@eusaamb107.ericsson.se> <075DE01702BBC249BE1357EFD20DCFE556E2EC@xmb-aln-x02.cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD07D6@eusaamb107.ericsson.se> <2691CE0099834E4A9C5044EEC662BB9D45389B2C@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645D290DA@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D290DA@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF632AD0B1Beusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZXLrHW3drUHuwwfWDnBZvNzWyWdxtmchk sfHXIjaL/a+Wslo8ebCV3YHVY8rvjaweLUfesnosWfKTKYA5issmJTUnsyy1SN8ugSvjcr9N wbGVTBVzLr9ibmB818zUxcjJISFgIvGi8SYbhC0mceHeeiCbi0NI4CijxJa7k9khnOWMEsvX 72EFqWIT0JA4dmctI4gtInCWUeLqSRMQm1lAUeLRrd9gU4UF9CW2tT1mg6gxkHiwuBuq3k9i 4ZklYDaLgKrEqc4+sJm8Ar4SM/oXskIse8UkcaNtE1iCUyBM4uTPThYQmxHovO+n1jBBLBOX uPVkPtQLAhJL9pxnhrBFJV4+/scKYStJfPw9nx2iPl+ip/MsI8QyQYmTM5+wTGAUnYVk1Cwk ZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZVjBylxalluelGhpsYgTF4TILNcQfj gk+WhxgFOBiVeHgVWNuDhVgTy4orcw8xSnOwKInz7rlWFSwkkJ5YkpqdmlqQWhRfVJqTWnyI kYmDU6qBMf3aTc8lrc4CM2Rd3ebIpwly3Tyb+y0lPGlp2q0n6xb1cxdeWuPaWLXhwJKLmSbn 7ftLgi/8l7+WraDm7nHm3bYpar82xn30NdudNe9TYeMhXguBUnOn//9W3gs32qNo/0qlISyX o+7CdC3Wpp3LUjk7PwRsqGG5I6DKbaUmXC3Rl+2m3bRTiaU4I9FQi7moOBEAZXIzjKICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/8NaeB0sHkPsAytlnk1WAgfQ0qsI Cc: "sfc@ietf.org" Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 21:23:32 -0000 --_000_48E1A67CB9CA044EADFEAB87D814BFF632AD0B1Beusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Linda, By the way, your proposal for Figure 5 would require a column width of at l= east 80 characters (more than you are supposed to have in an ID), and the situation= would be worse if it were applied to figure 6. For figure 5, you can improve the width slightly by fixing up a few of your= arrows, and even more by wrapping the figure. Wrapping might detract from simplic= ity, however. -- Eric From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Thursday, May 29, 2014 4:49 PM To: Lucy yong; Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (p= aulq) Cc: sfc@ietf.org Subject: RE: Figures in draft-quinn-sfc-arch-05 Importance: High I like the Figures drawn by Lucy. Actually why can't Figure 5 be simplified as enter -->{sf1}-->-{sf2|sf2'|sf2''}->--{sf3}-->-{sf4|sf4'|sf4''}->--{sf5= }--> exit ?? Linda From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong Sent: Thursday, May 29, 2014 1:12 PM To: Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 For readability on these figures, propose: Figure 5: +-sf2-+ +-sf4-+ | | | | enter -->sf1-->-sf2->--sf3-->-sf4->--sf5--> exit | | | | +-sf2-+ +-sf4-+ Figure 6: +-sf2-+ +-sf4-+ | | | | enter -->{sf1|sf1'}-->-sf2->--{sf3|sf3'}-->-sf4->--{sf5}--> exit | | | | +-sf2-+ +-sf4-+ lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray Sent: Thursday, May 29, 2014 12:54 PM To: Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 HaHa, funny man. :) From: Jakob Heitz (jheitz) [mailto:jheitz@cisco.com] Sent: Thursday, May 29, 2014 1:43 PM To: Eric Gray; Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: RE: Figures in draft-quinn-sfc-arch-05 Importance: High You could turn the whole picture right by 90 degrees. If you don't like top to bottom instead of left to right, make a note that = it's in landscape. --Jakob From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray Sent: Thursday, May 29, 2014 8:31 AM To: Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: [sfc] Figures in draft-quinn-sfc-arch-05 Paul/Joel, Pretty sure that Figures 5 and 6 don't actually fit the wid= th expected for an Internet Draft (Figure 5 is more than 80 characters wide and Figure 6 is wi= der still). Depending on how a reader tries to read the draft, this can= turn complicated illustrations into a _real_ fun time. :) Also, I am unsure what the figures are trying to convey wit= h some of "dotted lines" crossing the service functions. If the intent is to show that a ser= vice function is a virtual instance hosted by some network device, perhaps this will be bett= er shown in a separate figure and this aspect of Figures 5 and 6 can be eliminated? I would suggest replacing Figure 5 with a figure along the lines of: source +-----+ +-----+ | +-->| sf2 +--+ +-->| sf4 +--+ | | | | | | | | | | +------+--+ +-----+ +-->+-----+--+ +-----+ +->+-----+ | | sf1 | +-----+ | sf3 | +-----+ | sf5 | +->| +----->| sf2 +----->| |----->| sf4 +---->| |-+ | | | | | | | | | | | +------+--+ +-----+ +-->+-----+--+ +-----+ +->+-----+ | | +-----+ | | +-----+ | | +-->| sf2 +--+ +-->| sf4 +--+ +----+ | | | | | +-----+ +-----+ V destination Figure 5: Load Balancing (67 characters?) Similarly, I would suggest replacing Figure 6 with a figure= along the lines of: source | +-----+-+ +-----+-+ +---+ +-->| sf2 |-|+ +-->| sf4 |-|+ | +---|-->| | || +------>| | || | +------+|---+ +-----+ |+-->+-----+|---+ +-----+ |+-->+-----+ | | sf1 || +-----+ +--->| sf3 || +-----+ +--->| sf5 | +-->| +|------>| sf2 |+---->| ||------>| sf4 |+---->| |--+ | | || +---->| |-+ | || +---->| |-+ | | | | +------+|-|-+ +-----+ |+-->+-----+|-|-+ +-----+ |+-->+-----+ | | | | | +-----+ || | | | +-----+ || | | +------++ | +-->| sf2 |-|+ +-----++ | +-->| sf4 |-|+ +-----+ | | | sf1' | | +-->| | +--->| sf3'| | +-->| | +--->| sf5'| | +-->| +--+ | +-----+----->| |--+ | +-----+----->| |--+ | | | | | | | | | +------+----+ +-----+----+ +-----+ | | +--------+ | V destination Figure 6: Load Balancing and HA (72 characters?) In both cases, the figure has all the same connection compl= exity (fixed up in a few places), but seems to be less busy. -- Eric --_000_48E1A67CB9CA044EADFEAB87D814BFF632AD0B1Beusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Linda,

     

    By the way, your propo= sal for Figure 5 would require a column width of at least 80

    characters (more than = you are supposed to have in an ID), and the situation would

    be worse if it were ap= plied to figure 6.

     

    For figure 5, you can = improve the width slightly by fixing up a few of your arrows,

    and even more by wrapp= ing the figure.  Wrapping  might detract from simplicity,

    however.

     

    --

    Eric=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei.com]
    Sent: Thursday, May 29, 2014 4:49 PM
    To: Lucy yong; Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Q= uinn (paulq)
    Cc: sfc@ietf.org
    Subject: RE: Figures in draft-quinn-sfc-arch-05
    Importance: High

     

    I like the Figures dra= wn by Lucy.

     

    Actually why can’= ;t Figure 5 be simplified as

     

        enter --&g= t;{sf1}-->-{sf2|sf2’|sf2’’}->--{sf3}-->-{sf4|sf4= ’|sf4’’}->--{sf5}--> exit

     

    ??

     

    Linda

     

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong
    Sent: Thursday, May 29, 2014 1:12 PM
    To: Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq= )
    Cc: sfc@ietf.org
    Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05

     

    For readability on the= se figures, propose:

     

    Figure 5:

         = ;            &n= bsp;   +-sf2-+       +-= sf4-+

         = ;            &n= bsp;   |     |     &= nbsp; |     |

         = ;  enter -->sf1-->-sf2->--sf3-->-sf4->--sf5--> exit<= o:p>

         = ;            &n= bsp;   |     |     &= nbsp; |     |

         = ;            &n= bsp;   +-sf2-+       +-= sf4-+

    Figure 6:

     

         = ;            &n= bsp;       +-sf2-+   &= nbsp;          +-sf4-+=

         = ;            &n= bsp;       |     | &= nbsp;            |&n= bsp;    |

        enter --&g= t;{sf1|sf1'}-->-sf2->--{sf3|sf3'}-->-sf4->--{sf5}--> exit

         = ;            &n= bsp;       |     | &= nbsp;            |&n= bsp;    |

              = ;            &n= bsp;  +-sf2-+        &= nbsp;     +-sf4-+=

     

    lucy=

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray
    Sent: Thursday, May 29, 2014 12:54 PM
    To: Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq)
    Cc: sfc@ietf.org
    Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05

     

    HaHa, funny man. = J

     

    From: Jakob He= itz (jheitz) [mailto:jheitz@cisco.com]
    Sent: Thursday, May 29, 2014 1:43 PM
    To: Eric Gray; Joel Halpern; Paul Quinn (paulq)
    Cc:     sfc@ietf.org
    Subject: RE: Figures in draft-quinn-sfc-arch-05
    Importance: High

     

    You could turn the whole picture right by = 90 degrees.

    If you don’t like top to bottom inst= ead of left to right, make a note that it’s in landscape.<= /span>

     

    --Jakob

     

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray
    Sent: Thursday, May 29, 2014 8:31 AM
    To: Joel Halpern; Paul Quinn (paulq)
    Cc: sfc@ietf.org
    Subject: [sfc] Figures in draft-quinn-sfc-arch-05    <= /p>

     

    Paul/Joel,

     

            &nbs= p;       Pretty sure that Figures 5 and 6 don= ’t actually fit the width expected for an

    Internet Draft (Figure 5 is more than 80 characters = wide and Figure 6 is wider still).

     

            &nbs= p;       Depending on how a reader tries to r= ead the draft, this can turn complicated

    illustrations into a _real_ fun time.  <= span style=3D"font-family:Wingdings"> J

     

            &nbs= p;       Also, I am unsure what the figures a= re trying to convey with some of “dotted

    lines” crossing the service functions.  I= f the intent is to show that a service function is

    a virtual instance hosted by some network device, pe= rhaps this will be better shown

    in a separate figure and this aspect of Figures 5 an= d 6 can be eliminated?

     

    I would suggest replacing= Figure 5 with a figure along the lines of:

     

    source &nbs= p;           +--= ---+           &= nbsp;       +-----+=

      = ;|            +-= ->| sf2 +--+        &nbs= p;   +-->| sf4 +--+

      = ;|            | = ;  |     |  |     &n= bsp;      |   |     = |  |

      = ;|  +------+--+   +-----+  +--&= gt;+-----+--+   +-----+  +->+= -----+

      = ;|  | sf1  |      +-----+ &= nbsp;    | sf3 |      +-----= 3;     | sf5 |

      = ;+->|      +----->| sf2 +-----&g= t;|     |----->| sf4 +---->|   = ;  |-+

      = ;   |      |    &nbs= p; |     |      | &n= bsp;   |      |     = |     |     | |

      = ;   +------+--+   +-----+ = ; +-->+-----+--+   +-----+  += ->+-----+ |

      = ;            &n= bsp;|   +-----+  |     &nbs= p;      |   +-----+  | &nbs= p;        |

      = ;            &n= bsp;+-->| sf2 +--+       =      +-->| sf4 +--+    &n= bsp;+----+

      = ;            &n= bsp;    |     |   &n= bsp;            &nbs= p;  |     |      &nb= sp; |

      = ;            &n= bsp;    +-----+     &n= bsp;            &nbs= p;+-----+        V

      = ;            &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p;     destination

     =

      = ;            &n= bsp;    Figure 5: Load Balancing

     

    (67 characters?)

     

            &nbs= p;       Similarly, I would suggest replacing= Figure 6 with a figure along the

    lines of:

     

       source
         |       &n=
bsp;       +-----+-+ &n=
bsp;            =
;     +-----+-+
     +---+        &nb=
sp;  +-->| sf2 |-|+      &nbs=
p;       +-->| sf4 |-|+=

     |           &#=
43;---|-->|     | ||     &n=
bsp;    +------>|     | ||
     |   +------+|---+   +-----&#=
43; |+-->+-----+|---+   +-----+ |+=
-->+-----+
     |   | sf1  ||      =
 +-----+ +--->| sf3 ||       &=
#43;-----+ +--->| sf5 |
     +-->|      +|------>| sf2=
 |+---->|     ||------>| sf4 |+---->|&=
nbsp;    |--+
     |   |      || +---->|&=
nbsp;    |-+    |    =
 || +---->|     |-+    | =
;    |  |
     |   +------+|-|-+   +-----&#=
43; |+-->+-----+|-|-+   +-----+ |+=
-->+-----+  |
     |           | =
| |   +-----+ ||       =
;   | | |   +-----+ ||    &=
nbsp;       |
     |   +------++ | +-->| sf2 |-|+&=
nbsp;  +-----++ | +-->| sf4 |-|+   &#=
43;-----+  |
     |   | sf1' |  | +-->|   &nb=
sp; | +--->| sf3'|  | +-->|     | &#=
43;--->| sf5'|  |
     +-->|      +--+ | &=
nbsp; +-----+----->|     |--+ | &nb=
sp; +-----+----->|     |--+
         |      | &=
nbsp;  |          &n=
bsp;     |     |    =
|            &n=
bsp;   |     |  |

         +------+----+  &nb=
sp;            =
 +-----+----+        &n=
bsp;       +-----+  |=

    

               =
;             &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;         |=

    

               =
;            &n=
bsp;            =
;            &n=
bsp;            =
; +--------+
    

               =
;            &n=
bsp;            =
;            &n=
bsp;            =
; |
    

               =
;            &n=
bsp;            &nbs=
p;            &=
nbsp;           &nbs=
p;V
    

               =
;            &n=
bsp;            =
;            &n=
bsp;        destination
    

     
    

               =
;         Figure 6: Load Balancing =
and HA
    

     
    

    (72 characters?)
    

     
    

            &nbs=
p;       In both cases, the figure has all th=
e same connection complexity (fixed up in a few
    

    places), but seems to be less busy.
    

     
    

    --
    

    Eric
    --_000_48E1A67CB9CA044EADFEAB87D814BFF632AD0B1Beusaamb107erics_-- From nobody Thu May 29 14:32:59 2014 Return-Path: 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 B85C71A02CE for ; Thu, 29 May 2014 14:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 cWgVyvjA1Uwi for ; Thu, 29 May 2014 14:32:56 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA1791A0262 for ; Thu, 29 May 2014 14:32:56 -0700 (PDT) Received: by mail-yk0-f182.google.com with SMTP id 9so803009ykp.13 for ; Thu, 29 May 2014 14:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CJXUfQXqBCnwGYxCWT/HkEO4Gm28hZ3pSMjYCKV8QcM=; b=wlw2CXPwy5O0pbjFYkoLLtnkTupiieXhDDEBLc7wM9USBS1ufT7Q0zba3/e2hySJQe eyRjw9hSi9rRjmNO5N5nTqW8cgZjGX9gAPrTzoNARsXNOhe9TTVNVuM0nwQwmuG9trn3 rPnIsTvs1Mc27Zaorz8+rGmiGbZzGeTseG4pY0tYofAeubb4cFJkDlrsUKSMTSD7fEvO Bp1LpEOlesiXekOshrLHJXYzthAJmvbGb12fnibG6VxClDP2S5CqRLR1jnQP4+TNBIZy nVmMX4X654u+Op40kOoMoavkMOEk3GJ5ZXw1biczVYWVN+1x/QKl2TCePLhaNg3psKmq UFzQ== X-Received: by 10.236.137.198 with SMTP id y46mr13945788yhi.31.1401399172372; Thu, 29 May 2014 14:32:52 -0700 (PDT) Received: from [192.168.1.109] (108-214-96-27.lightspeed.sntcca.sbcglobal.net. [108.214.96.27]) by mx.google.com with ESMTPSA id m50sm2827525yha.8.2014.05.29.14.32.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 14:32:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Sharon X-Mailer: iPad Mail (11D201) In-Reply-To: <53878F04.40909@joelhalpern.com> Date: Thu, 29 May 2014 14:32:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> <53878F04.40909@joelhalpern.com> To: Joel Halpern Direct Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/w431AAxylu-Nw9kEO7Hbkyb6dkA Cc: "Joel M. Halpern" , "Paul Quinn \(paulq\)" , "Ken Gray \(kegray\)" , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 21:32:58 -0000 Yes, I guess you are right Joel. I assumed load-balancing inherently has classification ability. Otherwise the chain hop is statically circuited, no HA/LB. --szb > On May 29, 2014, at 12:48, Joel Halpern Direct wrote: >=20 > I am not at all sure I am following your diagram. > An SFF is concerned with forwarding packets to (and handling packets from)= its attached SFs. If you want the SFF to also affect downstream processing= , for example by changing the service path the packet is on, then you need a= classifier co-located with the SFF. >=20 > Yours, > Joel >=20 >> On 5/29/14, 12:09 PM, Sharon wrote: >> "the SFF nodes to which the multiple instances of SF2 or SF4 are attached= " >>=20 >> Can't the SFF node make a load balancing decision on instances not >> attached to it? >> In which case "the SFF node" is enough >>=20 >> Location A Location= B >> Functions - SFF/NVE - Underlay - NVE/SFF - Functions >>=20 >> The load balancing KPI decisions (and the invariant that keeps states >> consistent) >> May be known in Location A for SFs in location B where A/B are different >> racks or goes. >> KPIs that are factored in can include both those of the Underlay network >> and the chain. >>=20 >> --szb >>=20 >> On May 28, 2014, at 14:49, Linda Dunbar > > wrote: >>=20 >>> Joel, Eric, and Ken, >>>=20 >>> Thank you very much for the explanation. >>>=20 >>> Based on what you said, the description on how =E2=80=9Ccontrol entity p= ush >>> to the sf1 nodes =E2=80=A6=E2=80=9D should be removed from the text, spe= cifically: >>>=20 >>> =E2=80=9CIn this >>>=20 >>> case, the control entity will push to the sf1 nodes, a table of >>>=20 >>> sorts:[L1] <#_msocom_1> sf2 with a series of next hops, and if >>> needed some weighted or >>>=20 >>> other metrics (these could also be decided locally by some policy, >>>=20 >>> but sf1 would need to be aware of expand/contract triggers and >>>=20 >>> actions).=E2=80=9D >>>=20 >>> Should also change the sentence after the Figure 5 to >>>=20 >>> =E2=80=9CEither through an imbedded action in sf1 and sf3, the SFF nodes= to >>> which the multiple instances of SF2 or SF4 are attached, or through >>> external >>>=20 >>> control, the service functions sf2 and sf4 are elastically expanded >>>=20 >>> and contracted dynamically.=E2=80=9D >>>=20 >>> Linda >>>=20 >>> *From:*Ken Gray (kegray) [mailto:kegray@cisco.com] >>> *Sent:* Wednesday, May 28, 2014 4:24 PM >>> *To:* Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern >>> *Cc:* sfc@ietf.org >>> *Subject:* Re: [sfc] questions of "load balancing considerations" in >>> the draft-quinn-sfc-arch-05 >>>=20 >>> +1 to Joel =E2=80=A6 the picture would be ugly at best. We attempted a >>> generic HA/LB slide to make a point and even it was ugly =E2=80=A6such a= re the >>> limitations of ASCII art. >>>=20 >>> In line =E2=80=A6 >>>=20 >>> *From: *Linda Dunbar >> > >>> *Date: *Wednesday, May 28, 2014 3:34 PM >>> *To: *"Paul Quinn (paulq)" >, >>> "Joel M. Halpern" > >>> *Cc: *"sfc@ietf.org " >> > >>> *Subject: *[sfc] questions of "load balancing considerations" in the >>> draft-quinn-sfc-arch-05 >>>=20 >>> Paul and Joel, >>>=20 >>> Does the Load Balancing Figure 5 (of draft-quinn-sfc-arch-05) assume >>> that SF1 is responsible for balancing traffic among the 3 instances of >>> SF2, and SF3 is responsible for balancing traffic among the 3 >>> instances of SF4? >>>=20 >>> Document text below the picture says "Either through an imbedded >>> action in sf1 and sf3, or through external >>>=20 >>> control, the service functions sf2 and sf4 are elastically >>> expanded and contracted dynamically." >>>=20 >>> Isn=E2=80=99t it a single point of failure? >>>=20 >>> Document text immediately subsequent to that picture and >>> paragraph illustrates HA scenarios. >>>=20 >>> Some service functions are Stateful, i.e. they may require packets >>> from same flows to traverse the same service function instance. For >>> the Load Balancing scheme described by Figure 5, do you assume that >>> SF1 and SF3 will be responsible for making sure that same flows go >>> through the same service function instance? >>>=20 >>> Again, the aforementioned text deliberately allows this >>> responsibility to be either imbedded in the elasticity-causing >>> function or to be controlled externally or centrally. We don't get >>> into the mechanics as these can vary. While stateful/bidirectional >>> does add an additional burden, it can be accommodated without an >>> explosion of discrete chains. For example, it could be handled "at >>> allocation time" if elasticity is managed via a separate entity and >>> the individual allocations reflected through service chain control in >>> the initial metadata bound to at the classification point in either >>> direction. OR, if the devices are working as a paired system (single >>> vendor or ecosystem) with integrated elasticity, they could pass >>> metadata between them when sf1 or sf3 does the initial dynamic >>> allocation (affecting local forwarding on it's partner). That's >>> probably not an exhaustive list of ways to solve the problem. 8^) >>>=20 >>> The point of this section was that elasticity and HA should not >>> cause an inordinate explosion of discrete chains without recommending >>> a particular solution. That is, you shouldn't create unnecessary >>> complexity where it doesn't need to exist. >>>=20 >>> For the stateful service functions, if a flow is switched from >>> SF-Instance-X to SF-Instance-Y, the SF-Instance-Y needs to synchronize >>> the states from SF-Instance-X. Who is responsible for those states >>> maintenance for the Load Balancing described in Figure 5? >>>=20 >>> None of those entities exist in Figure 5. Can you re-phrase >>> your question from the figure? >>>=20 >>> Linda >>>=20 >>> ------------------------------------------------------------------------= >>>=20 >>> [L1] <#_msoanchor_1>Require pushing policies to SF1 on how to load >>> balance multiple instances of SF2. >>>=20 >>> SF1 may not have the capability to balance among multiple instances of >>> SF2 >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc From nobody Thu May 29 14:42:33 2014 Return-Path: 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 DDC211A0676 for ; Thu, 29 May 2014 14:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 RLYcmttL95y4 for ; Thu, 29 May 2014 14:42:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA2AC1A0246 for ; Thu, 29 May 2014 14:42:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BER47985; Thu, 29 May 2014 21:42:18 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 22:41:42 +0100 Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 22:42:17 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml706-chm.china.huawei.com ([169.254.8.4]) with mapi id 14.03.0158.001; Thu, 29 May 2014 14:42:07 -0700 From: Linda Dunbar To: Eric Gray , Lucy yong , "Jakob Heitz (jheitz)" , Joel Halpern , "Paul Quinn (paulq)" Thread-Topic: Figures in draft-quinn-sfc-arch-05 Thread-Index: Ac97S9R6mfocA+1iTpKXBfVlibSBggAGJh5AAACjtcAAAHRWQAAFiSTQAAEryZAAAFNDAA== Date: Thu, 29 May 2014 21:42:07 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D29193@dfweml701-chm.china.huawei.com> References: <48E1A67CB9CA044EADFEAB87D814BFF632AD0443@eusaamb107.ericsson.se> <075DE01702BBC249BE1357EFD20DCFE556E2EC@xmb-aln-x02.cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD07D6@eusaamb107.ericsson.se> <2691CE0099834E4A9C5044EEC662BB9D45389B2C@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645D290DA@dfweml701-chm.china.huawei.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD0B1B@eusaamb107.ericsson.se> In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF632AD0B1B@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.251] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D29193dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/mCCxkOW0e6BK9e-opkIkvEVABwU Cc: "sfc@ietf.org" Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 21:42:29 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645D29193dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eric, How about this shorter one? ->{sf1}->{sf2|sf2'|sf2''}->{sf3}->{sf4|sf4'|sf4''}->{sf5}-> The intent is pretty simple: If a service function on a chain has multiple = instances, one of the service function's instances is selected to treat pac= kets belonging to the service chain. This is a correct mathematics expression. There is really no need draw all those boxes. Linda From: Eric Gray [mailto:eric.gray@ericsson.com] Sent: Thursday, May 29, 2014 4:23 PM To: Linda Dunbar; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn= (paulq) Cc: sfc@ietf.org Subject: RE: Figures in draft-quinn-sfc-arch-05 Linda, By the way, your proposal for Figure 5 would require a column width of at l= east 80 characters (more than you are supposed to have in an ID), and the situation= would be worse if it were applied to figure 6. For figure 5, you can improve the width slightly by fixing up a few of your= arrows, and even more by wrapping the figure. Wrapping might detract from simplic= ity, however. -- Eric From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Thursday, May 29, 2014 4:49 PM To: Lucy yong; Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (p= aulq) Cc: sfc@ietf.org Subject: RE: Figures in draft-quinn-sfc-arch-05 Importance: High I like the Figures drawn by Lucy. Actually why can't Figure 5 be simplified as enter -->{sf1}-->-{sf2|sf2'|sf2''}->--{sf3}-->-{sf4|sf4'|sf4''}->--{sf5= }--> exit ?? Linda From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong Sent: Thursday, May 29, 2014 1:12 PM To: Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 For readability on these figures, propose: Figure 5: +-sf2-+ +-sf4-+ | | | | enter -->sf1-->-sf2->--sf3-->-sf4->--sf5--> exit | | | | +-sf2-+ +-sf4-+ Figure 6: +-sf2-+ +-sf4-+ | | | | enter -->{sf1|sf1'}-->-sf2->--{sf3|sf3'}-->-sf4->--{sf5}--> exit | | | | +-sf2-+ +-sf4-+ lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray Sent: Thursday, May 29, 2014 12:54 PM To: Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 HaHa, funny man. :) From: Jakob Heitz (jheitz) [mailto:jheitz@cisco.com] Sent: Thursday, May 29, 2014 1:43 PM To: Eric Gray; Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: RE: Figures in draft-quinn-sfc-arch-05 Importance: High You could turn the whole picture right by 90 degrees. If you don't like top to bottom instead of left to right, make a note that = it's in landscape. --Jakob From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray Sent: Thursday, May 29, 2014 8:31 AM To: Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: [sfc] Figures in draft-quinn-sfc-arch-05 Paul/Joel, Pretty sure that Figures 5 and 6 don't actually fit the wid= th expected for an Internet Draft (Figure 5 is more than 80 characters wide and Figure 6 is wi= der still). Depending on how a reader tries to read the draft, this can= turn complicated illustrations into a _real_ fun time. :) Also, I am unsure what the figures are trying to convey wit= h some of "dotted lines" crossing the service functions. If the intent is to show that a ser= vice function is a virtual instance hosted by some network device, perhaps this will be bett= er shown in a separate figure and this aspect of Figures 5 and 6 can be eliminated? I would suggest replacing Figure 5 with a figure along the lines of: source +-----+ +-----+ | +-->| sf2 +--+ +-->| sf4 +--+ | | | | | | | | | | +------+--+ +-----+ +-->+-----+--+ +-----+ +->+-----+ | | sf1 | +-----+ | sf3 | +-----+ | sf5 | +->| +----->| sf2 +----->| |----->| sf4 +---->| |-+ | | | | | | | | | | | +------+--+ +-----+ +-->+-----+--+ +-----+ +->+-----+ | | +-----+ | | +-----+ | | +-->| sf2 +--+ +-->| sf4 +--+ +----+ | | | | | +-----+ +-----+ V destination Figure 5: Load Balancing (67 characters?) Similarly, I would suggest replacing Figure 6 with a figure= along the lines of: source | +-----+-+ +-----+-+ +---+ +-->| sf2 |-|+ +-->| sf4 |-|+ | +---|-->| | || +------>| | || | +------+|---+ +-----+ |+-->+-----+|---+ +-----+ |+-->+-----+ | | sf1 || +-----+ +--->| sf3 || +-----+ +--->| sf5 | +-->| +|------>| sf2 |+---->| ||------>| sf4 |+---->| |--+ | | || +---->| |-+ | || +---->| |-+ | | | | +------+|-|-+ +-----+ |+-->+-----+|-|-+ +-----+ |+-->+-----+ | | | | | +-----+ || | | | +-----+ || | | +------++ | +-->| sf2 |-|+ +-----++ | +-->| sf4 |-|+ +-----+ | | | sf1' | | +-->| | +--->| sf3'| | +-->| | +--->| sf5'| | +-->| +--+ | +-----+----->| |--+ | +-----+----->| |--+ | | | | | | | | | +------+----+ +-----+----+ +-----+ | | +--------+ | V destination Figure 6: Load Balancing and HA (72 characters?) In both cases, the figure has all the same connection compl= exity (fixed up in a few places), but seems to be less busy. -- Eric --_000_4A95BA014132FF49AE685FAB4B9F17F645D29193dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Eric,

     

    How about this shorter= one?

     

    ->{sf1}->{sf2|sf2’|sf2’’}->{sf3}= ->{sf4|sf4’|sf4’’}->{sf5}->

     

    The intent is pretty s= imple: If a service function on a chain has multiple instances, one of the = service function’s instances is selected to treat packets belonging t= o the service chain.  

     

    This is a correct math= ematics expression.

    There is really no nee= d draw all those boxes.

     

    Linda  

     

    From: Eric Gra= y [mailto:eric.gray@ericsson.com]
    Sent: Thursday, May 29, 2014 4:23 PM
    To: Linda Dunbar; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Pau= l Quinn (paulq)
    Cc: sfc@ietf.org
    Subject: RE: Figures in draft-quinn-sfc-arch-05

     

    Linda,

     

    By the way, your propo= sal for Figure 5 would require a column width of at least 80

    characters (more than = you are supposed to have in an ID), and the situation would

    be worse if it were ap= plied to figure 6.

     

    For figure 5, you can = improve the width slightly by fixing up a few of your arrows,

    and even more by wrapp= ing the figure.  Wrapping  might detract from simplicity,

    however.

     

    --

    Eric=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei= .com]
    Sent: Thursday, May 29, 2014 4:49 PM
    To: Lucy yong; Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Q= uinn (paulq)
    Cc: sfc@ietf.org
    Subject: RE: Figures in draft-quinn-sfc-arch-05
    Importance: High

     

    I like the Figures dra= wn by Lucy.

     

    Actually why can’= ;t Figure 5 be simplified as

     

        enter --&g= t;{sf1}-->-{sf2|sf2’|sf2’’}->--{sf3}-->-{sf4|sf4= ’|sf4’’}->--{sf5}--> exit

     

    ??

     

    Linda

     

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong
    Sent: Thursday, May 29, 2014 1:12 PM
    To: Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq= )
    Cc: sfc@ietf.org
    Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05

     

    For readability on the= se figures, propose:

     

    Figure 5:

         = ;            &n= bsp;   +-sf2-+       +-= sf4-+

         = ;            &n= bsp;   |     |     &= nbsp; |     |

         = ;  enter -->sf1-->-sf2->--sf3-->-sf4->--sf5--> exit<= o:p>

         = ;            &n= bsp;   |     |     &= nbsp; |     |

         = ;            &n= bsp;   +-sf2-+       +-= sf4-+

    Figure 6:

     

         = ;            &n= bsp;       +-sf2-+   &= nbsp;          +-sf4-+=

         = ;            &n= bsp;       |     | &= nbsp;            |&n= bsp;    |

        enter --&g= t;{sf1|sf1'}-->-sf2->--{sf3|sf3'}-->-sf4->--{sf5}--> exit

         = ;            &n= bsp;       |     | &= nbsp;            |&n= bsp;    |

              = ;            &n= bsp;  +-sf2-+        &= nbsp;     +-sf4-+=

     

    lucy=

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray
    Sent: Thursday, May 29, 2014 12:54 PM
    To: Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq)
    Cc: sfc@ietf.org
    Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05

     

    HaHa, funny man. = J

     

    From: Jakob He= itz (jheitz) [mailto:jheitz@cisco.com]
    Sent: Thursday, May 29, 2014 1:43 PM
    To: Eric Gray; Joel Halpern; Paul Quinn (paulq)
    Cc:     sfc@ietf.org
    Subject: RE: Figures in draft-quinn-sfc-arch-05
    Importance: High

     

    You could turn the whole picture right by = 90 degrees.

    If you don’t like top to bottom inst= ead of left to right, make a note that it’s in landscape.<= /span>

     

    --Jakob

     

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray
    Sent: Thursday, May 29, 2014 8:31 AM
    To: Joel Halpern; Paul Quinn (paulq)
    Cc: sfc@ietf.org
    Subject: [sfc] Figures in draft-quinn-sfc-arch-05    <= /p>

     

    Paul/Joel,

     

            &nbs= p;       Pretty sure that Figures 5 and 6 don= ’t actually fit the width expected for an

    Internet Draft (Figure 5 is more than 80 characters = wide and Figure 6 is wider still).

     

            &nbs= p;       Depending on how a reader tries to r= ead the draft, this can turn complicated

    illustrations into a _real_ fun time.  <= span style=3D"font-family:Wingdings"> J

     

            &nbs= p;       Also, I am unsure what the figures a= re trying to convey with some of “dotted

    lines” crossing the service functions.  I= f the intent is to show that a service function is

    a virtual instance hosted by some network device, pe= rhaps this will be better shown

    in a separate figure and this aspect of Figures 5 an= d 6 can be eliminated?

     

    I would suggest replacing= Figure 5 with a figure along the lines of:

     

    source &nbs= p;           +--= ---+           &= nbsp;       +-----+=

      = ;|            +-= ->| sf2 +--+        &nbs= p;   +-->| sf4 +--+

      = ;|            | = ;  |     |  |     &n= bsp;      |   |     = |  |

      = ;|  +------+--+   +-----+  +--&= gt;+-----+--+   +-----+  +->+= -----+

      = ;|  | sf1  |      +-----+ &= nbsp;    | sf3 |      +-----= 3;     | sf5 |

      = ;+->|      +----->| sf2 +-----&g= t;|     |----->| sf4 +---->|   = ;  |-+

      = ;   |      |    &nbs= p; |     |      | &n= bsp;   |      |     = |     |     | |

      = ;   +------+--+   +-----+ = ; +-->+-----+--+   +-----+  += ->+-----+ |

      = ;            &n= bsp;|   +-----+  |     &nbs= p;      |   +-----+  | &nbs= p;        |

      = ;            &n= bsp;+-->| sf2 +--+       =      +-->| sf4 +--+    &n= bsp;+----+

      = ;            &n= bsp;    |     |   &n= bsp;            &nbs= p;  |     |      &nb= sp; |

      = ;            &n= bsp;    +-----+     &n= bsp;            &nbs= p;+-----+        V

      = ;            &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p;     destination

     =

      = ;            &n= bsp;    Figure 5: Load Balancing

     

    (67 characters?)

     

            &nbs= p;       Similarly, I would suggest replacing= Figure 6 with a figure along the

    lines of:

     

       source
         |       &n=
bsp;       +-----+-+ &n=
bsp;            =
;     +-----+-+
     +---+        &nb=
sp;  +-->| sf2 |-|+      &nbs=
p;       +-->| sf4 |-|+=

     |           &#=
43;---|-->|     | ||     &n=
bsp;    +------>|     | ||
     |   +------+|---+   +-----&#=
43; |+-->+-----+|---+   +-----+ |+=
-->+-----+
     |   | sf1  ||      =
 +-----+ +--->| sf3 ||       &=
#43;-----+ +--->| sf5 |
     +-->|      +|------>| sf2=
 |+---->|     ||------>| sf4 |+---->|&=
nbsp;    |--+
     |   |      || +---->|&=
nbsp;    |-+    |    =
 || +---->|     |-+    | =
;    |  |
     |   +------+|-|-+   +-----&#=
43; |+-->+-----+|-|-+   +-----+ |+=
-->+-----+  |
     |           | =
| |   +-----+ ||       =
;   | | |   +-----+ ||    &=
nbsp;       |
     |   +------++ | +-->| sf2 |-|+&=
nbsp;  +-----++ | +-->| sf4 |-|+   &#=
43;-----+  |
     |   | sf1' |  | +-->|   &nb=
sp; | +--->| sf3'|  | +-->|     | &#=
43;--->| sf5'|  |
     +-->|      +--+ | &=
nbsp; +-----+----->|     |--+ | &nb=
sp; +-----+----->|     |--+
         |      | &=
nbsp;  |          &n=
bsp;     |     |    =
|            &n=
bsp;   |     |  |

         +------+----+  &nb=
sp;            =
 +-----+----+        &n=
bsp;       +-----+  |=

    

               =
;             &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;         |=

    

               =
;            &n=
bsp;            =
;            &n=
bsp;            =
; +--------+
    

               =
;            &n=
bsp;            =
;            &n=
bsp;            =
; |
    

               =
;            &n=
bsp;            &nbs=
p;            &=
nbsp;           &nbs=
p;V
    

               =
;            &n=
bsp;            =
;            &n=
bsp;        destination
    

     
    

               =
;         Figure 6: Load Balancing =
and HA
    

     
    

    (72 characters?)
    

     
    

            &nbs=
p;       In both cases, the figure has all th=
e same connection complexity (fixed up in a few
    

    places), but seems to be less busy.
    

     
    

    --
    

    Eric
    --_000_4A95BA014132FF49AE685FAB4B9F17F645D29193dfweml701chmchi_-- From nobody Thu May 29 17:22:37 2014 Return-Path: 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 DF6511A02B5 for ; Thu, 29 May 2014 17:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 dJHApL2MpVsZ for ; Thu, 29 May 2014 17:22:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9D381A0756 for ; Thu, 29 May 2014 17:22:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BER54138; Fri, 30 May 2014 00:22:15 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 30 May 2014 01:21:38 +0100 Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 30 May 2014 01:22:14 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml706-chm.china.huawei.com ([169.254.8.4]) with mapi id 14.03.0158.001; Thu, 29 May 2014 17:21:58 -0700 From: Lucy yong To: Eric Gray , Linda Dunbar , "Jakob Heitz (jheitz)" , "Joel Halpern" , "Paul Quinn (paulq)" Thread-Topic: Figures in draft-quinn-sfc-arch-05 Thread-Index: Ac97S9R6mfocA+1iTpKXBfVlibSBggAGJh5AAACjtcAAAHRWQAAFiSTQAAC3mqAABo2PIA== Date: Fri, 30 May 2014 00:21:57 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D45389CA8@dfweml701-chm.china.huawei.com> References: <48E1A67CB9CA044EADFEAB87D814BFF632AD0443@eusaamb107.ericsson.se> <075DE01702BBC249BE1357EFD20DCFE556E2EC@xmb-aln-x02.cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD07D6@eusaamb107.ericsson.se> <2691CE0099834E4A9C5044EEC662BB9D45389B2C@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645D290DA@dfweml701-chm.china.huawei.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD0AF6@eusaamb107.ericsson.se> In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF632AD0AF6@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.138.124] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D45389CA8dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/10lsWmW4FFM-2cBCzIbahQWIn3s Cc: "sfc@ietf.org" Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 00:22:34 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D45389CA8dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eric, There is no contest in this discussion. We just provide suggestions and bel= ieve that editors will address them properly in next version based on the d= iscussion and suggestions. IMO: we have enough discussion on this subject.= So I am end here. :) Lucy From: Eric Gray [mailto:eric.gray@ericsson.com] Sent: Thursday, May 29, 2014 4:18 PM To: Linda Dunbar; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn= (paulq) Cc: sfc@ietf.org Subject: RE: Figures in draft-quinn-sfc-arch-05 Linda/Lucy, It's not a beauty contest. There are trade-offs associated= with using any of these approaches. If the authors decide to use Lucy's approach, they will nee= d to add a little bit more text to explain the notation (sf1|sf1' meaning two separate nodes providing the same service function, where packets may be processed by either) - as it is not as intuitive as if separate boxes are used in the= figure. Your suggestion would require even more additional text, as= it is (in effect) applying the same sort of notation recursively - especially if appl= ied to both figures 5 and 6. Either approach would be fine with me, provided the text to= make it clear what these figures mean is provided. For other folks - particularly those who understand things = better if they are clearly explained pictorially - having the need to add extra text = to make the picture itself more understandable may not work that well. I'm personally fine with any of the options discussed so fa= r, and am perfectly happy to let the Editors of the draft make whatever choice they prefer, for whatever reasons they prefer that (or those) choice(s). -- Eric From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Thursday, May 29, 2014 4:49 PM To: Lucy yong; Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (p= aulq) Cc: sfc@ietf.org Subject: RE: Figures in draft-quinn-sfc-arch-05 Importance: High I like the Figures drawn by Lucy. Actually why can't Figure 5 be simplified as enter -->{sf1}-->-{sf2|sf2'|sf2''}->--{sf3}-->-{sf4|sf4'|sf4''}->--{sf5= }--> exit ?? Linda From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong Sent: Thursday, May 29, 2014 1:12 PM To: Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 For readability on these figures, propose: Figure 5: +-sf2-+ +-sf4-+ | | | | enter -->sf1-->-sf2->--sf3-->-sf4->--sf5--> exit | | | | +-sf2-+ +-sf4-+ Figure 6: +-sf2-+ +-sf4-+ | | | | enter -->{sf1|sf1'}-->-sf2->--{sf3|sf3'}-->-sf4->--{sf5}--> exit | | | | +-sf2-+ +-sf4-+ lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray Sent: Thursday, May 29, 2014 12:54 PM To: Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 HaHa, funny man. :) From: Jakob Heitz (jheitz) [mailto:jheitz@cisco.com] Sent: Thursday, May 29, 2014 1:43 PM To: Eric Gray; Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: RE: Figures in draft-quinn-sfc-arch-05 Importance: High You could turn the whole picture right by 90 degrees. If you don't like top to bottom instead of left to right, make a note that = it's in landscape. --Jakob From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray Sent: Thursday, May 29, 2014 8:31 AM To: Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: [sfc] Figures in draft-quinn-sfc-arch-05 Paul/Joel, Pretty sure that Figures 5 and 6 don't actually fit the wid= th expected for an Internet Draft (Figure 5 is more than 80 characters wide and Figure 6 is wi= der still). Depending on how a reader tries to read the draft, this can= turn complicated illustrations into a _real_ fun time. :) Also, I am unsure what the figures are trying to convey wit= h some of "dotted lines" crossing the service functions. If the intent is to show that a ser= vice function is a virtual instance hosted by some network device, perhaps this will be bett= er shown in a separate figure and this aspect of Figures 5 and 6 can be eliminated? I would suggest replacing Figure 5 with a figure along the lines of: source +-----+ +-----+ | +-->| sf2 +--+ +-->| sf4 +--+ | | | | | | | | | | +------+--+ +-----+ +-->+-----+--+ +-----+ +->+-----+ | | sf1 | +-----+ | sf3 | +-----+ | sf5 | +->| +----->| sf2 +----->| |----->| sf4 +---->| |-+ | | | | | | | | | | | +------+--+ +-----+ +-->+-----+--+ +-----+ +->+-----+ | | +-----+ | | +-----+ | | +-->| sf2 +--+ +-->| sf4 +--+ +----+ | | | | | +-----+ +-----+ V destination Figure 5: Load Balancing (67 characters?) Similarly, I would suggest replacing Figure 6 with a figure= along the lines of: source | +-----+-+ +-----+-+ +---+ +-->| sf2 |-|+ +-->| sf4 |-|+ | +---|-->| | || +------>| | || | +------+|---+ +-----+ |+-->+-----+|---+ +-----+ |+-->+-----+ | | sf1 || +-----+ +--->| sf3 || +-----+ +--->| sf5 | +-->| +|------>| sf2 |+---->| ||------>| sf4 |+---->| |--+ | | || +---->| |-+ | || +---->| |-+ | | | | +------+|-|-+ +-----+ |+-->+-----+|-|-+ +-----+ |+-->+-----+ | | | | | +-----+ || | | | +-----+ || | | +------++ | +-->| sf2 |-|+ +-----++ | +-->| sf4 |-|+ +-----+ | | | sf1' | | +-->| | +--->| sf3'| | +-->| | +--->| sf5'| | +-->| +--+ | +-----+----->| |--+ | +-----+----->| |--+ | | | | | | | | | +------+----+ +-----+----+ +-----+ | | +--------+ | V destination Figure 6: Load Balancing and HA (72 characters?) In both cases, the figure has all the same connection compl= exity (fixed up in a few places), but seems to be less busy. -- Eric --_000_2691CE0099834E4A9C5044EEC662BB9D45389CA8dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Eric,

     

    There is no contest in= this discussion. We just provide suggestions and believe that editors will= address them properly in next version based on the discussion and suggesti= ons.  IMO: we have enough discussion on this subject. So I am end here. J

     

    Lucy=

     

    From: Eric Gra= y [mailto:eric.gray@ericsson.com]
    Sent: Thursday, May 29, 2014 4:18 PM
    To: Linda Dunbar; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Pau= l Quinn (paulq)
    Cc: sfc@ietf.org
    Subject: RE: Figures in draft-quinn-sfc-arch-05

     

    Linda/Lucy,=

     

       &nbs= p;            ItR= 17;s not a beauty contest.  There are trade-offs associated with using

    any of these approache= s.

     

       &nbs= p;            If the= authors decide to use Lucy’s approach, they will need to add a<= /o:p>

    little bit more text t= o explain the notation (sf1|sf1’ meaning two separate

    nodes providing the sa= me service function, where packets may be processed

    by either) – as = it is not as intuitive as if separate boxes are used in the figure.

     

       &nbs= p;            Your s= uggestion would require even more additional text, as it is (in<= /span>

    effect) applying the s= ame sort of notation recursively – especially if applied

    to both figures 5 and = 6.

     

       &nbs= p;            Either= approach would be fine with me, provided the text to make

    it clear what these fi= gures mean is provided.

     

       &nbs= p;            For ot= her folks – particularly those who understand things better if

    they are clearly expla= ined pictorially – having the need to add extra text to

    make the picture itsel= f more understandable may not work that well.

     

       &nbs= p;            I̵= 7;m personally fine with any of the options discussed so far, and am

    perfectly happy to let= the Editors of the draft make whatever choice they

    prefer, for whatever r= easons they prefer that (or those) choice(s).

     

    --

    Eric=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei= .com]
    Sent: Thursday, May 29, 2014 4:49 PM
    To: Lucy yong; Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Q= uinn (paulq)
    Cc: sfc@ietf.org
    Subject: RE: Figures in draft-quinn-sfc-arch-05
    Importance: High

     

    I like the Figures dra= wn by Lucy.

     

    Actually why can’= ;t Figure 5 be simplified as

     

        enter --&g= t;{sf1}-->-{sf2|sf2’|sf2’’}->--{sf3}-->-{sf4|sf4= ’|sf4’’}->--{sf5}--> exit

     

    ??

     

    Linda

     

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong
    Sent: Thursday, May 29, 2014 1:12 PM
    To: Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq= )
    Cc: sfc@ietf.org
    Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05

     

    For readability on the= se figures, propose:

     

    Figure 5:

         = ;            &n= bsp;   +-sf2-+       +-= sf4-+

         = ;            &n= bsp;   |     |     &= nbsp; |     |

         = ;  enter -->sf1-->-sf2->--sf3-->-sf4->--sf5--> exit<= o:p>

         = ;            &n= bsp;   |     |     &= nbsp; |     |

         = ;            &n= bsp;   +-sf2-+       +-= sf4-+

    Figure 6:

     

         = ;            &n= bsp;       +-sf2-+   &= nbsp;          +-sf4-+=

         = ;            &n= bsp;       |     | &= nbsp;            |&n= bsp;    |

        enter --&g= t;{sf1|sf1'}-->-sf2->--{sf3|sf3'}-->-sf4->--{sf5}--> exit

         = ;            &n= bsp;       |     | &= nbsp;            |&n= bsp;    |

              = ;            &n= bsp;  +-sf2-+        &= nbsp;     +-sf4-+=

     

    lucy=

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray
    Sent: Thursday, May 29, 2014 12:54 PM
    To: Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq)
    Cc: sfc@ietf.org
    Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05

     

    HaHa, funny man. = J

     

    From: Jakob He= itz (jheitz) [mailto:jheitz@cisco.com]
    Sent: Thursday, May 29, 2014 1:43 PM
    To: Eric Gray; Joel Halpern; Paul Quinn (paulq)
    Cc:     sfc@ietf.org
    Subject: RE: Figures in draft-quinn-sfc-arch-05
    Importance: High

     

    You could turn the whole picture right by = 90 degrees.

    If you don’t like top to bottom inst= ead of left to right, make a note that it’s in landscape.<= /span>

     

    --Jakob

     

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray
    Sent: Thursday, May 29, 2014 8:31 AM
    To: Joel Halpern; Paul Quinn (paulq)
    Cc: sfc@ietf.org
    Subject: [sfc] Figures in draft-quinn-sfc-arch-05    <= /p>

     

    Paul/Joel,

     

            &nbs= p;       Pretty sure that Figures 5 and 6 don= ’t actually fit the width expected for an

    Internet Draft (Figure 5 is more than 80 characters = wide and Figure 6 is wider still).

     

            &nbs= p;       Depending on how a reader tries to r= ead the draft, this can turn complicated

    illustrations into a _real_ fun time.  <= span style=3D"font-family:Wingdings"> J

     

            &nbs= p;       Also, I am unsure what the figures a= re trying to convey with some of “dotted

    lines” crossing the service functions.  I= f the intent is to show that a service function is

    a virtual instance hosted by some network device, pe= rhaps this will be better shown

    in a separate figure and this aspect of Figures 5 an= d 6 can be eliminated?

     

    I would suggest replacing= Figure 5 with a figure along the lines of:

     

    source &nbs= p;           +--= ---+           &= nbsp;       +-----+=

      = ;|            +-= ->| sf2 +--+        &nbs= p;   +-->| sf4 +--+

      = ;|            | = ;  |     |  |     &n= bsp;      |   |     = |  |

      = ;|  +------+--+   +-----+  +--&= gt;+-----+--+   +-----+  +->+= -----+

      = ;|  | sf1  |      +-----+ &= nbsp;    | sf3 |      +-----= 3;     | sf5 |

      = ;+->|      +----->| sf2 +-----&g= t;|     |----->| sf4 +---->|   = ;  |-+

      = ;   |      |    &nbs= p; |     |      | &n= bsp;   |      |     = |     |     | |

      = ;   +------+--+   +-----+ = ; +-->+-----+--+   +-----+  += ->+-----+ |

      = ;            &n= bsp;|   +-----+  |     &nbs= p;      |   +-----+  | &nbs= p;        |

      = ;            &n= bsp;+-->| sf2 +--+       =      +-->| sf4 +--+    &n= bsp;+----+

      = ;            &n= bsp;    |     |   &n= bsp;            &nbs= p;  |     |      &nb= sp; |

      = ;            &n= bsp;    +-----+     &n= bsp;            &nbs= p;+-----+        V

      = ;            &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p;     destination

     =

      = ;            &n= bsp;    Figure 5: Load Balancing

     

    (67 characters?)

     

            &nbs= p;       Similarly, I would suggest replacing= Figure 6 with a figure along the

    lines of:

     

       source
         |       &n=
bsp;       +-----+-+ &n=
bsp;            =
;     +-----+-+
     +---+        &nb=
sp;  +-->| sf2 |-|+      &nbs=
p;       +-->| sf4 |-|+=

     |           &#=
43;---|-->|     | ||     &n=
bsp;    +------>|     | ||
     |   +------+|---+   +-----&#=
43; |+-->+-----+|---+   +-----+ |+=
-->+-----+
     |   | sf1  ||      =
 +-----+ +--->| sf3 ||       &=
#43;-----+ +--->| sf5 |
     +-->|      +|------>| sf2=
 |+---->|     ||------>| sf4 |+---->|&=
nbsp;    |--+
     |   |      || +---->|&=
nbsp;    |-+    |    =
 || +---->|     |-+    | =
;    |  |
     |   +------+|-|-+   +-----&#=
43; |+-->+-----+|-|-+   +-----+ |+=
-->+-----+  |
     |           | =
| |   +-----+ ||       =
;   | | |   +-----+ ||    &=
nbsp;       |
     |   +------++ | +-->| sf2 |-|+&=
nbsp;  +-----++ | +-->| sf4 |-|+   &#=
43;-----+  |
     |   | sf1' |  | +-->|   &nb=
sp; | +--->| sf3'|  | +-->|     | &#=
43;--->| sf5'|  |
     +-->|      +--+ | &=
nbsp; +-----+----->|     |--+ | &nb=
sp; +-----+----->|     |--+
         |      | &=
nbsp;  |          &n=
bsp;     |     |    =
|            &n=
bsp;   |     |  |

         +------+----+  &nb=
sp;            =
 +-----+----+        &n=
bsp;       +-----+  |=

    

               =
;             &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;         |=

    

               =
;            &n=
bsp;            =
;            &n=
bsp;            =
; +--------+
    

               =
;            &n=
bsp;            =
;            &n=
bsp;            =
; |
    

               =
;            &n=
bsp;            &nbs=
p;            &=
nbsp;           &nbs=
p;V
    

               =
;            &n=
bsp;            =
;            &n=
bsp;        destination
    

     
    

               =
;         Figure 6: Load Balancing =
and HA
    

     
    

    (72 characters?)
    

     
    

            &nbs=
p;       In both cases, the figure has all th=
e same connection complexity (fixed up in a few
    

    places), but seems to be less busy.
    

     
    

    --
    

    Eric
    --_000_2691CE0099834E4A9C5044EEC662BB9D45389CA8dfweml701chmchi_-- From nobody Thu May 29 20:27:52 2014 Return-Path: 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 34FDF1A031B for ; Thu, 29 May 2014 20:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.552 X-Spam-Level: X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 r0R9wm4-gR-V for ; Thu, 29 May 2014 20:27:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA0EF1A02E8 for ; Thu, 29 May 2014 20:27:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHK65730; Fri, 30 May 2014 03:27:42 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 30 May 2014 04:27:09 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 30 May 2014 04:27:41 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.193]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Fri, 30 May 2014 11:27:27 +0800 From: Qin Wu To: Joel Halpern Direct , "Ken Gray (kegray)" , Linda Dunbar Thread-Topic: =?utf-8?B?W3NmY10g562U5aSNOiAgcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2luZyBj?= =?utf-8?Q?onsiderations"_in_the_draft-quinn-sfc-arch-05?= Thread-Index: AQHPe0BNgQzjDyNfAE6OxuZd1w53s5tYcKSg Date: Fri, 30 May 2014 03:27:26 +0000 Message-ID: References: , <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> <16984558-2B4C-4873-AFC7-DCD2698CA745@cisco.com> <53873333.80807@joelhalpern.com> In-Reply-To: <53873333.80807@joelhalpern.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.131] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/NK14xq_c6lZg5KrKkAzc38Qn18M Cc: "Joel M. Halpern" , "Paul Quinn \(paulq\)" , "sfc@ietf.org" Subject: [sfc] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgcXVlc3Rpb25zIG9mICJsb2Fk?= =?utf-8?q?_balancing_considerations=22_in_the_draft-quinn-sfc-arch-05?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 03:27:51 -0000 SGksIEpvZWw6DQpUaGFuayBmb3IgeW91ciBjbGFyaWZpY2F0aW9uLiANCmlmIGxvYWQgYmFsYW5j ZXIgaXMgcmVhbGx5IG5lZWRlZCBhbmQgaXQgaXMgbm90IGEgc2VydmljZSBmdW5jdGlvbiBpbiB0 aGUgY2hhaW4sIEkgYWdyZWUgd2Ugc2hvdWxkIG5vdCBtYW5kYXRlIGl0cyBsb2NhdGlvbi4NClNv IHRoZSBmb2xsb3dpbmcgZGVzY3JpcHRpb24gaW4gdGhlIGRyYWZ0IGlzIHZlcnkgcmVzdHJpY3Rp dmUNCiINCkVpdGhlciB0aHJvdWdoIGFuIGltYmVkZGVkIGFjdGlvbiBpbiBzZjEgYW5kIHNmMywg b3IgdGhyb3VnaCBleHRlcm5hbA0KY29udHJvbA0KIg0KSXQgc2VlbXMgZXhjbHVkaW5nIGhhdmlu ZyBsb2FkIGJhbGFuY2VyIG9uIHRoZSBTRkYuDQpBbHNvIGlmICBzZjEgcmVxdWlyZXMgbG9hZCBi YWxhbmNlciBhbmQgc2YxIGl0c2VsZiBwcm92aWRlcyBmaXJld2FsbCB0cmVhdG1lbnQsDQpJdCBs b29rcyBvbmUgc2Ygc3VwcG9ydHMgdHdvIGRpZmZlcmVudCB0cmVhdG1lbnRzLCBvbmUgaXMgZmly ZXdhbGwsIHRoZSBvdGhlciBpcyBsb2FkIGJhbGFuY2VyLg0KDQpIb3dldmVyIGlmIHdlIG1vdmUg bG9hZCBiYWxhbmNlciBmdW5jdGlvbmFsaXR5IHRvIFNGRiBvciBvdGhlciBib3gsIGl0IHNlZW1z IHJlYXNvbmFibGUuDQpTbyB0aGUgcXVlc3Rpb24gaXMgY2FuIG9uZSBzZXJ2aWNlIGZ1bmN0aW9u IHByb3ZpZGUgbW9yZSB0aGFuIG9uZSBzZXJ2aWNlIG9yIHRyZWF0bWVudD8NCg0KSSBtYXkgbWlz cyB0aGUgZWFybGllciBkaXNjdXNzaW9uLCBwbGVhc2UgY29ycmVjdCBtZSBpZiBJIGFtIHdyb25n Lg0KDQpSZWdhcmRzIQ0KLVFpbg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBK b2VsIEhhbHBlcm4gRGlyZWN0IFttYWlsdG86am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb21dIA0K 5Y+R6YCB5pe26Ze0OiAyMDE05bm0NeaciDI55pelIDIxOjE3DQrmlLbku7bkuro6IFFpbiBXdTsg S2VuIEdyYXkgKGtlZ3JheSk7IExpbmRhIER1bmJhcg0K5oqE6YCBOiBKb2VsIE0uIEhhbHBlcm47 IFBhdWwgUXVpbm4gKHBhdWxxKTsgc2ZjQGlldGYub3JnDQrkuLvpopg6IFJlOiBbc2ZjXSDnrZTl pI06IHF1ZXN0aW9ucyBvZiAibG9hZCBiYWxhbmNpbmcgY29uc2lkZXJhdGlvbnMiIGluIHRoZSBk cmFmdC1xdWlubi1zZmMtYXJjaC0wNQ0KDQpJIGFtIG5vdCBmb2xsb3dpbmcgeW91ciBxdWVzdGlv bi4NClNGRiBjYW4gaGF2ZSBhIGNvLWxvY2F0ZWQgbG9hZCBiYWxhbmNlci4gIE9yIHRoZSBsb2Fk IGJhbGFuY2VyIGNhbiBiZSB0cmFuc3BhcmVudGx5IGJlaGluZCB0aGUgU0ZGLCB1c2luZyBhbnkg bnVtYmVyIG9mIG1lY2hhbmlzbXMuDQpXZSBhcmUgbm90IG1hbmRhdGluZyB3aGVyZSBpdCBpcyBs b2NhdGVkLg0KDQpZb3VycywNCkpvZWwNCg0KT24gNS8yOC8xNCwgMTE6NTUgUE0sIFFpbiBXdSB3 cm90ZToNCj4gWW91IGFyZSB0YWxraW5nIGFib3V0IHNlcnZpY2UgZnVuY3Rpb24gc2NhbGUgdXAg YW5kIGRvd24uDQo+DQo+IFNpbmNlIHNlcnZpY2Ugbm9kZSBjYW4gaG9zdCBvbmUgb3IgbXVsdGlw bGUgc2VydmljZSBmdW5jdGlvbnMsIHdoeSANCj4gc2VydmljZSBub2RlIGNhbiBub3QgYmUgdXNl ZCB0byBjb250cm9sIHNjYWxlIHVwIG9yIGRvd24gb2Ygc2VydmljZSANCj4gZnVuY3Rpb25zIGl0 Pw0KPg0KPiBUbyBhdm9pZCBzaGFyZSByaXNrIGZhaWx1cmUsIHNlcnZpY2Ugbm9kZSBjYW4gYmUg cHJldmlvdXMgc2VydmljZSANCj4gbm9kZSwgZS5nLiwgaXQgY2FuIGJlIHRoZSBvbmUgdGhhdCBo b3N0cyBzZjEgb3Igc2YzLg0KPg0KPiBBbHNvIFNGRiBpcyByZXNwb25zaWJsZSBmb3IgZGVsaXZl cmluZyB0cmFmZmljIHRvIGFueSBjb25uZWN0ZWQgDQo+IHNlcnZpY2UgZnVuY3Rpb25zLCB3aHkg bm90IFNGRiBjYW4gbm90IGJlIHVzZWQgdG8gbWFuYWdlIHNjYWxlIHVwIG9yIA0KPiBkb3duIG9m IHNlcnZpY2UgZnVuY3Rpb24uDQo+DQo+IEFsc28gYmFzZWQgb24gTkZWIE1BTk8gYXJjaGl0ZWN0 dXJlLCB0aGVyZSBpcyByZWZlcmVuY2UgcG9pbnQgYmV0d2VlbiANCj4gTkZWIGFuZCBORlYgbWFu YWdlciwgTkZWIG1hbmFnZXIgYWxzbyBjYW4gY29udHJvbCBzY2FsZSB1cCBvciBkb3duIG9mIA0K PiBzZXJ2aWNlIGZ1bmN0aW9uLCBJIHRoaW5rIHRoaXMgY2FzZSBoYXMgYmVlbiBjb3ZlcmVkIGJ5 IOKAnHRocm91Z2ggDQo+IGV4dGVybmFsIGNvbnRyb2zigJ0gaW4gdGhlIGRyYWZ0Lg0KPg0KPiBV c2luZyBzZjEgdGhhdCBwcm92aWRlIGRlZGljYXRlZCBmaXJld2FsbCBzZXJ2aWNlIHRvIHByb3Zp ZGUgbG9hZCANCj4gYmFsYW5jaW5nIGZ1bmN0aW9uYWxpdHkgYXMgd2VsbCBpcyBhIGxpdHRsZSBi aXQgd2VpcmQgdG8gbWUuDQo+DQo+IExldCBtZSBrbm93IGlmIG15IHVuZGVyc3RhbmRpbmcgaXMg Y29ycmVjdD8NCj4NCj4gUmVnYXJkcyENCj4NCj4gLVFpbg0KPg0KPiAq5Y+R5Lu25Lq6OipzZmMg W21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gKuS7o+ihqCAqS2VuIEdyYXkgKGtlZ3JheSkN Cj4gKuWPkemAgeaXtumXtDoqMjAxNOW5tDXmnIgyOeaXpTg6NDkNCj4gKuaUtuS7tuS6ujoqTGlu ZGEgRHVuYmFyDQo+ICrmioTpgIE6KkpvZWwgTS4gSGFscGVybjsgUGF1bCBRdWlubiAocGF1bHEp OyBzZmNAaWV0Zi5vcmcNCj4gKuS4u+mimDoqUmU6IFtzZmNdIHF1ZXN0aW9ucyBvZiAibG9hZCBi YWxhbmNpbmcgY29uc2lkZXJhdGlvbnMiIGluIHRoZQ0KPiBkcmFmdC1xdWlubi1zZmMtYXJjaC0w NQ0KPg0KPiBJIGRvbid0IHNlZSBob3cgeW91IG1ha2UgdGhlIGxlYXAgZnJvbSB0aGUgZXhwbGFu YXRpb24gb2Ygd2h5IGl0IHdhcyANCj4gaXJyZWxldmFudCB0byBnbyBpbnRvIG1vcmUgZGV0YWls IGluIHRoZSBzZWN0aW9uIHRvIHRoZSBlbGltaW5hdGlvbiBvZiANCj4gdGhlIHZlcnkgZ2VuZXJh bGl6ZWQgZGVzY3JpcHRpb24gYWNjb21wYW55aW5nIHRoZSBmaWd1cmUuICBQbGVhc2UgdXNlIA0K PiB5b3VyIG93biBhcmd1bWVudCB0byBqdXN0aWZ5IHRoaXMgYW5kIG5vdCBpbmZlciBhbnkgZXh0 cmEgbWVhbmluZyBmcm9tIA0KPiBteSBhbnN3ZXIgdG8gYSBkaWZmZXJlbnQgcXVlc3Rpb24uDQo+ DQo+IEFzIHRvIHRoZSBzZWNvbmQgY2hhbmdlLCBpIGRpc2FncmVlLiAgQWdhaW4sIGluIGdlbmVy YWwvYnJvYWQgc3Ryb2tlcyANCj4gLSBmcm9tIHRoZSBkcmF3aW5nIGFuZCB0aGUgdGV4dCwgaXQg aXMgdW5saWtlbHkgdGhhdCBhbnkgc3BlY2lhbCANCj4gYWN0aW9uIHdvdWxkIGJlIHJlcXVpcmVk IG9uIHNmMiBvciBzZjQgLSBhcyB0aGV5IGNvbGxhcHNlIGluIGVpdGhlciANCj4gZGlyZWN0aW9u IHRvIGEgc2luZ2xlIGxvZ2ljYWwgbmV4dCBob3AuDQo+DQo+IFNlbnQgZnJvbSBteSBpUGhvbmUN Cj4NCj4NCj4gT24gTWF5IDI4LCAyMDE0LCBhdCA1OjQ5IFBNLCAiTGluZGEgRHVuYmFyIiA8bGlu ZGEuZHVuYmFyQGh1YXdlaS5jb20gDQo+IDxtYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+ PiB3cm90ZToNCj4NCj4gICAgIEpvZWwsIEVyaWMsIGFuZCBLZW4sDQo+DQo+ICAgICBUaGFuayB5 b3UgdmVyeSBtdWNoIGZvciB0aGUgZXhwbGFuYXRpb24uDQo+DQo+ICAgICBCYXNlZCBvbiB3aGF0 IHlvdSBzYWlkLCB0aGUgZGVzY3JpcHRpb24gb24gaG93IOKAnGNvbnRyb2wgZW50aXR5ICBwdXNo DQo+ICAgICB0byB0aGUgc2YxIG5vZGVzIOKApuKAnSBzaG91bGQgYmUgcmVtb3ZlZCBmcm9tIHRo ZSB0ZXh0LCBzcGVjaWZpY2FsbHk6DQo+DQo+ICAgICDigJxJbiB0aGlzDQo+DQo+ICAgICAgICAg Y2FzZSwgdGhlIGNvbnRyb2wgZW50aXR5IHdpbGwgcHVzaCB0byB0aGUgc2YxIG5vZGVzLCBhIHRh YmxlIA0KPiBvZg0KPg0KPiAgICAgICAgIHNvcnRzOltMMV0gPCNfbXNvY29tXzE+IHNmMiB3aXRo IGEgc2VyaWVzIG9mIG5leHQgaG9wcywgYW5kIGlmDQo+ICAgICBuZWVkZWQgc29tZSB3ZWlnaHRl ZCBvcg0KPg0KPiAgICAgICAgIG90aGVyIG1ldHJpY3MgKHRoZXNlIGNvdWxkIGFsc28gYmUgZGVj aWRlZCBsb2NhbGx5IGJ5IHNvbWUgDQo+IHBvbGljeSwNCj4NCj4gICAgICAgICBidXQgc2YxIHdv dWxkIG5lZWQgdG8gYmUgYXdhcmUgb2YgZXhwYW5kL2NvbnRyYWN0IHRyaWdnZXJzIGFuZA0KPg0K PiAgICAgICAgIGFjdGlvbnMpLuKAnQ0KPg0KPiAgICAgU2hvdWxkIGFsc28gY2hhbmdlIHRoZSBz ZW50ZW5jZSBhZnRlciB0aGUgRmlndXJlIDUgdG8NCj4NCj4gICAgIOKAnEVpdGhlciB0aHJvdWdo IGFuIGltYmVkZGVkIGFjdGlvbiBpbiBzZjEgYW5kIHNmMywgdGhlIFNGRiBub2RlcyB0bw0KPiAg ICAgd2hpY2ggdGhlIG11bHRpcGxlIGluc3RhbmNlcyBvZiBTRjIgb3IgU0Y0IGFyZSBhdHRhY2hl ZCwgb3IgdGhyb3VnaA0KPiAgICAgZXh0ZXJuYWwNCj4NCj4gICAgICAgICBjb250cm9sLCB0aGUg c2VydmljZSBmdW5jdGlvbnMgc2YyIGFuZCBzZjQgYXJlIGVsYXN0aWNhbGx5IA0KPiBleHBhbmRl ZA0KPg0KPiAgICAgICAgIGFuZCBjb250cmFjdGVkIGR5bmFtaWNhbGx5LuKAnQ0KPg0KPiAgICAg TGluZGENCj4NCj4gICAgICpGcm9tOipLZW4gR3JheSAoa2VncmF5KSBbbWFpbHRvOmtlZ3JheUBj aXNjby5jb21dDQo+ICAgICAqU2VudDoqIFdlZG5lc2RheSwgTWF5IDI4LCAyMDE0IDQ6MjQgUE0N Cj4gICAgICpUbzoqIExpbmRhIER1bmJhcjsgUGF1bCBRdWlubiAocGF1bHEpOyBKb2VsIE0uIEhh bHBlcm4NCj4gICAgICpDYzoqIHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4g ICAgICpTdWJqZWN0OiogUmU6IFtzZmNdIHF1ZXN0aW9ucyBvZiAibG9hZCBiYWxhbmNpbmcgY29u c2lkZXJhdGlvbnMiIGluDQo+ICAgICB0aGUgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDUNCj4NCj4g ICAgICsxIHRvIEpvZWwg4oCmIHRoZSBwaWN0dXJlIHdvdWxkIGJlIHVnbHkgYXQgYmVzdC4gIFdl IGF0dGVtcHRlZCBhDQo+ICAgICBnZW5lcmljIEhBL0xCIHNsaWRlIHRvIG1ha2UgYSBwb2ludCBh bmQgZXZlbiBpdCB3YXMgdWdseSDigKZzdWNoIGFyZQ0KPiAgICAgdGhlIGxpbWl0YXRpb25zIG9m IEFTQ0lJIGFydC4NCj4NCj4gICAgIEluIGxpbmUg4oCmDQo+DQo+ICAgICAqRnJvbTogKkxpbmRh IER1bmJhciA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20NCj4gICAgIDxtYWlsdG86bGluZGEuZHVu YmFyQGh1YXdlaS5jb20+Pg0KPiAgICAgKkRhdGU6ICpXZWRuZXNkYXksIE1heSAyOCwgMjAxNCAz OjM0IFBNDQo+ICAgICAqVG86ICoiUGF1bCBRdWlubiAocGF1bHEpIiA8cGF1bHFAY2lzY28uY29t DQo+ICAgICA8bWFpbHRvOnBhdWxxQGNpc2NvLmNvbT4+LCAiSm9lbCBNLiBIYWxwZXJuIiA8am1o QGpvZWxoYWxwZXJuLmNvbQ0KPiAgICAgPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4NCj4g ICAgICpDYzogKiJzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+IiA8c2ZjQGlldGYu b3JnDQo+ICAgICA8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQo+ICAgICAqU3ViamVjdDogKltzZmNd IHF1ZXN0aW9ucyBvZiAibG9hZCBiYWxhbmNpbmcgY29uc2lkZXJhdGlvbnMiIGluIHRoZQ0KPiAg ICAgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDUNCj4NCj4gICAgIFBhdWwgYW5kIEpvZWwsDQo+DQo+ ICAgICBEb2VzIHRoZSBMb2FkIEJhbGFuY2luZyBGaWd1cmUgNSAob2YgZHJhZnQtcXVpbm4tc2Zj LWFyY2gtMDUpIGFzc3VtZQ0KPiAgICAgdGhhdCBTRjEgaXMgcmVzcG9uc2libGUgZm9yIGJhbGFu Y2luZyB0cmFmZmljIGFtb25nIHRoZSAzIGluc3RhbmNlcw0KPiAgICAgb2YgU0YyLCBhbmQgU0Yz IGlzIHJlc3BvbnNpYmxlIGZvciBiYWxhbmNpbmcgdHJhZmZpYyBhbW9uZyB0aGUgMw0KPiAgICAg aW5zdGFuY2VzIG9mIFNGND8NCj4NCj4gICAgIDxrZWc+IERvY3VtZW50IHRleHQgYmVsb3cgdGhl IHBpY3R1cmUgc2F5cyAiRWl0aGVyIHRocm91Z2ggYW4NCj4gICAgIGltYmVkZGVkIGFjdGlvbiBp biBzZjEgYW5kIHNmMywgb3IgdGhyb3VnaCBleHRlcm5hbA0KPg0KPiAgICAgY29udHJvbCwgdGhl IHNlcnZpY2UgZnVuY3Rpb25zIHNmMiBhbmQgc2Y0IGFyZSBlbGFzdGljYWxseQ0KPiAgICAgZXhw YW5kZWQgYW5kIGNvbnRyYWN0ZWQgZHluYW1pY2FsbHkuIg0KPg0KPiAgICAgSXNu4oCZdCBpdCBh IHNpbmdsZSBwb2ludCBvZiBmYWlsdXJlPw0KPg0KPiAgICAgPGtlZz4gRG9jdW1lbnQgdGV4dCBp bW1lZGlhdGVseSBzdWJzZXF1ZW50IHRvIHRoYXQgcGljdHVyZSBhbmQNCj4gICAgIHBhcmFncmFw aCBpbGx1c3RyYXRlcyBIQSBzY2VuYXJpb3MuDQo+DQo+ICAgICBTb21lIHNlcnZpY2UgZnVuY3Rp b25zIGFyZSBTdGF0ZWZ1bCwgaS5lLiB0aGV5IG1heSByZXF1aXJlIHBhY2tldHMNCj4gICAgIGZy b20gc2FtZSBmbG93cyB0byB0cmF2ZXJzZSB0aGUgc2FtZSBzZXJ2aWNlIGZ1bmN0aW9uIGluc3Rh bmNlLiBGb3INCj4gICAgIHRoZSBMb2FkIEJhbGFuY2luZyBzY2hlbWUgZGVzY3JpYmVkIGJ5IEZp Z3VyZSA1LCBkbyB5b3UgYXNzdW1lIHRoYXQNCj4gICAgIFNGMSBhbmQgU0YzIHdpbGwgYmUgcmVz cG9uc2libGUgZm9yIG1ha2luZyBzdXJlIHRoYXQgc2FtZSBmbG93cyBnbw0KPiAgICAgdGhyb3Vn aCB0aGUgc2FtZSBzZXJ2aWNlIGZ1bmN0aW9uIGluc3RhbmNlPw0KPg0KPiAgICAgPGtlZz4gQWdh aW4sIHRoZSBhZm9yZW1lbnRpb25lZCB0ZXh0IGRlbGliZXJhdGVseSBhbGxvd3MgdGhpcw0KPiAg ICAgcmVzcG9uc2liaWxpdHkgdG8gYmUgZWl0aGVyIGltYmVkZGVkIGluIHRoZSBlbGFzdGljaXR5 LWNhdXNpbmcNCj4gICAgIGZ1bmN0aW9uIG9yIHRvIGJlIGNvbnRyb2xsZWQgZXh0ZXJuYWxseSBv ciBjZW50cmFsbHkuICBXZSBkb24ndCBnZXQNCj4gICAgIGludG8gdGhlIG1lY2hhbmljcyBhcyB0 aGVzZSBjYW4gdmFyeS4gIFdoaWxlIHN0YXRlZnVsL2JpZGlyZWN0aW9uYWwNCj4gICAgIGRvZXMg YWRkIGFuIGFkZGl0aW9uYWwgYnVyZGVuLCBpdCBjYW4gYmUgYWNjb21tb2RhdGVkIHdpdGhvdXQg YW4NCj4gICAgIGV4cGxvc2lvbiBvZiBkaXNjcmV0ZSBjaGFpbnMuICBGb3IgZXhhbXBsZSwgaXQg Y291bGQgYmUgaGFuZGxlZCAiYXQNCj4gICAgIGFsbG9jYXRpb24gdGltZSIgaWYgZWxhc3RpY2l0 eSBpcyBtYW5hZ2VkIHZpYSBhIHNlcGFyYXRlIGVudGl0eSBhbmQNCj4gICAgIHRoZSBpbmRpdmlk dWFsIGFsbG9jYXRpb25zIHJlZmxlY3RlZCB0aHJvdWdoIHNlcnZpY2UgY2hhaW4gY29udHJvbA0K PiAgICAgaW4gdGhlIGluaXRpYWwgbWV0YWRhdGEgYm91bmQgdG8gYXQgdGhlIGNsYXNzaWZpY2F0 aW9uIHBvaW50IGluDQo+ICAgICBlaXRoZXIgZGlyZWN0aW9uLiAgT1IsIGlmIHRoZSBkZXZpY2Vz IGFyZSB3b3JraW5nIGFzIGEgcGFpcmVkIHN5c3RlbQ0KPiAgICAgKHNpbmdsZSB2ZW5kb3Igb3Ig ZWNvc3lzdGVtKSB3aXRoIGludGVncmF0ZWQgZWxhc3RpY2l0eSwgdGhleSBjb3VsZA0KPiAgICAg cGFzcyBtZXRhZGF0YSBiZXR3ZWVuIHRoZW0gd2hlbiBzZjEgb3Igc2YzIGRvZXMgdGhlIGluaXRp YWwgZHluYW1pYw0KPiAgICAgYWxsb2NhdGlvbiAoYWZmZWN0aW5nIGxvY2FsIGZvcndhcmRpbmcg b24gaXQncyBwYXJ0bmVyKS4gIFRoYXQncw0KPiAgICAgcHJvYmFibHkgbm90IGFuIGV4aGF1c3Rp dmUgbGlzdCBvZiB3YXlzIHRvIHNvbHZlIHRoZSBwcm9ibGVtLiAgOF4pDQo+DQo+ICAgICA8a2Vn PiBUaGUgcG9pbnQgb2YgdGhpcyBzZWN0aW9uIHdhcyB0aGF0IGVsYXN0aWNpdHkgYW5kIEhBIHNo b3VsZA0KPiAgICAgbm90IGNhdXNlIGFuIGlub3JkaW5hdGUgZXhwbG9zaW9uIG9mIGRpc2NyZXRl IGNoYWlucyB3aXRob3V0DQo+ICAgICByZWNvbW1lbmRpbmcgYSBwYXJ0aWN1bGFyIHNvbHV0aW9u LiAgVGhhdCBpcywgIHlvdSBzaG91bGRuJ3QgY3JlYXRlDQo+ICAgICB1bm5lY2Vzc2FyeSAgY29t cGxleGl0eSB3aGVyZSBpdCBkb2Vzbid0IG5lZWQgdG8gZXhpc3QuDQo+DQo+ICAgICBGb3IgdGhl IHN0YXRlZnVsIHNlcnZpY2UgZnVuY3Rpb25zLCBpZiBhIGZsb3cgaXMgc3dpdGNoZWQgZnJvbQ0K PiAgICAgU0YtSW5zdGFuY2UtWCB0byBTRi1JbnN0YW5jZS1ZLCB0aGUgU0YtSW5zdGFuY2UtWSBu ZWVkcyB0bw0KPiAgICAgc3luY2hyb25pemUgdGhlIHN0YXRlcyBmcm9tIFNGLUluc3RhbmNlLVgu IFdobyBpcyByZXNwb25zaWJsZSBmb3INCj4gICAgIHRob3NlIHN0YXRlcyBtYWludGVuYW5jZSBm b3IgdGhlIExvYWQgQmFsYW5jaW5nIGRlc2NyaWJlZCBpbiBGaWd1cmUgNT8NCj4NCj4gICAgIDxr ZWc+IE5vbmUgb2YgdGhvc2UgZW50aXRpZXMgZXhpc3QgaW4gRmlndXJlIDUuICBDYW4geW91IHJl LXBocmFzZQ0KPiAgICAgeW91ciBxdWVzdGlvbiBmcm9tIHRoZSBmaWd1cmU/DQo+DQo+ICAgICBM aW5kYQ0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+DQo+IFJlcXVpcmUgcHVzaGluZyBwb2xp Y2llcyB0byBTRjEgb24gaG93IHRvIGxvYWQgYmFsYW5jZSBtdWx0aXBsZSANCj4gaW5zdGFuY2Vz IG9mIFNGMi4NCj4NCj4gU0YxIG1heSBub3QgaGF2ZSB0aGUgY2FwYWJpbGl0eSB0byBiYWxhbmNl IGFtb25nIG11bHRpcGxlIGluc3RhbmNlcyBvZiANCj4gU0YyDQo+DQo+DQo+DQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWlsaW5nIGxp c3QNCj4gc2ZjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQo+DQo= From nobody Fri May 30 00:57:12 2014 Return-Path: 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 616D61A026D for ; Fri, 30 May 2014 00:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 lAXVvVUi_j1X for ; Fri, 30 May 2014 00:57:10 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BE751A00AA for ; Fri, 30 May 2014 00:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=701; q=dns/txt; s=iport; t=1401436626; x=1402646226; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=OIkq/G8AKXaM+2NCmegy58LrBUZEU7m3lRrph1qk8jk=; b=NUQTIiH1GU51smtY8wj9WVhYqB/hqbrWVOurBaNP6lGvgaW3BrjByMcf uZLUZYAHQJnlSXnO7NwcfYTuy+0BWRMbpUZB3afRUm8HxAIQViUyfaSxr zHT02eSBjviTrglTQnhgwiYo9b+sMlCmj7lD8lSLA3aPA0HLEW9qAOABS Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkUAJc5iFOtJA2N/2dsb2JhbABZgwdSUQfCNgICAYEGFnSCJwEEOlEBKhRCJwQbAYg5CAWiV7QVF44hg2OBFQSbOIltiAGDOIIv X-IronPort-AV: E=Sophos;i="4.98,939,1392163200"; d="scan'208";a="329145340" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-3.cisco.com with ESMTP; 30 May 2014 07:57:04 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s4U7v4fG007081 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 30 May 2014 07:57:04 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.184]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Fri, 30 May 2014 02:57:04 -0500 From: "Reinaldo Penno (repenno)" To: "sfc@ietf.org" Thread-Topic: Yang Data Model for Service Function Chaining (02) Thread-Index: AQHPe9y+1dcKReUMXUuPJ+epenpTWA== Date: Fri, 30 May 2014 07:57:04 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040B8FFDED@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.86.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/uiPiphmdfyvrDFmCcRxOQzxenqw Subject: [sfc] Yang Data Model for Service Function Chaining (02) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 07:57:11 -0000 A new version of I-D, draft-penno-sfc-yang-02.txt=0A= has been successfully submitted by Reinaldo Penno and posted to the=0A= IETF repository.=0A= =0A= Name: draft-penno-sfc-yang=0A= Revision: 02=0A= Title: Yang Data Model for Service Function Chaining=0A= Document date: 2014-05-29=0A= Group: Individual Submission=0A= Pages: 20=0A= URL: http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-02= .txt=0A= Status: https://datatracker.ietf.org/doc/draft-penno-sfc-yang/=0A= Htmlized: http://tools.ietf.org/html/draft-penno-sfc-yang-02=0A= Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-penno-sfc-yang-02= From nobody Fri May 30 06:40:56 2014 Return-Path: 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 4ED091A08C9 for ; Fri, 30 May 2014 06:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 oMrl6vlqRdH2 for ; Fri, 30 May 2014 06:40:52 -0700 (PDT) Received: from hub021-ca-3.exch021.serverdata.net (hub021-ca-3.exch021.serverdata.net [64.78.22.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77D2D1A08A2 for ; Fri, 30 May 2014 06:40:52 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0174.001; Fri, 30 May 2014 06:40:48 -0700 From: Ron Parker To: Qin Wu , Joel Halpern Direct , "Ken Gray (kegray)" , "Linda Dunbar" Thread-Topic: =?utf-8?B?W3NmY10g562U5aSNOiAg562U5aSNOiAgcXVlc3Rpb25zIG9mICJsb2FkIGJh?= =?utf-8?B?bGFuY2luZyBjb25zaWRlcmF0aW9ucyIgaW4gdGhlIGRyYWZ0LXF1aW5uLXNm?= =?utf-8?Q?c-arch-05?= Thread-Index: AQHPe7ck++vjb88HekuHVQyejByh45tZH8DA Date: Fri, 30 May 2014 13:40:47 +0000 Message-ID: References: , <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> <16984558-2B4C-4873-AFC7-DCD2698CA745@cisco.com> <53873333.80807@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/zrfUneG9CIaMSQ35Ec6LEbkMuok Cc: "Joel M. Halpern" , "Paul Quinn \(paulq\)" , "sfc@ietf.org" Subject: Re: [sfc] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgcXVlc3Rpb25zIG9mICJsb2Fk?= =?utf-8?q?_balancing_considerations=22_in_the_draft-quinn-sfc-arch-05?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 13:40:54 -0000 UWluLA0KDQpSZWdhcmRpbmcgeW91ciBxdWVzdGlvbjoNCglTbyB0aGUgcXVlc3Rpb24gaXMgY2Fu IG9uZSBzZXJ2aWNlIGZ1bmN0aW9uIHByb3ZpZGUgbW9yZSB0aGFuIG9uZSBzZXJ2aWNlIG9yIHRy ZWF0bWVudD8NCg0KDQpBIHNlcnZpY2UgZnVuY3Rpb24gY2FuIGJlIHRob3VnaHQgb2YgYXMgYSBs b2dpY2FsIGNvbnN0cnVjdC4gICBNb3JlIHRoYW4gb25lIHN1Y2ggc2VydmljZSBmdW5jdGlvbiBj b3VsZCBiZSBjby1sb2NhdGVkIGF0IHRoZSBzYW1lIGxvY2F0b3IgKGkuZS4sIElQIGFkZHJlc3Mp LiAgIEkuZS4sIGEgc2luZ2xlIG1hbmFnZW1lbnQgZW50aXR5IHdpdGggYSBzaW5nbGUgSVAgYWRk cmVzcyBjb3VsZCBwcm92aWRlIG11bHRpcGxlIHNlcnZpY2UgZnVuY3Rpb25zIHNpbXVsdGFuZW91 c2x5LiAgIEluIGNhc2VzIHdoZXJlIHRoZSBzaW5nbGUgbWFuYWdlZCBlbnRpdHkgd2FzIGFza2Vk IHRvIHBlcmZvcm0gbXVsdGlwbGUgc2VydmljZSBmdW5jdGlvbnMgdGhhdCB3ZXJlIGNvbnNlY3V0 aXZlIGluIHRoZSBzZXJ2aWNlIGNoYWluLCBhcyBhbiBvcHRpbWl6YXRpb24gaXQgc2hvdWxkIG5v dCBiZSBuZWNlc3NhcnkgdG8gcmV0dXJuIHRoZSB0cmFmZmljIHRvIHRoZSBTRkYgaW4gYmV0d2Vl biB0aG9zZSBzZXJ2aWNlIGZ1bmN0aW9ucy4gDQoNCkFub3RoZXIgYXNwZWN0IG9mIHlvdXIgcXVl c3Rpb24gd2FzIGNhbiB0aGUgc2FtZSBsb2dpY2FsIHNlcnZpY2UgZnVuY3Rpb24gcHJvdmlkZSBt b3JlIHRoYW4gb25lIHRyZWF0bWVudD8gICAgVGhlcmUgYXJlIGF0IGxlYXN0IDMgYXBwcm9hY2hl cyB0byB0aGlzLiAgIEluIHRoZSBmaXJzdCwgZWFjaCBkaWZmZXJlbnRpYXRlZCBiZWhhdmlvciBp cyByZXByZXNlbnRlZCBhcyBhIGRpc3RpbmN0IGxvZ2ljYWwgc2VydmljZSBmdW5jdGlvbiAtLSBp LmUuLCBjb250ZW50X2ZpbHRlcl9hZHVsdCwgY29udGVudF9maWx0ZXJfY2hpbGQuICAgSW4gdGhl IHNlY29uZCBhcHByb2FjaCwgYSBzaW5nbGUgc2VydmljZSBmdW5jdGlvbiAoaS5lLiwgY29udGVu dF9maWx0ZXIpIGhhcyBpdHMgb3duIHByaXZhdGUgbWVjaGFuaXNtIHRvIGRldGVybWluZSB3aGlj aCBiZWhhdmlvciB0byBhcHBseSAoaS5lLiwgYSBtaXJyb3JlZCBSQURJVVMgZmVlZCB0ZWFjaGVz IGl0IHN1YnNjcmliZXIgcHJvcGVydGllcyByZWxhdGVkIHRvIHN1YnNjcmliZXIgSVAgYWRkcmVz c2VzKS4gICBBIHRoaXJkIGFwcHJvYWNoIGlzIHRoYXQgdGhlIHNlcnZpY2UgZnVuY3Rpb24gY29u dHJvbGxlciBpbnNlcnRzIG1ldGFkYXRhIHRvIHRoZSBwYWNrZXQgc3RyZWFtIHRoYXQgdGhlIHNl cnZpY2UgZnVuY3Rpb24gY2FuIGludGVycHJldCBmb3IgcHVycG9zZXMgb2YgcHJvdmlkaW5nIGEg ZGlmZmVyZW50aWF0ZWQgYmVoYXZpb3IgKGkuZS4sIHN1YnNjcmliZXJfdHlwZT1jaGlsZCkuDQoN CiAgIFJvbg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNmYyBbbWFp bHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUWluIFd1DQpTZW50OiBUaHVy c2RheSwgTWF5IDI5LCAyMDE0IDExOjI3IFBNDQpUbzogSm9lbCBIYWxwZXJuIERpcmVjdDsgS2Vu IEdyYXkgKGtlZ3JheSk7IExpbmRhIER1bmJhcg0KQ2M6IEpvZWwgTS4gSGFscGVybjsgUGF1bCBR dWlubiAocGF1bHEpOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFtzZmNdIOetlOWkjTog562U5aSN OiBxdWVzdGlvbnMgb2YgImxvYWQgYmFsYW5jaW5nIGNvbnNpZGVyYXRpb25zIiBpbiB0aGUgZHJh ZnQtcXVpbm4tc2ZjLWFyY2gtMDUNCg0KSGksIEpvZWw6DQpUaGFuayBmb3IgeW91ciBjbGFyaWZp Y2F0aW9uLiANCmlmIGxvYWQgYmFsYW5jZXIgaXMgcmVhbGx5IG5lZWRlZCBhbmQgaXQgaXMgbm90 IGEgc2VydmljZSBmdW5jdGlvbiBpbiB0aGUgY2hhaW4sIEkgYWdyZWUgd2Ugc2hvdWxkIG5vdCBt YW5kYXRlIGl0cyBsb2NhdGlvbi4NClNvIHRoZSBmb2xsb3dpbmcgZGVzY3JpcHRpb24gaW4gdGhl IGRyYWZ0IGlzIHZlcnkgcmVzdHJpY3RpdmUgIg0KRWl0aGVyIHRocm91Z2ggYW4gaW1iZWRkZWQg YWN0aW9uIGluIHNmMSBhbmQgc2YzLCBvciB0aHJvdWdoIGV4dGVybmFsIGNvbnRyb2wgIg0KSXQg c2VlbXMgZXhjbHVkaW5nIGhhdmluZyBsb2FkIGJhbGFuY2VyIG9uIHRoZSBTRkYuDQpBbHNvIGlm ICBzZjEgcmVxdWlyZXMgbG9hZCBiYWxhbmNlciBhbmQgc2YxIGl0c2VsZiBwcm92aWRlcyBmaXJl d2FsbCB0cmVhdG1lbnQsIEl0IGxvb2tzIG9uZSBzZiBzdXBwb3J0cyB0d28gZGlmZmVyZW50IHRy ZWF0bWVudHMsIG9uZSBpcyBmaXJld2FsbCwgdGhlIG90aGVyIGlzIGxvYWQgYmFsYW5jZXIuDQoN Ckhvd2V2ZXIgaWYgd2UgbW92ZSBsb2FkIGJhbGFuY2VyIGZ1bmN0aW9uYWxpdHkgdG8gU0ZGIG9y IG90aGVyIGJveCwgaXQgc2VlbXMgcmVhc29uYWJsZS4NClNvIHRoZSBxdWVzdGlvbiBpcyBjYW4g b25lIHNlcnZpY2UgZnVuY3Rpb24gcHJvdmlkZSBtb3JlIHRoYW4gb25lIHNlcnZpY2Ugb3IgdHJl YXRtZW50Pw0KDQpJIG1heSBtaXNzIHRoZSBlYXJsaWVyIGRpc2N1c3Npb24sIHBsZWFzZSBjb3Jy ZWN0IG1lIGlmIEkgYW0gd3JvbmcuDQoNClJlZ2FyZHMhDQotUWluDQotLS0tLemCruS7tuWOn+S7 ti0tLS0tDQrlj5Hku7bkuro6IEpvZWwgSGFscGVybiBEaXJlY3QgW21haWx0bzpqbWguZGlyZWN0 QGpvZWxoYWxwZXJuLmNvbV0NCuWPkemAgeaXtumXtDogMjAxNOW5tDXmnIgyOeaXpSAyMToxNw0K 5pS25Lu25Lq6OiBRaW4gV3U7IEtlbiBHcmF5IChrZWdyYXkpOyBMaW5kYSBEdW5iYXINCuaKhOmA gTogSm9lbCBNLiBIYWxwZXJuOyBQYXVsIFF1aW5uIChwYXVscSk7IHNmY0BpZXRmLm9yZw0K5Li7 6aKYOiBSZTogW3NmY10g562U5aSNOiBxdWVzdGlvbnMgb2YgImxvYWQgYmFsYW5jaW5nIGNvbnNp ZGVyYXRpb25zIiBpbiB0aGUgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDUNCg0KSSBhbSBub3QgZm9s bG93aW5nIHlvdXIgcXVlc3Rpb24uDQpTRkYgY2FuIGhhdmUgYSBjby1sb2NhdGVkIGxvYWQgYmFs YW5jZXIuICBPciB0aGUgbG9hZCBiYWxhbmNlciBjYW4gYmUgdHJhbnNwYXJlbnRseSBiZWhpbmQg dGhlIFNGRiwgdXNpbmcgYW55IG51bWJlciBvZiBtZWNoYW5pc21zLg0KV2UgYXJlIG5vdCBtYW5k YXRpbmcgd2hlcmUgaXQgaXMgbG9jYXRlZC4NCg0KWW91cnMsDQpKb2VsDQoNCk9uIDUvMjgvMTQs IDExOjU1IFBNLCBRaW4gV3Ugd3JvdGU6DQo+IFlvdSBhcmUgdGFsa2luZyBhYm91dCBzZXJ2aWNl IGZ1bmN0aW9uIHNjYWxlIHVwIGFuZCBkb3duLg0KPg0KPiBTaW5jZSBzZXJ2aWNlIG5vZGUgY2Fu IGhvc3Qgb25lIG9yIG11bHRpcGxlIHNlcnZpY2UgZnVuY3Rpb25zLCB3aHkgDQo+IHNlcnZpY2Ug bm9kZSBjYW4gbm90IGJlIHVzZWQgdG8gY29udHJvbCBzY2FsZSB1cCBvciBkb3duIG9mIHNlcnZp Y2UgDQo+IGZ1bmN0aW9ucyBpdD8NCj4NCj4gVG8gYXZvaWQgc2hhcmUgcmlzayBmYWlsdXJlLCBz ZXJ2aWNlIG5vZGUgY2FuIGJlIHByZXZpb3VzIHNlcnZpY2UgDQo+IG5vZGUsIGUuZy4sIGl0IGNh biBiZSB0aGUgb25lIHRoYXQgaG9zdHMgc2YxIG9yIHNmMy4NCj4NCj4gQWxzbyBTRkYgaXMgcmVz cG9uc2libGUgZm9yIGRlbGl2ZXJpbmcgdHJhZmZpYyB0byBhbnkgY29ubmVjdGVkIA0KPiBzZXJ2 aWNlIGZ1bmN0aW9ucywgd2h5IG5vdCBTRkYgY2FuIG5vdCBiZSB1c2VkIHRvIG1hbmFnZSBzY2Fs ZSB1cCBvciANCj4gZG93biBvZiBzZXJ2aWNlIGZ1bmN0aW9uLg0KPg0KPiBBbHNvIGJhc2VkIG9u IE5GViBNQU5PIGFyY2hpdGVjdHVyZSwgdGhlcmUgaXMgcmVmZXJlbmNlIHBvaW50IGJldHdlZW4g DQo+IE5GViBhbmQgTkZWIG1hbmFnZXIsIE5GViBtYW5hZ2VyIGFsc28gY2FuIGNvbnRyb2wgc2Nh bGUgdXAgb3IgZG93biBvZiANCj4gc2VydmljZSBmdW5jdGlvbiwgSSB0aGluayB0aGlzIGNhc2Ug aGFzIGJlZW4gY292ZXJlZCBieSDigJx0aHJvdWdoIA0KPiBleHRlcm5hbCBjb250cm9s4oCdIGlu IHRoZSBkcmFmdC4NCj4NCj4gVXNpbmcgc2YxIHRoYXQgcHJvdmlkZSBkZWRpY2F0ZWQgZmlyZXdh bGwgc2VydmljZSB0byBwcm92aWRlIGxvYWQgDQo+IGJhbGFuY2luZyBmdW5jdGlvbmFsaXR5IGFz IHdlbGwgaXMgYSBsaXR0bGUgYml0IHdlaXJkIHRvIG1lLg0KPg0KPiBMZXQgbWUga25vdyBpZiBt eSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3Q/DQo+DQo+IFJlZ2FyZHMhDQo+DQo+IC1RaW4NCj4N Cj4gKuWPkeS7tuS6ujoqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddICrku6Pooagg KktlbiBHcmF5IChrZWdyYXkpDQo+ICrlj5HpgIHml7bpl7Q6KjIwMTTlubQ15pyIMjnml6U4OjQ5 DQo+ICrmlLbku7bkuro6KkxpbmRhIER1bmJhcg0KPiAq5oqE6YCBOipKb2VsIE0uIEhhbHBlcm47 IFBhdWwgUXVpbm4gKHBhdWxxKTsgc2ZjQGlldGYub3JnDQo+ICrkuLvpopg6KlJlOiBbc2ZjXSBx dWVzdGlvbnMgb2YgImxvYWQgYmFsYW5jaW5nIGNvbnNpZGVyYXRpb25zIiBpbiB0aGUNCj4gZHJh ZnQtcXVpbm4tc2ZjLWFyY2gtMDUNCj4NCj4gSSBkb24ndCBzZWUgaG93IHlvdSBtYWtlIHRoZSBs ZWFwIGZyb20gdGhlIGV4cGxhbmF0aW9uIG9mIHdoeSBpdCB3YXMgDQo+IGlycmVsZXZhbnQgdG8g Z28gaW50byBtb3JlIGRldGFpbCBpbiB0aGUgc2VjdGlvbiB0byB0aGUgZWxpbWluYXRpb24gb2Yg DQo+IHRoZSB2ZXJ5IGdlbmVyYWxpemVkIGRlc2NyaXB0aW9uIGFjY29tcGFueWluZyB0aGUgZmln dXJlLiAgUGxlYXNlIHVzZSANCj4geW91ciBvd24gYXJndW1lbnQgdG8ganVzdGlmeSB0aGlzIGFu ZCBub3QgaW5mZXIgYW55IGV4dHJhIG1lYW5pbmcgZnJvbSANCj4gbXkgYW5zd2VyIHRvIGEgZGlm ZmVyZW50IHF1ZXN0aW9uLg0KPg0KPiBBcyB0byB0aGUgc2Vjb25kIGNoYW5nZSwgaSBkaXNhZ3Jl ZS4gIEFnYWluLCBpbiBnZW5lcmFsL2Jyb2FkIHN0cm9rZXMNCj4gLSBmcm9tIHRoZSBkcmF3aW5n IGFuZCB0aGUgdGV4dCwgaXQgaXMgdW5saWtlbHkgdGhhdCBhbnkgc3BlY2lhbCANCj4gYWN0aW9u IHdvdWxkIGJlIHJlcXVpcmVkIG9uIHNmMiBvciBzZjQgLSBhcyB0aGV5IGNvbGxhcHNlIGluIGVp dGhlciANCj4gZGlyZWN0aW9uIHRvIGEgc2luZ2xlIGxvZ2ljYWwgbmV4dCBob3AuDQo+DQo+IFNl bnQgZnJvbSBteSBpUGhvbmUNCj4NCj4NCj4gT24gTWF5IDI4LCAyMDE0LCBhdCA1OjQ5IFBNLCAi TGluZGEgRHVuYmFyIiA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20gDQo+IDxtYWlsdG86bGluZGEu ZHVuYmFyQGh1YXdlaS5jb20+PiB3cm90ZToNCj4NCj4gICAgIEpvZWwsIEVyaWMsIGFuZCBLZW4s DQo+DQo+ICAgICBUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB0aGUgZXhwbGFuYXRpb24uDQo+DQo+ ICAgICBCYXNlZCBvbiB3aGF0IHlvdSBzYWlkLCB0aGUgZGVzY3JpcHRpb24gb24gaG93IOKAnGNv bnRyb2wgZW50aXR5ICBwdXNoDQo+ICAgICB0byB0aGUgc2YxIG5vZGVzIOKApuKAnSBzaG91bGQg YmUgcmVtb3ZlZCBmcm9tIHRoZSB0ZXh0LCBzcGVjaWZpY2FsbHk6DQo+DQo+ICAgICDigJxJbiB0 aGlzDQo+DQo+ICAgICAgICAgY2FzZSwgdGhlIGNvbnRyb2wgZW50aXR5IHdpbGwgcHVzaCB0byB0 aGUgc2YxIG5vZGVzLCBhIHRhYmxlIA0KPiBvZg0KPg0KPiAgICAgICAgIHNvcnRzOltMMV0gPCNf bXNvY29tXzE+IHNmMiB3aXRoIGEgc2VyaWVzIG9mIG5leHQgaG9wcywgYW5kIGlmDQo+ICAgICBu ZWVkZWQgc29tZSB3ZWlnaHRlZCBvcg0KPg0KPiAgICAgICAgIG90aGVyIG1ldHJpY3MgKHRoZXNl IGNvdWxkIGFsc28gYmUgZGVjaWRlZCBsb2NhbGx5IGJ5IHNvbWUgDQo+IHBvbGljeSwNCj4NCj4g ICAgICAgICBidXQgc2YxIHdvdWxkIG5lZWQgdG8gYmUgYXdhcmUgb2YgZXhwYW5kL2NvbnRyYWN0 IHRyaWdnZXJzIGFuZA0KPg0KPiAgICAgICAgIGFjdGlvbnMpLuKAnQ0KPg0KPiAgICAgU2hvdWxk IGFsc28gY2hhbmdlIHRoZSBzZW50ZW5jZSBhZnRlciB0aGUgRmlndXJlIDUgdG8NCj4NCj4gICAg IOKAnEVpdGhlciB0aHJvdWdoIGFuIGltYmVkZGVkIGFjdGlvbiBpbiBzZjEgYW5kIHNmMywgdGhl IFNGRiBub2RlcyB0bw0KPiAgICAgd2hpY2ggdGhlIG11bHRpcGxlIGluc3RhbmNlcyBvZiBTRjIg b3IgU0Y0IGFyZSBhdHRhY2hlZCwgb3IgdGhyb3VnaA0KPiAgICAgZXh0ZXJuYWwNCj4NCj4gICAg ICAgICBjb250cm9sLCB0aGUgc2VydmljZSBmdW5jdGlvbnMgc2YyIGFuZCBzZjQgYXJlIGVsYXN0 aWNhbGx5IA0KPiBleHBhbmRlZA0KPg0KPiAgICAgICAgIGFuZCBjb250cmFjdGVkIGR5bmFtaWNh bGx5LuKAnQ0KPg0KPiAgICAgTGluZGENCj4NCj4gICAgICpGcm9tOipLZW4gR3JheSAoa2VncmF5 KSBbbWFpbHRvOmtlZ3JheUBjaXNjby5jb21dDQo+ICAgICAqU2VudDoqIFdlZG5lc2RheSwgTWF5 IDI4LCAyMDE0IDQ6MjQgUE0NCj4gICAgICpUbzoqIExpbmRhIER1bmJhcjsgUGF1bCBRdWlubiAo cGF1bHEpOyBKb2VsIE0uIEhhbHBlcm4NCj4gICAgICpDYzoqIHNmY0BpZXRmLm9yZyA8bWFpbHRv OnNmY0BpZXRmLm9yZz4NCj4gICAgICpTdWJqZWN0OiogUmU6IFtzZmNdIHF1ZXN0aW9ucyBvZiAi bG9hZCBiYWxhbmNpbmcgY29uc2lkZXJhdGlvbnMiIGluDQo+ICAgICB0aGUgZHJhZnQtcXVpbm4t c2ZjLWFyY2gtMDUNCj4NCj4gICAgICsxIHRvIEpvZWwg4oCmIHRoZSBwaWN0dXJlIHdvdWxkIGJl IHVnbHkgYXQgYmVzdC4gIFdlIGF0dGVtcHRlZCBhDQo+ICAgICBnZW5lcmljIEhBL0xCIHNsaWRl IHRvIG1ha2UgYSBwb2ludCBhbmQgZXZlbiBpdCB3YXMgdWdseSDigKZzdWNoIGFyZQ0KPiAgICAg dGhlIGxpbWl0YXRpb25zIG9mIEFTQ0lJIGFydC4NCj4NCj4gICAgIEluIGxpbmUg4oCmDQo+DQo+ ICAgICAqRnJvbTogKkxpbmRhIER1bmJhciA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20NCj4gICAg IDxtYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+Pg0KPiAgICAgKkRhdGU6ICpXZWRuZXNk YXksIE1heSAyOCwgMjAxNCAzOjM0IFBNDQo+ICAgICAqVG86ICoiUGF1bCBRdWlubiAocGF1bHEp IiA8cGF1bHFAY2lzY28uY29tDQo+ICAgICA8bWFpbHRvOnBhdWxxQGNpc2NvLmNvbT4+LCAiSm9l bCBNLiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbQ0KPiAgICAgPG1haWx0bzpqbWhAam9l bGhhbHBlcm4uY29tPj4NCj4gICAgICpDYzogKiJzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0 Zi5vcmc+IiA8c2ZjQGlldGYub3JnDQo+ICAgICA8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQo+ICAg ICAqU3ViamVjdDogKltzZmNdIHF1ZXN0aW9ucyBvZiAibG9hZCBiYWxhbmNpbmcgY29uc2lkZXJh dGlvbnMiIGluIHRoZQ0KPiAgICAgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDUNCj4NCj4gICAgIFBh dWwgYW5kIEpvZWwsDQo+DQo+ICAgICBEb2VzIHRoZSBMb2FkIEJhbGFuY2luZyBGaWd1cmUgNSAo b2YgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDUpIGFzc3VtZQ0KPiAgICAgdGhhdCBTRjEgaXMgcmVz cG9uc2libGUgZm9yIGJhbGFuY2luZyB0cmFmZmljIGFtb25nIHRoZSAzIGluc3RhbmNlcw0KPiAg ICAgb2YgU0YyLCBhbmQgU0YzIGlzIHJlc3BvbnNpYmxlIGZvciBiYWxhbmNpbmcgdHJhZmZpYyBh bW9uZyB0aGUgMw0KPiAgICAgaW5zdGFuY2VzIG9mIFNGND8NCj4NCj4gICAgIDxrZWc+IERvY3Vt ZW50IHRleHQgYmVsb3cgdGhlIHBpY3R1cmUgc2F5cyAiRWl0aGVyIHRocm91Z2ggYW4NCj4gICAg IGltYmVkZGVkIGFjdGlvbiBpbiBzZjEgYW5kIHNmMywgb3IgdGhyb3VnaCBleHRlcm5hbA0KPg0K PiAgICAgY29udHJvbCwgdGhlIHNlcnZpY2UgZnVuY3Rpb25zIHNmMiBhbmQgc2Y0IGFyZSBlbGFz dGljYWxseQ0KPiAgICAgZXhwYW5kZWQgYW5kIGNvbnRyYWN0ZWQgZHluYW1pY2FsbHkuIg0KPg0K PiAgICAgSXNu4oCZdCBpdCBhIHNpbmdsZSBwb2ludCBvZiBmYWlsdXJlPw0KPg0KPiAgICAgPGtl Zz4gRG9jdW1lbnQgdGV4dCBpbW1lZGlhdGVseSBzdWJzZXF1ZW50IHRvIHRoYXQgcGljdHVyZSBh bmQNCj4gICAgIHBhcmFncmFwaCBpbGx1c3RyYXRlcyBIQSBzY2VuYXJpb3MuDQo+DQo+ICAgICBT b21lIHNlcnZpY2UgZnVuY3Rpb25zIGFyZSBTdGF0ZWZ1bCwgaS5lLiB0aGV5IG1heSByZXF1aXJl IHBhY2tldHMNCj4gICAgIGZyb20gc2FtZSBmbG93cyB0byB0cmF2ZXJzZSB0aGUgc2FtZSBzZXJ2 aWNlIGZ1bmN0aW9uIGluc3RhbmNlLiBGb3INCj4gICAgIHRoZSBMb2FkIEJhbGFuY2luZyBzY2hl bWUgZGVzY3JpYmVkIGJ5IEZpZ3VyZSA1LCBkbyB5b3UgYXNzdW1lIHRoYXQNCj4gICAgIFNGMSBh bmQgU0YzIHdpbGwgYmUgcmVzcG9uc2libGUgZm9yIG1ha2luZyBzdXJlIHRoYXQgc2FtZSBmbG93 cyBnbw0KPiAgICAgdGhyb3VnaCB0aGUgc2FtZSBzZXJ2aWNlIGZ1bmN0aW9uIGluc3RhbmNlPw0K Pg0KPiAgICAgPGtlZz4gQWdhaW4sIHRoZSBhZm9yZW1lbnRpb25lZCB0ZXh0IGRlbGliZXJhdGVs eSBhbGxvd3MgdGhpcw0KPiAgICAgcmVzcG9uc2liaWxpdHkgdG8gYmUgZWl0aGVyIGltYmVkZGVk IGluIHRoZSBlbGFzdGljaXR5LWNhdXNpbmcNCj4gICAgIGZ1bmN0aW9uIG9yIHRvIGJlIGNvbnRy b2xsZWQgZXh0ZXJuYWxseSBvciBjZW50cmFsbHkuICBXZSBkb24ndCBnZXQNCj4gICAgIGludG8g dGhlIG1lY2hhbmljcyBhcyB0aGVzZSBjYW4gdmFyeS4gIFdoaWxlIHN0YXRlZnVsL2JpZGlyZWN0 aW9uYWwNCj4gICAgIGRvZXMgYWRkIGFuIGFkZGl0aW9uYWwgYnVyZGVuLCBpdCBjYW4gYmUgYWNj b21tb2RhdGVkIHdpdGhvdXQgYW4NCj4gICAgIGV4cGxvc2lvbiBvZiBkaXNjcmV0ZSBjaGFpbnMu ICBGb3IgZXhhbXBsZSwgaXQgY291bGQgYmUgaGFuZGxlZCAiYXQNCj4gICAgIGFsbG9jYXRpb24g dGltZSIgaWYgZWxhc3RpY2l0eSBpcyBtYW5hZ2VkIHZpYSBhIHNlcGFyYXRlIGVudGl0eSBhbmQN Cj4gICAgIHRoZSBpbmRpdmlkdWFsIGFsbG9jYXRpb25zIHJlZmxlY3RlZCB0aHJvdWdoIHNlcnZp Y2UgY2hhaW4gY29udHJvbA0KPiAgICAgaW4gdGhlIGluaXRpYWwgbWV0YWRhdGEgYm91bmQgdG8g YXQgdGhlIGNsYXNzaWZpY2F0aW9uIHBvaW50IGluDQo+ICAgICBlaXRoZXIgZGlyZWN0aW9uLiAg T1IsIGlmIHRoZSBkZXZpY2VzIGFyZSB3b3JraW5nIGFzIGEgcGFpcmVkIHN5c3RlbQ0KPiAgICAg KHNpbmdsZSB2ZW5kb3Igb3IgZWNvc3lzdGVtKSB3aXRoIGludGVncmF0ZWQgZWxhc3RpY2l0eSwg dGhleSBjb3VsZA0KPiAgICAgcGFzcyBtZXRhZGF0YSBiZXR3ZWVuIHRoZW0gd2hlbiBzZjEgb3Ig c2YzIGRvZXMgdGhlIGluaXRpYWwgZHluYW1pYw0KPiAgICAgYWxsb2NhdGlvbiAoYWZmZWN0aW5n IGxvY2FsIGZvcndhcmRpbmcgb24gaXQncyBwYXJ0bmVyKS4gIFRoYXQncw0KPiAgICAgcHJvYmFi bHkgbm90IGFuIGV4aGF1c3RpdmUgbGlzdCBvZiB3YXlzIHRvIHNvbHZlIHRoZSBwcm9ibGVtLiAg OF4pDQo+DQo+ICAgICA8a2VnPiBUaGUgcG9pbnQgb2YgdGhpcyBzZWN0aW9uIHdhcyB0aGF0IGVs YXN0aWNpdHkgYW5kIEhBIHNob3VsZA0KPiAgICAgbm90IGNhdXNlIGFuIGlub3JkaW5hdGUgZXhw bG9zaW9uIG9mIGRpc2NyZXRlIGNoYWlucyB3aXRob3V0DQo+ICAgICByZWNvbW1lbmRpbmcgYSBw YXJ0aWN1bGFyIHNvbHV0aW9uLiAgVGhhdCBpcywgIHlvdSBzaG91bGRuJ3QgY3JlYXRlDQo+ICAg ICB1bm5lY2Vzc2FyeSAgY29tcGxleGl0eSB3aGVyZSBpdCBkb2Vzbid0IG5lZWQgdG8gZXhpc3Qu DQo+DQo+ICAgICBGb3IgdGhlIHN0YXRlZnVsIHNlcnZpY2UgZnVuY3Rpb25zLCBpZiBhIGZsb3cg aXMgc3dpdGNoZWQgZnJvbQ0KPiAgICAgU0YtSW5zdGFuY2UtWCB0byBTRi1JbnN0YW5jZS1ZLCB0 aGUgU0YtSW5zdGFuY2UtWSBuZWVkcyB0bw0KPiAgICAgc3luY2hyb25pemUgdGhlIHN0YXRlcyBm cm9tIFNGLUluc3RhbmNlLVguIFdobyBpcyByZXNwb25zaWJsZSBmb3INCj4gICAgIHRob3NlIHN0 YXRlcyBtYWludGVuYW5jZSBmb3IgdGhlIExvYWQgQmFsYW5jaW5nIGRlc2NyaWJlZCBpbiBGaWd1 cmUgNT8NCj4NCj4gICAgIDxrZWc+IE5vbmUgb2YgdGhvc2UgZW50aXRpZXMgZXhpc3QgaW4gRmln dXJlIDUuICBDYW4geW91IHJlLXBocmFzZQ0KPiAgICAgeW91ciBxdWVzdGlvbiBmcm9tIHRoZSBm aWd1cmU/DQo+DQo+ICAgICBMaW5kYQ0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+DQo+IFJl cXVpcmUgcHVzaGluZyBwb2xpY2llcyB0byBTRjEgb24gaG93IHRvIGxvYWQgYmFsYW5jZSBtdWx0 aXBsZSANCj4gaW5zdGFuY2VzIG9mIFNGMi4NCj4NCj4gU0YxIG1heSBub3QgaGF2ZSB0aGUgY2Fw YWJpbGl0eSB0byBiYWxhbmNlIGFtb25nIG11bHRpcGxlIGluc3RhbmNlcyBvZg0KPiBTRjINCj4N Cj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Fri May 30 08:03:20 2014 Return-Path: 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 73F901A0997 for ; Fri, 30 May 2014 08:03:18 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 oCsJrb5oarth for ; Fri, 30 May 2014 08:03:13 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D42F1A0789 for ; Fri, 30 May 2014 08:03:13 -0700 (PDT) X-AuditID: c618062d-f79be6d000006b89-e7-53884d793dbd Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id C2.5F.27529.97D48835; Fri, 30 May 2014 11:20:58 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Fri, 30 May 2014 11:03:06 -0400 From: Eric Gray To: Linda Dunbar , Lucy yong , "Jakob Heitz (jheitz)" , Joel Halpern , "Paul Quinn (paulq)" Thread-Topic: Figures in draft-quinn-sfc-arch-05 Thread-Index: Ac97S9R6mfocA+1iTpKXBfVlibSBggAGJh5AAACjtcAAAHRWQAAFiSTQAAEryZAAAFNDAAAjvoJw Date: Fri, 30 May 2014 15:03:06 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF632AD1504@eusaamb107.ericsson.se> References: <48E1A67CB9CA044EADFEAB87D814BFF632AD0443@eusaamb107.ericsson.se> <075DE01702BBC249BE1357EFD20DCFE556E2EC@xmb-aln-x02.cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD07D6@eusaamb107.ericsson.se> <2691CE0099834E4A9C5044EEC662BB9D45389B2C@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645D290DA@dfweml701-chm.china.huawei.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD0B1B@eusaamb107.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645D29193@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D29193@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF632AD1504eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyuXSPn26Vb0ewwalfAhZvNzWyWdxtmchk sfHXIjaL/a+Wslo8ebCV3YHVY8rvjaweLUfesnosWfKTKYA5issmJTUnsyy1SN8ugStj7r0F jAWfpjJX3Pvyg6mBcdEjpi5GTg4JAROJb/9fM0LYYhIX7q1n62Lk4hASOMoosW7SHCYIZzmj xPnX68Gq2AQ0JI7dWQtmiwicZZS4etIExGYWUJR4dOs32FRhAX2JbW2P2SBqDCQeLO6Gqo+S OHdyPjOIzSKgKnFwwhowm1fAV+LprEnMEMt+MUuceLEKbBCnQJjEmtf/2EFsRqDzvp9awwSx TFzi1pP5UC8ISCzZc54ZwhaVePn4HyuErSTx8fd8doj6fIk3f9YxQiwTlDg58wnLBEbRWUhG zUJSNgtJGURcR2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/FyFFanFqWm25ksIkRGIXHJNh0 dzDueWl5iFGAg1GJh1eBtT1YiDWxrLgy9xCjNAeLkjiv9s2qYCGB9MSS1OzU1ILUovii0pzU 4kOMTBycUg2M1f4cYvWlkcv8o+vi/3zbs8amYNq0WbftKq8ePcchv4bVpMvvXnngPvcp617s 5QysKp1/p7j5QeyJ6NDDOYYZzPeE38pEl4o8TRPqWOV0Lreuv65zU6KOhmeVxrKKxoxTy7PW rjtlt8Cdj6Ev/PCe0gfXv8n+5MuL4jGckV5UsdTp3uc403lKLMUZiYZazEXFiQBK8aNDowIA AA== Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/EvZa8ZeCbEKnsioMI6i27uZDKo8 Cc: "sfc@ietf.org" Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 15:03:18 -0000 --_000_48E1A67CB9CA044EADFEAB87D814BFF632AD1504eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Linda, It may be a mathematically correct expression (depending on= interpretation of the notation used), but networking is not necessarily (possibly even usu= ally) a mathematical operation. There is nothing "intuitively obvious" in this expression t= hat makes it clear that "load sharing" is taking place between the sets of sf2 and sf4 instanc= es, or how the "or" operation takes place. One literal way to interpret this notation (as a mathematic= al expression) is that each the functions sf2, sf2' and sf2" are "visited" sequentially and p= assed on to sf3 as soon as it succeeds in any of the functions. With this interpret= ation, since the service function performed at each sf2 instance is presumed to be ident= ical, what the expression means is that either the service function will succeed = at sf2 (and always skip sf2' and sf2"), or that it will fail at each sf2 instance. An equally legitimate "parallel computing" (not exactly mat= hematical, but possibly viewed as more closely analogous to networking) interpretation wou= ld be that processing passes (on success at sf1) to each of sf2, sf2' and sf2"= in parallel and then proceeds to sf3 on success at any of the sf2 instances. None of these interpretations corresponds to "load sharing= " - yet all are perfectly legitimate interpretation of your suggested expression/notation. And yet, these are actually more common interpretation of t= he usage of an "or" operation to computing folks (which many of us are), depending on t= heir specific background in computing. As I said before, I have no objection to the suggested nota= tion you and Lucy proposed - provided that the notation is explained. I am unclear as t= o what value this usage - and included explanation may have - but this is largely = a style issue, and best left up to the draft editors at this point. And, as I also said, there may be others who would prefer n= ot to have too much textual explanation necessary in order to understand a figure. Finally, you must realize that there are a fairly large num= ber of folks who read-over mathematical expressions as if they were written in a foreign lan= guage. For this reason, even if it were a perfectly useful/correct mathematical ex= pression, a number of folks would still need a picture. -- Eric From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Thursday, May 29, 2014 5:42 PM To: Eric Gray; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (p= aulq) Cc: sfc@ietf.org Subject: RE: Figures in draft-quinn-sfc-arch-05 Importance: High Eric, How about this shorter one? ->{sf1}->{sf2|sf2'|sf2''}->{sf3}->{sf4|sf4'|sf4''}->{sf5}-> The intent is pretty simple: If a service function on a chain has multiple = instances, one of the service function's instances is selected to treat pac= kets belonging to the service chain. This is a correct mathematics expression. There is really no need draw all those boxes. Linda From: Eric Gray [mailto:eric.gray@ericsson.com] Sent: Thursday, May 29, 2014 4:23 PM To: Linda Dunbar; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn= (paulq) Cc: sfc@ietf.org Subject: RE: Figures in draft-quinn-sfc-arch-05 Linda, By the way, your proposal for Figure 5 would require a column width of at l= east 80 characters (more than you are supposed to have in an ID), and the situation= would be worse if it were applied to figure 6. For figure 5, you can improve the width slightly by fixing up a few of your= arrows, and even more by wrapping the figure. Wrapping might detract from simplic= ity, however. -- Eric From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Thursday, May 29, 2014 4:49 PM To: Lucy yong; Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (p= aulq) Cc: sfc@ietf.org Subject: RE: Figures in draft-quinn-sfc-arch-05 Importance: High I like the Figures drawn by Lucy. Actually why can't Figure 5 be simplified as enter -->{sf1}-->-{sf2|sf2'|sf2''}->--{sf3}-->-{sf4|sf4'|sf4''}->--{sf5= }--> exit ?? Linda From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong Sent: Thursday, May 29, 2014 1:12 PM To: Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 For readability on these figures, propose: Figure 5: +-sf2-+ +-sf4-+ | | | | enter -->sf1-->-sf2->--sf3-->-sf4->--sf5--> exit | | | | +-sf2-+ +-sf4-+ Figure 6: +-sf2-+ +-sf4-+ | | | | enter -->{sf1|sf1'}-->-sf2->--{sf3|sf3'}-->-sf4->--{sf5}--> exit | | | | +-sf2-+ +-sf4-+ lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray Sent: Thursday, May 29, 2014 12:54 PM To: Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 HaHa, funny man. :) From: Jakob Heitz (jheitz) [mailto:jheitz@cisco.com] Sent: Thursday, May 29, 2014 1:43 PM To: Eric Gray; Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: RE: Figures in draft-quinn-sfc-arch-05 Importance: High You could turn the whole picture right by 90 degrees. If you don't like top to bottom instead of left to right, make a note that = it's in landscape. --Jakob From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray Sent: Thursday, May 29, 2014 8:31 AM To: Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: [sfc] Figures in draft-quinn-sfc-arch-05 Paul/Joel, Pretty sure that Figures 5 and 6 don't actually fit the wid= th expected for an Internet Draft (Figure 5 is more than 80 characters wide and Figure 6 is wi= der still). Depending on how a reader tries to read the draft, this can= turn complicated illustrations into a _real_ fun time. :) Also, I am unsure what the figures are trying to convey wit= h some of "dotted lines" crossing the service functions. If the intent is to show that a ser= vice function is a virtual instance hosted by some network device, perhaps this will be bett= er shown in a separate figure and this aspect of Figures 5 and 6 can be eliminated? I would suggest replacing Figure 5 with a figure along the lines of: source +-----+ +-----+ | +-->| sf2 +--+ +-->| sf4 +--+ | | | | | | | | | | +------+--+ +-----+ +-->+-----+--+ +-----+ +->+-----+ | | sf1 | +-----+ | sf3 | +-----+ | sf5 | +->| +----->| sf2 +----->| |----->| sf4 +---->| |-+ | | | | | | | | | | | +------+--+ +-----+ +-->+-----+--+ +-----+ +->+-----+ | | +-----+ | | +-----+ | | +-->| sf2 +--+ +-->| sf4 +--+ +----+ | | | | | +-----+ +-----+ V destination Figure 5: Load Balancing (67 characters?) Similarly, I would suggest replacing Figure 6 with a figure= along the lines of: source | +-----+-+ +-----+-+ +---+ +-->| sf2 |-|+ +-->| sf4 |-|+ | +---|-->| | || +------>| | || | +------+|---+ +-----+ |+-->+-----+|---+ +-----+ |+-->+-----+ | | sf1 || +-----+ +--->| sf3 || +-----+ +--->| sf5 | +-->| +|------>| sf2 |+---->| ||------>| sf4 |+---->| |--+ | | || +---->| |-+ | || +---->| |-+ | | | | +------+|-|-+ +-----+ |+-->+-----+|-|-+ +-----+ |+-->+-----+ | | | | | +-----+ || | | | +-----+ || | | +------++ | +-->| sf2 |-|+ +-----++ | +-->| sf4 |-|+ +-----+ | | | sf1' | | +-->| | +--->| sf3'| | +-->| | +--->| sf5'| | +-->| +--+ | +-----+----->| |--+ | +-----+----->| |--+ | | | | | | | | | +------+----+ +-----+----+ +-----+ | | +--------+ | V destination Figure 6: Load Balancing and HA (72 characters?) In both cases, the figure has all the same connection compl= exity (fixed up in a few places), but seems to be less busy. -- Eric --_000_48E1A67CB9CA044EADFEAB87D814BFF632AD1504eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Linda,

     

       &nbs= p;            It may= be a mathematically correct expression (depending on interpretation

    of the notation used),= but networking is not necessarily (possibly even usually) a

    mathematical operation= .

     

       &nbs= p;            There = is nothing “intuitively obvious” in this expression that makes = it clear

    that “load shari= ng” is taking place between the sets of sf2 and sf4 instances, or how=

    the “or” o= peration takes place.

     

       &nbs= p;            One li= teral way to interpret this notation (as a mathematical expression) is=

    that each the function= s sf2, sf2’ and sf2” are “visited” sequentially and= passed on

    to sf3 ­as s= oon as it succeeds in any of the functions.  With this interpr= etation, since

    the service function p= erformed at each sf2 instance is presumed to be identical,

    what the expression me= ans is that either the service function will succeed at sf2

    (and always skip sf2&#= 8217; and sf2”), or that it will fail at each sf2 instance.

     

       &nbs= p;            An equ= ally legitimate “parallel computing” (not exactly mathematical,= but

    possibly viewed as mor= e closely analogous to networking) interpretation would

    be that processing pas= ses (on success at sf1) to each of sf2, sf2’ and sf2” in parallel=

    and then proceeds to s= f3 on success at any of the sf2 instances.

     

       &nbs= p;            None o= f these interpretations corresponds to  “load sharing” = 211; yet all are

    perfectly legitimate i= nterpretation of your suggested expression/notation.

     

       &nbs= p;            And ye= t, these are actually more common interpretation of the usage of=

    an “or” op= eration to computing folks (which many of us are), depending on their<= /o:p>

    specific background in= computing.

     

       &nbs= p;            As I s= aid before, I have no objection to the suggested notation you and

    Lucy proposed – = provided that the notation is explained.  I am unclear as to what=

    value this usage ̵= 1; and included explanation may have – but this is largely a style

    issue, and best left u= p to the draft editors at this point.

     

       &nbs= p;            And, a= s I also said, there may be others who would prefer not to have too

    much textual explanati= on necessary in order to understand a figure.

     

       &nbs= p;            Finall= y, you must realize that there are a fairly large number of folks who<= /o:p>

    read-over mathematical= expressions as if they were written in a foreign language.

    For this reason, even = if it were a perfectly useful/correct mathematical expression,

    a number of folks woul= d still need a picture.

     

    --

    Eric=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei.com]
    Sent: Thursday, May 29, 2014 5:42 PM
    To: Eric Gray; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Paul Q= uinn (paulq)
    Cc: sfc@ietf.org
    Subject: RE: Figures in draft-quinn-sfc-arch-05
    Importance: High

     

    Eric,

     

    How about this shorter= one?

     

    ->{sf1}->{sf2|sf2’|sf2’’}->{sf3}= ->{sf4|sf4’|sf4’’}->{sf5}->

     

    The intent is pretty s= imple: If a service function on a chain has multiple instances, one of the = service function’s instances is selected to treat packets belonging t= o the service chain.  

     

    This is a correct math= ematics expression.

    There is really no nee= d draw all those boxes.

     

    Linda  

     

     

    Linda,

     

    By the way, your propo= sal for Figure 5 would require a column width of at least 80

    characters (more than = you are supposed to have in an ID), and the situation would

    be worse if it were ap= plied to figure 6.

     

    For figure 5, you can = improve the width slightly by fixing up a few of your arrows,

    and even more by wrapp= ing the figure.  Wrapping  might detract from simplicity,

    however.

     

    --

    Eric=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei= .com]
    Sent: Thursday, May 29, 2014 4:49 PM
    To: Lucy yong; Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Q= uinn (paulq)
    Cc: sfc@ietf.org
    Subject: RE: Figures in draft-quinn-sfc-arch-05
    Importance: High

     

    I like the Figures dra= wn by Lucy.

     

    Actually why can’= ;t Figure 5 be simplified as

     

        enter --&g= t;{sf1}-->-{sf2|sf2’|sf2’’}->--{sf3}-->-{sf4|sf4= ’|sf4’’}->--{sf5}--> exit

     

    ??

     

    Linda

     

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong
    Sent: Thursday, May 29, 2014 1:12 PM
    To: Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq= )
    Cc: sfc@ietf.org
    Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05

     

    For readability on the= se figures, propose:

     

    Figure 5:

         = ;            &n= bsp;   +-sf2-+       +-= sf4-+

         = ;            &n= bsp;   |     |     &= nbsp; |     |

         = ;  enter -->sf1-->-sf2->--sf3-->-sf4->--sf5--> exit<= o:p>

         = ;            &n= bsp;   |     |     &= nbsp; |     |

         = ;            &n= bsp;   +-sf2-+       +-= sf4-+

    Figure 6:

     

         = ;            &n= bsp;       +-sf2-+   &= nbsp;          +-sf4-+=

         = ;            &n= bsp;       |     | &= nbsp;            |&n= bsp;    |

        enter --&g= t;{sf1|sf1'}-->-sf2->--{sf3|sf3'}-->-sf4->--{sf5}--> exit

         = ;            &n= bsp;       |     | &= nbsp;            |&n= bsp;    |

              = ;            &n= bsp;  +-sf2-+        &= nbsp;     +-sf4-+=

     

    lucy=

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray
    Sent: Thursday, May 29, 2014 12:54 PM
    To: Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq)
    Cc: sfc@ietf.org
    Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05

     

    HaHa, funny man. = J

     

    From: Jakob He= itz (jheitz) [mailto:jheitz@cisco.com]
    Sent: Thursday, May 29, 2014 1:43 PM
    To: Eric Gray; Joel Halpern; Paul Quinn (paulq)
    Cc:     sfc@ietf.org
    Subject: RE: Figures in draft-quinn-sfc-arch-05
    Importance: High

     

    You could turn the whole picture right by = 90 degrees.

    If you don’t like top to bottom inst= ead of left to right, make a note that it’s in landscape.<= /span>

     

    --Jakob

     

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray
    Sent: Thursday, May 29, 2014 8:31 AM
    To: Joel Halpern; Paul Quinn (paulq)
    Cc: sfc@ietf.org
    Subject: [sfc] Figures in draft-quinn-sfc-arch-05    <= /p>

     

    Paul/Joel,

     

            &nbs= p;       Pretty sure that Figures 5 and 6 don= ’t actually fit the width expected for an

    Internet Draft (Figure 5 is more than 80 characters = wide and Figure 6 is wider still).

     

            &nbs= p;       Depending on how a reader tries to r= ead the draft, this can turn complicated

    illustrations into a _real_ fun time.  <= span style=3D"font-family:Wingdings"> J

     

            &nbs= p;       Also, I am unsure what the figures a= re trying to convey with some of “dotted

    lines” crossing the service functions.  I= f the intent is to show that a service function is

    a virtual instance hosted by some network device, pe= rhaps this will be better shown

    in a separate figure and this aspect of Figures 5 an= d 6 can be eliminated?

     

    I would suggest replacing= Figure 5 with a figure along the lines of:

     

    source &nbs= p;           +--= ---+           &= nbsp;       +-----+=

      = ;|            +-= ->| sf2 +--+        &nbs= p;   +-->| sf4 +--+

      = ;|            | = ;  |     |  |     &n= bsp;      |   |     = |  |

      = ;|  +------+--+   +-----+  +--&= gt;+-----+--+   +-----+  +->+= -----+

      = ;|  | sf1  |      +-----+ &= nbsp;    | sf3 |      +-----= 3;     | sf5 |

      = ;+->|      +----->| sf2 +-----&g= t;|     |----->| sf4 +---->|   = ;  |-+

      = ;   |      |    &nbs= p; |     |      | &n= bsp;   |      |     = |     |     | |

      = ;   +------+--+   +-----+ = ; +-->+-----+--+   +-----+  += ->+-----+ |

      = ;            &n= bsp;|   +-----+  |     &nbs= p;      |   +-----+  | &nbs= p;        |

      = ;            &n= bsp;+-->| sf2 +--+       =      +-->| sf4 +--+    &n= bsp;+----+

      = ;            &n= bsp;    |     |   &n= bsp;            &nbs= p;  |     |      &nb= sp; |

      = ;            &n= bsp;    +-----+     &n= bsp;            &nbs= p;+-----+        V

      = ;            &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p;     destination

     =

      = ;            &n= bsp;    Figure 5: Load Balancing

     

    (67 characters?)

     

            &nbs= p;       Similarly, I would suggest replacing= Figure 6 with a figure along the

    lines of:

     

       source
         |       &n=
bsp;       +-----+-+ &n=
bsp;            =
;     +-----+-+
     +---+        &nb=
sp;  +-->| sf2 |-|+      &nbs=
p;       +-->| sf4 |-|+=

     |           &#=
43;---|-->|     | ||     &n=
bsp;    +------>|     | ||
     |   +------+|---+   +-----&#=
43; |+-->+-----+|---+   +-----+ |+=
-->+-----+
     |   | sf1  ||      =
 +-----+ +--->| sf3 ||       &=
#43;-----+ +--->| sf5 |
     +-->|      +|------>| sf2=
 |+---->|     ||------>| sf4 |+---->|&=
nbsp;    |--+
     |   |      || +---->|&=
nbsp;    |-+    |    =
 || +---->|     |-+    | =
;    |  |
     |   +------+|-|-+   +-----&#=
43; |+-->+-----+|-|-+   +-----+ |+=
-->+-----+  |
     |           | =
| |   +-----+ ||       =
;   | | |   +-----+ ||    &=
nbsp;       |
     |   +------++ | +-->| sf2 |-|+&=
nbsp;  +-----++ | +-->| sf4 |-|+   &#=
43;-----+  |
     |   | sf1' |  | +-->|   &nb=
sp; | +--->| sf3'|  | +-->|     | &#=
43;--->| sf5'|  |
     +-->|      +--+ | &=
nbsp; +-----+----->|     |--+ | &nb=
sp; +-----+----->|     |--+
         |      | &=
nbsp;  |          &n=
bsp;     |     |    =
|            &n=
bsp;   |     |  |

         +------+----+  &nb=
sp;            =
 +-----+----+        &n=
bsp;       +-----+  |=

    

               =
;             &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;         |=

    

               =
;            &n=
bsp;            =
;            &n=
bsp;            =
; +--------+
    

               =
;            &n=
bsp;            =
;            &n=
bsp;            =
; |
    

               =
;            &n=
bsp;            &nbs=
p;            &=
nbsp;           &nbs=
p;V
    

               =
;            &n=
bsp;            =
;            &n=
bsp;        destination
    

     
    

               =
;         Figure 6: Load Balancing =
and HA
    

     
    

    (72 characters?)
    

     
    

            &nbs=
p;       In both cases, the figure has all th=
e same connection complexity (fixed up in a few
    

    places), but seems to be less busy.
    

     
    

    --
    

    Eric
    --_000_48E1A67CB9CA044EADFEAB87D814BFF632AD1504eusaamb107erics_-- From nobody Fri May 30 10:55:20 2014 Return-Path: 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 BFD971A09D3 for ; Fri, 30 May 2014 10:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 wXNGi7JDFVoC for ; Fri, 30 May 2014 10:55:14 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A65A21A036A for ; Fri, 30 May 2014 10:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=54450; q=dns/txt; s=iport; t=1401472509; x=1402682109; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=a64SyB+NI+TNDEWRY2HHfcHVF4HP5BjNmdDGRH2Ukrw=; b=ju3ZkG+owrzV+IqWpSLnsBCj5BgzcbCgItokB/tVnkxe8uvD/Zo0PyPD oX5kZGg/SP1pE/tiAhOo7lO/e2t78z05SiOx9oLeCNEnLpQ9iEFq6rSrE ngPx2eKKdh2aPz/8laSTTIcyZiVRvk3t+mw7vhBCali90dO+5ScdfR6Xr o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcIAEPFiFOtJV2U/2dsb2JhbABZgkJFUlUDvhsBhCABgQkWdIIlAQEBAgInBkwQAgEIEQQBAQsWAQYHMhQJCAIEAQ0FCIg6DdZ8F4kzhDwyMQYBgyuBFQSVepcxgzhsgUM X-IronPort-AV: E=Sophos;i="4.98,942,1392163200"; d="scan'208,217";a="329257945" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-6.cisco.com with ESMTP; 30 May 2014 17:55:01 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s4UHt15D003173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 May 2014 17:55:01 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.121]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Fri, 30 May 2014 12:55:01 -0500 From: "Jakob Heitz (jheitz)" To: Eric Gray , Linda Dunbar , Lucy yong , Joel Halpern , "Paul Quinn (paulq)" Thread-Topic: Figures in draft-quinn-sfc-arch-05 Thread-Index: Ac97S9R6mfocA+1iTpKXBfVlibSBggAGJh5AAACjtcAAAHRWQAAFiSTQAAEryZAAAFNDAAAjvoJwAAcI2MA= Date: Fri, 30 May 2014 17:55:00 +0000 Message-ID: <075DE01702BBC249BE1357EFD20DCFE556F732@xmb-aln-x02.cisco.com> References: <48E1A67CB9CA044EADFEAB87D814BFF632AD0443@eusaamb107.ericsson.se> <075DE01702BBC249BE1357EFD20DCFE556E2EC@xmb-aln-x02.cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD07D6@eusaamb107.ericsson.se> <2691CE0099834E4A9C5044EEC662BB9D45389B2C@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645D290DA@dfweml701-chm.china.huawei.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD0B1B@eusaamb107.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645D29193@dfweml701-chm.china.huawei.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD1504@eusaamb107.ericsson.se> In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF632AD1504@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.165.107] Content-Type: multipart/alternative; boundary="_000_075DE01702BBC249BE1357EFD20DCFE556F732xmbalnx02ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/3TDcRBTe-h9Dp2Bx0M1ncCYZTe8 Cc: "sfc@ietf.org" Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 17:55:20 -0000 --_000_075DE01702BBC249BE1357EFD20DCFE556F732xmbalnx02ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is a good example of an RFC with readable diagrams http://www.rfc-editor.org/rfc/rfc1131.pdf How did he upload that? --Jakob From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray Sent: Friday, May 30, 2014 8:03 AM To: Linda Dunbar; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn= (paulq) Cc: sfc@ietf.org Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 Linda, It may be a mathematically correct expression (depending on= interpretation of the notation used), but networking is not necessarily (possibly even usu= ally) a mathematical operation. There is nothing "intuitively obvious" in this expression t= hat makes it clear that "load sharing" is taking place between the sets of sf2 and sf4 instanc= es, or how the "or" operation takes place. One literal way to interpret this notation (as a mathematic= al expression) is that each the functions sf2, sf2' and sf2" are "visited" sequentially and p= assed on to sf3 as soon as it succeeds in any of the functions. With this interpret= ation, since the service function performed at each sf2 instance is presumed to be ident= ical, what the expression means is that either the service function will succeed = at sf2 (and always skip sf2' and sf2"), or that it will fail at each sf2 instance. An equally legitimate "parallel computing" (not exactly mat= hematical, but possibly viewed as more closely analogous to networking) interpretation wou= ld be that processing passes (on success at sf1) to each of sf2, sf2' and sf2"= in parallel and then proceeds to sf3 on success at any of the sf2 instances. None of these interpretations corresponds to "load sharing= " - yet all are perfectly legitimate interpretation of your suggested expression/notation. And yet, these are actually more common interpretation of t= he usage of an "or" operation to computing folks (which many of us are), depending on t= heir specific background in computing. As I said before, I have no objection to the suggested nota= tion you and Lucy proposed - provided that the notation is explained. I am unclear as t= o what value this usage - and included explanation may have - but this is largely = a style issue, and best left up to the draft editors at this point. And, as I also said, there may be others who would prefer n= ot to have too much textual explanation necessary in order to understand a figure. Finally, you must realize that there are a fairly large num= ber of folks who read-over mathematical expressions as if they were written in a foreign lan= guage. For this reason, even if it were a perfectly useful/correct mathematical ex= pression, a number of folks would still need a picture. -- Eric From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Thursday, May 29, 2014 5:42 PM To: Eric Gray; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (p= aulq) Cc: sfc@ietf.org Subject: RE: Figures in draft-quinn-sfc-arch-05 Importance: High Eric, How about this shorter one? ->{sf1}->{sf2|sf2'|sf2''}->{sf3}->{sf4|sf4'|sf4''}->{sf5}-> The intent is pretty simple: If a service function on a chain has multiple = instances, one of the service function's instances is selected to treat pac= kets belonging to the service chain. This is a correct mathematics expression. There is really no need draw all those boxes. Linda From: Eric Gray [mailto:eric.gray@ericsson.com] Sent: Thursday, May 29, 2014 4:23 PM To: Linda Dunbar; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn= (paulq) Cc: sfc@ietf.org Subject: RE: Figures in draft-quinn-sfc-arch-05 Linda, By the way, your proposal for Figure 5 would require a column width of at l= east 80 characters (more than you are supposed to have in an ID), and the situation= would be worse if it were applied to figure 6. For figure 5, you can improve the width slightly by fixing up a few of your= arrows, and even more by wrapping the figure. Wrapping might detract from simplic= ity, however. -- Eric From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Thursday, May 29, 2014 4:49 PM To: Lucy yong; Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (p= aulq) Cc: sfc@ietf.org Subject: RE: Figures in draft-quinn-sfc-arch-05 Importance: High I like the Figures drawn by Lucy. Actually why can't Figure 5 be simplified as enter -->{sf1}-->-{sf2|sf2'|sf2''}->--{sf3}-->-{sf4|sf4'|sf4''}->--{sf5= }--> exit ?? Linda From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong Sent: Thursday, May 29, 2014 1:12 PM To: Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 For readability on these figures, propose: Figure 5: +-sf2-+ +-sf4-+ | | | | enter -->sf1-->-sf2->--sf3-->-sf4->--sf5--> exit | | | | +-sf2-+ +-sf4-+ Figure 6: +-sf2-+ +-sf4-+ | | | | enter -->{sf1|sf1'}-->-sf2->--{sf3|sf3'}-->-sf4->--{sf5}--> exit | | | | +-sf2-+ +-sf4-+ lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray Sent: Thursday, May 29, 2014 12:54 PM To: Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 HaHa, funny man. :) From: Jakob Heitz (jheitz) [mailto:jheitz@cisco.com] Sent: Thursday, May 29, 2014 1:43 PM To: Eric Gray; Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: RE: Figures in draft-quinn-sfc-arch-05 Importance: High You could turn the whole picture right by 90 degrees. If you don't like top to bottom instead of left to right, make a note that = it's in landscape. --Jakob From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray Sent: Thursday, May 29, 2014 8:31 AM To: Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: [sfc] Figures in draft-quinn-sfc-arch-05 Paul/Joel, Pretty sure that Figures 5 and 6 don't actually fit the wid= th expected for an Internet Draft (Figure 5 is more than 80 characters wide and Figure 6 is wi= der still). Depending on how a reader tries to read the draft, this can= turn complicated illustrations into a _real_ fun time. :) Also, I am unsure what the figures are trying to convey wit= h some of "dotted lines" crossing the service functions. If the intent is to show that a ser= vice function is a virtual instance hosted by some network device, perhaps this will be bett= er shown in a separate figure and this aspect of Figures 5 and 6 can be eliminated? I would suggest replacing Figure 5 with a figure along the lines of: source +-----+ +-----+ | +-->| sf2 +--+ +-->| sf4 +--+ | | | | | | | | | | +------+--+ +-----+ +-->+-----+--+ +-----+ +->+-----+ | | sf1 | +-----+ | sf3 | +-----+ | sf5 | +->| +----->| sf2 +----->| |----->| sf4 +---->| |-+ | | | | | | | | | | | +------+--+ +-----+ +-->+-----+--+ +-----+ +->+-----+ | | +-----+ | | +-----+ | | +-->| sf2 +--+ +-->| sf4 +--+ +----+ | | | | | +-----+ +-----+ V destination Figure 5: Load Balancing (67 characters?) Similarly, I would suggest replacing Figure 6 with a figure= along the lines of: source | +-----+-+ +-----+-+ +---+ +-->| sf2 |-|+ +-->| sf4 |-|+ | +---|-->| | || +------>| | || | +------+|---+ +-----+ |+-->+-----+|---+ +-----+ |+-->+-----+ | | sf1 || +-----+ +--->| sf3 || +-----+ +--->| sf5 | +-->| +|------>| sf2 |+---->| ||------>| sf4 |+---->| |--+ | | || +---->| |-+ | || +---->| |-+ | | | | +------+|-|-+ +-----+ |+-->+-----+|-|-+ +-----+ |+-->+-----+ | | | | | +-----+ || | | | +-----+ || | | +------++ | +-->| sf2 |-|+ +-----++ | +-->| sf4 |-|+ +-----+ | | | sf1' | | +-->| | +--->| sf3'| | +-->| | +--->| sf5'| | +-->| +--+ | +-----+----->| |--+ | +-----+----->| |--+ | | | | | | | | | +------+----+ +-----+----+ +-----+ | | +--------+ | V destination Figure 6: Load Balancing and HA (72 characters?) In both cases, the figure has all the same connection compl= exity (fixed up in a few places), but seems to be less busy. -- Eric --_000_075DE01702BBC249BE1357EFD20DCFE556F732xmbalnx02ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Here is a good example of an RFC with read= able diagrams

    http://www.rfc-editor.org/rfc/rfc1131.pdf=

     

    How did he upload that?<= /p>

     

    --Jakob

     

    From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Eric Gray
    Sent: Friday, May 30, 2014 8:03 AM
    To: Linda Dunbar; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Pau= l Quinn (paulq)
    Cc: sfc@ietf.org
    Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05

     

    Linda,

     

       &nbs= p;            It may= be a mathematically correct expression (depending on interpretation

    of the notation used),= but networking is not necessarily (possibly even usually) a

    mathematical operation= .

     

       &nbs= p;            There = is nothing “intuitively obvious” in this expression that makes = it clear

    that “load shari= ng” is taking place between the sets of sf2 and sf4 instances, or how=

    the “or” o= peration takes place.

     

       &nbs= p;            One li= teral way to interpret this notation (as a mathematical expression) is=

    that each the function= s sf2, sf2’ and sf2” are “visited” sequentially and= passed on

    to sf3 ­as s= oon as it succeeds in any of the functions.  With this interpr= etation, since

    the service function p= erformed at each sf2 instance is presumed to be identical,

    what the expression me= ans is that either the service function will succeed at sf2

    (and always skip sf2&#= 8217; and sf2”), or that it will fail at each sf2 instance.

     

       &nbs= p;            An equ= ally legitimate “parallel computing” (not exactly mathematical,= but

    possibly viewed as mor= e closely analogous to networking) interpretation would

    be that processing pas= ses (on success at sf1) to each of sf2, sf2’ and sf2” in parallel=

    and then proceeds to s= f3 on success at any of the sf2 instances.

     

       &nbs= p;            None o= f these interpretations corresponds to  “load sharing” = 211; yet all are

    perfectly legitimate i= nterpretation of your suggested expression/notation.

     

       &nbs= p;            And ye= t, these are actually more common interpretation of the usage of=

    an “or” op= eration to computing folks (which many of us are), depending on their<= /o:p>

    specific background in= computing.

     

       &nbs= p;            As I s= aid before, I have no objection to the suggested notation you and

    Lucy proposed – = provided that the notation is explained.  I am unclear as to what=

    value this usage ̵= 1; and included explanation may have – but this is largely a style

    issue, and best left u= p to the draft editors at this point.

     

       &nbs= p;            And, a= s I also said, there may be others who would prefer not to have too

    much textual explanati= on necessary in order to understand a figure.

     

       &nbs= p;            Finall= y, you must realize that there are a fairly large number of folks who<= /o:p>

    read-over mathematical= expressions as if they were written in a foreign language.

    For this reason, even = if it were a perfectly useful/correct mathematical expression,

    a number of folks woul= d still need a picture.

     

    --

    Eric=

     

    From: Linda Du= nbar [mailto:linda.dunbar@hu= awei.com]
    Sent: Thursday, May 29, 2014 5:42 PM
    To: Eric Gray; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Paul Q= uinn (paulq)
    Cc: sfc@ietf.org
    Subject: RE: Figures in draft-quinn-sfc-arch-05
    Importance: High

     

    Eric,

     

    How about this shorter= one?

     

    ->{sf1}->{sf2|sf2’|sf2’’}->{sf3}= ->{sf4|sf4’|sf4’’}->{sf5}->

     

    The intent is pretty s= imple: If a service function on a chain has multiple instances, one of the = service function’s instances is selected to treat packets belonging t= o the service chain.  

     

    This is a correct math= ematics expression.

    There is really no nee= d draw all those boxes.

     

    Linda  

     

     

    Linda,

     

    By the way, your propo= sal for Figure 5 would require a column width of at least 80

    characters (more than = you are supposed to have in an ID), and the situation would

    be worse if it were ap= plied to figure 6.

     

    For figure 5, you can = improve the width slightly by fixing up a few of your arrows,

    and even more by wrapp= ing the figure.  Wrapping  might detract from simplicity,

    however.

     

    --

    Eric=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei= .com]
    Sent: Thursday, May 29, 2014 4:49 PM
    To: Lucy yong; Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Q= uinn (paulq)
    Cc: sfc@ietf.org
    Subject: RE: Figures in draft-quinn-sfc-arch-05
    Importance: High

     

    I like the Figures dra= wn by Lucy.

     

    Actually why can’= ;t Figure 5 be simplified as

     

        enter --&g= t;{sf1}-->-{sf2|sf2’|sf2’’}->--{sf3}-->-{sf4|sf4= ’|sf4’’}->--{sf5}--> exit

     

    ??

     

    Linda

     

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong
    Sent: Thursday, May 29, 2014 1:12 PM
    To: Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq= )
    Cc: sfc@ietf.org
    Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05

     

    For readability on the= se figures, propose:

     

    Figure 5:

         = ;            &n= bsp;   +-sf2-+       +-= sf4-+

         = ;            &n= bsp;   |     |     &= nbsp; |     |

         = ;  enter -->sf1-->-sf2->--sf3-->-sf4->--sf5--> exit<= o:p>

         = ;            &n= bsp;   |     |     &= nbsp; |     |

         = ;            &n= bsp;   +-sf2-+       +-= sf4-+

    Figure 6:

     

         = ;            &n= bsp;       +-sf2-+   &= nbsp;          +-sf4-+=

         = ;            &n= bsp;       |     | &= nbsp;            |&n= bsp;    |

        enter --&g= t;{sf1|sf1'}-->-sf2->--{sf3|sf3'}-->-sf4->--{sf5}--> exit

         = ;            &n= bsp;       |     | &= nbsp;            |&n= bsp;    |

              = ;            &n= bsp;  +-sf2-+        &= nbsp;     +-sf4-+=

     

    lucy=

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray
    Sent: Thursday, May 29, 2014 12:54 PM
    To: Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq)
    Cc: sfc@ietf.org
    Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05

     

    HaHa, funny man. = J

     

    From: Jakob He= itz (jheitz) [mailto:jheitz@cisco.com]
    Sent: Thursday, May 29, 2014 1:43 PM
    To: Eric Gray; Joel Halpern; Paul Quinn (paulq)
    Cc:     sfc@ietf.org
    Subject: RE: Figures in draft-quinn-sfc-arch-05
    Importance: High

     

    You could turn the whole picture right by = 90 degrees.

    If you don’t like top to bottom inst= ead of left to right, make a note that it’s in landscape.<= /span>

     

    --Jakob

     

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray
    Sent: Thursday, May 29, 2014 8:31 AM
    To: Joel Halpern; Paul Quinn (paulq)
    Cc: sfc@ietf.org
    Subject: [sfc] Figures in draft-quinn-sfc-arch-05    <= /p>

     

    Paul/Joel,

     

            &nbs= p;       Pretty sure that Figures 5 and 6 don= ’t actually fit the width expected for an

    Internet Draft (Figure 5 is more than 80 characters = wide and Figure 6 is wider still).

     

            &nbs= p;       Depending on how a reader tries to r= ead the draft, this can turn complicated

    illustrations into a _real_ fun time.  <= span style=3D"font-family:Wingdings"> J

     

            &nbs= p;       Also, I am unsure what the figures a= re trying to convey with some of “dotted

    lines” crossing the service functions.  I= f the intent is to show that a service function is

    a virtual instance hosted by some network device, pe= rhaps this will be better shown

    in a separate figure and this aspect of Figures 5 an= d 6 can be eliminated?

     

    I would suggest replacing= Figure 5 with a figure along the lines of:

     

    source &nbs= p;           +--= ---+           &= nbsp;       +-----+=

      = ;|            +-= ->| sf2 +--+        &nbs= p;   +-->| sf4 +--+

      = ;|            | = ;  |     |  |     &n= bsp;      |   |     = |  |

      = ;|  +------+--+   +-----+  +--&= gt;+-----+--+   +-----+  +->+= -----+

      = ;|  | sf1  |      +-----+ &= nbsp;    | sf3 |      +-----= 3;     | sf5 |

      = ;+->|      +----->| sf2 +-----&g= t;|     |----->| sf4 +---->|   = ;  |-+

      = ;   |      |    &nbs= p; |     |      | &n= bsp;   |      |     = |     |     | |

      = ;   +------+--+   +-----+ = ; +-->+-----+--+   +-----+  += ->+-----+ |

      = ;            &n= bsp;|   +-----+  |     &nbs= p;      |   +-----+  | &nbs= p;        |

      = ;            &n= bsp;+-->| sf2 +--+       =      +-->| sf4 +--+    &n= bsp;+----+

      = ;            &n= bsp;    |     |   &n= bsp;            &nbs= p;  |     |      &nb= sp; |

      = ;            &n= bsp;    +-----+     &n= bsp;            &nbs= p;+-----+        V

      = ;            &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p;     destination

     =

      = ;            &n= bsp;    Figure 5: Load Balancing

     

    (67 characters?)

     

            &nbs= p;       Similarly, I would suggest replacing= Figure 6 with a figure along the

    lines of:

     

       source
         |       &n=
bsp;       +-----+-+ &n=
bsp;            =
;     +-----+-+
     +---+        &nb=
sp;  +-->| sf2 |-|+      &nbs=
p;       +-->| sf4 |-|+=

     |           &#=
43;---|-->|     | ||     &n=
bsp;    +------>|     | ||
     |   +------+|---+   +-----&#=
43; |+-->+-----+|---+   +-----+ |+=
-->+-----+
     |   | sf1  ||      =
 +-----+ +--->| sf3 ||       &=
#43;-----+ +--->| sf5 |
     +-->|      +|------>| sf2=
 |+---->|     ||------>| sf4 |+---->|&=
nbsp;    |--+
     |   |      || +---->|&=
nbsp;    |-+    |    =
 || +---->|     |-+    | =
;    |  |
     |   +------+|-|-+   +-----&#=
43; |+-->+-----+|-|-+   +-----+ |+=
-->+-----+  |
     |           | =
| |   +-----+ ||       =
;   | | |   +-----+ ||    &=
nbsp;       |
     |   +------++ | +-->| sf2 |-|+&=
nbsp;  +-----++ | +-->| sf4 |-|+   &#=
43;-----+  |
     |   | sf1' |  | +-->|   &nb=
sp; | +--->| sf3'|  | +-->|     | &#=
43;--->| sf5'|  |
     +-->|      +--+ | &=
nbsp; +-----+----->|     |--+ | &nb=
sp; +-----+----->|     |--+
         |      | &=
nbsp;  |          &n=
bsp;     |     |    =
|            &n=
bsp;   |     |  |

         +------+----+  &nb=
sp;            =
 +-----+----+        &n=
bsp;       +-----+  |=

    

               =
;             &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;         |=

    

               =
;            &n=
bsp;            =
;            &n=
bsp;            =
; +--------+
    

               =
;            &n=
bsp;            =
;            &n=
bsp;            =
; |
    

               =
;            &n=
bsp;            &nbs=
p;            &=
nbsp;           &nbs=
p;V
    

               =
;            &n=
bsp;            =
;            &n=
bsp;        destination
    

     
    

               =
;         Figure 6: Load Balancing =
and HA
    

     
    

    (72 characters?)
    

     
    

            &nbs=
p;       In both cases, the figure has all th=
e same connection complexity (fixed up in a few
    

    places), but seems to be less busy.
    

     
    

    --
    

    Eric
    --_000_075DE01702BBC249BE1357EFD20DCFE556F732xmbalnx02ciscocom_-- From nobody Fri May 30 11:06:01 2014 Return-Path: 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 616321A6FDB for ; Fri, 30 May 2014 11:06:00 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 mf7038C_4XZQ for ; Fri, 30 May 2014 11:05:53 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 302231A0427 for ; Fri, 30 May 2014 11:05:53 -0700 (PDT) X-AuditID: c618062d-f79be6d000006b89-36-5388783f36ed Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 20.69.27529.F3878835; Fri, 30 May 2014 14:23:28 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Fri, 30 May 2014 14:05:38 -0400 From: Eric Gray To: "Jakob Heitz (jheitz)" , Linda Dunbar , Lucy yong , Joel Halpern , "Paul Quinn (paulq)" Thread-Topic: Figures in draft-quinn-sfc-arch-05 Thread-Index: Ac97S9R6mfocA+1iTpKXBfVlibSBggAGJh5AAACjtcAAAHRWQAAFiSTQAAEryZAAAFNDAAAjvoJwAAcI2MAAAFj/oA== Date: Fri, 30 May 2014 18:05:37 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF632AD1919@eusaamb107.ericsson.se> References: <48E1A67CB9CA044EADFEAB87D814BFF632AD0443@eusaamb107.ericsson.se> <075DE01702BBC249BE1357EFD20DCFE556E2EC@xmb-aln-x02.cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD07D6@eusaamb107.ericsson.se> <2691CE0099834E4A9C5044EEC662BB9D45389B2C@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645D290DA@dfweml701-chm.china.huawei.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD0B1B@eusaamb107.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645D29193@dfweml701-chm.china.huawei.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD1504@eusaamb107.ericsson.se> <075DE01702BBC249BE1357EFD20DCFE556F732@xmb-aln-x02.cisco.com> In-Reply-To: <075DE01702BBC249BE1357EFD20DCFE556F732@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF632AD1919eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZXLonQdehoiPY4OENVou3mxrZLO62TGSy 2PhrEZvF/ldLWS2ePNjK7sDqMeX3RlaPliNvWT2WLPnJFMAcxWWTkpqTWZZapG+XwJVxc9IW 1oLJl5krVh8Qb2B8OIO5i5GTQ0LARGLLyU9MELaYxIV769m6GLk4hASOMkrs2L2FFcJZzijx 6nELWBWbgIbEsTtrGUESIgJnGSXeTupkBUkwCyhKPLr1G6xIWEBfYlvbYzYQW0TAQOLB4m5G CDtL4sK870A1HBwsAqoS0w4HgIR5BXwl3ly6ArXsP4vErscLWEFqOAW8JVZ9TAWpYQS67vup NUwQq8Qlbj2ZD3W1gMSSPeehvhGVePn4HyuErSTx8fd8doj6fIlf0+8wQuwSlDg58wnLBEbR WUhGzUJSNgtJGURcR2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/FyFFanFqWm25ksIkRGIHH JNh0dzDueWl5iFGAg1GJh3dBWEewEGtiWXFl7iFGaQ4WJXFe7ZtVwUIC6YklqdmpqQWpRfFF pTmpxYcYmTg4pRoYWzX1TnHsjL39ltHw2zLp73ZbvWNS2VrvTY+/yPV7cvFshwLFS7aXehz4 0qf1WN2zaKrwOZQtVe5bop93Oul/kA//Y+3HsUfnu8//qFv5vcNzjcFnz/xHE2flWP170PO2 +pJQnk7pgTcHMwOaeg2PcFX/bynwf/97Va7p7/5Ha+wMl3TvbtRUYinOSDTUYi4qTgQA7Wcz G6ECAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Y-PnTXcTCMocZzIkml6To-acUT4 Cc: "sfc@ietf.org" Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 18:06:00 -0000 --_000_48E1A67CB9CA044EADFEAB87D814BFF632AD1919eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ah. I see. It appears to have come around to that time of year when we discuss the use= of other formats for writing and reading RFCs. Normally, we have that discussion on the IETF Discussion mailing list, wher= e I can - along with a great many others - can generally ignore it. :) Let's move it to that list, shall we? Thanks! -- Eric From: Jakob Heitz (jheitz) [mailto:jheitz@cisco.com] Sent: Friday, May 30, 2014 1:55 PM To: Eric Gray; Linda Dunbar; Lucy yong; Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: RE: Figures in draft-quinn-sfc-arch-05 Importance: High Here is a good example of an RFC with readable diagrams http://www.rfc-editor.org/rfc/rfc1131.pdf How did he upload that? --Jakob From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray Sent: Friday, May 30, 2014 8:03 AM To: Linda Dunbar; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn= (paulq) Cc: sfc@ietf.org Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 Linda, It may be a mathematically correct expression (depending on= interpretation of the notation used), but networking is not necessarily (possibly even usu= ally) a mathematical operation. There is nothing "intuitively obvious" in this expression t= hat makes it clear that "load sharing" is taking place between the sets of sf2 and sf4 instanc= es, or how the "or" operation takes place. One literal way to interpret this notation (as a mathematic= al expression) is that each the functions sf2, sf2' and sf2" are "visited" sequentially and p= assed on to sf3 as soon as it succeeds in any of the functions. With this interpret= ation, since the service function performed at each sf2 instance is presumed to be ident= ical, what the expression means is that either the service function will succeed = at sf2 (and always skip sf2' and sf2"), or that it will fail at each sf2 instance. An equally legitimate "parallel computing" (not exactly mat= hematical, but possibly viewed as more closely analogous to networking) interpretation wou= ld be that processing passes (on success at sf1) to each of sf2, sf2' and sf2"= in parallel and then proceeds to sf3 on success at any of the sf2 instances. None of these interpretations corresponds to "load sharing= " - yet all are perfectly legitimate interpretation of your suggested expression/notation. And yet, these are actually more common interpretation of t= he usage of an "or" operation to computing folks (which many of us are), depending on t= heir specific background in computing. As I said before, I have no objection to the suggested nota= tion you and Lucy proposed - provided that the notation is explained. I am unclear as t= o what value this usage - and included explanation may have - but this is largely = a style issue, and best left up to the draft editors at this point. And, as I also said, there may be others who would prefer n= ot to have too much textual explanation necessary in order to understand a figure. Finally, you must realize that there are a fairly large num= ber of folks who read-over mathematical expressions as if they were written in a foreign lan= guage. For this reason, even if it were a perfectly useful/correct mathematical ex= pression, a number of folks would still need a picture. -- Eric From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Thursday, May 29, 2014 5:42 PM To: Eric Gray; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (p= aulq) Cc: sfc@ietf.org Subject: RE: Figures in draft-quinn-sfc-arch-05 Importance: High Eric, How about this shorter one? ->{sf1}->{sf2|sf2'|sf2''}->{sf3}->{sf4|sf4'|sf4''}->{sf5}-> The intent is pretty simple: If a service function on a chain has multiple = instances, one of the service function's instances is selected to treat pac= kets belonging to the service chain. This is a correct mathematics expression. There is really no need draw all those boxes. Linda From: Eric Gray [mailto:eric.gray@ericsson.com] Sent: Thursday, May 29, 2014 4:23 PM To: Linda Dunbar; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn= (paulq) Cc: sfc@ietf.org Subject: RE: Figures in draft-quinn-sfc-arch-05 Linda, By the way, your proposal for Figure 5 would require a column width of at l= east 80 characters (more than you are supposed to have in an ID), and the situation= would be worse if it were applied to figure 6. For figure 5, you can improve the width slightly by fixing up a few of your= arrows, and even more by wrapping the figure. Wrapping might detract from simplic= ity, however. -- Eric From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Thursday, May 29, 2014 4:49 PM To: Lucy yong; Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (p= aulq) Cc: sfc@ietf.org Subject: RE: Figures in draft-quinn-sfc-arch-05 Importance: High I like the Figures drawn by Lucy. Actually why can't Figure 5 be simplified as enter -->{sf1}-->-{sf2|sf2'|sf2''}->--{sf3}-->-{sf4|sf4'|sf4''}->--{sf5= }--> exit ?? Linda From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong Sent: Thursday, May 29, 2014 1:12 PM To: Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 For readability on these figures, propose: Figure 5: +-sf2-+ +-sf4-+ | | | | enter -->sf1-->-sf2->--sf3-->-sf4->--sf5--> exit | | | | +-sf2-+ +-sf4-+ Figure 6: +-sf2-+ +-sf4-+ | | | | enter -->{sf1|sf1'}-->-sf2->--{sf3|sf3'}-->-sf4->--{sf5}--> exit | | | | +-sf2-+ +-sf4-+ lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray Sent: Thursday, May 29, 2014 12:54 PM To: Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05 HaHa, funny man. :) From: Jakob Heitz (jheitz) [mailto:jheitz@cisco.com] Sent: Thursday, May 29, 2014 1:43 PM To: Eric Gray; Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: RE: Figures in draft-quinn-sfc-arch-05 Importance: High You could turn the whole picture right by 90 degrees. If you don't like top to bottom instead of left to right, make a note that = it's in landscape. --Jakob From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray Sent: Thursday, May 29, 2014 8:31 AM To: Joel Halpern; Paul Quinn (paulq) Cc: sfc@ietf.org Subject: [sfc] Figures in draft-quinn-sfc-arch-05 Paul/Joel, Pretty sure that Figures 5 and 6 don't actually fit the wid= th expected for an Internet Draft (Figure 5 is more than 80 characters wide and Figure 6 is wi= der still). Depending on how a reader tries to read the draft, this can= turn complicated illustrations into a _real_ fun time. :) Also, I am unsure what the figures are trying to convey wit= h some of "dotted lines" crossing the service functions. If the intent is to show that a ser= vice function is a virtual instance hosted by some network device, perhaps this will be bett= er shown in a separate figure and this aspect of Figures 5 and 6 can be eliminated? I would suggest replacing Figure 5 with a figure along the lines of: source +-----+ +-----+ | +-->| sf2 +--+ +-->| sf4 +--+ | | | | | | | | | | +------+--+ +-----+ +-->+-----+--+ +-----+ +->+-----+ | | sf1 | +-----+ | sf3 | +-----+ | sf5 | +->| +----->| sf2 +----->| |----->| sf4 +---->| |-+ | | | | | | | | | | | +------+--+ +-----+ +-->+-----+--+ +-----+ +->+-----+ | | +-----+ | | +-----+ | | +-->| sf2 +--+ +-->| sf4 +--+ +----+ | | | | | +-----+ +-----+ V destination Figure 5: Load Balancing (67 characters?) Similarly, I would suggest replacing Figure 6 with a figure= along the lines of: source | +-----+-+ +-----+-+ +---+ +-->| sf2 |-|+ +-->| sf4 |-|+ | +---|-->| | || +------>| | || | +------+|---+ +-----+ |+-->+-----+|---+ +-----+ |+-->+-----+ | | sf1 || +-----+ +--->| sf3 || +-----+ +--->| sf5 | +-->| +|------>| sf2 |+---->| ||------>| sf4 |+---->| |--+ | | || +---->| |-+ | || +---->| |-+ | | | | +------+|-|-+ +-----+ |+-->+-----+|-|-+ +-----+ |+-->+-----+ | | | | | +-----+ || | | | +-----+ || | | +------++ | +-->| sf2 |-|+ +-----++ | +-->| sf4 |-|+ +-----+ | | | sf1' | | +-->| | +--->| sf3'| | +-->| | +--->| sf5'| | +-->| +--+ | +-----+----->| |--+ | +-----+----->| |--+ | | | | | | | | | +------+----+ +-----+----+ +-----+ | | +--------+ | V destination Figure 6: Load Balancing and HA (72 characters?) In both cases, the figure has all the same connection compl= exity (fixed up in a few places), but seems to be less busy. -- Eric --_000_48E1A67CB9CA044EADFEAB87D814BFF632AD1919eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Ah.  I see.<= /o:p>

     

    It appears to have com= e around to that time of year when we discuss the use of<= /p>

    other formats for writ= ing and reading RFCs.

     

    Normally, we have that= discussion on the IETF Discussion mailing list, where I can

    - along with a great m= any others – can generally ignore it.  J

     

    Let’s move it to= that list, shall we?

     

    Thanks!

    --

    Eric=

     

    From: Jakob He= itz (jheitz) [mailto:jheitz@cisco.com]
    Sent: Friday, May 30, 2014 1:55 PM
    To: Eric Gray; Linda Dunbar; Lucy yong; Joel Halpern; Paul Quinn (pa= ulq)
    Cc: sfc@ietf.org
    Subject: RE: Figures in draft-quinn-sfc-arch-05
    Importance: High

     

    Here is a good example of an RFC with read= able diagrams

    http://www.rfc-editor.org/rfc/rfc1131.pdf=

     

    How did he upload that?<= /p>

     

    --Jakob

     

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray
    Sent: Friday, May 30, 2014 8:03 AM
    To: Linda Dunbar; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Pau= l Quinn (paulq)
    Cc: sfc@ietf.org
    Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05

     

    Linda,

     

       &nbs= p;            It may= be a mathematically correct expression (depending on interpretation

    of the notation used),= but networking is not necessarily (possibly even usually) a

    mathematical operation= .

     

       &nbs= p;            There = is nothing “intuitively obvious” in this expression that makes = it clear

    that “load shari= ng” is taking place between the sets of sf2 and sf4 instances, or how=

    the “or” o= peration takes place.

     

       &nbs= p;            One li= teral way to interpret this notation (as a mathematical expression) is=

    that each the function= s sf2, sf2’ and sf2” are “visited” sequentially and= passed on

    to sf3 ­as s= oon as it succeeds in any of the functions.  With this interpr= etation, since

    the service function p= erformed at each sf2 instance is presumed to be identical,

    what the expression me= ans is that either the service function will succeed at sf2

    (and always skip sf2&#= 8217; and sf2”), or that it will fail at each sf2 instance.

     

       &nbs= p;            An equ= ally legitimate “parallel computing” (not exactly mathematical,= but

    possibly viewed as mor= e closely analogous to networking) interpretation would

    be that processing pas= ses (on success at sf1) to each of sf2, sf2’ and sf2” in parallel=

    and then proceeds to s= f3 on success at any of the sf2 instances.

     

       &nbs= p;            None o= f these interpretations corresponds to  “load sharing” = 211; yet all are

    perfectly legitimate i= nterpretation of your suggested expression/notation.

     

       &nbs= p;            And ye= t, these are actually more common interpretation of the usage of=

    an “or” op= eration to computing folks (which many of us are), depending on their<= /o:p>

    specific background in= computing.

     

       &nbs= p;            As I s= aid before, I have no objection to the suggested notation you and

    Lucy proposed – = provided that the notation is explained.  I am unclear as to what=

    value this usage ̵= 1; and included explanation may have – but this is largely a style

    issue, and best left u= p to the draft editors at this point.

     

       &nbs= p;            And, a= s I also said, there may be others who would prefer not to have too

    much textual explanati= on necessary in order to understand a figure.

     

       &nbs= p;            Finall= y, you must realize that there are a fairly large number of folks who<= /o:p>

    read-over mathematical= expressions as if they were written in a foreign language.

    For this reason, even = if it were a perfectly useful/correct mathematical expression,

    a number of folks woul= d still need a picture.

     

    --

    Eric=

     

    From: Linda Du= nbar [mailto:linda.dunbar@hu= awei.com]
    Sent: Thursday, May 29, 2014 5:42 PM
    To: Eric Gray; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Paul Q= uinn (paulq)
    Cc: sfc@ietf.org
    Subject: RE: Figures in draft-quinn-sfc-arch-05
    Importance: High

     

    Eric,

     

    How about this shorter= one?

     

    ->{sf1}->{sf2|sf2’|sf2’’}->{sf3}= ->{sf4|sf4’|sf4’’}->{sf5}->

     

    The intent is pretty s= imple: If a service function on a chain has multiple instances, one of the = service function’s instances is selected to treat packets belonging t= o the service chain.  

     

    This is a correct math= ematics expression.

    There is really no nee= d draw all those boxes.

     

    Linda  

     

     

    Linda,

     

    By the way, your propo= sal for Figure 5 would require a column width of at least 80

    characters (more than = you are supposed to have in an ID), and the situation would

    be worse if it were ap= plied to figure 6.

     

    For figure 5, you can = improve the width slightly by fixing up a few of your arrows,

    and even more by wrapp= ing the figure.  Wrapping  might detract from simplicity,

    however.

     

    --

    Eric=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei= .com]
    Sent: Thursday, May 29, 2014 4:49 PM
    To: Lucy yong; Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Q= uinn (paulq)
    Cc: sfc@ietf.org
    Subject: RE: Figures in draft-quinn-sfc-arch-05
    Importance: High

     

    I like the Figures dra= wn by Lucy.

     

    Actually why can’= ;t Figure 5 be simplified as

     

        enter --&g= t;{sf1}-->-{sf2|sf2’|sf2’’}->--{sf3}-->-{sf4|sf4= ’|sf4’’}->--{sf5}--> exit

     

    ??

     

    Linda

     

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong
    Sent: Thursday, May 29, 2014 1:12 PM
    To: Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq= )
    Cc: sfc@ietf.org
    Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05

     

    For readability on the= se figures, propose:

     

    Figure 5:

         = ;            &n= bsp;   +-sf2-+       +-= sf4-+

         = ;            &n= bsp;   |     |     &= nbsp; |     |

         = ;  enter -->sf1-->-sf2->--sf3-->-sf4->--sf5--> exit<= o:p>

         = ;            &n= bsp;   |     |     &= nbsp; |     |

         = ;            &n= bsp;   +-sf2-+       +-= sf4-+

    Figure 6:

     

         = ;            &n= bsp;       +-sf2-+   &= nbsp;          +-sf4-+=

         = ;            &n= bsp;       |     | &= nbsp;            |&n= bsp;    |

        enter --&g= t;{sf1|sf1'}-->-sf2->--{sf3|sf3'}-->-sf4->--{sf5}--> exit

         = ;            &n= bsp;       |     | &= nbsp;            |&n= bsp;    |

              = ;            &n= bsp;  +-sf2-+        &= nbsp;     +-sf4-+=

     

    lucy=

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray
    Sent: Thursday, May 29, 2014 12:54 PM
    To: Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq)
    Cc: sfc@ietf.org
    Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05

     

    HaHa, funny man. = J

     

    From: Jakob He= itz (jheitz) [mailto:jheitz@cisco.com]
    Sent: Thursday, May 29, 2014 1:43 PM
    To: Eric Gray; Joel Halpern; Paul Quinn (paulq)
    Cc:     sfc@ietf.org
    Subject: RE: Figures in draft-quinn-sfc-arch-05
    Importance: High

     

    You could turn the whole picture right by = 90 degrees.

    If you don’t like top to bottom inst= ead of left to right, make a note that it’s in landscape.<= /span>

     

    --Jakob

     

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray
    Sent: Thursday, May 29, 2014 8:31 AM
    To: Joel Halpern; Paul Quinn (paulq)
    Cc: sfc@ietf.org
    Subject: [sfc] Figures in draft-quinn-sfc-arch-05    <= /p>

     

    Paul/Joel,

     

            &nbs= p;       Pretty sure that Figures 5 and 6 don= ’t actually fit the width expected for an

    Internet Draft (Figure 5 is more than 80 characters = wide and Figure 6 is wider still).

     

            &nbs= p;       Depending on how a reader tries to r= ead the draft, this can turn complicated

    illustrations into a _real_ fun time.  <= span style=3D"font-family:Wingdings"> J

     

            &nbs= p;       Also, I am unsure what the figures a= re trying to convey with some of “dotted

    lines” crossing the service functions.  I= f the intent is to show that a service function is

    a virtual instance hosted by some network device, pe= rhaps this will be better shown

    in a separate figure and this aspect of Figures 5 an= d 6 can be eliminated?

     

    I would suggest replacing= Figure 5 with a figure along the lines of:

     

    source &nbs= p;           +--= ---+           &= nbsp;       +-----+=

      = ;|            +-= ->| sf2 +--+        &nbs= p;   +-->| sf4 +--+

      = ;|            | = ;  |     |  |     &n= bsp;      |   |     = |  |

      = ;|  +------+--+   +-----+  +--&= gt;+-----+--+   +-----+  +->+= -----+

      = ;|  | sf1  |      +-----+ &= nbsp;    | sf3 |      +-----= 3;     | sf5 |

      = ;+->|      +----->| sf2 +-----&g= t;|     |----->| sf4 +---->|   = ;  |-+

      = ;   |      |    &nbs= p; |     |      | &n= bsp;   |      |     = |     |     | |

      = ;   +------+--+   +-----+ = ; +-->+-----+--+   +-----+  += ->+-----+ |

      = ;            &n= bsp;|   +-----+  |     &nbs= p;      |   +-----+  | &nbs= p;        |

      = ;            &n= bsp;+-->| sf2 +--+       =      +-->| sf4 +--+    &n= bsp;+----+

      = ;            &n= bsp;    |     |   &n= bsp;            &nbs= p;  |     |      &nb= sp; |

      = ;            &n= bsp;    +-----+     &n= bsp;            &nbs= p;+-----+        V

      = ;            &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p;     destination

     =

      = ;            &n= bsp;    Figure 5: Load Balancing

     

    (67 characters?)

     

            &nbs= p;       Similarly, I would suggest replacing= Figure 6 with a figure along the

    lines of:

     

       source
         |       &n=
bsp;       +-----+-+ &n=
bsp;            =
;     +-----+-+
     +---+        &nb=
sp;  +-->| sf2 |-|+      &nbs=
p;       +-->| sf4 |-|+=

     |           &#=
43;---|-->|     | ||     &n=
bsp;    +------>|     | ||
     |   +------+|---+   +-----&#=
43; |+-->+-----+|---+   +-----+ |+=
-->+-----+
     |   | sf1  ||      =
 +-----+ +--->| sf3 ||       &=
#43;-----+ +--->| sf5 |
     +-->|      +|------>| sf2=
 |+---->|     ||------>| sf4 |+---->|&=
nbsp;    |--+
     |   |      || +---->|&=
nbsp;    |-+    |    =
 || +---->|     |-+    | =
;    |  |
     |   +------+|-|-+   +-----&#=
43; |+-->+-----+|-|-+   +-----+ |+=
-->+-----+  |
     |           | =
| |   +-----+ ||       =
;   | | |   +-----+ ||    &=
nbsp;       |
     |   +------++ | +-->| sf2 |-|+&=
nbsp;  +-----++ | +-->| sf4 |-|+   &#=
43;-----+  |
     |   | sf1' |  | +-->|   &nb=
sp; | +--->| sf3'|  | +-->|     | &#=
43;--->| sf5'|  |
     +-->|      +--+ | &=
nbsp; +-----+----->|     |--+ | &nb=
sp; +-----+----->|     |--+
         |      | &=
nbsp;  |          &n=
bsp;     |     |    =
|            &n=
bsp;   |     |  |

         +------+----+  &nb=
sp;            =
 +-----+----+        &n=
bsp;       +-----+  |=

    

               =
;             &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;         |=

    

               =
;            &n=
bsp;            =
;            &n=
bsp;            =
; +--------+
    

               =
;            &n=
bsp;            =
;            &n=
bsp;            =
; |
    

               =
;            &n=
bsp;            &nbs=
p;            &=
nbsp;           &nbs=
p;V
    

               =
;            &n=
bsp;            =
;            &n=
bsp;        destination
    

     
    

               =
;         Figure 6: Load Balancing =
and HA
    

     
    

    (72 characters?)
    

     
    

            &nbs=
p;       In both cases, the figure has all th=
e same connection complexity (fixed up in a few
    

    places), but seems to be less busy.
    

     
    

    --
    

    Eric
    --_000_48E1A67CB9CA044EADFEAB87D814BFF632AD1919eusaamb107erics_-- From nobody Fri May 30 12:51:09 2014 Return-Path: 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 9C2D41A0A80 for ; Fri, 30 May 2014 12:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 UvrJhoi3xVkG for ; Fri, 30 May 2014 12:51:03 -0700 (PDT) Received: from hub021-ca-1.exch021.serverdata.net (hub021-ca-1.exch021.serverdata.net [64.78.22.168]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A52E1A0408 for ; Fri, 30 May 2014 12:51:03 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-1.exch021.domain.local ([10.254.4.30]) with mapi id 14.03.0174.001; Fri, 30 May 2014 12:50:59 -0700 From: Ron Parker To: "Reinaldo Penno (repenno)" , "sfc@ietf.org" Thread-Topic: Yang Data Model for Service Function Chaining (02) Thread-Index: AQHPe9y+1dcKReUMXUuPJ+epenpTWJtZNf2A Date: Fri, 30 May 2014 19:50:58 +0000 Message-ID: References: <45A697A8FFD7CF48BCF2BE7E106F06040B8FFDED@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040B8FFDED@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/KcG-sY_JyDUxaLvN-ZzeJUNOXss Subject: Re: [sfc] Yang Data Model for Service Function Chaining (02) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 19:51:06 -0000 To draft-penno-sfc-yang authors, Please consider the questions and comments below. Thank you. Ron ------------- 1. Why must there be exactly 3 elements in the leaf-list "/vxlan-gpe-heade= r/vni" ? 2. Regarding the identity statements that define service function types, I= feel that it is limiting to enumerate them. In list /service-functions/s= ervice-function, the type is optional, anyway, so perhaps just make it a de= scription string? 3. /service-functions/service-function/ip-host-address is a single leaf. = I realize that it is a slippery slope to make this a list, because then we= introduce confusion about if the list is a set of addresses for one manage= d entity vs. a set of independently managed entities, but I am thinking abo= ut certain internal load balancing scenarios (i.e., within the a single man= aged service function) that may require more than 1 IP address for that ser= vice function (i.e., multiple loopback IP addresses or even multiple interf= ace-level IP addresses). 4. In section 5 (Service Function Chain description), suggest chainging "= But a service function chain does not specify exactly which service (firewa= l1 vs. firewall2) will be used" to "But a service function chain does not s= pecify exactly which service function instance (firewal1= vs. firewall2) will be used". 5. leaf-list /service-function-chain/service-function limits the chain to = at most one occurrence of a given type of service function. While that wo= uld be typical, there could be cases where a given type must be visited mor= e than once in the chain. Also, since the chain is defined in terms of th= e types, new types of service functions can not be supported without a corr= esponding change to this YANG module. For these reasons, I would like to = suggest that the chain be defined in terms of user-specified service functi= on types. One approach would be to have a 2 level hierarchy where the ne= twork administrator defines the meaningful service-functions (i.e., list se= rvice-function {key =3D name} ) and within that list have a list of instanc= es and within that a list of IP addresses specific to the instance. For example: -- list service function {key type string} +-- list instance {key type string} +-- leaf-list ip-address 6. Service-node type definitions -- what if a service node is simultaneous= ly an ingress, middle, egress, legacy, etc? 7. /service-nodes/service-node -- how is the ip-host-address interpreted h= ere? Is it the management IP address of the service-node? 8. /service-function-path description -- suggest changing "the actual fire= wall" to "the actual firewall instance". 9. /service-function-path/service-function-instance is a singleton leaf-li= st. That is, exactly one sequence of service-functions can be specified. = Shouldn't there be a higher level list so that multiple sequences can be = defined? Also, is this the philosophy that we want for the service functi= on path -- that all paths are fully identified a priori (i.e., centralized = instance selection) vs. instance selection is done in a distributed manner?= I'm not taking a position, but merely asking the question. In the case= of pre-defining paths, the number of fully instantiated paths would grow a= rithmetically. 10. /service-function-forwarding-map/service-map -- how does this differ f= rom the ip address associated with the service function instance, itself? = Or from the service-node IP address? ------------- -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenn= o) Sent: Friday, May 30, 2014 3:57 AM To: sfc@ietf.org Subject: [sfc] Yang Data Model for Service Function Chaining (02) A new version of I-D, draft-penno-sfc-yang-02.txt has been successfully sub= mitted by Reinaldo Penno and posted to the IETF repository. Name: draft-penno-sfc-yang Revision: 02 Title: Yang Data Model for Service Function Chaining Document date: 2014-05-29 Group: Individual Submission Pages: 20 URL: http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-02= .txt Status: https://datatracker.ietf.org/doc/draft-penno-sfc-yang/ Htmlized: http://tools.ietf.org/html/draft-penno-sfc-yang-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-penno-sfc-yang-02 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Fri May 30 14:09:51 2014 Return-Path: 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 7CE341A8854 for ; Fri, 30 May 2014 14:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 0_6E-m4xkcYi for ; Fri, 30 May 2014 14:09:46 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 699D71A01ED for ; Fri, 30 May 2014 14:09:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6067; q=dns/txt; s=iport; t=1401484182; x=1402693782; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=XZ1OhSLrplShsQ9Yg4iv5XQ0z5kZ0Y/JLH7obVBuJho=; b=HMkSQHKF9StHL+fQpsofrfIMPFZDeOEs5IvkMbMrGWnQDmLYIYrFuIB4 KKnuY4c6vxzkQWt3GW1T5JaJQWNpJhTNuMsyWnPczqdRz0o2T3n1k259f Bjh9hF9KAbSsGTwWmEA0UTLAyH2kWNMKYw6DFp0s5JRIjuabs6NoRdlrw M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoKAPvyiFOtJV2b/2dsb2JhbABQCYMHUlEEA7sDhzkBgQoWdIIlAQEBBAEBAWsXBgEIEQQBASguCxQJCAIEARIJiDkIBdcQF413MDIGhDoEiWuQE4E+iW6IAYM4bIFD X-IronPort-AV: E=Sophos;i="4.98,943,1392163200"; d="scan'208";a="326203188" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 30 May 2014 21:09:41 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s4UL9fB0021084 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 May 2014 21:09:41 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.16]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Fri, 30 May 2014 16:09:40 -0500 From: "Reinaldo Penno (repenno)" To: Ron Parker , "sfc@ietf.org" Thread-Topic: Yang Data Model for Service Function Chaining (02) Thread-Index: AQHPe9y+1dcKReUMXUuPJ+epenpTWJtZNf2AgABHqoA= Date: Fri, 30 May 2014 21:09:40 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.91.203] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3931263EF506864AB208FBB2EB075765@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/PlCIUgYhe4DBrUCVf1M2BEZibPo Subject: Re: [sfc] Yang Data Model for Service Function Chaining (02) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 21:09:48 -0000 Hello Ron, Lots of good comments, comments inline with [RP] On 5/30/14, 12:50 PM, "Ron Parker" wrote: >To draft-penno-sfc-yang authors, > >Please consider the questions and comments below. Thank you. > > Ron > >------------- >1. Why must there be exactly 3 elements in the leaf-list >"/vxlan-gpe-header/vni" ? > >2. Regarding the identity statements that define service function types, >I feel that it is limiting to enumerate them. In list >/service-functions/service-function, the type is optional, anyway, so >perhaps just make it a description string? [RP] This is the approach used for IETF interfaces and the consensus of netmod on how to approach similar issues. http://tools.ietf.org/html/rfc7224 - List if interface type identities http://tools.ietf.org/html/rfc7223 - Base model Basically there is a list of identities for many interfaces and folks can augment that list with their own identities. My intention is that folks are free to also augment the list of service function types. > >3. /service-functions/service-function/ip-host-address is a single leaf. > I realize that it is a slippery slope to make this a list, because then >we introduce confusion about if the list is a set of addresses for one >managed entity vs. a set of independently managed entities, but I am >thinking about certain internal load balancing scenarios (i.e., within >the a single managed service function) that may require more than 1 IP >address for that service function (i.e., multiple loopback IP addresses >or even multiple interface-level IP addresses). [RP] This is the management address. The actual address used in the data plane is found in SFF/Service Path, but your comments applies irrespective. > >4. In section 5 (Service Function Chain description), suggest chainging >"But a service function chain does not specify exactly which service >(firewal1 vs. firewall2) will be used" to "But a service function chain >does not specify exactly which service function instance > (firewal1 vs. firewall2) will be used". [RP] Certainly. > >5. leaf-list /service-function-chain/service-function limits the chain >to at most one occurrence of a given type of service function. While >that would be typical, there could be cases where a given type must be >visited more than once in the chain. Also, since the chain is defined >in terms of the types, new types of service functions can not be >supported without a corresponding change to this YANG module. For these >reasons, I would like to suggest that the chain be defined in terms of >user-specified service function types. One approach would be to have a >2 level hierarchy where the network administrator defines the meaningful >service-functions (i.e., list service-function {key =3D name} ) and within >that list have a list of instances and within that a list of IP addresses >specific to the instance. > >For example: > >-- list service function {key type string} > +-- list instance {key type string} > +-- leaf-list ip-address [RP] Let me think about this one. > >6. Service-node type definitions -- what if a service node is >simultaneously an ingress, middle, egress, legacy, etc? [RP] Possible. Much like a router can be peering and edge. Do you think we should support multiple types or that would complicate things? > >7. /service-nodes/service-node -- how is the ip-host-address interpreted >here? Is it the management IP address of the service-node? [RP] Management. I will make clear next revision. > >8. /service-function-path description -- suggest changing "the actual >firewall" to "the actual firewall instance". [RP] Can do. > >9. /service-function-path/service-function-instance is a singleton >leaf-list. That is, exactly one sequence of service-functions can be >specified. Shouldn't there be a higher level list so that multiple >sequences can be defined? [RP] Wouldn=B9t they be separate function paths then? >Also, is this the philosophy that we want for the service function path >-- that all paths are fully identified a priori (i.e., centralized >instance selection) vs. instance selection is done in a distributed >manner? I'm not taking a position, but merely asking the question. In >the case of pre-defining paths, the number of fully instantiated paths >would grow arithmetically. [RP] How would that impact the Yang model? The configuration needs to be consistent and known by a SN/SFF by the time it will make selection of next SF in path.=20 > >10. /service-function-forwarding-map/service-map -- how does this differ >from the ip address associated with the service function instance, >itself? Or from the service-node IP address? [RP] Data plane vs. management. I think this point is not clear given your other comments. > > > > > > > > > > > > > >------------- > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno >(repenno) >Sent: Friday, May 30, 2014 3:57 AM >To: sfc@ietf.org >Subject: [sfc] Yang Data Model for Service Function Chaining (02) > >A new version of I-D, draft-penno-sfc-yang-02.txt has been successfully >submitted by Reinaldo Penno and posted to the IETF repository. > >Name: draft-penno-sfc-yang >Revision: 02 >Title: Yang Data Model for Service Function Chaining >Document date: 2014-05-29 >Group: Individual Submission >Pages: 20 >URL: =20 >http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-02.txt >Status: https://datatracker.ietf.org/doc/draft-penno-sfc-yang/ >Htmlized: http://tools.ietf.org/html/draft-penno-sfc-yang-02 >Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-penno-sfc-yang-02 >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Fri May 30 18:08:46 2014 Return-Path: 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 486BB1A043C for ; Fri, 30 May 2014 18:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.552 X-Spam-Level: X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 kVIts-3BHIuE for ; Fri, 30 May 2014 18:08:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E738B1A06C3 for ; Fri, 30 May 2014 18:08:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BES43234; Sat, 31 May 2014 01:08:32 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 31 May 2014 02:07:52 +0100 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 31 May 2014 02:08:30 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.193]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Sat, 31 May 2014 09:08:22 +0800 From: Qin Wu To: Ron Parker , Joel Halpern Direct , "Ken Gray (kegray)" , "Linda Dunbar" Thread-Topic: =?utf-8?B?W3NmY10g562U5aSNOiAg562U5aSNOiAgcXVlc3Rpb25zIG9mICJsb2FkIGJh?= =?utf-8?B?bGFuY2luZyBjb25zaWRlcmF0aW9ucyIgaW4gdGhlIGRyYWZ0LXF1aW5uLXNm?= =?utf-8?Q?c-arch-05?= Thread-Index: AQHPfAzVH8SwdaDD7k+69OAQE4kz2ptZ2yiw Date: Sat, 31 May 2014 01:08:20 +0000 Message-ID: References: , <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> <16984558-2B4C-4873-AFC7-DCD2698CA745@cisco.com> <53873333.80807@joelhalpern.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.131] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/yOG7-blLleU7dLx5AkTKjYf68dE Cc: "Joel M. Halpern" , "Paul Quinn \(paulq\)" , "sfc@ietf.org" Subject: [sfc] =?utf-8?b?562U5aSNOiAg562U5aSNOiAg562U5aSNOiAgcXVlc3Rpb25z?= =?utf-8?q?_of_=22load_balancing_considerations=22_in_the_draft-quinn-sfc-?= =?utf-8?q?arch-05?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 01:08:43 -0000 SGksIFJvbjoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogc2ZjIFttYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBSb24gUGFya2VyDQrlj5HpgIHml7bpl7Q6IDIw MTTlubQ15pyIMzDml6UgMjE6NDENCuaUtuS7tuS6ujogUWluIFd1OyBKb2VsIEhhbHBlcm4gRGly ZWN0OyBLZW4gR3JheSAoa2VncmF5KTsgTGluZGEgRHVuYmFyDQrmioTpgIE6IEpvZWwgTS4gSGFs cGVybjsgUGF1bCBRdWlubiAocGF1bHEpOyBzZmNAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtzZmNd IOetlOWkjTog562U5aSNOiBxdWVzdGlvbnMgb2YgImxvYWQgYmFsYW5jaW5nIGNvbnNpZGVyYXRp b25zIiBpbiB0aGUgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDUNCg0KUWluLA0KDQpSZWdhcmRpbmcg eW91ciBxdWVzdGlvbjoNCglTbyB0aGUgcXVlc3Rpb24gaXMgY2FuIG9uZSBzZXJ2aWNlIGZ1bmN0 aW9uIHByb3ZpZGUgbW9yZSB0aGFuIG9uZSBzZXJ2aWNlIG9yIHRyZWF0bWVudD8NCg0KDQpBIHNl cnZpY2UgZnVuY3Rpb24gY2FuIGJlIHRob3VnaHQgb2YgYXMgYSBsb2dpY2FsIGNvbnN0cnVjdC4g ICBNb3JlIHRoYW4gb25lIHN1Y2ggc2VydmljZSBmdW5jdGlvbiBjb3VsZCBiZSBjby1sb2NhdGVk IGF0IHRoZSBzYW1lIGxvY2F0b3IgKGkuZS4sIElQIGFkZHJlc3MpLiAgIEkuZS4sIGEgc2luZ2xl IG1hbmFnZW1lbnQgZW50aXR5IHdpdGggYSBzaW5nbGUgSVAgYWRkcmVzcyBjb3VsZCBwcm92aWRl IG11bHRpcGxlIHNlcnZpY2UgZnVuY3Rpb25zIHNpbXVsdGFuZW91c2x5LiAgIEluIGNhc2VzIHdo ZXJlIHRoZSBzaW5nbGUgbWFuYWdlZCBlbnRpdHkgd2FzIGFza2VkIHRvIHBlcmZvcm0gbXVsdGlw bGUgc2VydmljZSBmdW5jdGlvbnMgdGhhdCB3ZXJlIGNvbnNlY3V0aXZlIGluIHRoZSBzZXJ2aWNl IGNoYWluLCBhcyBhbiBvcHRpbWl6YXRpb24gaXQgc2hvdWxkIG5vdCBiZSBuZWNlc3NhcnkgdG8g cmV0dXJuIHRoZSB0cmFmZmljIHRvIHRoZSBTRkYgaW4gYmV0d2VlbiB0aG9zZSBzZXJ2aWNlIGZ1 bmN0aW9ucy4gDQoNCltRaW5dOiBZZXMsIElmIG9uZSBTRkYgaG9zdHMgdHdvIHNlcnZpY2UgZnVu Y3Rpb25zIGFuZCB0aGVzZSB0d28gc2VydmljZSBmdW5jdGlvbnMgYXJlIGNvbnNlY3V0aXZlIGlu IHRoZSBzYW1lIHNlcnZpY2UgY2hhaW4sIFN1cmUsIHRoZSB0cmFmZmljIGRvZXNuJ3QgbmVlZCB0 byBiZSByZXR1cm5lZCB0byB0aGUgU0ZGIGZvciBlYWNoIG9mIHNlcnZpY2UgZnVuY3Rpb25zIHRo YXQgYXJlIGNvbGxvY2F0ZWQgYXQgU0ZGLiBJIGZ1bGx5IGFncmVlLg0KDQpBbm90aGVyIGFzcGVj dCBvZiB5b3VyIHF1ZXN0aW9uIHdhcyBjYW4gdGhlIHNhbWUgbG9naWNhbCBzZXJ2aWNlIGZ1bmN0 aW9uIHByb3ZpZGUgbW9yZSB0aGFuIG9uZSB0cmVhdG1lbnQ/ICAgIFRoZXJlIGFyZSBhdCBsZWFz dCAzIGFwcHJvYWNoZXMgdG8gdGhpcy4gICBJbiB0aGUgZmlyc3QsIGVhY2ggZGlmZmVyZW50aWF0 ZWQgYmVoYXZpb3IgaXMgcmVwcmVzZW50ZWQgYXMgYSBkaXN0aW5jdCBsb2dpY2FsIHNlcnZpY2Ug ZnVuY3Rpb24gLS0gaS5lLiwgY29udGVudF9maWx0ZXJfYWR1bHQsIGNvbnRlbnRfZmlsdGVyX2No aWxkLiAgIEluIHRoZSBzZWNvbmQgYXBwcm9hY2gsIGEgc2luZ2xlIHNlcnZpY2UgZnVuY3Rpb24g KGkuZS4sIGNvbnRlbnRfZmlsdGVyKSBoYXMgaXRzIG93biBwcml2YXRlIG1lY2hhbmlzbSB0byBk ZXRlcm1pbmUgd2hpY2ggYmVoYXZpb3IgdG8gYXBwbHkgKGkuZS4sIGEgbWlycm9yZWQgUkFESVVT IGZlZWQgdGVhY2hlcyBpdCBzdWJzY3JpYmVyIHByb3BlcnRpZXMgcmVsYXRlZCB0byBzdWJzY3Jp YmVyIElQIGFkZHJlc3NlcykuICAgQSB0aGlyZCBhcHByb2FjaCBpcyB0aGF0IHRoZSBzZXJ2aWNl IGZ1bmN0aW9uIGNvbnRyb2xsZXIgaW5zZXJ0cyBtZXRhZGF0YSB0byB0aGUgcGFja2V0IHN0cmVh bSB0aGF0IHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGNhbiBpbnRlcnByZXQgZm9yIHB1cnBvc2VzIG9m IHByb3ZpZGluZyBhIGRpZmZlcmVudGlhdGVkIGJlaGF2aW9yIChpLmUuLCBzdWJzY3JpYmVyX3R5 cGU9Y2hpbGQpLg0KDQpbUWluXTogTXkgcXVlc3Rpb24gYWN0dWFsbHkgaXM6IENhbiBmaXJld2Fs bCBzZXJ2aWNlIGZ1bmN0aW9uIHByb3ZpZGUgbG9hZCBiYWxhbmNlciBzZXJ2aWNlPw0KSW4geW91 ciBleGFtcGxlIGFwcHJvYWNoZXMsIGl0IGxvb2tzIGEgZGlmZmVyZW50aWF0ZWQgYmVoYXZpb3Jz IHByb3ZpZGVkIGJ5IG9uZSBzZXJ2aWNlIGZ1bmN0aW9uIGFyZSBxdWl0ZSBzaW1pbGFyLCBlLmcu LCBjb250ZW50X2ZpbGVyX2FkdWx0IGFuZCBjb250ZW50X2ZpbGVyX2NoaWxkLCBib3RoIGFyZSBj b250ZW50IGZpbGVyIHNlcnZpY2UuDQpJIGFtIHdvbmRlcmluZyBjYW4gb25lIEhUVFAgb3B0aW1p emF0aW9uIHNlcnZpY2UgZnVuY3Rpb24gcHJvdmlkaW5nIGRpZmZlcmVudGlhdGUgYmVoYXZpb3Jz IGFsc28gc3VwcG9ydCBsb2FkIGJhbGFuY2VyIHNlcnZpY2U/IENhbiB0d28gc2VydmljZSBmdW5j dGlvbnMgcHJvdmlkaW5nIGRpZmZlcmVudCBzZXJ2aWNlIGFuZCBlbWJlZGRlZCBpbiB0aGUgc2Ft ZSBuZXR3b3JrIGVsZW1lbnQgYmUgY29tYmluZWQgaW50byBvbmUgc2VydmljZSBmdW5jdGlvbj8N CklmIHRoZSBhbnN3ZXIgaXMgeWVzLCB0aGUgZGVmaW5pdGlvbiBvZiBzZXJ2aWNlIGZ1bmN0aW9u IGluIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBkcmFmdCBuZWVkcyB0byBiZSByZXZpc2l0ZWQgYW5k IGNoYW5nZWQgc2luY2Ugc2VydmljZSBmdW5jdGlvbiBjYW4gYmUgcmVzcG9uc2libGUgZm9yIG1v cmUgdGhhbiBvbmUgdHJlYXRtZW50cyBhbmQgZWFjaCB0cmVhdG1lbnQgcHJvdmlkZSBkaWZmZXJl bnQgc2VydmljZS4NCiINCkkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBjb3JyZWN0Lg0KDQogICBSb24N Cg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzZmMgW21haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFFpbiBXdQ0KU2VudDogVGh1cnNkYXksIE1h eSAyOSwgMjAxNCAxMToyNyBQTQ0KVG86IEpvZWwgSGFscGVybiBEaXJlY3Q7IEtlbiBHcmF5IChr ZWdyYXkpOyBMaW5kYSBEdW5iYXINCkNjOiBKb2VsIE0uIEhhbHBlcm47IFBhdWwgUXVpbm4gKHBh dWxxKTsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBbc2ZjXSDnrZTlpI06IOetlOWkjTogcXVlc3Rp b25zIG9mICJsb2FkIGJhbGFuY2luZyBjb25zaWRlcmF0aW9ucyIgaW4gdGhlIGRyYWZ0LXF1aW5u LXNmYy1hcmNoLTA1DQoNCkhpLCBKb2VsOg0KVGhhbmsgZm9yIHlvdXIgY2xhcmlmaWNhdGlvbi4g DQppZiBsb2FkIGJhbGFuY2VyIGlzIHJlYWxseSBuZWVkZWQgYW5kIGl0IGlzIG5vdCBhIHNlcnZp Y2UgZnVuY3Rpb24gaW4gdGhlIGNoYWluLCBJIGFncmVlIHdlIHNob3VsZCBub3QgbWFuZGF0ZSBp dHMgbG9jYXRpb24uDQpTbyB0aGUgZm9sbG93aW5nIGRlc2NyaXB0aW9uIGluIHRoZSBkcmFmdCBp cyB2ZXJ5IHJlc3RyaWN0aXZlICINCkVpdGhlciB0aHJvdWdoIGFuIGltYmVkZGVkIGFjdGlvbiBp biBzZjEgYW5kIHNmMywgb3IgdGhyb3VnaCBleHRlcm5hbCBjb250cm9sICINCkl0IHNlZW1zIGV4 Y2x1ZGluZyBoYXZpbmcgbG9hZCBiYWxhbmNlciBvbiB0aGUgU0ZGLg0KQWxzbyBpZiAgc2YxIHJl cXVpcmVzIGxvYWQgYmFsYW5jZXIgYW5kIHNmMSBpdHNlbGYgcHJvdmlkZXMgZmlyZXdhbGwgdHJl YXRtZW50LCBJdCBsb29rcyBvbmUgc2Ygc3VwcG9ydHMgdHdvIGRpZmZlcmVudCB0cmVhdG1lbnRz LCBvbmUgaXMgZmlyZXdhbGwsIHRoZSBvdGhlciBpcyBsb2FkIGJhbGFuY2VyLg0KDQpIb3dldmVy IGlmIHdlIG1vdmUgbG9hZCBiYWxhbmNlciBmdW5jdGlvbmFsaXR5IHRvIFNGRiBvciBvdGhlciBi b3gsIGl0IHNlZW1zIHJlYXNvbmFibGUuDQpTbyB0aGUgcXVlc3Rpb24gaXMgY2FuIG9uZSBzZXJ2 aWNlIGZ1bmN0aW9uIHByb3ZpZGUgbW9yZSB0aGFuIG9uZSBzZXJ2aWNlIG9yIHRyZWF0bWVudD8N Cg0KSSBtYXkgbWlzcyB0aGUgZWFybGllciBkaXNjdXNzaW9uLCBwbGVhc2UgY29ycmVjdCBtZSBp ZiBJIGFtIHdyb25nLg0KDQpSZWdhcmRzIQ0KLVFpbg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K 5Y+R5Lu25Lq6OiBKb2VsIEhhbHBlcm4gRGlyZWN0IFttYWlsdG86am1oLmRpcmVjdEBqb2VsaGFs cGVybi5jb21dDQrlj5HpgIHml7bpl7Q6IDIwMTTlubQ15pyIMjnml6UgMjE6MTcNCuaUtuS7tuS6 ujogUWluIFd1OyBLZW4gR3JheSAoa2VncmF5KTsgTGluZGEgRHVuYmFyDQrmioTpgIE6IEpvZWwg TS4gSGFscGVybjsgUGF1bCBRdWlubiAocGF1bHEpOyBzZmNAaWV0Zi5vcmcNCuS4u+mimDogUmU6 IFtzZmNdIOetlOWkjTogcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2luZyBjb25zaWRlcmF0aW9u cyIgaW4gdGhlIGRyYWZ0LXF1aW5uLXNmYy1hcmNoLTA1DQoNCkkgYW0gbm90IGZvbGxvd2luZyB5 b3VyIHF1ZXN0aW9uLg0KU0ZGIGNhbiBoYXZlIGEgY28tbG9jYXRlZCBsb2FkIGJhbGFuY2VyLiAg T3IgdGhlIGxvYWQgYmFsYW5jZXIgY2FuIGJlIHRyYW5zcGFyZW50bHkgYmVoaW5kIHRoZSBTRkYs IHVzaW5nIGFueSBudW1iZXIgb2YgbWVjaGFuaXNtcy4NCldlIGFyZSBub3QgbWFuZGF0aW5nIHdo ZXJlIGl0IGlzIGxvY2F0ZWQuDQoNCllvdXJzLA0KSm9lbA0KDQpPbiA1LzI4LzE0LCAxMTo1NSBQ TSwgUWluIFd1IHdyb3RlOg0KPiBZb3UgYXJlIHRhbGtpbmcgYWJvdXQgc2VydmljZSBmdW5jdGlv biBzY2FsZSB1cCBhbmQgZG93bi4NCj4NCj4gU2luY2Ugc2VydmljZSBub2RlIGNhbiBob3N0IG9u ZSBvciBtdWx0aXBsZSBzZXJ2aWNlIGZ1bmN0aW9ucywgd2h5IA0KPiBzZXJ2aWNlIG5vZGUgY2Fu IG5vdCBiZSB1c2VkIHRvIGNvbnRyb2wgc2NhbGUgdXAgb3IgZG93biBvZiBzZXJ2aWNlIA0KPiBm dW5jdGlvbnMgaXQ/DQo+DQo+IFRvIGF2b2lkIHNoYXJlIHJpc2sgZmFpbHVyZSwgc2VydmljZSBu b2RlIGNhbiBiZSBwcmV2aW91cyBzZXJ2aWNlIA0KPiBub2RlLCBlLmcuLCBpdCBjYW4gYmUgdGhl IG9uZSB0aGF0IGhvc3RzIHNmMSBvciBzZjMuDQo+DQo+IEFsc28gU0ZGIGlzIHJlc3BvbnNpYmxl IGZvciBkZWxpdmVyaW5nIHRyYWZmaWMgdG8gYW55IGNvbm5lY3RlZCANCj4gc2VydmljZSBmdW5j dGlvbnMsIHdoeSBub3QgU0ZGIGNhbiBub3QgYmUgdXNlZCB0byBtYW5hZ2Ugc2NhbGUgdXAgb3Ig DQo+IGRvd24gb2Ygc2VydmljZSBmdW5jdGlvbi4NCj4NCj4gQWxzbyBiYXNlZCBvbiBORlYgTUFO TyBhcmNoaXRlY3R1cmUsIHRoZXJlIGlzIHJlZmVyZW5jZSBwb2ludCBiZXR3ZWVuIA0KPiBORlYg YW5kIE5GViBtYW5hZ2VyLCBORlYgbWFuYWdlciBhbHNvIGNhbiBjb250cm9sIHNjYWxlIHVwIG9y IGRvd24gb2YgDQo+IHNlcnZpY2UgZnVuY3Rpb24sIEkgdGhpbmsgdGhpcyBjYXNlIGhhcyBiZWVu IGNvdmVyZWQgYnkg4oCcdGhyb3VnaCANCj4gZXh0ZXJuYWwgY29udHJvbOKAnSBpbiB0aGUgZHJh ZnQuDQo+DQo+IFVzaW5nIHNmMSB0aGF0IHByb3ZpZGUgZGVkaWNhdGVkIGZpcmV3YWxsIHNlcnZp Y2UgdG8gcHJvdmlkZSBsb2FkIA0KPiBiYWxhbmNpbmcgZnVuY3Rpb25hbGl0eSBhcyB3ZWxsIGlz IGEgbGl0dGxlIGJpdCB3ZWlyZCB0byBtZS4NCj4NCj4gTGV0IG1lIGtub3cgaWYgbXkgdW5kZXJz dGFuZGluZyBpcyBjb3JyZWN0Pw0KPg0KPiBSZWdhcmRzIQ0KPg0KPiAtUWluDQo+DQo+ICrlj5Hk u7bkuro6KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSAq5Luj6KGoICpLZW4gR3Jh eSAoa2VncmF5KQ0KPiAq5Y+R6YCB5pe26Ze0OioyMDE05bm0NeaciDI55pelODo0OQ0KPiAq5pS2 5Lu25Lq6OipMaW5kYSBEdW5iYXINCj4gKuaKhOmAgToqSm9lbCBNLiBIYWxwZXJuOyBQYXVsIFF1 aW5uIChwYXVscSk7IHNmY0BpZXRmLm9yZw0KPiAq5Li76aKYOipSZTogW3NmY10gcXVlc3Rpb25z IG9mICJsb2FkIGJhbGFuY2luZyBjb25zaWRlcmF0aW9ucyIgaW4gdGhlDQo+IGRyYWZ0LXF1aW5u LXNmYy1hcmNoLTA1DQo+DQo+IEkgZG9uJ3Qgc2VlIGhvdyB5b3UgbWFrZSB0aGUgbGVhcCBmcm9t IHRoZSBleHBsYW5hdGlvbiBvZiB3aHkgaXQgd2FzIA0KPiBpcnJlbGV2YW50IHRvIGdvIGludG8g bW9yZSBkZXRhaWwgaW4gdGhlIHNlY3Rpb24gdG8gdGhlIGVsaW1pbmF0aW9uIG9mIA0KPiB0aGUg dmVyeSBnZW5lcmFsaXplZCBkZXNjcmlwdGlvbiBhY2NvbXBhbnlpbmcgdGhlIGZpZ3VyZS4gIFBs ZWFzZSB1c2UgDQo+IHlvdXIgb3duIGFyZ3VtZW50IHRvIGp1c3RpZnkgdGhpcyBhbmQgbm90IGlu ZmVyIGFueSBleHRyYSBtZWFuaW5nIGZyb20gDQo+IG15IGFuc3dlciB0byBhIGRpZmZlcmVudCBx dWVzdGlvbi4NCj4NCj4gQXMgdG8gdGhlIHNlY29uZCBjaGFuZ2UsIGkgZGlzYWdyZWUuICBBZ2Fp biwgaW4gZ2VuZXJhbC9icm9hZCBzdHJva2VzDQo+IC0gZnJvbSB0aGUgZHJhd2luZyBhbmQgdGhl IHRleHQsIGl0IGlzIHVubGlrZWx5IHRoYXQgYW55IHNwZWNpYWwgDQo+IGFjdGlvbiB3b3VsZCBi ZSByZXF1aXJlZCBvbiBzZjIgb3Igc2Y0IC0gYXMgdGhleSBjb2xsYXBzZSBpbiBlaXRoZXIgDQo+ IGRpcmVjdGlvbiB0byBhIHNpbmdsZSBsb2dpY2FsIG5leHQgaG9wLg0KPg0KPiBTZW50IGZyb20g bXkgaVBob25lDQo+DQo+DQo+IE9uIE1heSAyOCwgMjAxNCwgYXQgNTo0OSBQTSwgIkxpbmRhIER1 bmJhciIgPGxpbmRhLmR1bmJhckBodWF3ZWkuY29tIA0KPiA8bWFpbHRvOmxpbmRhLmR1bmJhckBo dWF3ZWkuY29tPj4gd3JvdGU6DQo+DQo+ICAgICBKb2VsLCBFcmljLCBhbmQgS2VuLA0KPg0KPiAg ICAgVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgdGhlIGV4cGxhbmF0aW9uLg0KPg0KPiAgICAgQmFz ZWQgb24gd2hhdCB5b3Ugc2FpZCwgdGhlIGRlc2NyaXB0aW9uIG9uIGhvdyDigJxjb250cm9sIGVu dGl0eSAgcHVzaA0KPiAgICAgdG8gdGhlIHNmMSBub2RlcyDigKbigJ0gc2hvdWxkIGJlIHJlbW92 ZWQgZnJvbSB0aGUgdGV4dCwgc3BlY2lmaWNhbGx5Og0KPg0KPiAgICAg4oCcSW4gdGhpcw0KPg0K PiAgICAgICAgIGNhc2UsIHRoZSBjb250cm9sIGVudGl0eSB3aWxsIHB1c2ggdG8gdGhlIHNmMSBu b2RlcywgYSB0YWJsZSANCj4gb2YNCj4NCj4gICAgICAgICBzb3J0czpbTDFdIDwjX21zb2NvbV8x PiBzZjIgd2l0aCBhIHNlcmllcyBvZiBuZXh0IGhvcHMsIGFuZCBpZg0KPiAgICAgbmVlZGVkIHNv bWUgd2VpZ2h0ZWQgb3INCj4NCj4gICAgICAgICBvdGhlciBtZXRyaWNzICh0aGVzZSBjb3VsZCBh bHNvIGJlIGRlY2lkZWQgbG9jYWxseSBieSBzb21lIA0KPiBwb2xpY3ksDQo+DQo+ICAgICAgICAg YnV0IHNmMSB3b3VsZCBuZWVkIHRvIGJlIGF3YXJlIG9mIGV4cGFuZC9jb250cmFjdCB0cmlnZ2Vy cyBhbmQNCj4NCj4gICAgICAgICBhY3Rpb25zKS7igJ0NCj4NCj4gICAgIFNob3VsZCBhbHNvIGNo YW5nZSB0aGUgc2VudGVuY2UgYWZ0ZXIgdGhlIEZpZ3VyZSA1IHRvDQo+DQo+ICAgICDigJxFaXRo ZXIgdGhyb3VnaCBhbiBpbWJlZGRlZCBhY3Rpb24gaW4gc2YxIGFuZCBzZjMsIHRoZSBTRkYgbm9k ZXMgdG8NCj4gICAgIHdoaWNoIHRoZSBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgU0YyIG9yIFNGNCBh cmUgYXR0YWNoZWQsIG9yIHRocm91Z2gNCj4gICAgIGV4dGVybmFsDQo+DQo+ICAgICAgICAgY29u dHJvbCwgdGhlIHNlcnZpY2UgZnVuY3Rpb25zIHNmMiBhbmQgc2Y0IGFyZSBlbGFzdGljYWxseSAN Cj4gZXhwYW5kZWQNCj4NCj4gICAgICAgICBhbmQgY29udHJhY3RlZCBkeW5hbWljYWxseS7igJ0N Cj4NCj4gICAgIExpbmRhDQo+DQo+ICAgICAqRnJvbToqS2VuIEdyYXkgKGtlZ3JheSkgW21haWx0 bzprZWdyYXlAY2lzY28uY29tXQ0KPiAgICAgKlNlbnQ6KiBXZWRuZXNkYXksIE1heSAyOCwgMjAx NCA0OjI0IFBNDQo+ICAgICAqVG86KiBMaW5kYSBEdW5iYXI7IFBhdWwgUXVpbm4gKHBhdWxxKTsg Sm9lbCBNLiBIYWxwZXJuDQo+ICAgICAqQ2M6KiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0 Zi5vcmc+DQo+ICAgICAqU3ViamVjdDoqIFJlOiBbc2ZjXSBxdWVzdGlvbnMgb2YgImxvYWQgYmFs YW5jaW5nIGNvbnNpZGVyYXRpb25zIiBpbg0KPiAgICAgdGhlIGRyYWZ0LXF1aW5uLXNmYy1hcmNo LTA1DQo+DQo+ICAgICArMSB0byBKb2VsIOKApiB0aGUgcGljdHVyZSB3b3VsZCBiZSB1Z2x5IGF0 IGJlc3QuICBXZSBhdHRlbXB0ZWQgYQ0KPiAgICAgZ2VuZXJpYyBIQS9MQiBzbGlkZSB0byBtYWtl IGEgcG9pbnQgYW5kIGV2ZW4gaXQgd2FzIHVnbHkg4oCmc3VjaCBhcmUNCj4gICAgIHRoZSBsaW1p dGF0aW9ucyBvZiBBU0NJSSBhcnQuDQo+DQo+ICAgICBJbiBsaW5lIOKApg0KPg0KPiAgICAgKkZy b206ICpMaW5kYSBEdW5iYXIgPGxpbmRhLmR1bmJhckBodWF3ZWkuY29tDQo+ICAgICA8bWFpbHRv OmxpbmRhLmR1bmJhckBodWF3ZWkuY29tPj4NCj4gICAgICpEYXRlOiAqV2VkbmVzZGF5LCBNYXkg MjgsIDIwMTQgMzozNCBQTQ0KPiAgICAgKlRvOiAqIlBhdWwgUXVpbm4gKHBhdWxxKSIgPHBhdWxx QGNpc2NvLmNvbQ0KPiAgICAgPG1haWx0bzpwYXVscUBjaXNjby5jb20+PiwgIkpvZWwgTS4gSGFs cGVybiIgPGptaEBqb2VsaGFscGVybi5jb20NCj4gICAgIDxtYWlsdG86am1oQGpvZWxoYWxwZXJu LmNvbT4+DQo+ICAgICAqQ2M6ICoic2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPiIg PHNmY0BpZXRmLm9yZw0KPiAgICAgPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KPiAgICAgKlN1Ympl Y3Q6ICpbc2ZjXSBxdWVzdGlvbnMgb2YgImxvYWQgYmFsYW5jaW5nIGNvbnNpZGVyYXRpb25zIiBp biB0aGUNCj4gICAgIGRyYWZ0LXF1aW5uLXNmYy1hcmNoLTA1DQo+DQo+ICAgICBQYXVsIGFuZCBK b2VsLA0KPg0KPiAgICAgRG9lcyB0aGUgTG9hZCBCYWxhbmNpbmcgRmlndXJlIDUgKG9mIGRyYWZ0 LXF1aW5uLXNmYy1hcmNoLTA1KSBhc3N1bWUNCj4gICAgIHRoYXQgU0YxIGlzIHJlc3BvbnNpYmxl IGZvciBiYWxhbmNpbmcgdHJhZmZpYyBhbW9uZyB0aGUgMyBpbnN0YW5jZXMNCj4gICAgIG9mIFNG MiwgYW5kIFNGMyBpcyByZXNwb25zaWJsZSBmb3IgYmFsYW5jaW5nIHRyYWZmaWMgYW1vbmcgdGhl IDMNCj4gICAgIGluc3RhbmNlcyBvZiBTRjQ/DQo+DQo+ICAgICA8a2VnPiBEb2N1bWVudCB0ZXh0 IGJlbG93IHRoZSBwaWN0dXJlIHNheXMgIkVpdGhlciB0aHJvdWdoIGFuDQo+ICAgICBpbWJlZGRl ZCBhY3Rpb24gaW4gc2YxIGFuZCBzZjMsIG9yIHRocm91Z2ggZXh0ZXJuYWwNCj4NCj4gICAgIGNv bnRyb2wsIHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyBzZjIgYW5kIHNmNCBhcmUgZWxhc3RpY2FsbHkN Cj4gICAgIGV4cGFuZGVkIGFuZCBjb250cmFjdGVkIGR5bmFtaWNhbGx5LiINCj4NCj4gICAgIElz buKAmXQgaXQgYSBzaW5nbGUgcG9pbnQgb2YgZmFpbHVyZT8NCj4NCj4gICAgIDxrZWc+IERvY3Vt ZW50IHRleHQgaW1tZWRpYXRlbHkgc3Vic2VxdWVudCB0byB0aGF0IHBpY3R1cmUgYW5kDQo+ICAg ICBwYXJhZ3JhcGggaWxsdXN0cmF0ZXMgSEEgc2NlbmFyaW9zLg0KPg0KPiAgICAgU29tZSBzZXJ2 aWNlIGZ1bmN0aW9ucyBhcmUgU3RhdGVmdWwsIGkuZS4gdGhleSBtYXkgcmVxdWlyZSBwYWNrZXRz DQo+ICAgICBmcm9tIHNhbWUgZmxvd3MgdG8gdHJhdmVyc2UgdGhlIHNhbWUgc2VydmljZSBmdW5j dGlvbiBpbnN0YW5jZS4gRm9yDQo+ICAgICB0aGUgTG9hZCBCYWxhbmNpbmcgc2NoZW1lIGRlc2Ny aWJlZCBieSBGaWd1cmUgNSwgZG8geW91IGFzc3VtZSB0aGF0DQo+ICAgICBTRjEgYW5kIFNGMyB3 aWxsIGJlIHJlc3BvbnNpYmxlIGZvciBtYWtpbmcgc3VyZSB0aGF0IHNhbWUgZmxvd3MgZ28NCj4g ICAgIHRocm91Z2ggdGhlIHNhbWUgc2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZT8NCj4NCj4gICAg IDxrZWc+IEFnYWluLCB0aGUgYWZvcmVtZW50aW9uZWQgdGV4dCBkZWxpYmVyYXRlbHkgYWxsb3dz IHRoaXMNCj4gICAgIHJlc3BvbnNpYmlsaXR5IHRvIGJlIGVpdGhlciBpbWJlZGRlZCBpbiB0aGUg ZWxhc3RpY2l0eS1jYXVzaW5nDQo+ICAgICBmdW5jdGlvbiBvciB0byBiZSBjb250cm9sbGVkIGV4 dGVybmFsbHkgb3IgY2VudHJhbGx5LiAgV2UgZG9uJ3QgZ2V0DQo+ICAgICBpbnRvIHRoZSBtZWNo YW5pY3MgYXMgdGhlc2UgY2FuIHZhcnkuICBXaGlsZSBzdGF0ZWZ1bC9iaWRpcmVjdGlvbmFsDQo+ ICAgICBkb2VzIGFkZCBhbiBhZGRpdGlvbmFsIGJ1cmRlbiwgaXQgY2FuIGJlIGFjY29tbW9kYXRl ZCB3aXRob3V0IGFuDQo+ICAgICBleHBsb3Npb24gb2YgZGlzY3JldGUgY2hhaW5zLiAgRm9yIGV4 YW1wbGUsIGl0IGNvdWxkIGJlIGhhbmRsZWQgImF0DQo+ICAgICBhbGxvY2F0aW9uIHRpbWUiIGlm IGVsYXN0aWNpdHkgaXMgbWFuYWdlZCB2aWEgYSBzZXBhcmF0ZSBlbnRpdHkgYW5kDQo+ICAgICB0 aGUgaW5kaXZpZHVhbCBhbGxvY2F0aW9ucyByZWZsZWN0ZWQgdGhyb3VnaCBzZXJ2aWNlIGNoYWlu IGNvbnRyb2wNCj4gICAgIGluIHRoZSBpbml0aWFsIG1ldGFkYXRhIGJvdW5kIHRvIGF0IHRoZSBj bGFzc2lmaWNhdGlvbiBwb2ludCBpbg0KPiAgICAgZWl0aGVyIGRpcmVjdGlvbi4gIE9SLCBpZiB0 aGUgZGV2aWNlcyBhcmUgd29ya2luZyBhcyBhIHBhaXJlZCBzeXN0ZW0NCj4gICAgIChzaW5nbGUg dmVuZG9yIG9yIGVjb3N5c3RlbSkgd2l0aCBpbnRlZ3JhdGVkIGVsYXN0aWNpdHksIHRoZXkgY291 bGQNCj4gICAgIHBhc3MgbWV0YWRhdGEgYmV0d2VlbiB0aGVtIHdoZW4gc2YxIG9yIHNmMyBkb2Vz IHRoZSBpbml0aWFsIGR5bmFtaWMNCj4gICAgIGFsbG9jYXRpb24gKGFmZmVjdGluZyBsb2NhbCBm b3J3YXJkaW5nIG9uIGl0J3MgcGFydG5lcikuICBUaGF0J3MNCj4gICAgIHByb2JhYmx5IG5vdCBh biBleGhhdXN0aXZlIGxpc3Qgb2Ygd2F5cyB0byBzb2x2ZSB0aGUgcHJvYmxlbS4gIDheKQ0KPg0K PiAgICAgPGtlZz4gVGhlIHBvaW50IG9mIHRoaXMgc2VjdGlvbiB3YXMgdGhhdCBlbGFzdGljaXR5 IGFuZCBIQSBzaG91bGQNCj4gICAgIG5vdCBjYXVzZSBhbiBpbm9yZGluYXRlIGV4cGxvc2lvbiBv ZiBkaXNjcmV0ZSBjaGFpbnMgd2l0aG91dA0KPiAgICAgcmVjb21tZW5kaW5nIGEgcGFydGljdWxh ciBzb2x1dGlvbi4gIFRoYXQgaXMsICB5b3Ugc2hvdWxkbid0IGNyZWF0ZQ0KPiAgICAgdW5uZWNl c3NhcnkgIGNvbXBsZXhpdHkgd2hlcmUgaXQgZG9lc24ndCBuZWVkIHRvIGV4aXN0Lg0KPg0KPiAg ICAgRm9yIHRoZSBzdGF0ZWZ1bCBzZXJ2aWNlIGZ1bmN0aW9ucywgaWYgYSBmbG93IGlzIHN3aXRj aGVkIGZyb20NCj4gICAgIFNGLUluc3RhbmNlLVggdG8gU0YtSW5zdGFuY2UtWSwgdGhlIFNGLUlu c3RhbmNlLVkgbmVlZHMgdG8NCj4gICAgIHN5bmNocm9uaXplIHRoZSBzdGF0ZXMgZnJvbSBTRi1J bnN0YW5jZS1YLiBXaG8gaXMgcmVzcG9uc2libGUgZm9yDQo+ICAgICB0aG9zZSBzdGF0ZXMgbWFp bnRlbmFuY2UgZm9yIHRoZSBMb2FkIEJhbGFuY2luZyBkZXNjcmliZWQgaW4gRmlndXJlIDU/DQo+ DQo+ICAgICA8a2VnPiBOb25lIG9mIHRob3NlIGVudGl0aWVzIGV4aXN0IGluIEZpZ3VyZSA1LiAg Q2FuIHlvdSByZS1waHJhc2UNCj4gICAgIHlvdXIgcXVlc3Rpb24gZnJvbSB0aGUgZmlndXJlPw0K Pg0KPiAgICAgTGluZGENCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLQ0KPg0KPiBSZXF1aXJlIHB1 c2hpbmcgcG9saWNpZXMgdG8gU0YxIG9uIGhvdyB0byBsb2FkIGJhbGFuY2UgbXVsdGlwbGUgDQo+ IGluc3RhbmNlcyBvZiBTRjIuDQo+DQo+IFNGMSBtYXkgbm90IGhhdmUgdGhlIGNhcGFiaWxpdHkg dG8gYmFsYW5jZSBhbW9uZyBtdWx0aXBsZSBpbnN0YW5jZXMgb2YNCj4gU0YyDQo+DQo+DQo+DQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBt YWlsaW5nIGxpc3QNCj4gc2ZjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjDQo+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg== From nobody Fri May 30 18:24:50 2014 Return-Path: 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 E97D21A043C for ; Fri, 30 May 2014 18:24:47 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): References: ...A837316@MBX021-W3-CA-2.exch021.domain.local>\n X-Spam-Flag: NO X-Spam-Score: -4.552 X-Spam-Level: X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 MDanzIu_SXPK for ; Fri, 30 May 2014 18:24:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB9251A0354 for ; Fri, 30 May 2014 18:24:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHL48899; Sat, 31 May 2014 01:24:38 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 31 May 2014 02:23:59 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 31 May 2014 02:24:37 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.193]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Sat, 31 May 2014 09:24:24 +0800 From: Qin Wu To: Ron Parker , Joel Halpern Direct , "Ken Gray (kegray)" , "Linda Dunbar" Thread-Topic: =?utf-8?B?W3NmY10g562U5aSNOiAg562U5aSNOiAgcXVlc3Rpb25zIG9mICJsb2FkIGJh?= =?utf-8?B?bGFuY2luZyBjb25zaWRlcmF0aW9ucyIgaW4gdGhlIGRyYWZ0LXF1aW5uLXNm?= =?utf-8?Q?c-arch-05?= Thread-Index: AQHPfAzVH8SwdaDD7k+69OAQE4kz2ptZ2yiwgAAJ7JA= Date: Sat, 31 May 2014 01:24:24 +0000 Message-ID: References: , <4A95BA014132FF49AE685FAB4B9F17F645D2762A@dfweml701-chm.china.huawei.com> <16984558-2B4C-4873-AFC7-DCD2698CA745@cisco.com> <53873333.80807@joelhalpern.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.131] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/8mZl-WAUQ4MRJGvgOMhqTNvX4sM Cc: "Joel M. Halpern" , "Paul Quinn \(paulq\)" , "sfc@ietf.org" Subject: [sfc] =?utf-8?b?562U5aSNOiAg562U5aSNOiAg562U5aSNOiAgcXVlc3Rpb25z?= =?utf-8?q?_of_=22load_balancing_considerations=22_in_the_draft-quinn-sfc-?= =?utf-8?q?arch-05?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 01:24:48 -0000 T25lIHBvaW50IHRvIGFkZCwgaW4gY2FzZSBzZXZlcmFsIFNGcyBhcmUgY28tbG9jYXRlZCBpbiB0 aGUgc2FtZSBub2RlIG9yIFNGRiwgdGhlIHBhY2tldCBpcyBwcm9jZXNzZWQgYnkNCmFsbCBTRnMg aW4gdGhlIFNGRiwgT25jZSB0aGUgcGFja2V0IGlzIHN1Y2Nlc3NmdWxseSBoYW5kbGVkIGJ5IG9u ZSBTRiwgdGhlIHBhY2tldCBpcyBmb3J3YXJkZWQNCnRvIHRoZSBuZXh0IFNGIHRoYXQgaXMgaW4g dGhlIHNhbWUgU0ZGLg0KDQpSZWdhcmRzIQ0KLVFpbg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K 5Y+R5Lu25Lq6OiBRaW4gV3UgDQrlj5HpgIHml7bpl7Q6IDIwMTTlubQ15pyIMzHml6UgOTowOA0K 5pS25Lu25Lq6OiAnUm9uIFBhcmtlcic7IEpvZWwgSGFscGVybiBEaXJlY3Q7IEtlbiBHcmF5IChr ZWdyYXkpOyBMaW5kYSBEdW5iYXINCuaKhOmAgTogSm9lbCBNLiBIYWxwZXJuOyBQYXVsIFF1aW5u IChwYXVscSk7IHNmY0BpZXRmLm9yZw0K5Li76aKYOiDnrZTlpI06IFtzZmNdIOetlOWkjTog562U 5aSNOiBxdWVzdGlvbnMgb2YgImxvYWQgYmFsYW5jaW5nIGNvbnNpZGVyYXRpb25zIiBpbiB0aGUg ZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDUNCg0KSGksIFJvbjoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0t LS0NCuWPkeS7tuS6ujogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBS b24gUGFya2VyDQrlj5HpgIHml7bpl7Q6IDIwMTTlubQ15pyIMzDml6UgMjE6NDENCuaUtuS7tuS6 ujogUWluIFd1OyBKb2VsIEhhbHBlcm4gRGlyZWN0OyBLZW4gR3JheSAoa2VncmF5KTsgTGluZGEg RHVuYmFyDQrmioTpgIE6IEpvZWwgTS4gSGFscGVybjsgUGF1bCBRdWlubiAocGF1bHEpOyBzZmNA aWV0Zi5vcmcNCuS4u+mimDogUmU6IFtzZmNdIOetlOWkjTog562U5aSNOiBxdWVzdGlvbnMgb2Yg ImxvYWQgYmFsYW5jaW5nIGNvbnNpZGVyYXRpb25zIiBpbiB0aGUgZHJhZnQtcXVpbm4tc2ZjLWFy Y2gtMDUNCg0KUWluLA0KDQpSZWdhcmRpbmcgeW91ciBxdWVzdGlvbjoNCglTbyB0aGUgcXVlc3Rp b24gaXMgY2FuIG9uZSBzZXJ2aWNlIGZ1bmN0aW9uIHByb3ZpZGUgbW9yZSB0aGFuIG9uZSBzZXJ2 aWNlIG9yIHRyZWF0bWVudD8NCg0KDQpBIHNlcnZpY2UgZnVuY3Rpb24gY2FuIGJlIHRob3VnaHQg b2YgYXMgYSBsb2dpY2FsIGNvbnN0cnVjdC4gICBNb3JlIHRoYW4gb25lIHN1Y2ggc2VydmljZSBm dW5jdGlvbiBjb3VsZCBiZSBjby1sb2NhdGVkIGF0IHRoZSBzYW1lIGxvY2F0b3IgKGkuZS4sIElQ IGFkZHJlc3MpLiAgIEkuZS4sIGEgc2luZ2xlIG1hbmFnZW1lbnQgZW50aXR5IHdpdGggYSBzaW5n bGUgSVAgYWRkcmVzcyBjb3VsZCBwcm92aWRlIG11bHRpcGxlIHNlcnZpY2UgZnVuY3Rpb25zIHNp bXVsdGFuZW91c2x5LiAgIEluIGNhc2VzIHdoZXJlIHRoZSBzaW5nbGUgbWFuYWdlZCBlbnRpdHkg d2FzIGFza2VkIHRvIHBlcmZvcm0gbXVsdGlwbGUgc2VydmljZSBmdW5jdGlvbnMgdGhhdCB3ZXJl IGNvbnNlY3V0aXZlIGluIHRoZSBzZXJ2aWNlIGNoYWluLCBhcyBhbiBvcHRpbWl6YXRpb24gaXQg c2hvdWxkIG5vdCBiZSBuZWNlc3NhcnkgdG8gcmV0dXJuIHRoZSB0cmFmZmljIHRvIHRoZSBTRkYg aW4gYmV0d2VlbiB0aG9zZSBzZXJ2aWNlIGZ1bmN0aW9ucy4gDQoNCltRaW5dOiBZZXMsIElmIG9u ZSBTRkYgaG9zdHMgdHdvIHNlcnZpY2UgZnVuY3Rpb25zIGFuZCB0aGVzZSB0d28gc2VydmljZSBm dW5jdGlvbnMgYXJlIGNvbnNlY3V0aXZlIGluIHRoZSBzYW1lIHNlcnZpY2UgY2hhaW4sIFN1cmUs IHRoZSB0cmFmZmljIGRvZXNuJ3QgbmVlZCB0byBiZSByZXR1cm5lZCB0byB0aGUgU0ZGIGZvciBl YWNoIG9mIHNlcnZpY2UgZnVuY3Rpb25zIHRoYXQgYXJlIGNvbGxvY2F0ZWQgYXQgU0ZGLiBJIGZ1 bGx5IGFncmVlLg0KDQpBbm90aGVyIGFzcGVjdCBvZiB5b3VyIHF1ZXN0aW9uIHdhcyBjYW4gdGhl IHNhbWUgbG9naWNhbCBzZXJ2aWNlIGZ1bmN0aW9uIHByb3ZpZGUgbW9yZSB0aGFuIG9uZSB0cmVh dG1lbnQ/ICAgIFRoZXJlIGFyZSBhdCBsZWFzdCAzIGFwcHJvYWNoZXMgdG8gdGhpcy4gICBJbiB0 aGUgZmlyc3QsIGVhY2ggZGlmZmVyZW50aWF0ZWQgYmVoYXZpb3IgaXMgcmVwcmVzZW50ZWQgYXMg YSBkaXN0aW5jdCBsb2dpY2FsIHNlcnZpY2UgZnVuY3Rpb24gLS0gaS5lLiwgY29udGVudF9maWx0 ZXJfYWR1bHQsIGNvbnRlbnRfZmlsdGVyX2NoaWxkLiAgIEluIHRoZSBzZWNvbmQgYXBwcm9hY2gs IGEgc2luZ2xlIHNlcnZpY2UgZnVuY3Rpb24gKGkuZS4sIGNvbnRlbnRfZmlsdGVyKSBoYXMgaXRz IG93biBwcml2YXRlIG1lY2hhbmlzbSB0byBkZXRlcm1pbmUgd2hpY2ggYmVoYXZpb3IgdG8gYXBw bHkgKGkuZS4sIGEgbWlycm9yZWQgUkFESVVTIGZlZWQgdGVhY2hlcyBpdCBzdWJzY3JpYmVyIHBy b3BlcnRpZXMgcmVsYXRlZCB0byBzdWJzY3JpYmVyIElQIGFkZHJlc3NlcykuICAgQSB0aGlyZCBh cHByb2FjaCBpcyB0aGF0IHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGNvbnRyb2xsZXIgaW5zZXJ0cyBt ZXRhZGF0YSB0byB0aGUgcGFja2V0IHN0cmVhbSB0aGF0IHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGNh biBpbnRlcnByZXQgZm9yIHB1cnBvc2VzIG9mIHByb3ZpZGluZyBhIGRpZmZlcmVudGlhdGVkIGJl aGF2aW9yIChpLmUuLCBzdWJzY3JpYmVyX3R5cGU9Y2hpbGQpLg0KDQpbUWluXTogTXkgcXVlc3Rp b24gYWN0dWFsbHkgaXM6IENhbiBmaXJld2FsbCBzZXJ2aWNlIGZ1bmN0aW9uIHByb3ZpZGUgbG9h ZCBiYWxhbmNlciBzZXJ2aWNlPw0KSW4geW91ciBleGFtcGxlIGFwcHJvYWNoZXMsIGl0IGxvb2tz IGEgZGlmZmVyZW50aWF0ZWQgYmVoYXZpb3JzIHByb3ZpZGVkIGJ5IG9uZSBzZXJ2aWNlIGZ1bmN0 aW9uIGFyZSBxdWl0ZSBzaW1pbGFyLCBlLmcuLCBjb250ZW50X2ZpbGVyX2FkdWx0IGFuZCBjb250 ZW50X2ZpbGVyX2NoaWxkLCBib3RoIGFyZSBjb250ZW50IGZpbGVyIHNlcnZpY2UuDQpJIGFtIHdv bmRlcmluZyBjYW4gb25lIEhUVFAgb3B0aW1pemF0aW9uIHNlcnZpY2UgZnVuY3Rpb24gcHJvdmlk aW5nIGRpZmZlcmVudGlhdGUgYmVoYXZpb3JzIGFsc28gc3VwcG9ydCBsb2FkIGJhbGFuY2VyIHNl cnZpY2U/IENhbiB0d28gc2VydmljZSBmdW5jdGlvbnMgcHJvdmlkaW5nIGRpZmZlcmVudCBzZXJ2 aWNlIGFuZCBlbWJlZGRlZCBpbiB0aGUgc2FtZSBuZXR3b3JrIGVsZW1lbnQgYmUgY29tYmluZWQg aW50byBvbmUgc2VydmljZSBmdW5jdGlvbj8NCklmIHRoZSBhbnN3ZXIgaXMgeWVzLCB0aGUgZGVm aW5pdGlvbiBvZiBzZXJ2aWNlIGZ1bmN0aW9uIGluIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBkcmFm dCBuZWVkcyB0byBiZSByZXZpc2l0ZWQgYW5kIGNoYW5nZWQgc2luY2Ugc2VydmljZSBmdW5jdGlv biBjYW4gYmUgcmVzcG9uc2libGUgZm9yIG1vcmUgdGhhbiBvbmUgdHJlYXRtZW50cyBhbmQgZWFj aCB0cmVhdG1lbnQgcHJvdmlkZSBkaWZmZXJlbnQgc2VydmljZS4NCiINCkkgZG9uJ3QgdGhpbmsg dGhpcyBpcyBjb3JyZWN0Lg0KDQogICBSb24NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IFFpbiBXdQ0KU2VudDogVGh1cnNkYXksIE1heSAyOSwgMjAxNCAxMToyNyBQTQ0KVG86IEpvZWwg SGFscGVybiBEaXJlY3Q7IEtlbiBHcmF5IChrZWdyYXkpOyBMaW5kYSBEdW5iYXINCkNjOiBKb2Vs IE0uIEhhbHBlcm47IFBhdWwgUXVpbm4gKHBhdWxxKTsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBb c2ZjXSDnrZTlpI06IOetlOWkjTogcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2luZyBjb25zaWRl cmF0aW9ucyIgaW4gdGhlIGRyYWZ0LXF1aW5uLXNmYy1hcmNoLTA1DQoNCkhpLCBKb2VsOg0KVGhh bmsgZm9yIHlvdXIgY2xhcmlmaWNhdGlvbi4gDQppZiBsb2FkIGJhbGFuY2VyIGlzIHJlYWxseSBu ZWVkZWQgYW5kIGl0IGlzIG5vdCBhIHNlcnZpY2UgZnVuY3Rpb24gaW4gdGhlIGNoYWluLCBJIGFn cmVlIHdlIHNob3VsZCBub3QgbWFuZGF0ZSBpdHMgbG9jYXRpb24uDQpTbyB0aGUgZm9sbG93aW5n IGRlc2NyaXB0aW9uIGluIHRoZSBkcmFmdCBpcyB2ZXJ5IHJlc3RyaWN0aXZlICINCkVpdGhlciB0 aHJvdWdoIGFuIGltYmVkZGVkIGFjdGlvbiBpbiBzZjEgYW5kIHNmMywgb3IgdGhyb3VnaCBleHRl cm5hbCBjb250cm9sICINCkl0IHNlZW1zIGV4Y2x1ZGluZyBoYXZpbmcgbG9hZCBiYWxhbmNlciBv biB0aGUgU0ZGLg0KQWxzbyBpZiAgc2YxIHJlcXVpcmVzIGxvYWQgYmFsYW5jZXIgYW5kIHNmMSBp dHNlbGYgcHJvdmlkZXMgZmlyZXdhbGwgdHJlYXRtZW50LCBJdCBsb29rcyBvbmUgc2Ygc3VwcG9y dHMgdHdvIGRpZmZlcmVudCB0cmVhdG1lbnRzLCBvbmUgaXMgZmlyZXdhbGwsIHRoZSBvdGhlciBp cyBsb2FkIGJhbGFuY2VyLg0KDQpIb3dldmVyIGlmIHdlIG1vdmUgbG9hZCBiYWxhbmNlciBmdW5j dGlvbmFsaXR5IHRvIFNGRiBvciBvdGhlciBib3gsIGl0IHNlZW1zIHJlYXNvbmFibGUuDQpTbyB0 aGUgcXVlc3Rpb24gaXMgY2FuIG9uZSBzZXJ2aWNlIGZ1bmN0aW9uIHByb3ZpZGUgbW9yZSB0aGFu IG9uZSBzZXJ2aWNlIG9yIHRyZWF0bWVudD8NCg0KSSBtYXkgbWlzcyB0aGUgZWFybGllciBkaXNj dXNzaW9uLCBwbGVhc2UgY29ycmVjdCBtZSBpZiBJIGFtIHdyb25nLg0KDQpSZWdhcmRzIQ0KLVFp bg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBKb2VsIEhhbHBlcm4gRGlyZWN0 IFttYWlsdG86am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb21dDQrlj5HpgIHml7bpl7Q6IDIwMTTl ubQ15pyIMjnml6UgMjE6MTcNCuaUtuS7tuS6ujogUWluIFd1OyBLZW4gR3JheSAoa2VncmF5KTsg TGluZGEgRHVuYmFyDQrmioTpgIE6IEpvZWwgTS4gSGFscGVybjsgUGF1bCBRdWlubiAocGF1bHEp OyBzZmNAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtzZmNdIOetlOWkjTogcXVlc3Rpb25zIG9mICJs b2FkIGJhbGFuY2luZyBjb25zaWRlcmF0aW9ucyIgaW4gdGhlIGRyYWZ0LXF1aW5uLXNmYy1hcmNo LTA1DQoNCkkgYW0gbm90IGZvbGxvd2luZyB5b3VyIHF1ZXN0aW9uLg0KU0ZGIGNhbiBoYXZlIGEg Y28tbG9jYXRlZCBsb2FkIGJhbGFuY2VyLiAgT3IgdGhlIGxvYWQgYmFsYW5jZXIgY2FuIGJlIHRy YW5zcGFyZW50bHkgYmVoaW5kIHRoZSBTRkYsIHVzaW5nIGFueSBudW1iZXIgb2YgbWVjaGFuaXNt cy4NCldlIGFyZSBub3QgbWFuZGF0aW5nIHdoZXJlIGl0IGlzIGxvY2F0ZWQuDQoNCllvdXJzLA0K Sm9lbA0KDQpPbiA1LzI4LzE0LCAxMTo1NSBQTSwgUWluIFd1IHdyb3RlOg0KPiBZb3UgYXJlIHRh bGtpbmcgYWJvdXQgc2VydmljZSBmdW5jdGlvbiBzY2FsZSB1cCBhbmQgZG93bi4NCj4NCj4gU2lu Y2Ugc2VydmljZSBub2RlIGNhbiBob3N0IG9uZSBvciBtdWx0aXBsZSBzZXJ2aWNlIGZ1bmN0aW9u cywgd2h5IA0KPiBzZXJ2aWNlIG5vZGUgY2FuIG5vdCBiZSB1c2VkIHRvIGNvbnRyb2wgc2NhbGUg dXAgb3IgZG93biBvZiBzZXJ2aWNlIA0KPiBmdW5jdGlvbnMgaXQ/DQo+DQo+IFRvIGF2b2lkIHNo YXJlIHJpc2sgZmFpbHVyZSwgc2VydmljZSBub2RlIGNhbiBiZSBwcmV2aW91cyBzZXJ2aWNlIA0K PiBub2RlLCBlLmcuLCBpdCBjYW4gYmUgdGhlIG9uZSB0aGF0IGhvc3RzIHNmMSBvciBzZjMuDQo+ DQo+IEFsc28gU0ZGIGlzIHJlc3BvbnNpYmxlIGZvciBkZWxpdmVyaW5nIHRyYWZmaWMgdG8gYW55 IGNvbm5lY3RlZCANCj4gc2VydmljZSBmdW5jdGlvbnMsIHdoeSBub3QgU0ZGIGNhbiBub3QgYmUg dXNlZCB0byBtYW5hZ2Ugc2NhbGUgdXAgb3IgDQo+IGRvd24gb2Ygc2VydmljZSBmdW5jdGlvbi4N Cj4NCj4gQWxzbyBiYXNlZCBvbiBORlYgTUFOTyBhcmNoaXRlY3R1cmUsIHRoZXJlIGlzIHJlZmVy ZW5jZSBwb2ludCBiZXR3ZWVuIA0KPiBORlYgYW5kIE5GViBtYW5hZ2VyLCBORlYgbWFuYWdlciBh bHNvIGNhbiBjb250cm9sIHNjYWxlIHVwIG9yIGRvd24gb2YgDQo+IHNlcnZpY2UgZnVuY3Rpb24s IEkgdGhpbmsgdGhpcyBjYXNlIGhhcyBiZWVuIGNvdmVyZWQgYnkg4oCcdGhyb3VnaCANCj4gZXh0 ZXJuYWwgY29udHJvbOKAnSBpbiB0aGUgZHJhZnQuDQo+DQo+IFVzaW5nIHNmMSB0aGF0IHByb3Zp ZGUgZGVkaWNhdGVkIGZpcmV3YWxsIHNlcnZpY2UgdG8gcHJvdmlkZSBsb2FkIA0KPiBiYWxhbmNp bmcgZnVuY3Rpb25hbGl0eSBhcyB3ZWxsIGlzIGEgbGl0dGxlIGJpdCB3ZWlyZCB0byBtZS4NCj4N Cj4gTGV0IG1lIGtub3cgaWYgbXkgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0Pw0KPg0KPiBSZWdh cmRzIQ0KPg0KPiAtUWluDQo+DQo+ICrlj5Hku7bkuro6KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2Vz QGlldGYub3JnXSAq5Luj6KGoICpLZW4gR3JheSAoa2VncmF5KQ0KPiAq5Y+R6YCB5pe26Ze0Oioy MDE05bm0NeaciDI55pelODo0OQ0KPiAq5pS25Lu25Lq6OipMaW5kYSBEdW5iYXINCj4gKuaKhOmA gToqSm9lbCBNLiBIYWxwZXJuOyBQYXVsIFF1aW5uIChwYXVscSk7IHNmY0BpZXRmLm9yZw0KPiAq 5Li76aKYOipSZTogW3NmY10gcXVlc3Rpb25zIG9mICJsb2FkIGJhbGFuY2luZyBjb25zaWRlcmF0 aW9ucyIgaW4gdGhlDQo+IGRyYWZ0LXF1aW5uLXNmYy1hcmNoLTA1DQo+DQo+IEkgZG9uJ3Qgc2Vl IGhvdyB5b3UgbWFrZSB0aGUgbGVhcCBmcm9tIHRoZSBleHBsYW5hdGlvbiBvZiB3aHkgaXQgd2Fz IA0KPiBpcnJlbGV2YW50IHRvIGdvIGludG8gbW9yZSBkZXRhaWwgaW4gdGhlIHNlY3Rpb24gdG8g dGhlIGVsaW1pbmF0aW9uIG9mIA0KPiB0aGUgdmVyeSBnZW5lcmFsaXplZCBkZXNjcmlwdGlvbiBh Y2NvbXBhbnlpbmcgdGhlIGZpZ3VyZS4gIFBsZWFzZSB1c2UgDQo+IHlvdXIgb3duIGFyZ3VtZW50 IHRvIGp1c3RpZnkgdGhpcyBhbmQgbm90IGluZmVyIGFueSBleHRyYSBtZWFuaW5nIGZyb20gDQo+ IG15IGFuc3dlciB0byBhIGRpZmZlcmVudCBxdWVzdGlvbi4NCj4NCj4gQXMgdG8gdGhlIHNlY29u ZCBjaGFuZ2UsIGkgZGlzYWdyZWUuICBBZ2FpbiwgaW4gZ2VuZXJhbC9icm9hZCBzdHJva2VzDQo+ IC0gZnJvbSB0aGUgZHJhd2luZyBhbmQgdGhlIHRleHQsIGl0IGlzIHVubGlrZWx5IHRoYXQgYW55 IHNwZWNpYWwgDQo+IGFjdGlvbiB3b3VsZCBiZSByZXF1aXJlZCBvbiBzZjIgb3Igc2Y0IC0gYXMg dGhleSBjb2xsYXBzZSBpbiBlaXRoZXIgDQo+IGRpcmVjdGlvbiB0byBhIHNpbmdsZSBsb2dpY2Fs IG5leHQgaG9wLg0KPg0KPiBTZW50IGZyb20gbXkgaVBob25lDQo+DQo+DQo+IE9uIE1heSAyOCwg MjAxNCwgYXQgNTo0OSBQTSwgIkxpbmRhIER1bmJhciIgPGxpbmRhLmR1bmJhckBodWF3ZWkuY29t IA0KPiA8bWFpbHRvOmxpbmRhLmR1bmJhckBodWF3ZWkuY29tPj4gd3JvdGU6DQo+DQo+ICAgICBK b2VsLCBFcmljLCBhbmQgS2VuLA0KPg0KPiAgICAgVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgdGhl IGV4cGxhbmF0aW9uLg0KPg0KPiAgICAgQmFzZWQgb24gd2hhdCB5b3Ugc2FpZCwgdGhlIGRlc2Ny aXB0aW9uIG9uIGhvdyDigJxjb250cm9sIGVudGl0eSAgcHVzaA0KPiAgICAgdG8gdGhlIHNmMSBu b2RlcyDigKbigJ0gc2hvdWxkIGJlIHJlbW92ZWQgZnJvbSB0aGUgdGV4dCwgc3BlY2lmaWNhbGx5 Og0KPg0KPiAgICAg4oCcSW4gdGhpcw0KPg0KPiAgICAgICAgIGNhc2UsIHRoZSBjb250cm9sIGVu dGl0eSB3aWxsIHB1c2ggdG8gdGhlIHNmMSBub2RlcywgYSB0YWJsZSANCj4gb2YNCj4NCj4gICAg ICAgICBzb3J0czpbTDFdIDwjX21zb2NvbV8xPiBzZjIgd2l0aCBhIHNlcmllcyBvZiBuZXh0IGhv cHMsIGFuZCBpZg0KPiAgICAgbmVlZGVkIHNvbWUgd2VpZ2h0ZWQgb3INCj4NCj4gICAgICAgICBv dGhlciBtZXRyaWNzICh0aGVzZSBjb3VsZCBhbHNvIGJlIGRlY2lkZWQgbG9jYWxseSBieSBzb21l IA0KPiBwb2xpY3ksDQo+DQo+ICAgICAgICAgYnV0IHNmMSB3b3VsZCBuZWVkIHRvIGJlIGF3YXJl IG9mIGV4cGFuZC9jb250cmFjdCB0cmlnZ2VycyBhbmQNCj4NCj4gICAgICAgICBhY3Rpb25zKS7i gJ0NCj4NCj4gICAgIFNob3VsZCBhbHNvIGNoYW5nZSB0aGUgc2VudGVuY2UgYWZ0ZXIgdGhlIEZp Z3VyZSA1IHRvDQo+DQo+ICAgICDigJxFaXRoZXIgdGhyb3VnaCBhbiBpbWJlZGRlZCBhY3Rpb24g aW4gc2YxIGFuZCBzZjMsIHRoZSBTRkYgbm9kZXMgdG8NCj4gICAgIHdoaWNoIHRoZSBtdWx0aXBs ZSBpbnN0YW5jZXMgb2YgU0YyIG9yIFNGNCBhcmUgYXR0YWNoZWQsIG9yIHRocm91Z2gNCj4gICAg IGV4dGVybmFsDQo+DQo+ICAgICAgICAgY29udHJvbCwgdGhlIHNlcnZpY2UgZnVuY3Rpb25zIHNm MiBhbmQgc2Y0IGFyZSBlbGFzdGljYWxseSANCj4gZXhwYW5kZWQNCj4NCj4gICAgICAgICBhbmQg Y29udHJhY3RlZCBkeW5hbWljYWxseS7igJ0NCj4NCj4gICAgIExpbmRhDQo+DQo+ICAgICAqRnJv bToqS2VuIEdyYXkgKGtlZ3JheSkgW21haWx0bzprZWdyYXlAY2lzY28uY29tXQ0KPiAgICAgKlNl bnQ6KiBXZWRuZXNkYXksIE1heSAyOCwgMjAxNCA0OjI0IFBNDQo+ICAgICAqVG86KiBMaW5kYSBE dW5iYXI7IFBhdWwgUXVpbm4gKHBhdWxxKTsgSm9lbCBNLiBIYWxwZXJuDQo+ICAgICAqQ2M6KiBz ZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ICAgICAqU3ViamVjdDoqIFJlOiBb c2ZjXSBxdWVzdGlvbnMgb2YgImxvYWQgYmFsYW5jaW5nIGNvbnNpZGVyYXRpb25zIiBpbg0KPiAg ICAgdGhlIGRyYWZ0LXF1aW5uLXNmYy1hcmNoLTA1DQo+DQo+ICAgICArMSB0byBKb2VsIOKApiB0 aGUgcGljdHVyZSB3b3VsZCBiZSB1Z2x5IGF0IGJlc3QuICBXZSBhdHRlbXB0ZWQgYQ0KPiAgICAg Z2VuZXJpYyBIQS9MQiBzbGlkZSB0byBtYWtlIGEgcG9pbnQgYW5kIGV2ZW4gaXQgd2FzIHVnbHkg 4oCmc3VjaCBhcmUNCj4gICAgIHRoZSBsaW1pdGF0aW9ucyBvZiBBU0NJSSBhcnQuDQo+DQo+ICAg ICBJbiBsaW5lIOKApg0KPg0KPiAgICAgKkZyb206ICpMaW5kYSBEdW5iYXIgPGxpbmRhLmR1bmJh ckBodWF3ZWkuY29tDQo+ICAgICA8bWFpbHRvOmxpbmRhLmR1bmJhckBodWF3ZWkuY29tPj4NCj4g ICAgICpEYXRlOiAqV2VkbmVzZGF5LCBNYXkgMjgsIDIwMTQgMzozNCBQTQ0KPiAgICAgKlRvOiAq IlBhdWwgUXVpbm4gKHBhdWxxKSIgPHBhdWxxQGNpc2NvLmNvbQ0KPiAgICAgPG1haWx0bzpwYXVs cUBjaXNjby5jb20+PiwgIkpvZWwgTS4gSGFscGVybiIgPGptaEBqb2VsaGFscGVybi5jb20NCj4g ICAgIDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+DQo+ICAgICAqQ2M6ICoic2ZjQGlldGYu b3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPiIgPHNmY0BpZXRmLm9yZw0KPiAgICAgPG1haWx0bzpz ZmNAaWV0Zi5vcmc+Pg0KPiAgICAgKlN1YmplY3Q6ICpbc2ZjXSBxdWVzdGlvbnMgb2YgImxvYWQg YmFsYW5jaW5nIGNvbnNpZGVyYXRpb25zIiBpbiB0aGUNCj4gICAgIGRyYWZ0LXF1aW5uLXNmYy1h cmNoLTA1DQo+DQo+ICAgICBQYXVsIGFuZCBKb2VsLA0KPg0KPiAgICAgRG9lcyB0aGUgTG9hZCBC YWxhbmNpbmcgRmlndXJlIDUgKG9mIGRyYWZ0LXF1aW5uLXNmYy1hcmNoLTA1KSBhc3N1bWUNCj4g ICAgIHRoYXQgU0YxIGlzIHJlc3BvbnNpYmxlIGZvciBiYWxhbmNpbmcgdHJhZmZpYyBhbW9uZyB0 aGUgMyBpbnN0YW5jZXMNCj4gICAgIG9mIFNGMiwgYW5kIFNGMyBpcyByZXNwb25zaWJsZSBmb3Ig YmFsYW5jaW5nIHRyYWZmaWMgYW1vbmcgdGhlIDMNCj4gICAgIGluc3RhbmNlcyBvZiBTRjQ/DQo+ DQo+ICAgICA8a2VnPiBEb2N1bWVudCB0ZXh0IGJlbG93IHRoZSBwaWN0dXJlIHNheXMgIkVpdGhl ciB0aHJvdWdoIGFuDQo+ICAgICBpbWJlZGRlZCBhY3Rpb24gaW4gc2YxIGFuZCBzZjMsIG9yIHRo cm91Z2ggZXh0ZXJuYWwNCj4NCj4gICAgIGNvbnRyb2wsIHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyBz ZjIgYW5kIHNmNCBhcmUgZWxhc3RpY2FsbHkNCj4gICAgIGV4cGFuZGVkIGFuZCBjb250cmFjdGVk IGR5bmFtaWNhbGx5LiINCj4NCj4gICAgIElzbuKAmXQgaXQgYSBzaW5nbGUgcG9pbnQgb2YgZmFp bHVyZT8NCj4NCj4gICAgIDxrZWc+IERvY3VtZW50IHRleHQgaW1tZWRpYXRlbHkgc3Vic2VxdWVu dCB0byB0aGF0IHBpY3R1cmUgYW5kDQo+ICAgICBwYXJhZ3JhcGggaWxsdXN0cmF0ZXMgSEEgc2Nl bmFyaW9zLg0KPg0KPiAgICAgU29tZSBzZXJ2aWNlIGZ1bmN0aW9ucyBhcmUgU3RhdGVmdWwsIGku ZS4gdGhleSBtYXkgcmVxdWlyZSBwYWNrZXRzDQo+ICAgICBmcm9tIHNhbWUgZmxvd3MgdG8gdHJh dmVyc2UgdGhlIHNhbWUgc2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZS4gRm9yDQo+ICAgICB0aGUg TG9hZCBCYWxhbmNpbmcgc2NoZW1lIGRlc2NyaWJlZCBieSBGaWd1cmUgNSwgZG8geW91IGFzc3Vt ZSB0aGF0DQo+ICAgICBTRjEgYW5kIFNGMyB3aWxsIGJlIHJlc3BvbnNpYmxlIGZvciBtYWtpbmcg c3VyZSB0aGF0IHNhbWUgZmxvd3MgZ28NCj4gICAgIHRocm91Z2ggdGhlIHNhbWUgc2VydmljZSBm dW5jdGlvbiBpbnN0YW5jZT8NCj4NCj4gICAgIDxrZWc+IEFnYWluLCB0aGUgYWZvcmVtZW50aW9u ZWQgdGV4dCBkZWxpYmVyYXRlbHkgYWxsb3dzIHRoaXMNCj4gICAgIHJlc3BvbnNpYmlsaXR5IHRv IGJlIGVpdGhlciBpbWJlZGRlZCBpbiB0aGUgZWxhc3RpY2l0eS1jYXVzaW5nDQo+ICAgICBmdW5j dGlvbiBvciB0byBiZSBjb250cm9sbGVkIGV4dGVybmFsbHkgb3IgY2VudHJhbGx5LiAgV2UgZG9u J3QgZ2V0DQo+ICAgICBpbnRvIHRoZSBtZWNoYW5pY3MgYXMgdGhlc2UgY2FuIHZhcnkuICBXaGls ZSBzdGF0ZWZ1bC9iaWRpcmVjdGlvbmFsDQo+ICAgICBkb2VzIGFkZCBhbiBhZGRpdGlvbmFsIGJ1 cmRlbiwgaXQgY2FuIGJlIGFjY29tbW9kYXRlZCB3aXRob3V0IGFuDQo+ICAgICBleHBsb3Npb24g b2YgZGlzY3JldGUgY2hhaW5zLiAgRm9yIGV4YW1wbGUsIGl0IGNvdWxkIGJlIGhhbmRsZWQgImF0 DQo+ICAgICBhbGxvY2F0aW9uIHRpbWUiIGlmIGVsYXN0aWNpdHkgaXMgbWFuYWdlZCB2aWEgYSBz ZXBhcmF0ZSBlbnRpdHkgYW5kDQo+ICAgICB0aGUgaW5kaXZpZHVhbCBhbGxvY2F0aW9ucyByZWZs ZWN0ZWQgdGhyb3VnaCBzZXJ2aWNlIGNoYWluIGNvbnRyb2wNCj4gICAgIGluIHRoZSBpbml0aWFs IG1ldGFkYXRhIGJvdW5kIHRvIGF0IHRoZSBjbGFzc2lmaWNhdGlvbiBwb2ludCBpbg0KPiAgICAg ZWl0aGVyIGRpcmVjdGlvbi4gIE9SLCBpZiB0aGUgZGV2aWNlcyBhcmUgd29ya2luZyBhcyBhIHBh aXJlZCBzeXN0ZW0NCj4gICAgIChzaW5nbGUgdmVuZG9yIG9yIGVjb3N5c3RlbSkgd2l0aCBpbnRl Z3JhdGVkIGVsYXN0aWNpdHksIHRoZXkgY291bGQNCj4gICAgIHBhc3MgbWV0YWRhdGEgYmV0d2Vl biB0aGVtIHdoZW4gc2YxIG9yIHNmMyBkb2VzIHRoZSBpbml0aWFsIGR5bmFtaWMNCj4gICAgIGFs bG9jYXRpb24gKGFmZmVjdGluZyBsb2NhbCBmb3J3YXJkaW5nIG9uIGl0J3MgcGFydG5lcikuICBU aGF0J3MNCj4gICAgIHByb2JhYmx5IG5vdCBhbiBleGhhdXN0aXZlIGxpc3Qgb2Ygd2F5cyB0byBz b2x2ZSB0aGUgcHJvYmxlbS4gIDheKQ0KPg0KPiAgICAgPGtlZz4gVGhlIHBvaW50IG9mIHRoaXMg c2VjdGlvbiB3YXMgdGhhdCBlbGFzdGljaXR5IGFuZCBIQSBzaG91bGQNCj4gICAgIG5vdCBjYXVz ZSBhbiBpbm9yZGluYXRlIGV4cGxvc2lvbiBvZiBkaXNjcmV0ZSBjaGFpbnMgd2l0aG91dA0KPiAg ICAgcmVjb21tZW5kaW5nIGEgcGFydGljdWxhciBzb2x1dGlvbi4gIFRoYXQgaXMsICB5b3Ugc2hv dWxkbid0IGNyZWF0ZQ0KPiAgICAgdW5uZWNlc3NhcnkgIGNvbXBsZXhpdHkgd2hlcmUgaXQgZG9l c24ndCBuZWVkIHRvIGV4aXN0Lg0KPg0KPiAgICAgRm9yIHRoZSBzdGF0ZWZ1bCBzZXJ2aWNlIGZ1 bmN0aW9ucywgaWYgYSBmbG93IGlzIHN3aXRjaGVkIGZyb20NCj4gICAgIFNGLUluc3RhbmNlLVgg dG8gU0YtSW5zdGFuY2UtWSwgdGhlIFNGLUluc3RhbmNlLVkgbmVlZHMgdG8NCj4gICAgIHN5bmNo cm9uaXplIHRoZSBzdGF0ZXMgZnJvbSBTRi1JbnN0YW5jZS1YLiBXaG8gaXMgcmVzcG9uc2libGUg Zm9yDQo+ICAgICB0aG9zZSBzdGF0ZXMgbWFpbnRlbmFuY2UgZm9yIHRoZSBMb2FkIEJhbGFuY2lu ZyBkZXNjcmliZWQgaW4gRmlndXJlIDU/DQo+DQo+ICAgICA8a2VnPiBOb25lIG9mIHRob3NlIGVu dGl0aWVzIGV4aXN0IGluIEZpZ3VyZSA1LiAgQ2FuIHlvdSByZS1waHJhc2UNCj4gICAgIHlvdXIg cXVlc3Rpb24gZnJvbSB0aGUgZmlndXJlPw0KPg0KPiAgICAgTGluZGENCj4NCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiAtLQ0KPg0KPiBSZXF1aXJlIHB1c2hpbmcgcG9saWNpZXMgdG8gU0YxIG9uIGhvdyB0 byBsb2FkIGJhbGFuY2UgbXVsdGlwbGUgDQo+IGluc3RhbmNlcyBvZiBTRjIuDQo+DQo+IFNGMSBt YXkgbm90IGhhdmUgdGhlIGNhcGFiaWxpdHkgdG8gYmFsYW5jZSBhbW9uZyBtdWx0aXBsZSBpbnN0 YW5jZXMgb2YNCj4gU0YyDQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWlsaW5nIGxpc3QNCj4gc2ZjQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0K c2ZjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWls aW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMNCg== From nobody Sat May 31 19:01:28 2014 Return-Path: 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 047981A015A for ; Sat, 31 May 2014 19:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 BVenhgEBi9WE for ; Sat, 31 May 2014 19:01:25 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECC591A0140 for ; Sat, 31 May 2014 19:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4947; q=dns/txt; s=iport; t=1401588080; x=1402797680; h=from:to:subject:date:message-id:mime-version; bh=DxPJAlZpbhWIympNGdUKv3KPDOPlbVcGzcUzuFx3j8U=; b=NW10gQ4rElkD33wPD4FpCNRU3wxOwlr+72l7j+5+dew9yyGRSR+lMCZU 7CNW3wG32YZtshWu6GXsMsTSUs5KghnqjYjsVNfk6oy5qN5QR343rgBU2 FsaEqSRtbk9wKVq95JJ4GJP+N9jt6KbHLpDMwXiFx28CWtJc98053g7RV 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIHACKJilOtJA2E/2dsb2JhbABZgkJFUlitHYw5iHuBCBZ0giUBAgQdUR0BCAQNAwECKDkUCQoEARKIQg3VLheOQR6EOgSaAIE+kW+BeIFAgi8 X-IronPort-AV: E=Sophos;i="4.98,948,1392163200"; d="scan'208,217";a="329329655" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-1.cisco.com with ESMTP; 01 Jun 2014 02:01:19 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s5121JrF018906 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 1 Jun 2014 02:01:19 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.72]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Sat, 31 May 2014 21:01:19 -0500 From: "Surendra Kumar (smkumar)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived-flow-use-cases-02 Thread-Index: AQHPfT1g95ya+M4sRn+252esY1l5Cg== Date: Sun, 1 Jun 2014 02:01:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.21.69.18] Content-Type: multipart/alternative; boundary="_000_CFAF771343C41smkumarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/937q24uaJypSn3MsveFb9O92jVU Subject: Re: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived-flow-use-cases-02 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 02:01:27 -0000 --_000_CFAF771343C41smkumarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Support; it is a beneficial function. Surendra. From: "Jim Guichard (jguichar)" > Date: Monday, May 19, 2014 10:27 AM To: "sfc@ietf.org" > Subject: [sfc] Call for WG adoption of draft-krishnan-sfc-long-lived-flow-u= se-cases-02 Greetings WG: This message begins a two week call for WG adoption of draft-krishnan-sfc-l= ong-lived-flow-use-cases-02 [http://datatracker.ietf.org/doc/draft-krishnan= -sfc-long-lived-flow-use-cases/] ending June 2nd 2014. The draft highlights a number of use cases specific to long lived flows and= appears to compliment our already adopted use case documents. Please respo= nd to the SFC mailing list with any statements of approval or disapproval. As always, please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document=92s content until there is WG consensus that = the content is solid. Therefore, please don=92t oppose adoption just becaus= e you want to see changes to its content. 2. If you have objections to adoption of the document, please state your= reasons why, and explain what it would take to address your concerns. 3. If you have issues with the content, by all means raise those issues = and we can begin a dialog about how best to address them. --_000_CFAF771343C41smkumarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0E411A2D33228546BCD4E7527A3B6309@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
    Support; it is a beneficial function.

    Surendra.

    From: "Jim Guichard (jguichar)= " <jguichar@cisco.com>=
    Date: Monday, May 19, 2014 10:27 AM=
    To: "sfc@ietf.org" <sfc@ietf.= org>
    Subject: [sfc] Call for WG adoption= of draft-krishnan-sfc-long-lived-flow-use-cases-02

    Greetings WG:

    This message begins a two week call for WG adoption of draft-krishnan-= sfc-long-lived-flow-use-cases-02 [http://datatracker.ietf.or= g/doc/draft-krishnan-sfc-long-lived-flow-use-cases/] ending June 2nd 2014.

    The draft highlights a number of use cases specific to long lived flow= s and appears to compliment our already adopted use case documents. Please = respond to the SFC mailing list with any statements of approval or disappro= val.

    As always, please note:
    1. This is not WG Last Call. The document is not final, and the = WG is expected to modify the document=92s content until there is WG consens= us that the content is solid. Therefore, please don=92t oppose adoption just because you want to see changes to its= content.
    2. If you have objections to ado= ption of the document, please state your reasons why, and explain what it w= ould take to address your concerns.
    3. If = you have issues with the content, by all means raise those issues and we ca= n begin a dialog about how best to address them. 
    --_000_CFAF771343C41smkumarciscocom_--