From nobody Sun Aug 3 14:18: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 157A61B2796 for ; Sun, 3 Aug 2014 14:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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.001, 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 Q-DvQ2H-MSd1 for ; Sun, 3 Aug 2014 14:18:43 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CAF01B2790 for ; Sun, 3 Aug 2014 14:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7915; q=dns/txt; s=iport; t=1407100723; x=1408310323; h=from:to:subject:date:message-id:references:mime-version; bh=LoAVT+RGR/YIJ+jND8SGVfOeoZWLXYZsBekoEVnLa94=; b=PulqerkRJIH9sJS/lyRKn1Wby/281D1HVW1nS7lxIUOcCx+zHBDdWyqi WhbnJ8ikHfnsWQGNpy5xwc3m6VOUFsIEsMS0xaOBd/rCGJ/pOKryGxVjn bK7vcq8LiyYAkNRgTd7dtISAeh+pC8wY5J61Jht2RfcmbpRie9BU2KqHo k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAC+m3lOtJV2Y/2dsb2JhbABagw1SUwQEyjKBWQELh0oBgQoWd4QDAQEBBHcSAgEZAQIBAigHMhQDBAIIAgQTCRKIJwgFxW0XjzsNCgeCMlMkgRwFjneND4FUkwuDTWwBgUU X-IronPort-AV: E=Sophos; i="5.01,794,1400025600"; d="scan'208,217"; a="66197060" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP; 03 Aug 2014 21:18:42 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s73LIgEh024587 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 3 Aug 2014 21:18:42 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.158]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Sun, 3 Aug 2014 16:18:42 -0500 From: "Carlos Pignataro (cpignata)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-merged-sfc-architecture-01.txt Thread-Index: AQHPr2AigUDp9PUKd0KN/JsZgTmzpw== Date: Sun, 3 Aug 2014 21:18:42 +0000 Message-ID: <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> References: <20140803211558.28482.8328.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.237.170] Content-Type: multipart/alternative; boundary="_000_0EE8F6C7DFB74DF3BD002B93EFF56E78ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/rsixYPw7AGiuOoNp3SLqKeuqMuw Subject: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.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, 03 Aug 2014 21:18:48 -0000 --_000_0EE8F6C7DFB74DF3BD002B93EFF56E78ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable SFCers, After Toronto, Joel and I have been working on resolving the key open discu= ssion items, and incorporating all the input and feedback received thus int= o this document as the vehicle for a single SFC Architecture item to progre= ss. While we are still working on the document, we wanted to get a version out = early to the WG to test the resolution to key open items, see what we might= still be missing, and iterate. Please review and let us know. Thanks, Carlos & Joel. Begin forwarded message: From: > Subject: New Version Notification for draft-merged-sfc-architecture-01.txt Date: August 3, 2014 at 5:15:58 PM EDT To: Joel Halpern >, Carlos = Pignataro >, "Joel M. Halpern= " >, Carlos Pignataro > A new version of I-D, draft-merged-sfc-architecture-01.txt has been successfully submitted by Carlos Pignataro and posted to the IETF repository. Name: draft-merged-sfc-architecture Revision: 01 Title: Service Function Chaining (SFC) Architecture Document date: 2014-08-03 Group: Individual Submission Pages: 25 URL: http://www.ietf.org/internet-drafts/draft-merged-sfc-archit= ecture-01.txt Status: https://datatracker.ietf.org/doc/draft-merged-sfc-architect= ure/ Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-archite= cture-01 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 submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_0EE8F6C7DFB74DF3BD002B93EFF56E78ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <976B5C6447A8634F9B7EC68AFBFC9DBF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable SFCers,

After Toronto, Joel and I have been working on resolving the key open = discussion items, and incorporating all the input and feedback receive= d thus into this document as the vehicle for a single SFC Architecture item= to progress.

While we are still working on the document, we wanted to get a version out = early to the WG to test the resolution to key open items, see what we = might still be missing, and iterate.

Please review and let us know.

Thanks,

Carlos & Joel.

Begin forwarded message:

Subje= ct: New Version Notification= for draft-merged-sfc-architecture-01.txt
Date:= August 3, 2014 at 5:15= :58 PM EDT
To: <= /b>Joel Halpern <jmh@joelhalpern.com>, Carlos Pignata= ro <cpignata@cisco.com>, "Joel M. Halpern" <jmh= @joelhalpern.com>, Carlos Pignataro <cpignata@cisco.com>


A new version of I-D, draft-merged-sfc-architecture-01.txt
has been successfully submitted by Carlos Pignataro and posted to the
IETF repository.

Name: draft-merged-sfc= -architecture
Revision: 0= 1
Title: Service Functio= n Chaining (SFC) Architecture
Document date: 2014-08-03
Group: Individual Subm= ission
Pages: 25
URL:            http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-01.= txt
Status:         https://datatracke= r.ietf.org/doc/draft-merged-sfc-architecture/
Htmlized:       http://tools.ietf.org/html/draft= -merged-sfc-architecture-01
Diff:           ht= tp://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-01

Abstract:
  This document describes an architecture for the specification,<= br>   creation, and ongoing maintenance of Service Function Chains (S= FC) in
  a network.  It includes architectural concepts, principles= , and
  components used in the construction of composite services throu= gh
  deployment of SFCs.  This document does not propose soluti= ons,
  protocols, or extensions to existing protocols.




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

The IETF Secretariat


--_000_0EE8F6C7DFB74DF3BD002B93EFF56E78ciscocom_-- From nobody Mon Aug 4 01:18: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 30DF31B28AE for ; Mon, 4 Aug 2014 01:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 G7kyJ8nOEFTk for ; Mon, 4 Aug 2014 01:18:07 -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 B57771B28B2 for ; Mon, 4 Aug 2014 01:18:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKW01208; Mon, 04 Aug 2014 08:18:04 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 4 Aug 2014 09:18:03 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.204]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Mon, 4 Aug 2014 16:17:55 +0800 From: Xuxiaohu To: "Carlos Pignataro (cpignata)" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.txt Thread-Index: AQHPr2AigUDp9PUKd0KN/JsZgTmzp5vACiPQ Date: Mon, 4 Aug 2014 08:17:55 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A22F1@NKGEML512-MBS.china.huawei.com> References: <20140803211558.28482.8328.idtracker@ietfa.amsl.com> <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> In-Reply-To: <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.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: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A22F1NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/xyXGnFXrUxj00waqGXXwHpQB6Xk Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.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, 04 Aug 2014 08:18:13 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A22F1NKGEML512MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Carlos and Joel, This revision looks much better. Thanks a lot for your excellent work. However, it seems there are still a few places which may need further impro= vements. 1. The following definition of network components looks a bit confused, = IMHO. There is an analogy between the PE and the SFF. For PE, it doesn't s= eparately define the function of performing the VRF lookup/forwarding and t= he function of performing the tunnel encapsulation/decapsulation work. Henc= e it seems better to allow the SFF to be interpreted flexibly as a function= or a device according to the specific context, just like the term of PE. I= n other words, there is no need for introduce the following term of Network= Components. Otherwise, if you prefer to interpret the SFF as a function on= ly, it seems better to give the device containing the SFF (as a function) a= name, which would be useful for solution description. 4.5. Network Components Underneath the SFF, there are components responsible for performing the overlay encapsulation/de-capsulation and forwarding of packets on the overlay network. They may consult the SFC encapsulation or the inner payload of an incoming packet only in the necessary cases to achieve optimal forwarding in the network. 2. The following definition of network service is never used in the whol= e doc. Therefore, why not remove it? Network Service: An offering provided by an operator that is delivered using one or more service functions. This may also be referred to as a composite service. The term "service" is used to denote a "network service" in the context of this document. 3. I think it' better to change the word "and" in the following sentence= to "and/or". In other word, the SFC encapsulation could play the role of S= FP selection, metadata sharing or both. In some cases where the SFP selecti= on role has been accomplished somewhere else (see 4.3.1. Transport Derived= SFF), the only possible role of the SFC encapsulation is metadata-sharing.= In some cases where no metadata is required to be shared, the only possibl= e role of the SFC encapsulation is SFP selection. " The SFC encapsulation enables service function path selection and the sharing of metadata/context information. 4. It seems that SF instance is a well understood term. Unfortunately, i= t has been removed. 5. s/SDC/SFC "Alternatively, a service provider may decide to exclude legacy service functions from an SDC domain. 6. s/SF functions/SFs according to the ordered set of SF functions Best regards, Xiaohu From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpig= nata) Sent: Monday, August 04, 2014 5:19 AM To: sfc@ietf.org Subject: [sfc] Fwd: New Version Notification for draft-merged-sfc-architect= ure-01.txt SFCers, After Toronto, Joel and I have been working on resolving the key open discu= ssion items, and incorporating all the input and feedback received thus int= o this document as the vehicle for a single SFC Architecture item to progre= ss. While we are still working on the document, we wanted to get a version out = early to the WG to test the resolution to key open items, see what we might= still be missing, and iterate. Please review and let us know. Thanks, Carlos & Joel. Begin forwarded message: From: > Subject: New Version Notification for draft-merged-sfc-architecture-01.txt Date: August 3, 2014 at 5:15:58 PM EDT To: Joel Halpern >, Carlos = Pignataro >, "Joel M. Halpern= " >, Carlos Pignataro > A new version of I-D, draft-merged-sfc-architecture-01.txt has been successfully submitted by Carlos Pignataro and posted to the IETF repository. Name: draft-merged-sfc-architecture Revision: 01 Title: Service Function Chaining (SFC) Architecture Document date: 2014-08-03 Group: Individual Submission Pages: 25 URL: http://www.ietf.org/internet-drafts/draft-merged-sfc-archit= ecture-01.txt Status: https://datatracker.ietf.org/doc/draft-merged-sfc-architect= ure/ Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-archite= cture-01 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 submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A22F1NKGEML512MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Carlos = and Joel,

 = ;

This revis= ion looks much better. Thanks a lot for your excellent work.

 = ;

However, i= t seems there are still a few places which may need further improvements.

 = ;

1.    Th= e following definition of network components looks a bit confused, IMHO. Th= ere is an analogy between the PE and the SFF. For PE,  it doesn’t separately define the function of performing the VRF lookup/= forwarding and the function of performing the tunnel encapsulation/decapsul= ation work. Hence it seems better to allow the SFF to be interpreted flexib= ly as a function or a device according to the specific context, just like the term of PE. In other words, there i= s no need for introduce the following term of Network Components. Otherwise= , if you prefer to interpret the SFF as a function only, it seems better to= give the device containing the SFF (as a function) a name, which would be useful for solution description= .

4.5.  Network Components

   Underneath the = SFF, there are components responsible for performing

   the overlay enc= apsulation/de-capsulation and forwarding of packets on

   the overlay net= work.  They may consult the SFC encapsulation or the=

   inner payload o= f an incoming packet only in the necessary cases to

   achieve optimal= forwarding in the network.

 

2.&= nbsp;   The f= ollowing definition of network service is never used in the whole doc. Ther= efore, why not remove it?

=  

   Network Service:  An offering provided by an op=
erator that is
        delivered using one or=
 more service functions.  This may also be
        referred to as a compo=
site service.  The term "service" is used<=
/pre>

        to denote a "netw=
ork service" in the context of this document.


 



3.&=
nbsp;  
I thi=
nk it’ better to change the word “and” in the following s=
entence to “and/or”. In other word, the SFC encapsulation could=
 play the role
 of SFP selection, metadata sharing or both. In some cases where the SFP se=
lection role has been accomplished somewhere else (see
4.3.1.  Transport Derived S=
FF), the only possible role of the SFC encapsulation
 is metadata-sharing. In some cases where no metadata is required to be sha=
red, the only possible role of the SFC encapsulation is SFP selection.=



“  =
 The SFC encapsulation enables service function path selection and the=



   sharing of metadata/context information.<=
/span>


 



4.&=
nbsp;  
It se=
ems that SF instance is a well understood term. Unfortunately, it has been =
removed.


=
 



5.&=
nbsp;  
s/SDC=
/SFC


=
 


“Alternativel=
y, a service provider may decide to exclude legacy


   service functions from an SDC domain.


 



6.&=
nbsp;  
s/SF =
functions/SFs


according to the ordered set of SF functions

 


Best regards,=



Xiaohu


 


 =
;








From: sfc [mailto:sfc-bounces@ietf.org]
On Behalf Of Carlos Pignataro (cpignata)

Sent: Monday, August 04, 2014 5:19 AM

To: sfc@ietf.org

Subject: [sfc] Fwd: New Version Notification for draft-merged-sfc-ar=
chitecture-01.txt






 


=
SFCers,




=
After Toronto, Joel and I have been working on resolving the key open discu=
ssion items, and incorporating all the input and feedback received thu=
s into this document as the vehicle for a single
 SFC Architecture item to progress.



While we are still working on the document, we wanted to get a version out =
early to the WG to test the resolution to key open items, see what we =
might still be missing, and iterate.



Please review and let us know.



Thanks,



Carlos & Joel.






Begin forwarded message:














Subject: New Version Notification fo=
r draft-merged-sfc-architecture-01.txt=







Date:
August 3, 2014 at 5:15:58 PM EDT






To:
Joel Halpern <jmh@joelhalpern.com>, Carlos Pignataro <cpignata@cisco.com>, "Joel M. Halpern" &=
lt;jmh@joelhalpern.com>,
 Carlos Pignataro <cpignata@cisco.=
com>




 




=


A new version of I-D, draft-merged-sfc-architecture-01.txt

has been successfully submitted by Carlos Pignataro and posted to the

IETF repository.



Name: draft-merged-sfc-architecture
Revision: 01

Title: Service Function Chaining (SFC=
) Architecture

Document date: 2014-08-03

Group: Individual Submission

Pages: 25

URL:            http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-01.=
txt

Status:         https://datatracke=
r.ietf.org/doc/draft-merged-sfc-architecture/

Htmlized:       http://tools.ietf.org/html/draft=
-merged-sfc-architecture-01

Diff:           ht=
tp://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-01



Abstract:

  This document describes an architecture for the specification,<=
br>
  creation, and ongoing maintenance of Service Function Chains (S=
FC) in

  a network.  It includes architectural concepts, principles=
, and

  components used in the construction of composite services throu=
gh

  deployment of SFCs.  This document does not propose soluti=
ons,

  protocols, or extensions to existing protocols.









Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at 
tools.ietf.org.



The IETF Secretariat






 
--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A22F1NKGEML512MBSchi_-- From nobody Mon Aug 4 07:39:38 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 40E3A1B2B2A for ; Mon, 4 Aug 2014 07:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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.001, 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 zEtp-XUZsY8h for ; Mon, 4 Aug 2014 07:39:33 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DFA51B2B28 for ; Mon, 4 Aug 2014 07:39:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35265; q=dns/txt; s=iport; t=1407163172; x=1408372772; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zXHsYZRsuZ5ZZeOP0p8enqugLHaFHQb30vSVs7aoEXE=; b=IGmv/GxgzcNp0zhJ5YKXvuyREfnPGfG7B/ifMIjL5bNh9GTrTM9xOjHL vEH3ALmq6qvMLQ4TDFSSXXUhyyDopcoJp4/7L/XsviV3SUVI1ZiyYSGt4 YLSU4dv4P5MqMQkN3l/kJAGaP8QLr8bHNvWTR+KB1o+3VHL4YdH+XoQN1 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgFAPGZ31OtJV2U/2dsb2JhbABagkdGUlMEBMpIgWWHSAGBDhZ3hAMBAQEEdwIQAgEIEQECAQEBIQEGBzIUAwYIAgQOBQkSiCcIBcUUF4l/hTwNBAYBBgODJoEcBYY5iD6ND4FUkwuDTWwBAYFE X-IronPort-AV: E=Sophos; i="5.01,798,1400025600"; d="scan'208,217"; a="66369836" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP; 04 Aug 2014 14:39:30 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s74EdUKf031578 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Aug 2014 14:39:30 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.158]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Mon, 4 Aug 2014 09:39:30 -0500 From: "Carlos Pignataro (cpignata)" To: Xiaohu Xu Thread-Topic: [sfc] New Version Notification for draft-merged-sfc-architecture-01.txt Thread-Index: AQHPr/HlWikE3Bm3vE2EAvyRSxIDmw== Date: Mon, 4 Aug 2014 14:39:29 +0000 Message-ID: <9333AEE2-0FB7-4985-B4BC-BC0A22902DE0@cisco.com> References: <20140803211558.28482.8328.idtracker@ietfa.amsl.com> <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A22F1@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A22F1@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.156.219] Content-Type: multipart/alternative; boundary="_000_9333AEE20FB74985B4BCBC0A22902DE0ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/2JOsi7aQk0Pvm5zy19HFeeGqkv8 Cc: "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-merged-sfc-architecture-01.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, 04 Aug 2014 14:39:36 -0000 --_000_9333AEE20FB74985B4BCBC0A22902DE0ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Xiaohu, On Aug 4, 2014, at 4:17 AM, Xuxiaohu > wrote: Hi Carlos and Joel, This revision looks much better. Thanks a lot for your excellent work. Many thanks! However, it seems there are still a few places which may need further impro= vements. 1. The following definition of network components looks a bit confused, = IMHO. There is an analogy between the PE and the SFF. For PE, it doesn=92t= separately define the function of performing the VRF lookup/forwarding and= the function of performing the tunnel encapsulation/decapsulation work. He= nce it seems better to allow the SFF to be interpreted flexibly as a functi= on or a device according to the specific context, just like the term of PE.= In other words, there is no need for introduce the following term of Netwo= rk Components. Otherwise, if you prefer to interpret the SFF as a function = only, it seems better to give the device containing the SFF (as a function)= a name, which would be useful for solution description. 4.5. Network Components Underneath the SFF, there are components responsible for performing the overlay encapsulation/de-capsulation and forwarding of packets on the overlay network. They may consult the SFC encapsulation or the inner payload of an incoming packet only in the necessary cases to achieve optimal forwarding in the network. I am not sure I understand this point. As you can see from Figure 3, the SF= F interfaces down with the network overlay. That's what this paragraph is d= escribing. Maybe we should rename it to "Network Overlay and Network Components"? 2. The following definition of network service is never used in the whol= e doc. Therefore, why not remove it? Network Service: An offering provided by an operator that is delivered using one or more service functions. This may also be referred to as a composite service. The term "service" is used to denote a "network service" in the context of this document. We purposely are describing terms not used in this specific document, but t= hat can be used in other documents, and that are necessary to understand SF= C even when not used. You will remember that the WG (or pre-WG) had long di= scussions during chartering on what was a services and a network service. W= e do not want to lose the output of that. 3. I think it=92 better to change the word =93and=94 in the following se= ntence to =93and/or=94. In other word, the SFC encapsulation could play the= role of SFP selection, metadata sharing or both. In some cases where the S= FP selection role has been accomplished somewhere else (see 4.3.1. Transpo= rt Derived SFF), the only possible role of the SFC encapsulation is metadat= a-sharing. In some cases where no metadata is required to be shared, the on= ly possible role of the SFC encapsulation is SFP selection. =93 The SFC encapsulation enables service function path selection and the sharing of metadata/context information. OK. I think this makes sense, but let me think it through a bit more. Thank= s. 4. It seems that SF instance is a well understood term. Unfortunately, i= t has been removed. We scrubbed through "instance", and right now the doc only says things like= "for instance, ", and not "SF instance. 5. s/SDC/SFC =93Alternatively, a service provider may decide to exclude legacy service functions from an SDC domain. Ack. Thanks! Done. 6. s/SF functions/SFs according to the ordered set of SF functions Many thanks again! Carlos. Best regards, Xiaohu From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpig= nata) Sent: Monday, August 04, 2014 5:19 AM To: sfc@ietf.org Subject: [sfc] Fwd: New Version Notification for draft-merged-sfc-architect= ure-01.txt SFCers, After Toronto, Joel and I have been working on resolving the key open discu= ssion items, and incorporating all the input and feedback received thus int= o this document as the vehicle for a single SFC Architecture item to progre= ss. While we are still working on the document, we wanted to get a version out = early to the WG to test the resolution to key open items, see what we might= still be missing, and iterate. Please review and let us know. Thanks, Carlos & Joel. Begin forwarded message: From: > Subject: New Version Notification for draft-merged-sfc-architecture-01.txt Date: August 3, 2014 at 5:15:58 PM EDT To: Joel Halpern >, Carlos = Pignataro >, "Joel M. Halpern= " >, Carlos Pignataro > A new version of I-D, draft-merged-sfc-architecture-01.txt has been successfully submitted by Carlos Pignataro and posted to the IETF repository. Name: draft-merged-sfc-architecture Revision: 01 Title: Service Function Chaining (SFC) Architecture Document date: 2014-08-03 Group: Individual Submission Pages: 25 URL: http://www.ietf.org/internet-drafts/draft-merged-sfc-archit= ecture-01.txt Status: https://datatracker.ietf.org/doc/draft-merged-sfc-architect= ure/ Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-archite= cture-01 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 submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_9333AEE20FB74985B4BCBC0A22902DE0ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8939706ED15AC247861D038064DDC772@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hi Xiaohu,

On Aug 4, 2014, at 4:17 AM, Xuxiaohu <xuxiaohu@huawei.com> wrote:

Hi Carlos and Joel,
 
This revision looks much better. Thanks a l= ot for your excellent work.
 

Many thanks!

However, it seems there are still a few pla= ces which may need further improvements.
 
1.    The following definition of network components looks a bit confused, IMHO. The= re is an analogy between the PE and the SFF. For PE,  it doesn=92t sep= arately define the function of performing the VRF lookup/forwarding and the= function of performing the tunnel encapsulation/decapsulation work. Hence it seems better to allow the SFF to be interpreted flexibly as= a function or a device according to the specific context, just like the te= rm of PE. In other words, there is no need for introduce the following term= of Network Components. Otherwise, if you prefer to interpret the SFF as a function only, it seems better to = give the device containing the SFF (as a function) a name, which would be u= seful for solution description.
4.5.  Network Components
 &nb= sp; Underneath the SFF, there are components responsible for performing
 &nb= sp; the overlay encapsulation/de-capsulation and forwarding of packets on
 &nb= sp; the overlay network.  They may consult the SFC encapsulation or th= e
 &nb= sp; inner payload of an incoming packet only in the necessary cases to=
 &nb= sp; achieve optimal forwarding in the network.
 

I am not sure I understand this point. As you can see from Figure 3, t= he SFF interfaces down with the network overlay. That's what this paragraph= is describing. 

Maybe we should rename it to "Network Overlay and Network Compone= nts"?

2.    The following definition of network service is never used in the whole doc. Th= erefore, why not remove it?
 
   Network Service:  An offering provided by an operator th=
at is
        delivered using one or more ser=
vice functions.  This may also be
        referred to as a composite serv=
ice.  The term "service" is used
        to denote a "network servi=
ce" in the context of this document.
 

We purposely are describing terms not used in this specific document, = but that can be used in other documents, and that are necessary to understa= nd SFC even when not used. You will remember that the WG (or pre-WG) had lo= ng discussions during chartering on what was a services and a network service. We do not want to lose the o= utput of that.

3.    I think it=92 better to change the word =93and=94 in the following sentence = to =93and/or=94. In other word, the SFC encapsulation could play the role o= f SFP selection, metadata sharing or both. In some cases where the SFP sele= ction role has been accomplished somewhere else (see 4.3.1.  Transport Derived SFF), the only possible role of the SFC encapsulation is= metadata-sharing. In some cases where no metadata is required to be shared= , the only possible role of the SFC encapsulation is SFP selection.
=93   The SFC encapsulation =
enables service function path selection and the
   sharing of metadata/context information.

 

OK. I think this makes sense, but let me think it through a bit more. = Thanks.

4.    It seems that SF instance is a well understood term. Unfortunately, it has be= en removed.
 

We scrubbed through "instance", and right now the doc only s= ays things like "for instance, ", and not "SF instance.
5.    s/SDC/SFC
 
=93Alternatively, a service provider m=
ay decide to exclude legacy
   service functions from an SDC domain.
 

Ack. Thanks! Done.

6.    s/SF functions/SFs
according to the ordered set of SF functions
 


Many thanks again!

Carlos.

Best regards,
Xiaohu
 
 
From: = sfc [mailto:sfc-bounces@ietf= .org] On Behalf Of Carlos Pig= nataro (cpignata)
Sent: Monday, Augu= st 04, 2014 5:19 AM
To: sfc@ietf.org
Subject: [sfc] Fwd= : New Version Notification for draft-merged-sfc-architecture-01.txt
 

SFCers,

After Toronto, Joel and I have been working on resolvi= ng the key open discussion items, and incorporating all the input and feedb= ack received thus into this document as the vehicle for a single SFC A= rchitecture item to progress.

While we are still working on the document, we wanted to get a version out = early to the WG to test the resolution to key open items, see what we = might still be missing, and iterate.

Please review and let us know.

Thanks,

Carlos & Joel.

Begin forwarded message:


Subje= ct: New Version Notification for draft-merged-sfc-architecture-01.txt
Date:=  August 3, 2014 at 5:1= 5:58 PM EDT
To: Joel Halpern <jmh@joelhalpern.com>, Carlos Pignataro <cpignata@cisco.com>, "Joe= l M. Halpern" <jmh@joelhalpern.com>, Carlos Pignataro <cpignata@cisco.com>
 


A new version of I-D, draft-merged-sfc-architecture-01.txt
has been successfully submitted by Carlos Pignataro and posted to the
IETF repository.

Name:&= nbsp;draft-merged-sfc-architecture
Revision: 01
Title:=  Service Function Chaining (SFC) Architecture
Document date: 2014-08-03
Group:=  Individual Submission
Pages:=  25
URL:            http://www.ietf.= org/internet-drafts/draft-merged-sfc-architecture-01.txt
Status:         https://datatracker.ietf.org/doc/draft-m= erged-sfc-architecture/
Htmlized:       http://tools.ietf.org/html/draft-merged-sfc-architectu= re-01
Diff:           http://www.ietf.org/rfcd= iff?url2=3Ddraft-merged-sfc-architecture-01

Abstract:
  This document describes an architecture for the specification,<= br>   creation, and ongoing maintenance of Service Function Chains (S= FC) in
  a network.  It includes architectural concepts, principles= , and
  components used in the construction of composite services throu= gh
  deployment of SFCs.  This document does not propose soluti= ons,
  protocols, or extensions to existing protocols.




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

The IETF Secretariat


--_000_9333AEE20FB74985B4BCBC0A22902DE0ciscocom_-- From nobody Mon Aug 4 08:12: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 ACC3A1B2B4D for ; Mon, 4 Aug 2014 08:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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.001, 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 n8WXukEdfyki for ; Mon, 4 Aug 2014 08:12:15 -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 A5F931B2B48 for ; Mon, 4 Aug 2014 08:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31722; q=dns/txt; s=iport; t=1407165135; x=1408374735; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Nlp92/eed4y/zBlNBJnFGtSecQ/B1tetknayJBWxPCs=; b=D3kRKwvLcZ03/GRW0oX+8wugLhzpLRklurULiWl8VPDvSpUCW+jBPVXV 8XvLn9TX8w31O2WgqPJGE7sIYn63hIMzskffDSkgrYvf79BOQ5lw/nu81 BjxfgybeH20HSnSMYbTDVHSTfVumvoSMDMNL26psI+qryaRcDTdsUSNO+ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgFAKWh31OtJA2D/2dsb2JhbABQCoJHRlJTBATKSIFlh0gBgQ8Wd4QDAQEBBHcCEAIBCBEBAgEBASEBBgcyFAMGCAIEDgUJEognCAXFKxeJf4RxSw0EBgEGA4MmgRwFhjmIPo0PgVSTC4IHgUZsAQGBRA X-IronPort-AV: E=Sophos;i="5.01,799,1400025600"; d="scan'208,217";a="345033687" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-4.cisco.com with ESMTP; 04 Aug 2014 15:12:14 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s74FCE6j012213 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Aug 2014 15:12:14 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.158]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Mon, 4 Aug 2014 10:12:14 -0500 From: "Carlos Pignataro (cpignata)" To: Xiaohu Xu Thread-Topic: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.txt Thread-Index: AQHPr7yg+SFvPeZEkUK0i3h2E8Km45vA4UwA Date: Mon, 4 Aug 2014 15:12:14 +0000 Message-ID: References: <20140803211558.28482.8328.idtracker@ietfa.amsl.com> <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A22F1@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A22F1@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.156.219] Content-Type: multipart/alternative; boundary="_000_E0792C41E0A440DA8E20A285CAF05623ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/8YI1yigQCQLF41OuW7z9K22hokY Cc: "sfc@ietf.org" Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.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, 04 Aug 2014 15:12:22 -0000 --_000_E0792C41E0A440DA8E20A285CAF05623ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Xiaohu, Please find an additional follow-up inline. On Aug 4, 2014, at 4:17 AM, Xuxiaohu > wrote: Hi Carlos and Joel, This revision looks much better. Thanks a lot for your excellent work. However, it seems there are still a few places which may need further impro= vements. 1. The following definition of network components looks a bit confused, = IMHO. There is an analogy between the PE and the SFF. For PE, it doesn=92t= separately define the function of performing the VRF lookup/forwarding and= the function of performing the tunnel encapsulation/decapsulation work. He= nce it seems better to allow the SFF to be interpreted flexibly as a functi= on or a device according to the specific context, just like the term of PE.= In other words, there is no need for introduce the following term of Netwo= rk Components. Otherwise, if you prefer to interpret the SFF as a function = only, it seems better to give the device containing the SFF (as a function)= a name, which would be useful for solution description. 4.5. Network Components Underneath the SFF, there are components responsible for performing the overlay encapsulation/de-capsulation and forwarding of packets on the overlay network. They may consult the SFC encapsulation or the inner payload of an incoming packet only in the necessary cases to achieve optimal forwarding in the network. 2. The following definition of network service is never used in the whol= e doc. Therefore, why not remove it? Network Service: An offering provided by an operator that is delivered using one or more service functions. This may also be referred to as a composite service. The term "service" is used to denote a "network service" in the context of this document. 3. I think it=92 better to change the word =93and=94 in the following se= ntence to =93and/or=94. In other word, the SFC encapsulation could play the= role of SFP selection, metadata sharing or both. In some cases where the S= FP selection role has been accomplished somewhere else (see 4.3.1. Transpo= rt Derived SFF), the only possible role of the SFC encapsulation is metadat= a-sharing. In some cases where no metadata is required to be shared, the on= ly possible role of the SFC encapsulation is SFP selection. =93 The SFC encapsulation enables service function path selection and the sharing of metadata/context information. Sorry I misunderstood where you were asking for the "and/or" to be inserted= on this comment. Section 4.1 clearly says: The SFC encapsulation provides explicit information used to identify the SFP. And that's, to me, the key issue we want to preserve on the SFC Encapsulati= on. If there is potential ambiguity in that first sentence, I'd suggest braking= it up in two: The SFC encapsulation enables service function path selection. It also e= nables the potential sharing of metadata and/or context information. Thanks, Carlos. 4. It seems that SF instance is a well understood term. Unfortunately, i= t has been removed. 5. s/SDC/SFC =93Alternatively, a service provider may decide to exclude legacy service functions from an SDC domain. 6. s/SF functions/SFs according to the ordered set of SF functions Best regards, Xiaohu From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpig= nata) Sent: Monday, August 04, 2014 5:19 AM To: sfc@ietf.org Subject: [sfc] Fwd: New Version Notification for draft-merged-sfc-architect= ure-01.txt SFCers, After Toronto, Joel and I have been working on resolving the key open discu= ssion items, and incorporating all the input and feedback received thus int= o this document as the vehicle for a single SFC Architecture item to progre= ss. While we are still working on the document, we wanted to get a version out = early to the WG to test the resolution to key open items, see what we might= still be missing, and iterate. Please review and let us know. Thanks, Carlos & Joel. Begin forwarded message: From: > Subject: New Version Notification for draft-merged-sfc-architecture-01.txt Date: August 3, 2014 at 5:15:58 PM EDT To: Joel Halpern >, Carlos = Pignataro >, "Joel M. Halpern= " >, Carlos Pignataro > A new version of I-D, draft-merged-sfc-architecture-01.txt has been successfully submitted by Carlos Pignataro and posted to the IETF repository. Name: draft-merged-sfc-architecture Revision: 01 Title: Service Function Chaining (SFC) Architecture Document date: 2014-08-03 Group: Individual Submission Pages: 25 URL: http://www.ietf.org/internet-drafts/draft-merged-sfc-archit= ecture-01.txt Status: https://datatracker.ietf.org/doc/draft-merged-sfc-architect= ure/ Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-archite= cture-01 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 submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_E0792C41E0A440DA8E20A285CAF05623ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <78E00E8341FEFE4A875CD956A639333D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Xiaohu,

Please find an additional follow-up inline.

On Aug 4, 2014, at 4:17 AM, Xuxiaohu <xuxiaohu@huawei.com> wrote:

Hi Carlos and Joel,
 
This revision looks much better. Thanks a l= ot for your excellent work.
 
However, it seems there are still a few pla= ces which may need further improvements.
 
1.    The following definition of network components looks a bit confused, IMHO. The= re is an analogy between the PE and the SFF. For PE,  it doesn=92t sep= arately define the function of performing the VRF lookup/forwarding and the= function of performing the tunnel encapsulation/decapsulation work. Hence it seems better to allow the SFF to be interpreted flexibly as= a function or a device according to the specific context, just like the te= rm of PE. In other words, there is no need for introduce the following term= of Network Components. Otherwise, if you prefer to interpret the SFF as a function only, it seems better to = give the device containing the SFF (as a function) a name, which would be u= seful for solution description.
4.5.  Network Components
 &nb= sp; Underneath the SFF, there are components responsible for performing
 &nb= sp; the overlay encapsulation/de-capsulation and forwarding of packets on
 &nb= sp; the overlay network.  They may consult the SFC encapsulation or th= e
 &nb= sp; inner payload of an incoming packet only in the necessary cases to=
 &nb= sp; achieve optimal forwarding in the network.
 
2.    The following definition of network service is never used in the whole doc. Th= erefore, why not remove it?
 
   Network Service:  An offering provided by an operator th=
at is
        delivered using one or more ser=
vice functions.  This may also be
        referred to as a composite serv=
ice.  The term "service" is used
        to denote a "network servi=
ce" in the context of this document.
 
3.    I think it=92 better to change the word =93and=94 in the following sentence = to =93and/or=94. In other word, the SFC encapsulation could play the role o= f SFP selection, metadata sharing or both. In some cases where the SFP sele= ction role has been accomplished somewhere else (see 4.3.1.  Transport Derived SFF), the only possible role of the SFC encapsulation is= metadata-sharing. In some cases where no metadata is required to be shared= , the only possible role of the SFC encapsulation is SFP selection.
=93   The SFC encapsulation =
enables service function path selection and the
   sharing of metadata/context information.

 

Sorry I misunderstood where you were asking for the "and/or"= to be inserted on this comment. 

Section 4.1 clearly says:
   The SFC encapsulation provides explicit information used = to identify
   the SFP.

And that's, to me, the key issue we want to preserve on the SFC Encaps= ulation.

If there is potential ambiguity in that first sentence, I'd suggest br= aking it up in two:

   The SFC encapsulation enables service function path selec= tion. It also enables the
   potential sharing of metadata and/or context information.=

Thanks,

Carlos.


4.    It seems that SF instance is a well understood term. Unfortunately, it has be= en removed.
 
5.    s/SDC/SFC
 
=93Alternatively, a service provider m=
ay decide to exclude legacy
   service functions from an SDC domain.
 
6.    s/SF functions/SFs
according to the ordered set of SF functions
 


Best regards,



Xiaohu



 



 









From: =
sfc [mailto:sfc-bounces@ietf=
.org] On
 Behalf Of Carlos Pig=
nataro (cpignata)

Sent: Monday, Augu=
st 04, 2014 5:19 AM

To: sfc@ietf.org

Subject: [sfc] Fwd=
: New Version Notification for draft-merged-sfc-architecture-01.txt







 



SFCers,





After Toronto, Joel and I have been working on resolvi=
ng the key open discussion items, and incorporating all the input and feedb=
ack received thus into this document as the vehicle for a single SFC A=
rchitecture item to progress.



While we are still working on the document, we wanted to get a version out =
early to the WG to test the resolution to key open items, see what we =
might still be missing, and iterate.



Please review and let us know.



Thanks,



Carlos & Joel.







Begin forwarded message:
















Subje=
ct: New Version Notification for draft-merged-sfc-architecture-01.txt







Date:=
 August 3, 2014 at 5:1=
5:58 PM EDT







To: Joel Halpern <jmh@joelhalpern.com>,
 Carlos Pignataro <cpignata@cisco.com>, "Joe=
l M. Halpern" <jmh@joelhalpern.com>,
 Carlos Pignataro <cpignata@cisco.com>





 







A new version of I-D, draft-merged-sfc-architecture-01.txt

has been successfully submitted by Carlos Pignataro and posted to the

IETF repository.



Name:&=
nbsp;draft-merged-sfc-architecture

Revision: 01

Title:=
 Service Function Chaining (SFC) Architecture

Document date: 2014-08-03

Group:=
 Individual Submission

Pages:=
 25

URL:            http://www.ietf.=
org/internet-drafts/draft-merged-sfc-architecture-01.txt

Status:         https://datatracker.ietf.org/doc/draft-m=
erged-sfc-architecture/

Htmlized:       http://tools.ietf.org/html/draft-merged-sfc-architectu=
re-01

Diff:           http://www.ietf.org/rfcd=
iff?url2=3Ddraft-merged-sfc-architecture-01



Abstract:

  This document describes an architecture for the specification,<=
br>
  creation, and ongoing maintenance of Service Function Chains (S=
FC) in

  a network.  It includes architectural concepts, principles=
, and

  components used in the construction of composite services throu=
gh

  deployment of SFCs.  This document does not propose soluti=
ons,

  protocols, or extensions to existing protocols.









Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



The IETF Secretariat

--_000_E0792C41E0A440DA8E20A285CAF05623ciscocom_-- From nobody Mon Aug 4 10:01: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 1B6AE1A0026 for ; Mon, 4 Aug 2014 10:01:13 -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 Fn8vb9JRgQ4F for ; Mon, 4 Aug 2014 10:01:09 -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 EFDC81A0019 for ; Mon, 4 Aug 2014 10:01:08 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-6c-53df68b988c9 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id C9.C2.05330.9B86FD35; Mon, 4 Aug 2014 13:04:25 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Mon, 4 Aug 2014 13:01:03 -0400 From: Dave Hood To: "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] New Version Notification for draft-merged-sfc-architecture-01.txt Thread-Index: AQHPr/HuIkPPwIIWgEizn+n+npHOuJvAnvog Date: Mon, 4 Aug 2014 17:01:03 +0000 Message-ID: <8D15A2BAF93E9C49AB037A0647E5FA643F47A019@eusaamb105.ericsson.se> References: <20140803211558.28482.8328.idtracker@ietfa.amsl.com> <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A22F1@NKGEML512-MBS.china.huawei.com> <9333AEE2-0FB7-4985-B4BC-BC0A22902DE0@cisco.com> In-Reply-To: <9333AEE2-0FB7-4985-B4BC-BC0A22902DE0@cisco.com> 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_8D15A2BAF93E9C49AB037A0647E5FA643F47A019eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyuXRPoO7OjPvBBsumqlh8ereDxeLJg63s DkweU35vZPVYsuQnUwBTFJdNSmpOZllqkb5dAlfGleV7mAvuLGSsuD57LmMD4+Q+xi5GTg4J AROJDd3H2SFsMYkL99azdTFycQgJHGWU+Lh5CjNIQkhgGaNE45FiEJtNQEPiyaXJTCC2iICZ ROPjSWA2s4CixKNbv8FsYYEwiTmvvjBC1IRL7D45Bco2kuh5NA9sGYuAisSOWY9Yuxg5OHgF fCVmbk6B2PuJUWLF3gNgNZwCthITDm8FsxmBjvt+ag3ULnGJW0/mM0EcLSCxZM95ZghbVOLl 43+sELaSxJzX15gh6vMllm2ZxAZi8woISpyc+YRlAqPoLCSjZiEpm4WkDCKuI7Fg9yc2CFtb YtnC18ww9pkDj5mQxRcwsq9i5CgtTi3LTTcy2MQIjKxjEmy6Oxj3vLQ8xCjAwajEw6vw8l6w EGtiWXFl7iFGaQ4WJXHeWbXzgoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwVhbLXPe9eanD Umbm84eLDqyTDs52zbmldXaZX9sh9elumz+ZV6o2aFx9k5ty5qeLnvjTgD1t9due/N3Jf7jl bM7Gh1XJTbP/8EpsffRm4UeRD30ba8xXMzB0GbzQvvhC9dcToxX3Gozms32ImRimq/9jccQq rb5Vhz/JrPJ4JxjJ4xUVlL9+jhJLcUaioRZzUXEiAIo/1lONAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/KcV1qCZBqCGoprDpZ4qLMiwJ240 Cc: "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-merged-sfc-architecture-01.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, 04 Aug 2014 17:01:13 -0000 --_000_8D15A2BAF93E9C49AB037A0647E5FA643F47A019eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This document would be greatly improved by everywhere distinguishing class = from instance, for example in the use of the acronyms SF, SFF, SFP. This di= stinction would permit some of the text to be removed or simplified. One case where the instance terminology needs to be particularly clear is t= he discussion of symmetric traffic, in which the SF *instances* need to be = the same, not just the SF *classes.* In the hybrid case, for example, the o= rder may not be as important as assuring that particular instances be trave= rsed in the return path. Likewise, if we don't care which instances are use= d, it's pretty much irrelevant whether return traffic happens to traverse t= he reversed sequence of SF classes as the forward direction. And if a flow = needs to traverse the same SF twice, it matters whether it needs to be the = same SF instance, or merely the same class. A bit of taxonomy would help to clarify the terms: that an SFC [instance] r= epresents a policy about which SF [classes] are applied to a flow, that an = SFP [instance] represents an SFC constrained by some level of implementatio= n considerations, as described in 2.3. The SFC is then nailed down by the r= endered service path. We also confuse network levels. An SFC domain is defined to be a network, b= ut SFC encap is said not to be used for [infrastructure-level] network forw= arding. Among other instances, see eg 4.3 item 1 "arrives ... from the netw= ork". >From this perspective, the principle that the [SFC overlay] network is topo= logically independent from the [infrastructure-level] network is understand= able, but needs to be refined: the overlay cannot do anything that is impos= sible in the underlay network. Perhaps 4.1 states the principle better: the= SFC overlay network is independent of the underlying transport infrastruct= ure (and if this is a key architectural principle, surely it belongs in cla= use 3; but see 4.3.1). An SFC proxy is said to be a logical element. But all SFs are logical eleme= nts, are they not? The distinction needs to be more carefully drawn (or aba= ndoned). A proxy is itself an SF, in composition with the non-SFC capable S= F. Lots more nits, but these are the main points I notice as I read through th= is. Dave From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpig= nata) Sent: Monday, August 04, 2014 5:19 AM To: sfc@ietf.org Subject: [sfc] Fwd: New Version Notification for draft-merged-sfc-architect= ure-01.txt SFCers, After Toronto, Joel and I have been working on resolving the key open discu= ssion items, and incorporating all the input and feedback received thus int= o this document as the vehicle for a single SFC Architecture item to progre= ss. While we are still working on the document, we wanted to get a version out = early to the WG to test the resolution to key open items, see what we might= still be missing, and iterate. Please review and let us know. Thanks, Carlos & Joel. Begin forwarded message: From: > Subject: New Version Notification for draft-merged-sfc-architecture-01.txt Date: August 3, 2014 at 5:15:58 PM EDT To: Joel Halpern >, Carlos = Pignataro >, "Joel M. Halpern= " >, Carlos Pignataro > A new version of I-D, draft-merged-sfc-architecture-01.txt has been successfully submitted by Carlos Pignataro and posted to the IETF repository. Name: draft-merged-sfc-architecture Revision: 01 Title: Service Function Chaining (SFC) Architecture Document date: 2014-08-03 Group: Individual Submission Pages: 25 URL: http://www.ietf.org/internet-drafts/draft-merged-sfc-archit= ecture-01.txt Status: https://datatracker.ietf.org/doc/draft-merged-sfc-architect= ure/ Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-archite= cture-01 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 submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_8D15A2BAF93E9C49AB037A0647E5FA643F47A019eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This document would = be greatly improved by everywhere distinguishing class from instance, for e= xample in the use of the acronyms SF, SFF, SFP. This distinction would permit some of the text to be removed or simplified.

 

One case where the i= nstance terminology needs to be particularly clear is the discussion of sym= metric traffic, in which the SF *instances* need to be the same, not just the SF *classes.* In the hybrid case, for = example, the order may not be as important as assuring that particular inst= ances be traversed in the return path. Likewise, if we don’t care whi= ch instances are used, it’s pretty much irrelevant whether return traffic happens to traverse the reversed sequenc= e of SF classes as the forward direction. And if a flow needs to traverse t= he same SF twice, it matters whether it needs to be the same SF instance, o= r merely the same class.

 

A bit of taxonomy wo= uld help to clarify the terms: that an SFC [instance] represents a policy a= bout which SF [classes] are applied to a flow, that an SFP [instance] represents an SFC constrained by some level of implementation c= onsiderations, as described in 2.3. The SFC is then nailed down by the rend= ered service path.

 

We also confuse netw= ork levels. An SFC domain is defined to be a network, but SFC encap is said= not to be used for [infrastructure-level] network forwarding. Among other instances, see eg 4.3 item 1 “arrives … from the n= etwork”.

 

From this perspectiv= e, the principle that the [SFC overlay] network is topologically independen= t from the [infrastructure-level] network is understandable, but needs to be refined: the overlay cannot do anything that is impossible= in the underlay network. Perhaps 4.1 states the principle better: the SFC = overlay network is independent of the underlying transport infrastructure (= and if this is a key architectural principle, surely it belongs in clause 3; but see 4.3.1).

 

An SFC proxy is said= to be a logical element. But all SFs are logical elements, are they not? T= he distinction needs to be more carefully drawn (or abandoned). A proxy is itself an SF, in composition with the non-SFC capable SF.<= /o:p>

 

Lots more nits, but = these are the main points I notice as I read through this.

 

Dave

From: sfc [mailto:sfc-bounces@ietf.org]<= span class=3D"apple-converted-space"> On Behalf Of Carlos Pignataro (cpignata) Sent: Monday, Augu= st 04, 2014 5:19 AM
To: sfc@ietf.org
Subject: [sfc] Fwd= : New Version Notification for draft-merged-sfc-architecture-01.txt<= span style=3D"mso-fareast-language:ZH-CN">

 

SFCers,

After Toronto, Joel and I have been working on resolv= ing the key open discussion items, and incorporating all the input and feed= back received thus into this document as the vehicle for a single SFC Architecture item to progress.

While we are still working on the document, we wanted to get a version out = early to the WG to test the resolution to key open items, see what we = might still be missing, and iterate.

Please review and let us know.

Thanks,

Carlos & Joel.

Begin for= warded message:




Subject: New Version Not= ification for draft-merged-sfc-architecture-01.txt

Date: August = 3, 2014 at 5:15:58 PM EDT

To: Joel Halp= ern <jmh@joelhalpern.com>, Carlos Pignataro <cpignata@cisco.com>, "Joel M. Halpern"= ; <j= mh@joelhalpern.com>, Carlos Pignataro <cpignata@cisco.com><= /p>

 


A new version of I-D, draft-merged-sfc-architecture-01.txt
has been successfully submitted by Carlos Pignataro and posted to the
IETF repository.

Name: draft-merged-sfc-ar= chitecture
Revision: 01
Title: Service Function C= haining (SFC) Architecture
Document date: 2014-08-03=
Group: Individual Submiss= ion
Pages: 25
URL:            http://www.ietf.org/internet-drafts/draf= t-merged-sfc-architecture-01.txt
Status:         https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/<= /span>
Htmlized:       htt= p://tools.ietf.org/html/draft-merged-sfc-architecture-01
Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-= sfc-architecture-01

Abstract:
  This document describes an architecture for the specification,<= br>   creation, and ongoing maintenance of Service Function Chains (S= FC) in
  a network.  It includes architectural concepts, principles= , and
  components used in the construction of composite services throu= gh
  deployment of SFCs.  This document does not propose soluti= ons,
  protocols, or extensions to existing protocols.




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

The IETF Secretariat

 

--_000_8D15A2BAF93E9C49AB037A0647E5FA643F47A019eusaamb105erics_-- From nobody Mon Aug 4 11:16: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 7D91C1A00E6; Mon, 4 Aug 2014 11:16:52 -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 f4aiX97rT8LR; Mon, 4 Aug 2014 11:16:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB801A005C; Mon, 4 Aug 2014 11:16:51 -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.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140804181651.7054.95913.idtracker@ietfa.amsl.com> Date: Mon, 04 Aug 2014 11:16:51 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Md2raUfVtyQ0wGxHbkA3QaBZ3y4 Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-08.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: Mon, 04 Aug 2014 18:16:52 -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 Problem Statement Authors : Paul Quinn Thomas Nadeau Filename : draft-ietf-sfc-problem-statement-08.txt Pages : 19 Date : 2014-08-04 Abstract: This document provides an overview of the issues associated with the deployment of service functions (such as firewalls, load balancers) in large-scale environments. The term service function chaining is used to describe the definition and instantiation of an ordered set of instances of such service functions, and the subsequent "steering" of traffic flows through those service functions. The set of enabled service function chains reflect operator service offerings and is designed in conjunction with application delivery and service and network policy. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-problem-statement-08 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 Mon Aug 4 11:20: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 82F1B1A00E5 for ; Mon, 4 Aug 2014 11:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 X-veRhbMN1al for ; Mon, 4 Aug 2014 11:20:13 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 062531A00F6 for ; Mon, 4 Aug 2014 11:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2094; q=dns/txt; s=iport; t=1407176400; x=1408386000; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=SmrW/+2GTkRXv55cZwBfIyIlEp4k9D5dGsPMVCC5cmc=; b=czRRoFF4VjS4b5FSBSNF9tGxEBDgyqCHC2Pdgk4BEQ89cCxYFLm/xDAw r2JIB/xNLJt1u6q4q7GShvLsJoj9EQgVaVHmIv3mtU+MedvQTb/kvnTF4 CwIyplHIZLLIRJuMSZAVqlkYiIm1NqrQqFDHjbM2rRLMPfncMgu+4z8W+ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAO3N31OtJA2D/2dsb2JhbABbgw1SUwQEzC4Kh0oBgREWd4QEAQEDAQEBATcrCRsCAQg2ECcLJQIEEwmIMQgIBcUMF48ZOoMvgRwFnAaBVJMLg01sgUY X-IronPort-AV: E=Sophos;i="5.01,799,1400025600"; d="scan'208";a="66428015" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP; 04 Aug 2014 18:19:59 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s74IJwFl026495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 4 Aug 2014 18:19:58 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Mon, 4 Aug 2014 13:19:58 -0500 From: "Paul Quinn (paulq)" To: "" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-problem-statement-08.txt Thread-Index: AQHPsBBKgKSLiX8vdUa59n7JrKL8v5vBFRYA Date: Mon, 4 Aug 2014 18:19:57 +0000 Message-ID: References: <20140804181651.7054.95913.idtracker@ietfa.amsl.com> In-Reply-To: <20140804181651.7054.95913.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.233] Content-Type: text/plain; charset="us-ascii" Content-ID: <9ADD313495082D408DD99063E8F6FB2C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/cQCprs6swNyJGmknC-Zqsm9IP2E Subject: Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-08.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, 04 Aug 2014 18:20:15 -0000 This version incorporates some minor grammar/typo corrections identified in= -07. Thanks, Paul On Aug 4, 2014, at 2:16 PM, wrote: >=20 > 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 Group = of the IETF. >=20 > Title : Service Function Chaining Problem Statement > Authors : Paul Quinn > Thomas Nadeau > Filename : draft-ietf-sfc-problem-statement-08.txt > Pages : 19 > Date : 2014-08-04 >=20 > Abstract: > This document provides an overview of the issues associated with the > deployment of service functions (such as firewalls, load balancers) > in large-scale environments. The term service function chaining is > used to describe the definition and instantiation of an ordered set > of instances of such service functions, and the subsequent "steering" > of traffic flows through those service functions. >=20 > The set of enabled service function chains reflect operator service > offerings and is designed in conjunction with application delivery > and service and network policy. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-08 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem-statement-08 >=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 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Aug 6 02:48: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 D4B821B2982 for ; Wed, 6 Aug 2014 02:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 NggARfxWHmbK for ; Wed, 6 Aug 2014 02:48:20 -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 5B1221B2CF8 for ; Wed, 6 Aug 2014 02:48:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHY81038; Wed, 06 Aug 2014 09:48:17 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 6 Aug 2014 10:48:16 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.204]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 6 Aug 2014 17:48:10 +0800 From: Xuxiaohu To: "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.txt Thread-Index: AQHPr2AigUDp9PUKd0KN/JsZgTmzp5vACiPQ///98QCAA03DIA== Date: Wed, 6 Aug 2014 09:48:09 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A2C72@NKGEML512-MBS.china.huawei.com> References: <20140803211558.28482.8328.idtracker@ietfa.amsl.com> <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A22F1@NKGEML512-MBS.china.huawei.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.111.98.134] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A2C72NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/1bb3afEt_Bospif5fDJIeEHWIgA Cc: "sfc@ietf.org" Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.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, 06 Aug 2014 09:48:33 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A2C72NKGEML512MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Carlos, In the case where the service path selection role is realized by other mean= s than the service path information contained in the SFC header, such as th= ose approaches as defined in the following docs (http://tools.ietf.org/html= /draft-rfernando-l3vpn-service-chaining-04, http://tools.ietf.org/html/draf= t-xu-spring-sfc-use-case-02), the SFC header just needs to accomplish the r= ole of metadata sharing. Best regards, Xiaohu 3. I think it' better to change the word "and" in the following sentence= to "and/or". In other word, the SFC encapsulation could play the role of S= FP selection, metadata sharing or both. In some cases where the SFP selecti= on role has been accomplished somewhere else (see 4.3.1. Transport Derived= SFF), the only possible role of the SFC encapsulation is metadata-sharing.= In some cases where no metadata is required to be shared, the only possibl= e role of the SFC encapsulation is SFP selection. " The SFC encapsulation enables service function path selection and the sharing of metadata/context information. Sorry I misunderstood where you were asking for the "and/or" to be inserted= on this comment. Section 4.1 clearly says: The SFC encapsulation provides explicit information used to identify the SFP. And that's, to me, the key issue we want to preserve on the SFC Encapsulati= on. If there is potential ambiguity in that first sentence, I'd suggest braking= it up in two: The SFC encapsulation enables service function path selection. It also e= nables the potential sharing of metadata and/or context information. Thanks, Carlos. 4. It seems that SF instance is a well understood term. Unfortunately, i= t has been removed. 5. s/SDC/SFC "Alternatively, a service provider may decide to exclude legacy service functions from an SDC domain. 6. s/SF functions/SFs according to the ordered set of SF functions Best regards, Xiaohu From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpig= nata) Sent: Monday, August 04, 2014 5:19 AM To: sfc@ietf.org Subject: [sfc] Fwd: New Version Notification for draft-merged-sfc-architect= ure-01.txt SFCers, After Toronto, Joel and I have been working on resolving the key open discu= ssion items, and incorporating all the input and feedback received thus int= o this document as the vehicle for a single SFC Architecture item to progre= ss. While we are still working on the document, we wanted to get a version out = early to the WG to test the resolution to key open items, see what we might= still be missing, and iterate. Please review and let us know. Thanks, Carlos & Joel. Begin forwarded message: From: > Subject: New Version Notification for draft-merged-sfc-architecture-01.txt Date: August 3, 2014 at 5:15:58 PM EDT To: Joel Halpern >, Carlos = Pignataro >, "Joel M. Halpern= " >, Carlos Pignataro > A new version of I-D, draft-merged-sfc-architecture-01.txt has been successfully submitted by Carlos Pignataro and posted to the IETF repository. Name: draft-merged-sfc-architecture Revision: 01 Title: Service Function Chaining (SFC) Architecture Document date: 2014-08-03 Group: Individual Submission Pages: 25 URL: http://www.ietf.org/internet-drafts/draft-merged-sfc-archit= ecture-01.txt Status: https://datatracker.ietf.org/doc/draft-merged-sfc-architect= ure/ Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-archite= cture-01 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 submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A2C72NKGEML512MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Carlos,=

 = ;

In the cas= e where the service path selection role is realized by other means than the= service path information contained in the SFC header, such as those approaches as defined in the following docs (http://tools.i= etf.org/html/draft-rfernando-l3vpn-service-chaining-04, http://tools.ie= tf.org/html/draft-xu-spring-sfc-use-case-02), the SFC header just needs to accomplish the role of metadata sharing.=

 = ;

Best regar= ds,

Xiaohu

 = ;

3.    = I think it’ better to change the word “and” in the followi= ng sentence to “and/or”. In other word, the SFC encapsulation c= ould play the role of SFP selection, metadata sharing or both. In some case= s where the SFP selection role has been accomplished somewhere else (see 4.3.1.  Transport Derived SFF), the only possible role of the SFC encapsulation is metadata-= sharing. In some cases where no metadata is required to be shared, the only= possible role of the SFC encapsulation is SFP selection.

“   The SFC encapsulation enables service function path sel=
ection and the
   sharing of metadata/context infor=
mation.
 

 

Sorry I misunderstood where you= were asking for the "and/or" to be inserted on this comment.&nbs= p;

 

Section 4.1 clearly says:<= /o:p>

   The SFC encapsulat= ion provides explicit information used to identify

   the SFP.

 

And that's, to me, the key issu= e we want to preserve on the SFC Encapsulation.

 

If there is potential ambiguity= in that first sentence, I'd suggest braking it up in two:

 

   The SFC encapsulat= ion enables service function path selection. It also enables the=

   potential sharing = of metadata and/or context information.

 

Thanks,

 

Carlos.

 



4.    It seems that SF instance is a well understood term. Unfortunately, it has be= en removed.

 =

5.    s/SDC/SFC

 = 

“Alternatively, a service provider may decide to exclude legacy
   service functions from an SDC dom=
ain.
 

6.    s/SF functions/SFs

according to the ordered set of SF functions
 

Best regards,=

Xiaohu=

 =

 

From: sfc [mailto:sfc-bounces@ietf.org]<= span class=3D"apple-converted-space"> On Behalf Of Carlos Pignataro (cpignata) Sent: Monday, Augu= st 04, 2014 5:19 AM
To: sfc@ietf.org
Subject: [sfc] Fwd= : New Version Notification for draft-merged-sfc-architecture-01.txt<= span lang=3D"EN-US">

 

= SFCers,

= After Toronto, Joel and I have been working on resolving the key open discu= ssion items, and incorporating all the input and feedback received thu= s into this document as the vehicle for a single SFC Architecture item to progress.

While we are still working on the document, we wanted to get a version out = early to the WG to test the resolution to key open items, see what we = might still be missing, and iterate.

Please review and let us know.

Thanks,

Carlos & Joel.

Begin forwarded message:




Subject: New Version Notification fo= r draft-merged-sfc-architecture-01.txt=

Date: August 3, 2014 at 5:15:58 PM ED= T

To: Joel Halpern <jmh@joelhalpern.com>, Carlos Pignataro <cpignata@cisco.com>, "Joel M. Halpern"= ; <j= mh@joelhalpern.com>, Carlos Pignataro <cpignata@cisco.com>

 

=
A new version of I-D, draft-merged-sfc-architecture-01.txt
has been successfully submitted by Carlos Pignataro and posted to the
IETF repository.

Name: draft-merged-sfc-ar= chitecture
Revision: 01
Title: Service Function C= haining (SFC) Architecture
Document date: 2014-08-03=
Group: Individual Submiss= ion
Pages: 25
URL:            http://www.ietf.org/internet-drafts/draf= t-merged-sfc-architecture-01.txt
Status:         https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/<= /span>
Htmlized:       htt= p://tools.ietf.org/html/draft-merged-sfc-architecture-01
Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-= sfc-architecture-01

Abstract:
  This document describes an architecture for the specification,<= br>   creation, and ongoing maintenance of Service Function Chains (S= FC) in
  a network.  It includes architectural concepts, principles= , and
  components used in the construction of composite services throu= gh
  deployment of SFCs.  This document does not propose soluti= ons,
  protocols, or extensions to existing protocols.




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

The IETF Secretariat

 

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A2C72NKGEML512MBSchi_-- From nobody Wed Aug 6 08:30: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 AC5E51B282F for ; Wed, 6 Aug 2014 08:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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.001, 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 nQ-zEzwkSCLH for ; Wed, 6 Aug 2014 08:30:03 -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 52F4A1B282A for ; Wed, 6 Aug 2014 08:30:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30147; q=dns/txt; s=iport; t=1407339003; x=1408548603; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=B8wBb9K77x+AEujtMA0IXZ0zUXfSZpOcyEea1bSWstk=; b=Z9JTpyqNUttGeKQ+IzW0p4bdZUjgzqHeRPGQfgk9qey8DOIJcxBZ4XgU 4EXVUQXHyAp5/OJeFIUy6oBYugz98t2ektHvTLpgHiX3qfkyBtxuq2asY CMfsWcE8tUfXB5vQ8VUygCQ1vl7WFxJePGPE9Rs2+Lxc9CQztTEwk8B09 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowFAK5I4lOtJV2R/2dsb2JhbABQCoJHRlJTBATKQoFnh0QBgRMWd4QDAQEBBHcCEAIBCBEBAgEBASEBBgcyFAMGCAIEDgUJEognCAXDGheJf4RxSw0EBgEGA4MmgRwFhjuIQYYvhmeBVJMRg1RsAQGBRA X-IronPort-AV: E=Sophos; i="5.01,812,1400025600"; d="scan'208,217"; a="66958800" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP; 06 Aug 2014 15:30:02 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s76FU2UI005294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Aug 2014 15:30:02 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.158]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Wed, 6 Aug 2014 10:30:01 -0500 From: "Carlos Pignataro (cpignata)" To: Xiaohu Xu Thread-Topic: [sfc] New Version Notification for draft-merged-sfc-architecture-01.txt Thread-Index: AQHPsYtJ0URE9p1bp06kXF0k9kXgvg== Date: Wed, 6 Aug 2014 15:30:01 +0000 Message-ID: <78D68F11-E179-41E0-87C0-816CD2953902@cisco.com> References: <20140803211558.28482.8328.idtracker@ietfa.amsl.com> <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A22F1@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A2C72@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A2C72@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.156.219] Content-Type: multipart/alternative; boundary="_000_78D68F11E17941E087C0816CD2953902ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/VgUg7z5pyZkfo-nTXRQS-tBUb_Y Cc: "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-merged-sfc-architecture-01.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, 06 Aug 2014 15:30:11 -0000 --_000_78D68F11E17941E087C0816CD2953902ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Xiaohu, I understand what you are saying, but those individual I-Ds don't even targ= et SFC. >From an SFC Architecture document, we ought to align the editing of the arc= hitecture to the WG charter , which = says: "Generic SFC Encapsulation: ... service-level data plane encapsulatio= n format that: ... specifies the Service Function Path". That parses unambi= guously to me. Thanks, Carlos. On Aug 6, 2014, at 5:48 AM, Xuxiaohu > wrote: Hi Carlos, In the case where the service path selection role is realized by other mean= s than the service path information contained in the SFC header, such as th= ose approaches as defined in the following docs (http://tools.ietf.org/html= /draft-rfernando-l3vpn-service-chaining-04,http://tools.ietf.org/html/draft= -xu-spring-sfc-use-case-02), the SFC header just needs to accomplish the ro= le of metadata sharing. Best regards, Xiaohu 3. I think it=92 better to change the word =93and=94 in the following se= ntence to =93and/or=94. In other word, the SFC encapsulation could play the= role of SFP selection, metadata sharing or both. In some cases where the S= FP selection role has been accomplished somewhere else (see 4.3.1. Transpo= rt Derived SFF), the only possible role of the SFC encapsulation is metadat= a-sharing. In some cases where no metadata is required to be shared, the on= ly possible role of the SFC encapsulation is SFP selection. =93 The SFC encapsulation enables service function path selection and the sharing of metadata/context information. Sorry I misunderstood where you were asking for the "and/or" to be inserted= on this comment. Section 4.1 clearly says: The SFC encapsulation provides explicit information used to identify the SFP. And that's, to me, the key issue we want to preserve on the SFC Encapsulati= on. If there is potential ambiguity in that first sentence, I'd suggest braking= it up in two: The SFC encapsulation enables service function path selection. It also e= nables the potential sharing of metadata and/or context information. Thanks, Carlos. 4. It seems that SF instance is a well understood term. Unfortunately, i= t has been removed. 5. s/SDC/SFC =93Alternatively, a service provider may decide to exclude legacy service functions from an SDC domain. 6. s/SF functions/SFs according to the ordered set of SF functions Best regards, Xiaohu From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpig= nata) Sent: Monday, August 04, 2014 5:19 AM To: sfc@ietf.org Subject: [sfc] Fwd: New Version Notification for draft-merged-sfc-architect= ure-01.txt SFCers, After Toronto, Joel and I have been working on resolving the key open discu= ssion items, and incorporating all the input and feedback received thus int= o this document as the vehicle for a single SFC Architecture item to progre= ss. While we are still working on the document, we wanted to get a version out = early to the WG to test the resolution to key open items, see what we might= still be missing, and iterate. Please review and let us know. Thanks, Carlos & Joel. Begin forwarded message: From: > Subject: New Version Notification for draft-merged-sfc-architecture-01.txt Date: August 3, 2014 at 5:15:58 PM EDT To: Joel Halpern >, Carlos = Pignataro >, "Joel M. Halpern= " >, Carlos Pignataro > A new version of I-D, draft-merged-sfc-architecture-01.txt has been successfully submitted by Carlos Pignataro and posted to the IETF repository. Name: draft-merged-sfc-architecture Revision: 01 Title: Service Function Chaining (SFC) Architecture Document date: 2014-08-03 Group: Individual Submission Pages: 25 URL: http://www.ietf.org/internet-drafts/draft-merged-sfc-archit= ecture-01.txt Status: https://datatracker.ietf.org/doc/draft-merged-sfc-architect= ure/ Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-archite= cture-01 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 submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_78D68F11E17941E087C0816CD2953902ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Xiaohu,

I understand what you are saying, but those individual I-Ds don't even= target SFC.

From an SFC Architecture document, we ought to align the editing of th= e architecture to the WG charter <http://tools.ietf.org/wg/sfc/charters>, which says: &quo= t;Generic SFC Encapsulation: ... service-level data plane encapsulation format that: ... specifies the Service Funct= ion Path". That parses unambiguously to me.

Thanks,

Carlos.

On Aug 6, 2014, at 5:48 AM, Xuxiaohu <xuxiaohu@huawei.com> wrote:

Hi Carlos,
 
In the case where the service path selectio= n role is realized by other means than the service path information contain= ed in the SFC header, such as those approaches as defined in the following docs (http://tools.ietf.org/html/draft-rfernando-l3= vpn-service-chaining-04,  
Best regards,
Xiaohu
 
3.    I think it=92 better to change the word =93and=94 in the following sentence = to =93and/or=94. In other word, the SFC encapsulation could play the role o= f SFP selection, metadata sharing or both. In some cases where the SFP sele= ction role has been accomplished somewhere else (see 4.3.1.  Transport Derived SFF), the only possible role of the SFC encapsulation is= metadata-sharing. In some cases where no metadata is required to be shared= , the only possible role of the SFC encapsulation is SFP selection.<= span lang=3D"EN-US">
=93 &=
nbsp; The SFC encapsulation enables service function path selection and the=

   sharing of metadata/context infor=
mation.
 
 
Sorry I misunderstood where you were asking for the &q= uot;and/or" to be inserted on this comment. 
 
Section 4.1 clearly says:
   The SFC encapsulation provides explicit i= nformation used to identify
   the SFP.
 
And that's, to me, the key issue we want to preserve o= n the SFC Encapsulation.
 
If there is potential ambiguity in that first sentence= , I'd suggest braking it up in two:
 
   The SFC encapsulation enables service fun= ction path selection. It also enables the
   potential sharing of metadata and/or cont= ext information.
 
Thanks,
 
Carlos.
 


4.    It seems that SF instance is a well understood term. Unfortunately, it has be= en removed.
 <= /span>
5.    s/SDC/SFC
 <= /span>
=93Alterna=
tively, a service provider may decide to exclude legacy<=
/pre>

   service functions from an SDC dom=
ain.


 





6.    s/SF
 functions/SFs




according to the ordered set of SF functions<=
o:p>


 <=
o:p>





Best regards,=








Xiaohu<=
/span>







 <=
/span>







 











From:&nbs=
p;sfc
 [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpignata)

Sent: Monday, Augu=
st 04, 2014 5:19 AM

To: sfc@=
ietf.org

Subject: [sfc] Fwd=
: New Version Notification for draft-merged-sfc-architecture-01.txt<=
span lang=3D"EN-US">









 





SFCers,





After Toronto, Joel and I have been working on resolvi=
ng the key open discussion items, and incorporating all the input and feedb=
ack received thus into this document as the vehicle for a single SFC A=
rchitecture item to progress.



While we are still working on the document, we wanted to get a version out =
early to the WG to test the resolution to key open items, see what we =
might still be missing, and iterate.



Please review and let us know.



Thanks,



Carlos & Joel.







Begin forwarded message:






















Subje=
ct: New Version Notification for draft-merged-sfc-architecture-01.txt







Date:=
 August 3, 2014 at 5:1=
5:58 PM EDT







To: Joel Halpern <jmh@joelhalpern.com>=
;,
 Carlos Pignataro <cpigna=
ta@cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.com>,
 Carlos Pignataro <cpigna=
ta@cisco.com>






 









A new version of I-D, draft-merged-sfc-architecture-01.txt

has been successfully submitted by Carlos Pignataro and posted to the

IETF repository.



Name: draft-merged-sfc-ar=
chitecture

Revision: 01

Title: Service Function C=
haining (SFC) Architecture

Document date: 2014-08-03=


Group: Individual Submiss=
ion

Pages: 25

URL:            http://www.ietf.org/internet-drafts/draft-merged-sfc-archite=
cture-01.txt

Status:         https://d=
atatracker.ietf.org/doc/draft-merged-sfc-architecture/

Htmlized:       http://tools.ietf.org/h=
tml/draft-merged-sfc-architecture-01

Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-01<=
/span>



Abstract:

  This document describes an architecture for the specification,<=
br>
  creation, and ongoing maintenance of Service Function Chains (S=
FC) in

  a network.  It includes architectural concepts, principles=
, and

  components used in the construction of composite services throu=
gh

  deployment of SFCs.  This document does not propose soluti=
ons,

  protocols, or extensions to existing protocols.









Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at too=
ls.ietf.org.



The IETF Secretariat

--_000_78D68F11E17941E087C0816CD2953902ciscocom_-- From nobody Wed Aug 6 09:45: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 E2CCF1A012D for ; Wed, 6 Aug 2014 09:45:46 -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 37wKgZo-KMuw for ; Wed, 6 Aug 2014 09:45:44 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65D01A00BB for ; Wed, 6 Aug 2014 09:45:43 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id a108so3043575qge.10 for ; Wed, 06 Aug 2014 09:45:43 -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=20343ybMsoPEiSlObQB80mHadZxg1dVpwfSFzg84D3M=; b=nefkiLald7T/mn8Oc9njcX1wWheCgS8m/Y6EieZdMD6QGeSZ/BoOrOoRi5mi2dsSge KdPzmpnYyTCTOJZQ//C3I9Qw1xv/22ZYN9Wv75rtWw0mG/kG3EzsNHCJm93wK3ZwEO1f Un+VSZAECEuJs5v3bUCG5FAXehx+fx/mih6rDvbWvSPqQeRJmBBW4mq2lWrSlNm/E9Xm UaXXfWV0CulWyDlHPC3kbLJinPe8Z0YufjDyQzhNGr7JogbPOkUX8KroSqTEN08cI2v2 8qoU9MZdvPEIyVP82RNRJuLt3TF6lyYVHniWqfc2zhMa9+Epgb5Ggitb2d91bVqKyyAq 6pZA== X-Received: by 10.140.37.178 with SMTP id r47mr4995480qgr.59.1407343543091; Wed, 06 Aug 2014 09:45:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.16.22 with HTTP; Wed, 6 Aug 2014 09:45:22 -0700 (PDT) In-Reply-To: <78D68F11-E179-41E0-87C0-816CD2953902@cisco.com> References: <20140803211558.28482.8328.idtracker@ietfa.amsl.com> <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A22F1@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A2C72@NKGEML512-MBS.china.huawei.com> <78D68F11-E179-41E0-87C0-816CD2953902@cisco.com> From: "Andrew G. Malis" Date: Wed, 6 Aug 2014 12:45:22 -0400 Message-ID: To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=001a11c15352f68a4b04fff8b37e Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Yeg0Sc0C4JvO9AgiFbTLMQeHdYk Cc: Xiaohu Xu , "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-merged-sfc-architecture-01.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, 06 Aug 2014 16:45:47 -0000 --001a11c15352f68a4b04fff8b37e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Carlos, You truncated some text from the charter. It also says, right after the text you quoted: - communicates context information between nodes that implement service functions and Service Function Chains. This is as much a part of the encapsulation as specifying the Service Function Path. Thus the text in the architecture document should reflect that. Thanks, Andy On Wed, Aug 6, 2014 at 11:30 AM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Hi Xiaohu, > > I understand what you are saying, but those individual I-Ds don't even > target SFC. > > From an SFC Architecture document, we ought to align the editing of the > architecture to the WG charter , > which says: "Generic SFC Encapsulation: ... service-level data plane > encapsulation format that: ... specifies the Service Function Path". That > parses unambiguously to me. > > Thanks, > > Carlos. > > On Aug 6, 2014, at 5:48 AM, Xuxiaohu wrote: > > Hi Carlos, > > In the case where the service path selection role is realized by other > means than the service path information contained in the SFC header, such > as those approaches as defined in the following docs ( > http://tools.ietf.org/html/draft-rfernando-l3vpn-service-chaining-04, > http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-02), the SFC > header just needs to accomplish the role of metadata sharing. > > Best regards, > Xiaohu > > 3. I think it=E2=80=99 better to change the word =E2=80=9Cand=E2=80= =9D in the following > sentence to =E2=80=9Cand/or=E2=80=9D. In other word, the SFC encapsulatio= n could play the > role of SFP selection, metadata sharing or both. In some cases where the > SFP selection role has been accomplished somewhere else (see 4.3.1 > . > Transport Derived SFF), the only possible role of the SFC encapsulation i= s > metadata-sharing. In some cases where no metadata is required to be share= d, > the only possible role of the SFC encapsulation is SFP selection. > > =E2=80=9C The SFC encapsulation enables service function path selection= and the > > sharing of metadata/context information. > > > > > Sorry I misunderstood where you were asking for the "and/or" to be > inserted on this comment. > > Section 4.1 clearly says: > The SFC encapsulation provides explicit information used to identify > the SFP. > > And that's, to me, the key issue we want to preserve on the SFC > Encapsulation. > > If there is potential ambiguity in that first sentence, I'd suggest > braking it up in two: > > The SFC encapsulation enables service function path selection. It > also enables the > potential sharing of metadata and/or context information. > > Thanks, > > Carlos. > > > > 4. It seems that SF instance is a well understood term. > Unfortunately, it has been removed. > > 5. s/SDC/SFC > > > =E2=80=9CAlternatively, a service provider may decide to exclude legacy > > service functions from an SDC domain. > > > > 6. s/SF functions/SFs > > according to the ordered set of SF functions > > > > Best regards, > Xiaohu > > > *From:* sfc [mailto:sfc-bounces@ietf.org ] *On > Behalf Of *Carlos Pignataro (cpignata) > *Sent:* Monday, August 04, 2014 5:19 AM > *To:* sfc@ietf.org > *Subject:* [sfc] Fwd: New Version Notification for > draft-merged-sfc-architecture-01.txt > > > SFCers, > > After Toronto, Joel and I have been working on resolving the key open > discussion items, and incorporating all the input and feedback received > thus into this document as the vehicle for a single SFC Architecture item > to progress. > > While we are still working on the document, we wanted to get a version ou= t > early to the WG to test the resolution to key open items, see what we mig= ht > still be missing, and iterate. > > Please review and let us know. > > Thanks, > > Carlos & Joel. > Begin forwarded message: > > > > *From: * > *Subject: New Version Notification for > draft-merged-sfc-architecture-01.txt* > *Date: *August 3, 2014 at 5:15:58 PM EDT > *To: *Joel Halpern , Carlos Pignataro < > cpignata@cisco.com>, "Joel M. Halpern" , Carlos > Pignataro > > > > A new version of I-D, draft-merged-sfc-architecture-01.txt > has been successfully submitted by Carlos Pignataro and posted to the > IETF repository. > > Name: draft-merged-sfc-architecture > Revision: 01 > Title: Service Function Chaining (SFC) Architecture > Document date: 2014-08-03 > Group: Individual Submission > Pages: 25 > URL: > http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-01.txt > Status: > https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ > Htmlized: > http://tools.ietf.org/html/draft-merged-sfc-architecture-01 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-01 > > 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.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > --001a11c15352f68a4b04fff8b37e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Carlos,

You truncated some text from th= e charter. It also says, right after the text you quoted:
     - communicates context informa=
tion between nodes that implement
       service functions and Service Function Chains.
This = is as much a part of the encapsulation as specifying the Service Function P= ath. Thus the text in the architecture document should reflect that.

Thanks,
Andy



On Wed, Aug 6, 2014= at 11:30 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
Hi Xiaohu,

I understand what you are saying, but those individual I-Ds don't = even target SFC.

From an SFC Architecture document, we ought to align the editing of th= e architecture to the WG charter <http://tools.ietf.org/wg/sfc/charters>= , which says: "Generic SFC Encapsulation: ... service-level data plane encapsulation format that: ...=C2=A0specifies the Service Funct= ion Path". That parses unambiguously to me.

Thanks,

Carlos.

On Aug 6, 2014, at 5:48 AM, Xuxiaohu <xuxiaohu@huawei.com> wrote:

Hi Carlos,
=C2=A0
In the case where the service path selection role is= realized by other means than the service path information contained in the= SFC header, such as those approaches as defined in the following docs (http://tools.ietf.org/html/draf= t-rfernando-l3vpn-service-chaining-04,http://tools.ietf.org/html/draft-xu-spring-sf= c-use-case-02), the SFC header just needs to accomplish the role of metadata sharing.
=C2=A0
Best regards,
Xiaohu
=C2=A0
3.=C2=A0=C2=A0=C2=A0=C2=A0I think it=E2=80=99 better to change the word =E2=80=9Cand=E2=80=9D in the f= ollowing sentence to =E2=80=9Cand/or=E2=80=9D. In other word, the SFC encap= sulation could play the role of SFP selection, metadata sharing or both. In= some cases where the SFP selection role has been accomplished somewhere else (see=C2=A04.3.1.=C2=A0 Transport Derived SFF), the only possible role of the SFC encapsulation is= metadata-sharing. In some cases where no metadata is required to be shared= , the only possible role of the SFC encapsulation is SFP selection.<= span lang=3D"EN-US">
=E2=80=9C=C2=A0=C2=A0 The SFC encapsulation enab=
les service function path selection and the
=
=C2=A0=C2=A0 sharing of metadata/context information.



=
=C2=A0
=C2=A0
Sorry I misunderstood where you were asking for the &q= uot;and/or" to be inserted on this comment.=C2=A0=
=C2=A0
Section 4.1 clearly says:
=C2=A0 =C2=A0The SFC encapsulation provides explicit i= nformation used to identify
=C2=A0 =C2=A0the SFP.
=C2=A0
And that's, to me, the key issue we want to preser= ve on the SFC Encapsulation.
=C2=A0
If there is potential ambiguity in that first sentence= , I'd suggest braking it up in two:
=C2=A0
=C2=A0 =C2=A0The SFC encapsulation enables service fun= ction path selection. It also enables the
=C2=A0 =C2=A0potential sharing of metadata and/or cont= ext information.
=C2=A0
Thanks,
=C2=A0
Carlos.
=C2=A0


4.=C2=A0=C2=A0=C2=A0=C2=A0It seems that SF instance is a well understood term. Unfortunately, it has be= en removed.
=C2=A0=
5.=C2=A0=C2=A0=C2=A0=C2=A0s/SDC/SFC
=C2=A0= 
=E2=80=9CAlternatively, a service provider may d=
ecide to exclude legacy
=
=C2=A0=C2=A0 service functions from an SDC domain.
=
=C2=A0
6.=C2=A0=C2=A0=C2=A0=C2=A0s/SF functions/SFs
=
according to the ordered set of SF functions
=C2=A0
Best regards,=
Xiaohu=
=C2=A0=
=C2=A0
From:=C2=A0sfc [mailto:sfc-bounces@ietf.org]=C2= =A0On Behalf Of=C2=A0Carlos Pignataro (cpignata)=
Sent:=C2=A0Monday, August 04, 2014 5:19 AM
To:=C2=A0sfc@ietf.org
Subject:=C2=A0[sfc] Fwd: New Version Notification for d= raft-merged-sfc-architecture-01.txt
=C2=A0

SFCers,

After Toronto, Joel and I have been working on resolvi= ng the key open discussion items, and incorporating all the input and feedb= ack=C2=A0received thus into this document as the vehicle for a single SFC A= rchitecture item to progress.

While we are still working on the document, we wanted to get a version out = early=C2=A0to the WG to test the resolution to key open items, see what we = might still be missing, and iterate.

Please review and let us know.

Thanks,

Carlos & Joel.

Begin forwarded message:



Subject:= New Version Notification for draft-merged-sfc-architecture-01.txt
Date:=C2=A0August 3, 2014 at 5:15:58 PM EDT
To:=C2=A0Joel Halpern <jmh@joelhalpern.com>, Carlos Pignataro <cpignata@cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.c= om>, Carlos Pignataro <cpignata@cisco.com><= u>
=C2=A0


A new version of I-D, draft-merged-sfc-architecture-01.txt
has been successfully submitted by Carlos Pignataro and posted to the
IETF repository.

Name:=C2=A0draft-merged-sfc-architecture
Revision:=C2=A001
Title:=C2=A0Service Function Chaining (SFC) Architecture
Document date:=C2=A02014-08-03
Group:=C2=A0Individual Submission
Pages:=C2=A025
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http://www.ietf.org/internet-drafts/draft-merged= -sfc-architecture-01.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http://tool= s.ietf.org/html/draft-merged-sfc-architecture-01
Diff: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-arch= itecture-01

Abstract:
=C2=A0=C2=A0This document describes an architecture for the specification,<= br> =C2=A0=C2=A0creation, and ongoing maintenance of Service Function Chains (S= FC) in
=C2=A0=C2=A0a network. =C2=A0It includes architectural concepts, principles= , and
=C2=A0=C2=A0components used in the construction of composite services throu= gh
=C2=A0=C2=A0deployment of SFCs. =C2=A0This document does not propose soluti= ons,
=C2=A0=C2=A0protocols, or extensions to existing protocols.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at=C2=A0tools.ietf.org.

The IETF Secretariat



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


--001a11c15352f68a4b04fff8b37e-- From nobody Wed Aug 6 11:34: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 72BFD1ACD01 for ; Wed, 6 Aug 2014 11:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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.001, 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 G5S2oq8VvM2V for ; Wed, 6 Aug 2014 11:34:11 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88A2B1ABD18 for ; Wed, 6 Aug 2014 11:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33215; q=dns/txt; s=iport; t=1407350051; x=1408559651; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=huxBQON8bJ0o9O+oqNNBb9gK2oETh9LlacXvTKoj9xg=; b=KGXtIK6tIbRm6dSQ+sNEUnUsURpn+2w8+ZUpx3T8I/VkjymVt3AiTGwD W9t7w2jZfcZ2Z8Ja6UAfsV9CYKlkjsZVUkbJRmTi2JUPWVqZ0wWkof6Wx tlS9ltZKmbTmqsP9ccVlr1PEbIY0g0FBDkx+Z65TVIw8AE34qY6CQ25An M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao4FAAR04lOtJA2M/2dsb2JhbABQCoJHRlJTBATKQ4FZAQ2HRAGBFxZ3hAMBAQEEAQEBawkCEAIBCBEBAgEBASEBBgchBgsUAwYIAgQOBQkSiBMDEQgFvSYNhhkXiX+DIIFRSw0EBgEGA4MmgRwFhjuIQYYvhGCCB4FUjGaGK4NUbAEBgUQ X-IronPort-AV: E=Sophos; i="5.01,813,1400025600"; d="scan'208,217"; a="67063566" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-8.cisco.com with ESMTP; 06 Aug 2014 18:34:10 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s76IYAWC003612 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Aug 2014 18:34:10 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.158]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Wed, 6 Aug 2014 13:34:10 -0500 From: "Carlos Pignataro (cpignata)" To: "Andrew G. Malis" Thread-Topic: [sfc] New Version Notification for draft-merged-sfc-architecture-01.txt Thread-Index: AQHPsZXeTTK/9mNTp0u6xkvsgzPxFpvEOrEA Date: Wed, 6 Aug 2014 18:34:09 +0000 Message-ID: <6A08CD87-353C-4D71-993E-9D83D01857AC@cisco.com> References: <20140803211558.28482.8328.idtracker@ietfa.amsl.com> <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A22F1@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A2C72@NKGEML512-MBS.china.huawei.com> <78D68F11-E179-41E0-87C0-816CD2953902@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.60] Content-Type: multipart/alternative; boundary="_000_6A08CD87353C4D71993E9D83D01857ACciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/maeG0iuRSDM-uhhSWJ26TPj9Sos Cc: Xiaohu Xu , "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-merged-sfc-architecture-01.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, 06 Aug 2014 18:34:15 -0000 --_000_6A08CD87353C4D71993E9D83D01857ACciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Andy, I agree. I actually truncated a lot (most of) the text from the charter, to minimize= the relevant context quoted. The first sentence in Section 4.1, SFC Encapsulation, currently reads: The SFC encapsulation enables service function path selection and the sharing of metadata/context information. I proposed the following, it it is more clear and removes perceived ambigui= ty: The SFC encapsulation enables service function path selection. It also e= nables the sharing of metadata/context information when such metadata exchange is r= equired. The "when required" is because of Section 4.9 says: Some SFCs may not require metadata exchange. SFC infrastructure enables the exchange of this shared data along the SFP. But I think either the existing text or the longer version capture the char= ter points. Thanks, Carlos. On Aug 6, 2014, at 12:45 PM, Andrew G. Malis > wrote: Carlos, You truncated some text from the charter. It also says, right after the tex= t you quoted: - communicates context information between nodes that implement service functions and Service Function Chains. This is as much a part of the encapsulation as specifying the Service Funct= ion Path. Thus the text in the architecture document should reflect that. Thanks, Andy On Wed, Aug 6, 2014 at 11:30 AM, Carlos Pignataro (cpignata) > wrote: Hi Xiaohu, I understand what you are saying, but those individual I-Ds don't even targ= et SFC. >From an SFC Architecture document, we ought to align the editing of the arc= hitecture to the WG charter , which = says: "Generic SFC Encapsulation: ... service-level data plane encapsulatio= n format that: ... specifies the Service Function Path". That parses unambi= guously to me. Thanks, Carlos. On Aug 6, 2014, at 5:48 AM, Xuxiaohu > wrote: Hi Carlos, In the case where the service path selection role is realized by other mean= s than the service path information contained in the SFC header, such as th= ose approaches as defined in the following docs (http://tools.ietf.org/html= /draft-rfernando-l3vpn-service-chaining-04,http://tools.ietf.org/html/draft= -xu-spring-sfc-use-case-02), the SFC header just needs to accomplish the ro= le of metadata sharing. Best regards, Xiaohu 3. I think it=92 better to change the word =93and=94 in the following se= ntence to =93and/or=94. In other word, the SFC encapsulation could play the= role of SFP selection, metadata sharing or both. In some cases where the S= FP selection role has been accomplished somewhere else (see 4.3.1. Transpo= rt Derived SFF), the only possible role of the SFC encapsulation is metadat= a-sharing. In some cases where no metadata is required to be shared, the on= ly possible role of the SFC encapsulation is SFP selection. =93 The SFC encapsulation enables service function path selection and the sharing of metadata/context information. Sorry I misunderstood where you were asking for the "and/or" to be inserted= on this comment. Section 4.1 clearly says: The SFC encapsulation provides explicit information used to identify the SFP. And that's, to me, the key issue we want to preserve on the SFC Encapsulati= on. If there is potential ambiguity in that first sentence, I'd suggest braking= it up in two: The SFC encapsulation enables service function path selection. It also e= nables the potential sharing of metadata and/or context information. Thanks, Carlos. 4. It seems that SF instance is a well understood term. Unfortunately, i= t has been removed. 5. s/SDC/SFC =93Alternatively, a service provider may decide to exclude legacy service functions from an SDC domain. 6. s/SF functions/SFs according to the ordered set of SF functions Best regards, Xiaohu From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpig= nata) Sent: Monday, August 04, 2014 5:19 AM To: sfc@ietf.org Subject: [sfc] Fwd: New Version Notification for draft-merged-sfc-architect= ure-01.txt SFCers, After Toronto, Joel and I have been working on resolving the key open discu= ssion items, and incorporating all the input and feedback received thus int= o this document as the vehicle for a single SFC Architecture item to progre= ss. While we are still working on the document, we wanted to get a version out = early to the WG to test the resolution to key open items, see what we might= still be missing, and iterate. Please review and let us know. Thanks, Carlos & Joel. Begin forwarded message: From: > Subject: New Version Notification for draft-merged-sfc-architecture-01.txt Date: August 3, 2014 at 5:15:58 PM EDT To: Joel Halpern >, Carlos = Pignataro >, "Joel M. Halpern= " >, Carlos Pignataro > A new version of I-D, draft-merged-sfc-architecture-01.txt has been successfully submitted by Carlos Pignataro and posted to the IETF repository. Name: draft-merged-sfc-architecture Revision: 01 Title: Service Function Chaining (SFC) Architecture Document date: 2014-08-03 Group: Individual Submission Pages: 25 URL: http://www.ietf.org/internet-drafts/draft-merged-sfc-archit= ecture-01.txt Status: https://datatracker.ietf.org/doc/draft-merged-sfc-architect= ure/ Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-archite= cture-01 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 submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_6A08CD87353C4D71993E9D83D01857ACciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Andy,

I agree.

I actually truncated a lot (most of) the text from the charter, to min= imize the relevant context quoted.

The first sentence in Section 4.1, SFC Encapsulation, currently reads:=

   The SFC encapsulation enables service function path selec= tion and the
   sharing of metadata/context information.

I proposed the following, it it is more clear and removes perceived am= biguity:

   The SFC encapsulation enables service function path selec= tion. It also enables the
   sharing of metadata/context information when such metadata exc= hange is required.

The "when required" is because of Section 4.9 says:

   Some SFCs may not
   require metadata exchange.  SFC infrastructure enabl= es the exchange
   of this shared data along the SFP.

But I think either the existing text or the longer version capture the= charter points.

Thanks,

Carlos.

On Aug 6, 2014, at 12:45 PM, Andrew G. Malis <agmalis@gmail.com> wrote:

Carlos,

You truncated some text from the charter. It also says, right after th= e text you quoted:
     - communicates context information bet=
ween nodes that implement
       service functions and Service Function Chains.
This is as much a part of the encapsulation as specifying the Service = Function Path. Thus the text in the architecture document should reflect th= at.

Thanks,
Andy



On Wed, Aug 6, 2014 at 11:30 AM, Carlos Pignatar= o (cpignata) <cpignata@cisco.com> wrote:
Hi Xiaohu,

I understand what you are saying, but those individual I-Ds don't even= target SFC.

From an SFC Architecture document, we ought to align the editing of th= e architecture to the WG charter <http://tools.ietf.org/wg/sfc/charters>= , which says: "Generic SFC Encapsulation: ... service-level data plane encapsulation format that: ... specifies= the Service Function Path". That parses unambiguously to me.

Thanks,

Carlos.

On Aug 6, 2014, at 5:48 AM, Xuxiaohu <xuxiaohu@huawei.com> wrote:

Hi Carlos,
 
In the case where the service path selection role is= realized by other means than the service path information contained in the= SFC header, such as those approaches as defined in the following docs (http://tools.ietf.org/html/draft-rfernando= -l3vpn-service-chaining-04,http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-= 02), the SFC header just needs to accomplish the role of metadata sharing.
 
Best regards,
Xiaohu
 
3.    I think it=92 better to change the word =93and=94 in the following sentence = to =93and/or=94. In other word, the SFC encapsulation could play the role o= f SFP selection, metadata sharing or both. In some cases where the SFP sele= ction role has been accomplished somewhere else (see 4.3.1.  Transport Derived SFF), the only possible role of the SFC encapsulation is= metadata-sharing. In some cases where no metadata is required to be shared= , the only possible role of the SFC encapsulation is SFP selection.<= span lang=3D"EN-US">
=93   The SFC encapsulation enables service fu=
nction path selection and the
 &n=
bsp; sharing of metadata/context information.
 
 
Sorry I misunderstood where you were asking for the &q= uot;and/or" to be inserted on this comment. =
 
Section 4.1 clearly says:
   The SFC encapsulation provides explicit i= nformation used to identify
   the SFP.
 
And that's, to me, the key issue we want to preserve o= n the SFC Encapsulation.
 
If there is potential ambiguity in that first sentence= , I'd suggest braking it up in two:
 
   The SFC encapsulation enables service fun= ction path selection. It also enables the
   potential sharing of metadata and/or cont= ext information.
 
Thanks,
 
Carlos.
 


4.    It seems that SF instance is a well understood term. Unfortunately, it has be= en removed.
 =
5.    s/SDC/SFC
 = 
=93Alternatively, a service provider may decide to exclu=
de legacy
 &n=
bsp; service functions from an SDC domain.
 
6.    s/SF functions/SFs
accordin=
g to the ordered set of SF functions
 
Best regards,=
Xiaohu=
 =
 
From: sfc [mailto:sfc-bounces@ietf.org]&nb= sp;On Behalf Of Carlos Pignataro (cpignata)=
Sent: Monday, August 04, 2014 5:19 AM
To: sfc@ietf.org
Subject: [sfc] Fwd: New Version Notification for d= raft-merged-sfc-architecture-01.txt
 

SFCers,

After Toronto, Joel and I have been working on resolvi= ng the key open discussion items, and incorporating all the input and feedb= ack received thus into this document as the vehicle for a single SFC A= rchitecture item to progress.

While we are still working on the document, we wanted to get a version out = early to the WG to test the resolution to key open items, see what we = might still be missing, and iterate.

Please review and let us know.

Thanks,

Carlos & Joel.

Begin forwarded message:



Subject:= New Version Notification for draft-merged-sfc-architecture-01.txt
Date: August 3, 2014 at 5:15:58 PM EDT
To: Joel Halpern <jmh@joelhalpern.com>, Carlos Pignataro <cpignata@cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.c= om>, Carlos Pignataro <cpignata@cisco.com><= u>
 


A new version of I-D, draft-merged-sfc-architecture-01.txt
has been successfully submitted by Carlos Pignataro and posted to the
IETF repository.

Name: draft-merged-sfc-architecture
Revision: 01
Title: Service Function Chaining (SFC) Architecture
Document date: 2014-08-03
Group: Individual Submission
Pages: 25
URL:            http://www.ietf.org/internet-drafts/draft-merged= -sfc-architecture-01.txt
Status:         https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/
Htmlized:       http://tool= s.ietf.org/html/draft-merged-sfc-architecture-01
Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-arch= itecture-01

Abstract:
  This document describes an architecture for the specification,<= br>   creation, and ongoing maintenance of Service Function Chains (S= FC) in
  a network.  It includes architectural concepts, principles= , and
  components used in the construction of composite services throu= gh
  deployment of SFCs.  This document does not propose soluti= ons,
  protocols, or extensions to existing protocols.




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

The IETF Secretariat



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



--_000_6A08CD87353C4D71993E9D83D01857ACciscocom_-- From nobody Wed Aug 6 12:30: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 8F1871B27AA for ; Wed, 6 Aug 2014 12:30:33 -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 d_zcENqPfWMs for ; Wed, 6 Aug 2014 12:30:24 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 340131B27AE for ; Wed, 6 Aug 2014 12:30:15 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id q107so3308428qgd.28 for ; Wed, 06 Aug 2014 12:30:14 -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=jBPEO4vgBWcGVWgJi+U1rHpvr0v9hugDWqPTxHkhzaU=; b=Q2pG178NCfCmACT6lj350tc2cFdYzJfSrOTfcO35PlVvN+mlzmDjLDj7XHwBEwNZaY iA/abOQ10sZ4IszoCYaj0VUjTe0fdMcatG8xVZEZ92PvI05eY7ROtm8Qj9ExfKh4SEJs /0I4AEasD8ToT9KeTZrrXNo5BxLmmpqUqNjUjcgtSW0cGOuMlB2nMLbMU1r7wMzkXKy0 xmu6KGTGDE1BYtB6WgrGpFCtNfagB5Px2tKrkYjPbtO6Bxpxt0uYMoIeSdGdQHYgveKj 6W/HS9b+BUzF5u5/I/UVeJ73LxYpvZqBWGSmtI2e3mzHLupCSVpKgEqF88jvIHSu88zu ri3Q== X-Received: by 10.224.172.129 with SMTP id l1mr20231440qaz.90.1407353414379; Wed, 06 Aug 2014 12:30:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.16.22 with HTTP; Wed, 6 Aug 2014 12:29:54 -0700 (PDT) In-Reply-To: <6A08CD87-353C-4D71-993E-9D83D01857AC@cisco.com> References: <20140803211558.28482.8328.idtracker@ietfa.amsl.com> <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A22F1@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A2C72@NKGEML512-MBS.china.huawei.com> <78D68F11-E179-41E0-87C0-816CD2953902@cisco.com> <6A08CD87-353C-4D71-993E-9D83D01857AC@cisco.com> From: "Andrew G. Malis" Date: Wed, 6 Aug 2014 15:29:54 -0400 Message-ID: To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=047d7b6771aa56730904fffb00a2 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/PTUWzS6BzouyqJVJWWGVvx1rrkI Cc: Xiaohu Xu , "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-merged-sfc-architecture-01.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, 06 Aug 2014 19:30:33 -0000 --047d7b6771aa56730904fffb00a2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Carlos, Thanks, I prefer the longer version. Cheers, Andy On Wed, Aug 6, 2014 at 2:34 PM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Andy, > > I agree. > > I actually truncated a lot (most of) the text from the charter, to > minimize the relevant context quoted. > > The first sentence in Section 4.1, SFC Encapsulation, currently reads: > > The SFC encapsulation enables service function path selection and the > sharing of metadata/context information. > > I proposed the following, it it is more clear and removes perceived > ambiguity: > > The SFC encapsulation enables service function path selection. It > also enables the > sharing of metadata/context information when such metadata exchange is > required. > > The "when required" is because of Section 4.9 says: > > Some SFCs may not > require metadata exchange. SFC infrastructure enables the exchange > of this shared data along the SFP. > > But I think either the existing text or the longer version capture the > charter points. > > Thanks, > > Carlos. > > On Aug 6, 2014, at 12:45 PM, Andrew G. Malis wrote: > > Carlos, > > You truncated some text from the charter. It also says, right after the > text you quoted: > > - communicates context information between nodes that implement > service functions and Service Function Chains. > > This is as much a part of the encapsulation as specifying the Service > Function Path. Thus the text in the architecture document should reflect > that. > > Thanks, > Andy > > > > On Wed, Aug 6, 2014 at 11:30 AM, Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > >> Hi Xiaohu, >> >> I understand what you are saying, but those individual I-Ds don't even >> target SFC. >> >> From an SFC Architecture document, we ought to align the editing of the >> architecture to the WG charter , >> which says: "Generic SFC Encapsulation: ... service-level data plane >> encapsulation format that: ... specifies the Service Function Path". Tha= t >> parses unambiguously to me. >> >> Thanks, >> >> Carlos. >> >> On Aug 6, 2014, at 5:48 AM, Xuxiaohu wrote: >> >> Hi Carlos, >> >> In the case where the service path selection role is realized by other >> means than the service path information contained in the SFC header, suc= h >> as those approaches as defined in the following docs ( >> http://tools.ietf.org/html/draft-rfernando-l3vpn-service-chaining-04, >> http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-02), the SFC >> header just needs to accomplish the role of metadata sharing. >> >> Best regards, >> Xiaohu >> >> 3. I think it=E2=80=99 better to change the word =E2=80=9Cand=E2= =80=9D in the following >> sentence to =E2=80=9Cand/or=E2=80=9D. In other word, the SFC encapsulati= on could play the >> role of SFP selection, metadata sharing or both. In some cases where the >> SFP selection role has been accomplished somewhere else (see 4.3.1 >> . >> Transport Derived SFF), the only possible role of the SFC encapsulation = is >> metadata-sharing. In some cases where no metadata is required to be shar= ed, >> the only possible role of the SFC encapsulation is SFP selection. >> >> =E2=80=9C The SFC encapsulation enables service function path selectio= n and the >> >> sharing of metadata/context information. >> >> >> >> >> Sorry I misunderstood where you were asking for the "and/or" to be >> inserted on this comment. >> >> Section 4.1 clearly says: >> The SFC encapsulation provides explicit information used to identif= y >> the SFP. >> >> And that's, to me, the key issue we want to preserve on the SFC >> Encapsulation. >> >> If there is potential ambiguity in that first sentence, I'd suggest >> braking it up in two: >> >> The SFC encapsulation enables service function path selection. It >> also enables the >> potential sharing of metadata and/or context information. >> >> Thanks, >> >> Carlos. >> >> >> >> 4. It seems that SF instance is a well understood term. >> Unfortunately, it has been removed. >> >> 5. s/SDC/SFC >> >> >> =E2=80=9CAlternatively, a service provider may decide to exclude legacy >> >> service functions from an SDC domain. >> >> >> >> 6. s/SF functions/SFs >> >> according to the ordered set of SF functions >> >> >> >> Best regards, >> Xiaohu >> >> >> *From:* sfc [mailto:sfc-bounces@ietf.org ] *On >> Behalf Of *Carlos Pignataro (cpignata) >> *Sent:* Monday, August 04, 2014 5:19 AM >> *To:* sfc@ietf.org >> *Subject:* [sfc] Fwd: New Version Notification for >> draft-merged-sfc-architecture-01.txt >> >> >> SFCers, >> >> After Toronto, Joel and I have been working on resolving the key open >> discussion items, and incorporating all the input and feedback received >> thus into this document as the vehicle for a single SFC Architecture ite= m >> to progress. >> >> While we are still working on the document, we wanted to get a version >> out early to the WG to test the resolution to key open items, see what w= e >> might still be missing, and iterate. >> >> Please review and let us know. >> >> Thanks, >> >> Carlos & Joel. >> Begin forwarded message: >> >> >> >> *From: * >> *Subject: New Version Notification for >> draft-merged-sfc-architecture-01.txt* >> *Date: *August 3, 2014 at 5:15:58 PM EDT >> *To: *Joel Halpern , Carlos Pignataro < >> cpignata@cisco.com>, "Joel M. Halpern" , Carlos >> Pignataro >> >> >> >> A new version of I-D, draft-merged-sfc-architecture-01.txt >> has been successfully submitted by Carlos Pignataro and posted to the >> IETF repository. >> >> Name: draft-merged-sfc-architecture >> Revision: 01 >> Title: Service Function Chaining (SFC) Architecture >> Document date: 2014-08-03 >> Group: Individual Submission >> Pages: 25 >> URL: >> http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-01.txt >> Status: >> https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ >> Htmlized: >> http://tools.ietf.org/html/draft-merged-sfc-architecture-01 >> Diff: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-01 >> >> 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.ietf.org. >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> >> > > --047d7b6771aa56730904fffb00a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Carlos,

Thanks, I prefer the longer ver= sion.

Cheers,
Andy


On Wed, Aug 6, 2014 at = 2:34 PM, Carlos Pignataro (cpignata) <cpignata@cisco.com> w= rote:
Andy,

I agree.

I actually truncated a lot (most of) the text from the charter, to min= imize the relevant context quoted.

The first sentence in Section 4.1, SFC Encapsulation, currently reads:=

=C2=A0 =C2=A0The SFC encapsulation enables service function path selec= tion and the
=C2=A0 =C2=A0sharing of metadata/context information.

I proposed the following, it it is more clear and removes percei= ved ambiguity:

=C2=A0 =C2=A0The SFC encapsulation enables service fun= ction path selection. It also enables the
=C2=A0 =C2=A0sharing of metadata/context information when such metadata exc= hange is required.

The "when required" is because of Section 4.9 says:

=C2=A0 =C2=A0Some SFCs may not
=C2=A0 =C2=A0require metadata exchange. =C2=A0SFC infrastructure enabl= es the exchange
=C2=A0 =C2=A0of this shared data along the SFP.

But I think either the existing text or the longer version capture the= charter points.

Thanks,

Carlos.

On Aug 6, 2014, at 12:45 PM, Andrew G. Malis <agmalis@gmail.com> wrote:

Carlos,

You truncated some text from the charter. It also says, right after th= e text you quoted:
     - communicates context information betwe=
en nodes that implement
       service functions and Service Function Chains.
This is as much a part of the encapsulation as specifying the Service = Function Path. Thus the text in the architecture document should reflect th= at.

Thanks,
Andy



On Wed, Aug 6, 2014 at 11:30 AM, Carlos Pignatar= o (cpignata) <cpignata@cisco.com> wrote:
Hi Xiaohu,

I understand what you are saying, but those individual I-Ds don't = even target SFC.

From an SFC Architecture document, we ought to align the editing of th= e architecture to the WG charter <http://tools.ietf.org/wg/sfc/charters>= , which says: "Generic SFC Encapsulation: ... service-level data plane encapsulation format that: ...=C2=A0specifies= the Service Function Path". That parses unambiguously to me.

Thanks,

Carlos.

On Aug 6, 2014, at 5:48 AM, Xuxiaohu <xuxiaohu@huawei.com> wrote:

Hi Carlos,
=C2=A0
In the case where the service path selection role is= realized by other means than the service path information contained in the= SFC header, such as those approaches as defined in the following docs (http://tools.ietf.org/html/draft-rfernando= -l3vpn-service-chaining-04,http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-= 02), the SFC header just needs to accomplish the role of metadata sharing.
=C2=A0
Best regards,
Xiaohu
=C2=A0
3.=C2=A0=C2=A0=C2=A0=C2=A0I think it=E2=80=99 better to change the word =E2=80=9Cand=E2=80=9D in the f= ollowing sentence to =E2=80=9Cand/or=E2=80=9D. In other word, the SFC encap= sulation could play the role of SFP selection, metadata sharing or both. In= some cases where the SFP selection role has been accomplished somewhere else (see=C2=A04.3.1.=C2=A0 Transport Derived SFF), the only possible role of the SFC encapsulation is= metadata-sharing. In some cases where no metadata is required to be shared= , the only possible role of the SFC encapsulation is SFP selection.<= span lang=3D"EN-US">
=E2=80=9C=C2=A0=C2=A0 The SFC encapsulation enab=
les service function path selection and the
=
=C2=A0=C2=A0 sharing of metadata/context information.



=
=C2=A0
=C2=A0
Sorry I misunderstood where you were asking for the &q= uot;and/or" to be inserted on this comment.=C2=A0=
=C2=A0
Section 4.1 clearly says:
=C2=A0 =C2=A0The SFC encapsulation provides explicit i= nformation used to identify
=C2=A0 =C2=A0the SFP.
=C2=A0
And that's, to me, the key issue we want to preser= ve on the SFC Encapsulation.
=C2=A0
If there is potential ambiguity in that first sentence= , I'd suggest braking it up in two:
=C2=A0
=C2=A0 =C2=A0The SFC encapsulation enables service fun= ction path selection. It also enables the
=C2=A0 =C2=A0potential sharing of metadata and/or cont= ext information.
=C2=A0
Thanks,
=C2=A0
Carlos.
=C2=A0


4.=C2=A0=C2=A0=C2=A0=C2=A0It seems that SF instance is a well understood term. Unfortunately, it has be= en removed.
=C2=A0=
5.=C2=A0=C2=A0=C2=A0=C2=A0s/SDC/SFC
=C2=A0= 
=E2=80=9CAlternatively, a service provider may d=
ecide to exclude legacy
=
=C2=A0=C2=A0 service functions from an SDC domain.
=
=C2=A0
6.=C2=A0=C2=A0=C2=A0=C2=A0s/SF functions/SFs
=
according to the ordered set of SF functions
=C2=A0
Best regards,=
Xiaohu=
=C2=A0=
=C2=A0
From:=C2=A0sfc [mailto:sfc-bounces@ietf.org]=C2= =A0On Behalf Of=C2=A0Carlos Pignataro (cpignata)=
Sent:=C2=A0Monday, August 04, 2014 5:19 AM
To:=C2=A0sfc@ietf.org
Subject:=C2=A0[sfc] Fwd: New Version Notification for d= raft-merged-sfc-architecture-01.txt
=C2=A0

SFCers,

After Toronto, Joel and I have been working on resolvi= ng the key open discussion items, and incorporating all the input and feedb= ack=C2=A0received thus into this document as the vehicle for a single SFC A= rchitecture item to progress.

While we are still working on the document, we wanted to get a version out = early=C2=A0to the WG to test the resolution to key open items, see what we = might still be missing, and iterate.

Please review and let us know.

Thanks,

Carlos & Joel.

Begin forwarded message:



Subject:= New Version Notification for draft-merged-sfc-architecture-01.txt
Date:=C2=A0August 3, 2014 at 5:15:58 PM EDT
To:=C2=A0Joel Halpern <jmh@joelhalpern.com>, Carlos Pignataro <cpignata@cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.c= om>, Carlos Pignataro <cpignata@cisco.com><= u>
=C2=A0


A new version of I-D, draft-merged-sfc-architecture-01.txt
has been successfully submitted by Carlos Pignataro and posted to the
IETF repository.

Name:=C2=A0draft-merged-sfc-architecture
Revision:=C2=A001
Title:=C2=A0Service Function Chaining (SFC) Architecture
Document date:=C2=A02014-08-03
Group:=C2=A0Individual Submission
Pages:=C2=A025
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http://www.ietf.org/internet-drafts/draft-merged= -sfc-architecture-01.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http://tool= s.ietf.org/html/draft-merged-sfc-architecture-01
Diff: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-arch= itecture-01

Abstract:
=C2=A0=C2=A0This document describes an architecture for the specification,<= br> =C2=A0=C2=A0creation, and ongoing maintenance of Service Function Chains (S= FC) in
=C2=A0=C2=A0a network. =C2=A0It includes architectural concepts, principles= , and
=C2=A0=C2=A0components used in the construction of composite services throu= gh
=C2=A0=C2=A0deployment of SFCs. =C2=A0This document does not propose soluti= ons,
=C2=A0=C2=A0protocols, or extensions to existing protocols.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at=C2=A0tools.ietf.org.

The IETF Secretariat



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




--047d7b6771aa56730904fffb00a2-- From nobody Wed Aug 6 18:40: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 DD4691A03B8 for ; Wed, 6 Aug 2014 18:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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.001, 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 499lSM9bKr1I for ; Wed, 6 Aug 2014 18:40:31 -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 D15391A03B7 for ; Wed, 6 Aug 2014 18:40:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35078; q=dns/txt; s=iport; t=1407375631; x=1408585231; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HfE3QgkWszZnQZpEdJIUzYR2b6GYq0+K43q9OsMFl0A=; b=fpDByQg/WfL+VT1TnCh0tJm2i5dM9301IFVoSQftnEtgJMRRbo7VbU9N HjFWl3OmNwY3LfO6x9Cqvxzjys/lA9XGbW9lrtfvavGpk6CDhHcqJJ70b XU+mDPu4k9IoTbOpcWd5MBJzfidSHBt2bO3BLfhRSP9NopIDD17HT7PzG U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEFAKfX4lOtJV2Y/2dsb2JhbABQCoJHRlJTBMsJgVkBDYdEAYEVFneEAwEBAQQBAQFrCQIQAgEIEQECAQEBIQEGByEGCxQDBggCBA4FCRKIEwMRCAW9UQ2GGReJf4MggVFLDQQGAQYDgyaBHAWGO4hChi+EYIIHgVSMZ4Yrg1dsAQE X-IronPort-AV: E=Sophos; i="5.01,815,1400025600"; d="scan'208,217"; a="67160146" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP; 07 Aug 2014 01:40:30 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s771eTM5012448 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Aug 2014 01:40:29 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.158]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Wed, 6 Aug 2014 20:40:29 -0500 From: "Carlos Pignataro (cpignata)" To: "Andrew G. Malis" Thread-Topic: [sfc] New Version Notification for draft-merged-sfc-architecture-01.txt Thread-Index: AQHPsZXeTTK/9mNTp0u6xkvsgzPxFpvEOrEAgAAPjQCAABO5MQ== Date: Thu, 7 Aug 2014 01:40:29 +0000 Message-ID: <7E57DA1F-5D4D-44E6-A332-751628CC8641@cisco.com> References: <20140803211558.28482.8328.idtracker@ietfa.amsl.com> <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A22F1@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A2C72@NKGEML512-MBS.china.huawei.com> <78D68F11-E179-41E0-87C0-816CD2953902@cisco.com> <6A08CD87-353C-4D71-993E-9D83D01857AC@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7E57DA1F5D4D44E6A332751628CC8641ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/RPiOsOIz9kxRyElKji7fBxX5a-s Cc: Xiaohu Xu , "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-merged-sfc-architecture-01.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, 07 Aug 2014 01:40:35 -0000 --_000_7E57DA1F5D4D44E6A332751628CC8641ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sounds good, Andy. Thanks. Updated in our working copy. Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On Aug 6, 2014, at 3:30 PM, "Andrew G. Malis" > wrote: Carlos, Thanks, I prefer the longer version. Cheers, Andy On Wed, Aug 6, 2014 at 2:34 PM, Carlos Pignataro (cpignata) > wrote: Andy, I agree. I actually truncated a lot (most of) the text from the charter, to minimize= the relevant context quoted. The first sentence in Section 4.1, SFC Encapsulation, currently reads: The SFC encapsulation enables service function path selection and the sharing of metadata/context information. I proposed the following, it it is more clear and removes perceived ambigui= ty: The SFC encapsulation enables service function path selection. It also e= nables the sharing of metadata/context information when such metadata exchange is r= equired. The "when required" is because of Section 4.9 says: Some SFCs may not require metadata exchange. SFC infrastructure enables the exchange of this shared data along the SFP. But I think either the existing text or the longer version capture the char= ter points. Thanks, Carlos. On Aug 6, 2014, at 12:45 PM, Andrew G. Malis > wrote: Carlos, You truncated some text from the charter. It also says, right after the tex= t you quoted: - communicates context information between nodes that implement service functions and Service Function Chains. This is as much a part of the encapsulation as specifying the Service Funct= ion Path. Thus the text in the architecture document should reflect that. Thanks, Andy On Wed, Aug 6, 2014 at 11:30 AM, Carlos Pignataro (cpignata) > wrote: Hi Xiaohu, I understand what you are saying, but those individual I-Ds don't even targ= et SFC. >From an SFC Architecture document, we ought to align the editing of the arc= hitecture to the WG charter , which = says: "Generic SFC Encapsulation: ... service-level data plane encapsulatio= n format that: ... specifies the Service Function Path". That parses unambi= guously to me. Thanks, Carlos. On Aug 6, 2014, at 5:48 AM, Xuxiaohu > wrote: Hi Carlos, In the case where the service path selection role is realized by other mean= s than the service path information contained in the SFC header, such as th= ose approaches as defined in the following docs (http://tools.ietf.org/html= /draft-rfernando-l3vpn-service-chaining-04,http://tools.ietf.org/html/draft= -xu-spring-sfc-use-case-02), the SFC header just needs to accomplish the ro= le of metadata sharing. Best regards, Xiaohu 3. I think it=92 better to change the word =93and=94 in the following se= ntence to =93and/or=94. In other word, the SFC encapsulation could play the= role of SFP selection, metadata sharing or both. In some cases where the S= FP selection role has been accomplished somewhere else (see 4.3.1. Transpo= rt Derived SFF), the only possible role of the SFC encapsulation is metadat= a-sharing. In some cases where no metadata is required to be shared, the on= ly possible role of the SFC encapsulation is SFP selection. =93 The SFC encapsulation enables service function path selection and the sharing of metadata/context information. Sorry I misunderstood where you were asking for the "and/or" to be inserted= on this comment. Section 4.1 clearly says: The SFC encapsulation provides explicit information used to identify the SFP. And that's, to me, the key issue we want to preserve on the SFC Encapsulati= on. If there is potential ambiguity in that first sentence, I'd suggest braking= it up in two: The SFC encapsulation enables service function path selection. It also e= nables the potential sharing of metadata and/or context information. Thanks, Carlos. 4. It seems that SF instance is a well understood term. Unfortunately, i= t has been removed. 5. s/SDC/SFC =93Alternatively, a service provider may decide to exclude legacy service functions from an SDC domain. 6. s/SF functions/SFs according to the ordered set of SF functions Best regards, Xiaohu From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpig= nata) Sent: Monday, August 04, 2014 5:19 AM To: sfc@ietf.org Subject: [sfc] Fwd: New Version Notification for draft-merged-sfc-architect= ure-01.txt SFCers, After Toronto, Joel and I have been working on resolving the key open discu= ssion items, and incorporating all the input and feedback received thus int= o this document as the vehicle for a single SFC Architecture item to progre= ss. While we are still working on the document, we wanted to get a version out = early to the WG to test the resolution to key open items, see what we might= still be missing, and iterate. Please review and let us know. Thanks, Carlos & Joel. Begin forwarded message: From: > Subject: New Version Notification for draft-merged-sfc-architecture-01.txt Date: August 3, 2014 at 5:15:58 PM EDT To: Joel Halpern >, Carlos = Pignataro >, "Joel M. Halpern= " >, Carlos Pignataro > A new version of I-D, draft-merged-sfc-architecture-01.txt has been successfully submitted by Carlos Pignataro and posted to the IETF repository. Name: draft-merged-sfc-architecture Revision: 01 Title: Service Function Chaining (SFC) Architecture Document date: 2014-08-03 Group: Individual Submission Pages: 25 URL: http://www.ietf.org/internet-drafts/draft-merged-sfc-archit= ecture-01.txt Status: https://datatracker.ietf.org/doc/draft-merged-sfc-architect= ure/ Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-archite= cture-01 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 submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_7E57DA1F5D4D44E6A332751628CC8641ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Sounds good, Andy. Thanks. 

Updated in our working copy.

Excuze typofraphicak errows

On Aug 6, 2014, at 3:30 PM, "Andrew G. Malis" <agmalis@gmail.com> wrote:

Carlos,

Thanks, I prefer the longer version.

Cheers,
Andy


On Wed, Aug 6, 2014 at 2:34 PM, Carlos Pignataro= (cpignata) <cpignata@cisco.com> wrote:
Andy,

I agree.

I actually truncated a lot (most of) the text from the charter, to min= imize the relevant context quoted.

The first sentence in Section 4.1, SFC Encapsulation, currently reads:=

   The SFC encapsulation enables service function path selec= tion and the
   sharing of metadata/context information.

I proposed the following, it it is more clear and removes perceived am= biguity:

   The SFC encapsulation enables service function= path selection. It also enables the
   sharing of metadata/context information when such metadata exc= hange is required.

The "when required" is because of Section 4.9 says:

   Some SFCs may not
   require metadata exchange.  SFC infrastructure enabl= es the exchange
   of this shared data along the SFP.

But I think either the existing text or the longer version capture the= charter points.

Thanks,

Carlos.

On Aug 6, 2014, at 12:45 PM, Andrew G. Malis <agmalis@gmail.com> wrote:

Carlos,

You truncated some text from the charter. It also says, right after th= e text you quoted:
     - communicates context information betwe=
en nodes that implement
       service functions and Service Function Chains.
This is as much a part of the encapsulation as specifying the Service = Function Path. Thus the text in the architecture document should reflect th= at.

Thanks,
Andy



On Wed, Aug 6, 2014 at 11:30 AM, Carlos Pignatar= o (cpignata) <cpignata@cisco.com> wrote:
Hi Xiaohu,

I understand what you are saying, but those individual I-Ds don't even= target SFC.

From an SFC Architecture document, we ought to align the editing of th= e architecture to the WG charter <http://tools.ietf.org/wg/sfc/charters>= , which says: "Generic SFC Encapsulation: ... service-level data plane encapsulation format that: ... specifies= the Service Function Path". That parses unambiguously to me.

Thanks,

Carlos.

On Aug 6, 2014, at 5:48 AM, Xuxiaohu <xuxiaohu@huawei.com> wrote:

Hi Carlos,
 
In the case where the service path selection role is= realized by other means than the service path information contained in the= SFC header, such as those approaches as defined in the following docs (http://tools.ietf.org/html/draft-rfernando= -l3vpn-service-chaining-04,http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-= 02), the SFC header just needs to accomplish the role of metadata sharing.
 
Best regards,
Xiaohu
 
3.    I think it=92 better to change the word =93and=94 in the following sentence = to =93and/or=94. In other word, the SFC encapsulation could play the role o= f SFP selection, metadata sharing or both. In some cases where the SFP sele= ction role has been accomplished somewhere else (see 4.3.1.  Transport Derived SFF), the only possible role of the SFC encapsulation is= metadata-sharing. In some cases where no metadata is required to be shared= , the only possible role of the SFC encapsulation is SFP selection.<= span lang=3D"EN-US">
=93   The SFC encapsulation enables service fu=
nction path selection and the
 &n=
bsp; sharing of metadata/context information.
 
 
Sorry I misunderstood where you were asking for the &q= uot;and/or" to be inserted on this comment. =
 
Section 4.1 clearly says:
   The SFC encapsulation provides explicit i= nformation used to identify
   the SFP.
 
And that's, to me, the key issue we want to preserve o= n the SFC Encapsulation.
 
If there is potential ambiguity in that first sentence= , I'd suggest braking it up in two:
 
   The SFC encapsulation enables service fun= ction path selection. It also enables the
   potential sharing of metadata and/or cont= ext information.
 
Thanks,
 
Carlos.
 


4.    It seems that SF instance is a well understood term. Unfortunately, it has be= en removed.
 =
5.    s/SDC/SFC
 = 
=93Alternatively, a service provider may decide to exclu=
de legacy
 &n=
bsp; service functions from an SDC domain.
 
6.    s/SF functions/SFs
accordin=
g to the ordered set of SF functions
 
Best regards,=
Xiaohu=
 =
 
From: sfc [mailto:sfc-bounces@ietf.org]&nb= sp;On Behalf Of Carlos Pignataro (cpignata)=
Sent: Monday, August 04, 2014 5:19 AM
To: sfc@ietf.org
Subject: [sfc] Fwd: New Version Notification for d= raft-merged-sfc-architecture-01.txt
 

SFCers,

After Toronto, Joel and I have been working on resolvi= ng the key open discussion items, and incorporating all the input and feedb= ack received thus into this document as the vehicle for a single SFC A= rchitecture item to progress.

While we are still working on the document, we wanted to get a version out = early to the WG to test the resolution to key open items, see what we = might still be missing, and iterate.

Please review and let us know.

Thanks,

Carlos & Joel.

Begin forwarded message:



Subject:= New Version Notification for draft-merged-sfc-architecture-01.txt
Date: August 3, 2014 at 5:15:58 PM EDT
To: Joel Halpern <jmh@joelhalpern.com>, Carlos Pignataro <cpignata@cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.c= om>, Carlos Pignataro <cpignata@cisco.com><= u>
 


A new version of I-D, draft-merged-sfc-architecture-01.txt
has been successfully submitted by Carlos Pignataro and posted to the
IETF repository.

Name: draft-merged-sfc-architecture
Revision: 01
Title: Service Function Chaining (SFC) Architecture
Document date: 2014-08-03
Group: Individual Submission
Pages: 25
URL:            http://www.ietf.org/internet-drafts/draft-merged= -sfc-architecture-01.txt
Status:         https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/
Htmlized:       http://tool= s.ietf.org/html/draft-merged-sfc-architecture-01
Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-arch= itecture-01

Abstract:
  This document describes an architecture for the specification,<= br>   creation, and ongoing maintenance of Service Function Chains (S= FC) in
  a network.  It includes architectural concepts, principles= , and
  components used in the construction of composite services throu= gh
  deployment of SFCs.  This document does not propose soluti= ons,
  protocols, or extensions to existing protocols.




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

The IETF Secretariat



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




--_000_7E57DA1F5D4D44E6A332751628CC8641ciscocom_-- From nobody Wed Aug 6 19:13: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 311A71A04C5 for ; Wed, 6 Aug 2014 19:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 62wCNru7sYfn for ; Wed, 6 Aug 2014 19:12:59 -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 E72801A034A for ; Wed, 6 Aug 2014 19:12:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHZ42949; Thu, 07 Aug 2014 02:12:57 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 Aug 2014 03:12:56 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.204]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Thu, 7 Aug 2014 10:12:50 +0800 From: Xuxiaohu To: "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] New Version Notification for draft-merged-sfc-architecture-01.txt Thread-Index: AQHPsYtR7ikjinnxxEqg9uFNHrftYZvEYwcA Date: Thu, 7 Aug 2014 02:12:49 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A3248@NKGEML512-MBS.china.huawei.com> References: <20140803211558.28482.8328.idtracker@ietfa.amsl.com> <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A22F1@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A2C72@NKGEML512-MBS.china.huawei.com> <78D68F11-E179-41E0-87C0-816CD2953902@cisco.com> In-Reply-To: <78D68F11-E179-41E0-87C0-816CD2953902@cisco.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: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A3248NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ZqwZZMuRsy_Z2oS9xxIZxSo7r-I Cc: "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-merged-sfc-architecture-01.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, 07 Aug 2014 02:13:04 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A3248NKGEML512MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Carlos and SFCers, I just noticed that the WG charter also says : "...The WG will examine exis= ting identifier schemes, if there is a need for such identifiers in the con= text of the Generic SFC encapsulation, before defining any new identifier s= cheme...." Hence, does it mean the SFC approaches as defined in those indiv= idual I-Ds, especially the SPRING-based SFC approach (http://www.ietf.org/p= roceedings/90/slides/slides-90-spring-5.pdf), should be discussed in the SF= C WG? Best regards, Xiaohu From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] Sent: Wednesday, August 06, 2014 11:30 PM To: Xuxiaohu Cc: sfc@ietf.org Subject: Re: [sfc] New Version Notification for draft-merged-sfc-architectu= re-01.txt Hi Xiaohu, I understand what you are saying, but those individual I-Ds don't even targ= et SFC. >From an SFC Architecture document, we ought to align the editing of the arc= hitecture to the WG charter , which = says: "Generic SFC Encapsulation: ... service-level data plane encapsulatio= n format that: ... specifies the Service Function Path". That parses unambi= guously to me. Thanks, Carlos. On Aug 6, 2014, at 5:48 AM, Xuxiaohu > wrote: Hi Carlos, In the case where the service path selection role is realized by other mean= s than the service path information contained in the SFC header, such as th= ose approaches as defined in the following docs (http://tools.ietf.org/html= /draft-rfernando-l3vpn-service-chaining-04,http://tools.ietf.org/html/draft= -xu-spring-sfc-use-case-02), the SFC header just needs to accomplish the ro= le of metadata sharing. Best regards, Xiaohu 3. I think it' better to change the word "and" in the following sentence= to "and/or". In other word, the SFC encapsulation could play the role of S= FP selection, metadata sharing or both. In some cases where the SFP selecti= on role has been accomplished somewhere else (see 4.3.1. Transport Derived= SFF), the only possible role of the SFC encapsulation is metadata-sharing.= In some cases where no metadata is required to be shared, the only possibl= e role of the SFC encapsulation is SFP selection. " The SFC encapsulation enables service function path selection and the sharing of metadata/context information. Sorry I misunderstood where you were asking for the "and/or" to be inserted= on this comment. Section 4.1 clearly says: The SFC encapsulation provides explicit information used to identify the SFP. And that's, to me, the key issue we want to preserve on the SFC Encapsulati= on. If there is potential ambiguity in that first sentence, I'd suggest braking= it up in two: The SFC encapsulation enables service function path selection. It also e= nables the potential sharing of metadata and/or context information. Thanks, Carlos. 4. It seems that SF instance is a well understood term. Unfortunately, i= t has been removed. 5. s/SDC/SFC "Alternatively, a service provider may decide to exclude legacy service functions from an SDC domain. 6. s/SF functions/SFs according to the ordered set of SF functions Best regards, Xiaohu From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpig= nata) Sent: Monday, August 04, 2014 5:19 AM To: sfc@ietf.org Subject: [sfc] Fwd: New Version Notification for draft-merged-sfc-architect= ure-01.txt SFCers, After Toronto, Joel and I have been working on resolving the key open discu= ssion items, and incorporating all the input and feedback received thus int= o this document as the vehicle for a single SFC Architecture item to progre= ss. While we are still working on the document, we wanted to get a version out = early to the WG to test the resolution to key open items, see what we might= still be missing, and iterate. Please review and let us know. Thanks, Carlos & Joel. Begin forwarded message: From: > Subject: New Version Notification for draft-merged-sfc-architecture-01.txt Date: August 3, 2014 at 5:15:58 PM EDT To: Joel Halpern >, Carlos = Pignataro >, "Joel M. Halpern= " >, Carlos Pignataro > A new version of I-D, draft-merged-sfc-architecture-01.txt has been successfully submitted by Carlos Pignataro and posted to the IETF repository. Name: draft-merged-sfc-architecture Revision: 01 Title: Service Function Chaining (SFC) Architecture Document date: 2014-08-03 Group: Individual Submission Pages: 25 URL: http://www.ietf.org/internet-drafts/draft-merged-sfc-archit= ecture-01.txt Status: https://datatracker.ietf.org/doc/draft-merged-sfc-architect= ure/ Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-archite= cture-01 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 submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A3248NKGEML512MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi= Carlos and SFCers,

 

I = just noticed that the WG charter also says : “…The WG will exam= ine existing identifier schemes, if there is a need for such identifiers in= the context of the Generic SFC encapsulation, before defining any new identifier scheme.…” Hence, does it mean the = SFC approaches as defined in those individual I-Ds, especially the SPRING-b= ased SFC approach (http://www.ietf.org/proceedings/90/slides/slides-90-spri= ng-5.pdf), should be discussed in the SFC WG?

 

Be= st regards,

Xi= aohu

 = ;

From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.co= m]
Sent: Wednesday, August 06, 2014 11:30 PM
To: Xuxiaohu
Cc: sfc@ietf.org
Subject: Re: [sfc] New Version Notification for draft-merged-sfc-arc= hitecture-01.txt

 

Hi Xiaohu,

 

I understand what you are sayin= g, but those individual I-Ds don't even target SFC.

 

From an SFC Architecture docume= nt, we ought to align the editing of the architecture to the WG charter <= ;http://tools.ietf.org/wg= /sfc/charters>, which says: "Generic SFC Encapsulation: ... service-level data plane encapsulation format that:= ... specifies the Service Function Path". That parses unambiguou= sly to me.

 

Thanks,

 

Carlos.

 

On Aug 6, 2014, at 5:48 AM, Xux= iaohu <xuxiaohu@huawei.com>= ; wrote:



Hi Carlos,=

 

In the cas= e where the service path selection role is realized by other means than the= service path information contained in the SFC header, such as those approaches as defined in the following docs (http://tools.ietf.org/html/draft-rfernando-l3vpn-service-cha= ining-04,http://tools.ietf.org/html/dra= ft-xu-spring-sfc-use-case-02), the SFC header just needs to accomplish the role of metadata sharing.

 

Best regar= ds,

Xiaohu

 

3.    = I think it’ better to change the word “and” in the followi= ng sentence to “and/or”. In other word, the SFC encapsulation c= ould play the role of SFP selection, metadata sharing or both. In some case= s where the SFP selection role has been accomplished somewhere else (see 4.3.1.  Transport Derived SFF), the only possible role of the SFC encapsulation is metadata-= sharing. In some cases where no metadata is required to be shared, the only= possible role of the SFC encapsulation is SFP selection.

“   The SFC encapsulation enables service function path sel=
ection and the
   sharing of metadata/context infor=
mation.
 <=
/span>

 

Sorry I misunderstood where you= were asking for the "and/or" to be inserted on this comment.&nbs= p;

 

Section 4.1 clearly says:<= /o:p>

   The SFC encapsulat= ion provides explicit information used to identify

   the SFP.

 

And that's, to me, the key issu= e we want to preserve on the SFC Encapsulation.

 

If there is potential ambiguity= in that first sentence, I'd suggest braking it up in two:

 

   The SFC encapsulat= ion enables service function path selection. It also enables the=

   potential sharing = of metadata and/or context information.

 

Thanks,

 

Carlos.

 




4.    It seems that SF instance is a well understood term. Unfortunately, it has be= en removed.

 =

5.    s/SDC/SFC

 = 

“Alternatively, a service provider may decide to exclude legacy
   service functions from an SDC dom=
ain.
 <=
/span>

6.    s/SF functions/SFs

according to the ordered set of SF functions
 

Best regards,=

Xiaohu=

 =

 

From: sfc [mail= to:sfc-bounces@ietf.org]&n= bsp;On Behalf Of Carlos Pignataro (cpignata)
Sent: Monday, Augu= st 04, 2014 5:19 AM
To: sfc@ietf.org
Subject: [sfc] Fwd= : New Version Notification for draft-merged-sfc-architecture-01.txt<= span lang=3D"EN-US">

 

= SFCers,

= After Toronto, Joel and I have been working on resolving the key open discu= ssion items, and incorporating all the input and feedback received thu= s into this document as the vehicle for a single SFC Architecture item to progress.

While we are still working on the document, we wanted to get a version out = early to the WG to test the resolution to key open items, see what we = might still be missing, and iterate.

Please review and let us know.

Thanks,

Carlos & Joel.

Begin forwarded message:





Subject: New Version Notification fo= r draft-merged-sfc-architecture-01.txt=

Date: August 3, 2014 at 5:15:58 PM ED= T

To: Joel Halpern <jmh@joelhalpern.com>, Carlos Pignataro <cpignata@cisco.com>, "Joel M. Halpern"= ; <j= mh@joelhalpern.com>, Carlos Pignataro <cpignata@cisco.com>

 

=
A new version of I-D, draft-merged-sfc-architecture-01.txt
has been successfully submitted by Carlos Pignataro and posted to the
IETF repository.

Name: draft-merged-sfc-ar= chitecture
Revision: 01
Title: Service Function C= haining (SFC) Architecture
Document date: 2014-08-03=
Group: Individual Submiss= ion
Pages: 25
URL:            http://www.ietf.org/internet-drafts/draf= t-merged-sfc-architecture-01.txt
Status:         https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/<= /span>
Htmlized:       htt= p://tools.ietf.org/html/draft-merged-sfc-architecture-01
Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-= sfc-architecture-01

Abstract:
  This document describes an architecture for the specification,<= br>   creation, and ongoing maintenance of Service Function Chains (S= FC) in
  a network.  It includes architectural concepts, principles= , and
  components used in the construction of composite services throu= gh
  deployment of SFCs.  This document does not propose soluti= ons,
  protocols, or extensions to existing protocols.




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

The IETF Secretariat

 

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A3248NKGEML512MBSchi_-- From nobody Thu Aug 7 05:20: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 E5C171B29B8 for ; Thu, 7 Aug 2014 05:20:47 -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 1t5FlM05wqT3 for ; Thu, 7 Aug 2014 05:20:45 -0700 (PDT) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A77681B2966 for ; Thu, 7 Aug 2014 05:20:45 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id k15so3911804qaq.10 for ; Thu, 07 Aug 2014 05:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=szQkcgygvbckEfV/yagcbMTENKw8sh8MTfH+U84aBEM=; b=nuCxTAXYqM5GuFzZBZvo1fAbERZmbNNWOQc5ITKYxDMsmkFfkehSLJagpZPH4kZjIV joomew9SsXGcDzcnwHfxOxIxUQTl87iNYcGD9PZLs13wKvQGE14f27MVxakdL+svA2Cb WTdvY7kQyWxUjJmm5ZNQGliSJegDYEvHQ9h6ye+dadx6LIooaNkSqqoSs6mF5Ml5ldos bCqE2oTcV8+sovwRGNfwnVcQt8fVlZ2XjxJrslA5FiN41RiZzxxFDiWWcKGSuPihq1Ln 6fugEqZgiGT+MRP87F0RYuwJlcgD9iCOnAvHodVFETWW/LOLRCyGqqG2kXFjbgjC3u7G Weiw== X-Received: by 10.140.37.178 with SMTP id r47mr12378826qgr.59.1407414044976; Thu, 07 Aug 2014 05:20:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.16.22 with HTTP; Thu, 7 Aug 2014 05:20:24 -0700 (PDT) From: "Andrew G. Malis" Date: Thu, 7 Aug 2014 08:20:24 -0400 Message-ID: To: "Carlos Pignataro (cpignata)" , Joel Halpern Content-Type: multipart/alternative; boundary=001a11c1535233ebfd0500091e8d Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/IX_AHMy9DHcygujWeMknoLYeZ_k Cc: "sfc@ietf.org" Subject: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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, 07 Aug 2014 12:20:48 -0000 --001a11c1535233ebfd0500091e8d Content-Type: text/plain; charset=UTF-8 Carlos and Joel, In light of the previous discussions, I went back and re-read this current definition of SFC Encapsulation in the text (section 1.3): SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP identification, and is used by the SFC-aware functions, such as the SFF and SFC-aware SFs. The SFC Encapsulation is not used for network packet forwarding. In addition to SFP identification, the SFC encapsulation carries dataplane context information, also referred to as metadata. I think this could be tightened up to make simpler for the reader: SFC Encapsulation: A data plane encapsulation that identifies the SFP and/or provides metadata (data plane context information). The SFP Encapsulation is used by the SFC-aware functions, such as the SFF and SFC-aware SFs, and is not used for network packet forwarding. Thanks, Andy --001a11c1535233ebfd0500091e8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Carlos and Joel,

In light of the previo= us discussions, I went back and re-read this current definition of SFC Enca= psulation=C2=A0in the text (section 1.3):

=C2= =A0 =C2=A0SFC Encapsulation: =C2=A0The SFC Encapsulation provides at a mini= mum SFP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 identification, and is used by the SFC-awa= re functions, such as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the SFF and SFC= -aware SFs. =C2=A0The SFC Encapsulation is not used
=C2=A0 =C2=A0= =C2=A0 =C2=A0 for network packet forwarding. =C2=A0In addition to SFP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 identification, the SFC encapsulation carr= ies dataplane context
=C2=A0 =C2=A0 =C2=A0 =C2=A0 information, al= so referred to as metadata.

I think this cou= ld be tightened up to make simpler for the reader:

SFC Encapsulation: =C2=A0A data plane encapsulatio= n that identifies the SFP and/or provides metadata (data plane context info= rmation). The SFP Encapsulation is used by the SFC-aware functions, such as= the SFF and SFC-aware SFs, and is not used for network packet forwarding.<= /div>

Thanks,
Andy

--001a11c1535233ebfd0500091e8d-- From nobody Thu Aug 7 05:51: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 7465A1B29BC for ; Thu, 7 Aug 2014 05:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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.001, 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 qVEKFpsDLSP8 for ; Thu, 7 Aug 2014 05:51:33 -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 1A0FE1B29BB for ; Thu, 7 Aug 2014 05:51:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5466; q=dns/txt; s=iport; t=1407415885; x=1408625485; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=f1ha4+dblHjwXdC85yEMUY/CxhQKN7pJXOQg6WAFsXc=; b=fY9Wnp9oOQAGXpbdXTPgWtf2YXKjaxZyzkuKg5Xy+7ku3U9dCa39FePr ikisTKXA8PAInP+6+bZd6pT81Lr1bt+r/ITQgdL+6USynSw2/5bEF2i3f I3e3212zwVwl70doSL4/pEgHyCGFZDDX1xC+KRQmAviUP58gF4XRBA0eW c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFABR241OtJV2a/2dsb2JhbABagw2BKQTUGQGBDxZ3hAQBAQRnEhACAQgEDi0HIREUAw4CBA4FiC4DEb1hDYYZF40fgi0Hgy+BHAWOf4sSggeOQIYtg1dsgUY X-IronPort-AV: E=Sophos;i="5.01,818,1400025600"; d="scan'208,217";a="345776238" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 07 Aug 2014 12:51:09 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s77Cp8X6014094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Aug 2014 12:51:08 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.158]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Thu, 7 Aug 2014 07:51:07 -0500 From: "Carlos Pignataro (cpignata)" To: "Andrew G. Malis" Thread-Topic: Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt Thread-Index: AQHPsjoEpUaq91+aSUyfBy1ywE3Zo5vFa98A Date: Thu, 7 Aug 2014 12:51:07 +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: [10.117.115.60] Content-Type: multipart/alternative; boundary="_000_E114E9109A804C878F62C42855FE6600ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/kQCEVJySK6hGraJfoDqp3x6QMG8 Cc: "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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, 07 Aug 2014 12:51:35 -0000 --_000_E114E9109A804C878F62C42855FE6600ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you for going back and checking, Andy! Which specific part of the current definition do you believe is loose enoug= h to need tightening? I believe that your new proposal falls shorter than the existing text in a = few areas: * First, it combines two different functions (SFP identification and me= tadata/context information) into a single sentence. This opposes the change= we just made based on your preference in Section 4.1, which breaks the two= functions into two sentences, for reader clarity. While longer, it's simpl= er. * Second, it introduces an extraneous "and/or" that would change the me= aning, and negate the "at a minimum" existing bit. That would not be simpli= fying. * Third, there is no third but three bullets look better :-) Net-net, the original text, even when longer in character count, seems more= clear and simpler to the reader (because of the separated sentences), IMHO= . Thanks, Carlos. On Aug 7, 2014, at 8:20 AM, Andrew G. Malis > wrote: Carlos and Joel, In light of the previous discussions, I went back and re-read this current = definition of SFC Encapsulation in the text (section 1.3): SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP identification, and is used by the SFC-aware functions, such as the SFF and SFC-aware SFs. The SFC Encapsulation is not used for network packet forwarding. In addition to SFP identification, the SFC encapsulation carries dataplane context information, also referred to as metadata. I think this could be tightened up to make simpler for the reader: SFC Encapsulation: A data plane encapsulation that identifies the SFP and/= or provides metadata (data plane context information). The SFP Encapsulatio= n is used by the SFC-aware functions, such as the SFF and SFC-aware SFs, an= d is not used for network packet forwarding. Thanks, Andy --_000_E114E9109A804C878F62C42855FE6600ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0B5C7F959DF08A42A3F86E8D0F6CD3A1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Thank you for going back and checking, Andy!

Which specific part of the current definition do you believe is loose = enough to need tightening?

I believe that your new proposal falls shorter than the existing text = in a few areas:
  • First, it combines two different functions (SFP identification and meta= data/context information) into a single sentence. This opposes the cha= nge we just made based on your preference in Section 4.1, which breaks the = two functions into two sentences, for reader clarity. While longer, it's simpler.
  • Second, it introduces = an extraneous "and/or" that would change the meaning, and negate = the "at a minimum" existing bit. That would not be simplifying.
  • Third, there is no third but three bullets look better :-)

Net-net, the original text, even when longer in character count, seems= more clear and simpler to the reader (because of the separated sentences),= IMHO.

Thanks,

Carlos.

On Aug 7, 2014, at 8:20 AM, Andrew G. Malis <agmalis@gmail.com> wrote:

Carlos and Joel,

In light of the previous discussions, I went back and re-read this cur= rent definition of SFC Encapsulation in the text (section 1.3):

   SFC Encapsulation:  The SFC Encapsulation provides a= t a minimum SFP
        identification, and is used by the SFC-awa= re functions, such as
        the SFF and SFC-aware SFs.  The SFC E= ncapsulation is not used
        for network packet forwarding.  In ad= dition to SFP
        identification, the SFC encapsulation carr= ies dataplane context
        information, also referred to as metadata.=

I think this could be tightened up to make simpler for the reader:

SFC Encapsulation:  A data plane encapsulation that identifies th= e SFP and/or provides metadata (data plane context information). The SFP En= capsulation is used by the SFC-aware functions, such as the SFF and SFC-awa= re SFs, and is not used for network packet forwarding.

Thanks,
Andy


--_000_E114E9109A804C878F62C42855FE6600ciscocom_-- From nobody Thu Aug 7 06:06: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 3B9D21B29CD for ; Thu, 7 Aug 2014 06:06:30 -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 Rvffu-Xh_o44 for ; Thu, 7 Aug 2014 06:06:24 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CB5E1B299E for ; Thu, 7 Aug 2014 06:06:24 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id a108so4371940qge.30 for ; Thu, 07 Aug 2014 06: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=IslrABKI2ZGMalwTNIK+bMp1HgmUJg1gZ7r3eX/cyB8=; b=jPtWNwOv8ZHvv/UXnoDsAcc5kH75Cz6uf68LiIXLD0ysi+wZIhQzvPpR1xJRlq3aBP FCeFWkX2GgjzaF8kxsrLdRZ1czR4DYCW9q6zx2gG+NrsTDLDjhk+R4JGChQBBD9PcHM9 5C8yNGeYJbpIbYKrVwsVoR1FBdN9v8b3y4rXe1tvGMEMjxpTMj/T5ZnXTLshWOhh/qxe WUF9BNjGnpHd/CR5j0j/i6JaImo4ssCxel1Q+fQDuCimAwFSEuI7BMHLwWZyaTjS0SYI 6glwsquQw+cznyb8NATIU2Bolrtj28sldDbbpY4sdfUvZ9EEkqSY3K4sZ6YOn0ofyzon kyzg== X-Received: by 10.140.88.41 with SMTP id s38mr12602748qgd.73.1407416783465; Thu, 07 Aug 2014 06:06:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.16.22 with HTTP; Thu, 7 Aug 2014 06:06:03 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Thu, 7 Aug 2014 09:06:03 -0400 Message-ID: To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=001a11c13e7e6df0e3050009c1dd Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/XGZK9NV7TcufnokLsexXU21WBLo Cc: "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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, 07 Aug 2014 13:06:30 -0000 --001a11c13e7e6df0e3050009c1dd Content-Type: text/plain; charset=UTF-8 Carlos, When I re-read the definition, it seemed to me to be more of a string of thoughts than a concise definition, which is why I was trying to tighten it up. A definition is meant to be a short summary for quick reference, while the discussion in 4.1 goes into the more formal details. Otherwise, you would just repeat the entire section 4.1 in section 1.3. This is why it doesn't need to be in separate sentences. The "and/or" is because not every usage of the encapsulation will need both the SFP identification and the metadata, so the definition needs to concisely convey that. Cheers, Andy On Thu, Aug 7, 2014 at 8:51 AM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Thank you for going back and checking, Andy! > > Which specific part of the current definition do you believe is loose > enough to need tightening? > > I believe that your new proposal falls shorter than the existing text in > a few areas: > > - First, it combines two different functions (SFP identification and > metadata/context information) into a single sentence. This opposes the > change we just made based on your preference in Section 4.1, which breaks > the two functions into two sentences, for reader clarity. While longer, > it's simpler. > - Second, it introduces an extraneous "and/or" that would change the > meaning, and negate the "at a minimum" existing bit. That would not be > simplifying. > - Third, there is no third but three bullets look better :-) > > > Net-net, the original text, even when longer in character count, seems > more clear and simpler to the reader (because of the separated sentences), > IMHO. > > Thanks, > > Carlos. > > On Aug 7, 2014, at 8:20 AM, Andrew G. Malis wrote: > > Carlos and Joel, > > In light of the previous discussions, I went back and re-read this > current definition of SFC Encapsulation in the text (section 1.3): > > SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP > identification, and is used by the SFC-aware functions, such as > the SFF and SFC-aware SFs. The SFC Encapsulation is not used > for network packet forwarding. In addition to SFP > identification, the SFC encapsulation carries dataplane context > information, also referred to as metadata. > > I think this could be tightened up to make simpler for the reader: > > SFC Encapsulation: A data plane encapsulation that identifies the SFP > and/or provides metadata (data plane context information). The SFP > Encapsulation is used by the SFC-aware functions, such as the SFF and > SFC-aware SFs, and is not used for network packet forwarding. > > Thanks, > Andy > > > --001a11c13e7e6df0e3050009c1dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Carlos,

When I re-read the definition, = it seemed to me to be more of a string of thoughts than a concise definitio= n, which is why I was trying to tighten it up. A definition is meant to be = a short summary for quick reference, while the discussion in 4.1 goes into = the more formal details. =C2=A0Otherwise, you would just repeat the entire = section 4.1 in section 1.3. =C2=A0This is why it doesn't need to be in = separate sentences. The "and/or" is because not every usage of th= e encapsulation will need both the SFP identification and the metadata, so = the definition needs to concisely convey that.

Cheers,
Andy


On Thu, Aug 7, 2014 at 8:51 AM, Ca= rlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
Thank you for going back and checking, Andy!

Which specific part of the current definition do you believe is loose = enough to need tightening?

I believe that your new proposal falls shorter than the existing text = in a few areas:
  • First, it combines two different functions (SFP identification and meta= data/context information)=C2=A0into a single sentence. This opposes the cha= nge we just made based on your preference in Section 4.1, which breaks the = two functions into two sentences, for reader clarity. While longer, it's simpler.
  • Second, it introdu= ces an extraneous "and/or" that would change the meaning, and neg= ate the "at a minimum" existing bit. That would not be simplifyin= g.
  • Third, there is no third but three bullets look better :-)

Net-net, the original text, even when longer in character count, seems= more clear and simpler to the reader (because of the separated sentences),= IMHO.

Thanks,

Carlos.

On Aug 7, 2014, at 8:20 AM, Andrew G. Malis <agmalis@gmail.com> wrote:

Carlos and Joel,

In light of the previous discussions, I went back and re-read this cur= rent definition of SFC Encapsulation=C2=A0in the text (section 1.3):

=C2=A0 =C2=A0SFC Encapsulation: =C2=A0The SFC Encapsulation provides a= t a minimum SFP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 identification, and is used by the SFC-awa= re functions, such as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the SFF and SFC-aware SFs. =C2=A0The SFC E= ncapsulation is not used
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for network packet forwarding. =C2=A0In ad= dition to SFP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 identification, the SFC encapsulation carr= ies dataplane context
=C2=A0 =C2=A0 =C2=A0 =C2=A0 information, also referred to as metadata.=

I think this could be tightened up to make simpler for the reader:

SFC Encapsulation: =C2=A0A data plane encapsulation that identifies th= e SFP and/or provides metadata (data plane context information). The SFP En= capsulation is used by the SFC-aware functions, such as the SFF and SFC-awa= re SFs, and is not used for network packet forwarding.

Thanks,
Andy



--001a11c13e7e6df0e3050009c1dd-- From nobody Thu Aug 7 08:09: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 C010B1B2BDF for ; Thu, 7 Aug 2014 08:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 YlfeGsT4M2o4 for ; Thu, 7 Aug 2014 08:09:31 -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 5753E1B2B5F for ; Thu, 7 Aug 2014 08:09:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKZ62527; Thu, 07 Aug 2014 15:09:28 +0000 (GMT) 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, 7 Aug 2014 16:09:15 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm.china.huawei.com ([169.254.8.145]) with mapi id 14.03.0158.001; Thu, 7 Aug 2014 08:09:07 -0700 From: Lucy yong To: "Andrew G. Malis" , "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt Thread-Index: AQHPsj5c7YF9E5dD1UCUnQ2EPs/fnJvFkYqA//+rbKA= Date: Thu, 7 Aug 2014 15:09:06 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453C77D7@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.139.73] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D453C77D7dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/AYOb9eVphVkxkw9BKsCDOGuwAwc Cc: "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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, 07 Aug 2014 15:09:40 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D453C77D7dfweml701chmchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBsaWtlIHRoZSB0ZXh0IEFuZHkgcHJvcG9zZWQgZm9yIFNGQyBlbmNhcHN1bGF0aW9uIGRlZmlu aXRpb24uIEl0IGlzIGNvbmNpc2UgYW5kIGNsZWFyLg0KTHVjeQ0KDQpGcm9tOiBzZmMgW21haWx0 bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHJldyBHLiBNYWxpcw0KU2Vu dDogVGh1cnNkYXksIEF1Z3VzdCAwNywgMjAxNCA4OjA2IEFNDQpUbzogQ2FybG9zIFBpZ25hdGFy byAoY3BpZ25hdGEpDQpDYzogSm9lbCBNLiBIYWxwZXJuOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbc2ZjXSBEZWZpbml0aW9uIG9mIFNGQyBFbmNhcHN1bGF0aW9uIGluIGRyYWZ0LW1lcmdl ZC1zZmMtYXJjaGl0ZWN0dXJlLTAxLnR4dA0KDQpDYXJsb3MsDQoNCldoZW4gSSByZS1yZWFkIHRo ZSBkZWZpbml0aW9uLCBpdCBzZWVtZWQgdG8gbWUgdG8gYmUgbW9yZSBvZiBhIHN0cmluZyBvZiB0 aG91Z2h0cyB0aGFuIGEgY29uY2lzZSBkZWZpbml0aW9uLCB3aGljaCBpcyB3aHkgSSB3YXMgdHJ5 aW5nIHRvIHRpZ2h0ZW4gaXQgdXAuIEEgZGVmaW5pdGlvbiBpcyBtZWFudCB0byBiZSBhIHNob3J0 IHN1bW1hcnkgZm9yIHF1aWNrIHJlZmVyZW5jZSwgd2hpbGUgdGhlIGRpc2N1c3Npb24gaW4gNC4x IGdvZXMgaW50byB0aGUgbW9yZSBmb3JtYWwgZGV0YWlscy4gIE90aGVyd2lzZSwgeW91IHdvdWxk IGp1c3QgcmVwZWF0IHRoZSBlbnRpcmUgc2VjdGlvbiA0LjEgaW4gc2VjdGlvbiAxLjMuICBUaGlz IGlzIHdoeSBpdCBkb2Vzbid0IG5lZWQgdG8gYmUgaW4gc2VwYXJhdGUgc2VudGVuY2VzLiBUaGUg ImFuZC9vciIgaXMgYmVjYXVzZSBub3QgZXZlcnkgdXNhZ2Ugb2YgdGhlIGVuY2Fwc3VsYXRpb24g d2lsbCBuZWVkIGJvdGggdGhlIFNGUCBpZGVudGlmaWNhdGlvbiBhbmQgdGhlIG1ldGFkYXRhLCBz byB0aGUgZGVmaW5pdGlvbiBuZWVkcyB0byBjb25jaXNlbHkgY29udmV5IHRoYXQuDQoNCkNoZWVy cywNCkFuZHkNCg0KT24gVGh1LCBBdWcgNywgMjAxNCBhdCA4OjUxIEFNLCBDYXJsb3MgUGlnbmF0 YXJvIChjcGlnbmF0YSkgPGNwaWduYXRhQGNpc2NvLmNvbTxtYWlsdG86Y3BpZ25hdGFAY2lzY28u Y29tPj4gd3JvdGU6DQpUaGFuayB5b3UgZm9yIGdvaW5nIGJhY2sgYW5kIGNoZWNraW5nLCBBbmR5 IQ0KDQpXaGljaCBzcGVjaWZpYyBwYXJ0IG9mIHRoZSBjdXJyZW50IGRlZmluaXRpb24gZG8geW91 IGJlbGlldmUgaXMgbG9vc2UgZW5vdWdoIHRvIG5lZWQgdGlnaHRlbmluZz8NCg0KSSBiZWxpZXZl IHRoYXQgeW91ciBuZXcgcHJvcG9zYWwgZmFsbHMgc2hvcnRlciB0aGFuIHRoZSBleGlzdGluZyB0 ZXh0IGluIGEgZmV3IGFyZWFzOg0KDQogICogICBGaXJzdCwgaXQgY29tYmluZXMgdHdvIGRpZmZl cmVudCBmdW5jdGlvbnMgKFNGUCBpZGVudGlmaWNhdGlvbiBhbmQgbWV0YWRhdGEvY29udGV4dCBp bmZvcm1hdGlvbikgaW50byBhIHNpbmdsZSBzZW50ZW5jZS4gVGhpcyBvcHBvc2VzIHRoZSBjaGFu Z2Ugd2UganVzdCBtYWRlIGJhc2VkIG9uIHlvdXIgcHJlZmVyZW5jZSBpbiBTZWN0aW9uIDQuMSwg d2hpY2ggYnJlYWtzIHRoZSB0d28gZnVuY3Rpb25zIGludG8gdHdvIHNlbnRlbmNlcywgZm9yIHJl YWRlciBjbGFyaXR5LiBXaGlsZSBsb25nZXIsIGl0J3Mgc2ltcGxlci4NCiAgKiAgIFNlY29uZCwg aXQgaW50cm9kdWNlcyBhbiBleHRyYW5lb3VzICJhbmQvb3IiIHRoYXQgd291bGQgY2hhbmdlIHRo ZSBtZWFuaW5nLCBhbmQgbmVnYXRlIHRoZSAiYXQgYSBtaW5pbXVtIiBleGlzdGluZyBiaXQuIFRo YXQgd291bGQgbm90IGJlIHNpbXBsaWZ5aW5nLg0KICAqICAgVGhpcmQsIHRoZXJlIGlzIG5vIHRo aXJkIGJ1dCB0aHJlZSBidWxsZXRzIGxvb2sgYmV0dGVyIDotKQ0KDQpOZXQtbmV0LCB0aGUgb3Jp Z2luYWwgdGV4dCwgZXZlbiB3aGVuIGxvbmdlciBpbiBjaGFyYWN0ZXIgY291bnQsIHNlZW1zIG1v cmUgY2xlYXIgYW5kIHNpbXBsZXIgdG8gdGhlIHJlYWRlciAoYmVjYXVzZSBvZiB0aGUgc2VwYXJh dGVkIHNlbnRlbmNlcyksIElNSE8uDQoNClRoYW5rcywNCg0KQ2FybG9zLg0KDQpPbiBBdWcgNywg MjAxNCwgYXQgODoyMCBBTSwgQW5kcmV3IEcuIE1hbGlzIDxhZ21hbGlzQGdtYWlsLmNvbTxtYWls dG86YWdtYWxpc0BnbWFpbC5jb20+PiB3cm90ZToNCg0KDQpDYXJsb3MgYW5kIEpvZWwsDQoNCklu IGxpZ2h0IG9mIHRoZSBwcmV2aW91cyBkaXNjdXNzaW9ucywgSSB3ZW50IGJhY2sgYW5kIHJlLXJl YWQgdGhpcyBjdXJyZW50IGRlZmluaXRpb24gb2YgU0ZDIEVuY2Fwc3VsYXRpb24gaW4gdGhlIHRl eHQgKHNlY3Rpb24gMS4zKToNCg0KICAgU0ZDIEVuY2Fwc3VsYXRpb246ICBUaGUgU0ZDIEVuY2Fw c3VsYXRpb24gcHJvdmlkZXMgYXQgYSBtaW5pbXVtIFNGUA0KICAgICAgICBpZGVudGlmaWNhdGlv biwgYW5kIGlzIHVzZWQgYnkgdGhlIFNGQy1hd2FyZSBmdW5jdGlvbnMsIHN1Y2ggYXMNCiAgICAg ICAgdGhlIFNGRiBhbmQgU0ZDLWF3YXJlIFNGcy4gIFRoZSBTRkMgRW5jYXBzdWxhdGlvbiBpcyBu b3QgdXNlZA0KICAgICAgICBmb3IgbmV0d29yayBwYWNrZXQgZm9yd2FyZGluZy4gIEluIGFkZGl0 aW9uIHRvIFNGUA0KICAgICAgICBpZGVudGlmaWNhdGlvbiwgdGhlIFNGQyBlbmNhcHN1bGF0aW9u IGNhcnJpZXMgZGF0YXBsYW5lIGNvbnRleHQNCiAgICAgICAgaW5mb3JtYXRpb24sIGFsc28gcmVm ZXJyZWQgdG8gYXMgbWV0YWRhdGEuDQoNCkkgdGhpbmsgdGhpcyBjb3VsZCBiZSB0aWdodGVuZWQg dXAgdG8gbWFrZSBzaW1wbGVyIGZvciB0aGUgcmVhZGVyOg0KDQpTRkMgRW5jYXBzdWxhdGlvbjog IEEgZGF0YSBwbGFuZSBlbmNhcHN1bGF0aW9uIHRoYXQgaWRlbnRpZmllcyB0aGUgU0ZQIGFuZC9v ciBwcm92aWRlcyBtZXRhZGF0YSAoZGF0YSBwbGFuZSBjb250ZXh0IGluZm9ybWF0aW9uKS4gVGhl IFNGUCBFbmNhcHN1bGF0aW9uIGlzIHVzZWQgYnkgdGhlIFNGQy1hd2FyZSBmdW5jdGlvbnMsIHN1 Y2ggYXMgdGhlIFNGRiBhbmQgU0ZDLWF3YXJlIFNGcywgYW5kIGlzIG5vdCB1c2VkIGZvciBuZXR3 b3JrIHBhY2tldCBmb3J3YXJkaW5nLg0KDQpUaGFua3MsDQpBbmR5DQoNCg0KDQo= --_000_2691CE0099834E4A9C5044EEC662BB9D453C77D7dfweml701chmchi_ 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 bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGww DQoJe21zby1saXN0LWlkOjMxODUxODc1Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTI1MjQ5 OTcyMDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdp bi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBsaWtlIHRoZSB0ZXh0IEFuZHkgcHJvcG9zZWQgZm9y IFNGQyBlbmNhcHN1bGF0aW9uIGRlZmluaXRpb24uIEl0IGlzIGNvbmNpc2UgYW5kIGNsZWFyLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MdWN5PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzZmMgW21haWx0 bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QW5kcmV3IEcuIE1h bGlzPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBdWd1c3QgMDcsIDIwMTQgODowNiBBTTxi cj4NCjxiPlRvOjwvYj4gQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpPGJyPg0KPGI+Q2M6PC9i PiBKb2VsIE0uIEhhbHBlcm47IHNmY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W3NmY10gRGVmaW5pdGlvbiBvZiBTRkMgRW5jYXBzdWxhdGlvbiBpbiBkcmFmdC1tZXJnZWQtc2Zj LWFyY2hpdGVjdHVyZS0wMS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkNhcmxvcyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPldoZW4gSSByZS1yZWFkIHRoZSBkZWZpbml0aW9uLCBpdCBzZWVtZWQgdG8gbWUgdG8g YmUgbW9yZSBvZiBhIHN0cmluZyBvZiB0aG91Z2h0cyB0aGFuIGEgY29uY2lzZSBkZWZpbml0aW9u LCB3aGljaCBpcyB3aHkgSSB3YXMgdHJ5aW5nIHRvIHRpZ2h0ZW4gaXQgdXAuIEEgZGVmaW5pdGlv biBpcyBtZWFudCB0byBiZSBhIHNob3J0IHN1bW1hcnkgZm9yIHF1aWNrIHJlZmVyZW5jZSwgd2hp bGUgdGhlIGRpc2N1c3Npb24NCiBpbiA0LjEgZ29lcyBpbnRvIHRoZSBtb3JlIGZvcm1hbCBkZXRh aWxzLiAmbmJzcDtPdGhlcndpc2UsIHlvdSB3b3VsZCBqdXN0IHJlcGVhdCB0aGUgZW50aXJlIHNl Y3Rpb24gNC4xIGluIHNlY3Rpb24gMS4zLiAmbmJzcDtUaGlzIGlzIHdoeSBpdCBkb2Vzbid0IG5l ZWQgdG8gYmUgaW4gc2VwYXJhdGUgc2VudGVuY2VzLiBUaGUgJnF1b3Q7YW5kL29yJnF1b3Q7IGlz IGJlY2F1c2Ugbm90IGV2ZXJ5IHVzYWdlIG9mIHRoZSBlbmNhcHN1bGF0aW9uIHdpbGwgbmVlZCBi b3RoIHRoZSBTRlANCiBpZGVudGlmaWNhdGlvbiBhbmQgdGhlIG1ldGFkYXRhLCBzbyB0aGUgZGVm aW5pdGlvbiBuZWVkcyB0byBjb25jaXNlbHkgY29udmV5IHRoYXQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBUaHUsIEF1ZyA3LCAyMDE0IGF0IDg6NTEgQU0sIENhcmxvcyBQaWdu YXRhcm8gKGNwaWduYXRhKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmNwaWduYXRhQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rIHlvdSBmb3IgZ29pbmcg YmFjayBhbmQgY2hlY2tpbmcsIEFuZHkhIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+V2hpY2ggc3BlY2lmaWMgcGFydCBvZiB0aGUgY3VycmVudCBkZWZpbml0 aW9uIGRvIHlvdSBiZWxpZXZlIGlzIGxvb3NlIGVub3VnaCB0byBuZWVkIHRpZ2h0ZW5pbmc/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYmVs aWV2ZSB0aGF0IHlvdXIgbmV3IHByb3Bvc2FsIGZhbGxzIHNob3J0ZXIgdGhhbiB0aGUgZXhpc3Rp bmcgdGV4dCBpbiBhIGZldyBhcmVhczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjx1 bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPg0KRmlyc3QsIGl0IGNvbWJpbmVzIHR3byBkaWZmZXJlbnQgZnVuY3Rpb25zIChTRlAg aWRlbnRpZmljYXRpb24gYW5kIG1ldGFkYXRhL2NvbnRleHQgaW5mb3JtYXRpb24pJm5ic3A7aW50 byBhIHNpbmdsZSBzZW50ZW5jZS4gVGhpcyBvcHBvc2VzIHRoZSBjaGFuZ2Ugd2UganVzdCBtYWRl IGJhc2VkIG9uIHlvdXIgcHJlZmVyZW5jZSBpbiBTZWN0aW9uIDQuMSwgd2hpY2ggYnJlYWtzIHRo ZSB0d28gZnVuY3Rpb25zIGludG8gdHdvIHNlbnRlbmNlcywgZm9yIHJlYWRlcg0KIGNsYXJpdHku IFdoaWxlIGxvbmdlciwgaXQncyBzaW1wbGVyLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClNlY29uZCwgaXQgaW50cm9kdWNl cyBhbiBleHRyYW5lb3VzICZxdW90O2FuZC9vciZxdW90OyB0aGF0IHdvdWxkIGNoYW5nZSB0aGUg bWVhbmluZywgYW5kIG5lZ2F0ZSB0aGUgJnF1b3Q7YXQgYSBtaW5pbXVtJnF1b3Q7IGV4aXN0aW5n IGJpdC4gVGhhdCB3b3VsZCBub3QgYmUgc2ltcGxpZnlpbmcuPG86cD48L286cD48L2xpPjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KVGhpcmQsIHRoZXJl IGlzIG5vIHRoaXJkIGJ1dCB0aHJlZSBidWxsZXRzIGxvb2sgYmV0dGVyIDotKTxvOnA+PC9vOnA+ PC9saT48L3VsPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OZXQtbmV0 LCB0aGUgb3JpZ2luYWwgdGV4dCwgZXZlbiB3aGVuIGxvbmdlciBpbiBjaGFyYWN0ZXIgY291bnQs IHNlZW1zIG1vcmUgY2xlYXIgYW5kIHNpbXBsZXIgdG8gdGhlIHJlYWRlciAoYmVjYXVzZSBvZiB0 aGUgc2VwYXJhdGVkIHNlbnRlbmNlcyksIElNSE8uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2FybG9zLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gQXVn IDcsIDIwMTQsIGF0IDg6MjAgQU0sIEFuZHJldyBHLiBNYWxpcyAmbHQ7PGEgaHJlZj0ibWFpbHRv OmFnbWFsaXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWdtYWxpc0BnbWFpbC5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Q2FybG9zIGFuZCBKb2VsLCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkluIGxpZ2h0IG9mIHRoZSBwcmV2aW91cyBkaXNjdXNzaW9ucywgSSB3ZW50IGJhY2sg YW5kIHJlLXJlYWQgdGhpcyBjdXJyZW50IGRlZmluaXRpb24gb2YgU0ZDIEVuY2Fwc3VsYXRpb24m bmJzcDtpbiB0aGUgdGV4dCAoc2VjdGlvbiAxLjMpOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO1NGQyBFbmNh cHN1bGF0aW9uOiAmbmJzcDtUaGUgU0ZDIEVuY2Fwc3VsYXRpb24gcHJvdmlkZXMgYXQgYSBtaW5p bXVtIFNGUDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGlkZW50aWZpY2F0aW9uLCBhbmQgaXMgdXNl ZCBieSB0aGUgU0ZDLWF3YXJlIGZ1bmN0aW9ucywgc3VjaCBhczxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IHRoZSBTRkYgYW5kIFNGQy1hd2FyZSBTRnMuICZuYnNwO1RoZSBTRkMgRW5jYXBzdWxhdGlv biBpcyBub3QgdXNlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGZvciBuZXR3b3JrIHBhY2tldCBm b3J3YXJkaW5nLiAmbmJzcDtJbiBhZGRpdGlvbiB0byBTRlA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBpZGVudGlmaWNhdGlvbiwgdGhlIFNGQyBlbmNhcHN1bGF0aW9uIGNhcnJpZXMgZGF0YXBsYW5l IGNvbnRleHQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpbmZvcm1hdGlvbiwgYWxzbyByZWZlcnJl ZCB0byBhcyBtZXRhZGF0YS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoaXMgY291bGQgYmUgdGlnaHRlbmVkIHVw IHRvIG1ha2Ugc2ltcGxlciBmb3IgdGhlIHJlYWRlcjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNGQyBFbmNhcHN1bGF0aW9uOiAm bmJzcDtBIGRhdGEgcGxhbmUgZW5jYXBzdWxhdGlvbiB0aGF0IGlkZW50aWZpZXMgdGhlIFNGUCBh bmQvb3IgcHJvdmlkZXMgbWV0YWRhdGEgKGRhdGEgcGxhbmUgY29udGV4dCBpbmZvcm1hdGlvbiku IFRoZSBTRlAgRW5jYXBzdWxhdGlvbiBpcyB1c2VkIGJ5IHRoZSBTRkMtYXdhcmUgZnVuY3Rpb25z LCBzdWNoIGFzIHRoZSBTRkYgYW5kIFNGQy1hd2FyZSBTRnMsIGFuZCBpcyBub3QgdXNlZA0KIGZv ciBuZXR3b3JrIHBhY2tldCBmb3J3YXJkaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_2691CE0099834E4A9C5044EEC662BB9D453C77D7dfweml701chmchi_-- From nobody Thu Aug 7 18:13: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 DE1E81A0A74 for ; Thu, 7 Aug 2014 18:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 QS1u4_JYFh56 for ; Thu, 7 Aug 2014 18:13:30 -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 D84261A0535 for ; Thu, 7 Aug 2014 18:13:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIA38980; Fri, 08 Aug 2014 01:13:28 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Aug 2014 02:13:27 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.204]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 8 Aug 2014 09:13:23 +0800 From: Xuxiaohu To: "Andrew G. Malis" , "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt Thread-Index: AQHPsj5Zo8zwYtoiUEi/TNVKSSoPaJvElhWAgAFOlbA= Date: Fri, 8 Aug 2014 01:13:23 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A4805@NKGEML512-MBS.china.huawei.com> References: 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.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/jki7Xdz4Ipo2S4bsM4c9RoFl-Ms Cc: "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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, 08 Aug 2014 01:13:33 -0000 SSBmdWxseSBhZ3JlZSB3aXRoIEFuZHnigJlzIHBvaW50IHRoYXQgbm90IGV2ZXJ5IHVzYWdlIG9m IHRoZSBlbmNhcHN1bGF0aW9uIHdpbGwgbmVlZCBib3RoIHRoZSBTRlAgaWRlbnRpZmljYXRpb24g YW5kIHRoZSBtZXRhZGF0YS4gSXTigJlzIGJldHRlciB0aGF0IHRoZSBTRkMgZW5jYXBzdWxhdGlv biBjb3VsZCBiZSBmbGV4aWJseSB1c2VkIGZvciBjYXJyeWluZyBTRlAgaWRlbnRpZmljYXRpb24s IG1ldGFkYXRhIG9yIGJvdGguIE90aGVyd2lzZSwgaXQgc2VlbXMgdGhhdCB0aG9zZSBTRkMgYXBw cm9hY2hlcyB3aGljaCBkb27igJl0IHVzZSB0aGUgU0ZDIGVuY2Fwc3VsYXRpb24gZm9yIFNGQyBz ZWxlY3Rpb24gd291bGQgaGF2ZSB0byBzZXBhcmF0ZWx5IGRlZmluZSB0aGUgd2F5IG9mIGNhcnJ5 aW5nIG1ldGFkYXRhLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUgDQoNCkZyb206IHNmYyBbbWFp bHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQW5kcmV3IEcuIE1hbGlzDQpT ZW50OiBUaHVyc2RheSwgQXVndXN0IDA3LCAyMDE0IDk6MDYgUE0NClRvOiBDYXJsb3MgUGlnbmF0 YXJvIChjcGlnbmF0YSkNCkNjOiBKb2VsIE0uIEhhbHBlcm47IHNmY0BpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtzZmNdIERlZmluaXRpb24gb2YgU0ZDIEVuY2Fwc3VsYXRpb24gaW4gZHJhZnQtbWVy Z2VkLXNmYy1hcmNoaXRlY3R1cmUtMDEudHh0DQoNCkNhcmxvcywNCg0KV2hlbiBJIHJlLXJlYWQg dGhlIGRlZmluaXRpb24sIGl0IHNlZW1lZCB0byBtZSB0byBiZSBtb3JlIG9mIGEgc3RyaW5nIG9m IHRob3VnaHRzIHRoYW4gYSBjb25jaXNlIGRlZmluaXRpb24sIHdoaWNoIGlzIHdoeSBJIHdhcyB0 cnlpbmcgdG8gdGlnaHRlbiBpdCB1cC4gQSBkZWZpbml0aW9uIGlzIG1lYW50IHRvIGJlIGEgc2hv cnQgc3VtbWFyeSBmb3IgcXVpY2sgcmVmZXJlbmNlLCB3aGlsZSB0aGUgZGlzY3Vzc2lvbiBpbiA0 LjEgZ29lcyBpbnRvIHRoZSBtb3JlIGZvcm1hbCBkZXRhaWxzLiDCoE90aGVyd2lzZSwgeW91IHdv dWxkIGp1c3QgcmVwZWF0IHRoZSBlbnRpcmUgc2VjdGlvbiA0LjEgaW4gc2VjdGlvbiAxLjMuIMKg VGhpcyBpcyB3aHkgaXQgZG9lc24ndCBuZWVkIHRvIGJlIGluIHNlcGFyYXRlIHNlbnRlbmNlcy4g VGhlICJhbmQvb3IiIGlzIGJlY2F1c2Ugbm90IGV2ZXJ5IHVzYWdlIG9mIHRoZSBlbmNhcHN1bGF0 aW9uIHdpbGwgbmVlZCBib3RoIHRoZSBTRlAgaWRlbnRpZmljYXRpb24gYW5kIHRoZSBtZXRhZGF0 YSwgc28gdGhlIGRlZmluaXRpb24gbmVlZHMgdG8gY29uY2lzZWx5IGNvbnZleSB0aGF0Lg0KDQpD aGVlcnMsDQpBbmR5DQoNCk9uIFRodSwgQXVnIDcsIDIwMTQgYXQgODo1MSBBTSwgQ2FybG9zIFBp Z25hdGFybyAoY3BpZ25hdGEpIDxjcGlnbmF0YUBjaXNjby5jb20+IHdyb3RlOg0KVGhhbmsgeW91 IGZvciBnb2luZyBiYWNrIGFuZCBjaGVja2luZywgQW5keSEgDQoNCldoaWNoIHNwZWNpZmljIHBh cnQgb2YgdGhlIGN1cnJlbnQgZGVmaW5pdGlvbiBkbyB5b3UgYmVsaWV2ZSBpcyBsb29zZSBlbm91 Z2ggdG8gbmVlZCB0aWdodGVuaW5nPw0KDQpJIGJlbGlldmUgdGhhdCB5b3VyIG5ldyBwcm9wb3Nh bCBmYWxscyBzaG9ydGVyIHRoYW4gdGhlIGV4aXN0aW5nIHRleHQgaW4gYSBmZXcgYXJlYXM6DQri gKIgRmlyc3QsIGl0IGNvbWJpbmVzIHR3byBkaWZmZXJlbnQgZnVuY3Rpb25zIChTRlAgaWRlbnRp ZmljYXRpb24gYW5kIG1ldGFkYXRhL2NvbnRleHQgaW5mb3JtYXRpb24pwqBpbnRvIGEgc2luZ2xl IHNlbnRlbmNlLiBUaGlzIG9wcG9zZXMgdGhlIGNoYW5nZSB3ZSBqdXN0IG1hZGUgYmFzZWQgb24g eW91ciBwcmVmZXJlbmNlIGluIFNlY3Rpb24gNC4xLCB3aGljaCBicmVha3MgdGhlIHR3byBmdW5j dGlvbnMgaW50byB0d28gc2VudGVuY2VzLCBmb3IgcmVhZGVyIGNsYXJpdHkuIFdoaWxlIGxvbmdl ciwgaXQncyBzaW1wbGVyLg0K4oCiIFNlY29uZCwgaXQgaW50cm9kdWNlcyBhbiBleHRyYW5lb3Vz ICJhbmQvb3IiIHRoYXQgd291bGQgY2hhbmdlIHRoZSBtZWFuaW5nLCBhbmQgbmVnYXRlIHRoZSAi YXQgYSBtaW5pbXVtIiBleGlzdGluZyBiaXQuIFRoYXQgd291bGQgbm90IGJlIHNpbXBsaWZ5aW5n Lg0K4oCiIFRoaXJkLCB0aGVyZSBpcyBubyB0aGlyZCBidXQgdGhyZWUgYnVsbGV0cyBsb29rIGJl dHRlciA6LSkNCg0KTmV0LW5ldCwgdGhlIG9yaWdpbmFsIHRleHQsIGV2ZW4gd2hlbiBsb25nZXIg aW4gY2hhcmFjdGVyIGNvdW50LCBzZWVtcyBtb3JlIGNsZWFyIGFuZCBzaW1wbGVyIHRvIHRoZSBy ZWFkZXIgKGJlY2F1c2Ugb2YgdGhlIHNlcGFyYXRlZCBzZW50ZW5jZXMpLCBJTUhPLg0KDQpUaGFu a3MsDQoNCkNhcmxvcy4NCg0KT24gQXVnIDcsIDIwMTQsIGF0IDg6MjAgQU0sIEFuZHJldyBHLiBN YWxpcyA8YWdtYWxpc0BnbWFpbC5jb20+IHdyb3RlOg0KDQoNCkNhcmxvcyBhbmQgSm9lbCwgDQoN CkluIGxpZ2h0IG9mIHRoZSBwcmV2aW91cyBkaXNjdXNzaW9ucywgSSB3ZW50IGJhY2sgYW5kIHJl LXJlYWQgdGhpcyBjdXJyZW50IGRlZmluaXRpb24gb2YgU0ZDIEVuY2Fwc3VsYXRpb27CoGluIHRo ZSB0ZXh0IChzZWN0aW9uIDEuMyk6DQoNCsKgIMKgU0ZDIEVuY2Fwc3VsYXRpb246IMKgVGhlIFNG QyBFbmNhcHN1bGF0aW9uIHByb3ZpZGVzIGF0IGEgbWluaW11bSBTRlANCsKgIMKgIMKgIMKgIGlk ZW50aWZpY2F0aW9uLCBhbmQgaXMgdXNlZCBieSB0aGUgU0ZDLWF3YXJlIGZ1bmN0aW9ucywgc3Vj aCBhcw0KwqAgwqAgwqAgwqAgdGhlIFNGRiBhbmQgU0ZDLWF3YXJlIFNGcy4gwqBUaGUgU0ZDIEVu Y2Fwc3VsYXRpb24gaXMgbm90IHVzZWQNCsKgIMKgIMKgIMKgIGZvciBuZXR3b3JrIHBhY2tldCBm b3J3YXJkaW5nLiDCoEluIGFkZGl0aW9uIHRvIFNGUA0KwqAgwqAgwqAgwqAgaWRlbnRpZmljYXRp b24sIHRoZSBTRkMgZW5jYXBzdWxhdGlvbiBjYXJyaWVzIGRhdGFwbGFuZSBjb250ZXh0DQrCoCDC oCDCoCDCoCBpbmZvcm1hdGlvbiwgYWxzbyByZWZlcnJlZCB0byBhcyBtZXRhZGF0YS4NCg0KSSB0 aGluayB0aGlzIGNvdWxkIGJlIHRpZ2h0ZW5lZCB1cCB0byBtYWtlIHNpbXBsZXIgZm9yIHRoZSBy ZWFkZXI6DQoNClNGQyBFbmNhcHN1bGF0aW9uOiDCoEEgZGF0YSBwbGFuZSBlbmNhcHN1bGF0aW9u IHRoYXQgaWRlbnRpZmllcyB0aGUgU0ZQIGFuZC9vciBwcm92aWRlcyBtZXRhZGF0YSAoZGF0YSBw bGFuZSBjb250ZXh0IGluZm9ybWF0aW9uKS4gVGhlIFNGUCBFbmNhcHN1bGF0aW9uIGlzIHVzZWQg YnkgdGhlIFNGQy1hd2FyZSBmdW5jdGlvbnMsIHN1Y2ggYXMgdGhlIFNGRiBhbmQgU0ZDLWF3YXJl IFNGcywgYW5kIGlzIG5vdCB1c2VkIGZvciBuZXR3b3JrIHBhY2tldCBmb3J3YXJkaW5nLg0KDQpU aGFua3MsDQpBbmR5DQoNCg0KDQo= From nobody Fri Aug 8 05:53: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 778FC1B2B5E for ; Fri, 8 Aug 2014 05:53:07 -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, RP_MATCHES_RCVD=-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 wRqFCVD-yfMG for ; Fri, 8 Aug 2014 05:53:05 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D1EE1B2ACE for ; Fri, 8 Aug 2014 05:53:05 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id D86CE963B5AC; Fri, 8 Aug 2014 12:53:01 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s78Cr17p027961 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Aug 2014 08:53:02 -0400 Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.186]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Fri, 8 Aug 2014 08:53:02 -0400 From: "Dolganow, Andrew (Andrew)" To: "Andrew G. Malis" Thread-Topic: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt Thread-Index: AQHPsj5kT1+rEDp5KkG/JCAtv4QdD5vFX0CAgADLNoCAAIBskw== Date: Fri, 8 Aug 2014 12:53:01 +0000 Message-ID: <57B2ECF6-8DB4-4E23-BB14-E030EB74E09C@alcatel-lucent.com> References: , <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A4805@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A4805@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/TIKTJvvfdNOzg94hlRTI2MjQ_DU Cc: "Carlos Pignataro \(cpignata\)" , Xuxiaohu , "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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, 08 Aug 2014 12:53:07 -0000 I agree that we should have stronger separation of two functions: SFP and m= etadata.=20 How about small edit to what Andy proposed: SFC Encapsulation: A data plane encapsulation that encodes either one or b= oth of - the SFP=20 - metadata (data plane context information).=20 > The SFP Encapsulation is used by the SFC-aware functions, such as the SFF= and SFC-aware SFs, and is not used for network packet forwarding. Andrew Sent from my iPhone > On Aug 7, 2014, at 9:13 PM, "Xuxiaohu" wrote: >=20 > I fully agree with Andy=92s point that not every usage of the encapsulati= on will need both the SFP identification and the metadata. It=92s better th= at the SFC encapsulation could be flexibly used for carrying SFP identifica= tion, metadata or both. Otherwise, it seems that those SFC approaches which= don=92t use the SFC encapsulation for SFC selection would have to separate= ly define the way of carrying metadata. >=20 > Best regards, > Xiaohu=20 >=20 > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Andrew G. Malis > Sent: Thursday, August 07, 2014 9:06 PM > To: Carlos Pignataro (cpignata) > Cc: Joel M. Halpern; sfc@ietf.org > Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-ar= chitecture-01.txt >=20 > Carlos, >=20 > When I re-read the definition, it seemed to me to be more of a string of = thoughts than a concise definition, which is why I was trying to tighten it= up. A definition is meant to be a short summary for quick reference, while= the discussion in 4.1 goes into the more formal details. Otherwise, you w= ould just repeat the entire section 4.1 in section 1.3. This is why it doe= sn't need to be in separate sentences. The "and/or" is because not every us= age of the encapsulation will need both the SFP identification and the meta= data, so the definition needs to concisely convey that. >=20 > Cheers, > Andy >=20 > On Thu, Aug 7, 2014 at 8:51 AM, Carlos Pignataro (cpignata) wrote: > Thank you for going back and checking, Andy!=20 >=20 > Which specific part of the current definition do you believe is loose eno= ugh to need tightening? >=20 > I believe that your new proposal falls shorter than the existing text in = a few areas: > =95 First, it combines two different functions (SFP identification and me= tadata/context information) into a single sentence. This opposes the change= we just made based on your preference in Section 4.1, which breaks the two= functions into two sentences, for reader clarity. While longer, it's simpl= er. > =95 Second, it introduces an extraneous "and/or" that would change the me= aning, and negate the "at a minimum" existing bit. That would not be simpli= fying. > =95 Third, there is no third but three bullets look better :-) >=20 > Net-net, the original text, even when longer in character count, seems mo= re clear and simpler to the reader (because of the separated sentences), IM= HO. >=20 > Thanks, >=20 > Carlos. >=20 > On Aug 7, 2014, at 8:20 AM, Andrew G. Malis wrote: >=20 >=20 > Carlos and Joel,=20 >=20 > In light of the previous discussions, I went back and re-read this curren= t definition of SFC Encapsulation in the text (section 1.3): >=20 > SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP > identification, and is used by the SFC-aware functions, such as > the SFF and SFC-aware SFs. The SFC Encapsulation is not used > for network packet forwarding. In addition to SFP > identification, the SFC encapsulation carries dataplane context > information, also referred to as metadata. >=20 > I think this could be tightened up to make simpler for the reader: >=20 > SFC Encapsulation: A data plane encapsulation that identifies the SFP an= d/or provides metadata (data plane context information). The SFP Encapsulat= ion is used by the SFC-aware functions, such as the SFF and SFC-aware SFs, = and is not used for network packet forwarding. >=20 > Thanks, > Andy >=20 >=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Aug 8 06:20:02 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 39DFB1B2BB4 for ; Fri, 8 Aug 2014 06:20:00 -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 paBowl82ePYh for ; Fri, 8 Aug 2014 06:19:57 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BBBD1B2B9E for ; Fri, 8 Aug 2014 06:19:57 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id a108so6043251qge.30 for ; Fri, 08 Aug 2014 06:19:56 -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=2Cw+I4IvAJKdB4SOwx+korcb0JF7qRkJFJep+bNUBCc=; b=w6i8Q6cCc1tOUe+ZxbcmE3942NKM2u9RWyeGOraTIG0MP9cf90XGBIcGNQvTAeF+XR QwOTmoIOm9ZxmD1UDbnhekSt8Ml0p6Iw28Lofqh2tl6/pKBPaJfb6puIdyAdImygUeMg p7Wlr6pippvtS3ZLjztEuWJc3Nj6TYRXbMYNRJWQGYD5EAF04YrSTOs6ytOi1wVOopSU /U/zf7PGta+lcv8cWPDJIWpHPsPBu1KhqAFLsYKZBQwMddwENeK1vSYPjYQqaCY+cEkj wWA+S2tV8E6a6TaH8wvbhMDKSoiprmlbKMvN0ssCSFVmF/HRjNgUPzPvYIIpMeiGIXyR /YJA== X-Received: by 10.140.88.41 with SMTP id s38mr22504610qgd.73.1407503996675; Fri, 08 Aug 2014 06:19:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.16.22 with HTTP; Fri, 8 Aug 2014 06:19:36 -0700 (PDT) In-Reply-To: <57B2ECF6-8DB4-4E23-BB14-E030EB74E09C@alcatel-lucent.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A4805@NKGEML512-MBS.china.huawei.com> <57B2ECF6-8DB4-4E23-BB14-E030EB74E09C@alcatel-lucent.com> From: "Andrew G. Malis" Date: Fri, 8 Aug 2014 09:19:36 -0400 Message-ID: To: "Dolganow, Andrew (Andrew)" Content-Type: multipart/alternative; boundary=001a11c13e7ebded4505001e0f56 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/hiPOPy7sPiW1fMen7e2BhyEW4NI Cc: "Carlos Pignataro \(cpignata\)" , Xuxiaohu , "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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, 08 Aug 2014 13:20:00 -0000 --001a11c13e7ebded4505001e0f56 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Andrew, That looks great to me. Cheers, Andy On Fri, Aug 8, 2014 at 8:53 AM, Dolganow, Andrew (Andrew) < andrew.dolganow@alcatel-lucent.com> wrote: > I agree that we should have stronger separation of two functions: SFP and > metadata. > > How about small edit to what Andy proposed: > > SFC Encapsulation: A data plane encapsulation that encodes either one or > both of > - the SFP > - metadata (data plane context information). > > The SFP Encapsulation is used by the SFC-aware functions, such as the > SFF and SFC-aware SFs, and is not used for network packet forwarding. > > > Andrew > > Sent from my iPhone > > > On Aug 7, 2014, at 9:13 PM, "Xuxiaohu" wrote: > > > > I fully agree with Andy=E2=80=99s point that not every usage of the > encapsulation will need both the SFP identification and the metadata. It= =E2=80=99s > better that the SFC encapsulation could be flexibly used for carrying SFP > identification, metadata or both. Otherwise, it seems that those SFC > approaches which don=E2=80=99t use the SFC encapsulation for SFC selectio= n would > have to separately define the way of carrying metadata. > > > > Best regards, > > Xiaohu > > > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Andrew G. Malis > > Sent: Thursday, August 07, 2014 9:06 PM > > To: Carlos Pignataro (cpignata) > > Cc: Joel M. Halpern; sfc@ietf.org > > Subject: Re: [sfc] Definition of SFC Encapsulation in > draft-merged-sfc-architecture-01.txt > > > > Carlos, > > > > When I re-read the definition, it seemed to me to be more of a string o= f > thoughts than a concise definition, which is why I was trying to tighten = it > up. A definition is meant to be a short summary for quick reference, whil= e > the discussion in 4.1 goes into the more formal details. Otherwise, you > would just repeat the entire section 4.1 in section 1.3. This is why it > doesn't need to be in separate sentences. The "and/or" is because not eve= ry > usage of the encapsulation will need both the SFP identification and the > metadata, so the definition needs to concisely convey that. > > > > Cheers, > > Andy > > > > On Thu, Aug 7, 2014 at 8:51 AM, Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > > Thank you for going back and checking, Andy! > > > > Which specific part of the current definition do you believe is loose > enough to need tightening? > > > > I believe that your new proposal falls shorter than the existing text i= n > a few areas: > > =E2=80=A2 First, it combines two different functions (SFP identificatio= n and > metadata/context information) into a single sentence. This opposes the > change we just made based on your preference in Section 4.1, which breaks > the two functions into two sentences, for reader clarity. While longer, > it's simpler. > > =E2=80=A2 Second, it introduces an extraneous "and/or" that would chang= e the > meaning, and negate the "at a minimum" existing bit. That would not be > simplifying. > > =E2=80=A2 Third, there is no third but three bullets look better :-) > > > > Net-net, the original text, even when longer in character count, seems > more clear and simpler to the reader (because of the separated sentences)= , > IMHO. > > > > Thanks, > > > > Carlos. > > > > On Aug 7, 2014, at 8:20 AM, Andrew G. Malis wrote: > > > > > > Carlos and Joel, > > > > In light of the previous discussions, I went back and re-read this > current definition of SFC Encapsulation in the text (section 1.3): > > > > SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP > > identification, and is used by the SFC-aware functions, such as > > the SFF and SFC-aware SFs. The SFC Encapsulation is not used > > for network packet forwarding. In addition to SFP > > identification, the SFC encapsulation carries dataplane context > > information, also referred to as metadata. > > > > I think this could be tightened up to make simpler for the reader: > > > > SFC Encapsulation: A data plane encapsulation that identifies the SFP > and/or provides metadata (data plane context information). The SFP > Encapsulation is used by the SFC-aware functions, such as the SFF and > SFC-aware SFs, and is not used for network packet forwarding. > > > > Thanks, > > Andy > > > > > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > --001a11c13e7ebded4505001e0f56 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Andrew,

That looks great to me.

Cheers,
Andy


On Fri, Aug 8, 2014 at 8:53 AM, Dolg= anow, Andrew (Andrew) <andrew.dolganow@alcatel-lucent.com= > wrote:
I agree that we should have stronger separat= ion of two functions: SFP and metadata.

How about small edit to what Andy proposed:

SFC Encapsulation: =C2=A0A data plane encapsulation that encodes either one= or both of
- the SFP
- metadata (data plane context information).
> The SFP Encapsulation is used by the SFC-aware functions, such as the = SFF and SFC-aware SFs, and is not used for network packet forwarding.


Andrew

Sent from my iPhone

> On Aug 7, 2014, at 9:13 PM, "Xuxiaohu" <xuxiaohu@huawei.com> wrote:
>
> I fully agree with Andy=E2=80=99s point that not every usage of the en= capsulation will need both the SFP identification and the metadata. It=E2= =80=99s better that the SFC encapsulation could be flexibly used for carryi= ng SFP identification, metadata or both. Otherwise, it seems that those SFC= approaches which don=E2=80=99t use the SFC encapsulation for SFC selection= would have to separately define the way of carrying metadata.
>
> Best regards,
> Xiaohu
>
> From: sfc [mailto:sfc-bounces@= ietf.org] On Behalf Of Andrew G. Malis
> Sent: Thursday, August 07, 2014 9:06 PM
> To: Carlos Pignataro (cpignata)
> Cc: Joel M. Halpern; sfc@ietf.org<= br> > Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc= -architecture-01.txt
>
> Carlos,
>
> When I re-read the definition, it seemed to me to be more of a string = of thoughts than a concise definition, which is why I was trying to tighten= it up. A definition is meant to be a short summary for quick reference, wh= ile the discussion in 4.1 goes into the more formal details. =C2=A0Otherwis= e, you would just repeat the entire section 4.1 in section 1.3. =C2=A0This = is why it doesn't need to be in separate sentences. The "and/or&qu= ot; is because not every usage of the encapsulation will need both the SFP = identification and the metadata, so the definition needs to concisely conve= y that.
>
> Cheers,
> Andy
>
> On Thu, Aug 7, 2014 at 8:51 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
> Thank you for going back and checking, Andy!
>
> Which specific part of the current definition do you believe is loose = enough to need tightening?
>
> I believe that your new proposal falls shorter than the existing text = in a few areas:
> =E2=80=A2 First, it combines two different functions (SFP identificati= on and metadata/context information) into a single sentence. This opposes t= he change we just made based on your preference in Section 4.1, which break= s the two functions into two sentences, for reader clarity. While longer, i= t's simpler.
> =E2=80=A2 Second, it introduces an extraneous "and/or" that = would change the meaning, and negate the "at a minimum" existing = bit. That would not be simplifying.
> =E2=80=A2 Third, there is no third but three bullets look better :-) >
> Net-net, the original text, even when longer in character count, seems= more clear and simpler to the reader (because of the separated sentences),= IMHO.
>
> Thanks,
>
> Carlos.
>
> On Aug 7, 2014, at 8:20 AM, Andrew G. Malis <agmalis@gmail.com> wrote:
>
>
> Carlos and Joel,
>
> In light of the previous discussions, I went back and re-read this cur= rent definition of SFC Encapsulation in the text (section 1.3):
>
> =C2=A0 =C2=A0SFC Encapsulation: =C2=A0The SFC Encapsulation provides a= t a minimum SFP
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 identification, and is used by the SFC-awa= re functions, such as
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 the SFF and SFC-aware SFs. =C2=A0The SFC E= ncapsulation is not used
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 for network packet forwarding. =C2=A0In ad= dition to SFP
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 identification, the SFC encapsulation carr= ies dataplane context
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 information, also referred to as metadata.=
>
> I think this could be tightened up to make simpler for the reader:
>
> SFC Encapsulation: =C2=A0A data plane encapsulation that identifies th= e SFP and/or provides metadata (data plane context information). The SFP En= capsulation is used by the SFC-aware functions, such as the SFF and SFC-awa= re SFs, and is not used for network packet forwarding.
>
> Thanks,
> Andy
>
>
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc

--001a11c13e7ebded4505001e0f56-- From nobody Fri Aug 8 08:06: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 C17CE1B2AFA for ; Fri, 8 Aug 2014 08:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 vuJ-UzeaOj4H for ; Fri, 8 Aug 2014 08:06:21 -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 B92D61A0AFC for ; Fri, 8 Aug 2014 08:06:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4298; q=dns/txt; s=iport; t=1407510380; x=1408719980; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SwZYzfLywaJf1kHzi8OdlnsQlZfR/KSOBf/0u7byT1Q=; b=XSy2uxL5wz1DAEXDiALDVdJclJEf3TImfiBjfyiwhJij3j5jziS/65ok z82HR4ucBCuVwnd4QhvOb/5BFvFKvYrpbSHCxSYeke7QaqDeRuR4KGv69 EkB+d/W+riqfNQbrkPjrAILmj9ifZjr1/fk7k25CS9FCgw3tXfy5d2tG+ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFALTm5FOtJV2S/2dsb2JhbABagmojgSkE1DMBgRMWd4QDAQEBAwFnEgULAgEIEQEDAQEBJwchERQDBggCBA4FiC4DCQgBv3cNhWAXiX+DIIF6MweDL4EcAQSPA4IRiQiCCY5Ehi6CEYFGbIFG X-IronPort-AV: E=Sophos;i="5.01,825,1400025600"; d="scan'208";a="67600924" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-1.cisco.com with ESMTP; 08 Aug 2014 15:06:19 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s78F6JdX002945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Aug 2014 15:06:19 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Fri, 8 Aug 2014 10:06:19 -0500 From: "Carlos Pignataro (cpignata)" To: Xiaohu Xu Thread-Topic: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt Thread-Index: AQHPsjoEpUaq91+aSUyfBy1ywE3Zo5vFa98AgAAELYCAAMs3gIAA6LiA Date: Fri, 8 Aug 2014 15:06:18 +0000 Message-ID: <06AA8234-5892-4B92-8429-789C4DF457F5@cisco.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A4805@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A4805@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.99.254] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0FE3DE84ACC61042B3A0C6A195C5A282@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/cbysgrr2uR_sjoYZikT0OKDeNgU Cc: "Joel M. Halpern" , "Andrew G. Malis" , "sfc@ietf.org" Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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, 08 Aug 2014 15:06:23 -0000 Hi, Xiaohu, Andy, Lucy, I agree Andy with the goal of a simple definition. From a "simplifying to t= he reader" perspective, two smaller sentences are easier to parse than an c= oncatenated mega-sentence. And if you consider all the definitions in Secti= on 1.3, the one for "SFC Encapsulation" is within the shortest ones, and to= me follows a logical succession of sentences instead of a stream of though= ts. That said, if the definition needs tightening let's do so maintaining t= he meaning. Again, the meaning is constrained by and needs to follow the ch= arter, which is not "and/or". Thanks, Carlos. On Aug 7, 2014, at 9:13 PM, Xuxiaohu wrote: > I fully agree with Andy=92s point that not every usage of the encapsulati= on will need both the SFP identification and the metadata. It=92s better th= at the SFC encapsulation could be flexibly used for carrying SFP identifica= tion, metadata or both. Otherwise, it seems that those SFC approaches which= don=92t use the SFC encapsulation for SFC selection would have to separate= ly define the way of carrying metadata. >=20 > Best regards, > Xiaohu=20 >=20 > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Andrew G. Malis > Sent: Thursday, August 07, 2014 9:06 PM > To: Carlos Pignataro (cpignata) > Cc: Joel M. Halpern; sfc@ietf.org > Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-ar= chitecture-01.txt >=20 > Carlos, >=20 > When I re-read the definition, it seemed to me to be more of a string of = thoughts than a concise definition, which is why I was trying to tighten it= up. A definition is meant to be a short summary for quick reference, while= the discussion in 4.1 goes into the more formal details. Otherwise, you w= ould just repeat the entire section 4.1 in section 1.3. This is why it doe= sn't need to be in separate sentences. The "and/or" is because not every us= age of the encapsulation will need both the SFP identification and the meta= data, so the definition needs to concisely convey that. >=20 > Cheers, > Andy >=20 > On Thu, Aug 7, 2014 at 8:51 AM, Carlos Pignataro (cpignata) wrote: > Thank you for going back and checking, Andy!=20 >=20 > Which specific part of the current definition do you believe is loose eno= ugh to need tightening? >=20 > I believe that your new proposal falls shorter than the existing text in = a few areas: > =95 First, it combines two different functions (SFP identification and me= tadata/context information) into a single sentence. This opposes the change= we just made based on your preference in Section 4.1, which breaks the two= functions into two sentences, for reader clarity. While longer, it's simpl= er. > =95 Second, it introduces an extraneous "and/or" that would change the me= aning, and negate the "at a minimum" existing bit. That would not be simpli= fying. > =95 Third, there is no third but three bullets look better :-) >=20 > Net-net, the original text, even when longer in character count, seems mo= re clear and simpler to the reader (because of the separated sentences), IM= HO. >=20 > Thanks, >=20 > Carlos. >=20 > On Aug 7, 2014, at 8:20 AM, Andrew G. Malis wrote: >=20 >=20 > Carlos and Joel,=20 >=20 > In light of the previous discussions, I went back and re-read this curren= t definition of SFC Encapsulation in the text (section 1.3): >=20 > SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP > identification, and is used by the SFC-aware functions, such as > the SFF and SFC-aware SFs. The SFC Encapsulation is not used > for network packet forwarding. In addition to SFP > identification, the SFC encapsulation carries dataplane context > information, also referred to as metadata. >=20 > I think this could be tightened up to make simpler for the reader: >=20 > SFC Encapsulation: A data plane encapsulation that identifies the SFP an= d/or provides metadata (data plane context information). The SFP Encapsulat= ion is used by the SFC-aware functions, such as the SFF and SFC-aware SFs, = and is not used for network packet forwarding. >=20 > Thanks, > Andy >=20 >=20 >=20 From nobody Fri Aug 8 08: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 BF12D1B2B6E for ; Fri, 8 Aug 2014 08:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 1pm4OmHSNiHY for ; Fri, 8 Aug 2014 08:09:47 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 155CC1B2AFA for ; Fri, 8 Aug 2014 08:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4791; q=dns/txt; s=iport; t=1407510555; x=1408720155; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cga+T3CZVDgiwUQfPRWtRECu8up4nwvisJ2XMUsizfI=; b=dA9bll13Oj3YQmgPIdOr/XQkEJdj6XRzVvXmiUEpdSPhHR6D8PF8sVax mfVuQsoBBwLAuM5O6uxLOQlisWtZIJaSobjXrv7jSeOopvC3Z6kiPY01P 99pjoDcvvkS5GHwT0OkVcGr5Rdnbb5sdIIaG68mylw6JGII7W8cRtAgBJ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFACvn5FOtJV2d/2dsb2JhbABagmojUlcEzGEKh0gBgRMWd4QDAQEBAwEBAQFkBwsFCwIBCBEBAwEBAScHIQYLFAMGCAIEDgWILgMJCAEMv2wNhWAXiX+DIIF6MweDL4EcBY8DghGEI4RlggmBVIxwhi6CEYFGbIFG X-IronPort-AV: E=Sophos;i="5.01,825,1400025600"; d="scan'208";a="67648925" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 08 Aug 2014 15:09:14 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s78F9EUY008940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Aug 2014 15:09:14 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Fri, 8 Aug 2014 10:09:13 -0500 From: "Carlos Pignataro (cpignata)" To: "Dolganow, Andrew (Andrew)" Thread-Topic: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt Thread-Index: AQHPsjoEpUaq91+aSUyfBy1ywE3Zo5vFa98AgAAELYCAAMs3gIAAw3mAgAAmDwA= Date: Fri, 8 Aug 2014 15:09:13 +0000 Message-ID: References: , <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A4805@NKGEML512-MBS.china.huawei.com> <57B2ECF6-8DB4-4E23-BB14-E030EB74E09C@alcatel-lucent.com> In-Reply-To: <57B2ECF6-8DB4-4E23-BB14-E030EB74E09C@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.99.254] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1AFE4008892AB749B705065526F654B1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/wodNNeMZBumMAECArVQeQA33imc Cc: Xiaohu Xu , "Joel M. Halpern" , "Andrew G. Malis" , "sfc@ietf.org" Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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, 08 Aug 2014 15:09:52 -0000 Hi, Andrew, On Aug 8, 2014, at 8:53 AM, Dolganow, Andrew (Andrew) wrote: > I agree that we should have stronger separation of two functions: SFP and= metadata.=20 >=20 > How about small edit to what Andy proposed: >=20 > SFC Encapsulation: A data plane encapsulation that encodes either one or= both of > - the SFP=20 > - metadata (data plane context information).=20 Looking at http://datatracker.ietf.org/wg/sfc/charter/, there is no "either= one or both of". In fact, looking at the history of the charter text, the = text for SFC Encapsulation is a bullet list form of a longer sentence that = includes "and" only (see 00-09). Thanks, Carlos. >> The SFP Encapsulation is used by the SFC-aware functions, such as the SF= F and SFC-aware SFs, and is not used for network packet forwarding. >=20 >=20 > Andrew >=20 > Sent from my iPhone >=20 >> On Aug 7, 2014, at 9:13 PM, "Xuxiaohu" wrote: >>=20 >> I fully agree with Andy=92s point that not every usage of the encapsulat= ion will need both the SFP identification and the metadata. It=92s better t= hat the SFC encapsulation could be flexibly used for carrying SFP identific= ation, metadata or both. Otherwise, it seems that those SFC approaches whic= h don=92t use the SFC encapsulation for SFC selection would have to separat= ely define the way of carrying metadata. >>=20 >> Best regards, >> Xiaohu=20 >>=20 >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Andrew G. Malis >> Sent: Thursday, August 07, 2014 9:06 PM >> To: Carlos Pignataro (cpignata) >> Cc: Joel M. Halpern; sfc@ietf.org >> Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-a= rchitecture-01.txt >>=20 >> Carlos, >>=20 >> When I re-read the definition, it seemed to me to be more of a string of= thoughts than a concise definition, which is why I was trying to tighten i= t up. A definition is meant to be a short summary for quick reference, whil= e the discussion in 4.1 goes into the more formal details. Otherwise, you = would just repeat the entire section 4.1 in section 1.3. This is why it do= esn't need to be in separate sentences. The "and/or" is because not every u= sage of the encapsulation will need both the SFP identification and the met= adata, so the definition needs to concisely convey that. >>=20 >> Cheers, >> Andy >>=20 >> On Thu, Aug 7, 2014 at 8:51 AM, Carlos Pignataro (cpignata) wrote: >> Thank you for going back and checking, Andy!=20 >>=20 >> Which specific part of the current definition do you believe is loose en= ough to need tightening? >>=20 >> I believe that your new proposal falls shorter than the existing text in= a few areas: >> =95 First, it combines two different functions (SFP identification and m= etadata/context information) into a single sentence. This opposes the chang= e we just made based on your preference in Section 4.1, which breaks the tw= o functions into two sentences, for reader clarity. While longer, it's simp= ler. >> =95 Second, it introduces an extraneous "and/or" that would change the m= eaning, and negate the "at a minimum" existing bit. That would not be simpl= ifying. >> =95 Third, there is no third but three bullets look better :-) >>=20 >> Net-net, the original text, even when longer in character count, seems m= ore clear and simpler to the reader (because of the separated sentences), I= MHO. >>=20 >> Thanks, >>=20 >> Carlos. >>=20 >> On Aug 7, 2014, at 8:20 AM, Andrew G. Malis wrote: >>=20 >>=20 >> Carlos and Joel,=20 >>=20 >> In light of the previous discussions, I went back and re-read this curre= nt definition of SFC Encapsulation in the text (section 1.3): >>=20 >> SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP >> identification, and is used by the SFC-aware functions, such as >> the SFF and SFC-aware SFs. The SFC Encapsulation is not used >> for network packet forwarding. In addition to SFP >> identification, the SFC encapsulation carries dataplane context >> information, also referred to as metadata. >>=20 >> I think this could be tightened up to make simpler for the reader: >>=20 >> SFC Encapsulation: A data plane encapsulation that identifies the SFP a= nd/or provides metadata (data plane context information). The SFP Encapsula= tion is used by the SFC-aware functions, such as the SFF and SFC-aware SFs,= and is not used for network packet forwarding. >>=20 >> Thanks, >> Andy >>=20 >>=20 >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Aug 8 08:53: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 3D9D91B2C48; Fri, 8 Aug 2014 08:53:12 -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 ol-_dvEbpwxY; Fri, 8 Aug 2014 08:53:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D144C1B2C41; Fri, 8 Aug 2014 08:53:10 -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.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140808155310.11324.35405.idtracker@ietfa.amsl.com> Date: Fri, 08 Aug 2014 08:53:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/4vStseFnmipdVMZ9OGTJLM7pjJU Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-09.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: Fri, 08 Aug 2014 15:53:12 -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 Problem Statement Authors : Paul Quinn Thomas Nadeau Filename : draft-ietf-sfc-problem-statement-09.txt Pages : 19 Date : 2014-08-08 Abstract: This document provides an overview of the issues associated with the deployment of service functions (such as firewalls, load balancers) in large-scale environments. The term service function chaining is used to describe the definition and instantiation of an ordered set of instances of such service functions, and the subsequent "steering" of traffic flows through those service functions. The set of enabled service function chains reflect operator service offerings and is designed in conjunction with application delivery and service and network policy. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-problem-statement-09 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 Fri Aug 8 12:49: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 A3E341A03BC for ; Fri, 8 Aug 2014 12:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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.001, 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 tvqtjbWdOYYG for ; Fri, 8 Aug 2014 12:48:49 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E9F1A03C6 for ; Fri, 8 Aug 2014 12:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3259; q=dns/txt; s=iport; t=1407527329; x=1408736929; h=from:to:subject:date:message-id:mime-version; bh=1Jc3YsGtt0ePX80Q09udsjnofJJYJgnlybh0eAi3e30=; b=HIe1V4AX7q6E0oPAGZn945l4U69aQUxhq4CVksQDIqoGI6G1K238yRAc TYectrxG/hMvJU2vGqxDQlTRwwFE/39HcD6zh3tL6o0EQDwjeNOJ37aE0 k7Si8nIAvzvpNEHMslBvKxZmJpdGgf5Y0PE/EOj4XtNtuEgQQ4bYXzRGC A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoHAFEo5VOtJV2a/2dsb2JhbABagkdGUlgDsTCZWYFjiF4Wd4QKbh0BDHQnBIhVDaBVpSQXlB4FkRaEJYZugVaKKIh6g1eCMw X-IronPort-AV: E=Sophos; i="5.01,827,1400025600"; d="scan'208,217"; a="67718836" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP; 08 Aug 2014 19:48:48 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s78Jmm9v015507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 8 Aug 2014 19:48:48 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Fri, 8 Aug 2014 14:48:48 -0500 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: SFC Problem Statement to IESG Thread-Index: AQHPs0HEU7eygBQELkiKupzFgFkUdg== Date: Fri, 8 Aug 2014 19:48:47 +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_D00AA1DC302F3jguicharciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/zondKiYXY4hVmDmpAaWBWmOwUNw Subject: [sfc] SFC Problem Statement to IESG 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, 08 Aug 2014 19:48:54 -0000 --_000_D00AA1DC302F3jguicharciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ has been = updated in accordance with the comments and suggestions made on the mailing= list and during our recent face-to-face meeting in Toronto. The next step = is to send the document to the IESG for review and approval. For the authors of this document, please confirm to the mailing list that a= ll relevant IPR you are aware of has been properly disclosed. If you are on the SFC WG mailing list but are not listed as an author or co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. Jim --_000_D00AA1DC302F3jguicharciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <3A93C1366A50B745948D2690BD5EB334@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Dear WG:

http://datatracker.ietf.org/doc/draft-= ietf-sfc-problem-statement/ has been updated in accordance with th= e comments and suggestions made on the mailing list and during our recent face-to-face meeting in Toronto. The next step = is to send the document to the IESG for review and approval. 

For the authors of this document, please = confirm to the mailing list that all relevant IPR you are aware of has been= properly disclosed. 

If you are on the SFC WG mailing list but are not listed as an author = or contributor, then please explicitly respond only if you are aware of any= IPR that has not yet been disclosed in conformance with IETF rules.

Jim





--_000_D00AA1DC302F3jguicharciscocom_-- From nobody Fri Aug 8 12:54: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 29D5E1A03F0 for ; Fri, 8 Aug 2014 12:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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.001, 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 jtxXf0w3Paji for ; Fri, 8 Aug 2014 12:54:34 -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 2577A1A03BB for ; Fri, 8 Aug 2014 12:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4483; q=dns/txt; s=iport; t=1407527675; x=1408737275; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DFCr8UcgfmUpdljvAElK506LvByghsDj4crp0mCj4uM=; b=g/imdEkzJZpwjAuB82vVlvw/ILFDAQrqmR4MDYKAAex3+Ce74dCyddm5 N58a0uwgT35d20kMWb2MOVA/n6gHd6i7OWDSeTk4ZWiyfpkQEZci/o6nY 1NJQt/nc38PbubZ+AZ9/PvtAUJdIMPn1bYkTZ2sGX3n9kBftzHs9FPb0K Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAFAAQq5VOtJV2S/2dsb2JhbABagkdGUk0KBLEwmVmBWQEJh0gBgRUWd4QEAQEEAQEBawsQAgEIBDsHJwsUEQIEDgWIQg3FexePTAeDL4EcBZEWhCWGboFWiiiIeoNXbIFH X-IronPort-AV: E=Sophos;i="5.01,827,1400025600"; d="scan'208,217";a="346165942" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-3.cisco.com with ESMTP; 08 Aug 2014 19:54:34 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s78JsXds005653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 8 Aug 2014 19:54:33 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Fri, 8 Aug 2014 14:54:33 -0500 From: "Paul Quinn (paulq)" To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] SFC Problem Statement to IESG Thread-Index: AQHPs0HEU7eygBQELkiKupzFgFkUdpvHcnIA Date: Fri, 8 Aug 2014 19:54:32 +0000 Message-ID: <32CE5820-5BD1-47D3-91F0-6B6970B111BE@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.226] Content-Type: multipart/alternative; boundary="_000_32CE58205BD147D391F06B6970B111BEciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/MmQRI88yKzk8IzN0sLbPN9bKQ5Q Cc: "sfc@ietf.org" Subject: Re: [sfc] SFC Problem Statement to IESG 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, 08 Aug 2014 19:54:38 -0000 --_000_32CE58205BD147D391F06B6970B111BEciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Aug 8, 2014, at 3:48 PM, Jim Guichard (jguichar) > wrote: Dear WG: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ has been = updated in accordance with the comments and suggestions made on the mailing= list and during our recent face-to-face meeting in Toronto. The next step = is to send the document to the IESG for review and approval. For the authors of this document, please confirm to the mailing list that a= ll relevant IPR you are aware of has been properly disclosed. As an editor, I am not aware of any IPR related to the problem statement. If you are on the SFC WG mailing list but are not listed as an author or co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. Jim _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_32CE58205BD147D391F06B6970B111BEciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <3454536AA561B34E80353C0E56039390@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On Aug 8, 2014, at 3:48 PM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:

Dear WG:

http://datatracker.ietf.org/doc/draft-ie= tf-sfc-problem-statement/ has been updated in accordance with the = comments and suggestions made on the mailing list and during our recent face-to-face meeting in Toronto. The next step = is to send the document to the IESG for review and approval. 

For the authors of this document, please co= nfirm to the mailing list that all relevant IPR you are aware of has been p= roperly disclosed. 

As an editor, I am not aware of any IPR related to the problem stateme= nt.



If you are on the SFC WG mailing list but are not listed as an author = or contributor, then please explicitly respond only if you are aware of any= IPR that has not yet been disclosed in conformance with IETF rules.

Jim





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

--_000_32CE58205BD147D391F06B6970B111BEciscocom_-- From nobody Fri Aug 8 13:59: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 D72ED1A0450 for ; Fri, 8 Aug 2014 13:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 QyKfjPjFCL7K for ; Fri, 8 Aug 2014 13:59:05 -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 4309E1A0158 for ; Fri, 8 Aug 2014 13:59:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIB17630; Fri, 08 Aug 2014 20:59:03 +0000 (GMT) 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; Fri, 8 Aug 2014 21:59:01 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm.china.huawei.com ([169.254.4.217]) with mapi id 14.03.0158.001; Fri, 8 Aug 2014 13:58:49 -0700 From: Lucy yong To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: SFC Problem Statement to IESG Thread-Index: AQHPs0HEU7eygBQELkiKupzFgFkUdpvHLOFA Date: Fri, 8 Aug 2014 20:58:48 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453C9DF9@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.138.88] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D453C9DF9dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/XtDp5MCqqjiqOLneWE15xFRISfM Subject: Re: [sfc] SFC Problem Statement to IESG 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, 08 Aug 2014 20:59:12 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D453C9DF9dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This definition in new version is not right. Network Overlay: Locally instantiated policy and customer/network/ service profile matching of traffic flows for identification of appropriate outbound forwarding actions. Editing error? This definition: Service Function Chain (SFC): A service Function chain defines an abstract set of service functions and their ordering constraints that must be applied to packets and/or frames selected as a result of classification. The implied order may not be a linear progression as the architecture allows for nodes that copy to more than one branch, and also allows for cases where there is flexibility in the order in which services need to be applied. The term service chain is often used as shorthand for service function chain. The marked text seems conflict each other. Does a SFC need the flexibilit= y in the order of abstract set of SFs? Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Friday, August 08, 2014 2:49 PM To: sfc@ietf.org Subject: [sfc] SFC Problem Statement to IESG Dear WG: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ has been = updated in accordance with the comments and suggestions made on the mailing= list and during our recent face-to-face meeting in Toronto. The next step = is to send the document to the IESG for review and approval. For the authors of this document, please confirm to the mailing list that a= ll relevant IPR you are aware of has been properly disclosed. If you are on the SFC WG mailing list but are not listed as an author or co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. Jim --_000_2691CE0099834E4A9C5044EEC662BB9D453C9DF9dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This definition in new ve= rsion is not right.

   Network Overlay:  Locally instantiated p= olicy and customer/network/

      service profile matching of= traffic flows for identification of

      appropriate outbound forwar= ding actions.

Editing error?=

 <= /p>

This definition:

Service Function Chain (SFC):  A service Function chain defines a=
n
      abstract set of service functions and <=
span style=3D"color:#C00000">their ordering constraints

      that must=
 be applied to packets and/or frames selected as a result=



      of classification.  The implied or=
der may not be a linear


      progression as the architecture allows =
for nodes that copy to more


      than one branch, and also allows for cases where there is


      flexibili=
ty in the order in which services need to be applied.

      The term service chain is often used as=
 shorthand for service


      function chain.


 <=
/p>

The marked text seems con=
flict each other.   Does a SFC need the flexibility in the order =
of abstract set of SFs?


 <=
/p>

Lucy

 <=
/p>





From: sfc [mai=
lto:sfc-bounces@ietf.org]
On Behalf Of Jim Guichard (jguichar)

Sent: Friday, August 08, 2014 2:49 PM

To: sfc@ietf.org

Subject: [sfc] SFC Problem Statement to IESG






 




Dear WG:





 





http://datatracker.ietf.=
org/doc/draft-ietf-sfc-problem-statement/ has been updated
 in accordance with the comments and suggestions made on the mailing list a=
nd during our recent face-to-face meeting in Toronto. The next step is to s=
end the document to the IESG for review and approval. 






 





For the authors of this doc=
ument, please confirm to the mailing list that all relevant IPR you are awa=
re of has been properly disclosed. =







 










If you are on the SFC WG ma=
iling list but are not listed as an author or contributor, then please expl=
icitly respond only if you are aware of any IPR that has
 not yet been disclosed in conformance with IETF rules.





 





Jim










 






 






 






 






 
--_000_2691CE0099834E4A9C5044EEC662BB9D453C9DF9dfweml701chmchi_-- From nobody Fri Aug 8 14:06:05 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 1C8E71A0379 for ; Fri, 8 Aug 2014 14:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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.001, 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 R4yB2toDNDOR for ; Fri, 8 Aug 2014 14:06:00 -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 7125F1A0AD6 for ; Fri, 8 Aug 2014 14:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16142; q=dns/txt; s=iport; t=1407531960; x=1408741560; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wV03TG/e0cvKUC8sLbILuRDHuUkQ26qJ/DUcwhNZUhg=; b=KQUO+RzWoh81Kf5EqT/+wYBJutv7Nq8Mky38qQfgIyO1XIQXCTmSpfaz OthSAnDSfBh5/OdF10o3LDBQvSu6CQsNbcfDN8XGTSQdrLe0Kq87IKp5M uwr1CTb5Tx1wE7hhLzp8wBMrZ2BjFTMtM9MsHvxaptTUBjykb3uEZVajJ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowFAJc65VOtJV2S/2dsb2JhbABagkdGUlcEsTCZWYFZAQmHSAGBFRZ3hAMBAQEEAQEBawsQAgEIEQEDAQEoBycLFAMGCAIEDgWIQg3FYxePSAQGAYMvgRwFjwOCE4QlgjmENYFWiiiIeoNXbIFH X-IronPort-AV: E=Sophos;i="5.01,827,1400025600"; d="scan'208,217";a="343063158" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-9.cisco.com with ESMTP; 08 Aug 2014 21:05:59 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s78L5xGV020126 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Aug 2014 21:05:59 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Fri, 8 Aug 2014 16:05:58 -0500 From: "Paul Quinn (paulq)" To: Lucy yong Thread-Topic: [sfc] SFC Problem Statement to IESG Thread-Index: AQHPs0HEU7eygBQELkiKupzFgFkUdpvHLOFAgABZhYA= Date: Fri, 8 Aug 2014 21:05:57 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D453C9DF9@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453C9DF9@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.226] Content-Type: multipart/alternative; boundary="_000_C370614C23A94B27A1EB55976A721A3Fciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/iWj6TbCnEAeuz1Yxp4BACHWF0bY Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] SFC Problem Statement to IESG 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, 08 Aug 2014 21:06:03 -0000 --_000_C370614C23A94B27A1EB55976A721A3Fciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Aug 8, 2014, at 4:58 PM, Lucy yong > wrote: This definition in new version is not right. Network Overlay: Locally instantiated policy and customer/network/ service profile matching of traffic flows for identification of appropriate outbound forwarding actions. Editing error? Yes indeed, thanks for catching that. This definition: Service Function Chain (SFC): A service Function chain defines an abstract set of service functions and their ordering constraints that must be applied to packets and/or frames selected as a result of classification. The implied order may not be a linear progression as the architecture allows for nodes that copy to more than one branch, and also allows for cases where there is flexibility in the order in which services need to be applied. The term service chain is often used as shorthand for service function chain. The marked text seems conflict each other. Does a SFC need the flexibilit= y in the order of abstract set of SFs? That is the same defn used in the arch draft. I don=92t see a conflict: th= e first sentence states there might be a constraints. The 2nd simply allow= s for loose constraints. Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Friday, August 08, 2014 2:49 PM To: sfc@ietf.org Subject: [sfc] SFC Problem Statement to IESG Dear WG: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ has been = updated in accordance with the comments and suggestions made on the mailing= list and during our recent face-to-face meeting in Toronto. The next step = is to send the document to the IESG for review and approval. For the authors of this document, please confirm to the mailing list that a= ll relevant IPR you are aware of has been properly disclosed. If you are on the SFC WG mailing list but are not listed as an author or co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. Jim _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_C370614C23A94B27A1EB55976A721A3Fciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8131BF0F9AA7CD48B8C22E7B516993D3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable



On Aug 8, 2014, at 4:58 PM, Lucy yong <lucy.yong@huawei.com> wrote:

This definition in new version is not right.
   N= etwork Overlay:  Locally instantiated policy and customer/network/
  &n= bsp;   service profile matching of traffic flows for identificati= on of
  &n= bsp;   appropriate outbound forwarding actions.=
Editing error?

Yes indeed, thanks for catching that.


 
This definition:
Service Function Chain (SFC):  A service Function chain def=
ines an
      abstract set of service functions=
 and their ordering constraints
      that must be applied to packets and/or frames selected as a re=
sult
      of classification.  The impl=
ied order may not be a linear
      progression as the architecture a=
llows for nodes that copy to more
      than one branch, and also allows for cases where there is=

    &=
nbsp; flexibility in the order in which services need to be applied.
      The term service chain is often u=
sed as shorthand for service
      function chain.
 
The marked text seems conflict each other.   Doe= s a SFC need the flexibility in the order of abstract set of SFs?

That is the same defn used in the arch draft.  I don=92t see a co= nflict: the first sentence states there might be a constraints.  The 2= nd simply allows for loose constraints.


 
Lucy
 
From:<= /span> sfc [= mailto:sfc-bounces@ietf.org] = ;On Behalf Of Jim Guicha= rd (jguichar)
Sent: Friday, Augu= st 08, 2014 2:49 PM
To: sfc@= ietf.org
Subject: [sfc] SFC= Problem Statement to IESG
 
Dear W= G:
 =
http://datatracker.ietf.o= rg/doc/draft-ietf-sfc-problem-statement/ has been updated in accordance with the comments and suggestions made on the m= ailing list and during our recent face-to-face meeting in Toronto. The next= step is to send the document to the IESG for review and approval. 
 =
For th= e authors of this document, please confirm to the mailing list that all rel= evant IPR you are aware of has been properly disclosed. 
 
If you= are on the SFC WG mailing list but are not listed as an author or contribu= tor, then please explicitly respond only if you are aware of any IPR that h= as not yet been disclosed in conformance with IETF rules.
 =
Jim
 
 
 
 
 
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

--_000_C370614C23A94B27A1EB55976A721A3Fciscocom_-- From nobody Fri Aug 8 14: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 6F84A1A0264 for ; Fri, 8 Aug 2014 14:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 EfWjy_cQJqTf for ; Fri, 8 Aug 2014 14:18:22 -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 B5C8A1A00D7 for ; Fri, 8 Aug 2014 14:18:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIB18389; Fri, 08 Aug 2014 21:18:20 +0000 (GMT) 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; Fri, 8 Aug 2014 22:18:19 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Fri, 8 Aug 2014 14:18:13 -0700 From: Lucy yong To: "Paul Quinn (paulq)" Thread-Topic: [sfc] SFC Problem Statement to IESG Thread-Index: AQHPs0HEU7eygBQELkiKupzFgFkUdpvHLOFAgABZhYD//62OUA== Date: Fri, 8 Aug 2014 21:18:13 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453C9E29@dfweml701-chm.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D453C9DF9@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.88] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D453C9E29dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/cVufGdPTHiuIzHTbmFWI_Oj6Rnw Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] SFC Problem Statement to IESG 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, 08 Aug 2014 21:18:25 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D453C9E29dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [snip] This definition: Service Function Chain (SFC): A service Function chain defines an abstract set of service functions and their ordering constraints that must be applied to packets and/or frames selected as a result of classification. The implied order may not be a linear progression as the architecture allows for nodes that copy to more than one branch, and also allows for cases where there is flexibility in the order in which services need to be applied. The term service chain is often used as shorthand for service function chain. The marked text seems conflict each other. Does a SFC need the flexibilit= y in the order of abstract set of SFs? That is the same defn used in the arch draft. I don't see a conflict: the = first sentence states there might be a constraints. The 2nd simply allows = for loose constraints. [Lucy] OK, I see latest version arch doc having the same definition. Then I= question: do we need that? What does the SFC graph in figure 1 mean in the= second case? The order of SFs can be changed in any way? Don't know if peo= ple read the new ver. of arch doc yet and realize this change from last ver= .. Is there a use case to drive this flexibility? Lucy Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Friday, August 08, 2014 2:49 PM To: sfc@ietf.org Subject: [sfc] SFC Problem Statement to IESG Dear WG: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ has been = updated in accordance with the comments and suggestions made on the mailing= list and during our recent face-to-face meeting in Toronto. The next step = is to send the document to the IESG for review and approval. For the authors of this document, please confirm to the mailing list that a= ll relevant IPR you are aware of has been properly disclosed. If you are on the SFC WG mailing list but are not listed as an author or co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. Jim _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_2691CE0099834E4A9C5044EEC662BB9D453C9E29dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[snip] 

This definition:

Service Function Chain (SFC):  A service Function chain defines a=
n
      abstract set of service functions and <=
span style=3D"color:#C00000">their ordering constraints

      that must=
 be applied to packets and/or frames selected as a result=



      of classification.  The implied or=
der may not be a linear


      progression as the architecture allows =
for nodes that copy to more


      than one branch, and also allows for cases where there is


      flexibili=
ty in the order in which services need to be applied.

      The term service chain is often used as=
 shorthand for service


      function chain.




 <=
/p>





The marked text seems con=
flict each other.   Does a SFC need the flexibility in the order =
of abstract set of SFs?

 

That is the same defn used in the arch draft.  = I don’t see a conflict: the first sentence states there might be a co= nstraints.  The 2nd simply allows for loose constraints.

[Lucy] OK, I see la= test version arch doc having the same definition. Then I question: do we ne= ed that? What does the SFC graph in figure 1 mean in the second case? The order of SFs can be changed in any way? Don’t know = if people read the new ver. of arch doc yet and realize this change from la= st ver.. Is there a use case to drive this flexibility?  

 

Lucy=

 



 <= /p>

Lucy

 <= /p>

From: sfc [mail= to:sfc-bounces@ietf.org]&n= bsp;On Behalf Of Jim Guichard (jguichar)
Sent: Friday, Augu= st 08, 2014 2:49 PM
To: sfc@ietf.org
Subject: [sfc] SFC= Problem Statement to IESG

 

Dear WG:

 

http://= datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ = has been updated in accordance with the comments and suggestions made on the m= ailing list and during our recent face-to-face meeting in Toronto. The next= step is to send the document to the IESG for review and approval. 

 

For the authors of this document, pleas= e confirm to the mailing list that all relevant IPR you are aware of has be= en properly disclosed. 

 

If you are on the SFC WG mailing list b= ut are not listed as an author or contributor, then please explicitly respo= nd only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

 

Jim

 

 

 

 

 

______________________________________= _________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

 

--_000_2691CE0099834E4A9C5044EEC662BB9D453C9E29dfweml701chmchi_-- From nobody Fri Aug 8 14:47: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 E70481A0140 for ; Fri, 8 Aug 2014 14:47:04 -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 odiN0kYjgCBs for ; Fri, 8 Aug 2014 14:46:59 -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 C21D61A00F2 for ; Fri, 8 Aug 2014 14:46:58 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id j107so6706622qga.22 for ; Fri, 08 Aug 2014 14:46:58 -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=KAjj4q9/weudPTJxojpQx9bScKAU4g16iX9obbxUsF0=; b=OJd0rkDPSWNC0bNifjpyqWkg+GssuZYNQXkztCgpgKI1dUkLmV5GWHefl2MCwFUuSG 3u47cnz02Ed7Y+QDeGiL5sfHGsm3BZNnumTY238vZuyam58k0iP2hXXstIXmaYFTC5OF qyxIOm62CIF6LwdK/hBlG3peKgPtqSbG4mMBq5kAyjHLko/fju3BzD6uGwlicietf3vy iZ+bmzCZFaJVbBjO0+HVXu1YULn6Aqr+2j028HJYHLA7z3PNXoLxFSZeteGvdEmXJh+H JzbO+Hl6jQR+IZ3kfKLYnpFcZvg9oXEQJiieDklq20LIbxQCMSqp4NEKpK0FvqfT61s+ +88A== X-Received: by 10.229.140.70 with SMTP id h6mr41389216qcu.3.1407534417981; Fri, 08 Aug 2014 14:46:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.16.22 with HTTP; Fri, 8 Aug 2014 14:46:37 -0700 (PDT) In-Reply-To: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A4805@NKGEML512-MBS.china.huawei.com> <57B2ECF6-8DB4-4E23-BB14-E030EB74E09C@alcatel-lucent.com> From: "Andrew G. Malis" Date: Fri, 8 Aug 2014 17:46:37 -0400 Message-ID: To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=001a1132ec32fe387e0500252439 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/BN0IYt0YbcBgZYxWZhx1QkiKPT8 Cc: Xiaohu Xu , "Dolganow, Andrew \(Andrew\)" , "sfc@ietf.org" , "Joel M. Halpern" Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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, 08 Aug 2014 21:47:05 -0000 --001a1132ec32fe387e0500252439 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Carlos, I agree that the charter requires the encapsulation to support each of the bullet items, but there's no requirement that every encapsulated packet will need all of the bullet items supported, so I'm trying to keep the text as flexible as possible to not preclude possible solutions. Cheers, Andy On Fri, Aug 8, 2014 at 11:09 AM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Hi, Andrew, > > On Aug 8, 2014, at 8:53 AM, Dolganow, Andrew (Andrew) < > andrew.dolganow@alcatel-lucent.com> wrote: > > > I agree that we should have stronger separation of two functions: SFP > and metadata. > > > > How about small edit to what Andy proposed: > > > > SFC Encapsulation: A data plane encapsulation that encodes either one > or both of > > - the SFP > > - metadata (data plane context information). > > Looking at http://datatracker.ietf.org/wg/sfc/charter/, there is no > "either one or both of". In fact, looking at the history of the charter > text, the text for SFC Encapsulation is a bullet list form of a longer > sentence that includes "and" only (see 00-09). > > Thanks, > > Carlos. > > >> The SFP Encapsulation is used by the SFC-aware functions, such as the > SFF and SFC-aware SFs, and is not used for network packet forwarding. > > > > > > Andrew > > > > Sent from my iPhone > > > >> On Aug 7, 2014, at 9:13 PM, "Xuxiaohu" wrote: > >> > >> I fully agree with Andy=E2=80=99s point that not every usage of the > encapsulation will need both the SFP identification and the metadata. It= =E2=80=99s > better that the SFC encapsulation could be flexibly used for carrying SFP > identification, metadata or both. Otherwise, it seems that those SFC > approaches which don=E2=80=99t use the SFC encapsulation for SFC selectio= n would > have to separately define the way of carrying metadata. > >> > >> Best regards, > >> Xiaohu > >> > >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Andrew G. Malis > >> Sent: Thursday, August 07, 2014 9:06 PM > >> To: Carlos Pignataro (cpignata) > >> Cc: Joel M. Halpern; sfc@ietf.org > >> Subject: Re: [sfc] Definition of SFC Encapsulation in > draft-merged-sfc-architecture-01.txt > >> > >> Carlos, > >> > >> When I re-read the definition, it seemed to me to be more of a string > of thoughts than a concise definition, which is why I was trying to tight= en > it up. A definition is meant to be a short summary for quick reference, > while the discussion in 4.1 goes into the more formal details. Otherwise= , > you would just repeat the entire section 4.1 in section 1.3. This is why > it doesn't need to be in separate sentences. The "and/or" is because not > every usage of the encapsulation will need both the SFP identification an= d > the metadata, so the definition needs to concisely convey that. > >> > >> Cheers, > >> Andy > >> > >> On Thu, Aug 7, 2014 at 8:51 AM, Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > >> Thank you for going back and checking, Andy! > >> > >> Which specific part of the current definition do you believe is loose > enough to need tightening? > >> > >> I believe that your new proposal falls shorter than the existing text > in a few areas: > >> =E2=80=A2 First, it combines two different functions (SFP identificati= on and > metadata/context information) into a single sentence. This opposes the > change we just made based on your preference in Section 4.1, which breaks > the two functions into two sentences, for reader clarity. While longer, > it's simpler. > >> =E2=80=A2 Second, it introduces an extraneous "and/or" that would chan= ge the > meaning, and negate the "at a minimum" existing bit. That would not be > simplifying. > >> =E2=80=A2 Third, there is no third but three bullets look better :-) > >> > >> Net-net, the original text, even when longer in character count, seems > more clear and simpler to the reader (because of the separated sentences)= , > IMHO. > >> > >> Thanks, > >> > >> Carlos. > >> > >> On Aug 7, 2014, at 8:20 AM, Andrew G. Malis wrote: > >> > >> > >> Carlos and Joel, > >> > >> In light of the previous discussions, I went back and re-read this > current definition of SFC Encapsulation in the text (section 1.3): > >> > >> SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP > >> identification, and is used by the SFC-aware functions, such as > >> the SFF and SFC-aware SFs. The SFC Encapsulation is not used > >> for network packet forwarding. In addition to SFP > >> identification, the SFC encapsulation carries dataplane context > >> information, also referred to as metadata. > >> > >> I think this could be tightened up to make simpler for the reader: > >> > >> SFC Encapsulation: A data plane encapsulation that identifies the SFP > and/or provides metadata (data plane context information). The SFP > Encapsulation is used by the SFC-aware functions, such as the SFF and > SFC-aware SFs, and is not used for network packet forwarding. > >> > >> Thanks, > >> Andy > >> > >> > >> > >> _______________________________________________ > >> sfc mailing list > >> sfc@ietf.org > >> https://www.ietf.org/mailman/listinfo/sfc > > --001a1132ec32fe387e0500252439 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Carlos,

I agree that the charter requir= es the encapsulation to support each of the bullet items, but there's n= o requirement that every encapsulated packet will need all of the bullet it= ems supported, so I'm trying to keep the text as flexible as possible t= o not preclude possible solutions.

Cheers,
Andy


On Fri, Aug 8, 2014 at 11:09 AM, C= arlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
Hi, Andrew,

On Aug 8, 2014, at 8:53 AM, Dolganow, Andrew (Andrew) <andrew.dolganow@alcatel-lucent.com= > wrote:

> I agree that we should have stronger separation of two functions: SFP = and metadata.
>
> How about small edit to what Andy proposed:
>
> SFC Encapsulation: =C2=A0A data plane encapsulation that encodes eithe= r one or both of
> - the SFP
> - metadata (data plane context information).

Looking at http://datatracker.ietf.org/wg/sfc/charter/, there is n= o "either one or both of". In fact, looking at the history of the= charter text, the text for SFC Encapsulation is a bullet list form of a lo= nger sentence that includes "and" only (see 00-09).

Thanks,

Carlos.

>> The SFP Encapsulation is used by the SFC-aware functions, such as = the SFF and SFC-aware SFs, and is not used for network packet forwarding. >
>
> Andrew
>
> Sent from my iPhone
>
>> On Aug 7, 2014, at 9:13 PM, "Xuxiaohu" <xuxiaohu@huawei.com> wrote:
>>
>> I fully agree with Andy=E2=80=99s point that not every usage of th= e encapsulation will need both the SFP identification and the metadata. It= =E2=80=99s better that the SFC encapsulation could be flexibly used for car= rying SFP identification, metadata or both. Otherwise, it seems that those = SFC approaches which don=E2=80=99t use the SFC encapsulation for SFC select= ion would have to separately define the way of carrying metadata.
>>
>> Best regards,
>> Xiaohu
>>
>> From: sfc [mailto:sfc-boun= ces@ietf.org] On Behalf Of Andrew G. Malis
>> Sent: Thursday, August 07, 2014 9:06 PM
>> To: Carlos Pignataro (cpignata)
>> Cc: Joel M. Halpern; sfc@ietf.org<= /a>
>> Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged= -sfc-architecture-01.txt
>>
>> Carlos,
>>
>> When I re-read the definition, it seemed to me to be more of a str= ing of thoughts than a concise definition, which is why I was trying to tig= hten it up. A definition is meant to be a short summary for quick reference= , while the discussion in 4.1 goes into the more formal details. =C2=A0Othe= rwise, you would just repeat the entire section 4.1 in section 1.3. =C2=A0T= his is why it doesn't need to be in separate sentences. The "and/o= r" is because not every usage of the encapsulation will need both the = SFP identification and the metadata, so the definition needs to concisely c= onvey that.
>>
>> Cheers,
>> Andy
>>
>> On Thu, Aug 7, 2014 at 8:51 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
>> Thank you for going back and checking, Andy!
>>
>> Which specific part of the current definition do you believe is lo= ose enough to need tightening?
>>
>> I believe that your new proposal falls shorter than the existing t= ext in a few areas:
>> =E2=80=A2 First, it combines two different functions (SFP identifi= cation and metadata/context information) into a single sentence. This oppos= es the change we just made based on your preference in Section 4.1, which b= reaks the two functions into two sentences, for reader clarity. While longe= r, it's simpler.
>> =E2=80=A2 Second, it introduces an extraneous "and/or" t= hat would change the meaning, and negate the "at a minimum" exist= ing bit. That would not be simplifying.
>> =E2=80=A2 Third, there is no third but three bullets look better := -)
>>
>> Net-net, the original text, even when longer in character count, s= eems more clear and simpler to the reader (because of the separated sentenc= es), IMHO.
>>
>> Thanks,
>>
>> Carlos.
>>
>> On Aug 7, 2014, at 8:20 AM, Andrew G. Malis <agmalis@gmail.com> wrote:
>>
>>
>> Carlos and Joel,
>>
>> In light of the previous discussions, I went back and re-read this= current definition of SFC Encapsulation in the text (section 1.3):
>>
>> =C2=A0 SFC Encapsulation: =C2=A0The SFC Encapsulation provides at = a minimum SFP
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0identification, and is used by the SFC-= aware functions, such as
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0the SFF and SFC-aware SFs. =C2=A0The SF= C Encapsulation is not used
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0for network packet forwarding. =C2=A0In= addition to SFP
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0identification, the SFC encapsulation c= arries dataplane context
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0information, also referred to as metada= ta.
>>
>> I think this could be tightened up to make simpler for the reader:=
>>
>> SFC Encapsulation: =C2=A0A data plane encapsulation that identifie= s the SFP and/or provides metadata (data plane context information). The SF= P Encapsulation is used by the SFC-aware functions, such as the SFF and SFC= -aware SFs, and is not used for network packet forwarding.
>>
>> Thanks,
>> Andy
>>
>>
>>
>> _______________________________________________
>> sfc mailing list
>> sfc@ietf.org
>> https://www.ietf.org/mailman/listinfo/sfc


--001a1132ec32fe387e0500252439-- From nobody Sat Aug 9 05:52: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 B815C1B27CB for ; Sat, 9 Aug 2014 05:52:23 -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, RP_MATCHES_RCVD=-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 rYKvFQWtmJBm for ; Sat, 9 Aug 2014 05:52:20 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 977C21ABB32 for ; Sat, 9 Aug 2014 05:52:20 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 0F28154CA7155; Sat, 9 Aug 2014 12:52:17 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s79CqHG1020869 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 9 Aug 2014 08:52:18 -0400 Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.186]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Sat, 9 Aug 2014 08:52:17 -0400 From: "Dolganow, Andrew (Andrew)" To: "Andrew G. Malis" Thread-Topic: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt Thread-Index: AQHPsjoEpUaq91+aSUyfBy1ywE3Zo5vFa98AgAAELYCAAMs3gIAAw3mAgAAmDwCAAF5EgIAAufx2 Date: Sat, 9 Aug 2014 12:52:17 +0000 Message-ID: <3E3F067D-5D96-4631-94BB-F9D5377853E5@alcatel-lucent.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A4805@NKGEML512-MBS.china.huawei.com> <57B2ECF6-8DB4-4E23-BB14-E030EB74E09C@alcatel-lucent.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3E3F067D5D96463194BBF9D5377853E5alcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/pReWm0okcExcC1OhwEirqq843XA Cc: "Carlos Pignataro \(cpignata\)" , Xiaohu Xu , "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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: Sat, 09 Aug 2014 12:52:23 -0000 --_000_3E3F067D5D96463194BBF9D5377853E5alcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Agree with Andy. Andrew Sent from my iPhone On Aug 8, 2014, at 5:47 PM, "Andrew G. Malis" > wrote: Carlos, I agree that the charter requires the encapsulation to support each of the = bullet items, but there's no requirement that every encapsulated packet wil= l need all of the bullet items supported, so I'm trying to keep the text as= flexible as possible to not preclude possible solutions. Cheers, Andy On Fri, Aug 8, 2014 at 11:09 AM, Carlos Pignataro (cpignata) > wrote: Hi, Andrew, On Aug 8, 2014, at 8:53 AM, Dolganow, Andrew (Andrew) > wrote: > I agree that we should have stronger separation of two functions: SFP and= metadata. > > How about small edit to what Andy proposed: > > SFC Encapsulation: A data plane encapsulation that encodes either one or= both of > - the SFP > - metadata (data plane context information). Looking at http://datatracker.ietf.org/wg/sfc/charter/, there is no "either= one or both of". In fact, looking at the history of the charter text, the = text for SFC Encapsulation is a bullet list form of a longer sentence that = includes "and" only (see 00-09). Thanks, Carlos. >> The SFP Encapsulation is used by the SFC-aware functions, such as the SF= F and SFC-aware SFs, and is not used for network packet forwarding. > > > Andrew > > Sent from my iPhone > >> On Aug 7, 2014, at 9:13 PM, "Xuxiaohu" > wrote: >> >> I fully agree with Andy=92s point that not every usage of the encapsulat= ion will need both the SFP identification and the metadata. It=92s better t= hat the SFC encapsulation could be flexibly used for carrying SFP identific= ation, metadata or both. Otherwise, it seems that those SFC approaches whic= h don=92t use the SFC encapsulation for SFC selection would have to separat= ely define the way of carrying metadata. >> >> Best regards, >> Xiaohu >> >> From: sfc [mailto:sfc-bounces@ietf.org] On = Behalf Of Andrew G. Malis >> Sent: Thursday, August 07, 2014 9:06 PM >> To: Carlos Pignataro (cpignata) >> Cc: Joel M. Halpern; sfc@ietf.org >> Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-a= rchitecture-01.txt >> >> Carlos, >> >> When I re-read the definition, it seemed to me to be more of a string of= thoughts than a concise definition, which is why I was trying to tighten i= t up. A definition is meant to be a short summary for quick reference, whil= e the discussion in 4.1 goes into the more formal details. Otherwise, you = would just repeat the entire section 4.1 in section 1.3. This is why it do= esn't need to be in separate sentences. The "and/or" is because not every u= sage of the encapsulation will need both the SFP identification and the met= adata, so the definition needs to concisely convey that. >> >> Cheers, >> Andy >> >> On Thu, Aug 7, 2014 at 8:51 AM, Carlos Pignataro (cpignata) > wrote: >> Thank you for going back and checking, Andy! >> >> Which specific part of the current definition do you believe is loose en= ough to need tightening? >> >> I believe that your new proposal falls shorter than the existing text in= a few areas: >> =95 First, it combines two different functions (SFP identification and m= etadata/context information) into a single sentence. This opposes the chang= e we just made based on your preference in Section 4.1, which breaks the tw= o functions into two sentences, for reader clarity. While longer, it's simp= ler. >> =95 Second, it introduces an extraneous "and/or" that would change the m= eaning, and negate the "at a minimum" existing bit. That would not be simpl= ifying. >> =95 Third, there is no third but three bullets look better :-) >> >> Net-net, the original text, even when longer in character count, seems m= ore clear and simpler to the reader (because of the separated sentences), I= MHO. >> >> Thanks, >> >> Carlos. >> >> On Aug 7, 2014, at 8:20 AM, Andrew G. Malis > wrote: >> >> >> Carlos and Joel, >> >> In light of the previous discussions, I went back and re-read this curre= nt definition of SFC Encapsulation in the text (section 1.3): >> >> SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP >> identification, and is used by the SFC-aware functions, such as >> the SFF and SFC-aware SFs. The SFC Encapsulation is not used >> for network packet forwarding. In addition to SFP >> identification, the SFC encapsulation carries dataplane context >> information, also referred to as metadata. >> >> I think this could be tightened up to make simpler for the reader: >> >> SFC Encapsulation: A data plane encapsulation that identifies the SFP a= nd/or provides metadata (data plane context information). The SFP Encapsula= tion is used by the SFC-aware functions, such as the SFF and SFC-aware SFs,= and is not used for network packet forwarding. >> >> Thanks, >> Andy >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc --_000_3E3F067D5D96463194BBF9D5377853E5alcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Agree with Andy. 

Andrew

Sent from my iPhone

On Aug 8, 2014, at 5:47 PM, "Andrew G. Malis" <agmalis@gmail.com> wrote:

Carlos,

I agree that the charter requires the encapsulation to support each of= the bullet items, but there's no requirement that every encapsulated packe= t will need all of the bullet items supported, so I'm trying to keep the te= xt as flexible as possible to not preclude possible solutions.

Cheers,
Andy


On Fri, Aug 8, 2014 at 11:09 AM, Carlos Pignatar= o (cpignata) <cpignata@cisco.com> wrote:
Hi, Andrew,

On Aug 8, 2014, at 8:53 AM, Dolganow, Andrew (Andrew) <andrew.dolganow@alcatel-lucent.com= > wrote:

> I agree that we should have stronger separation of two functions: SFP = and metadata.
>
> How about small edit to what Andy proposed:
>
> SFC Encapsulation:  A data plane encapsulation that encodes eithe= r one or both of
> - the SFP
> - metadata (data plane context information).

Looking at http://datatracker.ietf.org/wg/sfc/charter/, there is no "either o= ne or both of". In fact, looking at the history of the charter text, t= he text for SFC Encapsulation is a bullet list form of a longer sentence th= at includes "and" only (see 00-09).

Thanks,

Carlos.

>> The SFP Encapsulation is used by the SFC-aware functions, such as = the SFF and SFC-aware SFs, and is not used for network packet forwarding. >
>
> Andrew
>
> Sent from my iPhone
>
>> On Aug 7, 2014, at 9:13 PM, "Xuxiaohu" <xuxiaohu@huawei.com> wrote:
>>
>> I fully agree with Andy=92s point that not every usage of the enca= psulation will need both the SFP identification and the metadata. It=92s be= tter that the SFC encapsulation could be flexibly used for carrying SFP ide= ntification, metadata or both. Otherwise, it seems that those SFC approaches which don=92t use the SFC encapsulation= for SFC selection would have to separately define the way of carrying meta= data.
>>
>> Best regards,
>> Xiaohu
>>
>> From: sfc [mailto:sfc-boun= ces@ietf.org] On Behalf Of Andrew G. Malis
>> Sent: Thursday, August 07, 2014 9:06 PM
>> To: Carlos Pignataro (cpignata)
>> Cc: Joel M. Halpern; sfc@ietf.org<= /a>
>> Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged= -sfc-architecture-01.txt
>>
>> Carlos,
>>
>> When I re-read the definition, it seemed to me to be more of a str= ing of thoughts than a concise definition, which is why I was trying to tig= hten it up. A definition is meant to be a short summary for quick reference= , while the discussion in 4.1 goes into the more formal details.  Otherwise, you would just repeat the entire= section 4.1 in section 1.3.  This is why it doesn't need to be in sep= arate sentences. The "and/or" is because not every usage of the e= ncapsulation will need both the SFP identification and the metadata, so the definition needs to concisely convey that.
>>
>> Cheers,
>> Andy
>>
>> On Thu, Aug 7, 2014 at 8:51 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
>> Thank you for going back and checking, Andy!
>>
>> Which specific part of the current definition do you believe is lo= ose enough to need tightening?
>>
>> I believe that your new proposal falls shorter than the existing t= ext in a few areas:
>> =95 First, it combines two different functions (SFP identification= and metadata/context information) into a single sentence. This opposes the= change we just made based on your preference in Section 4.1, which breaks = the two functions into two sentences, for reader clarity. While longer, it's simpler.
>> =95 Second, it introduces an extraneous "and/or" that wo= uld change the meaning, and negate the "at a minimum" existing bi= t. That would not be simplifying.
>> =95 Third, there is no third but three bullets look better :-)
>>
>> Net-net, the original text, even when longer in character count, s= eems more clear and simpler to the reader (because of the separated sentenc= es), IMHO.
>>
>> Thanks,
>>
>> Carlos.
>>
>> On Aug 7, 2014, at 8:20 AM, Andrew G. Malis <agmalis@gmail.com> wrote:
>>
>>
>> Carlos and Joel,
>>
>> In light of the previous discussions, I went back and re-read this= current definition of SFC Encapsulation in the text (section 1.3):
>>
>>   SFC Encapsulation:  The SFC Encapsulation provides at = a minimum SFP
>>        identification, and is used by the SFC-= aware functions, such as
>>        the SFF and SFC-aware SFs.  The SF= C Encapsulation is not used
>>        for network packet forwarding.  In= addition to SFP
>>        identification, the SFC encapsulation c= arries dataplane context
>>        information, also referred to as metada= ta.
>>
>> I think this could be tightened up to make simpler for the reader:=
>>
>> SFC Encapsulation:  A data plane encapsulation that identifie= s the SFP and/or provides metadata (data plane context information). The SF= P Encapsulation is used by the SFC-aware functions, such as the SFF and SFC= -aware SFs, and is not used for network packet forwarding.
>>
>> Thanks,
>> Andy
>>
>>
>>
>> _______________________________________________
>> sfc mailing list
>> sfc@ietf.org
>> https://www.ietf.org/mailman/listinfo/sfc


--_000_3E3F067D5D96463194BBF9D5377853E5alcatellucentcom_-- From nobody Sun Aug 10 06:20: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 A933C1A0717 for ; Sun, 10 Aug 2014 06:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.67 X-Spam-Level: X-Spam-Status: No, score=-0.67 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, 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 xx7Y1YOtdF1w for ; Sun, 10 Aug 2014 06:20:55 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4D52E1A03A1 for ; Sun, 10 Aug 2014 06:20:55 -0700 (PDT) Received: from [192.168.1.145] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 4C114284ECC2; Sun, 10 Aug 2014 09:20:53 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_8279B8BC-304C-4C57-B4D1-26D3E9AFC115"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Sun, 10 Aug 2014 09:20:52 -0400 Message-Id: <43865177-7D1E-466E-99C9-894886C6868A@lucidvision.com> References: To: Guichard Jim X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/yXl6U_5M5RXV3seLuo3I0LnoV3E Cc: "sfc@ietf.org" Subject: Re: [sfc] SFC Problem Statement to IESG 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, 10 Aug 2014 13:20:56 -0000 --Apple-Mail=_8279B8BC-304C-4C57-B4D1-26D3E9AFC115 Content-Type: multipart/alternative; boundary="Apple-Mail=_0D5C0EB9-BB92-40DC-A53C-BA9B88A67388" --Apple-Mail=_0D5C0EB9-BB92-40DC-A53C-BA9B88A67388 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii No IPR from me. On Aug 8, 2014:3:48 PM, at 3:48 PM, Jim Guichard (jguichar) = wrote: > Dear WG: >=20 > http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ has = been updated in accordance with the comments and suggestions made on the = mailing list and during our recent face-to-face meeting in Toronto. The = next step is to send the document to the IESG for review and approval.=20= >=20 > For the authors of this document, please confirm to the mailing list = that all relevant IPR you are aware of has been properly disclosed.=20 >=20 > If you are on the SFC WG mailing list but are not listed as an author = or contributor, then please explicitly respond only if you are aware of = any IPR that has not yet been disclosed in conformance with IETF rules. >=20 > Jim >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail=_0D5C0EB9-BB92-40DC-A53C-BA9B88A67388 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii No IPR from me.

On Aug 8, 2014:3:48 PM, at 3:48 PM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:

Dear WG:

http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ has been updated in accordance with the comments and suggestions made on the mailing list and during our recent face-to-face meeting in Toronto. The next step is to send the document to the IESG for review and approval. 

For the authors of this document, please confirm to the mailing list that all relevant IPR you are aware of has been properly disclosed. 

If you are on the SFC WG mailing list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

Jim





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

--Apple-Mail=_0D5C0EB9-BB92-40DC-A53C-BA9B88A67388-- --Apple-Mail=_8279B8BC-304C-4C57-B4D1-26D3E9AFC115 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 iQIcBAEBCgAGBQJT53G1AAoJEPcO+I7eiUJZk1oQAKNSUpK8QSov3+y4zWiZ8J+N aAOPPgKZLiUUX/emCctZ12g/63Jj/xwyNWuBASxM6tabgqFFWUTWI6AgEYFYKaBs k0QRx7LXoWmaEDjBt8UHAj3m1LXZWtV3vwiFFmIpO8pkCySQgJWwu50UGAu0XcxR A74NwLHn0/yqJ0QB2+zPr2qd3GJ8OdYTCZd5DtDFQ7iOt/C8ychBpy5s3ibskebJ TuMNeiEomQB9MvBGsY9Lkua20qEm/qMh++bJQttCnBa+G3AXfQhsBWMcs3eBUmPF CQYP5rJlCeha9TDWmEXDoXa5bxmKstPx7Q4yZ2iapdwuQ+89TgSSvTIM9TlUcY2u COnEkz3qBsJyUJ5qVZeMgoXTMOcvSjq+hXMU2+qvB3SWfopihIs1iWo7U6dvFyym yBeXm3wPSJ/Gw7HyTrFaI7fhHPn+iHq70g2TAMc5mD/n4oJTUpdjLlim7ZDj2M57 nmUTZxdFOD/d75l7t25b7+IjE06thEPnn4fO0Ux645IwCxjHfO1Q06nRJcMYVkMV 8Ol3LT4NFOrSVHEPiHbmuLB6dnxnPKODhirddsJw+XaCv0G2ZOYEMiUgKExsIoyj F5xV3M7PXlJjA/shaFC2ZDhbijpum1/gNryVROsqPssKIz1WBMAlfRa0XOl5tqNA 6A/UXoVVLNqaFHxMGLRn =Esge -----END PGP SIGNATURE----- --Apple-Mail=_8279B8BC-304C-4C57-B4D1-26D3E9AFC115-- From nobody Mon Aug 11 01:54: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 739DD1A0382 for ; Mon, 11 Aug 2014 01:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, 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 SSUN3k1QDCYb for ; Mon, 11 Aug 2014 01:54:46 -0700 (PDT) Received: from mailgw.allot.com (mailgw.allot.com [199.203.223.210]) by ietfa.amsl.com (Postfix) with ESMTP id 916B21A0391 for ; Mon, 11 Aug 2014 01:54:42 -0700 (PDT) Received: from PUMA.ALLOT.LOCAL (Not Verified[199.203.223.202]) by mailgw.allot.com with MailMarshal (v7, 2, 3, 6978) id ; Mon, 11 Aug 2014 11:54:40 +0300 Received: from LION.ALLOT.LOCAL ([172.20.20.40]) by PUMA.ALLOT.LOCAL ([199.203.223.202]) with mapi id 14.03.0123.003; Mon, 11 Aug 2014 11:56:23 +0300 From: Alla Goldner To: "Carlos Pignataro (cpignata)" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.txt Thread-Index: AQHPr2AigUDp9PUKd0KN/JsZgTmzp5vLI0nw Date: Mon, 11 Aug 2014 08:56:23 +0000 Message-ID: References: <20140803211558.28482.8328.idtracker@ietfa.amsl.com> <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> In-Reply-To: <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.17.17.81] Content-Type: multipart/related; boundary="_004_A6B8F2A767638641889989BC1BA7047934A766A7LIONALLOTLOCAL_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/pCkp-myoQ1RpPJTAGs5QqN3XhdQ Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.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, 11 Aug 2014 08:54:49 -0000 --_004_A6B8F2A767638641889989BC1BA7047934A766A7LIONALLOTLOCAL_ Content-Type: multipart/alternative; boundary="_000_A6B8F2A767638641889989BC1BA7047934A766A7LIONALLOTLOCAL_" --_000_A6B8F2A767638641889989BC1BA7047934A766A7LIONALLOTLOCAL_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Carlos, Joel, all, Thanks for providing this merged architecture document! According to the model in figure 3 and section 4.5, the network (underlay= ) components are responsible for: * Finding the network path to reach the next SF (next SFF) in the= =20SFP. * Encapsulate/de-capsulate the underlay network transport. Section 4.3 (SFF) contradicts this and says the network encapsulation/de-= capsulation is done by the SFF. I believe that the section 4.3 should be fixed in this regard. The reason= =20is that network transport functions should not necessarily be coupled = with the SFF. Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com www.allot.com [291X55_signature (2)] From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro (cp= ignata) Sent: Monday, August 04, 2014 12:19 AM To: sfc@ietf.org Subject: [sfc] Fwd: New Version Notification for draft-merged-sfc-archite= cture-01.txt SFCers, After Toronto, Joel and I have been working on resolving the key open dis= cussion items, and incorporating all the input and feedback received thus= =20into this document as the vehicle for a single SFC Architecture item t= o progress. While we are still working on the document, we wanted to get a version ou= t early to the WG to test the resolution to key open items, see what we m= ight still be missing, and iterate. Please review and let us know. Thanks, Carlos & Joel. Begin forwarded message: From: > Subject: New Version Notification for draft-merged-sfc-architecture-01.tx= t Date: August 3, 2014 at 5:15:58 PM EDT To: Joel Halpern >, Carlo= s Pignataro >, "Joel M. Hal= pern" >, Carlos Pignataro= =20> A new version of I-D, draft-merged-sfc-architecture-01.txt has been successfully submitted by Carlos Pignataro and posted to the IETF repository. Name: draft-merged-sfc-architecture Revision: 01 Title: Service Function Chaining (SFC) Architecture Document date: 2014-08-03 Group: Individual Submission Pages: 25 URL: http://www.ietf.org/internet-drafts/draft-merged-sfc-arch= itecture-01.txt Status: https://datatracker.ietf.org/doc/draft-merged-sfc-archite= cture/ Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-= 01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-archi= tecture-01 Abstract: =20 This document describes an architecture for the specification, =20 creation, and ongoing maintenance of Service Function Chains (SFC) in= =20 a network. It includes architectural concepts, principles, and =20 components used in the construction of composite services through =20 deployment of SFCs. This document does not propose solutions, =20 protocols, or extensions to existing protocols. 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. The IETF Secretariat #########################################################################= ##################### This message is intended only for the designated recipient(s).It may cont= ain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or dist= ribute this message. If you have mistakenly received this message, please notify the sender by= =20a reply e-mail and delete this message.=20 Thank you. #########################################################################= ##################### --_000_A6B8F2A767638641889989BC1BA7047934A766A7LIONALLOTLOCAL_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =

Dear Carlos, Joel, al= l,

 

Thanks for providing = this merged architecture document!

 

According to the mode= l in figure 3 and section 4.5, the network (underlay) components are resp= onsible for:

•  &n= bsp;      Finding the network path to reach the = next SF (next SFF) in the SFP.

•  &n= bsp;      Encapsulate/de-capsulate the underlay = network transport.

 

Section 4.3 (SFF) con= tradicts this and says the network encapsulation/de-capsulation is done b= y the SFF.

 

I believe that the se= ction 4.3 should be fixed in this regard. The reason is that network tran= sport functions should not necessarily be coupled with the SFF.

 

Best regards,

 

= Alla Goldner

= Director of Mobile Technologies and Standards

All= ot Communications

Tel= =20+972 9 7619251<= /span>

Cel= l +972 54 2493985<= o:p>

Fax= =20+972 9 7443626<= /span>

= agoldner@allot.com

www.allot= .com

 

= 3D"291X55_signature=

=

 

 

From: sf= c [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpignata)
Sent: Monday, August 04, 2014 12:19 AM
To: sfc@ietf.org
Subject: [sfc] Fwd: New Version Notification for draft-merged-sfc-= architecture-01.txt

 

SFCers,<= /p>

After Toronto, Joel= =20and I have been working on resolving the key open discussion items, an= d incorporating all the input and feedback received thus into this d= ocument as the vehicle for a single SFC Architecture =20item to progress.

While we are still working on the document, we wanted to get a version ou= t early to the WG to test the resolution to key open items, see what= =20we might still be missing, and iterate.

Please review and let us know.

Thanks,

Carlos & Joel.

Begin forwarded message:



Subject: New Version Notification for draft-mer= ged-sfc-architecture-01.txt

Date: August 3, 2014 at 5:15:58 PM EDT

To: Joel Halpern <jmh@joelhalpe= rn.com>, Carlos Pignataro <cpignata@cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, =20Carlos Pignataro <cpignata@ci= sco.com>

 


A new version of I-D, draft-merged-sfc-architecture-01.txt
has been successfully submitted by Carlos Pignataro and posted to the
= IETF repository.

Name: draft-merged-sfc-architecture=
Revision: 01
Title: Service Function Chaining (S= FC) Architecture
Document date: 2014-08-03
Group: Individual Submission
Pages: 25
URL:            http://www.ietf.org/internet-drafts/draft-merged-sfc-architec= ture-01.txt
Status:         https://datatr= acker.ietf.org/doc/draft-merged-sfc-architecture/
Htmlized:       http://tools.ietf.org/html/d= raft-merged-sfc-architecture-01
Diff:           = http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-01
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, principl= es, and
  components used in the construction of composite services thr= ough
  deployment of SFCs.  This document does not propose solu= tions,
  protocols, or extensions to existing protocols.




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.

The IETF Secretariat

 

This message is intended only for the designated recipient(s). It may con= tain=20 confidential or proprietary information. If you are not the designated=20 recipient, you may not review, copy or distribute this message. If you ha= ve=20 mistakenly received this message, please notify the sender by a reply e-m= ail and=20 delete this message. Thank you.

--_000_A6B8F2A767638641889989BC1BA7047934A766A7LIONALLOTLOCAL_-- --_004_A6B8F2A767638641889989BC1BA7047934A766A7LIONALLOTLOCAL_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=29141; creation-date="Mon, 11 Aug 2014 08:56:23 GMT"; modification-date="Mon, 11 Aug 2014 08:56:23 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABkAAD/7gAOQWRvYmUA ZMAAAAAB/9sAhAABAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAgIC AgICAgICAgIDAwMDAwMDAwMDAQEBAQEBAQIBAQICAgECAgMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwP/wAARCAA3ASMDAREAAhEBAxEB/8QAyAAAAQQCAwEB AAAAAAAAAAAACAUGBwkECgACAwsBAQABBQADAQEAAAAAAAAAAAAIBAUGBwkAAQMCChAAAAcAAQMD AgMEBAkLBQAAAQIDBAUGBwgAERITFAkhFTEiFkFRMiNhQjUXcWJyMzQ3GDgKUqJzVHQlVTZWVxlj JGRlZhEAAgIBAwMCAwUDCAcFCAMAAQIDBAUREgYAEwchCDEiFEFhMiMVUTMWcaFCUmJyNAmBkUNT JFQXY3ODZDWx0ZKiRHQmNjcYOP/aAAwDAQACEQMRAD8A365KSYQ8e9lZV43j42ObLPHz52qRBs0a t0zKruF1lBAiaSSZREREfw6bsvlsZgcXYzeasRVcRUheWaaVgkcUcalnd2OgVVUEknpRUqWr9qOl SjeW3K4REUEszMdAoA9SSfQdBK63TYdsl38Hx0rreKq8e5OxkNQtaAJMyrkEoKfb0HSLpAFSFOBv blbPHQEMUyhW49yhnbd9yHnz3EZy1xz2oYqKhw2rKYZuQ5JNse8aamBJEkQEAhuyILVnYyPIlYkq CKh8bcC8d0Isl5YttPmZUDpjqx1YqfhvKlTodNN5kij1BCGUevWeXA+SLlIZB9yckkJsf5gM2EQ/ CCBX8fAUyTDMpku4dvo2KHb+r+zpyX2xe7W5H+q5HzFdiz/4uzDWm+k3faugswgrr9orKNP6H2FK fJ/iSF/pa3DoWx3w3vKne0/bqYn9f/EP8vSM70zkfx/USdbBEx2n52VRNN5daqkkhIRBFjEIVR+k VtH+1TSMfx7u0PRVOIF92Tpiu+Xfdt7YJkt+dqNXmfiveFlyuOVUsVQxAUyqI4NgUnb/AMTB25XK oLsZI6cIOH+JPKKmHgU8uG5WQSlSySY5SATohLPuJ01/KfcoBPYbozajbq9eq/HWeryKMpDSaXqN 3CXcpyHKPis2comAFWztsoAkUTOAGIYOwh1oBwXnXFvJPFqnMuGW47mAuJuSRfQgj0aORDo0csba rJGwDKw0I+HQ/Z3BZXjWUlw2ZiaHIQtoyn4EfYykejKw9VYehHTk6l3TR1zrnXOtd35KvnhpfF+0 WHC+McFX9c2euOXMRdLjOruV8vzqcbnOg8rxUIh2ykLxbopYhk3qCDpoxjnHZJVddwm5aIlH4m9t +Q5hTi5Hy+SWjgJQGiiQAWJ0PqH1YFYYmHqhKs7r8wVVKOw1+UfcFR4pbl4/xWOO7nIiVlkckwQu PQpopBlkX4MAyqh9CzMGRdc+wfLd8pGsSzyVj+Q2lIkTcKOAiszqsBXomLTMIHI1BvVKwgso2QIU AKLtVdQS/UxzCIiJT1fCXh3CwrDLi6hJGm6xI7s336ySEan+yAP2AdDPZ8x+WcxM0seStAa67YI0 RV+7SNAdB/aJP7Sep1wD59ufmK2Fu31Weg+QVTbuUkpeqaNXomtWZFskXwcIw90qURESsdJqdg/m ybaXSIICPoCIj3jnJvbT405BVLYaOTGXSDtkgdpIyT8C0UjMrL90bRE/1upBx33EeRMFZC5eSPJU wfmjmRUcD7Qssaqyt97rIB/V63D+EXOzCuemWm0bHJZw3lIRVnHaFnU8Ldvc89nHiKqrZnNM0FVU XcTKlbLHjpNuY7N8RFQpTEcIOW6AK+QvHPI/G2Y/Ss8gMMgLQTpqYp0BAJQkAhl1AeNtGQkEgqyM xqcD8gcf8hYn9TwjkSxkLNC+glhcjUBgPQq2h2OuquAR6MrKpndQLqcdc651zqB9r3quY60YsTM3 Nmu894J1unRYHUkH6iypm7ddyCCThdBqs5KKaQETUWcKFMVMggRQ6Y0e4f3NcU8C0q+NNebMeRsn oKGKratNMXYxo8mxXeOJpAY4wqPLPIGSGNgkzxWZ478Y5bn08lkSJT45W1Ni1JoEQAbmVdSoZguj NqyqikF2BZFeE2dP5g6eBZayX+HxuJeACiFcgmXu5pogcAUSFYzNYqzZYxD9jEVklTkMHYxSj9AH ilwL35eY1Ga5bymhwHC2NGSjSi7lqJD6rvMTB0YqdGSS+7owIZFIK9WJPnvAvDSaOIxc/IL0fo08 z7YWYeh03ghhqPQrXUEHUEj169nWV8tKR3kaXtbHQiNwBY9fuLEzVxJeP4tUnkirNN0/UAR+vrtP +kD8eva34U98PjkHK+P/ACJBykRfMaWUi7bzgf7JZJ2tIpb19e/W/wC8U+vXnDzXwdyP/hOQ8dkx Rf0E9V9yx/2isYiY6f3JP7p+HUg43yLSvM45zu/QDjP9VjAOVzXn5FUGst6SRllFYgXJzqlOLcgr FRE6xVEA9RFZYpVPTtLwF7rovI3IpfFXlDFy8X81VAQ9KYMkVrYu9mq9wlg2wGVYS0geD86CedBI Y4tz/wATycbxycr4xaXKcJm02zoQWi1OgEu0AabiELaKVf5JEjJXcTvRjdU51zrnXOmHo+kVTK6w 7tdufe0YNx9Fs3SAij+TemIdRKPjkDnTKs5UImYwiYxU00ymOoYpCmMFZ+WvLnCvCvDpua85s9nG xnZHGgDT2ZiCUgroSoeRgpPqyoiK0kjpGrMJNxLiOb5rmUwmCi32m9WY6hI01ALyMAdFBIHoCzEh VDMQCJjCy8q94IWYpqcRitAddzxchNNzObBMMj9vTcpILs1pBRNVJQDpLEJHJHDt4GOH5xB7F8u9 6/uXQZ7ga0fHnjCY615rSdy7ahPwkVXieZgykPHKkdKJ102PIPnN42sP4T8Zt9ByAz8i5QnpJHE2 2CJx8VLBggII0ZCZ2H9IKfl6V1cH5LRRCvq/yYeyMqH5jtLFFPjRJj/tKQFZCcTIT/Kan/wdPcvt n93uEjGR4z5gs281pqYr1ab6bd92+e4oX+Wu3SFPJniC6xrZTh8cVL7GglTu6ffokJJ/kkH8vXWu 8iNAzeyR9H5K1hGCGUVFvCaNDFKetyRiAUBO7O3D2hv4gMqZIrdVsUxRUbATyVL3xT3VeUfEnLKv jr3d4ePHC4+ypnqgBoTkaAmXZrHpqQZGjEMkAZDLTWMtKveW8U8X5diJeSeIbjWeyu6ahL6WI9fs UN833KGLrIQdsxbRCa6aiayZFUjkVSVIVRJVMxTpqJnKBiHIcoiU5DlEBAQHsIdaGxSxTxLPAyvC 6hlZSCrKRqCCPQgj1BHoR6jod3Ro2KOCrqdCD6EEfEEfYR1369OvnrGevWkazdyEg6QZMGDZd49e OlSINWjRskZZw5cLqmKmiggiQTHMYQKUoCI/TpHkMhQxNCfK5SaKvjK0LyyyyMEjiijUu8kjsQqI igszMQFAJJ0HXtXrz27CVaqNJZlcIiKCzMzHRVUD1JJIAA9SfToL3m3avssu/guPUG3jq0wWFo/0 uytgTQ9X8vc8c2eJLN0C+BwOVMyDt4ZMxTmRR/DrO3Je5Tzh7guQW+K+03FxV+KVJe1Y5DkE2RK/ pqYUlV0X0IcRGC1aaNkkeCvqR0RNbxrwfx/j4sr5ZtO+VmXfHj651cj+2UIJ9QQW3xRBgVDyfHrN DB+Qjovv33JKYQlh/OLNiyfhEAp+PgAJSDBD0vL/APCAO39Xpevtk921xP1TI+YLcWdPzdmGvP8A S7v2arYgTbr/AOUA0/ofZ14Hyb4jhb6Wtw+J6Pw3vJH3dP2+sbnX/wAb/T0lOdF5C4Oqi41eNZab QBWIk6ttbRRRlooqpiFIZcEm0akAEE/iBXbdMiyggQroBEAFkueYPdZ7YZ47PnulW5f4sMirJlsc qrYrbyAplAjrhdCdoFqBElkKxrdDEArYeHeKfJ8bR8BnlxHKgpK1LJJjl01J26tJrrpr+VIWVQWM JHRg1W0wN1gI2z1mRRlIWVQ9dm7R8g79jCmqiskcCqtnTZYhk1UjgVRNQolMACAh1oDwrmvGfIfG KnMeH247vHr0e+KVNf2kMjqdGSSNgUkjcB43VlYAgjofs1hcnx7JzYfMRNBkIG2sp/1ggj0ZWGhV gSGUggkHpwdSnpr651zrnQiaVyRlv1YrleGVn+8LQkxUSk3g9zVyuCkoCDgz1yVdqgcWaw+Cyqq6 LZBXsn3VUA6RQV8ue7XOnm7+F/bdh/4p8ooWWxMfWhQKnbJ3XDxoxiY7JZJJYq8MpWMtNKJIUvbi HiOj+hrzXyTc/SuKnQxr/t59RquxdGI3j1RVR5HX5tEQq5b7bGOU1oD39x5ChV3KoeqSKp8asdFo ZT8/tlnDNWtt1QRMPj3BM/cA/iH8eopW9vnvR5mgyXPPKn6Lcf5hXxcDlI9fURs0LUEOz8J0STXT 0c/EusvkHwthj9LgOK/Wwj0MlqQAtp6bgriww1+Pqw/kHWE8i+YWREGXZWKH3KuNB8nkIoxOhZva JiBlFmyKgFkXboxREClReuTgP19BT8OkF/C+/PwShzuPy1DyPxOD1lptCUyBjX1Z41IE8jkahVit 2GB0P08vw6UV7vgXnbfQWKljjeWf8EwcNX3H4BiPkVftJeGMfZ3F+PRCY3ttT2iEWkIMVY6YjTAj PVp+cv3KIceRkxEfypi5ZHVIYpFQIQfIolUImoAkAp/AXuJ4R7gePSZLjvcp8gpkLdx85H1FVzqN fgvchZgwSUKp1BWRIpA0Yqvn/jrOePsitXJbZsfMNYbCfu5V+P37XAIJXUjQgqzqQxmTq/eoB0E3 Jd9MaTf8643wD1xHNrScLRe37UwFVb1mOVXVIRMxjgmc6JY9ZUEzgIC6M0MH8IgOd/u8yOd8ueT+ Ke0zjNiWrSzJGRzE0foyUIGdlUEnaSggmlEbghrH0TD1XQkT4frUOI8Xy3lvKRrLNSH09NG+DWJA ASfTXQ70UsD+7E4+30iHadT0XP4YYfIftub5hn98c5AghFx7Z5YH07H1llZFn8gtJsnjGPinSTs3 tgJ5PHi3qOF1DAoUAor3D+Z/LHi7jhwvgw1eJeH+M8lk4yiwQJJenuQUYrzzTPZhliiryiRjAUJt WZBPZsyOZFVJ5484VxPlGQ+v533svzLKYxcoTI7JAkL2HrhEEbq7yKVHc10iiXbFGo2kkXh5CbsJ /U/vYt3fv37AeJAn49+3phFeHb+jt0GX/wDa33J9zufxpmt396DT/wCHsbf9GmnVzf8ASvxrt2/o dDT+SXX/AF9zXopeP266zOKF/X0nHXuiTl4reWvWk1HMGk2hK2+Ofrt3UYqxYN2E3GJIpFLJM3JD KFbn9UhgKVQpzS9rfuS83cjIPlK3W5J44yfI6HHnjtQQR2lsZSGZkeBooY4bVdETS9WnV3ELCWMq olD0t5S8a8Hxq/8A4vDNjOS1sbPkUaKR2hMdWRAyyB3Z4ZCSTBLGQpcbGBJUrImdMz8fOR7/ACRm soTNtVj17PTGSyxzpQcu3I4FWORUWObxIgLFRoUPqqqiqzKYwikHe1fFVKX2u+7S14QpSOPEnNqr 5DFxMxKU7SB9YVZidNvZkrAesksb0BI7NF6xTlk6+U/EsXOp1B5dhJRXtuAAZomK6SEAfFt6yH4K rLYIAD+h39aV9DR1Vx8wnLyc4ccJ7vc6RJKRGoaLLR2Q5rLNznI7gZ+1spR7K2ZkdL86EjXKhCyT pkt/AlIkbibuH5TXF4L4PX535Br0MggfD1UazOp+DpGVCxn9qvK6K4+JQvp+0VN5p5nY4TwSe9QY plrLrXgYfFHkDFnH7Ckauyn7H26/s61Zvhd+MyI516baNQ2pGRX485DIR6E7FoOnzFzqV+kCBJNa T94aHQdM4ONjPF7OLN103wJuWiCIkF2Zw3Mbz75cn8c4iHD8fKjlF5WKMQCK8K/KZdp1Bdm+SEMC mquza7AjCX4N8WQ+QMrLls6GPG6TAOoJBnmPzCLcNCEVfmlIIbRkVdN5Zd0w9nwrjBDwOV0KjsK4 0bNCqQuaZJT45v7NiUoJ+8NDxRY1g3FYqXcTqGBdfxE/5+wm6xj83+63hXjfkkOH5fPmM95BvR91 aNCFr98xan82RWkRY0Oh2h5FZlDFEKqSNQfH/h/J5nENLx6GhjOMV22d2ZlrVw3p8q7VJZvhuIUg Ejc2p6Fnkxw04a/JrntiZ2Cvx0Rp8c0O0iNTiIJvCa1ns4ZFQkYaa+jNxaa8VVESKxr5Vdg4IVUq CiDkhXCNw+2P3jYbk6SZbxdlJbFSlKqX8VaV4ZYCxb5J60mphdtrhLEO5C6MoeTZJH1W/mn28w2I hR5lSjhvTxk1b8G192gGjJKuglQajdDJodrA6IWR+tNPjLrGu/Ev8hnsbsZePHOb2tlm8V+PO5Xi rjl8pIMyy8hHIqCwUkm6sOdrY6+ooCPm4RaHUKCZlEzax8uwuD81+L+5j9G+qrCxTdtA0VhVO1WP rtO7dBMBroC4HqAes4uK5jM+HvJPbv6r9NYNe2g1KyQMRuKj03DbtmhJ01IQn0JHX0YUF0XKKLls sk4buEk10F0FCKorIqkBRJZFVMTEUSUIYBKYBEBAe4dZYMrIxVgQwOhB9CCPsPWmCsrKGUgqRqCP gR+0dYUzKs4GHlZyQP6TCGjX0q9U7gHptI9sq7cn7mEC/lRREfqIB0z8gzdDjOBu8jyrbMZj6k1m Zv6sUEbSyH10Hoik+vS3H0Z8nfgxtUbrViZI0H7Wdgqj/WR0GPFmqr36Ws3JO7pg+s1qmJaNpqTg BVb12vMVjRzlWM9T6EUcKImZJqAHmRm2AAN/OV8s/fZdwuz5PzOX93HkVBZ5fmr9mHFB9Xjo0Ym7 DtX3egZirU43A3pWrkBz9RMCQXmnNRcYo0/EXHD28PSrxSWyvo087juKJNPiFBErD4GWTUj8tNDg 60Z6HHqHdX3XOscYivbJkppZZA60dWIsCPbDJAQO/mkxBQhWjX97hydFuHYfz9/p1Q3mz3JeKfAm MNnnF8HNPGWgx9fSW9PoCdVh3ARRnQ/nTtFD6Eby3ymfcI8a8s59Z7eDrkUVYCSxJqkEev2F9Dub /s4w7n+rp69Dxr1ZmtcxKA3hGEJTNPqUf/eBWCRrhU8s2qKLgZlKDkpEyTczp+SGIV+n4pgRCQL4 pdinUMcV/PXD895w9vOO9yVWgmC8vYKuc1jjXdzYTGJIbUdaedkRpJRVC3o9IlENsGOEKssrSWtw PMY7gvkW140ksnIcNvS/RWDIoETWivaM0cerBUMpMDasS8B1fUqgUo8kvSelZxUrqUEiLTcUmo/T REPSSlGiijGUTSDyMJUQkGqnpgI+XpiHfoyfBnkqLy94lwXkNAiz5GkrTKn4VsxM0NlVGpIQTxyb AfXZt19eqX5zxp+IctvcdbcY605CE/ExsA8ZP37GXdp6a66dSN1bHUT6r5WauuQm/wBtmXUWW1UH B1m0RB1FR6g2jbLbF33pLKu1nnlHqNEF2CzxYDAYrhJuzSMU5O4Gy2sVL3uj9z2d5Dbo/rfjXxpJ HVpYxpkir38i8xR2keUGBo1eGW1Lrqs0dejBIkiMwYpopoPFni+jj4pzR5PyZWlmtBGaSvWCagKE +cMwdIk00KM9hwVbQgm7pdNahqhY5iCyxs+mY6KdOYyPLZySzly7KQASBKKjowi8kZITeYt010lF gIJCGAxgHouvIXkXzvgOB5bPcZ4TBYz9WlI9eH9SFp3kGgUirXrCSxs17hgjmjklCGONw7Keqi45 xvgWR5BTx+UzjxY6adVkk+mMSqpPrrLJIVj1/DvZGVCdzAgHoQIzkzyIzgIew7Rnx3dJsr1Zm0VC FLVZxmuiHkKTZA7tdJNVVLyUQbSJEFHhEzCkt9B6AfD+8z3YeIvoOWe4niUknjfL2Hiif6UY+5E6 aEoiFyFYpvkhgvRxPbWNjDOFVmBB3fC/iLmP1GJ8cZYR8lpRh2HeNqB1P2swRSQDoryVy6xFhvj9 R1Otg2TjRulcDPZq3NBPbVGkfHMJKNlouYjJ92oVGIdMHLuPK1ZTLJ+qX0lAVFMT/kMJkzGKYneQ +4n2fe5fiv8A0szWehabONHBBBPWtQWq9yQ7K0kUkkHaisxSsNj9wxE6o5eF3VqsxvjfzL40yp5X j8fJsoK8kkkckUsUkCjWVXVZNzxOgO4bQ2nzAKygjF4mWqfQjrnjNxcGcWXIZw8Kg4MBuzqvKKLE jjImMJjHboih6iPceybVygmUOxOvH2P8z5NUxXIPb/z2VpeWcEyJqxudfzKLM6wbCdSyIULREnRa 89eJQFj9OeccLjJbeP8AIOAUJiM9WEzL/VnABk1/Yx12t/Wkjkc+rdF/0eHVDdBxybkpi5WXOuP9 edKs1L29LM2t0kQTHRrMeuoKYeInKRw2KZg7dqpiJRMZikUDdjmAc+vefm+Q8/5ZxL2scQnkr2uV WhZyUqDVo8dA7HXTUB0UQWrMiaqS9OFA2kjAkH4XpY7AYrLeU8wiyRYqIx1kJ9GsOAP2EqTviiVv UATOdNVB6Kir1iEpsBGVmusUo6HiWxGrRskAd+xfqouup283DtyqIqLKm7nVUMJjCIiPRtcH4Txn xzxWlwvh9VKfHsfCI4o1+71Z3b4ySyMTJLK2rySMzuSzE9UlnM3k+R5WfNZiVpsjYcs7H+ZVHwVF Gioo9FUBQAB0v9Svpp68HTVs+bOGT1ug8Zu0FWrto6RTcNnTZdMyS7dwgqU6SyCyRhKchgEpiiIC HbpLeo0snSmxuShisY6xE0csUqLJHJG6lXjkRgVdHUlWVgVZSQQQevWCeerOlms7R2Y2DI6kqysp 1VlYaEMCAQQdQfUdBTlzdbDuQE5jiSyxqLoTBa20tuuoop9vkkUF1l2yZziYO/tY1y2UExjKKlaN zGHyEQHOTwfUse2r3TZT27wySN4z5PVbKYdJGZuxKEdniVm1/ClexXYszPIlam7HcxBI7nMsfkvx ZV8iuqjk2MlFW4VAHcUlQHIH7WkjkAACqZJgBoBobvWkvQ2dDxyf0t/mOUyb+DOoSzWJ41qtcOiY SuEZCVIuZV03EpiqJuUWLdUEFA+ibkyQj3D6CKvvI8vZPw/4TuZLjjMnL8tYjxtFkJ3pNZDlpU2k MHjhjk7Tj8E7QsQR6G1fDfEKvMebQ1ckAcPUjazOCNVKREaK32FS7LvU/ijDgft6bVNjM94iY+2k Lg7IhMSajNe0SLVt72btFteIGOSGiUEhMs7bRpAOi0SAxUUUEzrHEvkqoMT4BhvFnsX8EQ5PnU6x Zy40T5CZEEtvIZKVCwqV1U6yJAN8ddAyxRxJJYkKGSeQvHILnKvO3PXq4GMtQhDLXRm2Q16ytp3Z SfRWkOjStoXZ2WNQ21FGbm/LbJ9GkncMVeVqMm3ZO5JFG3N2ce2fsI9Azl+qzkWr58wFZk2IZRRF RRNX0wExQMUphKu8R++bwh5Zys+CWW7gstFBLOiZNIYEmhgQyTNFNHNNFuijDSPG7o+xWdFdVcqn 5d4L5xxKmmQKwX6byLGTVZnZHc7UDRsiPo7EKrKpXcQpIJALYac48Uc2AsSf9UtIdRyDZK4O4UqV fMBjgRN6sn7sZprFqd+4LqNCgUv5jgUvcwRKj/mM+3u7y0cdb9Zgwry9tcnJVVaR1ICyMvdNuOFt fSR6ykfF0RdSHif24eQ4cUby/RSXwm41Vl1n+GpQHb2mkH9RZTqfRST6dNLkBDkxnQabyVpCZEWE jLs4HS42OMQGk+xmAAEJgqZDlbqu5JukKCin1IZyDVwICdMxjQX3Q4FfAPlDj/u58dIExtm9HTz1 evt7d2C16iyFBCNJPGrRu/qhsLTslTKjyM++Lr7eQeLZDxDyMlrUUDTY+STXdA8X4otSNwWNjvUf ERmeIEKwANv9QQ3/AIi2/sf9Qf5wP7G/8R/7N/jdaIfxRx//AJuH/AfW/i/+k/3/AP3f9rodP0vI f7p/8R2Ph/tf93/e+7oQYP0i85bl9z/zx8ta/pv1P+SCNU+4e37/AL+y/ft/jf09Afxrtr/mQ8h/ V9e43DIvoN3w/Bju9s+/0n+H9v7+r4yQc+27Hmn+7Gab6jT9utnZu/8Ak/m6cnIrjkjpUNZJ+nun 8dd3beMerQpJErasXWQrpTEiRnWK6Z0E55tGqKtWb8h0DkA5CLmOiUAJMvdf7UIPMHHcryLg09mp 5BlSCZqqzLHQy09Iba5uROpX6yOuZK9S2skJQOsc7NAPkafE/lmTiGQqYvPJFLxxHkQSmPdYqJP6 y9lwQxhaQLJLCQ4JDNGFkJLVGKQc6lNjWFYKYTtASJIf9MmYLffhl1AKZOLLGgArHeqkOBilDuBi CBwHw/N1hPNxblEHJP4Mmxt9eYfVCt9CYJPq/qGICwiDbvMjagqANGUhgdp16OpcljHx36ylmucN 2jL9RvHZ7Q+Mnc+AQEEE/YflI19OrZuN/HEKBA1uxXhxJu7girITzerKyCS1WpkzNNisFnrFg2TB F5awgkyNHD9VRb0yiok38ExEx9yfaP7UT4r4ti+SeQZrk3Nw81xcc0yNj8XasoIWlihjXbLkPpFS Ce1JJME+eKttjG9wd8t+Wv4oydvFccSFMCypC1kIRZtxRNvCO7HVK3eJlSFVTcQry7mACp3JEUB2 riqVDwGTC+vTqgT/AEgIoJCq+sJ/H8/tvVD9v5e4D/T0x+7k1z7hvCa1dv6wOTzFtPx/Td/G7t2n rs3a/drr9/SvxGJB485s0uv0f6YgGv4e5ss6afZu0/0/Do0OtCOh761j/wDic28ybj/xmdoCp+nk diszeUABH0RmXVKWUghOH4CoDJpI+A/sDy/f0XXtEauOTZdG0+qNCMr+3YJRv/nKfzdCt7qlnPHM U66/TC64b9m4xHZ/MH/n6m//AIfK0Umu/GxZp1A6CKtV2fVZDQTIEAHJ5lrX6hItjKFHsK7paomj E0u38fiUgfUO3VZe9nk9TgfI8hzXk7snH8bgBaJ+J7EAnd1Qfa7SLIqIPVnYKPVh1N/afjTnuG18 JiADk7GXeFh/2snaClj9gEZQlvgFGv2dF7mdqt9sPdNAJcIfJ2UnNqur1qUuxbSr986cgCsFntTb ypgTKxhY5EhjJonBwbun5iYhUUx/Op4X5z5B56/JPLEfIcdwPG3cm0ua5NbhjtTzSyDdSwOLjtHa IKddEZo4WFhtYi5eNa8R1T5pguP4FcbxNsdYz1mCsFpYyJ2ijRV9J79povXfNISAzgxjR9oDGRgk obAtVtpptr/XEBfmSxggbDdIaGcViVn6u8cpMjtbjAKNmKAyVfEhV2q5Cm9ZJFHyWUAoFJHYvcRL wD3Gce8gPyfE8qxLf8HkMxUpyY2zexkjrE0eWotHAhs0NqzVZ1Dd6KKuHsShAsS+Tx4md8b5HAjG W8VaUd+vTmmWzFBZRS4apOGdu3PqUlQkbGeTbGm7VtWv/iCjQo/JJePtQoi+DMsnCyekKQn+9DWS mQ9x6f5vV/TpmHbz/N6fj/V8ev2He2RbA8TVWm17TWrJj/ud0g6fd3A/w9Ndft16/P8Ae47sf9T7 Ai07n0tff/e2emv37Nnx+zT7Ot33jEZ6bjXx6NI+f3A2HZMZ/wCp3FT3o0KAF16gm/N5+v5d+/17 9Z58v7Y5ZlBF+6/UbOn8nefT+bo8uKbzxfGmX979BX1/l7Ka/wA/StvSThbGNNI2Kc6v6NmziVMB E3opNDquR7B9fEGxDiP9Hfoafc3Dase3zmMdMMZv4fuHQfHYsRaT/QIwxP3a9Wz4yeKPyDh2mICf qEI9f2lgF/8AmI0+/pu8Xl2avH7LjtTJ+kjWU0FxKIACbxq7doSJVP2FUI9SU8+/18u/fqM+zi3j rHth4dNj2T6ZMTsYjQASxyypOD+wiVX3a/bqT06+ZorCeUs0s4O9rhYfejKpj0+4oV0+7oe7hyk0 Gbu8s7xCpnu+ZZaU394j1s19f9TA7OZFc0G9S7vGyMQkgqq2ValWOv4HWOmZsBDHFznnvL8o8h8h Xb3t2wb8j8Q8OB/W5o0DC+JG2Oaso/NRK6pI9eWuJDJtksyRyVEUtaeB8L8Wx3HIIPI14Y3mOa/w KM2n0+0ajvIfkYykqsiyFQmqxq4mLBRSgMMvOxTLHQYeszaGc6BoaUeMhNzDmwWVtWVnIKSE1JPX Y+/lYVNuis1I8FQfFYSlKApFBUQn457bPJnnrklfyliMRkIPFnI+UJB3bdqS3kY6JkUS2p5XXuz1 0jSSL6pn17o2alQJWu7J+SeN8Bx8nFr9ys3LMXii+yGJYK7WAuiQxovyRylikhi2+q6k6OSguKsY RkXT54HJEUIeOrcoC6QgBUEYxpFr+qQQH6Aim1TEP8kOt5+WDD4bgWTFtY4sBUxFjevwRK8Vd9w0 +G1Y1I/kHQDYn6y7nq3aLNfluR7T9pkaQaH+Usf9fQ18IkXCWBQZliKESXmZxVl5gIALUF00B9Pv /UK6RVKPb+sA9CL/AJdUFyH2x4+S0G7UuRuNET8DH3FQlfu7iSD0/pBvt6t73GSRP5PsrGQXWvCH 0/rbSfX79pU/yEdFx0dHVFdABxesjqpZxrU41rchaXkZqNofWOPh1macyhHMa9HPActWrxVAZRyc qBiJNkzAqocexe4j26y59mvMMhwPxFznk1LD283ep8zyM16Cq8K20rw0oJe5FHMyfUudjpHXRhI7 khNSdOij8x4aDP8ALsFi57kNGCfC1kryShzC0jzum1mQHtKNwZpGG1R8dB69TBmHLHMNCavSyrsc /mo9vJSLqHti6bUpYWOMiJpUsuJE4rsZJwUTIGUK5IIG/IYpfMb58M++Xwv5Xgs18vY/hjkdRJ5p KuScRr9NDsJnW2VSsdQ/rCzrOpSQiN41ErQjm3gbm3Ep4zQj/VsbK8cazVVLEzSa/ldrUy/FSA4U xsCvzBjtEk6eNWtFEeRMjFM7xDWOKCR+yR79uMpL11AzNy/nakBAVNJycK1dJPGoICU6igJlTOU5 yCNs+aX4TzTxhYweVo1+S8fy9IWPo4J4zZtUEMUk93FgB/qbFSKWO3WWEhpXESRSLJJGTDuE/rmE 5THfpzyYzI05+33pEbtRWG3qkFrXTtxzMrQylwQqly6lVbSp6wYBosXcmsNnzBxobF4wZXOk2eIW YotpOvA8RVjH0m4cumjeNfNnZU0lwESgYwgoQPE3YuF3Kfan5Ww3kivgfEkEvKMTaqw5bE5Gq0Qj noGVTBNM8kkSQSo+2OUMy6to6fKyno8cT5X4he47JkeWSpiLUcr07laUOWjn2ESJGqq7SIybmQgH Qaq3qNSbOXKrOOYmxuEGxWaSmfVs0+0SUKsk1sh2FLM4bGWT7pLLoD6hROAiBvEwh+PWlfhea1b9 +/PrcEIrwvxXHm7ErBkjvtDiTJHuX5XdD3FLD0YhyCdT0MHNEjh8CYCKRzI4ytjsORoWrh7YVtD6 hW+U6H1GoB6N7rRrocug0lQFDmxWhfgIg8zNYIQTfgApt7D64JiP7vbuu4B+8es8uQA1v8x3BNlA Stjh8opk/AFYrpfb/ojs6/yn9vRD489324XxV+MeYTvf6Wg01/8Aii/1dSZpOwSme6hmNTdRkYWp X1ZVg5sLxR0RwzlCOCtStkRIcrVMgKPGgiZQBDsqIiIAXv1dfl3z3mvFfmXh3B71OmvBeTu0Ml6V pA8VkSCMRroRGq7pa2rSAjSRiSoUnqE8R4FS5Tw3M5yCaY53GKHWBApV4yu7cdRuJ0SXQL9qgepO nU/9FF1V3UAm2GRecgUMehIyOfxEfWVZm2y4quQkIh57ZZdBsiQhvanSEXccU3kHkAuTfUBL26F9 /PeWv+6SLwJxynUtYKrh2t5O0Wk79WXtu6RoAe2V1loq24ag2GGoKgG0BwKpB4tbnuRmlivS3BFW i0XZKu4KWJPzA/LORodNIx6aHXqMth7rcoOPjdl9JBNGUcOPEweX24BkDqAIfj4C3bOQ/cP16pLz 7rY97Xiqrjv/AFRK1qSTQ+v0+6YnX7tkdj+X1/YepvwHSPwlyuWx/hWliVf+80T+fVo/5ujL60N6 HjoKuWoty2vjgeT/ALBLqjL7qKn+j/WTrntvW7/l/Yft3/q+X7O/WeXvk7C838SyZbX+GhzSL6nX 8GnfobN/2aaCT4/0d/2a9EP4MEpwnLVp/wDqZwr9vT8X7ufdp/N/p06bXPesTcjUqNa2TZZzCVGZ ly2EyJROWNSnmjNowlnJCgJiNEXTYUDqj+VL3ICbsAiIRT/M04XyXNcH47zLFRyy8fwl60LuwaiJ bkcMcE8gHwjWSIxM59FaZAfxah39sWYx1TO5LCWXVMjerxGDX07hhZ2eJT9rFW3hfi3bOnqAOqvz FKcAAwAYvcDAAh3DuH1KYOsYmRJF0cAr6H/3HoywSp1Hoeu5Wzp+qjHsWa8lISaycfHxrVI7h3JP nhvRbMGyCYGUXXcqnAoFAB/HuP0AR6U1qF7LWosTi4JLOUtyLDDDGrPJNLKdkcSIoLMzsQoVQSde vgzQ1ka1ZkWGrCpd5GIVY0X1Z2Y+gCga6n/29W2bpBr1Xhw4rdicpuZmDqFAhzrLHTUOedYyldbA RsoAmBRRJdIxSGKIiYhe/wC/rcv3KcbscL9gUvEeVyrNn8bgcLVZmIYm5DYoR6RtqdxV1ZUYEkqu uvqegZ8bZKPNefly+JQpQs37soABAELxztqw+wEEEg/AnTpv+El+5b/cU8PwP/aX7v8Apv8AndRb ZmP2Sf8A+atPt/xH7P738/Tpup/2f/5K1+z93/7v5ulXkzGTWe3bPeR9aYuJEKcoWu3iObD/ADXl WfqrpgJQEhkk/UCRXR9Q34OTNf2AIg/e8DEZ/wAWeReLe7TiVeW0mBYUcvBHrukx8zOqkDTYu7vz QmR9ds709AQCVReHrmO5TxzK+JMxIsJyA79ORvgtlAD+3U6dtG2j4xif7SASHe6czd5420HPoOV0 9vKINlISJqyjAjx+o5MJBI6Wk3TRvFlYKAYrv1R9VuYhiimZQPDorbnl/HZLxhB5N8Y0LfLal2NG qV6BjEkrPqNJWlZRXELArZ7gMkDKyGIyDZ1VVfhtiDlT8W5TZgw0sLMJpbIcogX11URqzSFxoYtv yyAghwp3dAgu55ILbk33AOObor5tXjVklcGYizInZmBUv3I8wC4KhNFSWFIFAb+AIh4fh1mtYue7 Kf3Gxe4ceKZBkIsZ9AKX1MBUx6OvfNrdu+p2v29/Y07QCaaenRLxw+JI/G7+OP4sQ1ntfUGftSah /T8sRaadrUbiN+u/5vj1YFTrm8nqkay22rSuaOWYOxmYm1uosPtibFMFnD8JRm7VYLw/oiJyuDCl +UpvMhBAQ61B4Pz27yHhbcs5riLfFLNcSG1XyEkIEAiQPJMLCP2nrBSSJ2EX4X3Im3oXM/x+vjM4 MPg7sGYik29qWssn5hc6KnbdQ6y6+hQBvUjaza9CbmLpbkFyHktmQbqlzjM49eqUVy4ROmE1JrJr gvIkSVTKIlXJIqu+xvFVBP2XkUBOPiDnh+3Y90Xurt+fa8Ug8T8OqvjcQ7qVFqywcNMEYDXcs8tr 5tssKHHhlDMdt48xhj8W+KYfH0jKeW5iUWbiqQe1GCukeoJ/D21i9NVdvqNDoo1O7rSroaOq6PlR 4fO+a/DXRMrrbduvpVeWY6ZkxXAokK4vtPRfChCFXcKIotVbdX5CQhiLKKJpIKSBVVB8CGAbT8Nc 5Tx/zyrmbZIxMoNezpr6QykavoNSe06pKQASQhUepHVZ+XOFvzrhFnEVQDlIiJ6+unrLGDoup0A7 iF4wSQAXBPoD1pP8Duc9w4VT+k5HeWc4ljerSsHG6zXTMHf6mo9opL6QSj7FHQbw6CiDli7cmbzr Eqabx0g2RDuZRomka3f8xr2o8u94ftru8K8TZKjR8jQyQ26gsMqVMtBFLFZfFy2xr9KbDwQy1LTb oEmQxTbIbEkyDr7SfPGO8AeUEyHMq00vFpiYpwobu05tGjFlYj+PYrPHPH6OUO9Q8kKRPug8MI7F ttoda0dtqWb7BX2aBl6fWKraYefgquaQBN5IPLXDNnB1G9ydqCQHLN+iRdmCRSLk9QhCN8Rfb17C ud8Dx1C37r8LPDmsXv8A0zAWkDU6PdYPPcsxrurW7lpwvzq08IijiLPIywpU1Q5x7iONcqeb/pFe jejcCm1ejcCebaNI4UOolghiUn5SI33M3ypq5ljD5LeXfB/jpmsqvdrVVZLbGDJRTP8ANs3cw8ho MxLAgc8bH2ZnFHOFapjs6Piu/lPRTQTAwtAWcgVuqWXkb/LoxPu+wH6FiqFXjWYjGkGdFMIldRoG jkSMRG7GyaqkAYmNysgMahy1Hw+62t4Mme3kLzZFJAQ2OE3ckkJBIZdd4rtr695wFI1BWQ6L1qF8 XMi2n5Xee8aW/vpKxv75Z2V73e4olVTbVTKqsWIjJFJu5BFwDBNnW2LKuwRVAMAulWaZx8fM5dns zZ437e/DVTA4WWeWnh8bFQotaZXtW7CoQJ7JUKrzzy9y5aKBVBaXYNAo6zNw9PN+cfKs2Qvoqvfu NZtdsFYoK4YapGDuKIibYIFYtoe2pY+rdfRzbt27Rug1aoItmrZFJu2bN0iIt27dEhU0UEEUylTS RSTKBSlKAFKUAAA7dZdszOxdyS5OpJ9SSfiSftJ60mVVRQiABANAB6AAfAAfs66PWbaQZu2DxIq7 R82XZukT9/FZs5SOiukbt2HxUSOID/QPSHIUKmVoT4u+gko2YXikQ/Bo5FKOp+5lJB/l6UV7EtWw lquxWeN1dSPiGUgg/wCggHqt2oshoyuh8QtFskvT4a5LP3uYX1i5KxFy2m1hMMSo5V8WopTKyAmF uIlTcLHeMhOBjJeWS3AaQ8bWOUexXy1lr2DwGdllm4/mIpBCJYrT6/StIdqbLZQ7oCVSaVr9AzB5 IdS4ztj+JExXnfidSC/kMeqJkaTrv2tCP3oUatrEDpvALIogsBdA+h3ZnnFZymnRVLqrUEI+OT83 Dk5S+9l5NUpPfTEkqUA9d8+UIAmH+EhAKmQCpkIUulPiHxPxHwpwKl4/4ZD28ZVXWSRgO7asMB3b U7D8U0pA1/oogSKMLFHGijRzDluY5vn5+Q5t91qU6Ko/BFGNdkUY+xEB9PtJJdiXZiX0mkmimRJF MiSSZSkTSTIUiaZCh2KQhCgBSlKAdgAA7B1ZEUMVeJYIFVIUACqoAVQPQAAegA+wD06jTu8jF5CW cnUknUk/tJPx6DXlDpi8qghx9zo33nRNDOhEzKLBQDhW626H1H4STggmIzdy7NM5BIf6oMBWcKeB ATMcAveV5fs5mrF7XfFB/UPKnKnStaSFgRQoyfNMLDjVY5LMQZXRx+TSNizN2k7LOQHhnh8VKRvK XLB9PxTFAyRFxp9RYX0TtqfV1icggj8c3biTcxcKTmf09ln9KrVNjz+q3r8U3Yiv4+AunQAKr56J O4+mL18qoqJQ+hRP2D8OjD8W8Bx3i7x3h/H+LbfUxVJId+mnck9Wml0/o92ZpJCvwXfoPQdU5ynP 2OUciucgtDSW1Oz7fjtX4Imv27ECrr9umvTx6n3TB0BKUqnxr5HWEZ4SsMr3NVOSbzRyelHQNsTc KHEXi3iCLVoR5ILIrj+UiSDlqocwEIfxzKgzMXtF92WVPJj9N4X8kOtiO2Rtgp5IOzHuv+CKNZZ5 YpdAqRw2ak0jrHE+hOPSfy94lqjGfm8142pjMQ9ZJqxUD5R8WYqiunxLPHMigsy6q+08OIrRJuSu dMsYQVhn5E0pNs5xNSXrsgsdoggRwxBuKbyJXEyHmYxRcJnE4iBC9g7uHuO/y+MF5e5Ha8h8Ay/6 byvJWGntRW1+oozs0aqHiMYE1diylnOs6vvIVY1UA+fjf3EXuI4yHjnI6f1WIqw9uF4CIrEYDMxV 92qSr82gB7bLoNWOvoq55j2x1qrVeqPpeCBxUn5nkVaX8q+mVq89M9WHvUI5BhHuXdSVrDk8W4ip B039Q4+omZIhSlM+eJ/b/wCf+G8NwfCMnfxn1GBtiWtkZrU9p6MveYE4uBIIZJMZJjXfHWMbesQ7 5GM0LQRIqMh5d5C8eZrOXs7Vr2uzfi2S1kiSEWE2D/FyM8ipaFlRZS1BHJtA2OrsSRK8ovn/AB1o 8/cphUh3ax1ncpImSbJTdvsT9dy8QiYtoiVNu3F9IOFPbsm5CNWpDHUEClKqr1euVk8Xe0/xxk+e 511fISF5bNgrGlzKXppJZ1rV40Cxx92eSQwVIFStWRpJWCos03UAqjlXlrklXj9BSK6ALFGCxhq1 0VUMsjtqzbI1XuTSFpJCFUEkonUb8TahPhEW/YLmgKNr1+bPPgibyD2tf81VowqRTgUybdcXJgRD t2OzRbnD+LqqfZDwXk36JnfPPP4zHzPneQNxUOv5dHV3r7QfVEkMjdoeoNaOs6nRtBK/OGexZvUO B8fbdhMDWEOv9afQCTUj4sNoLfsleVT8Oi76OrqiehK5QVGebFqG1UtuK9myx8L2SappqHPIVYyp XLv1wREF1WsYoQ/rJl8f/s3Tk4mDwDoEfepwDlMEOB9xHjiLuc34Ra78sYDEz4/cJJQ+w72ihIcS ou3/AIWzbdmAQA3v4V5Binkv+O+SPtwmci7aMSPy7Gm1SuvoGfVdjHX82KJQPm6dkixzfldlaXou xKmqKbls4QFI83TbImgIGRdNxEAMdMFTEVTN2SdtzeaZgAyapZ1fqeIPfL4RRqs5WNyroy7TcxGQ VNDHLGSPmXcUkjbSOzAwkicBoZlYoJeX+DebsJU1YAqQdezbrk+jI37DoCrD5opBtcah0MWN6HzI hGhanFaTTZGGTIDRlaJMgqTbViUoJEBY7qBePTugS/rHF0oA/gt9AEKbqeM/f/xyiOEYTl3H7fH0 URQ5GwN1uOEDaN5kpSymTb/SY2XB+E/oCJjLybwBkZznLuIyEWQJ3PXjOkLP8ToFmRAuv2Dtgj4x /EdSfm2a1PjzWLHbbdZwkp+V/wC87reJk5wUcKeZ1isWBVTuHhyKO1zCBe6jp85OAiAj6SSdxeJv EnA/adwvL8959mha5JcH1GXzFskFzqWEMIYySsGlckKDJZu2GUkM3Zhih/LOW57yxmqeAwFIxY2H 8upThA0UaAb30CoNFA1OixwxggEDe7RthjaV2DVrLyGmWSzCvNG7ip5wydFAFRapAdq8fkHuYOyD c6xFDEMdIzt44IU3ZEQ6pr2x0c75883Zr3Z8kqyVOMRxPjMBBKBvECaxyTD4/hRpRIVLRtZtWo0f SAjqZ+T56HAeEUvEuNlWbJsws5B1PoZG0ZU/0kIVBAYRRRMw/M16NbrRvoceh+5NZm91HKZWKhin NZYJ03tFbKl/nlZSKIuBmyHYBEzlyxcLFQL3AoufT8hAAEQFz3g+H8h5l8KXcNgFZuW4yePI0Av4 nsVg4MSaepeWGSVYl1AM/a3EKCRaXh7mFfhnNoLuQIGIso1exr8BHIR8zf2VdVLn4iPfp6+nXthG uQu20BM74rQ1mjmhIO/Vt0RJQyT8W4t3DhRisQAWhJ9MDKoiJBTMUx0h7nTUAFHtq858d9xHjBXy Agbl1SAU81QlCkrNsKPI0LDRql1Q0keqmMhpICS8UgHn5M4LkPHfKCKxkGHmczUrC6jVN25VDg+k 0J0VwDuBCuPldSRk2rhMR05LPYn7ONUdvm6clSpV2ZvCNk3jgiS8tAvjgqtHIsPUFdZiPmmdIpwb +BwIkcP/AHDf5dsGRuDk3t9MFKaewosYqxIVqIJXAaxUlOrQrESZZarb1aPf9NsdY4JLi8ee4loY jjPIncmWONjHbjXdMxVSVimQaCQvpsSYaMGKmXcu51IbEeM9IxxNCXEv6mvh2xknlskUSgZp65fF w1rrDuojCMjlESCYomcqlEQUVMUfECo9uvtB8deA4Y82F/V/JDQ7ZclOoHb3DR0ow6slWMglSylp 5FZhJMUbYtVeRfMHI+fM1AH6PjIfVa0Z/Fp+Fp39DM/2gHSNTptQEamHd7nR3XS6px1pzj3kVETT ex6nNMjAq2i0osQ7RBXJCKJlexqa4qKh3EhXyjVAwgcVCloT3Nckb3I+XcJ7U+AymfDUsgl7kVuE 7o66Vzoa/cAZe7Ars0gOqfWSVKzssolVZ94xxv8A004fe8r59O3dnrtXx0T+jSGT/a7SQdkhUKv2 mFZpQCu0k3vssT/1Bt/Zf2X/ADYf2T/1D/s3+L1or/D2D/5WH/BfSfh/+m/3H/d/2ehz/Ub3+9f9 93vj/tf6/wDe+/rKfMWcmzdx0i1bvmD9sszesnaRF2rtq4TMku3cIKlMmsiskcSmKYBAQHsPSzJY 7H5jHz4nKwxWcZZieKaKVQ8cscilXjdGBVkdSVZSCCCQR14VrNinYS3Udo7UThkdSVZWU6qykeoI IBBHqD0E0hx+1XIpyQsfG21NyQsm4F3J5paFhcRSy5uwGFmq7VI3VU7ABSqmWZuiplADrr9Z3ZT2 u+a/BHIrXK/aPmohx25L3bGAyL767Ppp+U8rBGPwAkaWrZWNQr2Z+iKq+UuE87xsWJ8uUmOQhTbH kKw2ygf2goLAfaVCSxliSscfWT/fVyrakGPe8cGjiX/gB8ynXX2cVPwA4gkm/RKn3+vb3gh/jft6 VJ7iPerVT9Kv+JYpc5+EzRWpBV3ft0AmTbr/AOb00/penXifHfhOZvqq/LXSh8djwr3dP2epQ6/+ ED93SWvkPIXd3CBNysUdRaERdFyvQKeoideR9MxVSpvlknMmiuAD28TOnTkiZygINe/5gaLHgr3U e5W1EnuOytXjPjVZUkfDYplMk+07gsrrJOjD4aNZsWFjdQy1N3zBbFzzxX4ziZvG9SXJcmKlRdtA gR6+hKArGV+8RxxlgdO9p6dGdV6tA0uBjq1WY1CKhYtH0WjNuBhAO5hOqssqcTLOXThUwnVVUMZR RQwmMIiIj1oHwzhfGPHvGanEOH1IqPHqUeyKJNfTUkszMSWkkdiXkkcs8jks7FiT0PmazWT5Dk5c xmJmnyEzaszf6gAB6KqjQKqgKqgAAAdODqUdNfXOudc6o1+SX4Sck5qzUrsWVzrLE+Qj9MFJuTGN M7z3SnSSfgk5u0THlLIRViOBSENNMQVVOmA+5auz+B0yJ8Ue4PN8ArpgszG2Q4wp+Rd2k8A/ZEzf KyfE9p9AD+B0GoNB+T/BGG51O+bxEi0OSMPmbbrDOf2yqPVX+A7qakj8SOdCNaC/fBj8mNAl12cf hjO/MU3CzZtZM70ahP4x+Qg9iuW7ObsNctDZquX6lF1HtzdvoYpR+nRa433FeJMnAJJci1aQgExz wTKw+4lEeMkf2Xb7iehayPgLynjpikdBbEYJAeGaEqfvAZ0kAP8AaRfvHUy4F/w8/O3T5tiGts6X x3qBjN1ZGXs9mg7vZhZqKlKsEJUqDLTKDqSSSETAjISMUmPbsKoD9OmHkvug8cYiu36I1jKXvUKs cbwx6/ZvkmVSFP7USQ/d0+cd9t3kDKzr+srBjaXoWaR1lfT7dscLMC33O8Y+/rb24R8EsJ4F5cfO sciHDiUnFGUhoOiz/t3N00KbZIqpNnc08QSSRaRMWVyqWOjGxU2bEiyhilO4XcuFwd8heR+R+Scx +qZ5wIYwVhgTURQITqQgJJLNoC8jas5ABIVUVTN4H4/4/wCPcT+m4RCZpCDNM+hlmYDQFiPQKup2 IuipqToWZmYzuoD1OOudc651GGqZFS9hr4wNvj/VFH1FIuWa+mlLQ66gEBRVi4UTVIKS3pl9VFQp 0VfEomL5EIYtOeavBPj3z1xf+Gud1S7RlmrWotq2artpq0MhVhtfavcidXik2qWTekbpMuFc75Dw LKfqeBl2htBJE2pilUa6B1BB1Gp2spDLqQDozAjU0znltlhAj6DoNd0isNv5UdF3VI4yrVsQABFI rl4sg5TSRIPiUoyaxQAodilDsACHT8Ue+bwwn6X4y5TieXcQi+WCvllP1EaD8K75WR1VR8qqMhIo CjRFGg6t+flvgvmjfVcnxVvEZh/WSSoR22Y/E7UBUkn1J+nU6n1JPqfVevc1b6UY6Zs9Jy2KUD03 bmuEKrMqJHECnFm6QWnl0lSlERD012hu4fRQB+vXrY4t/mG+TUOK5BmOO8Lw7ekslABrTKfQ9qRG uOrgEkFJ6x1H7wH16848r7eOMH6vH08jmro9VWwdIgR8N6kQqQft3JKP7J6mvHMApmOIOXUcLiet kp6gzVwmP5sq9MucqrhNDzUXMybOFygdQPUUWWMACqqp4k8SI8B+2DgHgSvNfxZlyfObu428pa+a zKXYO6xgl+zG7je43vLIwUzTS7I9ld8/8ocg59IkFvZWwcOnaqxekaaDRS2gG9lHovoqqNdiJubW dOiS6rbrnXOudMq/59VtNrL2qW6PK/i3fZQhiiCbxg8TIciEhHOBKf27xAFDAA9jEOQxiKFOmc5D V55Q8W8L8w8QscJ51VFnDT/MpB2ywSqCEngk0PblQMwB0ZWVmjkR4ndGkPF+U5rh2YjzeClMV2P0 P2q6EglJF1G5G0HpqCCAylXVWAiMKLylwgv2vOJSG12gNu4RlfsqoNpiIaFH8rRqu5fs3LdJIg+K aaTl2j+XuRBIB8OgVxnjf3oe2tRhvE9zH868Yw+lelfYR2qsQP7uNpJoXQKpCokVixF8pKV4tdnV 72uS+FvJZ+t5bDYwXJ3/AHk9cbopW/rMFR1Yk+pZo4m9dGkf8XSsfZOV8wUI+E47sIeSP/LPIzk0 4UjUjCAAKxCOfsKJwII9wAXIh/h6eZPP/vczy/pXHPFVahlz8vfuWnNdSfQuBIaaaD4gfUMD8PX7 UK8A8IUD9VkeVy2Kg9RHDCokP3Er3iNfh+7/ANXXtV+N1xvNlY37klaUrfIR4irDUWNH06vEiYxT gk4RSIizMn+UAVRSIcXHiALOFk/JMVPDfaVz/wAk8ureTfdxmkzuSqndVw1c6Y6tqQ22RVCRFfQC WKJG7+xfqLU8e6JvPNeXMBxvDycY8RUmoVZfSW5J62Jfs1UkltftVmI2antxRto4NIpSkKUhClIQ hQKQhQApSlKHYpSlDsBSlAOwAH4daEoiRoI4wFjUAAAaAAegAA+AH2DoeiSxLMSWJ9T126+uuuuC ACAgIdwH6CA/UBAfxAQ66IBGh9QeufD1Hx6ES18ZZCJsLm64RcVcznnZvN7BdlTVR8YxhOYCoIpu fZNxOYT+3O3dtQN29NNIADoCueezPJYjlk3kj2zcgl4Zy2c6zVV3fps5JJI7arII49SW7EkFmuG0 7UUIA6vvA+Zq9vEpxvybj1zWIj/BKdPqU+z8RKlm0AG9ZIpCPxs5PSWD/m00D7f9kzeTEvZL7767 JP1P2e5FL7nH9h/b29kX/J/Z0xi//mRUdMT9Hw67t+X609pS32dzYLUA+/T6Rf7n2dLux7bp/wDi +9mYdfXs/MQP7OvakP3fvT/e6/WPHG/aFKsprkJoR7KyYrlctaTWzrM4QDiAiJXDhJvFpoB4mFNT 2zYq6hPp7kOu8V7QPJvlTO1uS+6/lj5unVkEkWIoloqSt6/iZI66J6ExuYIBM6en1Y66teYOM8Vo y4zxRiVoyyrte3OA85H3AtIW+G5Q8mxT/sujCjo5hEMGcXFs20fGx7dJoxYs0U27Vo1QICaLdugk UqaSSRCgAFAAAA60BxWKxmCxsGGwteGriasSxQwxIsccUaAKqIigKqqAAAAAOh/tW7N6zJcuyPLb lcs7uSzMzHUsxPqST8Seszpw6T9c651zoTNR42O5G0jqGNWY2caV3VUeqI+ScHYDrGBRx9wRTQdJ oneHDycAdu5buDh5mSKqYywg75m9o9/K80PmX2/5c8T8ufO0xXUU7zOQXM6KsgRpWAacNDPBYcB5 IBKzztePDPLsFTC/wZ5ApjLcQ9AgPrNAB6LsJKkhB6IQ8bxj5VcoFjDVQ1Pl3VShH2jDoa5qpgCa c1WpQzMrzt9PXXbsFJ5FIT/iIeLf/IDqFQ+avfXwlP0zmPjejyCdPRbWPsGMSj+u6QtcVSftASD+ 4vw6e5OFeCc2fqsNySxj0J1MViMNt+4M4hJ0/lf+8esR6nzE2AgxLplAYdVnnkm+fMngurKqzN9F EkXKbpzJt1jlN9PSRjzD27esX8RQ5BPft55jOEt1sZ454VYBWaaOUvkGiI0ZVdZZLCOdfl7cdInT QzqCdfeu3gPgTfXQyWuSZqP1RHTbXDfYSpVY2A/tPOB8e2eiMyDF6fjECeJrSCjh++FNWcsD4CHk 5hymBhAVTlAQbs0lFDikgURKQTmMYTqGOocsfBHt84H7f+NNhOJRvNlLO1rl6bQ2LUig6biPwRIS xihUlU3MzNJK8kr1NzzyFn/IOTF7LsErR6iGBNe3Ep/YP6TEABnPqdAAFRVVZc6vTqC9axnMflzy lrvM/mzlWOb3vTPUMwHia44g8d80x6C0yhaJK3umVyW1yE0xcuazbqIhwTMLxFy/n4f0QcuVETOC olQIXfA+EcOtcB4/ms9jca2HufqQyd6xaevNAsMrrWeuO+gZv6JVIZddqBgu7cRP5xzTl1XnWew+ DyORXLVP0442lBWSeGZpokayk57DlV/pBnmj03MVLbdosYcfJg+aADEcWRezZfknY/HEKKOgC2Yq 2d3nRLeOlgsenuFG8WnPm+3mjOyhytwFyDsxg9AasXxJG/5n6gVr/wAJnOamHUiMT9rsad0ats+f uegLfJsA+bqzm8qyJ+X9AGsfxUMJoJtB3DD3O/r2zou/5Nnqdvz7z+HpB4F8peV2hcPuSWybBSob R9Eyy/8AItHO67XLfEA9vq+aydnM2y0qsHRYhhBEjJaJTg4yUO3fLySChHiyZTD4HU+SeHcLxnOs TgcFYkqYu5Womd3ibSETrHrY0eZi+5WM0ke5BGQY1JHqE/jrl3MclwnKZzNwR2snTs3RCiSLrMYG k0r/ACRKE2soijk0cuCHYD4Fml+YJhY2NJSzvHoazWTSapwmhKjGuNRWRiEORnNpOyy9cyK0TkbQ ZQIaBzOoUuVkpqaBBVyqdBNsWPROqByrz4MkqSWGyl6SGpUmyzysK4LGjie2r2Y0aZd72JZY44ot QoBLmVgNCh/62x2o64xlFJbVqHFrGpsEKLuU3slaR1hbakEcUjyy6FjoFEak6h70H5Sl7ZeMIzCX xBOIveh3fnHlWptGGjJy0RmOkcIaswslhYQUiaoMjXyv3wko3Bo7EkYoxIsAmSX8R6bsn4cWljsl mIMiXxtWviLFcmDa1iDLSNGhde6ey8O1ty6yByPQrr0vxvl1rmQx2Jnx4TI2bGVr2AJ9ywT4qMO4 Ru2O8k25draRlAfUNp16cfvko1HklqGF59nnFP1IfScHyvkRpd4ebNDoRuQ0XQ5+81122+0vKfHy V4mWT+poFZJM/RO8ByqdUjYjbur1ybxPh+J4fI5PKZrSepkrFGCEVWLWZoEhcHcJWWFSsh3ltQu1 QC5f5frjflPL8py+PxuMw+sFrHV7s8psqFrRTPKhG0xhpWBjG0LoW3EkKF9RZ5n81eSWGc8Nno8P f3sJx8DiZ+m49daKglonLOQ+oUDXZ3E76aQWhHDtFWZu+WpwxBfLLRvuJJMiiJhOQSTLgPj/AIny LxvQyM9ZZOT/AK33GAZw1ilXmrJbh2hwDthsGU7AJNsZIb0OsQ51zzlPH/Il/HwWWj41+jbFJVCt e7PDZerNuKEjdLXEQ3kpucAr6jTJyL5kk4VpxzzO6xNdvM+lkvCJHdLpP6IyqmrWrQOUue16eeWL JMiYUx0x0KvZupMtHlucEkoozMsiBWzY4IiJ/jOeBzYfK5fHvLWrG7ljTiSAyVo4cfO6BLNlpQYH n2stZTHJu2fO43en1hfOIgTF4q+kViyKWKFuV5hHYkmvwo5etWEREyQblay2+Pbv+VDt9cnjl8mf IWkvbqly5otdkalJc0uYuLIaDAX2PVa5GOE57ZdGZZcnGx+ZV5O3RDReprRMTMu120jJoqndLplM gCSvxyvxHxfIR124RYlS8mAxdowPCwNn6yeOA2NzWH7TESCSWJQyRkBFOjbl++L+VuS0JJ15pXia k+dydUTJMNK30kLzivtECdxQYzHHKxV3BLsNV0LshPm9qL3HUdYm8LlYRzCcb7/u2kUlK7qSc5Sr JGchonjbk+UuDkpLQxZbV7jNt5D3ztBn9rh/Nf2rrt26RWPb1ejzpwtfIpIkmWhpwS9raksbUmvW bI/NPy1okZNilu5Lou9Ollfz7SkwYzNjHvG8eLmtzxd3c8TrdWjXrn8ofNYlcPvYL249W2P0+bp8 pWt56EhmctxVgbZymg+Umf8AF+Sx6l7qgSqSUrsONyevZZc4HTLLnEQ1CGlUGHsJFB8xaHjTFUXM qYABIW7H+HMJlNuXgzMkHDZMNNkFtS0z3FWraWtYievHOx3KW3oUdg/ooA+PThf8u5nGbsVNh45u Xx5eGg1aK2O2zWazWa8qTyQKNrAbHDopT1Yk/Dpl8YPkD1uw8stn4oy7NXWNje8qbQm6p0jMxVXq 3GfjVU8/oMhcp1K0saudfQzxeh2FzBwUeVAruWVSM5XdNUOwmcOYeMcJV4VQ5pAwpYFcNHpKqtJJ fvyTTLEnbMmkG6BFmmfdtjBCKjt8EPEvJOas8yvcOnU3M42Yk1iZljjo0Y4YTK/cEes22Z2iiTTd IQXZ0X4ldz8542XhQ0j55PMKDO0xCmTl1mLXpm6QGTEtL+Dk2LIuO41WUa9d7louxS0e6UkSomjm MMzZIlFZ6KivgnC/Gnjep5BdqxuWY75sJEsdem9ntq6k/VWpC8MUFVWATXe8rOTtj0GpmHkfyJb4 Ei2BUrSURA8rST20r9wowH01ZAkss1llJfTYkSoPmk1OgYnE7k/yJ2Pn3zDzmyx0J/s80vN+OV0z dgpYIgtgo6Om06QsMEr9raVBlLzz3SY8q7yYTdSSyNcdR6LZsZyR0KvTjzXiHFsD40wWVqNJ/FFi 3einbY2yY15VR/mMpVBA2ixFYwZ1dncIU06b+G8t5PnPI2bxdpY/4agq0pYBvXfEJ4mdPlEYZzOu rShnIgZFRSwfXqv6+84eezS7bVDkdwsc6pvym8ZcEzunwNtp6qNgq96ZOTy+CyVld5ogaEq9wjTM 3y1ndpOH7J44VbFJ4ICJrNxnjzxs+Px85WR0n4bfuTyvFKCkkJG24sYnO+SJtyCupVHVVcnVvSt8 jz/yKl+/AGjR4OX0acMSSRkPHKDuqM5gGyORdrmdgzqzFANF9Z5ufzRzFKqkRHz2E55Vdpb6dyuz e71W+8hmlUzONkeJRohGxx9S0s2dSD21WbS5aeaxNaZHhmZFpL1fXWTQIRRWN0PAUGQuvLWyVqbA Gnjp4pIaRksMuS3FGkg76iOOBUaSdxKxEe3apYkLIr3naehTSKzjq0OeFvIQSxzXRHArY7bvEc/Z YySTs6xwL2lBfXcwUAmfuZPMm5veBOI7bx6lpbL7Hyuu3HOiVmyysPFydmy+O2+YjhnHZomSQfwr iywUUV0wAwlVRTcH9ZEwiVJTqM8D4HQj8lZDj3KES5Uwte9NJGrMsdhqitsG5SHEbttf7CVG1h6k dSPnPOb0njqhn+NO9S1mbFKKN2VWkrraZd52sCpkRdyfaA3zKfQHqN7nyI2z42Y1/SNk2ymcko7X t5hKPxdte9abH57MZ1Tz01efvz/lFrELmCEOyjK67aJnjRZQ8hIPRegQBKmJE2ztQ4vx/wAsSrkM Dj7GJlo415shHTrtOs8vdCQrj6z2CxZwSJN8qIuzX1Opdrvcmz3iyJqGcvwZWK7kVioSW51haGPt F5jfsLAFCoQCm2N3bdp6DQLHhvmvtllpkTaMw4kjOro8MLLzLvrG6bWyo4U2tZvslwx3SKyxMGeT p7WunJ1VN1BOkganlW0giY7ZuJTk6dB7fqVS+9PL5vtqc/Hi4TFUM3dknqxWoJD+enbG2QrMp3CN kYB31B6bD55uWqKW8The4wwT5OYS2hF2kgsy1p4x+S/cO6MNEw2mRXUlF0I6TXfyhbZmGqc+9Svd MjbRxzyfKuHdqxqimutcrs1A2TkixaNs/Zy0opTEVkY/QBl15O0O3j18FUShwTZIPwXEevVPD/H8 xhuM4bG2Hh5Vdu5SO1N2ndHjokmYqvdILQ7RHXVUT6gy6yNFt68n8t57E5jkeXyECTcYp08bJWi7 qIyPeAEIZu0CFm3GSdmZ/pxFpGsm7p9Rny96NcIrOIHJOLlU2rXb5yB2XjqhCULkbBJ5lMz2X0Cu 6PE6Fn2oTtDj2lrze11efO5Mu7aRTpl7Bwl6aynpAo3TeDsVQmt2c3mJsfg62Mq3i81F/qESxM8D QT10mYxzxyIF0VpFbep1UbtHCLzXlLsNWthcRDfzVjJWaQWG6nYZ68KTrNDYeFRJBJG5bVljZdjD Rjt1MDmJzVvXHW0ZZmGY4tFa5q2iZ9sesP4iwaQTOarWqLhdUZ2e3iaxEqtteSljnF3ycfENiMk2 5lxMq5XQSJ3NBuCeP8dymnczGXyD0cLVtVawZIO/JJNckMcXydyILGgBeVi5bTQIrMfSbc355kOM W6eJxNBLuYtVrNgq8/YjSGpGJJPn7chZ3JCRqFA11Lsqj1ErCOVG+coPkhyZ9COJup8U5ngpSOSF YzxtfoRoMghp55+C/VOl1xGkSTyw2WLuorwacQ2mm7NknFtZYjlQVlWSs25Jw3jXD/FN2OwI5+aR 8jmoyTmFztNfY/bgcyqEjaLSYytEzOZHgKDasghvHuX8j5b5RpSVzJDw+Tj0V2OETINRPvTuToIm LususQjWUKgjSYOdxjIscqudXOqkaT8ptbgJNlXarx40HgzE5X+np+mupyjRmtWSutft8KEzmyCd kcbvVHjiRlRl3ahKk8ArJsZ0kYXJJjwzxz45yGJ4bbso0tzKVcu1jekoSZq0bnc+yc9sU5AqR9pQ bK6yOEb5DD+YeQvIVDKcvq1nWKnjLOJWvseIvEth0G1d0A3m3GS8ncYiu35alx84LSb+XaVrETKV S95HlOTbtG8or1xweQ+m8i0obC4FvRMyj9Vf3qy7YjmR1GTZ9HSraIaMSQhlXMuumHqJlOJCwqv4 PhuTpdxt67d44+HhvBq9EvbczWGriGOobHqQytKz93RYgfQkamZ2PNM1SF6eRpU6XIVy8tIrPd21 EEUC2DK9rsegKssap2tWkI9QDoHdyf5wW67fD9dObmCr2LG7rNUGp2Kug+bRklO0qaDXK5SLXF/9 8xCsbKoJLpSDRF0oyIDpqcq5E0hOUCIeH+PKOP8AOdfx7yQRX8fHZkR9CypKn00ksbfK25SRsYqH O1gVJOh1W8t5/dv+E5+fcdMtG/JWjdNQrPE31KRSL8ylWGu9QxUblIYAajQMN35RbrxgrnNzLLzv 287DU6Jxv4sciM/vcZL5dmvIGmutM2Ws0C3VaN0iHyuRqDiJeuXQLid3WXK5I8yzVISqH9yM+45w 7jnMLfHszjsZjaF2zlcjRmhZbE9KUV6sk0UjQNYWUMANPlsKC+121A2dQXkPLuQ8Sq5/EZDJZG9S r4vH3YZlavBciM9mOGSNZ1rtGVJOvzQMdm5F0J3dGnHfKLapbkI0zWE47ISOKv8AmxK8EmOzPdaa x1nHVKbVk7BdJhxlwUd0detpqGOSPXSlwByRuYy3t1FE0eoBL4epQcYbLWMoU5AvH1zBqisWj+nl k2RKLHdGknwLgx/KWAXcAW6ncXlu5NyVcVXxgbAtnmxIsmwFk+oij3ysa/aOqD1CESfMAS20kL0H nD7nNyqvGhcII+sRV2v2IaVhXK+8WGF03V6Bdd30SUy3YrHXpF+8m2eW57ErWOqPGKEXWY1BaJjp Fi8D3rlIWh1xnXOvHXDMdi+Qy23r1uQ1MjjoUevWmipwLYqo6qENidgkgJksSESOjr+Wh3heoRwn yDzDIZPAR1EsWcBax+QldJ7EMtuZq9l0YlxXhUvGQI4EBjR0b8xhsLdK28fKbsF443cqWlFToGNb VhjXirc/1JiuxVrkNF16J2jeKzn1ly22zilEiqrHavSkFlmc2gxCYjQOuYEHXkmAm8eN+G8FjuV4 Z8ibN/j+RbIxdu3VkpM7Vack0diNO80jVpSA0RftPoBuTQ9e3IvL2byHFswmPFajnseMfLvq2Uuq i2raQvXkftLGtiIErKE7iak7X1HrYdzI2XUM55W/G/Q6RcH1ep+zbJp9a0+Cas4lw2t8JCZ4nNxL B6u/j3b5mmykiioUzRVucwmEDCYOwBV3A8Dh8rwvleSyMCy3qFCvJXclgYnefYxAVgDqvp8wYfs6 sznGcy+L5jxbHY+doqV69Ok6AKRIiQ71BJUkaN6/KQf29Bb8i/L3ZMWsfPGPxKxaBF3nLuK+HXGO dy93rKmZUyLvmkvKrO3Kj0RxnjqUR0lq3MRH1XUw4bOirAomk3O2L60/8WcHwOfq8bl5DFVfHXMz biYLFJ9RK0MAkSKaYThTAT66LErLpoSwc7YJ5O5rnMDa5FFgJbKZCph6kqlpY+xEs05jeWKIwlhO B6atKVbXUBSg3LlU+UKUxHWcq4i6JT0brZqlcOP/ABz1+yTW9Q103x7rev09nNubxWKPFZxWkNOy mky8tHx07YRNAOTO3w+1jVAQ8Vk13w/DyHCXecYuc16k8F29VjSm0VMVq0pQQyTNPIa9mVVd4YPz l2p88o3fKop+WpsBmafC8nALFuGenSsu1tZbhs2Yw5ljiWCMT14mZElm/Jbc/wAkR2/My7F8qu+7 VxJ5a6ji+R0fM5fNMluNvrk+pvFJsOl47J1fQ5WiyVc3TFp6mJWKkauaAh1rHCx3sJeAkkPFmrJo uQ8DOFXwzxrj/NsJh8/esW4Ld6KKRPo5UgtLJAsyyU7SSmOatvYQSvvimjOrrCyeoQ2fMHI89wzM 5fBUq9SapSlkR/q4nnrNHM0TJbqvFvisbFM8SbJIXHyGVX9DLtD+UzRYeQisd2HAo1htwaVwVyaK cwmphM1LQ0uY9fmJdHTY+QRzeIdNI6is6pIqyrVuxXbi6IKCbkhCiqDHkvDmLnifO4LJu3HvpMvZ YPX2SQfpbqprspnYFpjIgjYuDtO4oSdOnrHeXcnDImDzeOVc/wDVYmupWxujm/U0Zu+pECkLEI3M iqhG4bQwA16HOj/LZeMO4950vozyobZp9td8x9IXntT0WOxRCUzPAtptNIrmfUs0Hntnb2rZL0jF gyrsKm0QIudEBXc9zAPUqyPhLHci5PaXFLPj8PAuLgCV4GtlZ7lWOaSaXfPGY6sJbfPKWJAPyp6d RfH+Zshx/jVVso0F/LTNk5y9iZaoaCnakiSGLZDIJLMu3bDEFAJHzN69Wkf/ACD5T/6J1X/cM/8A kH/8rof6qf8A0T/aX+tX/wDV/wAH/wBbqnf+mGa/5il/+yfov7w/4n/e/h/w/wD2nx/s9W7/ANSs P/y9z/8AXf1n92P8P/uvxf4j/s/h/a6ceM41llQ5jc0NhqWyMLfpuvsOOrXXsfZzFZdvcgLQs9kY HPHM1ERTxWxxB73Ancv2gyqKIuEwUM2E6QD2SZ/PZm9wTAYK7QaDEUWvGtaKyAWe9OrzhGYBG7L7 Ubtk7ToH0bpTgsHiKXOM7m6V5Z8tdWkLNYNGTW7MLJCWVTvXvJude4BqNSmo6Bd7wnxBfdnehhz4 immcD8ldZ5BReEkXxM8e15vsocidkyeQu7lytc5O82KtppJNKomdrIRrHzUBo4WOVySxo/IPIV44 uL/hp2yv8JSUmuaW9xxJb8uysIAiWFJNS1khkkfQb1UbDXz8CwDchbJjkaLi/wCKo7i1Nau0ZUL8 9cyk91pXTQLXBV0TU7GY7wX3EPHa1x6zXe3OD7AvycpVh1HWdDo9HjpvNVGlUvj6Zn5e35ZGX6EO iyWkXtyW9m4UmnIDGOCdlQRAFe8G5xnbfKMtjU5JRGIyEVOtBNMyT6yQhUWKw0L6kKIhuURL+Yp9 N3y9TbhWEq8axWRbjt45ahLbsTRRK8GkcxZ2krrMugLGU7SZW/LYeu35uqguF/D/AI3TXE2Siz8j cFxDX7T8g9b5BYO6zvccX3dbDdcixkW/GXDZyRhbOaj7JaEKsymVE4NuqmaXQfuBQIBkT+F5c+5z yuvzVJhislkcHDxiSlcE9S1TFus2037aK8feqxmQxAzMD2ii7jow1pTgnCeLWOGvCcpjsfm5uSpc qGG3VtmpZXcKNR2WTtWZBGJSIlI7gdto1U6E2HBbBXr7BmdD+QuKrvJCh7LzTsdr0OvOcIl7br2m bLEQhOY8OxzZ6u+g6naqRXW7NJVs0avVKayVIo7bnVFJckQ/6jckjjyUmS4u8vFLNDFJHA4uLFWr 1Wf9LYzgB5I5XLEMzILTAhGA3KZX/wBPeOySY5MdyZIuU172UeSZDUaSzPZVP1NRASUjkiQKCqqx rKQXUnawJzhDxp48YveKvN5ByWgNnlozh5kuSR0HEWOgTJ5LKqtd7pNVTWU0arIPXqsTZZaXeMkH afeOWM0OVNVRQpvGI+Q+W8oz+Omr5zEy0IHztmyzsky7bMkUSSVtZFADRqquVPzjcCQARrLOAcV4 zgshDYwmVjvzJhK9dUV4W3V45ZWjsaRsTtdmZAw+Q7ToSQdGhy/4q8TtUmuZcluXKGrZux2DDMFo OpQs/dM7rTTH2VP0N/PY7o8otPyjFzFKWC7mO2j/ALkZBpIqlVbomUMYSlXcG5nzXDV8DFx3DzW5 KORuTV3SKeQ2jLAqWoFCKQ2yLRn7erICGYDTUoubcP4bmJ85LyDLw1Y7uPqQ2FeWFBWEUxetOxdg V3y6qm/RXOqqTroGDiXB/Ho7TYSb41c8zJV6FpHDdpyYoOXzGZWGe1wuB0CLZ4bNzNzhZh7P5JVd cpTJsvMMY5AqNrijD6C5EFTGM5ch8h52XESV+W8b1tSWMoaE1hbCJW+smY20WJ1CWZK0pYRO51ry fiUsAA3YDgGEiy0c/FeRaVY6+MF6Gu0DvZ+jhUVGaVGL1o7MQUyIg0sR/hYKTqwdu4J8P7pifJKn 3bnpX6pjms83bDsbGVkLhiEXFYjyRXC+PdXzKCtyzmM9ewykHMu2zqEkXIyMUwjR7JAIvTrOfHvI 3OaHIMTex/G5Zs7S48lUqsVtmt0R2RWsPEA2iK6qyyouyR5Pxfuwrbn/AB7wm/gcpSv8iihwdzPv ZDGSqq1bx7xsQJISursjMrRO2+NE+H7wsoW3hj8b0+7+R5xNcscujGfJRlmBNbZsNZyiGLxpc1e5 x7yqvfWJOF/T6Nh2H7UuCEwVBF0+RRZEAwqiBvKjz7yvWTii18Lcd8S1j6YmtZf68SRMJBps+cpV 7g1i1KoWkP4fT0u8F8XWX5Q0+ZqImVWD6kCxXX6ExygxnXf8gez2zpJoGcLGPj6vyL4f4ix0atSW z836ffOU0VzfxXdNGsByZFndjuupVXH3tRxTCS5hHTbkaehJZcC75iwS9xNSxDLvUzHT8RSbZudc hkxU0OA49PW4c/HrdOBP+JnSKvJaEtu59QyDulbGiO50ijO2MgHXc5Q8JwEeUilzufgscuTP1bc7 /wDDQvLYjrGOrU7Cse2Gg1dEGssg3SAkabekXxK4fr8qJiw5/wAu85i+YxuZFm5GItK5YcfkNsYN V6J9g1HjTL1lCTPcJbM5GnN1nD5msgm9ju6joBIJljKdzc25yvDY6uTwdp+CfoMdEl0tLUYibfXv rIV7S2FlIVGBKP6J66KB1FwzhLcvezjc1VTm/wCuSXQEes1oAw7LFFow3caBogS6kBk9X9NWJXee HErD9v3KZuNm5n1fjhc5jh9eMl1qmzamRS0vKcZ3dmk5yTu8M30SRbSmaRDCyOXDaYsbdFRuuyJ7 UFmipTLim8b825Dx7jsdCpgJsrQjzsNmtKn1Kqt8RqiwsYFKzsYwrRQMQyud+1wQvSjyJwzj+f5A 963nYcXefCS17MT/AEzM1EyM7SqJmDQKHLLJOAQVGzchBbqcuO3HXMqDym0vWMu5MpXWcncJ4/0P acYjX2dziAjS6YjEYnp8qWI9e2Uwk9T2cgvHt/JNhKFeOF0zKpppAlHeU8py+T4bUwuYxBr148ld mq2mE6H82Utbrru0jl2SlA59Xj2qpCknWQcZ4xicdy+1mcRlRPYkx1OG1VUwuPyottWdtuskW+MO UHokm5mBYAaD/aeHfGeR26+3x5zKiYxCwc9uNu2P8teWfJzNq5yozgCKV3LSvlnLayJWjUIcySKE Auf7l6JSHbIqj9Rk1PnXLYuPVsamBd2i41fqCwI7OsmOn/HY0AMfbrtqTMB29dQ7DqN3OEcUlz9n IvnERZeR0bRrmSvomQg/BX1JD9yddAIT8+mhVT0ypPg7jM1pclJYX8gcTnfIWV5H81r0wdQKmN3q xxTfc5Copch8iiKY6lkpdGzZNNxDNRCWKqEpWn7wfeIH80U03GLyJnq+JSHkfGHtcXTFYqFg/wBV CjGosppWWlClTHZRmDR6dudF/LYaMSgl4Bgp8q8vHuSJV5M+UykoKfTSuotmP62ssRbcJK7KpEgP cgdvnU6qAanJ7jviF24kVLAtY3aYoUJCvMkhc13m8aBXQ0EuuUl/Fnze0L2u4C3irjoNknYsPdIC Qq8ud04IiCSihDp1/wAQ5TyHH83n5LhcbHZsSLZeenDC/Z+mlDd+MRxatFDGjfKddIgqltwBBnnL eM4C/wAMh45mci9avG1ZYLcsyd76mIr2JDJJosszuvzDTWQswXaSCAeNwhyFq9kWst8htVfc9F+V EDrrjaJiMwr74nsDHJ31VjMwcccfuqEMWJfZM8WefZSKpSpwKR8muVBIqfVhjyFnHjR4OLzL42GG esKqtc2fSmyJGsC9tL7hZAXu6GMesZUsdeq//gHCJIyTcmhbyKcwlk2mWpv+pFcxrAaW4LtNclu1 qJD6SBgo06ctq4K8c4qWv8XqHOOTkdBf/G3e+POkyur6FQX1/Rx+0bZMaFbeSVkVsMshKx9YibpK LQrVVyUsHGNEUWXuBURARSUvI3Kpoa02H46iYteWQ3YFrQTCE2o6iwR0E2KVaRolErBfzpGLSbNG 6V3PHvGIZrMOX5A7ZJuLS0p2sTQmYVpLTTSXnLsGWNZWMSlvyo1Cx7tV6R7/AMIOKlhT3gXPOqNq 9fu+I8OKJpTAlsxEWlVv+UlrX+x9s0nIyYHdwZrUEKr9uhVVG8dayybj26hxBsKCjGeQ+Z1TjdvH Hms18hlJoG7dvWSGz3P1Oqqr6P2943ygM9btruA+fd4ZLgHD7IyO/kKw1rGPxkM47lXSOavs/TbT M3qnc2HZESqWO420n5ds4wfECr1bWOJtt3LmxM6XuVK2fb9RqDS5uaBVk9WtGgZdB1GcomU56D5V 3UqLntPhU5BCDg1XwN1Hbl0uYQWKZOO2Oc3LmFzdLjvH46nHbFCpXlMQmk+mjhsPKk1mfTSSaeVy hmmCbgqIo+Ugv8HCalTM4a7yDPSWuQQX7ViMSmGP6iSaBI3hrw66xxQxKHEURfQs7sfmGjt5y8ba JumhZRMs+VcZxi3Kp51uUDDrrpZ7ZHtww6912MitrKFGu0jGulUa5EtUF055qp6MEoqKrlNYpiAR D465ZkuOYy7Xkwr5jjs9qo7AGeMRW4XZqn50SsNXYkGFhrMBtQqQdVvkDi2O5Dkqc6ZhMTyCGrbR Sey5lqTIq2vypWU6IoBEynSInVg2o09eMXHfjTnG459d8V5AQV6Xr/A3LcKoecx1uoVodSmDVS8v 5Ws7aLyvLhLTzKz2UztsMs3QThnLo6pEh8ilTT65fynluV47ax/IMZJWWXkli5NO0U0YW5JCqyVN HG1DHHtbtsTKqhS3oST9cT4zxXF8grZDA5KOw0XHa9SGBZIZC1SOUtHa1Q7nEkm5e4AImYsB6gAD tya4XcaNL1jmXcZ3m/FZK31tfiUXk5nTixYyo0oV6zKTqbnjvMz72zKJWPP3txhoQzSLj3qqCM0a TVWTK5ErYiUo4jz7luJwuBoVuPPdaiMl9BOEtazQ2FkF5UEeqTCJ33SOgJi7aqSnzloxyvgnFMrm c7esZ9KS3Tjvr4S9XSGWBozSZzJ88JlVNsaMQJe4WAf5QvrbeHuFSmu2yx5Nzio+c8qJfmBpWwUO Rco41o81SdFsWLNKTq+NnymfmUQtqjbLzIyKjVcqMtEdkXw9iAIqdUudcjhwcFXN8dsWuGpgoKsy g2oElgS2Za1r6lEPb1saoGGscvzR/H4d3eE8emzU1rDcgr1eYPm57MLEVp3imeqIrFb6d2Hc0g0c qdJI/lk+HxJvkJxkyyZ+PO0cZNk5Jz9dzT9H1WCunJXV7lXHVgOpFXuv2A9itduuTlnXQcT9jZkZ fz1UyJFclQRMByp9RHi/LszX8oQ8uwOJily3fkeKhWicJ80LpsjiiBfRIyX9AddpZhoT1LOS8TxE /jSbimcyskWK7EaS3rEqF/lmR98kkpCau4C+pGm4KvqB0IOn8F+OT7JOWFJ5L8+0bBqew5xgjDVN n0Gw4hQ3+WYnQNJh5fKWzGixwV2r1Go221svYjJPQ8JZ8uHoqe57+c5w/kXlUebwuQ4lxkxYajbu NXqwJbmWxbmgZbJMzb5JZYozv7aesaD5hs+EJy3j7i8mFzNDlXIxJl71WmLFqZ6sJr1YZ1auBEuy OOOSQbN7ekjn5Tu+I3tsMkJrnTWbBSJGLz3IYf5Rbtp08d9yx43XzCLTrbbNhaWeIpdFhvtfIaF5 UXxdADv6VJIuWdYSBcUDqoLionK35FFX8czVcij2s5Jw+KummNvQ3I6xn1jaWZt1J8dCDoluMq1g 7dwDLoYuvH5Z/IUVmg6VsKnLpZ31yNGapJZEGkixRLturkJiNXquGWAbtpKtqJ1o3BDhzH5Rx5qt Y54Rbym51gvMilytkr19xY6Wz8c9bvNmmN6fDKgtKsa/EZtYZRZo/sUQIEiVW3g5OioUQCN5HyRz uXNZS7b42637WSxcqxvDa/4W9WhjWmNuil2nRQyQS+sgbVAwPUhx/jzg8eHxlOpyJGo1cdk4mdJq v/FUrEsjXDu1YIsDsVeaP0jK6MVI6akXwL40/wBxOlVC/wDyNUGzV22ceuJ9DLeokMCodfoeMZTu bG2YHZYttFTjmHVi75ZWIwyMvJOXSc9KOFjoqqKmTbJLpvJPLf4jqXsZxWzDagymSm7LfWTPNas1 DHcjYsgbdDGe6Yo1UwxqoZQoLlHD464r/D1ulkuUVpas2Mx0PdX6OFIate2JKbqFcrtmcdoSOzCa RmKknRBYJzf45VfetA4sSQcqFuMWx5vdb5L4a5jCZ1JWO7WaaqrVhYGNdq+geqSzvIattlVFUGrd yKbdc6ipOwEMWsfHnKrnGsZmYv0YZjBW68K2w3fVIo0kJQvJDp2w8hADMV1YAA/EGyef8XqciyWH l/WDic5VnmaoV7LPLI0YDhI5te4VQEkKG0BJI+BAt7Vwnwqxx/JaL5Cc82f94V94u5PmO63G3yOL UqdrFMq+uKXCq6nZ6+RWGiqqys0kdOCRVXQaMFik/lKHcj5BMeP+QeR1ZcTNxjjbfpdbMWbFOKJb UqSSyVu1JXjf52kMa6zEAs419QE9OojnuBcetRZWHkvIl/U7OIrwW5ZGqxPHFHZ7sdiRPlWMSNpE CQqH7CX9epmacQa1YeVV/wBLzjmnY4Cuu9Ty7QOROAZo/orScldnz+jwMLWo2zX6AekvtJp1xr7K MezdRcoqJy4GA6aqCKxSgwvzm3V4ZWxOV4/FLaWnYho3Z1mKLVmmd5GjhcdmWWJzIkVlSDF8CGZS en1OFVbPMLOVxeeljqtcrzXacBiDtahiRY1kmQ96KKVBG0tZgRJ8QVVgOhrjOC/G+AunKaI3X5BI TR9JnOIug4landpk8JpezZpx7ss5CS85pW9TrZcbNpVirzxvEtU7XY0WDJszAiR0vUWIqErm8i8r s0MNPxzjElTEx5yC3GI1uS1Z7saOqQU0I7cCODIxrQF3ZtWDaKV6isXj7i9a9l4eQ8kjtZSTCzVZ DI1SKzBTd0Z57bg9yd0IjUWJwiqugI1YN01K5gMW3+T3iHK6bp+dyjPjfxsjKrQNCvGxYiy0HlvN T8PeEMkkKrx/qUq1sEU3z1jbbORpMqsjBKLQ6ijXz9M65ltrk0zeIM5DiKdpJMtlmkmghq2zDjUR oTZWS7KpRjOY65aIP+WJQH01ChHV45CvlnCzZa3VdMXiljhmls1RNkWdZRWMdONg6iESThZSv5hj JTXQsXdXeCeJLwmMVfjf8hkPUdNgavygrLC81FfHL1cL9jGubE9s2vMqrHITibis2jONFUUYs7dC HK5gX/mi4TOoBUiIrXkfkK2L9zlfF5J8RLNj5GhlFqGKG1WqiOsZGKaSRzwaO1aYbZk0ZSBqStq+ PcA1ehU4tyZIMtHDfjEsZrSyzVbNkyWRGofWOSCbVFsxHdC+qsCdALSv9n6rf+7e0/7tn+z9/rbl v/K3/u3+P+un/wDrv9L6pz+J7n/I4/8A9W+t/wAMv7z/AJb/AO0/8t+Hq3f4bqf87f8A/Svo/wDE t+7/AOY/+6/8z+Lr/9k= --_004_A6B8F2A767638641889989BC1BA7047934A766A7LIONALLOTLOCAL_-- From nobody Mon Aug 11 06:18: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 601C91A086B; Mon, 11 Aug 2014 06:18:47 -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 4j8IKBvkH1tr; Mon, 11 Aug 2014 06:18:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 076021A0172; Mon, 11 Aug 2014 06:18:46 -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.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140811131846.24355.95667.idtracker@ietfa.amsl.com> Date: Mon, 11 Aug 2014 06:18:46 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/vYD6EGOSi2WZtyWIqwQbKXNZaDQ Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-10.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: Mon, 11 Aug 2014 13:18:47 -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 Problem Statement Authors : Paul Quinn Thomas Nadeau Filename : draft-ietf-sfc-problem-statement-10.txt Pages : 19 Date : 2014-08-11 Abstract: This document provides an overview of the issues associated with the deployment of service functions (such as firewalls, load balancers) in large-scale environments. The term service function chaining is used to describe the definition and instantiation of an ordered set of instances of such service functions, and the subsequent "steering" of traffic flows through those service functions. The set of enabled service function chains reflect operator service offerings and is designed in conjunction with application delivery and service and network policy. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-problem-statement-10 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 Mon Aug 11 07:03: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 C43B91A03CB for ; Mon, 11 Aug 2014 07:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_57=0.6, 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 lfttwPSqN_7e for ; Mon, 11 Aug 2014 07:03:06 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 905B11A03CC for ; Mon, 11 Aug 2014 07:03:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id F122924163E; Mon, 11 Aug 2014 07:03:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id E9C8D24163C; Mon, 11 Aug 2014 07:03:00 -0700 (PDT) Message-ID: <53E8CD15.7010002@joelhalpern.com> Date: Mon, 11 Aug 2014 10:03:01 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alla Goldner , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" References: <20140803211558.28482.8328.idtracker@ietfa.amsl.com> <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/SW2CDGz94ophoqpOMlgSTFyUP00 Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.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, 11 Aug 2014 14:03:08 -0000 I would say instead that we need to fix section 4.5, to make it clear that the SFF is responsible for the encaps decaps, while the network uses the outer encapsulation for its forwarding. Yours, Joel On 8/11/14, 4:56 AM, Alla Goldner wrote: > Dear Carlos, Joel, all, > > Thanks for providing this merged architecture document! > > According to the model in figure 3 and section 4.5, the network > (underlay) components are responsible for: > > • Finding the network path to reach the next SF (next SFF) in > the SFP. > > • Encapsulate/de-capsulate the underlay network transport. > > Section 4.3 (SFF) contradicts this and says the network > encapsulation/de-capsulation is done by the SFF. > > I believe that the section 4.3 should be fixed in this regard. The > reason is that network transport functions should not necessarily be > coupled with the SFF. > > Best regards, > > *Alla Goldner* > > *Director of Mobile Technologies and Standards* > > Allot Communications > > Tel +972 9 7619251 > > Cell +972 54 2493985 > > Fax +972 9 7443626 > > *agoldner@allot.com **__* > > *www.allot.com* *__* > > *__* > > *291X55_signature (2)* > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Carlos Pignataro > (cpignata) > *Sent:* Monday, August 04, 2014 12:19 AM > *To:* sfc@ietf.org > *Subject:* [sfc] Fwd: New Version Notification for > draft-merged-sfc-architecture-01.txt > > SFCers, > > After Toronto, Joel and I have been working on resolving the key open > discussion items, and incorporating all the input and feedback received > thus into this document as the vehicle for a single SFC Architecture > item to progress. > > While we are still working on the document, we wanted to get a version > out early to the WG to test the resolution to key open items, see what > we might still be missing, and iterate. > > Please review and let us know. > > Thanks, > > Carlos & Joel. > > Begin forwarded message: > > > > *From: *> > > *Subject: New Version Notification for draft-merged-sfc-architecture-01.txt* > > *Date: *August 3, 2014 at 5:15:58 PM EDT > > *To: *Joel Halpern >, > Carlos Pignataro >, "Joel > M. Halpern" >, Carlos > Pignataro > > > > A new version of I-D, draft-merged-sfc-architecture-01.txt > has been successfully submitted by Carlos Pignataro and posted to the > IETF repository. > > Name:draft-merged-sfc-architecture > Revision:01 > Title:Service Function Chaining (SFC) Architecture > Document date:2014-08-03 > Group:Individual Submission > Pages:25 > URL: > http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-01.txt > Status: https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ > Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-01 > Diff: http://www.ietf.org/rfcdiff?url2=draft-merged-sfc-architecture-01 > > 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.ietf.org > . > > The IETF Secretariat > > ------------------------------------------------------------------------ > This message is intended only for the designated recipient(s). It may > contain confidential or proprietary information. If you are not the > designated recipient, you may not review, copy or distribute this > message. If you have mistakenly received this message, please notify the > sender by a reply e-mail and delete this message. Thank you. > > ------------------------------------------------------------------------ > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Aug 11 07:42: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 70AA51A03E4 for ; Mon, 11 Aug 2014 07:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_57=0.6, RP_MATCHES_RCVD=-0.668, 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 Dw9JlL000rTK for ; Mon, 11 Aug 2014 07:42:44 -0700 (PDT) Received: from mailgw.allot.com (mailgw.allot.com [199.203.223.210]) by ietfa.amsl.com (Postfix) with ESMTP id 68FE91A0386 for ; Mon, 11 Aug 2014 07:42:43 -0700 (PDT) Received: from PUMA.ALLOT.LOCAL (Not Verified[199.203.223.202]) by mailgw.allot.com with MailMarshal (v7, 2, 3, 6978) id ; Mon, 11 Aug 2014 17:42:41 +0300 Received: from LION.ALLOT.LOCAL ([172.20.20.40]) by PUMA.ALLOT.LOCAL ([199.203.223.202]) with mapi id 14.03.0123.003; Mon, 11 Aug 2014 17:44:24 +0300 From: Alla Goldner To: "Joel M. Halpern" , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.txt Thread-Index: AQHPtW03NJovc/o8mE+6NnTvPh1hHJvLedUg Date: Mon, 11 Aug 2014 14:44:23 +0000 Message-ID: References: <20140803211558.28482.8328.idtracker@ietfa.amsl.com> <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> <53E8CD15.7010002@joelhalpern.com> In-Reply-To: <53E8CD15.7010002@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.142.232.97] 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/JfzpBVGZruJK4Z8yOfbgtvdBAEI Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.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, 11 Aug 2014 14:42:46 -0000 Dear Joel, all, One of the motivations of SFC is be agnostic to the underlay transport ne= twork. When you couple the SFF with the encapsulation/de-capsulation process it = has to be aware of the network transport and it has to be capable to supp= ort different types of transport protocols. For me it doesn't make too much sense and it makes the SFF very complex. I think that a cleaner architecture is to have the SFF handle the SFC tas= ks and handle the SFC encapsulations (that is the metadata and SFC header= s) but leave the transport to be handled by the network layer which can b= e any type of network. Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com=20 www.allot.com -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Monday, August 11, 2014 5:03 PM To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-arc= hitecture-01.txt I would say instead that we need to fix section 4.5, to make it clear tha= t the SFF is responsible for the encaps decaps, while the network uses t= he outer encapsulation for its forwarding. Yours, Joel On 8/11/14, 4:56 AM, Alla Goldner wrote: > Dear Carlos, Joel, all, > > Thanks for providing this merged architecture document! > > According to the model in figure 3 and section 4.5, the network > (underlay) components are responsible for: > > * Finding the network path to reach the next SF (next SFF) in > the SFP. > > * Encapsulate/de-capsulate the underlay network transport. > > Section 4.3 (SFF) contradicts this and says the network=20 > encapsulation/de-capsulation is done by the SFF. > > I believe that the section 4.3 should be fixed in this regard. The=20 > reason is that network transport functions should not necessarily be=20 > coupled with the SFF. > > Best regards, > > *Alla Goldner* > > *Director of Mobile Technologies and Standards* > > Allot Communications > > Tel +972 9 7619251 > > Cell +972 54 2493985 > > Fax +972 9 7443626 > > *agoldner@allot.com **__* > > *www.allot.com* *__* > > *__* > > *291X55_signature (2)* > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Carlos=20 > Pignataro > (cpignata) > *Sent:* Monday, August 04, 2014 12:19 AM > *To:* sfc@ietf.org > *Subject:* [sfc] Fwd: New Version Notification for=20 > draft-merged-sfc-architecture-01.txt > > SFCers, > > After Toronto, Joel and I have been working on resolving the key open=20 > discussion items, and incorporating all the input and feedback=20 > received thus into this document as the vehicle for a single SFC=20 > Architecture item to progress. > > While we are still working on the document, we wanted to get a version = > out early to the WG to test the resolution to key open items, see what = > we might still be missing, and iterate. > > Please review and let us know. > > Thanks, > > Carlos & Joel. > > Begin forwarded message: > > > > *From: *> > > *Subject: New Version Notification for=20 > draft-merged-sfc-architecture-01.txt* > > *Date: *August 3, 2014 at 5:15:58 PM EDT > > *To: *Joel Halpern >, = > Carlos Pignataro >,=20 > "Joel M. Halpern" >,=20 > Carlos Pignataro > > > > A new version of I-D, draft-merged-sfc-architecture-01.txt > has been successfully submitted by Carlos Pignataro and posted to the=20 > IETF repository. > > Name:draft-merged-sfc-architecture > Revision:01 > Title:Service Function Chaining (SFC) Architecture Document=20 > date:2014-08-03 Group:Individual Submission > Pages:25 > URL: > http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-01.t > xt > Status:=20 > https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ > Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-01 > Diff:=20 > http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-01 > > Abstract: > This document describes an architecture for the specification, > creation, and ongoing maintenance of Service Function Chains (SFC) i= n > 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=20 > submission until the htmlized version and diff are available at=20 > tools.ietf.org . > > The IETF Secretariat > > ---------------------------------------------------------------------- > -- This message is intended only for the designated recipient(s). It=20 > may contain confidential or proprietary information. If you are not=20 > the designated recipient, you may not review, copy or distribute this=20 > message. If you have mistakenly received this message, please notify=20 > the sender by a reply e-mail and delete this message. Thank you. > > ---------------------------------------------------------------------- > -- > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > #########################################################################= ##################### This message is intended only for the designated recipient(s).It may cont= ain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or dist= ribute this message. If you have mistakenly received this message, please notify the sender by= =20a reply e-mail and delete this message.=20 Thank you. #########################################################################= ##################### From nobody Mon Aug 11 07:46:29 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 9B70C1A0409 for ; Mon, 11 Aug 2014 07:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_57=0.6, 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 omuvxOIgHupi for ; Mon, 11 Aug 2014 07:46:26 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44FA31A0408 for ; Mon, 11 Aug 2014 07:46:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 17E5D241957; Mon, 11 Aug 2014 07:46:26 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id F00C6241936; Mon, 11 Aug 2014 07:46:24 -0700 (PDT) Message-ID: <53E8D740.6090501@joelhalpern.com> Date: Mon, 11 Aug 2014 10:46: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.6.0 MIME-Version: 1.0 To: Alla Goldner , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" References: <20140803211558.28482.8328.idtracker@ietfa.amsl.com> <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> <53E8CD15.7010002@joelhalpern.com> 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/yE10cDYT0g2xhVPcxqOSTwGxQ3Q Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.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, 11 Aug 2014 14:46:28 -0000 That is how we had drawn the figure before. And described the functions. The problem is that this creates an interface between a network component and the SFF which can not exist visibly. There is no way I know of to ship the packets between those two. So the Encaps / decaps has to be co-located with the SFF. This archtiecture tries not to get into the internal structure of the logical components or to describe separately components that must be co-located. Some architectures do describe that. Yours, Joel On 8/11/14, 10:44 AM, Alla Goldner wrote: > Dear Joel, all, > > One of the motivations of SFC is be agnostic to the underlay transport network. > When you couple the SFF with the encapsulation/de-capsulation process it has to be aware of the network transport and it has to be capable to support different types of transport protocols. > For me it doesn't make too much sense and it makes the SFF very complex. > I think that a cleaner architecture is to have the SFF handle the SFC tasks and handle the SFC encapsulations (that is the metadata and SFC headers) but leave the transport to be handled by the network layer which can be any type of network. > > Best regards, > > > Alla Goldner > Director of Mobile Technologies and Standards > Allot Communications > Tel +972 9 7619251 > Cell +972 54 2493985 > Fax +972 9 7443626 > agoldner@allot.com > www.allot.com > > > > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Monday, August 11, 2014 5:03 PM > To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org > Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.txt > > I would say instead that we need to fix section 4.5, to make it clear that the SFF is responsible for the encaps decaps, while the network uses the outer encapsulation for its forwarding. > > Yours, > Joel > > On 8/11/14, 4:56 AM, Alla Goldner wrote: >> Dear Carlos, Joel, all, >> >> Thanks for providing this merged architecture document! >> >> According to the model in figure 3 and section 4.5, the network >> (underlay) components are responsible for: >> >> * Finding the network path to reach the next SF (next SFF) in >> the SFP. >> >> * Encapsulate/de-capsulate the underlay network transport. >> >> Section 4.3 (SFF) contradicts this and says the network >> encapsulation/de-capsulation is done by the SFF. >> >> I believe that the section 4.3 should be fixed in this regard. The >> reason is that network transport functions should not necessarily be >> coupled with the SFF. >> >> Best regards, >> >> *Alla Goldner* >> >> *Director of Mobile Technologies and Standards* >> >> Allot Communications >> >> Tel +972 9 7619251 >> >> Cell +972 54 2493985 >> >> Fax +972 9 7443626 >> >> *agoldner@allot.com **__* >> >> *www.allot.com* *__* >> >> *__* >> >> *291X55_signature (2)* >> >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Carlos >> Pignataro >> (cpignata) >> *Sent:* Monday, August 04, 2014 12:19 AM >> *To:* sfc@ietf.org >> *Subject:* [sfc] Fwd: New Version Notification for >> draft-merged-sfc-architecture-01.txt >> >> SFCers, >> >> After Toronto, Joel and I have been working on resolving the key open >> discussion items, and incorporating all the input and feedback >> received thus into this document as the vehicle for a single SFC >> Architecture item to progress. >> >> While we are still working on the document, we wanted to get a version >> out early to the WG to test the resolution to key open items, see what >> we might still be missing, and iterate. >> >> Please review and let us know. >> >> Thanks, >> >> Carlos & Joel. >> >> Begin forwarded message: >> >> >> >> *From: *> >> >> *Subject: New Version Notification for >> draft-merged-sfc-architecture-01.txt* >> >> *Date: *August 3, 2014 at 5:15:58 PM EDT >> >> *To: *Joel Halpern >, >> Carlos Pignataro >, >> "Joel M. Halpern" >, >> Carlos Pignataro > >> >> >> A new version of I-D, draft-merged-sfc-architecture-01.txt >> has been successfully submitted by Carlos Pignataro and posted to the >> IETF repository. >> >> Name:draft-merged-sfc-architecture >> Revision:01 >> Title:Service Function Chaining (SFC) Architecture Document >> date:2014-08-03 Group:Individual Submission >> Pages:25 >> URL: >> http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-01.t >> xt >> Status: >> https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ >> Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-01 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-merged-sfc-architecture-01 >> >> 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.ietf.org . >> >> The IETF Secretariat >> >> ---------------------------------------------------------------------- >> -- This message is intended only for the designated recipient(s). It >> may contain confidential or proprietary information. If you are not >> the designated recipient, you may not review, copy or distribute this >> message. If you have mistakenly received this message, please notify >> the sender by a reply e-mail and delete this message. Thank you. >> >> ---------------------------------------------------------------------- >> -- >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > ############################################################################################## > This message is intended only for the designated recipient(s).It may contain confidential or proprietary information. > If you are not the designated recipient, you may not review, copy or distribute this message. > If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. > Thank you. > ############################################################################################## > From nobody Mon Aug 11 07:48:21 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 09E601A041A for ; Mon, 11 Aug 2014 07:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 t3Nx-Fk46HUO for ; Mon, 11 Aug 2014 07:48:16 -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 2F7AA1A040D for ; Mon, 11 Aug 2014 07:48:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLC76849; Mon, 11 Aug 2014 14:48:13 +0000 (GMT) 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, 11 Aug 2014 15:47:24 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0158.001; Mon, 11 Aug 2014 07:47:15 -0700 From: Lucy yong To: "Andrew G. Malis" , "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt Thread-Index: AQHPsj5Z7YF9E5dD1UCUnQ2EPs/fnJvElhWAgAFOlbCAATuRgIAAJg6AgABvCICAA8wz0A== Date: Mon, 11 Aug 2014 14:47:15 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453CBFBE@dfweml701-chm.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A4805@NKGEML512-MBS.china.huawei.com> <57B2ECF6-8DB4-4E23-BB14-E030EB74E09C@alcatel-lucent.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.142.44] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D453CBFBEdfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/cNY3oK-jC0uNi0ouwo2zOJ5NKXs Cc: Xuxiaohu , "Dolganow, Andrew \(Andrew\)" , "sfc@ietf.org" , "Joel M. Halpern" Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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, 11 Aug 2014 14:48:19 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D453CBFBEdfweml701chmchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSBBbmR54oCZcyBwb2ludC4NCg0KTHVjeQ0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHJldyBHLiBNYWxpcw0KU2VudDogRnJp ZGF5LCBBdWd1c3QgMDgsIDIwMTQgNDo0NyBQTQ0KVG86IENhcmxvcyBQaWduYXRhcm8gKGNwaWdu YXRhKQ0KQ2M6IFh1eGlhb2h1OyBEb2xnYW5vdywgQW5kcmV3IChBbmRyZXcpOyBzZmNAaWV0Zi5v cmc7IEpvZWwgTS4gSGFscGVybg0KU3ViamVjdDogUmU6IFtzZmNdIERlZmluaXRpb24gb2YgU0ZD IEVuY2Fwc3VsYXRpb24gaW4gZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUtMDEudHh0DQoN CkNhcmxvcywNCg0KSSBhZ3JlZSB0aGF0IHRoZSBjaGFydGVyIHJlcXVpcmVzIHRoZSBlbmNhcHN1 bGF0aW9uIHRvIHN1cHBvcnQgZWFjaCBvZiB0aGUgYnVsbGV0IGl0ZW1zLCBidXQgdGhlcmUncyBu byByZXF1aXJlbWVudCB0aGF0IGV2ZXJ5IGVuY2Fwc3VsYXRlZCBwYWNrZXQgd2lsbCBuZWVkIGFs bCBvZiB0aGUgYnVsbGV0IGl0ZW1zIHN1cHBvcnRlZCwgc28gSSdtIHRyeWluZyB0byBrZWVwIHRo ZSB0ZXh0IGFzIGZsZXhpYmxlIGFzIHBvc3NpYmxlIHRvIG5vdCBwcmVjbHVkZSBwb3NzaWJsZSBz b2x1dGlvbnMuDQoNCkNoZWVycywNCkFuZHkNCg0KT24gRnJpLCBBdWcgOCwgMjAxNCBhdCAxMTow OSBBTSwgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIDxjcGlnbmF0YUBjaXNjby5jb208bWFp bHRvOmNwaWduYXRhQGNpc2NvLmNvbT4+IHdyb3RlOg0KSGksIEFuZHJldywNCg0KT24gQXVnIDgs IDIwMTQsIGF0IDg6NTMgQU0sIERvbGdhbm93LCBBbmRyZXcgKEFuZHJldykgPGFuZHJldy5kb2xn YW5vd0BhbGNhdGVsLWx1Y2VudC5jb208bWFpbHRvOmFuZHJldy5kb2xnYW5vd0BhbGNhdGVsLWx1 Y2VudC5jb20+PiB3cm90ZToNCg0KPiBJIGFncmVlIHRoYXQgd2Ugc2hvdWxkIGhhdmUgc3Ryb25n ZXIgc2VwYXJhdGlvbiBvZiB0d28gZnVuY3Rpb25zOiBTRlAgYW5kIG1ldGFkYXRhLg0KPg0KPiBI b3cgYWJvdXQgc21hbGwgZWRpdCB0byB3aGF0IEFuZHkgcHJvcG9zZWQ6DQo+DQo+IFNGQyBFbmNh cHN1bGF0aW9uOiAgQSBkYXRhIHBsYW5lIGVuY2Fwc3VsYXRpb24gdGhhdCBlbmNvZGVzIGVpdGhl ciBvbmUgb3IgYm90aCBvZg0KPiAtIHRoZSBTRlANCj4gLSBtZXRhZGF0YSAoZGF0YSBwbGFuZSBj b250ZXh0IGluZm9ybWF0aW9uKS4NCkxvb2tpbmcgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYu b3JnL3dnL3NmYy9jaGFydGVyLywgdGhlcmUgaXMgbm8gImVpdGhlciBvbmUgb3IgYm90aCBvZiIu IEluIGZhY3QsIGxvb2tpbmcgYXQgdGhlIGhpc3Rvcnkgb2YgdGhlIGNoYXJ0ZXIgdGV4dCwgdGhl IHRleHQgZm9yIFNGQyBFbmNhcHN1bGF0aW9uIGlzIGEgYnVsbGV0IGxpc3QgZm9ybSBvZiBhIGxv bmdlciBzZW50ZW5jZSB0aGF0IGluY2x1ZGVzICJhbmQiIG9ubHkgKHNlZSAwMC0wOSkuDQoNClRo YW5rcywNCg0KQ2FybG9zLg0KDQo+PiBUaGUgU0ZQIEVuY2Fwc3VsYXRpb24gaXMgdXNlZCBieSB0 aGUgU0ZDLWF3YXJlIGZ1bmN0aW9ucywgc3VjaCBhcyB0aGUgU0ZGIGFuZCBTRkMtYXdhcmUgU0Zz LCBhbmQgaXMgbm90IHVzZWQgZm9yIG5ldHdvcmsgcGFja2V0IGZvcndhcmRpbmcuDQo+DQo+DQo+ IEFuZHJldw0KPg0KPiBTZW50IGZyb20gbXkgaVBob25lDQo+DQo+PiBPbiBBdWcgNywgMjAxNCwg YXQgOToxMyBQTSwgIlh1eGlhb2h1IiA8eHV4aWFvaHVAaHVhd2VpLmNvbTxtYWlsdG86eHV4aWFv aHVAaHVhd2VpLmNvbT4+IHdyb3RlOg0KPj4NCj4+IEkgZnVsbHkgYWdyZWUgd2l0aCBBbmR54oCZ cyBwb2ludCB0aGF0IG5vdCBldmVyeSB1c2FnZSBvZiB0aGUgZW5jYXBzdWxhdGlvbiB3aWxsIG5l ZWQgYm90aCB0aGUgU0ZQIGlkZW50aWZpY2F0aW9uIGFuZCB0aGUgbWV0YWRhdGEuIEl04oCZcyBi ZXR0ZXIgdGhhdCB0aGUgU0ZDIGVuY2Fwc3VsYXRpb24gY291bGQgYmUgZmxleGlibHkgdXNlZCBm b3IgY2FycnlpbmcgU0ZQIGlkZW50aWZpY2F0aW9uLCBtZXRhZGF0YSBvciBib3RoLiBPdGhlcndp c2UsIGl0IHNlZW1zIHRoYXQgdGhvc2UgU0ZDIGFwcHJvYWNoZXMgd2hpY2ggZG9u4oCZdCB1c2Ug dGhlIFNGQyBlbmNhcHN1bGF0aW9uIGZvciBTRkMgc2VsZWN0aW9uIHdvdWxkIGhhdmUgdG8gc2Vw YXJhdGVseSBkZWZpbmUgdGhlIHdheSBvZiBjYXJyeWluZyBtZXRhZGF0YS4NCj4+DQo+PiBCZXN0 IHJlZ2FyZHMsDQo+PiBYaWFvaHUNCj4+DQo+PiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgQW5k cmV3IEcuIE1hbGlzDQo+PiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDA3LCAyMDE0IDk6MDYgUE0N Cj4+IFRvOiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkNCj4+IENjOiBKb2VsIE0uIEhhbHBl cm47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gU3ViamVjdDogUmU6IFtz ZmNdIERlZmluaXRpb24gb2YgU0ZDIEVuY2Fwc3VsYXRpb24gaW4gZHJhZnQtbWVyZ2VkLXNmYy1h cmNoaXRlY3R1cmUtMDEudHh0DQo+Pg0KPj4gQ2FybG9zLA0KPj4NCj4+IFdoZW4gSSByZS1yZWFk IHRoZSBkZWZpbml0aW9uLCBpdCBzZWVtZWQgdG8gbWUgdG8gYmUgbW9yZSBvZiBhIHN0cmluZyBv ZiB0aG91Z2h0cyB0aGFuIGEgY29uY2lzZSBkZWZpbml0aW9uLCB3aGljaCBpcyB3aHkgSSB3YXMg dHJ5aW5nIHRvIHRpZ2h0ZW4gaXQgdXAuIEEgZGVmaW5pdGlvbiBpcyBtZWFudCB0byBiZSBhIHNo b3J0IHN1bW1hcnkgZm9yIHF1aWNrIHJlZmVyZW5jZSwgd2hpbGUgdGhlIGRpc2N1c3Npb24gaW4g NC4xIGdvZXMgaW50byB0aGUgbW9yZSBmb3JtYWwgZGV0YWlscy4gIE90aGVyd2lzZSwgeW91IHdv dWxkIGp1c3QgcmVwZWF0IHRoZSBlbnRpcmUgc2VjdGlvbiA0LjEgaW4gc2VjdGlvbiAxLjMuICBU aGlzIGlzIHdoeSBpdCBkb2Vzbid0IG5lZWQgdG8gYmUgaW4gc2VwYXJhdGUgc2VudGVuY2VzLiBU aGUgImFuZC9vciIgaXMgYmVjYXVzZSBub3QgZXZlcnkgdXNhZ2Ugb2YgdGhlIGVuY2Fwc3VsYXRp b24gd2lsbCBuZWVkIGJvdGggdGhlIFNGUCBpZGVudGlmaWNhdGlvbiBhbmQgdGhlIG1ldGFkYXRh LCBzbyB0aGUgZGVmaW5pdGlvbiBuZWVkcyB0byBjb25jaXNlbHkgY29udmV5IHRoYXQuDQo+Pg0K Pj4gQ2hlZXJzLA0KPj4gQW5keQ0KPj4NCj4+IE9uIFRodSwgQXVnIDcsIDIwMTQgYXQgODo1MSBB TSwgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIDxjcGlnbmF0YUBjaXNjby5jb208bWFpbHRv OmNwaWduYXRhQGNpc2NvLmNvbT4+IHdyb3RlOg0KPj4gVGhhbmsgeW91IGZvciBnb2luZyBiYWNr IGFuZCBjaGVja2luZywgQW5keSENCj4+DQo+PiBXaGljaCBzcGVjaWZpYyBwYXJ0IG9mIHRoZSBj dXJyZW50IGRlZmluaXRpb24gZG8geW91IGJlbGlldmUgaXMgbG9vc2UgZW5vdWdoIHRvIG5lZWQg dGlnaHRlbmluZz8NCj4+DQo+PiBJIGJlbGlldmUgdGhhdCB5b3VyIG5ldyBwcm9wb3NhbCBmYWxs cyBzaG9ydGVyIHRoYW4gdGhlIGV4aXN0aW5nIHRleHQgaW4gYSBmZXcgYXJlYXM6DQo+PiDigKIg Rmlyc3QsIGl0IGNvbWJpbmVzIHR3byBkaWZmZXJlbnQgZnVuY3Rpb25zIChTRlAgaWRlbnRpZmlj YXRpb24gYW5kIG1ldGFkYXRhL2NvbnRleHQgaW5mb3JtYXRpb24pIGludG8gYSBzaW5nbGUgc2Vu dGVuY2UuIFRoaXMgb3Bwb3NlcyB0aGUgY2hhbmdlIHdlIGp1c3QgbWFkZSBiYXNlZCBvbiB5b3Vy IHByZWZlcmVuY2UgaW4gU2VjdGlvbiA0LjEsIHdoaWNoIGJyZWFrcyB0aGUgdHdvIGZ1bmN0aW9u cyBpbnRvIHR3byBzZW50ZW5jZXMsIGZvciByZWFkZXIgY2xhcml0eS4gV2hpbGUgbG9uZ2VyLCBp dCdzIHNpbXBsZXIuDQo+PiDigKIgU2Vjb25kLCBpdCBpbnRyb2R1Y2VzIGFuIGV4dHJhbmVvdXMg ImFuZC9vciIgdGhhdCB3b3VsZCBjaGFuZ2UgdGhlIG1lYW5pbmcsIGFuZCBuZWdhdGUgdGhlICJh dCBhIG1pbmltdW0iIGV4aXN0aW5nIGJpdC4gVGhhdCB3b3VsZCBub3QgYmUgc2ltcGxpZnlpbmcu DQo+PiDigKIgVGhpcmQsIHRoZXJlIGlzIG5vIHRoaXJkIGJ1dCB0aHJlZSBidWxsZXRzIGxvb2sg YmV0dGVyIDotKQ0KPj4NCj4+IE5ldC1uZXQsIHRoZSBvcmlnaW5hbCB0ZXh0LCBldmVuIHdoZW4g bG9uZ2VyIGluIGNoYXJhY3RlciBjb3VudCwgc2VlbXMgbW9yZSBjbGVhciBhbmQgc2ltcGxlciB0 byB0aGUgcmVhZGVyIChiZWNhdXNlIG9mIHRoZSBzZXBhcmF0ZWQgc2VudGVuY2VzKSwgSU1ITy4N Cj4+DQo+PiBUaGFua3MsDQo+Pg0KPj4gQ2FybG9zLg0KPj4NCj4+IE9uIEF1ZyA3LCAyMDE0LCBh dCA4OjIwIEFNLCBBbmRyZXcgRy4gTWFsaXMgPGFnbWFsaXNAZ21haWwuY29tPG1haWx0bzphZ21h bGlzQGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4NCj4+DQo+PiBDYXJsb3MgYW5kIEpvZWwsDQo+Pg0K Pj4gSW4gbGlnaHQgb2YgdGhlIHByZXZpb3VzIGRpc2N1c3Npb25zLCBJIHdlbnQgYmFjayBhbmQg cmUtcmVhZCB0aGlzIGN1cnJlbnQgZGVmaW5pdGlvbiBvZiBTRkMgRW5jYXBzdWxhdGlvbiBpbiB0 aGUgdGV4dCAoc2VjdGlvbiAxLjMpOg0KPj4NCj4+ICAgU0ZDIEVuY2Fwc3VsYXRpb246ICBUaGUg U0ZDIEVuY2Fwc3VsYXRpb24gcHJvdmlkZXMgYXQgYSBtaW5pbXVtIFNGUA0KPj4gICAgICAgIGlk ZW50aWZpY2F0aW9uLCBhbmQgaXMgdXNlZCBieSB0aGUgU0ZDLWF3YXJlIGZ1bmN0aW9ucywgc3Vj aCBhcw0KPj4gICAgICAgIHRoZSBTRkYgYW5kIFNGQy1hd2FyZSBTRnMuICBUaGUgU0ZDIEVuY2Fw c3VsYXRpb24gaXMgbm90IHVzZWQNCj4+ICAgICAgICBmb3IgbmV0d29yayBwYWNrZXQgZm9yd2Fy ZGluZy4gIEluIGFkZGl0aW9uIHRvIFNGUA0KPj4gICAgICAgIGlkZW50aWZpY2F0aW9uLCB0aGUg U0ZDIGVuY2Fwc3VsYXRpb24gY2FycmllcyBkYXRhcGxhbmUgY29udGV4dA0KPj4gICAgICAgIGlu Zm9ybWF0aW9uLCBhbHNvIHJlZmVycmVkIHRvIGFzIG1ldGFkYXRhLg0KPj4NCj4+IEkgdGhpbmsg dGhpcyBjb3VsZCBiZSB0aWdodGVuZWQgdXAgdG8gbWFrZSBzaW1wbGVyIGZvciB0aGUgcmVhZGVy Og0KPj4NCj4+IFNGQyBFbmNhcHN1bGF0aW9uOiAgQSBkYXRhIHBsYW5lIGVuY2Fwc3VsYXRpb24g dGhhdCBpZGVudGlmaWVzIHRoZSBTRlAgYW5kL29yIHByb3ZpZGVzIG1ldGFkYXRhIChkYXRhIHBs YW5lIGNvbnRleHQgaW5mb3JtYXRpb24pLiBUaGUgU0ZQIEVuY2Fwc3VsYXRpb24gaXMgdXNlZCBi eSB0aGUgU0ZDLWF3YXJlIGZ1bmN0aW9ucywgc3VjaCBhcyB0aGUgU0ZGIGFuZCBTRkMtYXdhcmUg U0ZzLCBhbmQgaXMgbm90IHVzZWQgZm9yIG5ldHdvcmsgcGFja2V0IGZvcndhcmRpbmcuDQo+Pg0K Pj4gVGhhbmtzLA0KPj4gQW5keQ0KPj4NCj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+IHNmY0Bp ZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMNCg0K --_000_2691CE0099834E4A9C5044EEC662BB9D453CBFBEdfweml701chmchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUg QW5keeKAmXMgcG9pbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MdWN5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzZmMgW21haWx0bzpz ZmMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QW5kcmV3IEcuIE1hbGlz PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXVndXN0IDA4LCAyMDE0IDQ6NDcgUE08YnI+DQo8 Yj5Ubzo8L2I+IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKTxicj4NCjxiPkNjOjwvYj4gWHV4 aWFvaHU7IERvbGdhbm93LCBBbmRyZXcgKEFuZHJldyk7IHNmY0BpZXRmLm9yZzsgSm9lbCBNLiBI YWxwZXJuPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2ZjXSBEZWZpbml0aW9uIG9mIFNGQyBF bmNhcHN1bGF0aW9uIGluIGRyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAxLnR4dDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2FybG9zLDxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSB0aGF0IHRoZSBj aGFydGVyIHJlcXVpcmVzIHRoZSBlbmNhcHN1bGF0aW9uIHRvIHN1cHBvcnQgZWFjaCBvZiB0aGUg YnVsbGV0IGl0ZW1zLCBidXQgdGhlcmUncyBubyByZXF1aXJlbWVudCB0aGF0IGV2ZXJ5IGVuY2Fw c3VsYXRlZCBwYWNrZXQgd2lsbCBuZWVkIGFsbCBvZiB0aGUgYnVsbGV0IGl0ZW1zIHN1cHBvcnRl ZCwgc28gSSdtIHRyeWluZyB0byBrZWVwIHRoZSB0ZXh0IGFzIGZsZXhpYmxlIGFzDQogcG9zc2li bGUgdG8gbm90IHByZWNsdWRlIHBvc3NpYmxlIHNvbHV0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIEZyaSwgQXVnIDgsIDIwMTQgYXQgMTE6MDkgQU0sIENhcmxvcyBQaWdu YXRhcm8gKGNwaWduYXRhKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmNwaWduYXRhQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksIEFuZHJldyw8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pjxicj4NCk9uIEF1ZyA4LCAyMDE0LCBhdCA4OjUzIEFNLCBEb2xnYW5vdywgQW5kcmV3IChBbmRy ZXcpICZsdDs8YSBocmVmPSJtYWlsdG86YW5kcmV3LmRvbGdhbm93QGFsY2F0ZWwtbHVjZW50LmNv bSI+YW5kcmV3LmRvbGdhbm93QGFsY2F0ZWwtbHVjZW50LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4N Cjxicj4NCiZndDsgSSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBoYXZlIHN0cm9uZ2VyIHNlcGFyYXRp b24gb2YgdHdvIGZ1bmN0aW9uczogU0ZQIGFuZCBtZXRhZGF0YS48YnI+DQomZ3Q7PGJyPg0KJmd0 OyBIb3cgYWJvdXQgc21hbGwgZWRpdCB0byB3aGF0IEFuZHkgcHJvcG9zZWQ6PGJyPg0KJmd0Ozxi cj4NCiZndDsgU0ZDIEVuY2Fwc3VsYXRpb246ICZuYnNwO0EgZGF0YSBwbGFuZSBlbmNhcHN1bGF0 aW9uIHRoYXQgZW5jb2RlcyBlaXRoZXIgb25lIG9yIGJvdGggb2Y8YnI+DQomZ3Q7IC0gdGhlIFNG UDxicj4NCiZndDsgLSBtZXRhZGF0YSAoZGF0YSBwbGFuZSBjb250ZXh0IGluZm9ybWF0aW9uKS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TG9va2luZyBhdCA8 YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvc2ZjL2NoYXJ0ZXIvIiB0YXJn ZXQ9Il9ibGFuayI+DQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvc2ZjL2NoYXJ0ZXIv PC9hPiwgdGhlcmUgaXMgbm8gJnF1b3Q7ZWl0aGVyIG9uZSBvciBib3RoIG9mJnF1b3Q7LiBJbiBm YWN0LCBsb29raW5nIGF0IHRoZSBoaXN0b3J5IG9mIHRoZSBjaGFydGVyIHRleHQsIHRoZSB0ZXh0 IGZvciBTRkMgRW5jYXBzdWxhdGlvbiBpcyBhIGJ1bGxldCBsaXN0IGZvcm0gb2YgYSBsb25nZXIg c2VudGVuY2UgdGhhdCBpbmNsdWRlcyAmcXVvdDthbmQmcXVvdDsgb25seSAoc2VlIDAwLTA5KS48 YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KPGJyPg0KQ2FybG9zLjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxicj4NCiZndDsmZ3Q7IFRoZSBTRlAgRW5jYXBzdWxhdGlvbiBpcyB1c2VkIGJ5IHRoZSBT RkMtYXdhcmUgZnVuY3Rpb25zLCBzdWNoIGFzIHRoZSBTRkYgYW5kIFNGQy1hd2FyZSBTRnMsIGFu ZCBpcyBub3QgdXNlZCBmb3IgbmV0d29yayBwYWNrZXQgZm9yd2FyZGluZy48YnI+DQomZ3Q7PGJy Pg0KJmd0Ozxicj4NCiZndDsgQW5kcmV3PGJyPg0KJmd0Ozxicj4NCiZndDsgU2VudCBmcm9tIG15 IGlQaG9uZTxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyBPbiBBdWcgNywgMjAxNCwgYXQgOToxMyBQ TSwgJnF1b3Q7WHV4aWFvaHUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp4dXhpYW9odUBodWF3 ZWkuY29tIj54dXhpYW9odUBodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyBJIGZ1bGx5IGFncmVlIHdpdGggQW5keeKAmXMgcG9pbnQgdGhhdCBub3Qg ZXZlcnkgdXNhZ2Ugb2YgdGhlIGVuY2Fwc3VsYXRpb24gd2lsbCBuZWVkIGJvdGggdGhlIFNGUCBp ZGVudGlmaWNhdGlvbiBhbmQgdGhlIG1ldGFkYXRhLiBJdOKAmXMgYmV0dGVyIHRoYXQgdGhlIFNG QyBlbmNhcHN1bGF0aW9uIGNvdWxkIGJlIGZsZXhpYmx5IHVzZWQgZm9yIGNhcnJ5aW5nIFNGUCBp ZGVudGlmaWNhdGlvbiwgbWV0YWRhdGEgb3IgYm90aC4gT3RoZXJ3aXNlLA0KIGl0IHNlZW1zIHRo YXQgdGhvc2UgU0ZDIGFwcHJvYWNoZXMgd2hpY2ggZG9u4oCZdCB1c2UgdGhlIFNGQyBlbmNhcHN1 bGF0aW9uIGZvciBTRkMgc2VsZWN0aW9uIHdvdWxkIGhhdmUgdG8gc2VwYXJhdGVseSBkZWZpbmUg dGhlIHdheSBvZiBjYXJyeWluZyBtZXRhZGF0YS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 IEJlc3QgcmVnYXJkcyw8YnI+DQomZ3Q7Jmd0OyBYaWFvaHU8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7IEZyb206IHNmYyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZyI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgQW5kcmV3IEcuIE1h bGlzPGJyPg0KJmd0OyZndDsgU2VudDogVGh1cnNkYXksIEF1Z3VzdCAwNywgMjAxNCA5OjA2IFBN PGJyPg0KJmd0OyZndDsgVG86IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKTxicj4NCiZndDsm Z3Q7IENjOiBKb2VsIE0uIEhhbHBlcm47IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNm Y0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW3NmY10gRGVmaW5pdGlv biBvZiBTRkMgRW5jYXBzdWxhdGlvbiBpbiBkcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZS0w MS50eHQ8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IENhcmxvcyw8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7IFdoZW4gSSByZS1yZWFkIHRoZSBkZWZpbml0aW9uLCBpdCBzZWVtZWQgdG8g bWUgdG8gYmUgbW9yZSBvZiBhIHN0cmluZyBvZiB0aG91Z2h0cyB0aGFuIGEgY29uY2lzZSBkZWZp bml0aW9uLCB3aGljaCBpcyB3aHkgSSB3YXMgdHJ5aW5nIHRvIHRpZ2h0ZW4gaXQgdXAuIEEgZGVm aW5pdGlvbiBpcyBtZWFudCB0byBiZSBhIHNob3J0IHN1bW1hcnkgZm9yIHF1aWNrIHJlZmVyZW5j ZSwgd2hpbGUgdGhlIGRpc2N1c3Npb24gaW4gNC4xIGdvZXMgaW50bw0KIHRoZSBtb3JlIGZvcm1h bCBkZXRhaWxzLiAmbmJzcDtPdGhlcndpc2UsIHlvdSB3b3VsZCBqdXN0IHJlcGVhdCB0aGUgZW50 aXJlIHNlY3Rpb24gNC4xIGluIHNlY3Rpb24gMS4zLiAmbmJzcDtUaGlzIGlzIHdoeSBpdCBkb2Vz bid0IG5lZWQgdG8gYmUgaW4gc2VwYXJhdGUgc2VudGVuY2VzLiBUaGUgJnF1b3Q7YW5kL29yJnF1 b3Q7IGlzIGJlY2F1c2Ugbm90IGV2ZXJ5IHVzYWdlIG9mIHRoZSBlbmNhcHN1bGF0aW9uIHdpbGwg bmVlZCBib3RoIHRoZSBTRlAgaWRlbnRpZmljYXRpb24gYW5kDQogdGhlIG1ldGFkYXRhLCBzbyB0 aGUgZGVmaW5pdGlvbiBuZWVkcyB0byBjb25jaXNlbHkgY29udmV5IHRoYXQuPGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyBDaGVlcnMsPGJyPg0KJmd0OyZndDsgQW5keTxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgT24gVGh1LCBBdWcgNywgMjAxNCBhdCA4OjUxIEFNLCBDYXJsb3MgUGln bmF0YXJvIChjcGlnbmF0YSkgJmx0OzxhIGhyZWY9Im1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20i PmNwaWduYXRhQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7IFRoYW5rIHlv dSBmb3IgZ29pbmcgYmFjayBhbmQgY2hlY2tpbmcsIEFuZHkhPGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyBXaGljaCBzcGVjaWZpYyBwYXJ0IG9mIHRoZSBjdXJyZW50IGRlZmluaXRpb24gZG8g eW91IGJlbGlldmUgaXMgbG9vc2UgZW5vdWdoIHRvIG5lZWQgdGlnaHRlbmluZz88YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7IEkgYmVsaWV2ZSB0aGF0IHlvdXIgbmV3IHByb3Bvc2FsIGZhbGxz IHNob3J0ZXIgdGhhbiB0aGUgZXhpc3RpbmcgdGV4dCBpbiBhIGZldyBhcmVhczo8YnI+DQomZ3Q7 Jmd0OyDigKIgRmlyc3QsIGl0IGNvbWJpbmVzIHR3byBkaWZmZXJlbnQgZnVuY3Rpb25zIChTRlAg aWRlbnRpZmljYXRpb24gYW5kIG1ldGFkYXRhL2NvbnRleHQgaW5mb3JtYXRpb24pIGludG8gYSBz aW5nbGUgc2VudGVuY2UuIFRoaXMgb3Bwb3NlcyB0aGUgY2hhbmdlIHdlIGp1c3QgbWFkZSBiYXNl ZCBvbiB5b3VyIHByZWZlcmVuY2UgaW4gU2VjdGlvbiA0LjEsIHdoaWNoIGJyZWFrcyB0aGUgdHdv IGZ1bmN0aW9ucyBpbnRvIHR3byBzZW50ZW5jZXMsIGZvcg0KIHJlYWRlciBjbGFyaXR5LiBXaGls ZSBsb25nZXIsIGl0J3Mgc2ltcGxlci48YnI+DQomZ3Q7Jmd0OyDigKIgU2Vjb25kLCBpdCBpbnRy b2R1Y2VzIGFuIGV4dHJhbmVvdXMgJnF1b3Q7YW5kL29yJnF1b3Q7IHRoYXQgd291bGQgY2hhbmdl IHRoZSBtZWFuaW5nLCBhbmQgbmVnYXRlIHRoZSAmcXVvdDthdCBhIG1pbmltdW0mcXVvdDsgZXhp c3RpbmcgYml0LiBUaGF0IHdvdWxkIG5vdCBiZSBzaW1wbGlmeWluZy48YnI+DQomZ3Q7Jmd0OyDi gKIgVGhpcmQsIHRoZXJlIGlzIG5vIHRoaXJkIGJ1dCB0aHJlZSBidWxsZXRzIGxvb2sgYmV0dGVy IDotKTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgTmV0LW5ldCwgdGhlIG9yaWdpbmFsIHRl eHQsIGV2ZW4gd2hlbiBsb25nZXIgaW4gY2hhcmFjdGVyIGNvdW50LCBzZWVtcyBtb3JlIGNsZWFy IGFuZCBzaW1wbGVyIHRvIHRoZSByZWFkZXIgKGJlY2F1c2Ugb2YgdGhlIHNlcGFyYXRlZCBzZW50 ZW5jZXMpLCBJTUhPLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhhbmtzLDxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgQ2FybG9zLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg T24gQXVnIDcsIDIwMTQsIGF0IDg6MjAgQU0sIEFuZHJldyBHLiBNYWxpcyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmFnbWFsaXNAZ21haWwuY29tIj5hZ21hbGlzQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3Rl Ojxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBDYXJsb3MgYW5kIEpv ZWwsPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJbiBsaWdodCBvZiB0aGUgcHJldmlvdXMg ZGlzY3Vzc2lvbnMsIEkgd2VudCBiYWNrIGFuZCByZS1yZWFkIHRoaXMgY3VycmVudCBkZWZpbml0 aW9uIG9mIFNGQyBFbmNhcHN1bGF0aW9uIGluIHRoZSB0ZXh0IChzZWN0aW9uIDEuMyk6PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgU0ZDIEVuY2Fwc3VsYXRpb246ICZuYnNwO1Ro ZSBTRkMgRW5jYXBzdWxhdGlvbiBwcm92aWRlcyBhdCBhIG1pbmltdW0gU0ZQPGJyPg0KJmd0OyZn dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aWRlbnRpZmljYXRpb24sIGFuZCBpcyB1c2Vk IGJ5IHRoZSBTRkMtYXdhcmUgZnVuY3Rpb25zLCBzdWNoIGFzPGJyPg0KJmd0OyZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhlIFNGRiBhbmQgU0ZDLWF3YXJlIFNGcy4gJm5ic3A7VGhl IFNGQyBFbmNhcHN1bGF0aW9uIGlzIG5vdCB1c2VkPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Zm9yIG5ldHdvcmsgcGFja2V0IGZvcndhcmRpbmcuICZuYnNwO0luIGFk ZGl0aW9uIHRvIFNGUDxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2lk ZW50aWZpY2F0aW9uLCB0aGUgU0ZDIGVuY2Fwc3VsYXRpb24gY2FycmllcyBkYXRhcGxhbmUgY29u dGV4dDxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2luZm9ybWF0aW9u LCBhbHNvIHJlZmVycmVkIHRvIGFzIG1ldGFkYXRhLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgSSB0aGluayB0aGlzIGNvdWxkIGJlIHRpZ2h0ZW5lZCB1cCB0byBtYWtlIHNpbXBsZXIgZm9y IHRoZSByZWFkZXI6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBTRkMgRW5jYXBzdWxhdGlv bjogJm5ic3A7QSBkYXRhIHBsYW5lIGVuY2Fwc3VsYXRpb24gdGhhdCBpZGVudGlmaWVzIHRoZSBT RlAgYW5kL29yIHByb3ZpZGVzIG1ldGFkYXRhIChkYXRhIHBsYW5lIGNvbnRleHQgaW5mb3JtYXRp b24pLiBUaGUgU0ZQIEVuY2Fwc3VsYXRpb24gaXMgdXNlZCBieSB0aGUgU0ZDLWF3YXJlIGZ1bmN0 aW9ucywgc3VjaCBhcyB0aGUgU0ZGIGFuZCBTRkMtYXdhcmUgU0ZzLCBhbmQgaXMgbm90IHVzZWQg Zm9yIG5ldHdvcmsgcGFja2V0DQogZm9yd2FyZGluZy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0OyBBbmR5PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBzZmMgbWFpbGluZyBsaXN0PGJyPg0K Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxi cj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmM8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_2691CE0099834E4A9C5044EEC662BB9D453CBFBEdfweml701chmchi_-- From nobody Mon Aug 11 08:20: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 C84FF1A046A for ; Mon, 11 Aug 2014 08:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_57=0.6, RP_MATCHES_RCVD=-0.668, 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 NSNnP9JMuHU4 for ; Mon, 11 Aug 2014 08:20:43 -0700 (PDT) Received: from mailgw.allot.com (mailgw.allot.com [199.203.223.210]) by ietfa.amsl.com (Postfix) with ESMTP id 29F211A040E for ; Mon, 11 Aug 2014 08:20:42 -0700 (PDT) Received: from PUMA.ALLOT.LOCAL (Not Verified[199.203.223.202]) by mailgw.allot.com with MailMarshal (v7, 2, 3, 6978) id ; Mon, 11 Aug 2014 18:20:41 +0300 Received: from LION.ALLOT.LOCAL ([172.20.20.40]) by PUMA.ALLOT.LOCAL ([199.203.223.202]) with mapi id 14.03.0123.003; Mon, 11 Aug 2014 18:22:24 +0300 From: Alla Goldner To: "Joel M. Halpern" , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.txt Thread-Index: AQHPtW03NJovc/o8mE+6NnTvPh1hHJvLedUg///PEQCAADq0YA== Date: Mon, 11 Aug 2014 15:22:23 +0000 Message-ID: References: <20140803211558.28482.8328.idtracker@ietfa.amsl.com> <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> <53E8CD15.7010002@joelhalpern.com> <53E8D740.6090501@joelhalpern.com> In-Reply-To: <53E8D740.6090501@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.142.232.97] 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/K30mlbW47w5fuZaKqG0ehXWIa8Y Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.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, 11 Aug 2014 15:20:46 -0000 Dear Joel, all, SFF and transport network connectivity point need to be co-located (this = is not mandatory but makes sense). This means that a simple L2 connectivity between SFF and the network conn= ectivity point can be used as this interface. That can be some VLAN or VXLAN or any other L2 protocol. This shouldn't i= mpose a big overhead on the SFF. Also, the same interface you are talking about should exist also between = SFF and SF proxy. So if we already need to solve it there, we can use it between SFF and ne= twork component. I strongly believe we should decouple network transport functions from th= e SFF and thus correct the section 4.3. Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com=20 www.allot.com -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Monday, August 11, 2014 5:46 PM To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-arc= hitecture-01.txt That is how we had drawn the figure before. And described the functions.= The problem is that this creates an interface between a network component= =20and the SFF which can not exist visibly. There is no way I know of to= =20ship the packets between those two. So the Encaps / decaps has to be co-located with the SFF. This archtiecture tries not to get into the internal structure of the log= ical components or to describe separately components that must be co-loca= ted. Some architectures do describe that. Yours, Joel On 8/11/14, 10:44 AM, Alla Goldner wrote: > Dear Joel, all, > > One of the motivations of SFC is be agnostic to the underlay transport = network. > When you couple the SFF with the encapsulation/de-capsulation process i= t has to be aware of the network transport and it has to be capable to su= pport different types of transport protocols. > For me it doesn't make too much sense and it makes the SFF very complex= . > I think that a cleaner architecture is to have the SFF handle the SFC t= asks and handle the SFC encapsulations (that is the metadata and SFC head= ers) but leave the transport to be handled by the network layer which can= =20be any type of network. > > Best regards, > > > Alla Goldner > Director of Mobile Technologies and Standards Allot Communications Tel = > +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626=20 > agoldner@allot.com www.allot.com > > > > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Monday, August 11, 2014 5:03 PM > To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org > Subject: Re: [sfc] Fwd: New Version Notification for=20 > draft-merged-sfc-architecture-01.txt > > I would say instead that we need to fix section 4.5, to make it clear t= hat the SFF is responsible for the encaps decaps, while the network uses= =20the outer encapsulation for its forwarding. > > Yours, > Joel > > On 8/11/14, 4:56 AM, Alla Goldner wrote: >> Dear Carlos, Joel, all, >> >> Thanks for providing this merged architecture document! >> >> According to the model in figure 3 and section 4.5, the network >> (underlay) components are responsible for: >> >> * Finding the network path to reach the next SF (next SFF) in >> the SFP. >> >> * Encapsulate/de-capsulate the underlay network transport. >> >> Section 4.3 (SFF) contradicts this and says the network=20 >> encapsulation/de-capsulation is done by the SFF. >> >> I believe that the section 4.3 should be fixed in this regard. The=20 >> reason is that network transport functions should not necessarily be=20 >> coupled with the SFF. >> >> Best regards, >> >> *Alla Goldner* >> >> *Director of Mobile Technologies and Standards* >> >> Allot Communications >> >> Tel +972 9 7619251 >> >> Cell +972 54 2493985 >> >> Fax +972 9 7443626 >> >> *agoldner@allot.com **__* >> >> *www.allot.com* *__* >> >> *__* >> >> *291X55_signature (2)* >> >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Carlos=20 >> Pignataro >> (cpignata) >> *Sent:* Monday, August 04, 2014 12:19 AM >> *To:* sfc@ietf.org >> *Subject:* [sfc] Fwd: New Version Notification for=20 >> draft-merged-sfc-architecture-01.txt >> >> SFCers, >> >> After Toronto, Joel and I have been working on resolving the key open = >> discussion items, and incorporating all the input and feedback=20 >> received thus into this document as the vehicle for a single SFC=20 >> Architecture item to progress. >> >> While we are still working on the document, we wanted to get a=20 >> version out early to the WG to test the resolution to key open items, = >> see what we might still be missing, and iterate. >> >> Please review and let us know. >> >> Thanks, >> >> Carlos & Joel. >> >> Begin forwarded message: >> >> >> >> *From: *> >> >> *Subject: New Version Notification for >> draft-merged-sfc-architecture-01.txt* >> >> *Date: *August 3, 2014 at 5:15:58 PM EDT >> >> *To: *Joel Halpern > >, Carlos Pignataro > >, "Joel M. Halpern" > >, Carlos Pignataro > > >> >> >> A new version of I-D, draft-merged-sfc-architecture-01.txt >> has been successfully submitted by Carlos Pignataro and posted to the = >> IETF repository. >> >> Name:draft-merged-sfc-architecture >> Revision:01 >> Title:Service Function Chaining (SFC) Architecture Document >> date:2014-08-03 Group:Individual Submission >> Pages:25 >> URL: >> http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-01. >> t >> xt >> Status: >> https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ >> Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-01 >> Diff: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-01 >> >> Abstract: >> This document describes an architecture for the specification, >> creation, and ongoing maintenance of Service Function Chains (SFC)= =20in >> 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=20 >> submission until the htmlized version and diff are available at=20 >> tools.ietf.org . >> >> The IETF Secretariat >> >> --------------------------------------------------------------------- >> - >> -- This message is intended only for the designated recipient(s). It=20 >> may contain confidential or proprietary information. If you are not=20 >> the designated recipient, you may not review, copy or distribute this = >> message. If you have mistakenly received this message, please notify=20 >> the sender by a reply e-mail and delete this message. Thank you. >> >> --------------------------------------------------------------------- >> - >> -- >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > ###################################################################### > ######################## This message is intended only for the=20 > designated recipient(s).It may contain confidential or proprietary info= rmation. > If you are not the designated recipient, you may not review, copy or di= stribute this message. > If you have mistakenly received this message, please notify the sender = by a reply e-mail and delete this message. > Thank you. > ###################################################################### > ######################## > #########################################################################= ##################### This message is intended only for the designated recipient(s).It may cont= ain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or dist= ribute this message. If you have mistakenly received this message, please notify the sender by= =20a reply e-mail and delete this message.=20 Thank you. #########################################################################= ##################### From nobody Mon Aug 11 08:25: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 38C421A0401 for ; Mon, 11 Aug 2014 08:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_57=0.6, 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 Sqxcgh-Kos1s for ; Mon, 11 Aug 2014 08:25:08 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D23551A03E3 for ; Mon, 11 Aug 2014 08:25:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id A78182A095C; Mon, 11 Aug 2014 08:25:08 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 402B12A095A; Mon, 11 Aug 2014 08:25:06 -0700 (PDT) Message-ID: <53E8E053.8050608@joelhalpern.com> Date: Mon, 11 Aug 2014 11:25:07 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alla Goldner , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" References: <20140803211558.28482.8328.idtracker@ietfa.amsl.com> <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> <53E8CD15.7010002@joelhalpern.com> <53E8D740.6090501@joelhalpern.com> 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/tnqEfbzcHI9z2M0Q4tdlaGpULPM Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.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, 11 Aug 2014 15:25:10 -0000 Part of my problem is that the SFF has the information about what the next SFF. (Even if the SFP allows only one next-SFF, it is the current SFF who knows what that is. And if the decision is delegated, it is delegated to the SFF. ) But if the Encaps is not part of the SFF, then the SFF has no way to express that decision. Even an Ethernet link does not handle it. I need to check the text on SF Proxy, but I usually think of that as a more-specialized SFF, not as something separate from the SFF. Yours, Joel On 8/11/14, 11:22 AM, Alla Goldner wrote: > Dear Joel, all, > > SFF and transport network connectivity point need to be co-located (this is not mandatory but makes sense). > This means that a simple L2 connectivity between SFF and the network connectivity point can be used as this interface. > That can be some VLAN or VXLAN or any other L2 protocol. This shouldn't impose a big overhead on the SFF. > > Also, the same interface you are talking about should exist also between SFF and SF proxy. > So if we already need to solve it there, we can use it between SFF and network component. > > I strongly believe we should decouple network transport functions from the SFF and thus correct the section 4.3. > > Best regards, > > Alla Goldner > Director of Mobile Technologies and Standards > Allot Communications > Tel +972 9 7619251 > Cell +972 54 2493985 > Fax +972 9 7443626 > agoldner@allot.com > www.allot.com > > > > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Monday, August 11, 2014 5:46 PM > To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org > Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.txt > > That is how we had drawn the figure before. And described the functions. > The problem is that this creates an interface between a network component and the SFF which can not exist visibly. There is no way I know of to ship the packets between those two. > > So the Encaps / decaps has to be co-located with the SFF. > This archtiecture tries not to get into the internal structure of the logical components or to describe separately components that must be co-located. Some architectures do describe that. > > Yours, > Joel > > On 8/11/14, 10:44 AM, Alla Goldner wrote: >> Dear Joel, all, >> >> One of the motivations of SFC is be agnostic to the underlay transport network. >> When you couple the SFF with the encapsulation/de-capsulation process it has to be aware of the network transport and it has to be capable to support different types of transport protocols. >> For me it doesn't make too much sense and it makes the SFF very complex. >> I think that a cleaner architecture is to have the SFF handle the SFC tasks and handle the SFC encapsulations (that is the metadata and SFC headers) but leave the transport to be handled by the network layer which can be any type of network. >> >> Best regards, >> >> >> Alla Goldner >> Director of Mobile Technologies and Standards Allot Communications Tel >> +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 >> agoldner@allot.com www.allot.com >> >> >> >> >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Monday, August 11, 2014 5:03 PM >> To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org >> Subject: Re: [sfc] Fwd: New Version Notification for >> draft-merged-sfc-architecture-01.txt >> >> I would say instead that we need to fix section 4.5, to make it clear that the SFF is responsible for the encaps decaps, while the network uses the outer encapsulation for its forwarding. >> >> Yours, >> Joel >> >> On 8/11/14, 4:56 AM, Alla Goldner wrote: >>> Dear Carlos, Joel, all, >>> >>> Thanks for providing this merged architecture document! >>> >>> According to the model in figure 3 and section 4.5, the network >>> (underlay) components are responsible for: >>> >>> * Finding the network path to reach the next SF (next SFF) in >>> the SFP. >>> >>> * Encapsulate/de-capsulate the underlay network transport. >>> >>> Section 4.3 (SFF) contradicts this and says the network >>> encapsulation/de-capsulation is done by the SFF. >>> >>> I believe that the section 4.3 should be fixed in this regard. The >>> reason is that network transport functions should not necessarily be >>> coupled with the SFF. >>> >>> Best regards, >>> >>> *Alla Goldner* >>> >>> *Director of Mobile Technologies and Standards* >>> >>> Allot Communications >>> >>> Tel +972 9 7619251 >>> >>> Cell +972 54 2493985 >>> >>> Fax +972 9 7443626 >>> >>> *agoldner@allot.com **__* >>> >>> *www.allot.com* *__* >>> >>> *__* >>> >>> *291X55_signature (2)* >>> >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Carlos >>> Pignataro >>> (cpignata) >>> *Sent:* Monday, August 04, 2014 12:19 AM >>> *To:* sfc@ietf.org >>> *Subject:* [sfc] Fwd: New Version Notification for >>> draft-merged-sfc-architecture-01.txt >>> >>> SFCers, >>> >>> After Toronto, Joel and I have been working on resolving the key open >>> discussion items, and incorporating all the input and feedback >>> received thus into this document as the vehicle for a single SFC >>> Architecture item to progress. >>> >>> While we are still working on the document, we wanted to get a >>> version out early to the WG to test the resolution to key open items, >>> see what we might still be missing, and iterate. >>> >>> Please review and let us know. >>> >>> Thanks, >>> >>> Carlos & Joel. >>> >>> Begin forwarded message: >>> >>> >>> >>> *From: *> >>> >>> *Subject: New Version Notification for >>> draft-merged-sfc-architecture-01.txt* >>> >>> *Date: *August 3, 2014 at 5:15:58 PM EDT >>> >>> *To: *Joel Halpern >> >, Carlos Pignataro >> >, "Joel M. Halpern" >> >, Carlos Pignataro >> > >>> >>> >>> A new version of I-D, draft-merged-sfc-architecture-01.txt >>> has been successfully submitted by Carlos Pignataro and posted to the >>> IETF repository. >>> >>> Name:draft-merged-sfc-architecture >>> Revision:01 >>> Title:Service Function Chaining (SFC) Architecture Document >>> date:2014-08-03 Group:Individual Submission >>> Pages:25 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-01. >>> t >>> xt >>> Status: >>> https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ >>> Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-01 >>> Diff: >>> http://www.ietf.org/rfcdiff?url2=draft-merged-sfc-architecture-01 >>> >>> 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.ietf.org . >>> >>> The IETF Secretariat >>> >>> --------------------------------------------------------------------- >>> - >>> -- This message is intended only for the designated recipient(s). It >>> may contain confidential or proprietary information. If you are not >>> the designated recipient, you may not review, copy or distribute this >>> message. If you have mistakenly received this message, please notify >>> the sender by a reply e-mail and delete this message. Thank you. >>> >>> --------------------------------------------------------------------- >>> - >>> -- >>> >>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >> ###################################################################### >> ######################## This message is intended only for the >> designated recipient(s).It may contain confidential or proprietary information. >> If you are not the designated recipient, you may not review, copy or distribute this message. >> If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. >> Thank you. >> ###################################################################### >> ######################## >> > ############################################################################################## > This message is intended only for the designated recipient(s).It may contain confidential or proprietary information. > If you are not the designated recipient, you may not review, copy or distribute this message. > If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. > Thank you. > ############################################################################################## > From nobody Mon Aug 11 09:05: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 D0DDE1A0688 for ; Mon, 11 Aug 2014 09:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 sQ5pQ0Mia50r for ; Mon, 11 Aug 2014 09:05:42 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCC401A067A for ; Mon, 11 Aug 2014 09:05:41 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id B380C4DE8F9AC; Mon, 11 Aug 2014 16:05:34 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s7BG4xBS014326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Aug 2014 18:05:36 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.52]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 11 Aug 2014 18:05:21 +0200 From: "Henderickx, Wim (Wim)" To: Lucy yong , "Andrew G. Malis" , "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt Thread-Index: AQHPsj5YGmQTNDgwUkC8vugZ2lF9lZvE+qqAgADLN4CAAMN6gIAAJg6AgABvCICABEHTgIAAN0oA Date: Mon, 11 Aug 2014 16:05:20 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A4805@NKGEML512-MBS.china.huawei.com> <57B2ECF6-8DB4-4E23-BB14-E030EB74E09C@alcatel-lucent.com> <2691CE0099834E4A9C5044EEC662BB9D453CBFBE@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453CBFBE@dfweml701-chm.china.huawei.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_D00EB632E9362wimhenderickxalcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/4hs4RVoKyhQ8UDgKe2Bc0PWbqvw Cc: Xuxiaohu , "Dolganow, Andrew \(Andrew\)" , "sfc@ietf.org" , "Joel M. Halpern" Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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, 11 Aug 2014 16:05:47 -0000 --_000_D00EB632E9362wimhenderickxalcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Same here, I believe these elements should be independent. From: Lucy yong > Date: Monday 11 August 2014 16:47 To: "Andrew G. Malis" >, "Carlo= s Pignataro (cpignata)" > Cc: Xuxiaohu >, "Dolganow, = Andrew (Andrew)" >, "sfc@ietf.org" >, "Joel M. Halpern" > Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-arch= itecture-01.txt I agree Andy=92s point. Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Andrew G. Malis Sent: Friday, August 08, 2014 4:47 PM To: Carlos Pignataro (cpignata) Cc: Xuxiaohu; Dolganow, Andrew (Andrew); sfc@ietf.org;= Joel M. Halpern Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-arch= itecture-01.txt Carlos, I agree that the charter requires the encapsulation to support each of the = bullet items, but there's no requirement that every encapsulated packet wil= l need all of the bullet items supported, so I'm trying to keep the text as= flexible as possible to not preclude possible solutions. Cheers, Andy On Fri, Aug 8, 2014 at 11:09 AM, Carlos Pignataro (cpignata) > wrote: Hi, Andrew, On Aug 8, 2014, at 8:53 AM, Dolganow, Andrew (Andrew) > wrote: > I agree that we should have stronger separation of two functions: SFP and= metadata. > > How about small edit to what Andy proposed: > > SFC Encapsulation: A data plane encapsulation that encodes either one or= both of > - the SFP > - metadata (data plane context information). Looking at http://datatracker.ietf.org/wg/sfc/charter/, there is no "either= one or both of". In fact, looking at the history of the charter text, the = text for SFC Encapsulation is a bullet list form of a longer sentence that = includes "and" only (see 00-09). Thanks, Carlos. >> The SFP Encapsulation is used by the SFC-aware functions, such as the SF= F and SFC-aware SFs, and is not used for network packet forwarding. > > > Andrew > > Sent from my iPhone > >> On Aug 7, 2014, at 9:13 PM, "Xuxiaohu" > wrote: >> >> I fully agree with Andy=92s point that not every usage of the encapsulat= ion will need both the SFP identification and the metadata. It=92s better t= hat the SFC encapsulation could be flexibly used for carrying SFP identific= ation, metadata or both. Otherwise, it seems that those SFC approaches whic= h don=92t use the SFC encapsulation for SFC selection would have to separat= ely define the way of carrying metadata. >> >> Best regards, >> Xiaohu >> >> From: sfc [mailto:sfc-bounces@ietf.org] On = Behalf Of Andrew G. Malis >> Sent: Thursday, August 07, 2014 9:06 PM >> To: Carlos Pignataro (cpignata) >> Cc: Joel M. Halpern; sfc@ietf.org >> Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-a= rchitecture-01.txt >> >> Carlos, >> >> When I re-read the definition, it seemed to me to be more of a string of= thoughts than a concise definition, which is why I was trying to tighten i= t up. A definition is meant to be a short summary for quick reference, whil= e the discussion in 4.1 goes into the more formal details. Otherwise, you = would just repeat the entire section 4.1 in section 1.3. This is why it do= esn't need to be in separate sentences. The "and/or" is because not every u= sage of the encapsulation will need both the SFP identification and the met= adata, so the definition needs to concisely convey that. >> >> Cheers, >> Andy >> >> On Thu, Aug 7, 2014 at 8:51 AM, Carlos Pignataro (cpignata) > wrote: >> Thank you for going back and checking, Andy! >> >> Which specific part of the current definition do you believe is loose en= ough to need tightening? >> >> I believe that your new proposal falls shorter than the existing text in= a few areas: >> =95 First, it combines two different functions (SFP identification and m= etadata/context information) into a single sentence. This opposes the chang= e we just made based on your preference in Section 4.1, which breaks the tw= o functions into two sentences, for reader clarity. While longer, it's simp= ler. >> =95 Second, it introduces an extraneous "and/or" that would change the m= eaning, and negate the "at a minimum" existing bit. That would not be simpl= ifying. >> =95 Third, there is no third but three bullets look better :-) >> >> Net-net, the original text, even when longer in character count, seems m= ore clear and simpler to the reader (because of the separated sentences), I= MHO. >> >> Thanks, >> >> Carlos. >> >> On Aug 7, 2014, at 8:20 AM, Andrew G. Malis > wrote: >> >> >> Carlos and Joel, >> >> In light of the previous discussions, I went back and re-read this curre= nt definition of SFC Encapsulation in the text (section 1.3): >> >> SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP >> identification, and is used by the SFC-aware functions, such as >> the SFF and SFC-aware SFs. The SFC Encapsulation is not used >> for network packet forwarding. In addition to SFP >> identification, the SFC encapsulation carries dataplane context >> information, also referred to as metadata. >> >> I think this could be tightened up to make simpler for the reader: >> >> SFC Encapsulation: A data plane encapsulation that identifies the SFP a= nd/or provides metadata (data plane context information). The SFP Encapsula= tion is used by the SFC-aware functions, such as the SFF and SFC-aware SFs,= and is not used for network packet forwarding. >> >> Thanks, >> Andy >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc --_000_D00EB632E9362wimhenderickxalcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7FFFAA07AF4ADF4B8D780F265E24E65F@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
Same here, I believe these elements should be independent.

From: Lucy yong <lucy.yong@huawei.com>
Date: Monday 11 August 2014 16:47 To: "Andrew G. Malis" <= ;agmalis@gmail.com>, "Carl= os Pignataro (cpignata)" <cpi= gnata@cisco.com>
Cc: Xuxiaohu <xuxiaohu@huawei.com>, "Dolganow, Andrew (A= ndrew)" <andr= ew.dolganow@alcatel-lucent.com>, "sfc@ietf.org" <sfc@ietf.org>, "Joel M. Ha= lpern" <jmh@joelhalpern.com<= /a>>
Subject: Re: [sfc] Definition of SF= C Encapsulation in draft-merged-sfc-architecture-01.txt

I agree Andy=92s point.<= /span>

 

Lucy

 

From: sfc [mailt= o:sfc-bounces@ietf.org] On Behalf Of Andrew G. Malis
Sent: Friday, August 08, 2014 4:47 PM
To: Carlos Pignataro (cpignata)
Cc: Xuxiaohu; Dolganow, Andrew (Andrew); sfc@ietf.org; Joel M. Halpern
Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-s= fc-architecture-01.txt

 

Carlos,

 

I agree that the charter requires the encapsulation = to support each of the bullet items, but there's no requirement that every = encapsulated packet will need all of the bullet items supported, so I'm try= ing to keep the text as flexible as possible to not preclude possible solutions.

 

Cheers,

Andy

 

On Fri, Aug 8, 2014 at 11:09 AM, Carlos Pignataro (c= pignata) <cpigna= ta@cisco.com> wrote:

Hi, Andrew,


On Aug 8, 2014, at 8:53 AM, Dolganow, Andrew (Andrew) <andrew.dolganow@alcatel-lucent.com= > wrote:

> I agree that we should have stronger separation of two functions: SFP = and metadata.
>
> How about small edit to what Andy proposed:
>
> SFC Encapsulation:  A data plane encapsulation that encodes eithe= r one or both of
> - the SFP
> - metadata (data plane context information).

Looking at http://datatracker.ietf.org/wg/sfc/charter/, there is no "either o= ne or both of". In fact, looking at the history of the charter text, t= he text for SFC Encapsulation is a bullet list form of a longer sentence th= at includes "and" only (see 00-09).

Thanks,

Carlos.


>> The SFP Encapsulation is used by the SFC-aware functions, such as = the SFF and SFC-aware SFs, and is not used for network packet forwarding. >
>
> Andrew
>
> Sent from my iPhone
>
>> On Aug 7, 2014, at 9:13 PM, "Xuxiaohu" <xuxiaohu@huawei.com> wrote:
>>
>> I fully agree with Andy=92s point that not every usage of the enca= psulation will need both the SFP identification and the metadata. It=92s be= tter that the SFC encapsulation could be flexibly used for carrying SFP ide= ntification, metadata or both. Otherwise, it seems that those SFC approaches which don=92t use the SFC encapsulation= for SFC selection would have to separately define the way of carrying meta= data.
>>
>> Best regards,
>> Xiaohu
>>
>> From: sfc [mailto:sfc-boun= ces@ietf.org] On Behalf Of Andrew G. Malis
>> Sent: Thursday, August 07, 2014 9:06 PM
>> To: Carlos Pignataro (cpignata)
>> Cc: Joel M. Halpern; sfc@ietf.org<= /a>
>> Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged= -sfc-architecture-01.txt
>>
>> Carlos,
>>
>> When I re-read the definition, it seemed to me to be more of a str= ing of thoughts than a concise definition, which is why I was trying to tig= hten it up. A definition is meant to be a short summary for quick reference= , while the discussion in 4.1 goes into the more formal details.  Otherwise, you would just repeat the entire= section 4.1 in section 1.3.  This is why it doesn't need to be in sep= arate sentences. The "and/or" is because not every usage of the e= ncapsulation will need both the SFP identification and the metadata, so the definition needs to concisely convey that.
>>
>> Cheers,
>> Andy
>>
>> On Thu, Aug 7, 2014 at 8:51 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
>> Thank you for going back and checking, Andy!
>>
>> Which specific part of the current definition do you believe is lo= ose enough to need tightening?
>>
>> I believe that your new proposal falls shorter than the existing t= ext in a few areas:
>> =95 First, it combines two different functions (SFP identification= and metadata/context information) into a single sentence. This opposes the= change we just made based on your preference in Section 4.1, which breaks = the two functions into two sentences, for reader clarity. While longer, it's simpler.
>> =95 Second, it introduces an extraneous "and/or" that wo= uld change the meaning, and negate the "at a minimum" existing bi= t. That would not be simplifying.
>> =95 Third, there is no third but three bullets look better :-)
>>
>> Net-net, the original text, even when longer in character count, s= eems more clear and simpler to the reader (because of the separated sentenc= es), IMHO.
>>
>> Thanks,
>>
>> Carlos.
>>
>> On Aug 7, 2014, at 8:20 AM, Andrew G. Malis <agmalis@gmail.com> wrote:
>>
>>
>> Carlos and Joel,
>>
>> In light of the previous discussions, I went back and re-read this= current definition of SFC Encapsulation in the text (section 1.3):
>>
>>   SFC Encapsulation:  The SFC Encapsulation provides at = a minimum SFP
>>        identification, and is used by the SFC-= aware functions, such as
>>        the SFF and SFC-aware SFs.  The SF= C Encapsulation is not used
>>        for network packet forwarding.  In= addition to SFP
>>        identification, the SFC encapsulation c= arries dataplane context
>>        information, also referred to as metada= ta.
>>
>> I think this could be tightened up to make simpler for the reader:=
>>
>> SFC Encapsulation:  A data plane encapsulation that identifie= s the SFP and/or provides metadata (data plane context information). The SF= P Encapsulation is used by the SFC-aware functions, such as the SFF and SFC= -aware SFs, and is not used for network packet forwarding.
>>
>> Thanks,
>> Andy
>>
>>
>>
>> _______________________________________________
>> sfc mailing list
>> sfc@ietf.org
>> https://www.ietf.org/mailman/listinfo/sfc

 

 --_000_D00EB632E9362wimhenderickxalcatellucentcom_-- From nobody Mon Aug 11 11:29: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 CF5A21A0661 for ; Mon, 11 Aug 2014 11:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_57=0.6, 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 0bdwTZOUxoUD for ; Mon, 11 Aug 2014 11:29:22 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4AE91A0066 for ; Mon, 11 Aug 2014 11:29:22 -0700 (PDT) Received: from emg-ca-1-2 (localhost [127.0.0.1]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id EB30253E75; Mon, 11 Aug 2014 11:29:01 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Mon, 11 Aug 2014 11:29:01.939 -0700 x-echoworx-msg-id: d33467c7-cc99-4687-a215-c941bf2d5222 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-2 (JAMES SMTP Server 2.3.2) with SMTP ID 515; Mon, 11 Aug 2014 11:29:01 -0700 (PDT) Received: from HUB021-CA-6.exch021.domain.local (unknown [10.254.4.92]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id CEC6153E75; Mon, 11 Aug 2014 11:29:01 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0174.001; Mon, 11 Aug 2014 11:29:22 -0700 From: Ron Parker To: Alla Goldner , "Joel M. Halpern" , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.txt Thread-Index: AQHPtWQt2xbT3pzzL0yYgMkZIwSK8JvL5HyAgAALj4CAAACQAIAACg6A//+92QA= Date: Mon, 11 Aug 2014 18:29:21 +0000 Message-ID: References: <20140803211558.28482.8328.idtracker@ietfa.amsl.com> <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> <53E8CD15.7010002@joelhalpern.com> <53E8D740.6090501@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] x-source-routing-agent: Processed Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/33lrqG7toUCEHtIh-lbmguLFfaQ Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.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, 11 Aug 2014 18:29:26 -0000 Alla, I'm trying to clarify, in my mind, the distinction of network encapsulation= and network transport. For reasons that Joel states, I feel the transpor= t encapsulation and de-encapsulation must happen at the SFF (i.e., the SFF = terminates the transport tunnels). The networking path followed by those = transport tunnels is based on the network switching/routing behavior and ne= ed not be visible to the SFF. In an SDN overlay type of network, the SFF= would be the Virtual Tunnel Endpoint (VTEP) in this way of thinking. =20 Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Alla Goldner Sent: Monday, August 11, 2014 11:22 AM To: Joel M. Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-archi= tecture-01.txt Dear Joel, all, SFF and transport network connectivity point need to be co-located (this is= not mandatory but makes sense). This means that a simple L2 connectivity between SFF and the network connec= tivity point can be used as this interface. That can be some VLAN or VXLAN or any other L2 protocol. This shouldn't imp= ose a big overhead on the SFF. Also, the same interface you are talking about should exist also between SF= F and SF proxy. So if we already need to solve it there, we can use it between SFF and netw= ork component. I strongly believe we should decouple network transport functions from the = SFF and thus correct the section 4.3. Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972= 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com www.a= llot.com -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Monday, August 11, 2014 5:46 PM To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-archi= tecture-01.txt That is how we had drawn the figure before. And described the functions. The problem is that this creates an interface between a network component a= nd the SFF which can not exist visibly. There is no way I know of to ship = the packets between those two. So the Encaps / decaps has to be co-located with the SFF. This archtiecture tries not to get into the internal structure of the logic= al components or to describe separately components that must be co-located.= Some architectures do describe that. Yours, Joel On 8/11/14, 10:44 AM, Alla Goldner wrote: > Dear Joel, all, > > One of the motivations of SFC is be agnostic to the underlay transport ne= twork. > When you couple the SFF with the encapsulation/de-capsulation process it = has to be aware of the network transport and it has to be capable to suppor= t different types of transport protocols. > For me it doesn't make too much sense and it makes the SFF very complex. > I think that a cleaner architecture is to have the SFF handle the SFC tas= ks and handle the SFC encapsulations (that is the metadata and SFC headers)= but leave the transport to be handled by the network layer which can be an= y type of network. > > Best regards, > > > Alla Goldner > Director of Mobile Technologies and Standards Allot Communications Tel=20 > +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626=20 > agoldner@allot.com www.allot.com > > > > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Monday, August 11, 2014 5:03 PM > To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org > Subject: Re: [sfc] Fwd: New Version Notification for=20 > draft-merged-sfc-architecture-01.txt > > I would say instead that we need to fix section 4.5, to make it clear tha= t the SFF is responsible for the encaps decaps, while the network uses the= outer encapsulation for its forwarding. > > Yours, > Joel > > On 8/11/14, 4:56 AM, Alla Goldner wrote: >> Dear Carlos, Joel, all, >> >> Thanks for providing this merged architecture document! >> >> According to the model in figure 3 and section 4.5, the network >> (underlay) components are responsible for: >> >> * Finding the network path to reach the next SF (next SFF) in >> the SFP. >> >> * Encapsulate/de-capsulate the underlay network transport. >> >> Section 4.3 (SFF) contradicts this and says the network=20 >> encapsulation/de-capsulation is done by the SFF. >> >> I believe that the section 4.3 should be fixed in this regard. The=20 >> reason is that network transport functions should not necessarily be=20 >> coupled with the SFF. >> >> Best regards, >> >> *Alla Goldner* >> >> *Director of Mobile Technologies and Standards* >> >> Allot Communications >> >> Tel +972 9 7619251 >> >> Cell +972 54 2493985 >> >> Fax +972 9 7443626 >> >> *agoldner@allot.com **__* >> >> *www.allot.com* *__* >> >> *__* >> >> *291X55_signature (2)* >> >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Carlos=20 >> Pignataro >> (cpignata) >> *Sent:* Monday, August 04, 2014 12:19 AM >> *To:* sfc@ietf.org >> *Subject:* [sfc] Fwd: New Version Notification for=20 >> draft-merged-sfc-architecture-01.txt >> >> SFCers, >> >> After Toronto, Joel and I have been working on resolving the key open=20 >> discussion items, and incorporating all the input and feedback=20 >> received thus into this document as the vehicle for a single SFC=20 >> Architecture item to progress. >> >> While we are still working on the document, we wanted to get a=20 >> version out early to the WG to test the resolution to key open items,=20 >> see what we might still be missing, and iterate. >> >> Please review and let us know. >> >> Thanks, >> >> Carlos & Joel. >> >> Begin forwarded message: >> >> >> >> *From: *> >> >> *Subject: New Version Notification for >> draft-merged-sfc-architecture-01.txt* >> >> *Date: *August 3, 2014 at 5:15:58 PM EDT >> >> *To: *Joel Halpern > >, Carlos Pignataro > >, "Joel M. Halpern" > >, Carlos Pignataro > > >> >> >> A new version of I-D, draft-merged-sfc-architecture-01.txt >> has been successfully submitted by Carlos Pignataro and posted to the=20 >> IETF repository. >> >> Name:draft-merged-sfc-architecture >> Revision:01 >> Title:Service Function Chaining (SFC) Architecture Document >> date:2014-08-03 Group:Individual Submission >> Pages:25 >> URL: >> http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-01. >> t >> xt >> Status: >> https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ >> Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-01 >> Diff: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-01 >> >> Abstract: >> This document describes an architecture for the specification, >> creation, and ongoing maintenance of Service Function Chains (SFC) i= n >> 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=20 >> submission until the htmlized version and diff are available at=20 >> tools.ietf.org . >> >> The IETF Secretariat >> >> --------------------------------------------------------------------- >> - >> -- This message is intended only for the designated recipient(s). It=20 >> may contain confidential or proprietary information. If you are not=20 >> the designated recipient, you may not review, copy or distribute this=20 >> message. If you have mistakenly received this message, please notify=20 >> the sender by a reply e-mail and delete this message. Thank you. >> >> --------------------------------------------------------------------- >> - >> -- >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > ###################################################################### > ######################## This message is intended only for the=20 > designated recipient(s).It may contain confidential or proprietary inform= ation. > If you are not the designated recipient, you may not review, copy or dist= ribute this message. > If you have mistakenly received this message, please notify the sender by= a reply e-mail and delete this message. > Thank you. > ###################################################################### > ######################## > ###########################################################################= ################### This message is intended only for the designated recipient(s).It may contai= n confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distri= bute this message. If you have mistakenly received this message, please notify the sender by a= reply e-mail and delete this message.=20 Thank you. ###########################################################################= ################### _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Aug 11 11:52: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 848991A008E for ; Mon, 11 Aug 2014 11:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 pkTS0NkfAqeO for ; Mon, 11 Aug 2014 11:52: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 E1EF91A005E for ; Mon, 11 Aug 2014 11:52:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLC92033; Mon, 11 Aug 2014 18:51:59 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 11 Aug 2014 19:51:58 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Mon, 11 Aug 2014 11:51:49 -0700 From: Lucy yong To: "sfc@ietf.org" Thread-Topic: commment on draft merged-sfc-architecture-01 Thread-Index: Ac+1lV2bUWy7j9OcSg+1LcHuFbPT6w== Date: Mon, 11 Aug 2014 18:51:48 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453CC138@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.142.44] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D453CC138dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/nIg7VHa3xO-97R8jM_5Fg5ea6bs Subject: [sfc] commment on draft merged-sfc-architecture-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, 11 Aug 2014 18:52:04 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D453CC138dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Joel and Carlos, Here are some comments beside the comments others already stated. SFC definition in this version: Service Function Chain (SFC): A service Function chain defines an abstract set of service functions and their ordering constraints that must be applied to packets and/or frames selected as a result of classification. The implied order may not be a linear progression as the architecture allows for nodes that copy to more than one branch, and also allows for cases where there is flexibility in the order in which services need to be applied. The term service chain is often used as shorthand for service function chain. In previous version: Service Function Chain (SFC): A service Function chain defines an ordered set of service functions that must be applied to packets and/or frames selected as a result of classification. The implied order may not be a linear progression as the architecture allows for nodes that copy to more than one branch. The term service chain is often used as shorthand for service function chain. Comment: I am not sure why it has been changed and what use case drives the= order flexibility. Don't see the rest of architecture change to allow/desc= ribe this. When such flexibility applies, does it mean that SFC is just a s= et of SFs? Could you explain? Comments: Service Function Definition in section 1.3 is too long. Last para= graph in the definition does not belong to SF definition. Suggest giving sh= orter definition and have the SF description in section 4.2. Section 2. ...it describes a method for deploying SFs in a way that enables dynamic ordering and topological independence of those SFs as well as the exchange of metadata between participating entities... Comment: Suggest using "dynamic selection of those SFs". "ordering" make c= onfusion here. Section 2.1 SFCs can start from the origination point of the service function graph (i.e.: node 1 in Figure 1), or from any subsequent node in the graph. Comment: Add a note that a node in graph represents an abstract Service Fu= nction. Section 2.3 State that a SF may apply part of zero, one, or multiple SFPs that associat= e to a single SFC. Section 4.1 The SFC encapsulation provides explicit information used to identify the SFP. However, ... Comment: remove this sentence and combine the rest of paragraph (however, .= ..) with previous paragraph. Regards/Thanks, Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D453CC138dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Joel and Carlos,

 

Here are some comments beside the comments others al= ready stated.

 

SFC definition in this= version:  

 

  Service Function Chain (SFC):  A = service Function chain defines an

        abstract set of service functions and their order= ing constraints

      = ;  that must be applied to packets and/or f= rames selected as a

        re= sult of classification.  The implied order may not be a linear

        pr= ogression as the architecture allows for nodes that copy to

        mo= re than one branch, and also allows for cases where there is

      = ;  flexibility in the order in which services need to be applied.=

        Th= e term service chain is often used as shorthand for service

        fu= nction chain.

 

In previous version:

Service Function Chain (SFC):  A service= Function chain defines an

      = ;  ordered set of service functions that must be applied to packets<= /p>

        an= d/or frames selected as a result of classification.  The

        im= plied order may not be a linear progression as the

        ar= chitecture allows for nodes that copy to more than one branch.

        Th= e term service chain is often used as shorthand for service

        fu= nction chain.

 

Comment: I am not sure why it has been changed and w= hat use case drives the order flexibility. Don’t see the rest of arch= itecture change to allow/describe this. When such flexibility applies, does= it mean that SFC is just a set of SFs? Could you explain?

 

Comments: Service Function Definition in section 1.3= is too long. Last paragraph in the definition does not belong to SF defini= tion. Suggest giving shorter definition and have the SF description in sect= ion 4.2.

 

Section 2.

…it describes a method fo= r deploying SFs in a way that enables

   dynamic ordering a= nd topological independence of those SFs as well as

   the exchange of me= tadata between participating entities…

=  

Comment:  Suggest using “dynamic selectio= n of those SFs”. “ordering” make confusion here.

 

Section 2.1

 

SFCs can start from the origination point of = the service function

   graph (i.e.: node 1 in Figure 1)= , or from any subsequent node in the

=    graph. 

Comment:  Add a note that a node in graph repre= sents an abstract Service Function.  

 

Section 2.3

 

State that a SF may apply part of zero, one, or mult= iple SFPs that associate to a single SFC.

=  

Section 4.1

The SFC encapsulation provides explicit information used to identify

   the SFP. However, …  

Comment: remove this s= entence and combine the rest of paragraph (however, …) with previous = paragraph.

 

Regards/Thanks,

Lucy

 

--_000_2691CE0099834E4A9C5044EEC662BB9D453CC138dfweml701chmchi_-- From nobody Mon Aug 11 12:00: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 D20A91A002E for ; Mon, 11 Aug 2014 12:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, 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 75vS_3Lj9a2B for ; Mon, 11 Aug 2014 11:59:57 -0700 (PDT) Received: from smtp1.riverbed.com (smtp1.riverbed.com [208.70.196.45]) by ietfa.amsl.com (Postfix) with ESMTP id 219B61A0049 for ; Mon, 11 Aug 2014 11:59:57 -0700 (PDT) Received: from unknown (HELO 365EXCH-HUB-P1.nbttech.com) ([10.16.4.1]) by smtp1.riverbed.com with ESMTP; 11 Aug 2014 11:59:36 -0700 Received: from SFO1EXC-MBXP14.nbttech.com ([fe80::48a3:fcd6:284c:af72]) by 365EXCH-HUB-P1.nbttech.com ([::1]) with mapi id 14.03.0195.001; Mon, 11 Aug 2014 11:59:35 -0700 From: Kevin Glavin To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] SFC Problem Statement to IESG Thread-Index: AQHPtZZkU7eygBQELkiKupzFgFkUdg== Date: Mon, 11 Aug 2014 18:59:35 +0000 Message-ID: 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_D00E60462A9F8kevinglavinriverbedcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/tH1XD7vmXa5zCF0xClP_OSBtcJ0 Subject: Re: [sfc] SFC Problem Statement to IESG 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, 11 Aug 2014 19:00:05 -0000 --_000_D00E60462A9F8kevinglavinriverbedcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As a contributor to the problem statement, I am not aware of any IPR relate= d to the problem statement Kevin From: "Jim Guichard (jguichar)" > Date: Friday, August 8, 2014 12:48 PM To: "sfc@ietf.org" > Subject: [sfc] SFC Problem Statement to IESG Dear WG: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ has been = updated in accordance with the comments and suggestions made on the mailing= list and during our recent face-to-face meeting in Toronto. The next step = is to send the document to the IESG for review and approval. For the authors of this document, please confirm to the mailing list that a= ll relevant IPR you are aware of has been properly disclosed. If you are on the SFC WG mailing list but are not listed as an author or co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. Jim --_000_D00E60462A9F8kevinglavinriverbedcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <67391DD1F987514EB3D5E8C6BC2454A0@riverbed.com> Content-Transfer-Encoding: quoted-printable
As a contributor to the problem statement, I am not aware of= any IPR related to the problem statement
Kevin


From: "Jim Guichard (jguichar)= " <jguichar@cisco.com>=
Date: Friday, August 8, 2014 12:48 = PM
To: "sfc@ietf.org" <sfc@ietf.= org>
Subject: [sfc] SFC Problem Statemen= t to IESG

Dear WG:

http://datatracker.ietf.org/doc/draft-= ietf-sfc-problem-statement/ has been updated in accordance with th= e comments and suggestions made on the mailing list and during our recent face-to-face meeting in Toronto. The next step = is to send the document to the IESG for review and approval. 

For the authors of this document, please = confirm to the mailing list that all relevant IPR you are aware of has been= properly disclosed. 

If you are on the SFC WG mailing list but are not listed as an author = or contributor, then please explicitly respond only if you are aware of any= IPR that has not yet been disclosed in conformance with IETF rules.

Jim





--_000_D00E60462A9F8kevinglavinriverbedcom_-- From nobody Mon Aug 11 12:07: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 362931A0062 for ; Mon, 11 Aug 2014 12:07:34 -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 5OhdFdATKjW2 for ; Mon, 11 Aug 2014 12:07:33 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3820A1A0025 for ; Mon, 11 Aug 2014 12:07:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id D10F51207AF; Mon, 11 Aug 2014 12:07:32 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 2AC731207A4; Mon, 11 Aug 2014 12:07:32 -0700 (PDT) Message-ID: <53E91475.50404@joelhalpern.com> Date: Mon, 11 Aug 2014 15:07:33 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Lucy yong , "sfc@ietf.org" References: <2691CE0099834E4A9C5044EEC662BB9D453CC138@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453CC138@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/rW0gzDdMC7QlC8y_d1nKmBLQpKI Subject: Re: [sfc] commment on draft merged-sfc-architecture-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, 11 Aug 2014 19:07:34 -0000 Lucy, The reason we added ordering flexibility in the SFC definition is that we understood that to be part of what folks were requesting on the mailing list. I don't much care one way or the other. It is undeniable that there are many cases where there is flexibility in the order in which services are applied without loss of generality. (In some contexts you can apply charging either before or after optimization, for example.) Whether we should allow that is up to the WG. Yours, Joel On 8/11/14, 2:51 PM, Lucy yong wrote: > Hi Joel and Carlos, > > Here are some comments beside the comments others already stated. > > SFC definition in this version: > > Service Function Chain (SFC): A service Function chain defines an > > abstract set of service functions and their ordering constraints > > that must be applied to packets and/or frames selected as a > > result of classification. The implied order may not be a linear > > progression as the architecture allows for nodes that copy to > > more than one branch, and also allows for cases where there is > > flexibility in the order in which services need to be applied. > > The term service chain is often used as shorthand for service > > function chain. > > In previous version: > > Service Function Chain (SFC): A service Function chain defines an > > ordered set of service functions that must be applied topackets > > and/or frames selected as a result of classification. The > > implied order may not be a linear progression as the > > architecture allows for nodes that copy to more than one branch. > > The term service chain is often used as shorthand for service > > function chain. > > Comment: I am not sure why it has been changed and what use case drives > the order flexibility. Don’t see the rest of architecture change to > allow/describe this. When such flexibility applies, does it mean that > SFC is just a set of SFs? Could you explain? > ... From nobody Mon Aug 11 13:26: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 379A91A014B for ; Mon, 11 Aug 2014 13:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 8B-g8XSSKC57 for ; Mon, 11 Aug 2014 13:26:21 -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 05DCA1A0002 for ; Mon, 11 Aug 2014 13:26:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLC96347; Mon, 11 Aug 2014 20:26:19 +0000 (GMT) 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; Mon, 11 Aug 2014 21:26:18 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml703-chm.china.huawei.com ([169.254.5.198]) with mapi id 14.03.0158.001; Mon, 11 Aug 2014 13:26:12 -0700 From: Lucy yong To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] commment on draft merged-sfc-architecture-01 Thread-Index: Ac+1lV2bUWy7j9OcSg+1LcHuFbPT6wAPNACAAAxhjkA= Date: Mon, 11 Aug 2014 20:26:11 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453CC1E7@dfweml701-chm.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D453CC138@dfweml701-chm.china.huawei.com> <53E91475.50404@joelhalpern.com> In-Reply-To: <53E91475.50404@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.142.44] 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/DRcnnD4sQ5W2ez2cUi_dtJ7wGOg Subject: Re: [sfc] commment on draft merged-sfc-architecture-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, 11 Aug 2014 20:26:23 -0000 Joel, I missed such discussion on the list for sure. If this is allowed, how does= the architecture reflect to it? Should we say that an SFC could be a set o= f SFs that traffic MUST pass through, but the sequence of SFs traffic trave= rse does not matter. This let a SFF to select any rest of SFs (traffic not = passes over yet) in a SFC? Should the arch add that too? I do not see the charter text stating this as SFC but agree some use case t= hat the order may not matter to the customer, or say traffic.=20 Thanks, Lucy =20 -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Monday, August 11, 2014 2:08 PM To: Lucy yong; sfc@ietf.org Subject: Re: [sfc] commment on draft merged-sfc-architecture-01 Lucy, The reason we added ordering flexibility in the SFC definition is that= we understood that to be part of what folks were requesting on the mailing= list. I don't much care one way or the other. It is undeniable that ther= e are many cases where there is flexibility in the order in which services = are applied without loss of generality. (In some contexts you can apply ch= arging either before or after optimization, for example.) Whether we should allow that is up to the WG. Yours, Joel On 8/11/14, 2:51 PM, Lucy yong wrote: > Hi Joel and Carlos, > > Here are some comments beside the comments others already stated. > > SFC definition in this version: > > Service Function Chain (SFC): A service Function chain defines an > > abstract set of service functions and their ordering constraints > > that must be applied to packets and/or frames selected as a > > result of classification. The implied order may not be a=20 > linear > > progression as the architecture allows for nodes that copy to > > more than one branch, and also allows for cases where there=20 > is > > flexibility in the order in which services need to be applied. > > The term service chain is often used as shorthand for service > > function chain. > > In previous version: > > Service Function Chain (SFC): A service Function chain defines an > > ordered set of service functions that must be applied=20 > topackets > > and/or frames selected as a result of classification. The > > implied order may not be a linear progression as the > > architecture allows for nodes that copy to more than one branch. > > The term service chain is often used as shorthand for service > > function chain. > > Comment: I am not sure why it has been changed and what use case=20 > drives the order flexibility. Don't see the rest of architecture=20 > change to allow/describe this. When such flexibility applies, does it=20 > mean that SFC is just a set of SFs? Could you explain? > ... From nobody Mon Aug 11 13:34:21 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 572411A005B for ; Mon, 11 Aug 2014 13:34:19 -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 a8NYc9mmJZS1 for ; Mon, 11 Aug 2014 13:34:18 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D84B1A0010 for ; Mon, 11 Aug 2014 13:34:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 056A7127131; Mon, 11 Aug 2014 13:34:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 411CE127130; Mon, 11 Aug 2014 13:34:17 -0700 (PDT) Message-ID: <53E928C8.7060800@joelhalpern.com> Date: Mon, 11 Aug 2014 16:34:16 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Lucy yong , "sfc@ietf.org" References: <2691CE0099834E4A9C5044EEC662BB9D453CC138@dfweml701-chm.china.huawei.com> <53E91475.50404@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D453CC1E7@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453CC1E7@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/6ZHhvNsGIEh6iG6T6l8f4gxZtH8 Subject: Re: [sfc] commment on draft merged-sfc-architecture-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, 11 Aug 2014 20:34:19 -0000 An SFC can include order constraints. That is clearly necessary. As currently described, an SFC would consist of a list of abstract service functions, with ordering constraints where desired. Exactly how flexible that is is left largely up to the control systems, as the definition of SFC and the representations for it are not really our space. Yours, Joel On 8/11/14, 4:26 PM, Lucy yong wrote: > Joel, > > I missed such discussion on the list for sure. If this is allowed, how does the architecture reflect to it? Should we say that an SFC could be a set of SFs that traffic MUST pass through, but the sequence of SFs traffic traverse does not matter. This let a SFF to select any rest of SFs (traffic not passes over yet) in a SFC? Should the arch add that too? > > I do not see the charter text stating this as SFC but agree some use case that the order may not matter to the customer, or say traffic. > > Thanks, > Lucy > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Monday, August 11, 2014 2:08 PM > To: Lucy yong; sfc@ietf.org > Subject: Re: [sfc] commment on draft merged-sfc-architecture-01 > > Lucy, > The reason we added ordering flexibility in the SFC definition is that we understood that to be part of what folks were requesting on the mailing list. I don't much care one way or the other. It is undeniable that there are many cases where there is flexibility in the order in which services are applied without loss of generality. (In some contexts you can apply charging either before or after optimization, for > example.) Whether we should allow that is up to the WG. > > Yours, > Joel > > On 8/11/14, 2:51 PM, Lucy yong wrote: >> Hi Joel and Carlos, >> >> Here are some comments beside the comments others already stated. >> >> SFC definition in this version: >> >> Service Function Chain (SFC): A service Function chain defines an >> >> abstract set of service functions and their ordering constraints >> >> that must be applied to packets and/or frames selected as a >> >> result of classification. The implied order may not be a >> linear >> >> progression as the architecture allows for nodes that copy to >> >> more than one branch, and also allows for cases where there >> is >> >> flexibility in the order in which services need to be applied. >> >> The term service chain is often used as shorthand for service >> >> function chain. >> >> In previous version: >> >> Service Function Chain (SFC): A service Function chain defines an >> >> ordered set of service functions that must be applied >> topackets >> >> and/or frames selected as a result of classification. The >> >> implied order may not be a linear progression as the >> >> architecture allows for nodes that copy to more than one branch. >> >> The term service chain is often used as shorthand for service >> >> function chain. >> >> Comment: I am not sure why it has been changed and what use case >> drives the order flexibility. Don't see the rest of architecture >> change to allow/describe this. When such flexibility applies, does it >> mean that SFC is just a set of SFs? Could you explain? >> > ... > From nobody Mon Aug 11 14:01: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 B746E1A00BE for ; Mon, 11 Aug 2014 14:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 YIN4Dhi9PPaj for ; Mon, 11 Aug 2014 14:01:13 -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 EAEDB1A0002 for ; Mon, 11 Aug 2014 14:01:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLC97953; Mon, 11 Aug 2014 21:01:11 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 11 Aug 2014 22:01:10 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm.china.huawei.com ([169.254.4.217]) with mapi id 14.03.0158.001; Mon, 11 Aug 2014 14:01:08 -0700 From: Lucy yong To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] commment on draft merged-sfc-architecture-01 Thread-Index: Ac+1lV2bUWy7j9OcSg+1LcHuFbPT6wAPNACAAAxhjkD//7UuAIAAc48g Date: Mon, 11 Aug 2014 21:01:08 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453CC23D@dfweml701-chm.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D453CC138@dfweml701-chm.china.huawei.com> <53E91475.50404@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D453CC1E7@dfweml701-chm.china.huawei.com> <53E928C8.7060800@joelhalpern.com> In-Reply-To: <53E928C8.7060800@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.142.44] 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/4PFsiFHkzE5EANbuW7iXEF3BLxY Subject: Re: [sfc] commment on draft merged-sfc-architecture-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, 11 Aug 2014 21:01:17 -0000 Joel, Your last sentence is interesting. The merged arch did define SFC in sectio= n 1.3 and further describe it in section 2. Maybe we at least make the architecture clear if a SFP in a SFC can be a se= t of SFs w/ order flexible or not if the SFC is order flexible. IMO: it sho= uld not. Thus, it is pure control plane implementation. =20 Thanks, Lucy=20 =20 -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Monday, August 11, 2014 3:34 PM To: Lucy yong; sfc@ietf.org Subject: Re: [sfc] commment on draft merged-sfc-architecture-01 An SFC can include order constraints. That is clearly necessary. As currently described, an SFC would consist of a list of abstract service = functions, with ordering constraints where desired. Exactly how flexible t= hat is is left largely up to the control systems, as the definition of SFC = and the representations for it are not really our space. Yours, Joel On 8/11/14, 4:26 PM, Lucy yong wrote: > Joel, > > I missed such discussion on the list for sure. If this is allowed, how do= es the architecture reflect to it? Should we say that an SFC could be a set= of SFs that traffic MUST pass through, but the sequence of SFs traffic tra= verse does not matter. This let a SFF to select any rest of SFs (traffic no= t passes over yet) in a SFC? Should the arch add that too? > > I do not see the charter text stating this as SFC but agree some use case= that the order may not matter to the customer, or say traffic. > > Thanks, > Lucy > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Monday, August 11, 2014 2:08 PM > To: Lucy yong; sfc@ietf.org > Subject: Re: [sfc] commment on draft merged-sfc-architecture-01 > > Lucy, > The reason we added ordering flexibility in the SFC definition=20 > is that we understood that to be part of what folks were requesting on=20 > the mailing list. I don't much care one way or the other. It is=20 > undeniable that there are many cases where there is flexibility in the=20 > order in which services are applied without loss of generality. (In=20 > some contexts you can apply charging either before or after=20 > optimization, for > example.) Whether we should allow that is up to the WG. > > Yours, > Joel > > On 8/11/14, 2:51 PM, Lucy yong wrote: >> Hi Joel and Carlos, >> >> Here are some comments beside the comments others already stated. >> >> SFC definition in this version: >> >> Service Function Chain (SFC): A service Function chain defines=20 >> an >> >> abstract set of service functions and their ordering constraints >> >> that must be applied to packets and/or frames selected as a >> >> result of classification. The implied order may not be a=20 >> linear >> >> progression as the architecture allows for nodes that copy=20 >> to >> >> more than one branch, and also allows for cases where there=20 >> is >> >> flexibility in the order in which services need to be applied. >> >> The term service chain is often used as shorthand for=20 >> service >> >> function chain. >> >> In previous version: >> >> Service Function Chain (SFC): A service Function chain defines an >> >> ordered set of service functions that must be applied=20 >> topackets >> >> and/or frames selected as a result of classification. The >> >> implied order may not be a linear progression as the >> >> architecture allows for nodes that copy to more than one branc= h. >> >> The term service chain is often used as shorthand for=20 >> service >> >> function chain. >> >> Comment: I am not sure why it has been changed and what use case=20 >> drives the order flexibility. Don't see the rest of architecture=20 >> change to allow/describe this. When such flexibility applies, does it=20 >> mean that SFC is just a set of SFs? Could you explain? >> > ... > From nobody Mon Aug 11 14:38: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 070391A0174 for ; Mon, 11 Aug 2014 14:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 M84yLqdZJOiM for ; Mon, 11 Aug 2014 14:38:07 -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 2AE301A0101 for ; Mon, 11 Aug 2014 14:38:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLC99565; Mon, 11 Aug 2014 21:38:04 +0000 (GMT) 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; Mon, 11 Aug 2014 22:38:03 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml703-chm.china.huawei.com ([169.254.5.198]) with mapi id 14.03.0158.001; Mon, 11 Aug 2014 14:37:53 -0700 From: Lucy yong To: Lucy yong , "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] commment on draft merged-sfc-architecture-01 Thread-Index: Ac+1lV2bUWy7j9OcSg+1LcHuFbPT6wAPNACAAAxhjkD//7UuAIAAc48ggADYq+A= Date: Mon, 11 Aug 2014 21:37:52 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453CC269@dfweml701-chm.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D453CC138@dfweml701-chm.china.huawei.com> <53E91475.50404@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D453CC1E7@dfweml701-chm.china.huawei.com> <53E928C8.7060800@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D453CC23D@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453CC23D@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.142.44] 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/Er7TZSVmqLyHlXR87gns972Kd5Y Subject: Re: [sfc] commment on draft merged-sfc-architecture-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, 11 Aug 2014 21:38:12 -0000 Further clarify my suggestion below. I mean that the set of SFs selected fo= r an order flexible SFC should be ordered in data plane. Lucy -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong Sent: Monday, August 11, 2014 4:01 PM To: Joel M. Halpern; sfc@ietf.org Subject: Re: [sfc] commment on draft merged-sfc-architecture-01 Joel, Your last sentence is interesting. The merged arch did define SFC in sectio= n 1.3 and further describe it in section 2. Maybe we at least make the architecture clear if a SFP in a SFC can be a se= t of SFs w/ order flexible or not if the SFC is order flexible. IMO: it sho= uld not. Thus, it is pure control plane implementation. =20 Thanks, Lucy=20 =20 -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Monday, August 11, 2014 3:34 PM To: Lucy yong; sfc@ietf.org Subject: Re: [sfc] commment on draft merged-sfc-architecture-01 An SFC can include order constraints. That is clearly necessary. As currently described, an SFC would consist of a list of abstract service = functions, with ordering constraints where desired. Exactly how flexible t= hat is is left largely up to the control systems, as the definition of SFC = and the representations for it are not really our space. Yours, Joel On 8/11/14, 4:26 PM, Lucy yong wrote: > Joel, > > I missed such discussion on the list for sure. If this is allowed, how do= es the architecture reflect to it? Should we say that an SFC could be a set= of SFs that traffic MUST pass through, but the sequence of SFs traffic tra= verse does not matter. This let a SFF to select any rest of SFs (traffic no= t passes over yet) in a SFC? Should the arch add that too? > > I do not see the charter text stating this as SFC but agree some use case= that the order may not matter to the customer, or say traffic. > > Thanks, > Lucy > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Monday, August 11, 2014 2:08 PM > To: Lucy yong; sfc@ietf.org > Subject: Re: [sfc] commment on draft merged-sfc-architecture-01 > > Lucy, > The reason we added ordering flexibility in the SFC definition=20 > is that we understood that to be part of what folks were requesting on=20 > the mailing list. I don't much care one way or the other. It is=20 > undeniable that there are many cases where there is flexibility in the=20 > order in which services are applied without loss of generality. (In=20 > some contexts you can apply charging either before or after=20 > optimization, for > example.) Whether we should allow that is up to the WG. > > Yours, > Joel > > On 8/11/14, 2:51 PM, Lucy yong wrote: >> Hi Joel and Carlos, >> >> Here are some comments beside the comments others already stated. >> >> SFC definition in this version: >> >> Service Function Chain (SFC): A service Function chain defines=20 >> an >> >> abstract set of service functions and their ordering constraints >> >> that must be applied to packets and/or frames selected as a >> >> result of classification. The implied order may not be a=20 >> linear >> >> progression as the architecture allows for nodes that copy=20 >> to >> >> more than one branch, and also allows for cases where there=20 >> is >> >> flexibility in the order in which services need to be applied. >> >> The term service chain is often used as shorthand for=20 >> service >> >> function chain. >> >> In previous version: >> >> Service Function Chain (SFC): A service Function chain defines an >> >> ordered set of service functions that must be applied=20 >> topackets >> >> and/or frames selected as a result of classification. The >> >> implied order may not be a linear progression as the >> >> architecture allows for nodes that copy to more than one branc= h. >> >> The term service chain is often used as shorthand for=20 >> service >> >> function chain. >> >> Comment: I am not sure why it has been changed and what use case=20 >> drives the order flexibility. Don't see the rest of architecture=20 >> change to allow/describe this. When such flexibility applies, does it=20 >> mean that SFC is just a set of SFs? Could you explain? >> > ... > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Aug 11 17:41: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 4674D1A0021 for ; Mon, 11 Aug 2014 17:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.269 X-Spam-Level: X-Spam-Status: No, score=-4.269 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 kOOtF4L46Mh3 for ; Mon, 11 Aug 2014 17:40:57 -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 87D671A000E for ; Mon, 11 Aug 2014 17:40:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BID42325; Tue, 12 Aug 2014 00:40:54 +0000 (GMT) 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; Tue, 12 Aug 2014 01:40:54 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.204]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 12 Aug 2014 08:40:49 +0800 From: Xuxiaohu To: Ron Parker , Alla Goldner , "Joel M. Halpern" , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.txt Thread-Index: AQHPr2AigUDp9PUKd0KN/JsZgTmzp5vLI0nw///Rx4CAAAuOgIAAAJEAgAAKDYCAADQ9gIAA7ZmA Date: Tue, 12 Aug 2014 00:40:48 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A67B7@NKGEML512-MBS.china.huawei.com> References: <20140803211558.28482.8328.idtracker@ietfa.amsl.com> <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> <53E8CD15.7010002@joelhalpern.com> <53E8D740.6090501@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.111.98.134] 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/CwuRNr4f-Twtkb1N5pevVGtJ_iU Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.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, 12 Aug 2014 00:41:00 -0000 +1 Xiaohu > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker > Sent: Tuesday, August 12, 2014 2:29 AM > To: Alla Goldner; Joel M. Halpern; Carlos Pignataro (cpignata); sfc@ietf.= org > Subject: Re: [sfc] Fwd: New Version Notification for > draft-merged-sfc-architecture-01.txt >=20 > Alla, >=20 > I'm trying to clarify, in my mind, the distinction of network encapsulati= on and > network transport. For reasons that Joel states, I feel the transport > encapsulation and de-encapsulation must happen at the SFF (i.e., the SFF > terminates the transport tunnels). The networking path followed by thos= e > transport tunnels is based on the network switching/routing behavior and = need > not be visible to the SFF. In an SDN overlay type of network, the SFF = would > be the Virtual Tunnel Endpoint (VTEP) in this way of thinking. >=20 > Ron >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Alla Goldner > Sent: Monday, August 11, 2014 11:22 AM > To: Joel M. Halpern; Carlos Pignataro (cpignata); sfc@ietf.org > Subject: Re: [sfc] Fwd: New Version Notification for > draft-merged-sfc-architecture-01.txt >=20 > Dear Joel, all, >=20 > SFF and transport network connectivity point need to be co-located (this = is not > mandatory but makes sense). > This means that a simple L2 connectivity between SFF and the network > connectivity point can be used as this interface. > That can be some VLAN or VXLAN or any other L2 protocol. This shouldn't > impose a big overhead on the SFF. >=20 > Also, the same interface you are talking about should exist also between = SFF and > SF proxy. > So if we already need to solve it there, we can use it between SFF and ne= twork > component. >=20 > I strongly believe we should decouple network transport functions from th= e SFF > and thus correct the section 4.3. >=20 > Best regards, >=20 > Alla Goldner > Director of Mobile Technologies and Standards Allot Communications Tel +9= 72 9 > 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com > www.allot.com >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Monday, August 11, 2014 5:46 PM > To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org > Subject: Re: [sfc] Fwd: New Version Notification for > draft-merged-sfc-architecture-01.txt >=20 > That is how we had drawn the figure before. And described the functions. > The problem is that this creates an interface between a network component= and > the SFF which can not exist visibly. There is no way I know of to ship t= he > packets between those two. >=20 > So the Encaps / decaps has to be co-located with the SFF. > This archtiecture tries not to get into the internal structure of the log= ical > components or to describe separately components that must be co-located. > Some architectures do describe that. >=20 > Yours, > Joel >=20 > On 8/11/14, 10:44 AM, Alla Goldner wrote: > > Dear Joel, all, > > > > One of the motivations of SFC is be agnostic to the underlay transport > network. > > When you couple the SFF with the encapsulation/de-capsulation process i= t has > to be aware of the network transport and it has to be capable to support > different types of transport protocols. > > For me it doesn't make too much sense and it makes the SFF very complex= . > > I think that a cleaner architecture is to have the SFF handle the SFC t= asks and > handle the SFC encapsulations (that is the metadata and SFC headers) but = leave > the transport to be handled by the network layer which can be any type of > network. > > > > Best regards, > > > > > > Alla Goldner > > Director of Mobile Technologies and Standards Allot Communications Tel > > +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 > > agoldner@allot.com www.allot.com > > > > > > > > > > > > -----Original Message----- > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > > Sent: Monday, August 11, 2014 5:03 PM > > To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org > > Subject: Re: [sfc] Fwd: New Version Notification for > > draft-merged-sfc-architecture-01.txt > > > > I would say instead that we need to fix section 4.5, to make it clear t= hat the SFF > is responsible for the encaps decaps, while the network uses the outer > encapsulation for its forwarding. > > > > Yours, > > Joel > > > > On 8/11/14, 4:56 AM, Alla Goldner wrote: > >> Dear Carlos, Joel, all, > >> > >> Thanks for providing this merged architecture document! > >> > >> According to the model in figure 3 and section 4.5, the network > >> (underlay) components are responsible for: > >> > >> * Finding the network path to reach the next SF (next SFF) in > >> the SFP. > >> > >> * Encapsulate/de-capsulate the underlay network transport. > >> > >> Section 4.3 (SFF) contradicts this and says the network > >> encapsulation/de-capsulation is done by the SFF. > >> > >> I believe that the section 4.3 should be fixed in this regard. The > >> reason is that network transport functions should not necessarily be > >> coupled with the SFF. > >> > >> Best regards, > >> > >> *Alla Goldner* > >> > >> *Director of Mobile Technologies and Standards* > >> > >> Allot Communications > >> > >> Tel +972 9 7619251 > >> > >> Cell +972 54 2493985 > >> > >> Fax +972 9 7443626 > >> > >> *agoldner@allot.com **__* > >> > >> *www.allot.com* *__* > >> > >> *__* > >> > >> *291X55_signature (2)* > >> > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Carlos > >> Pignataro > >> (cpignata) > >> *Sent:* Monday, August 04, 2014 12:19 AM > >> *To:* sfc@ietf.org > >> *Subject:* [sfc] Fwd: New Version Notification for > >> draft-merged-sfc-architecture-01.txt > >> > >> SFCers, > >> > >> After Toronto, Joel and I have been working on resolving the key open > >> discussion items, and incorporating all the input and feedback > >> received thus into this document as the vehicle for a single SFC > >> Architecture item to progress. > >> > >> While we are still working on the document, we wanted to get a > >> version out early to the WG to test the resolution to key open items, > >> see what we might still be missing, and iterate. > >> > >> Please review and let us know. > >> > >> Thanks, > >> > >> Carlos & Joel. > >> > >> Begin forwarded message: > >> > >> > >> > >> *From: *> > >> > >> *Subject: New Version Notification for > >> draft-merged-sfc-architecture-01.txt* > >> > >> *Date: *August 3, 2014 at 5:15:58 PM EDT > >> > >> *To: *Joel Halpern >> >, Carlos Pignataro >> >, "Joel M. Halpern" >> >, Carlos Pignataro >> > > >> > >> > >> A new version of I-D, draft-merged-sfc-architecture-01.txt > >> has been successfully submitted by Carlos Pignataro and posted to the > >> IETF repository. > >> > >> Name:draft-merged-sfc-architecture > >> Revision:01 > >> Title:Service Function Chaining (SFC) Architecture Document > >> date:2014-08-03 Group:Individual Submission > >> Pages:25 > >> URL: > >> http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-01. > >> t > >> xt > >> Status: > >> https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ > >> Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-01 > >> Diff: > >> http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-01 > >> > >> 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.ietf.org . > >> > >> The IETF Secretariat > >> > >> --------------------------------------------------------------------- > >> - > >> -- This message is intended only for the designated recipient(s). It > >> may contain confidential or proprietary information. If you are not > >> the designated recipient, you may not review, copy or distribute this > >> message. If you have mistakenly received this message, please notify > >> the sender by a reply e-mail and delete this message. Thank you. > >> > >> --------------------------------------------------------------------- > >> - > >> -- > >> > >> > >> > >> _______________________________________________ > >> sfc mailing list > >> sfc@ietf.org > >> https://www.ietf.org/mailman/listinfo/sfc > >> > > > ############################################################# > ######### > > ######################## This message is intended only for the > > designated recipient(s).It may contain confidential or proprietary info= rmation. > > If you are not the designated recipient, you may not review, copy or di= stribute > this message. > > If you have mistakenly received this message, please notify the sender = by a > reply e-mail and delete this message. > > Thank you. > > > ############################################################# > ######### > > ######################## > > > ############################################################# > ################################# > This message is intended only for the designated recipient(s).It may cont= ain > confidential or proprietary information. > If you are not the designated recipient, you may not review, copy or dist= ribute > this message. > If you have mistakenly received this message, please notify the sender by= a reply > e-mail and delete this message. > Thank you. > ############################################################# > ################################# >=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 From nobody Mon Aug 11 18:31:00 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 06D871A0047 for ; Mon, 11 Aug 2014 18:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.269 X-Spam-Level: X-Spam-Status: No, score=-4.269 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 Fte0cHQBPZQu for ; Mon, 11 Aug 2014 18:30: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 3DFE71A0045 for ; Mon, 11 Aug 2014 18:30:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLD09750; Tue, 12 Aug 2014 01:30:48 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Aug 2014 02:30:47 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.204]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Tue, 12 Aug 2014 09:30:43 +0800 From: Xuxiaohu To: "Joel M. Halpern" , Alla Goldner , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.txt Thread-Index: AQHPr2AigUDp9PUKd0KN/JsZgTmzp5vLI0nw///Rx4CAAAuOgIAAAJEAgAAKDYCAAADEgIABKf3w Date: Tue, 12 Aug 2014 01:30:43 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A6840@NKGEML512-MBS.china.huawei.com> References: <20140803211558.28482.8328.idtracker@ietfa.amsl.com> <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> <53E8CD15.7010002@joelhalpern.com> <53E8D740.6090501@joelhalpern.com> <53E8E053.8050608@joelhalpern.com> In-Reply-To: <53E8E053.8050608@joelhalpern.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/2zvq7sxopz-xt899HXDuqI_x9zk Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.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, 12 Aug 2014 01:30:55 -0000 Hi Joel, > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Monday, August 11, 2014 11:25 PM > To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org > Subject: Re: [sfc] Fwd: New Version Notification for > draft-merged-sfc-architecture-01.txt >=20 > Part of my problem is that the SFF has the information about what the nex= t SFF. > (Even if the SFP allows only one next-SFF, it is the current SFF who know= s what > that is. And if the decision is delegated, it is delegated to the SFF. )= But if the > Encaps is not part of the SFF, then the SFF has no way to express that de= cision. > Even an Ethernet link does not handle it. >=20 > I need to check the text on SF Proxy, but I usually think of that as a > more-specialized SFF, not as something separate from the SFF. Fully agree with the above points. That's the reason why I had suggested gi= ving the entity containing the SFF or even the SF proxy components a name (= see http://www.ietf.org/mail-archive/web/sfc/current/msg02150.html) Best regards, Xiaohu > Yours, > Joel >=20 > On 8/11/14, 11:22 AM, Alla Goldner wrote: > > Dear Joel, all, > > > > SFF and transport network connectivity point need to be co-located (thi= s is not > mandatory but makes sense). > > This means that a simple L2 connectivity between SFF and the network > connectivity point can be used as this interface. > > That can be some VLAN or VXLAN or any other L2 protocol. This shouldn't > impose a big overhead on the SFF. > > > > Also, the same interface you are talking about should exist also betwee= n SFF > and SF proxy. > > So if we already need to solve it there, we can use it between SFF and = network > component. > > > > I strongly believe we should decouple network transport functions from = the > SFF and thus correct the section 4.3. > > > > Best regards, > > > > Alla Goldner > > Director of Mobile Technologies and Standards Allot Communications Tel > > +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 > > agoldner@allot.com www.allot.com > > > > > > > > > > > > -----Original Message----- > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > > Sent: Monday, August 11, 2014 5:46 PM > > To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org > > Subject: Re: [sfc] Fwd: New Version Notification for > > draft-merged-sfc-architecture-01.txt > > > > That is how we had drawn the figure before. And described the function= s. > > The problem is that this creates an interface between a network compone= nt > and the SFF which can not exist visibly. There is no way I know of to sh= ip the > packets between those two. > > > > So the Encaps / decaps has to be co-located with the SFF. > > This archtiecture tries not to get into the internal structure of the l= ogical > components or to describe separately components that must be co-located. > Some architectures do describe that. > > > > Yours, > > Joel > > > > On 8/11/14, 10:44 AM, Alla Goldner wrote: > >> Dear Joel, all, > >> > >> One of the motivations of SFC is be agnostic to the underlay transport > network. > >> When you couple the SFF with the encapsulation/de-capsulation process = it > has to be aware of the network transport and it has to be capable to supp= ort > different types of transport protocols. > >> For me it doesn't make too much sense and it makes the SFF very comple= x. > >> I think that a cleaner architecture is to have the SFF handle the SFC = tasks and > handle the SFC encapsulations (that is the metadata and SFC headers) but = leave > the transport to be handled by the network layer which can be any type of > network. > >> > >> Best regards, > >> > >> > >> Alla Goldner > >> Director of Mobile Technologies and Standards Allot Communications > >> Tel > >> +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 > >> agoldner@allot.com www.allot.com > >> > >> > >> > >> > >> > >> -----Original Message----- > >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >> Sent: Monday, August 11, 2014 5:03 PM > >> To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org > >> Subject: Re: [sfc] Fwd: New Version Notification for > >> draft-merged-sfc-architecture-01.txt > >> > >> I would say instead that we need to fix section 4.5, to make it clear = that the > SFF is responsible for the encaps decaps, while the network uses the out= er > encapsulation for its forwarding. > >> > >> Yours, > >> Joel > >> > >> On 8/11/14, 4:56 AM, Alla Goldner wrote: > >>> Dear Carlos, Joel, all, > >>> > >>> Thanks for providing this merged architecture document! > >>> > >>> According to the model in figure 3 and section 4.5, the network > >>> (underlay) components are responsible for: > >>> > >>> * Finding the network path to reach the next SF (next SFF) in > >>> the SFP. > >>> > >>> * Encapsulate/de-capsulate the underlay network transport. > >>> > >>> Section 4.3 (SFF) contradicts this and says the network > >>> encapsulation/de-capsulation is done by the SFF. > >>> > >>> I believe that the section 4.3 should be fixed in this regard. The > >>> reason is that network transport functions should not necessarily be > >>> coupled with the SFF. > >>> > >>> Best regards, > >>> > >>> *Alla Goldner* > >>> > >>> *Director of Mobile Technologies and Standards* > >>> > >>> Allot Communications > >>> > >>> Tel +972 9 7619251 > >>> > >>> Cell +972 54 2493985 > >>> > >>> Fax +972 9 7443626 > >>> > >>> *agoldner@allot.com **__* > >>> > >>> *www.allot.com* *__* > >>> > >>> *__* > >>> > >>> *291X55_signature (2)* > >>> > >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Carlos > >>> Pignataro > >>> (cpignata) > >>> *Sent:* Monday, August 04, 2014 12:19 AM > >>> *To:* sfc@ietf.org > >>> *Subject:* [sfc] Fwd: New Version Notification for > >>> draft-merged-sfc-architecture-01.txt > >>> > >>> SFCers, > >>> > >>> After Toronto, Joel and I have been working on resolving the key > >>> open discussion items, and incorporating all the input and feedback > >>> received thus into this document as the vehicle for a single SFC > >>> Architecture item to progress. > >>> > >>> While we are still working on the document, we wanted to get a > >>> version out early to the WG to test the resolution to key open > >>> items, see what we might still be missing, and iterate. > >>> > >>> Please review and let us know. > >>> > >>> Thanks, > >>> > >>> Carlos & Joel. > >>> > >>> Begin forwarded message: > >>> > >>> > >>> > >>> *From: *> > >>> > >>> *Subject: New Version Notification for > >>> draft-merged-sfc-architecture-01.txt* > >>> > >>> *Date: *August 3, 2014 at 5:15:58 PM EDT > >>> > >>> *To: *Joel Halpern >>> >, Carlos Pignataro >>> >, "Joel M. Halpern" >>> >, Carlos Pignataro >>> > > >>> > >>> > >>> A new version of I-D, draft-merged-sfc-architecture-01.txt > >>> has been successfully submitted by Carlos Pignataro and posted to > >>> the IETF repository. > >>> > >>> Name:draft-merged-sfc-architecture > >>> Revision:01 > >>> Title:Service Function Chaining (SFC) Architecture Document > >>> date:2014-08-03 Group:Individual Submission > >>> Pages:25 > >>> URL: > >>> http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-01. > >>> t > >>> xt > >>> Status: > >>> https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ > >>> Htmlized: > >>> http://tools.ietf.org/html/draft-merged-sfc-architecture-01 > >>> Diff: > >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-01 > >>> > >>> Abstract: > >>> This document describes an architecture for the specification, > >>> creation, and ongoing maintenance of Service Function Chains (SF= C) > in > >>> a network. It includes architectural concepts, principles, and > >>> components used in the construction of composite services throug= h > >>> 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.ietf.org . > >>> > >>> The IETF Secretariat > >>> > >>> -------------------------------------------------------------------- > >>> - > >>> - > >>> -- This message is intended only for the designated recipient(s). It > >>> may contain confidential or proprietary information. If you are not > >>> the designated recipient, you may not review, copy or distribute > >>> this message. If you have mistakenly received this message, please > >>> notify the sender by a reply e-mail and delete this message. Thank yo= u. > >>> > >>> -------------------------------------------------------------------- > >>> - > >>> - > >>> -- > >>> > >>> > >>> > >>> _______________________________________________ > >>> sfc mailing list > >>> sfc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sfc > >>> > >> > ############################################################# > ######## > >> # ######################## This message is intended only for the > >> designated recipient(s).It may contain confidential or proprietary > information. > >> If you are not the designated recipient, you may not review, copy or > distribute this message. > >> If you have mistakenly received this message, please notify the sender= by a > reply e-mail and delete this message. > >> Thank you. > >> > ############################################################# > ######## > >> # > >> ######################## > >> > > > ############################################################# > ######### > > ######################## This message is intended only for the > > designated recipient(s).It may contain confidential or proprietary info= rmation. > > If you are not the designated recipient, you may not review, copy or di= stribute > this message. > > If you have mistakenly received this message, please notify the sender = by a > reply e-mail and delete this message. > > Thank you. > > > ############################################################# > ######### > > ######################## > > >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Aug 11 19:39:23 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 CD5581A015F for ; Mon, 11 Aug 2014 19:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_57=0.6, 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 jkXLFsGEaddC for ; Mon, 11 Aug 2014 19:39:21 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 678EB1A0154 for ; Mon, 11 Aug 2014 19:39:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 37BA5127E11; Mon, 11 Aug 2014 19:39:21 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id B1024127E0B; Mon, 11 Aug 2014 19:39:19 -0700 (PDT) Message-ID: <53E97E56.7070508@joelhalpern.com> Date: Mon, 11 Aug 2014 22:39:18 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Xuxiaohu , Alla Goldner , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" References: <20140803211558.28482.8328.idtracker@ietfa.amsl.com> <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> <53E8CD15.7010002@joelhalpern.com> <53E8D740.6090501@joelhalpern.com> <53E8E053.8050608@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A6840@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A6840@NKGEML512-MBS.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/hQHeRoYOJl-NG4WmhfiZOBU5SC0 Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.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, 12 Aug 2014 02:39:22 -0000 If the encapsulation / decapsulation is part of the job of the SFF, then there is no need to discuss or name the node that happens to contain the SFF. Avoiding an extra term keeps things simpler. Yours, Joel On 8/11/14, 9:30 PM, Xuxiaohu wrote: > Hi Joel, > >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Monday, August 11, 2014 11:25 PM >> To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org >> Subject: Re: [sfc] Fwd: New Version Notification for >> draft-merged-sfc-architecture-01.txt >> >> Part of my problem is that the SFF has the information about what the next SFF. >> (Even if the SFP allows only one next-SFF, it is the current SFF who knows what >> that is. And if the decision is delegated, it is delegated to the SFF. ) But if the >> Encaps is not part of the SFF, then the SFF has no way to express that decision. >> Even an Ethernet link does not handle it. >> >> I need to check the text on SF Proxy, but I usually think of that as a >> more-specialized SFF, not as something separate from the SFF. > > Fully agree with the above points. That's the reason why I had suggested giving the entity containing the SFF or even the SF proxy components a name (see http://www.ietf.org/mail-archive/web/sfc/current/msg02150.html) > > Best regards, > Xiaohu > >> Yours, >> Joel >> >> On 8/11/14, 11:22 AM, Alla Goldner wrote: >>> Dear Joel, all, >>> >>> SFF and transport network connectivity point need to be co-located (this is not >> mandatory but makes sense). >>> This means that a simple L2 connectivity between SFF and the network >> connectivity point can be used as this interface. >>> That can be some VLAN or VXLAN or any other L2 protocol. This shouldn't >> impose a big overhead on the SFF. >>> >>> Also, the same interface you are talking about should exist also between SFF >> and SF proxy. >>> So if we already need to solve it there, we can use it between SFF and network >> component. >>> >>> I strongly believe we should decouple network transport functions from the >> SFF and thus correct the section 4.3. >>> >>> Best regards, >>> >>> Alla Goldner >>> Director of Mobile Technologies and Standards Allot Communications Tel >>> +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 >>> agoldner@allot.com www.allot.com >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Sent: Monday, August 11, 2014 5:46 PM >>> To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org >>> Subject: Re: [sfc] Fwd: New Version Notification for >>> draft-merged-sfc-architecture-01.txt >>> >>> That is how we had drawn the figure before. And described the functions. >>> The problem is that this creates an interface between a network component >> and the SFF which can not exist visibly. There is no way I know of to ship the >> packets between those two. >>> >>> So the Encaps / decaps has to be co-located with the SFF. >>> This archtiecture tries not to get into the internal structure of the logical >> components or to describe separately components that must be co-located. >> Some architectures do describe that. >>> >>> Yours, >>> Joel >>> >>> On 8/11/14, 10:44 AM, Alla Goldner wrote: >>>> Dear Joel, all, >>>> >>>> One of the motivations of SFC is be agnostic to the underlay transport >> network. >>>> When you couple the SFF with the encapsulation/de-capsulation process it >> has to be aware of the network transport and it has to be capable to support >> different types of transport protocols. >>>> For me it doesn't make too much sense and it makes the SFF very complex. >>>> I think that a cleaner architecture is to have the SFF handle the SFC tasks and >> handle the SFC encapsulations (that is the metadata and SFC headers) but leave >> the transport to be handled by the network layer which can be any type of >> network. >>>> >>>> Best regards, >>>> >>>> >>>> Alla Goldner >>>> Director of Mobile Technologies and Standards Allot Communications >>>> Tel >>>> +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 >>>> agoldner@allot.com www.allot.com >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>> Sent: Monday, August 11, 2014 5:03 PM >>>> To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org >>>> Subject: Re: [sfc] Fwd: New Version Notification for >>>> draft-merged-sfc-architecture-01.txt >>>> >>>> I would say instead that we need to fix section 4.5, to make it clear that the >> SFF is responsible for the encaps decaps, while the network uses the outer >> encapsulation for its forwarding. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 8/11/14, 4:56 AM, Alla Goldner wrote: >>>>> Dear Carlos, Joel, all, >>>>> >>>>> Thanks for providing this merged architecture document! >>>>> >>>>> According to the model in figure 3 and section 4.5, the network >>>>> (underlay) components are responsible for: >>>>> >>>>> * Finding the network path to reach the next SF (next SFF) in >>>>> the SFP. >>>>> >>>>> * Encapsulate/de-capsulate the underlay network transport. >>>>> >>>>> Section 4.3 (SFF) contradicts this and says the network >>>>> encapsulation/de-capsulation is done by the SFF. >>>>> >>>>> I believe that the section 4.3 should be fixed in this regard. The >>>>> reason is that network transport functions should not necessarily be >>>>> coupled with the SFF. >>>>> >>>>> Best regards, >>>>> >>>>> *Alla Goldner* >>>>> >>>>> *Director of Mobile Technologies and Standards* >>>>> >>>>> Allot Communications >>>>> >>>>> Tel +972 9 7619251 >>>>> >>>>> Cell +972 54 2493985 >>>>> >>>>> Fax +972 9 7443626 >>>>> >>>>> *agoldner@allot.com **__* >>>>> >>>>> *www.allot.com* *__* >>>>> >>>>> *__* >>>>> >>>>> *291X55_signature (2)* >>>>> >>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Carlos >>>>> Pignataro >>>>> (cpignata) >>>>> *Sent:* Monday, August 04, 2014 12:19 AM >>>>> *To:* sfc@ietf.org >>>>> *Subject:* [sfc] Fwd: New Version Notification for >>>>> draft-merged-sfc-architecture-01.txt >>>>> >>>>> SFCers, >>>>> >>>>> After Toronto, Joel and I have been working on resolving the key >>>>> open discussion items, and incorporating all the input and feedback >>>>> received thus into this document as the vehicle for a single SFC >>>>> Architecture item to progress. >>>>> >>>>> While we are still working on the document, we wanted to get a >>>>> version out early to the WG to test the resolution to key open >>>>> items, see what we might still be missing, and iterate. >>>>> >>>>> Please review and let us know. >>>>> >>>>> Thanks, >>>>> >>>>> Carlos & Joel. >>>>> >>>>> Begin forwarded message: >>>>> >>>>> >>>>> >>>>> *From: *> >>>>> >>>>> *Subject: New Version Notification for >>>>> draft-merged-sfc-architecture-01.txt* >>>>> >>>>> *Date: *August 3, 2014 at 5:15:58 PM EDT >>>>> >>>>> *To: *Joel Halpern >>>> >, Carlos Pignataro >>>> >, "Joel M. Halpern" >>>> >, Carlos Pignataro >>>> > >>>>> >>>>> >>>>> A new version of I-D, draft-merged-sfc-architecture-01.txt >>>>> has been successfully submitted by Carlos Pignataro and posted to >>>>> the IETF repository. >>>>> >>>>> Name:draft-merged-sfc-architecture >>>>> Revision:01 >>>>> Title:Service Function Chaining (SFC) Architecture Document >>>>> date:2014-08-03 Group:Individual Submission >>>>> Pages:25 >>>>> URL: >>>>> http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-01. >>>>> t >>>>> xt >>>>> Status: >>>>> https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ >>>>> Htmlized: >>>>> http://tools.ietf.org/html/draft-merged-sfc-architecture-01 >>>>> Diff: >>>>> http://www.ietf.org/rfcdiff?url2=draft-merged-sfc-architecture-01 >>>>> >>>>> 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.ietf.org . >>>>> >>>>> The IETF Secretariat >>>>> >>>>> -------------------------------------------------------------------- >>>>> - >>>>> - >>>>> -- This message is intended only for the designated recipient(s). It >>>>> may contain confidential or proprietary information. If you are not >>>>> the designated recipient, you may not review, copy or distribute >>>>> this message. If you have mistakenly received this message, please >>>>> notify the sender by a reply e-mail and delete this message. Thank you. >>>>> >>>>> -------------------------------------------------------------------- >>>>> - >>>>> - >>>>> -- >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>> >> ############################################################# >> ######## >>>> # ######################## This message is intended only for the >>>> designated recipient(s).It may contain confidential or proprietary >> information. >>>> If you are not the designated recipient, you may not review, copy or >> distribute this message. >>>> If you have mistakenly received this message, please notify the sender by a >> reply e-mail and delete this message. >>>> Thank you. >>>> >> ############################################################# >> ######## >>>> # >>>> ######################## >>>> >>> >> ############################################################# >> ######### >>> ######################## This message is intended only for the >>> designated recipient(s).It may contain confidential or proprietary information. >>> If you are not the designated recipient, you may not review, copy or distribute >> this message. >>> If you have mistakenly received this message, please notify the sender by a >> reply e-mail and delete this message. >>> Thank you. >>> >> ############################################################# >> ######### >>> ######################## >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Aug 12 01:26: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 1CF851A078B for ; Tue, 12 Aug 2014 01:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 FazDl6N-i4Wa for ; Tue, 12 Aug 2014 01:26: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 910C41A0359 for ; Tue, 12 Aug 2014 01:26:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLD41819; Tue, 12 Aug 2014 08:26:37 +0000 (GMT) Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Aug 2014 09:26:36 +0100 Received: from SZXEMA509-MBX.china.huawei.com ([169.254.1.59]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Tue, 12 Aug 2014 16:26:24 +0800 From: "Hongyu Li (Julio)" To: "Carlos Pignataro (cpignata)" , "Dolganow, Andrew (Andrew)" Thread-Topic: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt Thread-Index: AQHPsj5aLLMeiGPAKE+4WkNpLSA+FJvElhWAgADLN4CAAMN6gIAAJg6AgAZUK1A= Date: Tue, 12 Aug 2014 08:26:23 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97EA55327@SZXEMA509-MBX.china.huawei.com> References: , <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A4805@NKGEML512-MBS.china.huawei.com> <57B2ECF6-8DB4-4E23-BB14-E030EB74E09C@alcatel-lucent.com> 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.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/c28Os9ROpscg7qxbpZb2hUmsfAA Cc: Xuxiaohu , "Joel M. Halpern" , "Andrew G. Malis" , "sfc@ietf.org" Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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, 12 Aug 2014 08:26:41 -0000 SGkgQ2FybG9zIGFuZCBhbGwsDQoNClNpbmNlIHRoZSBkZXNpZ24gZ29hbCBpcyB0byBhbGxvdyBT RkMgYmVpbmcgYW4gb3ZlcmxheSBvZiBhbnkgbmV0d29yaywgaXQgbWFrZSBzZW5zZSB0byBoYXZl IGEgZ2VuZXJpYyBkYXRhIHBsYW5lIGVuY2Fwc3VsYXRpb24gZW5jb2RlcyB0aGUgU0ZQLiBNZWFu d2hpbGUsIGNvbW11bmljYXRpb24gYmV0d2VlbiBTRnMsIHdoZXJlIG1ldGFkYXRhIGlzIHVzZWQs IG1heSBiZSByZXF1aXJlZCBpbiBjZXJ0YWluIHNjZW5hcmlvcyBidXQgbm90IGFsbCBjYXNlcywg c28sIG1ldGFkYXRhIHNob3VsZCBiZSBvcHRpb25hbGx5IGVuY2Fwc3VsYXRlZC4NCg0KQ2hlZXJz LA0KSG9uZ3l1DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzZmMgW21haWx0 bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENhcmxvcyBQaWduYXRhcm8gKGNw aWduYXRhKQ0KU2VudDogRnJpZGF5LCBBdWd1c3QgMDgsIDIwMTQgMTE6MDkgUE0NClRvOiBEb2xn YW5vdywgQW5kcmV3IChBbmRyZXcpDQpDYzogWHV4aWFvaHU7IEpvZWwgTS4gSGFscGVybjsgQW5k cmV3IEcuIE1hbGlzOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBEZWZpbml0aW9u IG9mIFNGQyBFbmNhcHN1bGF0aW9uIGluIGRyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAx LnR4dA0KDQpIaSwgQW5kcmV3LA0KDQpPbiBBdWcgOCwgMjAxNCwgYXQgODo1MyBBTSwgRG9sZ2Fu b3csIEFuZHJldyAoQW5kcmV3KSA8YW5kcmV3LmRvbGdhbm93QGFsY2F0ZWwtbHVjZW50LmNvbT4g d3JvdGU6DQoNCj4gSSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBoYXZlIHN0cm9uZ2VyIHNlcGFyYXRp b24gb2YgdHdvIGZ1bmN0aW9uczogU0ZQIGFuZCBtZXRhZGF0YS4gDQo+IA0KPiBIb3cgYWJvdXQg c21hbGwgZWRpdCB0byB3aGF0IEFuZHkgcHJvcG9zZWQ6DQo+IA0KPiBTRkMgRW5jYXBzdWxhdGlv bjogIEEgZGF0YSBwbGFuZSBlbmNhcHN1bGF0aW9uIHRoYXQgZW5jb2RlcyBlaXRoZXIgb25lIG9y IGJvdGggb2YNCj4gLSB0aGUgU0ZQIA0KPiAtIG1ldGFkYXRhIChkYXRhIHBsYW5lIGNvbnRleHQg aW5mb3JtYXRpb24pLiANCg0KTG9va2luZyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv d2cvc2ZjL2NoYXJ0ZXIvLCB0aGVyZSBpcyBubyAiZWl0aGVyIG9uZSBvciBib3RoIG9mIi4gSW4g ZmFjdCwgbG9va2luZyBhdCB0aGUgaGlzdG9yeSBvZiB0aGUgY2hhcnRlciB0ZXh0LCB0aGUgdGV4 dCBmb3IgU0ZDIEVuY2Fwc3VsYXRpb24gaXMgYSBidWxsZXQgbGlzdCBmb3JtIG9mIGEgbG9uZ2Vy IHNlbnRlbmNlIHRoYXQgaW5jbHVkZXMgImFuZCIgb25seSAoc2VlIDAwLTA5KS4NCg0KVGhhbmtz LA0KDQpDYXJsb3MuDQoNCj4+IFRoZSBTRlAgRW5jYXBzdWxhdGlvbiBpcyB1c2VkIGJ5IHRoZSBT RkMtYXdhcmUgZnVuY3Rpb25zLCBzdWNoIGFzIHRoZSBTRkYgYW5kIFNGQy1hd2FyZSBTRnMsIGFu ZCBpcyBub3QgdXNlZCBmb3IgbmV0d29yayBwYWNrZXQgZm9yd2FyZGluZy4NCj4gDQo+IA0KPiBB bmRyZXcNCj4gDQo+IFNlbnQgZnJvbSBteSBpUGhvbmUNCj4gDQo+PiBPbiBBdWcgNywgMjAxNCwg YXQgOToxMyBQTSwgIlh1eGlhb2h1IiA8eHV4aWFvaHVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+PiAN Cj4+IEkgZnVsbHkgYWdyZWUgd2l0aCBBbmR54oCZcyBwb2ludCB0aGF0IG5vdCBldmVyeSB1c2Fn ZSBvZiB0aGUgZW5jYXBzdWxhdGlvbiB3aWxsIG5lZWQgYm90aCB0aGUgU0ZQIGlkZW50aWZpY2F0 aW9uIGFuZCB0aGUgbWV0YWRhdGEuIEl04oCZcyBiZXR0ZXIgdGhhdCB0aGUgU0ZDIGVuY2Fwc3Vs YXRpb24gY291bGQgYmUgZmxleGlibHkgdXNlZCBmb3IgY2FycnlpbmcgU0ZQIGlkZW50aWZpY2F0 aW9uLCBtZXRhZGF0YSBvciBib3RoLiBPdGhlcndpc2UsIGl0IHNlZW1zIHRoYXQgdGhvc2UgU0ZD IGFwcHJvYWNoZXMgd2hpY2ggZG9u4oCZdCB1c2UgdGhlIFNGQyBlbmNhcHN1bGF0aW9uIGZvciBT RkMgc2VsZWN0aW9uIHdvdWxkIGhhdmUgdG8gc2VwYXJhdGVseSBkZWZpbmUgdGhlIHdheSBvZiBj YXJyeWluZyBtZXRhZGF0YS4NCj4+IA0KPj4gQmVzdCByZWdhcmRzLA0KPj4gWGlhb2h1IA0KPj4g DQo+PiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEFuZHJldyBHLiBNYWxpcw0KPj4gU2VudDogVGh1cnNkYXksIEF1Z3VzdCAwNywgMjAxNCA5OjA2 IFBNDQo+PiBUbzogQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpDQo+PiBDYzogSm9lbCBNLiBI YWxwZXJuOyBzZmNAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBEZWZpbml0aW9uIG9m IFNGQyBFbmNhcHN1bGF0aW9uIGluIGRyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAxLnR4 dA0KPj4gDQo+PiBDYXJsb3MsDQo+PiANCj4+IFdoZW4gSSByZS1yZWFkIHRoZSBkZWZpbml0aW9u LCBpdCBzZWVtZWQgdG8gbWUgdG8gYmUgbW9yZSBvZiBhIHN0cmluZyBvZiB0aG91Z2h0cyB0aGFu IGEgY29uY2lzZSBkZWZpbml0aW9uLCB3aGljaCBpcyB3aHkgSSB3YXMgdHJ5aW5nIHRvIHRpZ2h0 ZW4gaXQgdXAuIEEgZGVmaW5pdGlvbiBpcyBtZWFudCB0byBiZSBhIHNob3J0IHN1bW1hcnkgZm9y IHF1aWNrIHJlZmVyZW5jZSwgd2hpbGUgdGhlIGRpc2N1c3Npb24gaW4gNC4xIGdvZXMgaW50byB0 aGUgbW9yZSBmb3JtYWwgZGV0YWlscy4gIE90aGVyd2lzZSwgeW91IHdvdWxkIGp1c3QgcmVwZWF0 IHRoZSBlbnRpcmUgc2VjdGlvbiA0LjEgaW4gc2VjdGlvbiAxLjMuICBUaGlzIGlzIHdoeSBpdCBk b2Vzbid0IG5lZWQgdG8gYmUgaW4gc2VwYXJhdGUgc2VudGVuY2VzLiBUaGUgImFuZC9vciIgaXMg YmVjYXVzZSBub3QgZXZlcnkgdXNhZ2Ugb2YgdGhlIGVuY2Fwc3VsYXRpb24gd2lsbCBuZWVkIGJv dGggdGhlIFNGUCBpZGVudGlmaWNhdGlvbiBhbmQgdGhlIG1ldGFkYXRhLCBzbyB0aGUgZGVmaW5p dGlvbiBuZWVkcyB0byBjb25jaXNlbHkgY29udmV5IHRoYXQuDQo+PiANCj4+IENoZWVycywNCj4+ IEFuZHkNCj4+IA0KPj4gT24gVGh1LCBBdWcgNywgMjAxNCBhdCA4OjUxIEFNLCBDYXJsb3MgUGln bmF0YXJvIChjcGlnbmF0YSkgPGNwaWduYXRhQGNpc2NvLmNvbT4gd3JvdGU6DQo+PiBUaGFuayB5 b3UgZm9yIGdvaW5nIGJhY2sgYW5kIGNoZWNraW5nLCBBbmR5ISANCj4+IA0KPj4gV2hpY2ggc3Bl Y2lmaWMgcGFydCBvZiB0aGUgY3VycmVudCBkZWZpbml0aW9uIGRvIHlvdSBiZWxpZXZlIGlzIGxv b3NlIGVub3VnaCB0byBuZWVkIHRpZ2h0ZW5pbmc/DQo+PiANCj4+IEkgYmVsaWV2ZSB0aGF0IHlv dXIgbmV3IHByb3Bvc2FsIGZhbGxzIHNob3J0ZXIgdGhhbiB0aGUgZXhpc3RpbmcgdGV4dCBpbiBh IGZldyBhcmVhczoNCj4+IOKAoiBGaXJzdCwgaXQgY29tYmluZXMgdHdvIGRpZmZlcmVudCBmdW5j dGlvbnMgKFNGUCBpZGVudGlmaWNhdGlvbiBhbmQgbWV0YWRhdGEvY29udGV4dCBpbmZvcm1hdGlv bikgaW50byBhIHNpbmdsZSBzZW50ZW5jZS4gVGhpcyBvcHBvc2VzIHRoZSBjaGFuZ2Ugd2UganVz dCBtYWRlIGJhc2VkIG9uIHlvdXIgcHJlZmVyZW5jZSBpbiBTZWN0aW9uIDQuMSwgd2hpY2ggYnJl YWtzIHRoZSB0d28gZnVuY3Rpb25zIGludG8gdHdvIHNlbnRlbmNlcywgZm9yIHJlYWRlciBjbGFy aXR5LiBXaGlsZSBsb25nZXIsIGl0J3Mgc2ltcGxlci4NCj4+IOKAoiBTZWNvbmQsIGl0IGludHJv ZHVjZXMgYW4gZXh0cmFuZW91cyAiYW5kL29yIiB0aGF0IHdvdWxkIGNoYW5nZSB0aGUgbWVhbmlu ZywgYW5kIG5lZ2F0ZSB0aGUgImF0IGEgbWluaW11bSIgZXhpc3RpbmcgYml0LiBUaGF0IHdvdWxk IG5vdCBiZSBzaW1wbGlmeWluZy4NCj4+IOKAoiBUaGlyZCwgdGhlcmUgaXMgbm8gdGhpcmQgYnV0 IHRocmVlIGJ1bGxldHMgbG9vayBiZXR0ZXIgOi0pDQo+PiANCj4+IE5ldC1uZXQsIHRoZSBvcmln aW5hbCB0ZXh0LCBldmVuIHdoZW4gbG9uZ2VyIGluIGNoYXJhY3RlciBjb3VudCwgc2VlbXMgbW9y ZSBjbGVhciBhbmQgc2ltcGxlciB0byB0aGUgcmVhZGVyIChiZWNhdXNlIG9mIHRoZSBzZXBhcmF0 ZWQgc2VudGVuY2VzKSwgSU1ITy4NCj4+IA0KPj4gVGhhbmtzLA0KPj4gDQo+PiBDYXJsb3MuDQo+ PiANCj4+IE9uIEF1ZyA3LCAyMDE0LCBhdCA4OjIwIEFNLCBBbmRyZXcgRy4gTWFsaXMgPGFnbWFs aXNAZ21haWwuY29tPiB3cm90ZToNCj4+IA0KPj4gDQo+PiBDYXJsb3MgYW5kIEpvZWwsIA0KPj4g DQo+PiBJbiBsaWdodCBvZiB0aGUgcHJldmlvdXMgZGlzY3Vzc2lvbnMsIEkgd2VudCBiYWNrIGFu ZCByZS1yZWFkIHRoaXMgY3VycmVudCBkZWZpbml0aW9uIG9mIFNGQyBFbmNhcHN1bGF0aW9uIGlu IHRoZSB0ZXh0IChzZWN0aW9uIDEuMyk6DQo+PiANCj4+ICAgU0ZDIEVuY2Fwc3VsYXRpb246ICBU aGUgU0ZDIEVuY2Fwc3VsYXRpb24gcHJvdmlkZXMgYXQgYSBtaW5pbXVtIFNGUA0KPj4gICAgICAg IGlkZW50aWZpY2F0aW9uLCBhbmQgaXMgdXNlZCBieSB0aGUgU0ZDLWF3YXJlIGZ1bmN0aW9ucywg c3VjaCBhcw0KPj4gICAgICAgIHRoZSBTRkYgYW5kIFNGQy1hd2FyZSBTRnMuICBUaGUgU0ZDIEVu Y2Fwc3VsYXRpb24gaXMgbm90IHVzZWQNCj4+ICAgICAgICBmb3IgbmV0d29yayBwYWNrZXQgZm9y d2FyZGluZy4gIEluIGFkZGl0aW9uIHRvIFNGUA0KPj4gICAgICAgIGlkZW50aWZpY2F0aW9uLCB0 aGUgU0ZDIGVuY2Fwc3VsYXRpb24gY2FycmllcyBkYXRhcGxhbmUgY29udGV4dA0KPj4gICAgICAg IGluZm9ybWF0aW9uLCBhbHNvIHJlZmVycmVkIHRvIGFzIG1ldGFkYXRhLg0KPj4gDQo+PiBJIHRo aW5rIHRoaXMgY291bGQgYmUgdGlnaHRlbmVkIHVwIHRvIG1ha2Ugc2ltcGxlciBmb3IgdGhlIHJl YWRlcjoNCj4+IA0KPj4gU0ZDIEVuY2Fwc3VsYXRpb246ICBBIGRhdGEgcGxhbmUgZW5jYXBzdWxh dGlvbiB0aGF0IGlkZW50aWZpZXMgdGhlIFNGUCBhbmQvb3IgcHJvdmlkZXMgbWV0YWRhdGEgKGRh dGEgcGxhbmUgY29udGV4dCBpbmZvcm1hdGlvbikuIFRoZSBTRlAgRW5jYXBzdWxhdGlvbiBpcyB1 c2VkIGJ5IHRoZSBTRkMtYXdhcmUgZnVuY3Rpb25zLCBzdWNoIGFzIHRoZSBTRkYgYW5kIFNGQy1h d2FyZSBTRnMsIGFuZCBpcyBub3QgdXNlZCBmb3IgbmV0d29yayBwYWNrZXQgZm9yd2FyZGluZy4N Cj4+IA0KPj4gVGhhbmtzLA0KPj4gQW5keQ0KPj4gDQo+PiANCj4+IA0KPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHNmYyBtYWlsaW5nIGxpc3QN Cj4+IHNmY0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZmMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMNCg== From nobody Tue Aug 12 18:37: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 BB8B51A6FAB for ; Tue, 12 Aug 2014 18:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.269 X-Spam-Level: X-Spam-Status: No, score=-4.269 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 EqhAcZAyrkpD for ; Tue, 12 Aug 2014 18:37:15 -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 D2DA71A6F8D for ; Tue, 12 Aug 2014 18:37:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIE46149; Wed, 13 Aug 2014 01:37:13 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 Aug 2014 02:37:12 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.204]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Wed, 13 Aug 2014 09:37:06 +0800 From: Xuxiaohu To: "Joel M. Halpern" , Alla Goldner , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.txt Thread-Index: AQHPr2AigUDp9PUKd0KN/JsZgTmzp5vLI0nw///Rx4CAAAuOgIAAAJEAgAAKDYCAAADEgIABKf3w//+SYACAAIlyEA== Date: Wed, 13 Aug 2014 01:37:06 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A6C12@NKGEML512-MBS.china.huawei.com> References: <20140803211558.28482.8328.idtracker@ietfa.amsl.com> <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> <53E8CD15.7010002@joelhalpern.com> <53E8D740.6090501@joelhalpern.com> <53E8E053.8050608@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A6840@NKGEML512-MBS.china.huawei.com> <53E97E56.7070508@joelhalpern.com> In-Reply-To: <53E97E56.7070508@joelhalpern.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/VO6sDQKig1tw5sjSb-bfHheLEpM Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.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, 13 Aug 2014 01:37:22 -0000 > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Tuesday, August 12, 2014 10:39 AM > To: Xuxiaohu; Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org > Subject: Re: [sfc] Fwd: New Version Notification for > draft-merged-sfc-architecture-01.txt >=20 > If the encapsulation / decapsulation is part of the job of the SFF, then = there is no > need to discuss or name the node that happens to contain the SFF. Avoidi= ng an > extra term keeps things simpler. Agree. It seems fine to just call the node containing the SFF component as = an SFF node. BTW, should the SFC proxy be looked as an optional functionali= ty of the SFF component or an optional component of the SFF node? Of course= , If you want to deem the SFC proxy as a more-specialized SFF, it seems tha= t Figure 3 should be updated accordingly and it seems better to call it as = proxy-enabled SFF or something like that. Best regards, Xiaohu > Yours, > Joel >=20 > On 8/11/14, 9:30 PM, Xuxiaohu wrote: > > Hi Joel, > > > >> -----Original Message----- > >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > >> Sent: Monday, August 11, 2014 11:25 PM > >> To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org > >> Subject: Re: [sfc] Fwd: New Version Notification for > >> draft-merged-sfc-architecture-01.txt > >> > >> Part of my problem is that the SFF has the information about what the = next > SFF. > >> (Even if the SFP allows only one next-SFF, it is the current SFF who > >> knows what that is. And if the decision is delegated, it is > >> delegated to the SFF. ) But if the Encaps is not part of the SFF, the= n the SFF > has no way to express that decision. > >> Even an Ethernet link does not handle it. > >> > >> I need to check the text on SF Proxy, but I usually think of that as > >> a more-specialized SFF, not as something separate from the SFF. > > > > Fully agree with the above points. That's the reason why I had > > suggested giving the entity containing the SFF or even the SF proxy > > components a name (see > > http://www.ietf.org/mail-archive/web/sfc/current/msg02150.html) > > > > Best regards, > > Xiaohu > > > >> Yours, > >> Joel > >> > >> On 8/11/14, 11:22 AM, Alla Goldner wrote: > >>> Dear Joel, all, > >>> > >>> SFF and transport network connectivity point need to be co-located > >>> (this is not > >> mandatory but makes sense). > >>> This means that a simple L2 connectivity between SFF and the network > >> connectivity point can be used as this interface. > >>> That can be some VLAN or VXLAN or any other L2 protocol. This > >>> shouldn't > >> impose a big overhead on the SFF. > >>> > >>> Also, the same interface you are talking about should exist also > >>> between SFF > >> and SF proxy. > >>> So if we already need to solve it there, we can use it between SFF > >>> and network > >> component. > >>> > >>> I strongly believe we should decouple network transport functions > >>> from the > >> SFF and thus correct the section 4.3. > >>> > >>> Best regards, > >>> > >>> Alla Goldner > >>> Director of Mobile Technologies and Standards Allot Communications > >>> Tel > >>> +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 > >>> agoldner@allot.com www.allot.com > >>> > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >>> Sent: Monday, August 11, 2014 5:46 PM > >>> To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org > >>> Subject: Re: [sfc] Fwd: New Version Notification for > >>> draft-merged-sfc-architecture-01.txt > >>> > >>> That is how we had drawn the figure before. And described the functi= ons. > >>> The problem is that this creates an interface between a network > >>> component > >> and the SFF which can not exist visibly. There is no way I know of > >> to ship the packets between those two. > >>> > >>> So the Encaps / decaps has to be co-located with the SFF. > >>> This archtiecture tries not to get into the internal structure of > >>> the logical > >> components or to describe separately components that must be co-locate= d. > >> Some architectures do describe that. > >>> > >>> Yours, > >>> Joel > >>> > >>> On 8/11/14, 10:44 AM, Alla Goldner wrote: > >>>> Dear Joel, all, > >>>> > >>>> One of the motivations of SFC is be agnostic to the underlay > >>>> transport > >> network. > >>>> When you couple the SFF with the encapsulation/de-capsulation > >>>> process it > >> has to be aware of the network transport and it has to be capable to > >> support different types of transport protocols. > >>>> For me it doesn't make too much sense and it makes the SFF very comp= lex. > >>>> I think that a cleaner architecture is to have the SFF handle the > >>>> SFC tasks and > >> handle the SFC encapsulations (that is the metadata and SFC headers) > >> but leave the transport to be handled by the network layer which can > >> be any type of network. > >>>> > >>>> Best regards, > >>>> > >>>> > >>>> Alla Goldner > >>>> Director of Mobile Technologies and Standards Allot Communications > >>>> Tel > >>>> +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 > >>>> agoldner@allot.com www.allot.com > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >>>> Sent: Monday, August 11, 2014 5:03 PM > >>>> To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org > >>>> Subject: Re: [sfc] Fwd: New Version Notification for > >>>> draft-merged-sfc-architecture-01.txt > >>>> > >>>> I would say instead that we need to fix section 4.5, to make it > >>>> clear that the > >> SFF is responsible for the encaps decaps, while the network uses the > >> outer encapsulation for its forwarding. > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> On 8/11/14, 4:56 AM, Alla Goldner wrote: > >>>>> Dear Carlos, Joel, all, > >>>>> > >>>>> Thanks for providing this merged architecture document! > >>>>> > >>>>> According to the model in figure 3 and section 4.5, the network > >>>>> (underlay) components are responsible for: > >>>>> > >>>>> * Finding the network path to reach the next SF (next SFF) = in > >>>>> the SFP. > >>>>> > >>>>> * Encapsulate/de-capsulate the underlay network transport. > >>>>> > >>>>> Section 4.3 (SFF) contradicts this and says the network > >>>>> encapsulation/de-capsulation is done by the SFF. > >>>>> > >>>>> I believe that the section 4.3 should be fixed in this regard. The > >>>>> reason is that network transport functions should not necessarily > >>>>> be coupled with the SFF. > >>>>> > >>>>> Best regards, > >>>>> > >>>>> *Alla Goldner* > >>>>> > >>>>> *Director of Mobile Technologies and Standards* > >>>>> > >>>>> Allot Communications > >>>>> > >>>>> Tel +972 9 7619251 > >>>>> > >>>>> Cell +972 54 2493985 > >>>>> > >>>>> Fax +972 9 7443626 > >>>>> > >>>>> *agoldner@allot.com **__* > >>>>> > >>>>> *www.allot.com* *__* > >>>>> > >>>>> *__* > >>>>> > >>>>> *291X55_signature (2)* > >>>>> > >>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Carlos > >>>>> Pignataro > >>>>> (cpignata) > >>>>> *Sent:* Monday, August 04, 2014 12:19 AM > >>>>> *To:* sfc@ietf.org > >>>>> *Subject:* [sfc] Fwd: New Version Notification for > >>>>> draft-merged-sfc-architecture-01.txt > >>>>> > >>>>> SFCers, > >>>>> > >>>>> After Toronto, Joel and I have been working on resolving the key > >>>>> open discussion items, and incorporating all the input and > >>>>> feedback received thus into this document as the vehicle for a > >>>>> single SFC Architecture item to progress. > >>>>> > >>>>> While we are still working on the document, we wanted to get a > >>>>> version out early to the WG to test the resolution to key open > >>>>> items, see what we might still be missing, and iterate. > >>>>> > >>>>> Please review and let us know. > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Carlos & Joel. > >>>>> > >>>>> Begin forwarded message: > >>>>> > >>>>> > >>>>> > >>>>> *From: * >>>>> > > >>>>> > >>>>> *Subject: New Version Notification for > >>>>> draft-merged-sfc-architecture-01.txt* > >>>>> > >>>>> *Date: *August 3, 2014 at 5:15:58 PM EDT > >>>>> > >>>>> *To: *Joel Halpern >>>>> >, Carlos Pignataro > >>>>> >, "Joel M. > >>>>> Halpern" >, > >>>>> Carlos Pignataro > > >>>>> > >>>>> > >>>>> A new version of I-D, draft-merged-sfc-architecture-01.txt > >>>>> has been successfully submitted by Carlos Pignataro and posted to > >>>>> the IETF repository. > >>>>> > >>>>> Name:draft-merged-sfc-architecture > >>>>> Revision:01 > >>>>> Title:Service Function Chaining (SFC) Architecture Document > >>>>> date:2014-08-03 Group:Individual Submission > >>>>> Pages:25 > >>>>> URL: > >>>>> http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-0= 1. > >>>>> t > >>>>> xt > >>>>> Status: > >>>>> https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ > >>>>> Htmlized: > >>>>> http://tools.ietf.org/html/draft-merged-sfc-architecture-01 > >>>>> Diff: > >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-01 > >>>>> > >>>>> 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, a= nd > >>>>> 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.ietf.org . > >>>>> > >>>>> The IETF Secretariat > >>>>> > >>>>> ------------------------------------------------------------------ > >>>>> -- > >>>>> - > >>>>> - > >>>>> -- This message is intended only for the designated recipient(s). > >>>>> It may contain confidential or proprietary information. If you are > >>>>> not the designated recipient, you may not review, copy or > >>>>> distribute this message. If you have mistakenly received this > >>>>> message, please notify the sender by a reply e-mail and delete this > message. Thank you. > >>>>> > >>>>> ------------------------------------------------------------------ > >>>>> -- > >>>>> - > >>>>> - > >>>>> -- > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> sfc mailing list > >>>>> sfc@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>> > >>>> > >> > ############################################################# > >> ######## > >>>> # ######################## This message is intended only for the > >>>> designated recipient(s).It may contain confidential or proprietary > >> information. > >>>> If you are not the designated recipient, you may not review, copy > >>>> or > >> distribute this message. > >>>> If you have mistakenly received this message, please notify the > >>>> sender by a > >> reply e-mail and delete this message. > >>>> Thank you. > >>>> > >> > ############################################################# > >> ######## > >>>> # > >>>> ######################## > >>>> > >>> > >> > ############################################################# > >> ######### > >>> ######################## This message is intended only for the > >>> designated recipient(s).It may contain confidential or proprietary > information. > >>> If you are not the designated recipient, you may not review, copy or > >>> distribute > >> this message. > >>> If you have mistakenly received this message, please notify the > >>> sender by a > >> reply e-mail and delete this message. > >>> Thank you. > >>> > >> > ############################################################# > >> ######### > >>> ######################## > >>> > >> > >> _______________________________________________ > >> sfc mailing list > >> sfc@ietf.org > >> https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Aug 12 18: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 DDFFE1A6FC8 for ; Tue, 12 Aug 2014 18:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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.668, 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 V8EUKWqPGVC7 for ; Tue, 12 Aug 2014 18:51:48 -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 304E51A6FC1 for ; Tue, 12 Aug 2014 18:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22601; q=dns/txt; s=iport; t=1407894708; x=1409104308; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EKJZqxP+NcxBYUljG6h+RdO38z5RNQi5WFrQrhsBKtQ=; b=ltreItSqx2I48tGqflPsEMp9moi9o4jmdOBZkl4HNELSgpg11UZzHec7 4/jnHIcyBDxbEQZRnlk6kT/6iSOQ1blLp2DJre30smlTWGx0WrBOfesoR ND3v95S9I8acIsfwZ+bXxg311jPMV4+II/KmORjJaFcZT7YRkzLoKNWm0 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFACTE6lOtJV2R/2dsb2JhbABagkcjI1JXBLFsmV+BWQEJh0gBgREWd4QDAQEBAwEBAQELVwIHCwULAgEIEQEDAQEBJwchBgsUAwYIAgQOBRuIEwMJCAEMv0QNhUMXiX+DIIIpBAYBgy+BHQWPCoIThCaEaIIOgVeMdIYzghaBRmyBSA X-IronPort-AV: E=Sophos;i="5.01,853,1400025600"; d="scan'208,217";a="347159671" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP; 13 Aug 2014 01:51:46 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s7D1pk1W016288 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Aug 2014 01:51:46 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Tue, 12 Aug 2014 20:51:46 -0500 From: "Carlos Pignataro (cpignata)" To: Lucy yong Thread-Topic: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt Thread-Index: AQHPsjoEpUaq91+aSUyfBy1ywE3Zo5vFa98AgAAELYCAAMs3gIAAw3mAgAAmDwCAAG8HgIAEQdSAgAJL/gA= Date: Wed, 13 Aug 2014 01:51:45 +0000 Message-ID: <5F8C4A2F-3C60-459D-92F7-31EA1DA9E469@cisco.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A4805@NKGEML512-MBS.china.huawei.com> <57B2ECF6-8DB4-4E23-BB14-E030EB74E09C@alcatel-lucent.com> <2691CE0099834E4A9C5044EEC662BB9D453CBFBE@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453CBFBE@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.82.213.37] Content-Type: multipart/alternative; boundary="_000_5F8C4A2F3C60459D92F731EA1DA9E469ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/vnwP_wRxAsWWtluztDH8NRxA2pY Cc: Xiaohu Xu , "Dolganow, Andrew \(Andrew\)" , "Andrew G. Malis" , "sfc@ietf.org" , "Joel M. Halpern" Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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, 13 Aug 2014 01:51:51 -0000 --_000_5F8C4A2F3C60459D92F731EA1DA9E469ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Andy, Lucy, Flexibility is certainly good as long as it does not get in the way of inte= roperability. This architecture drives a balance and tradeoff in which opti= ons are maximized while having interoperability as the goal. >From a technical perspective, the SFC Encapsulation specifies the Service F= unction Path to allow for end-to-end SFPs and interoperable implementations= . One of the key principles of this architecture is that the SFC Encapsulat= ion is transport-independent. The text is flexible such that any transport = may be used to carry the SFC encapsulation. However, two SFs part of an SFP= that are not adjacent in the services topology can have different transpor= t encapsulations but need the SFC-encapsulation (minimum invariant encap) t= o specify the SPF. This is within the service topology, which again is inde= pendent from the underlay topology as an architectural principle. Please no= te that the use of the SFC encapsulation to specify the SFP and the SFFs an= d SFs use of this is articulated throughout the architecture. This architec= ture also allows for flexibility in bringing SFC-unaware SFs by proxy as th= e one gateway, to provide backwards compatibility, but attempts to carry fo= rward interoperability. Consequently, for "SFC Aware" chains, the architect= ural choice that follows the principles is to carry the SFP id. It is (also= ) to convey shared context (when demanded by the use case) using the SFC-en= capsulation for similar reasons. As a WG, I believe we should first strive = for a single service-level data plane encapsulation as per the current WG c= harter and based on that provide the most optimal placement of functions an= d identifiers. Note also that I was pointing to the charter because I believe these points= were discussed already to get to the current charter text. Best, Carlos. On Aug 11, 2014, at 10:47 AM, Lucy yong > wrote: I agree Andy=92s point. Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Andrew G. Malis Sent: Friday, August 08, 2014 4:47 PM To: Carlos Pignataro (cpignata) Cc: Xuxiaohu; Dolganow, Andrew (Andrew); sfc@ietf.org;= Joel M. Halpern Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-arch= itecture-01.txt Carlos, I agree that the charter requires the encapsulation to support each of the = bullet items, but there's no requirement that every encapsulated packet wil= l need all of the bullet items supported, so I'm trying to keep the text as= flexible as possible to not preclude possible solutions. Cheers, Andy On Fri, Aug 8, 2014 at 11:09 AM, Carlos Pignataro (cpignata) > wrote: Hi, Andrew, On Aug 8, 2014, at 8:53 AM, Dolganow, Andrew (Andrew) > wrote: > I agree that we should have stronger separation of two functions: SFP and= metadata. > > How about small edit to what Andy proposed: > > SFC Encapsulation: A data plane encapsulation that encodes either one or= both of > - the SFP > - metadata (data plane context information). Looking at http://datatracker.ietf.org/wg/sfc/charter/, there is no "either= one or both of". In fact, looking at the history of the charter text, the = text for SFC Encapsulation is a bullet list form of a longer sentence that = includes "and" only (see 00-09). Thanks, Carlos. >> The SFP Encapsulation is used by the SFC-aware functions, such as the SF= F and SFC-aware SFs, and is not used for network packet forwarding. > > > Andrew > > Sent from my iPhone > >> On Aug 7, 2014, at 9:13 PM, "Xuxiaohu" > wrote: >> >> I fully agree with Andy=92s point that not every usage of the encapsulat= ion will need both the SFP identification and the metadata. It=92s better t= hat the SFC encapsulation could be flexibly used for carrying SFP identific= ation, metadata or both. Otherwise, it seems that those SFC approaches whic= h don=92t use the SFC encapsulation for SFC selection would have to separat= ely define the way of carrying metadata. >> >> Best regards, >> Xiaohu >> >> From: sfc [mailto:sfc-bounces@ietf.org] On = Behalf Of Andrew G. Malis >> Sent: Thursday, August 07, 2014 9:06 PM >> To: Carlos Pignataro (cpignata) >> Cc: Joel M. Halpern; sfc@ietf.org >> Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-a= rchitecture-01.txt >> >> Carlos, >> >> When I re-read the definition, it seemed to me to be more of a string of= thoughts than a concise definition, which is why I was trying to tighten i= t up. A definition is meant to be a short summary for quick reference, whil= e the discussion in 4.1 goes into the more formal details. Otherwise, you = would just repeat the entire section 4.1 in section 1.3. This is why it do= esn't need to be in separate sentences. The "and/or" is because not every u= sage of the encapsulation will need both the SFP identification and the met= adata, so the definition needs to concisely convey that. >> >> Cheers, >> Andy >> >> On Thu, Aug 7, 2014 at 8:51 AM, Carlos Pignataro (cpignata) > wrote: >> Thank you for going back and checking, Andy! >> >> Which specific part of the current definition do you believe is loose en= ough to need tightening? >> >> I believe that your new proposal falls shorter than the existing text in= a few areas: >> =95 First, it combines two different functions (SFP identification and m= etadata/context information) into a single sentence. This opposes the chang= e we just made based on your preference in Section 4.1, which breaks the tw= o functions into two sentences, for reader clarity. While longer, it's simp= ler. >> =95 Second, it introduces an extraneous "and/or" that would change the m= eaning, and negate the "at a minimum" existing bit. That would not be simpl= ifying. >> =95 Third, there is no third but three bullets look better :-) >> >> Net-net, the original text, even when longer in character count, seems m= ore clear and simpler to the reader (because of the separated sentences), I= MHO. >> >> Thanks, >> >> Carlos. >> >> On Aug 7, 2014, at 8:20 AM, Andrew G. Malis > wrote: >> >> >> Carlos and Joel, >> >> In light of the previous discussions, I went back and re-read this curre= nt definition of SFC Encapsulation in the text (section 1.3): >> >> SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP >> identification, and is used by the SFC-aware functions, such as >> the SFF and SFC-aware SFs. The SFC Encapsulation is not used >> for network packet forwarding. In addition to SFP >> identification, the SFC encapsulation carries dataplane context >> information, also referred to as metadata. >> >> I think this could be tightened up to make simpler for the reader: >> >> SFC Encapsulation: A data plane encapsulation that identifies the SFP a= nd/or provides metadata (data plane context information). The SFP Encapsula= tion is used by the SFC-aware functions, such as the SFF and SFC-aware SFs,= and is not used for network packet forwarding. >> >> Thanks, >> Andy >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc --_000_5F8C4A2F3C60459D92F731EA1DA9E469ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <32AE72DA0932EC45A54F8221633CC3F2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hi, Andy, Lucy,

Flexibility is certainly good as long as it does not get in the way of= interoperability. This architecture drives a balance and tradeoff in which= options are maximized while having interoperability as the goal.

From a technical perspective, the SFC Encapsulation specifies the Serv= ice Function Path to allow for end-to-end SFPs and interoperable implementa= tions. One of the key principles of this architecture is that the SFC Encap= sulation is transport-independent. The text is flexible such that any transport may be used to carry the SFC = encapsulation. However, two SFs part of an SFP that are not adjacent in the= services topology can have different transport encapsulations but need the= SFC-encapsulation (minimum invariant encap) to specify the SPF. This is within the service topology, which agai= n is independent from the underlay topology as an architectural principle. = Please note that the use of the SFC encapsulation to specify the SFP and th= e SFFs and SFs use of this is articulated throughout the architecture. This architecture also allows for flexibility= in bringing SFC-unaware SFs by proxy as the one gateway, to provide backwa= rds compatibility, but attempts to carry forward interoperability. Conseque= ntly, for "SFC Aware" chains, the architectural choice that follows the principles is to carry the SFP id. I= t is (also) to convey shared context (when demanded by the use case) using = the SFC-encapsulation for similar reasons. As a WG, I believe we should fir= st strive for a single service-level data plane encapsulation as per the current WG charter and based on that p= rovide the most optimal placement of functions and identifiers.

Note also that I was pointing to the charter because I believe these p= oints were discussed already to get to the current charter text.

Best,

Carlos.

On Aug 11, 2014, at 10:47 AM, Lucy yong <lucy.yong@huawei.com> wrote:

I agree Andy=92s point.
 
Lucy
 
From:<= /span> sfc [= mailto:sfc-bounces@ietf.org] = ;On Behalf Of Andrew G. = Malis
Sent: Friday, Augu= st 08, 2014 4:47 PM
To: Carlos Pignata= ro (cpignata)
Cc: Xuxiaohu; Dolg= anow, Andrew (Andrew); sfc@ietf.org; Joel M. Halpern
Subject: Re: [sfc]= Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt
 
Carlos,
 
I agree that the charter requires the encapsulation to support each of the = bullet items, but there's no requirement that every encapsulated packet wil= l need all of the bullet items supported, so I'm trying to keep the text as= flexible as possible to not preclude possible solutions.
 
Cheers,
Andy

 

On Fri, Aug 8, 2014 at 11:09 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
Hi, Andrew,


On Aug 8, 2014, at 8:53 AM, Dolganow, Andrew (Andrew) <andrew.dolganow@alcatel-lucent.com> wrote:

> I agree that we should have stronger separation of two functions: SFP = and metadata.
>
> How about small edit to what Andy proposed:
>
> SFC Encapsulation:  A data plane encapsulation that encodes eithe= r one or both of
> - the SFP
> - metadata (data plane context information).

Looking at http://datatracker.ietf.org/wg/sfc/ch= arter/, there is no "either one or both of". In fact, looking at the history of the charter text, the text for SFC Enca= psulation is a bullet list form of a longer sentence that includes "an= d" only (see 00-09).

Thanks,

Carlos.


>> The SFP Encapsulation is used by the SFC-aware functions, such as = the SFF and SFC-aware SFs, and is not used for network packet forwarding. >
>
> Andrew
>
> Sent from my iPhone
>
>> On Aug 7, 2014, at 9:13 PM, "Xuxiaohu" <xuxiaohu@huawei.com> wrote:
>>
>> I fully agree with Andy=92s point that not every usage of the enca= psulation will need both the SFP identification and the metadata. It=92s be= tter that the SFC encapsulation could be flexibly used for carrying SFP ide= ntification, metadata or both. Otherwise, it seems that those SFC approaches which don=92t use the SFC encapsulation= for SFC selection would have to separately define the way of carrying meta= data.
>>
>> Best regards,
>> Xiaohu
>>
>> From: sfc [mailto:sfc-bounces@ietf.org] On B= ehalf Of Andrew G. Malis
>> Sent: Thursday, August 07, 2014 9:06 PM
>> To: Carlos Pignataro (cpignata)
>> Cc: Joel M. Halpern; sfc@ietf.org
>> Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged= -sfc-architecture-01.txt
>>
>> Carlos,
>>
>> When I re-read the definition, it seemed to me to be more of a str= ing of thoughts than a concise definition, which is why I was trying to tig= hten it up. A definition is meant to be a short summary for quick reference= , while the discussion in 4.1 goes into the more formal details.  Otherwise, you would just repeat the entire= section 4.1 in section 1.3.  This is why it doesn't need to be in sep= arate sentences. The "and/or" is because not every usage of the e= ncapsulation will need both the SFP identification and the metadata, so the definition needs to concisely convey that.
>>
>> Cheers,
>> Andy
>>
>> On Thu, Aug 7, 2014 at 8:51 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
>> Thank you for going back and checking, Andy!
>>
>> Which specific part of the current definition do you believe is lo= ose enough to need tightening?
>>
>> I believe that your new proposal falls shorter than the existing t= ext in a few areas:
>> =95 First, it combines two different functions (SFP identification= and metadata/context information) into a single sentence. This opposes the= change we just made based on your preference in Section 4.1, which breaks = the two functions into two sentences, for reader clarity. While longer, it's simpler.
>> =95 Second, it introduces an extraneous "and/or" that wo= uld change the meaning, and negate the "at a minimum" existing bi= t. That would not be simplifying.
>> =95 Third, there is no third but three bullets look better :-)
>>
>> Net-net, the original text, even when longer in character count, s= eems more clear and simpler to the reader (because of the separated sentenc= es), IMHO.
>>
>> Thanks,
>>
>> Carlos.
>>
>> On Aug 7, 2014, at 8:20 AM, Andrew G. Malis <agm= alis@gmail.com> wrote:
>>
>>
>> Carlos and Joel,
>>
>> In light of the previous discussions, I went back and re-read this= current definition of SFC Encapsulation in the text (section 1.3):
>>
>>   SFC Encapsulation:  The SFC Encapsulation provides at = a minimum SFP
>>        identification, and is used by the SFC-= aware functions, such as
>>        the SFF and SFC-aware SFs.  The SF= C Encapsulation is not used
>>        for network packet forwarding.  In= addition to SFP
>>        identification, the SFC encapsulation c= arries dataplane context
>>        information, also referred to as metada= ta.
>>
>> I think this could be tightened up to make simpler for the reader:=
>>
>> SFC Encapsulation:  A data plane encapsulation that identifie= s the SFP and/or provides metadata (data plane context information). The SF= P Encapsulation is used by the SFC-aware functions, such as the SFF and SFC= -aware SFs, and is not used for network packet forwarding.
>>
>> Thanks,
>> Andy
>>
>>
>>
>> _______________________________________________
>> sfc mailing list
>> sfc@ie= tf.org
>> https://www.ietf.org/mailman/listinfo/sfc=


--_000_5F8C4A2F3C60459D92F731EA1DA9E469ciscocom_-- From nobody Tue Aug 12 18:51: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 9F9B91A6FCD for ; Tue, 12 Aug 2014 18:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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.668, 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 8GZPafg94xBT for ; Tue, 12 Aug 2014 18:51:51 -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 9FA2C1A6FC1 for ; Tue, 12 Aug 2014 18:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5937; q=dns/txt; s=iport; t=1407894711; x=1409104311; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Zo8M//A+zsdHNt8QAgSjLrusyu0umRl9tQp5aHSAvoc=; b=lVxyaovjPDBdn4kyE8F13S4FUPJnSnFAjNLGcb72Sa7VY67wlHNBVrKr bWvZuqV8WNJP6xVANHeG8kQLSZMYsKBu7RYn/Wwp3Kf4K+Rvf5RfmtRvb AiWd7GDX8q2mJLVPWNgL4aEbeLO3Om7V8MNVfx62cEQUYi2PZXb6hsmgb A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFABjE6lOtJV2c/2dsb2JhbABagmojUlcEzSgKh0gBgREWd4QDAQEBAwEBAQFkBwsFBwQCAQgRAQMBAQEnByEGCxQDBggCBA4FiC4DCQgBDL9EDYVDF4l/gyCBejMHBoMpgR0FjwqCE4QmhGiCDoFXjHSGM4IWgUZsgUg X-IronPort-AV: E=Sophos;i="5.01,853,1400025600"; d="scan'208";a="347045950" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 13 Aug 2014 01:51:50 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s7D1po1j013502 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Aug 2014 01:51:50 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Tue, 12 Aug 2014 20:51:50 -0500 From: "Carlos Pignataro (cpignata)" To: "Hongyu Li (Julio)" Thread-Topic: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt Thread-Index: AQHPsjoEpUaq91+aSUyfBy1ywE3Zo5vFa98AgAAELYCAAMs3gIAAw3mAgAAmDwCABdjGgIABJBoA Date: Wed, 13 Aug 2014 01:51:50 +0000 Message-ID: <31ACE4AA-5F9E-4504-B68D-94CFD7FC0AD4@cisco.com> References: , <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A4805@NKGEML512-MBS.china.huawei.com> <57B2ECF6-8DB4-4E23-BB14-E030EB74E09C@alcatel-lucent.com> <6EB34CB5D82C4645B826C56144826EA97EA55327@SZXEMA509-MBX.china.huawei.com> In-Reply-To: <6EB34CB5D82C4645B826C56144826EA97EA55327@SZXEMA509-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.213.37] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/QHXfWB5QVKmSFANbeneZu1iRNnk Cc: Xiaohu Xu , "Dolganow, Andrew \(Andrew\)" , "Andrew G. Malis" , "sfc@ietf.org" , "Joel M. Halpern" Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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, 13 Aug 2014 01:51:53 -0000 Hi, Hongyu, I see this a very similar way. Thanks, -- Carlos. On Aug 12, 2014, at 4:26 AM, Hongyu Li (Julio) wrote= : > Hi Carlos and all, >=20 > Since the design goal is to allow SFC being an overlay of any network, it= make sense to have a generic data plane encapsulation encodes the SFP. Mea= nwhile, communication between SFs, where metadata is used, may be required = in certain scenarios but not all cases, so, metadata should be optionally e= ncapsulated. >=20 > Cheers, > Hongyu >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro (cp= ignata) > Sent: Friday, August 08, 2014 11:09 PM > To: Dolganow, Andrew (Andrew) > Cc: Xuxiaohu; Joel M. Halpern; Andrew G. Malis; sfc@ietf.org > Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-ar= chitecture-01.txt >=20 > Hi, Andrew, >=20 > On Aug 8, 2014, at 8:53 AM, Dolganow, Andrew (Andrew) wrote: >=20 >> I agree that we should have stronger separation of two functions: SFP an= d metadata.=20 >>=20 >> How about small edit to what Andy proposed: >>=20 >> SFC Encapsulation: A data plane encapsulation that encodes either one o= r both of >> - the SFP=20 >> - metadata (data plane context information).=20 >=20 > Looking at http://datatracker.ietf.org/wg/sfc/charter/, there is no "eith= er one or both of". In fact, looking at the history of the charter text, th= e text for SFC Encapsulation is a bullet list form of a longer sentence tha= t includes "and" only (see 00-09). >=20 > Thanks, >=20 > Carlos. >=20 >>> The SFP Encapsulation is used by the SFC-aware functions, such as the S= FF and SFC-aware SFs, and is not used for network packet forwarding. >>=20 >>=20 >> Andrew >>=20 >> Sent from my iPhone >>=20 >>> On Aug 7, 2014, at 9:13 PM, "Xuxiaohu" wrote: >>>=20 >>> I fully agree with Andy=92s point that not every usage of the encapsula= tion will need both the SFP identification and the metadata. It=92s better = that the SFC encapsulation could be flexibly used for carrying SFP identifi= cation, metadata or both. Otherwise, it seems that those SFC approaches whi= ch don=92t use the SFC encapsulation for SFC selection would have to separa= tely define the way of carrying metadata. >>>=20 >>> Best regards, >>> Xiaohu=20 >>>=20 >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Andrew G. Malis >>> Sent: Thursday, August 07, 2014 9:06 PM >>> To: Carlos Pignataro (cpignata) >>> Cc: Joel M. Halpern; sfc@ietf.org >>> Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-= architecture-01.txt >>>=20 >>> Carlos, >>>=20 >>> When I re-read the definition, it seemed to me to be more of a string o= f thoughts than a concise definition, which is why I was trying to tighten = it up. A definition is meant to be a short summary for quick reference, whi= le the discussion in 4.1 goes into the more formal details. Otherwise, you= would just repeat the entire section 4.1 in section 1.3. This is why it d= oesn't need to be in separate sentences. The "and/or" is because not every = usage of the encapsulation will need both the SFP identification and the me= tadata, so the definition needs to concisely convey that. >>>=20 >>> Cheers, >>> Andy >>>=20 >>> On Thu, Aug 7, 2014 at 8:51 AM, Carlos Pignataro (cpignata) wrote: >>> Thank you for going back and checking, Andy!=20 >>>=20 >>> Which specific part of the current definition do you believe is loose e= nough to need tightening? >>>=20 >>> I believe that your new proposal falls shorter than the existing text i= n a few areas: >>> =95 First, it combines two different functions (SFP identification and = metadata/context information) into a single sentence. This opposes the chan= ge we just made based on your preference in Section 4.1, which breaks the t= wo functions into two sentences, for reader clarity. While longer, it's sim= pler. >>> =95 Second, it introduces an extraneous "and/or" that would change the = meaning, and negate the "at a minimum" existing bit. That would not be simp= lifying. >>> =95 Third, there is no third but three bullets look better :-) >>>=20 >>> Net-net, the original text, even when longer in character count, seems = more clear and simpler to the reader (because of the separated sentences), = IMHO. >>>=20 >>> Thanks, >>>=20 >>> Carlos. >>>=20 >>> On Aug 7, 2014, at 8:20 AM, Andrew G. Malis wrote: >>>=20 >>>=20 >>> Carlos and Joel,=20 >>>=20 >>> In light of the previous discussions, I went back and re-read this curr= ent definition of SFC Encapsulation in the text (section 1.3): >>>=20 >>> SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP >>> identification, and is used by the SFC-aware functions, such as >>> the SFF and SFC-aware SFs. The SFC Encapsulation is not used >>> for network packet forwarding. In addition to SFP >>> identification, the SFC encapsulation carries dataplane context >>> information, also referred to as metadata. >>>=20 >>> I think this could be tightened up to make simpler for the reader: >>>=20 >>> SFC Encapsulation: A data plane encapsulation that identifies the SFP = and/or provides metadata (data plane context information). The SFP Encapsul= ation is used by the SFC-aware functions, such as the SFF and SFC-aware SFs= , and is not used for network packet forwarding. >>>=20 >>> Thanks, >>> Andy >>>=20 >>>=20 >>>=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 From nobody Tue Aug 12 18:52: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 283B71A6FD5 for ; Tue, 12 Aug 2014 18:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.569 X-Spam-Level: X-Spam-Status: No, score=-14.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 UTbb7Jl3TB3o for ; Tue, 12 Aug 2014 18:52:05 -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 0BA2C1A6FC1 for ; Tue, 12 Aug 2014 18:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12074; q=dns/txt; s=iport; t=1407894725; x=1409104325; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Cf0RYc6TDhy769ZHSBc5gHy8wZMgZc8RaA6NuAXe7RM=; b=A61t0VsvXlozvg1k6EAN0mMqkXuPh02eiVNs4kur31MKZciIoM89/NvR Q21Eye5JkcSuM/kYravbpjIg5z9gsu0PwWQQDtr07mqYQHSxvBKa/3TOB XYc5MP0Xg0exEQL96mOwrZmTUDefHBEIrszlBfELfDDsFS4DqHV8hKiNA w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFANzD6lOtJA2F/2dsb2JhbABagmojUlMEBM0oCodIAYERFneEAwEBAQMBAQEBRiUJAgUHBAIBCAcKAQIBAQEBJwcnCxQDBggCBA4FCRKIHwgBBwXFFheOaRIBARwzAgUGgymBHQWGEIRThBQTghOEJoZ2gVeGV4xQg1xsAYEOOQ X-IronPort-AV: E=Sophos;i="5.01,853,1400025600"; d="scan'208";a="68752856" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP; 13 Aug 2014 01:52:03 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s7D1q360015013 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Aug 2014 01:52:03 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Tue, 12 Aug 2014 20:52:03 -0500 From: "Carlos Pignataro (cpignata)" To: "Joel M. Halpern" Thread-Topic: [sfc] New Version Notification for draft-merged-sfc-architecture-01.txt Thread-Index: AQHPtpktoKl3BuEHDUeTb/LL0zQwHQ== Date: Wed, 13 Aug 2014 01:52:03 +0000 Message-ID: References: <20140803211558.28482.8328.idtracker@ietfa.amsl.com> <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> <53E8CD15.7010002@joelhalpern.com> <53E8D740.6090501@joelhalpern.com> <53E8E053.8050608@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A6840@NKGEML512-MBS.china.huawei.com> <53E97E56.7070508@joelhalpern.com> In-Reply-To: <53E97E56.7070508@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.213.37] 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/KSM_69frLPXWV5kM6Rs4KFiNjhI Cc: Alla Goldner , Xiaohu Xu , "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-merged-sfc-architecture-01.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, 13 Aug 2014 01:52:12 -0000 Note also that since the SFC Network Forwarder (NF) was removed from revisi= on -01, the "container" effectively equals the SFF only (the "entity contai= ning the SFF" contains only the SFF). Thanks, Carlos. On Aug 11, 2014, at 10:39 PM, Joel M. Halpern wrote: > If the encapsulation / decapsulation is part of the job of the SFF, then = there is no need to discuss or name the node that happens to contain the SF= F. Avoiding an extra term keeps things simpler. >=20 > Yours, > Joel >=20 > On 8/11/14, 9:30 PM, Xuxiaohu wrote: >> Hi Joel, >>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>> Sent: Monday, August 11, 2014 11:25 PM >>> To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org >>> Subject: Re: [sfc] Fwd: New Version Notification for >>> draft-merged-sfc-architecture-01.txt >>>=20 >>> Part of my problem is that the SFF has the information about what the n= ext SFF. >>> (Even if the SFP allows only one next-SFF, it is the current SFF who kn= ows what >>> that is. And if the decision is delegated, it is delegated to the SFF.= ) But if the >>> Encaps is not part of the SFF, then the SFF has no way to express that = decision. >>> Even an Ethernet link does not handle it. >>>=20 >>> I need to check the text on SF Proxy, but I usually think of that as a >>> more-specialized SFF, not as something separate from the SFF. >>=20 >> Fully agree with the above points. That's the reason why I had suggested= giving the entity containing the SFF or even the SF proxy components a nam= e (see http://www.ietf.org/mail-archive/web/sfc/current/msg02150.html) >>=20 >> Best regards, >> Xiaohu >>=20 >>> Yours, >>> Joel >>>=20 >>> On 8/11/14, 11:22 AM, Alla Goldner wrote: >>>> Dear Joel, all, >>>>=20 >>>> SFF and transport network connectivity point need to be co-located (th= is is not >>> mandatory but makes sense). >>>> This means that a simple L2 connectivity between SFF and the network >>> connectivity point can be used as this interface. >>>> That can be some VLAN or VXLAN or any other L2 protocol. This shouldn'= t >>> impose a big overhead on the SFF. >>>>=20 >>>> Also, the same interface you are talking about should exist also betwe= en SFF >>> and SF proxy. >>>> So if we already need to solve it there, we can use it between SFF and= network >>> component. >>>>=20 >>>> I strongly believe we should decouple network transport functions from= the >>> SFF and thus correct the section 4.3. >>>>=20 >>>> Best regards, >>>>=20 >>>> Alla Goldner >>>> Director of Mobile Technologies and Standards Allot Communications Tel >>>> +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 >>>> agoldner@allot.com www.allot.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>> Sent: Monday, August 11, 2014 5:46 PM >>>> To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org >>>> Subject: Re: [sfc] Fwd: New Version Notification for >>>> draft-merged-sfc-architecture-01.txt >>>>=20 >>>> That is how we had drawn the figure before. And described the functio= ns. >>>> The problem is that this creates an interface between a network compon= ent >>> and the SFF which can not exist visibly. There is no way I know of to = ship the >>> packets between those two. >>>>=20 >>>> So the Encaps / decaps has to be co-located with the SFF. >>>> This archtiecture tries not to get into the internal structure of the = logical >>> components or to describe separately components that must be co-located= . >>> Some architectures do describe that. >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 8/11/14, 10:44 AM, Alla Goldner wrote: >>>>> Dear Joel, all, >>>>>=20 >>>>> One of the motivations of SFC is be agnostic to the underlay transpor= t >>> network. >>>>> When you couple the SFF with the encapsulation/de-capsulation process= it >>> has to be aware of the network transport and it has to be capable to su= pport >>> different types of transport protocols. >>>>> For me it doesn't make too much sense and it makes the SFF very compl= ex. >>>>> I think that a cleaner architecture is to have the SFF handle the SFC= tasks and >>> handle the SFC encapsulations (that is the metadata and SFC headers) bu= t leave >>> the transport to be handled by the network layer which can be any type = of >>> network. >>>>>=20 >>>>> Best regards, >>>>>=20 >>>>>=20 >>>>> Alla Goldner >>>>> Director of Mobile Technologies and Standards Allot Communications >>>>> Tel >>>>> +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 >>>>> agoldner@allot.com www.allot.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>> Sent: Monday, August 11, 2014 5:03 PM >>>>> To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org >>>>> Subject: Re: [sfc] Fwd: New Version Notification for >>>>> draft-merged-sfc-architecture-01.txt >>>>>=20 >>>>> I would say instead that we need to fix section 4.5, to make it clear= that the >>> SFF is responsible for the encaps decaps, while the network uses the o= uter >>> encapsulation for its forwarding. >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>> On 8/11/14, 4:56 AM, Alla Goldner wrote: >>>>>> Dear Carlos, Joel, all, >>>>>>=20 >>>>>> Thanks for providing this merged architecture document! >>>>>>=20 >>>>>> According to the model in figure 3 and section 4.5, the network >>>>>> (underlay) components are responsible for: >>>>>>=20 >>>>>> * Finding the network path to reach the next SF (next SFF) i= n >>>>>> the SFP. >>>>>>=20 >>>>>> * Encapsulate/de-capsulate the underlay network transport. >>>>>>=20 >>>>>> Section 4.3 (SFF) contradicts this and says the network >>>>>> encapsulation/de-capsulation is done by the SFF. >>>>>>=20 >>>>>> I believe that the section 4.3 should be fixed in this regard. The >>>>>> reason is that network transport functions should not necessarily be >>>>>> coupled with the SFF. >>>>>>=20 >>>>>> Best regards, >>>>>>=20 >>>>>> *Alla Goldner* >>>>>>=20 >>>>>> *Director of Mobile Technologies and Standards* >>>>>>=20 >>>>>> Allot Communications >>>>>>=20 >>>>>> Tel +972 9 7619251 >>>>>>=20 >>>>>> Cell +972 54 2493985 >>>>>>=20 >>>>>> Fax +972 9 7443626 >>>>>>=20 >>>>>> *agoldner@allot.com **__* >>>>>>=20 >>>>>> *www.allot.com* *__* >>>>>>=20 >>>>>> *__* >>>>>>=20 >>>>>> *291X55_signature (2)* >>>>>>=20 >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Carlos >>>>>> Pignataro >>>>>> (cpignata) >>>>>> *Sent:* Monday, August 04, 2014 12:19 AM >>>>>> *To:* sfc@ietf.org >>>>>> *Subject:* [sfc] Fwd: New Version Notification for >>>>>> draft-merged-sfc-architecture-01.txt >>>>>>=20 >>>>>> SFCers, >>>>>>=20 >>>>>> After Toronto, Joel and I have been working on resolving the key >>>>>> open discussion items, and incorporating all the input and feedback >>>>>> received thus into this document as the vehicle for a single SFC >>>>>> Architecture item to progress. >>>>>>=20 >>>>>> While we are still working on the document, we wanted to get a >>>>>> version out early to the WG to test the resolution to key open >>>>>> items, see what we might still be missing, and iterate. >>>>>>=20 >>>>>> Please review and let us know. >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> Carlos & Joel. >>>>>>=20 >>>>>> Begin forwarded message: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> *From: *> >>>>>>=20 >>>>>> *Subject: New Version Notification for >>>>>> draft-merged-sfc-architecture-01.txt* >>>>>>=20 >>>>>> *Date: *August 3, 2014 at 5:15:58 PM EDT >>>>>>=20 >>>>>> *To: *Joel Halpern >>>>> >, Carlos Pignataro >>>>> >, "Joel M. Halpern" >>>>> >, Carlos Pignataro >>>>> > >>>>>>=20 >>>>>>=20 >>>>>> A new version of I-D, draft-merged-sfc-architecture-01.txt >>>>>> has been successfully submitted by Carlos Pignataro and posted to >>>>>> the IETF repository. >>>>>>=20 >>>>>> Name:draft-merged-sfc-architecture >>>>>> Revision:01 >>>>>> Title:Service Function Chaining (SFC) Architecture Document >>>>>> date:2014-08-03 Group:Individual Submission >>>>>> Pages:25 >>>>>> URL: >>>>>> http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-01= . >>>>>> t >>>>>> xt >>>>>> Status: >>>>>> https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ >>>>>> Htmlized: >>>>>> http://tools.ietf.org/html/draft-merged-sfc-architecture-01 >>>>>> Diff: >>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-01 >>>>>>=20 >>>>>> Abstract: >>>>>> This document describes an architecture for the specification, >>>>>> creation, and ongoing maintenance of Service Function Chains (S= FC) >>> in >>>>>> a network. It includes architectural concepts, principles, and >>>>>> components used in the construction of composite services throu= gh >>>>>> 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 >>>>>> submission until the htmlized version and diff are available at >>>>>> tools.ietf.org . >>>>>>=20 >>>>>> The IETF Secretariat >>>>>>=20 >>>>>> -------------------------------------------------------------------- >>>>>> - >>>>>> - >>>>>> -- This message is intended only for the designated recipient(s). It >>>>>> may contain confidential or proprietary information. If you are not >>>>>> the designated recipient, you may not review, copy or distribute >>>>>> this message. If you have mistakenly received this message, please >>>>>> notify the sender by a reply e-mail and delete this message. Thank y= ou. >>>>>>=20 >>>>>> -------------------------------------------------------------------- >>>>>> - >>>>>> - >>>>>> -- >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>=20 >>>>>=20 >>> ############################################################# >>> ######## >>>>> # ######################## This message is intended only for the >>>>> designated recipient(s).It may contain confidential or proprietary >>> information. >>>>> If you are not the designated recipient, you may not review, copy or >>> distribute this message. >>>>> If you have mistakenly received this message, please notify the sende= r by a >>> reply e-mail and delete this message. >>>>> Thank you. >>>>>=20 >>> ############################################################# >>> ######## >>>>> # >>>>> ######################## >>>>>=20 >>>>=20 >>> ############################################################# >>> ######### >>>> ######################## This message is intended only for the >>>> designated recipient(s).It may contain confidential or proprietary inf= ormation. >>>> If you are not the designated recipient, you may not review, copy or d= istribute >>> this message. >>>> If you have mistakenly received this message, please notify the sender= by a >>> reply e-mail and delete this message. >>>> Thank you. >>>>=20 >>> ############################################################# >>> ######### >>>> ######################## >>>>=20 >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Aug 12 18:52: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 6A1261A6FD5 for ; Tue, 12 Aug 2014 18:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.569 X-Spam-Level: X-Spam-Status: No, score=-14.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 Hq2ngF04Wuhq for ; Tue, 12 Aug 2014 18:52:13 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FB091A6FC1 for ; Tue, 12 Aug 2014 18:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13529; q=dns/txt; s=iport; t=1407894733; x=1409104333; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=JpUwqJA0P0z3jUgX/e+Z1PRaaATZ2ffQY6WINbZMkz8=; b=asvmLmOkcyNI1VnAjkeiaZIs+JfhVUiXdRJrWhBzSO33yYZn/HXVCvSp vnIbZJCW95MKl4sME40PWoBpABn1O2P4nTFrHylRmtiRGRod6WZyTiRO+ rMYju46nyKzXMRz2+4dAelxZv5t+V7FNs//GKjdx+K2CVDFrl4gpTREGE E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAK7D6lOtJA2I/2dsb2JhbABagmojUlMEBM0oDIdGAYERFneEAwEBAQMBAQEBNw8lCQIFBwQCAQgHCgECAQEBAR4JBycLFAMGCAIEDgUJEogfCAEHBcUWF4l/hGoSAQEcESEBAgUGgymBHQWGEIh6ghOEJoZ2gVeTJ4IWgUZsAYEOOQ X-IronPort-AV: E=Sophos;i="5.01,853,1400025600"; d="scan'208";a="68750246" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP; 13 Aug 2014 01:52:11 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s7D1qBOJ014435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Aug 2014 01:52:11 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Tue, 12 Aug 2014 20:52:11 -0500 From: "Carlos Pignataro (cpignata)" To: Xiaohu Xu Thread-Topic: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.txt Thread-Index: AQHPtW0DFUhLnw6Kf0yh+T12LJbQpZvLznKAgAAAkQCAAAoNgIAAAMSAgACpNICAABMpAIABgPQAgAAEOYA= Date: Wed, 13 Aug 2014 01:52:11 +0000 Message-ID: <6BA840C8-BF58-44D9-8840-048431FBBF1E@cisco.com> References: <20140803211558.28482.8328.idtracker@ietfa.amsl.com> <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> <53E8CD15.7010002@joelhalpern.com> <53E8D740.6090501@joelhalpern.com> <53E8E053.8050608@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A6840@NKGEML512-MBS.china.huawei.com> <53E97E56.7070508@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A6C12@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A6C12@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.213.37] Content-Type: text/plain; charset="us-ascii" Content-ID: <92536B4571FB4F48B6B179F8E3A797D4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/TEOp1k6Zm8F3QkSMcdneB1n9OP0 Cc: Alla Goldner , "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.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, 13 Aug 2014 01:52:16 -0000 Hi, Xiaohu, On Aug 12, 2014, at 9:37 PM, Xuxiaohu wrote: >=20 >=20 >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Tuesday, August 12, 2014 10:39 AM >> To: Xuxiaohu; Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org >> Subject: Re: [sfc] Fwd: New Version Notification for >> draft-merged-sfc-architecture-01.txt >>=20 >> If the encapsulation / decapsulation is part of the job of the SFF, then= there is no >> need to discuss or name the node that happens to contain the SFF. Avoid= ing an >> extra term keeps things simpler. >=20 > Agree. It seems fine to just call the node containing the SFF component a= s an SFF node. BTW, should the SFC proxy be looked as an optional functiona= lity of the SFF component or an optional component of the SFF node? Of cour= se, If you want to deem the SFC proxy as a more-specialized SFF, it seems t= hat Figure 3 should be updated accordingly and it seems better to call it a= s proxy-enabled SFF or something like that. >=20 Besides the name in Figure 3, we should look at the overall SFC Proxy text:= =20 http://tools.ietf.org/html/draft-merged-sfc-architecture-01#section-4.6 Anything in this section that you think does not match what was discussed a= bout the SFC Proxy? Thanks, Carlos. > Best regards, > Xiaohu >=20 >> Yours, >> Joel >>=20 >> On 8/11/14, 9:30 PM, Xuxiaohu wrote: >>> Hi Joel, >>>=20 >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>> Sent: Monday, August 11, 2014 11:25 PM >>>> To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org >>>> Subject: Re: [sfc] Fwd: New Version Notification for >>>> draft-merged-sfc-architecture-01.txt >>>>=20 >>>> Part of my problem is that the SFF has the information about what the = next >> SFF. >>>> (Even if the SFP allows only one next-SFF, it is the current SFF who >>>> knows what that is. And if the decision is delegated, it is >>>> delegated to the SFF. ) But if the Encaps is not part of the SFF, the= n the SFF >> has no way to express that decision. >>>> Even an Ethernet link does not handle it. >>>>=20 >>>> I need to check the text on SF Proxy, but I usually think of that as >>>> a more-specialized SFF, not as something separate from the SFF. >>>=20 >>> Fully agree with the above points. That's the reason why I had >>> suggested giving the entity containing the SFF or even the SF proxy >>> components a name (see >>> http://www.ietf.org/mail-archive/web/sfc/current/msg02150.html) >>>=20 >>> Best regards, >>> Xiaohu >>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 8/11/14, 11:22 AM, Alla Goldner wrote: >>>>> Dear Joel, all, >>>>>=20 >>>>> SFF and transport network connectivity point need to be co-located >>>>> (this is not >>>> mandatory but makes sense). >>>>> This means that a simple L2 connectivity between SFF and the network >>>> connectivity point can be used as this interface. >>>>> That can be some VLAN or VXLAN or any other L2 protocol. This >>>>> shouldn't >>>> impose a big overhead on the SFF. >>>>>=20 >>>>> Also, the same interface you are talking about should exist also >>>>> between SFF >>>> and SF proxy. >>>>> So if we already need to solve it there, we can use it between SFF >>>>> and network >>>> component. >>>>>=20 >>>>> I strongly believe we should decouple network transport functions >>>>> from the >>>> SFF and thus correct the section 4.3. >>>>>=20 >>>>> Best regards, >>>>>=20 >>>>> Alla Goldner >>>>> Director of Mobile Technologies and Standards Allot Communications >>>>> Tel >>>>> +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 >>>>> agoldner@allot.com www.allot.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>> Sent: Monday, August 11, 2014 5:46 PM >>>>> To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org >>>>> Subject: Re: [sfc] Fwd: New Version Notification for >>>>> draft-merged-sfc-architecture-01.txt >>>>>=20 >>>>> That is how we had drawn the figure before. And described the functi= ons. >>>>> The problem is that this creates an interface between a network >>>>> component >>>> and the SFF which can not exist visibly. There is no way I know of >>>> to ship the packets between those two. >>>>>=20 >>>>> So the Encaps / decaps has to be co-located with the SFF. >>>>> This archtiecture tries not to get into the internal structure of >>>>> the logical >>>> components or to describe separately components that must be co-locate= d. >>>> Some architectures do describe that. >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>> On 8/11/14, 10:44 AM, Alla Goldner wrote: >>>>>> Dear Joel, all, >>>>>>=20 >>>>>> One of the motivations of SFC is be agnostic to the underlay >>>>>> transport >>>> network. >>>>>> When you couple the SFF with the encapsulation/de-capsulation >>>>>> process it >>>> has to be aware of the network transport and it has to be capable to >>>> support different types of transport protocols. >>>>>> For me it doesn't make too much sense and it makes the SFF very comp= lex. >>>>>> I think that a cleaner architecture is to have the SFF handle the >>>>>> SFC tasks and >>>> handle the SFC encapsulations (that is the metadata and SFC headers) >>>> but leave the transport to be handled by the network layer which can >>>> be any type of network. >>>>>>=20 >>>>>> Best regards, >>>>>>=20 >>>>>>=20 >>>>>> Alla Goldner >>>>>> Director of Mobile Technologies and Standards Allot Communications >>>>>> Tel >>>>>> +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 >>>>>> agoldner@allot.com www.allot.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>>> Sent: Monday, August 11, 2014 5:03 PM >>>>>> To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org >>>>>> Subject: Re: [sfc] Fwd: New Version Notification for >>>>>> draft-merged-sfc-architecture-01.txt >>>>>>=20 >>>>>> I would say instead that we need to fix section 4.5, to make it >>>>>> clear that the >>>> SFF is responsible for the encaps decaps, while the network uses the >>>> outer encapsulation for its forwarding. >>>>>>=20 >>>>>> Yours, >>>>>> Joel >>>>>>=20 >>>>>> On 8/11/14, 4:56 AM, Alla Goldner wrote: >>>>>>> Dear Carlos, Joel, all, >>>>>>>=20 >>>>>>> Thanks for providing this merged architecture document! >>>>>>>=20 >>>>>>> According to the model in figure 3 and section 4.5, the network >>>>>>> (underlay) components are responsible for: >>>>>>>=20 >>>>>>> * Finding the network path to reach the next SF (next SFF) = in >>>>>>> the SFP. >>>>>>>=20 >>>>>>> * Encapsulate/de-capsulate the underlay network transport. >>>>>>>=20 >>>>>>> Section 4.3 (SFF) contradicts this and says the network >>>>>>> encapsulation/de-capsulation is done by the SFF. >>>>>>>=20 >>>>>>> I believe that the section 4.3 should be fixed in this regard. The >>>>>>> reason is that network transport functions should not necessarily >>>>>>> be coupled with the SFF. >>>>>>>=20 >>>>>>> Best regards, >>>>>>>=20 >>>>>>> *Alla Goldner* >>>>>>>=20 >>>>>>> *Director of Mobile Technologies and Standards* >>>>>>>=20 >>>>>>> Allot Communications >>>>>>>=20 >>>>>>> Tel +972 9 7619251 >>>>>>>=20 >>>>>>> Cell +972 54 2493985 >>>>>>>=20 >>>>>>> Fax +972 9 7443626 >>>>>>>=20 >>>>>>> *agoldner@allot.com **__* >>>>>>>=20 >>>>>>> *www.allot.com* *__* >>>>>>>=20 >>>>>>> *__* >>>>>>>=20 >>>>>>> *291X55_signature (2)* >>>>>>>=20 >>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Carlos >>>>>>> Pignataro >>>>>>> (cpignata) >>>>>>> *Sent:* Monday, August 04, 2014 12:19 AM >>>>>>> *To:* sfc@ietf.org >>>>>>> *Subject:* [sfc] Fwd: New Version Notification for >>>>>>> draft-merged-sfc-architecture-01.txt >>>>>>>=20 >>>>>>> SFCers, >>>>>>>=20 >>>>>>> After Toronto, Joel and I have been working on resolving the key >>>>>>> open discussion items, and incorporating all the input and >>>>>>> feedback received thus into this document as the vehicle for a >>>>>>> single SFC Architecture item to progress. >>>>>>>=20 >>>>>>> While we are still working on the document, we wanted to get a >>>>>>> version out early to the WG to test the resolution to key open >>>>>>> items, see what we might still be missing, and iterate. >>>>>>>=20 >>>>>>> Please review and let us know. >>>>>>>=20 >>>>>>> Thanks, >>>>>>>=20 >>>>>>> Carlos & Joel. >>>>>>>=20 >>>>>>> Begin forwarded message: >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> *From: *>>>>>> > >>>>>>>=20 >>>>>>> *Subject: New Version Notification for >>>>>>> draft-merged-sfc-architecture-01.txt* >>>>>>>=20 >>>>>>> *Date: *August 3, 2014 at 5:15:58 PM EDT >>>>>>>=20 >>>>>>> *To: *Joel Halpern >>>>>> >, Carlos Pignataro >>>>>>> >, "Joel M. >>>>>>> Halpern" >, >>>>>>> Carlos Pignataro > >>>>>>>=20 >>>>>>>=20 >>>>>>> A new version of I-D, draft-merged-sfc-architecture-01.txt >>>>>>> has been successfully submitted by Carlos Pignataro and posted to >>>>>>> the IETF repository. >>>>>>>=20 >>>>>>> Name:draft-merged-sfc-architecture >>>>>>> Revision:01 >>>>>>> Title:Service Function Chaining (SFC) Architecture Document >>>>>>> date:2014-08-03 Group:Individual Submission >>>>>>> Pages:25 >>>>>>> URL: >>>>>>> http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-0= 1. >>>>>>> t >>>>>>> xt >>>>>>> Status: >>>>>>> https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ >>>>>>> Htmlized: >>>>>>> http://tools.ietf.org/html/draft-merged-sfc-architecture-01 >>>>>>> Diff: >>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-01 >>>>>>>=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, an= d >>>>>>> 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 >>>>>>> submission until the htmlized version and diff are available at >>>>>>> tools.ietf.org . >>>>>>>=20 >>>>>>> The IETF Secretariat >>>>>>>=20 >>>>>>> ------------------------------------------------------------------ >>>>>>> -- >>>>>>> - >>>>>>> - >>>>>>> -- This message is intended only for the designated recipient(s). >>>>>>> It may contain confidential or proprietary information. If you are >>>>>>> not the designated recipient, you may not review, copy or >>>>>>> distribute this message. If you have mistakenly received this >>>>>>> message, please notify the sender by a reply e-mail and delete this >> message. Thank you. >>>>>>>=20 >>>>>>> ------------------------------------------------------------------ >>>>>>> -- >>>>>>> - >>>>>>> - >>>>>>> -- >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>=20 >>>>>>=20 >>>>=20 >> ############################################################# >>>> ######## >>>>>> # ######################## This message is intended only for the >>>>>> designated recipient(s).It may contain confidential or proprietary >>>> information. >>>>>> If you are not the designated recipient, you may not review, copy >>>>>> or >>>> distribute this message. >>>>>> If you have mistakenly received this message, please notify the >>>>>> sender by a >>>> reply e-mail and delete this message. >>>>>> Thank you. >>>>>>=20 >>>>=20 >> ############################################################# >>>> ######## >>>>>> # >>>>>> ######################## >>>>>>=20 >>>>>=20 >>>>=20 >> ############################################################# >>>> ######### >>>>> ######################## This message is intended only for the >>>>> designated recipient(s).It may contain confidential or proprietary >> information. >>>>> If you are not the designated recipient, you may not review, copy or >>>>> distribute >>>> this message. >>>>> If you have mistakenly received this message, please notify the >>>>> sender by a >>>> reply e-mail and delete this message. >>>>> Thank you. >>>>>=20 >>>>=20 >> ############################################################# >>>> ######### >>>>> ######################## >>>>>=20 >>>>=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 From nobody Tue Aug 12 21:03: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 A21E31A6F13 for ; Tue, 12 Aug 2014 21:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.269 X-Spam-Level: X-Spam-Status: No, score=-4.269 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 87lboCEtaI2y for ; Tue, 12 Aug 2014 21:03:24 -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 A65EF1A028A for ; Tue, 12 Aug 2014 21:03:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLE26589; Wed, 13 Aug 2014 04:03:22 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 Aug 2014 05:03:21 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.204]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Wed, 13 Aug 2014 12:03:14 +0800 From: Xuxiaohu To: "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.txt Thread-Index: AQHPr2AigUDp9PUKd0KN/JsZgTmzp5vLI0nw///Rx4CAAAuOgIAAAJEAgAAKDYCAAADEgIABKf3w//+SYACAAIlyEIAA+7mAgACo6xA= Date: Wed, 13 Aug 2014 04:03:13 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A6D4B@NKGEML512-MBS.china.huawei.com> References: <20140803211558.28482.8328.idtracker@ietfa.amsl.com> <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> <53E8CD15.7010002@joelhalpern.com> <53E8D740.6090501@joelhalpern.com> <53E8E053.8050608@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A6840@NKGEML512-MBS.china.huawei.com> <53E97E56.7070508@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A6C12@NKGEML512-MBS.china.huawei.com> <6BA840C8-BF58-44D9-8840-048431FBBF1E@cisco.com> In-Reply-To: <6BA840C8-BF58-44D9-8840-048431FBBF1E@cisco.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/F_u_qYcqSD89ACswY-BWAXV1pvI Cc: Alla Goldner , "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.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, 13 Aug 2014 04:03:27 -0000 Hi Carlos, > -----Original Message----- > From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] > Sent: Wednesday, August 13, 2014 9:52 AM > To: Xuxiaohu > Cc: Joel M. Halpern; Alla Goldner; sfc@ietf.org > Subject: Re: [sfc] Fwd: New Version Notification for > draft-merged-sfc-architecture-01.txt >=20 > Hi, Xiaohu, >=20 > On Aug 12, 2014, at 9:37 PM, Xuxiaohu wrote: >=20 > > > > > >> -----Original Message----- > >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >> Sent: Tuesday, August 12, 2014 10:39 AM > >> To: Xuxiaohu; Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org > >> Subject: Re: [sfc] Fwd: New Version Notification for > >> draft-merged-sfc-architecture-01.txt > >> > >> If the encapsulation / decapsulation is part of the job of the SFF, > >> then there is no need to discuss or name the node that happens to > >> contain the SFF. Avoiding an extra term keeps things simpler. > > > > Agree. It seems fine to just call the node containing the SFF component= as an > SFF node. BTW, should the SFC proxy be looked as an optional functionalit= y of > the SFF component or an optional component of the SFF node? Of course, If > you want to deem the SFC proxy as a more-specialized SFF, it seems that F= igure > 3 should be updated accordingly and it seems better to call it as proxy-e= nabled > SFF or something like that. > > >=20 > Besides the name in Figure 3, we should look at the overall SFC Proxy tex= t: > http://tools.ietf.org/html/draft-merged-sfc-architecture-01#section-4.6 >=20 > Anything in this section that you think does not match what was discussed= about > the SFC Proxy? If the SFC proxy is deemed as a special SFF, it seems unnecessary to repeat= the functionalities of the SFF in the definition of SFC proxy. It just nee= ds to describe the "special" parts compared to the normal SFF, for instance= , strip the SFC header before sending the packet to the legacy SF while att= aching the SFC header to the packet returned from one local SF before perfo= rming a lookup for next SF or SFF. Best regards, Xiaohu > Thanks, >=20 > Carlos. >=20 > > Best regards, > > Xiaohu > > > >> Yours, > >> Joel > >> > >> On 8/11/14, 9:30 PM, Xuxiaohu wrote: > >>> Hi Joel, > >>> > >>>> -----Original Message----- > >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. > >>>> Halpern > >>>> Sent: Monday, August 11, 2014 11:25 PM > >>>> To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org > >>>> Subject: Re: [sfc] Fwd: New Version Notification for > >>>> draft-merged-sfc-architecture-01.txt > >>>> > >>>> Part of my problem is that the SFF has the information about what > >>>> the next > >> SFF. > >>>> (Even if the SFP allows only one next-SFF, it is the current SFF > >>>> who knows what that is. And if the decision is delegated, it is > >>>> delegated to the SFF. ) But if the Encaps is not part of the SFF, > >>>> then the SFF > >> has no way to express that decision. > >>>> Even an Ethernet link does not handle it. > >>>> > >>>> I need to check the text on SF Proxy, but I usually think of that > >>>> as a more-specialized SFF, not as something separate from the SFF. > >>> > >>> Fully agree with the above points. That's the reason why I had > >>> suggested giving the entity containing the SFF or even the SF proxy > >>> components a name (see > >>> http://www.ietf.org/mail-archive/web/sfc/current/msg02150.html) > >>> > >>> Best regards, > >>> Xiaohu > >>> > >>>> Yours, > >>>> Joel > >>>> > >>>> On 8/11/14, 11:22 AM, Alla Goldner wrote: > >>>>> Dear Joel, all, > >>>>> > >>>>> SFF and transport network connectivity point need to be co-located > >>>>> (this is not > >>>> mandatory but makes sense). > >>>>> This means that a simple L2 connectivity between SFF and the > >>>>> network > >>>> connectivity point can be used as this interface. > >>>>> That can be some VLAN or VXLAN or any other L2 protocol. This > >>>>> shouldn't > >>>> impose a big overhead on the SFF. > >>>>> > >>>>> Also, the same interface you are talking about should exist also > >>>>> between SFF > >>>> and SF proxy. > >>>>> So if we already need to solve it there, we can use it between SFF > >>>>> and network > >>>> component. > >>>>> > >>>>> I strongly believe we should decouple network transport functions > >>>>> from the > >>>> SFF and thus correct the section 4.3. > >>>>> > >>>>> Best regards, > >>>>> > >>>>> Alla Goldner > >>>>> Director of Mobile Technologies and Standards Allot Communications > >>>>> Tel > >>>>> +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 > >>>>> agoldner@allot.com www.allot.com > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >>>>> Sent: Monday, August 11, 2014 5:46 PM > >>>>> To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org > >>>>> Subject: Re: [sfc] Fwd: New Version Notification for > >>>>> draft-merged-sfc-architecture-01.txt > >>>>> > >>>>> That is how we had drawn the figure before. And described the > functions. > >>>>> The problem is that this creates an interface between a network > >>>>> component > >>>> and the SFF which can not exist visibly. There is no way I know of > >>>> to ship the packets between those two. > >>>>> > >>>>> So the Encaps / decaps has to be co-located with the SFF. > >>>>> This archtiecture tries not to get into the internal structure of > >>>>> the logical > >>>> components or to describe separately components that must be > co-located. > >>>> Some architectures do describe that. > >>>>> > >>>>> Yours, > >>>>> Joel > >>>>> > >>>>> On 8/11/14, 10:44 AM, Alla Goldner wrote: > >>>>>> Dear Joel, all, > >>>>>> > >>>>>> One of the motivations of SFC is be agnostic to the underlay > >>>>>> transport > >>>> network. > >>>>>> When you couple the SFF with the encapsulation/de-capsulation > >>>>>> process it > >>>> has to be aware of the network transport and it has to be capable > >>>> to support different types of transport protocols. > >>>>>> For me it doesn't make too much sense and it makes the SFF very > complex. > >>>>>> I think that a cleaner architecture is to have the SFF handle the > >>>>>> SFC tasks and > >>>> handle the SFC encapsulations (that is the metadata and SFC > >>>> headers) but leave the transport to be handled by the network layer > >>>> which can be any type of network. > >>>>>> > >>>>>> Best regards, > >>>>>> > >>>>>> > >>>>>> Alla Goldner > >>>>>> Director of Mobile Technologies and Standards Allot > >>>>>> Communications Tel > >>>>>> +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 > >>>>>> agoldner@allot.com www.allot.com > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >>>>>> Sent: Monday, August 11, 2014 5:03 PM > >>>>>> To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org > >>>>>> Subject: Re: [sfc] Fwd: New Version Notification for > >>>>>> draft-merged-sfc-architecture-01.txt > >>>>>> > >>>>>> I would say instead that we need to fix section 4.5, to make it > >>>>>> clear that the > >>>> SFF is responsible for the encaps decaps, while the network uses > >>>> the outer encapsulation for its forwarding. > >>>>>> > >>>>>> Yours, > >>>>>> Joel > >>>>>> > >>>>>> On 8/11/14, 4:56 AM, Alla Goldner wrote: > >>>>>>> Dear Carlos, Joel, all, > >>>>>>> > >>>>>>> Thanks for providing this merged architecture document! > >>>>>>> > >>>>>>> According to the model in figure 3 and section 4.5, the network > >>>>>>> (underlay) components are responsible for: > >>>>>>> > >>>>>>> * Finding the network path to reach the next SF (next SFF= ) in > >>>>>>> the SFP. > >>>>>>> > >>>>>>> * Encapsulate/de-capsulate the underlay network transport= . > >>>>>>> > >>>>>>> Section 4.3 (SFF) contradicts this and says the network > >>>>>>> encapsulation/de-capsulation is done by the SFF. > >>>>>>> > >>>>>>> I believe that the section 4.3 should be fixed in this regard. > >>>>>>> The reason is that network transport functions should not > >>>>>>> necessarily be coupled with the SFF. > >>>>>>> > >>>>>>> Best regards, > >>>>>>> > >>>>>>> *Alla Goldner* > >>>>>>> > >>>>>>> *Director of Mobile Technologies and Standards* > >>>>>>> > >>>>>>> Allot Communications > >>>>>>> > >>>>>>> Tel +972 9 7619251 > >>>>>>> > >>>>>>> Cell +972 54 2493985 > >>>>>>> > >>>>>>> Fax +972 9 7443626 > >>>>>>> > >>>>>>> *agoldner@allot.com **__* > >>>>>>> > >>>>>>> *www.allot.com* *__* > >>>>>>> > >>>>>>> *__* > >>>>>>> > >>>>>>> *291X55_signature (2)* > >>>>>>> > >>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Carlos > >>>>>>> Pignataro > >>>>>>> (cpignata) > >>>>>>> *Sent:* Monday, August 04, 2014 12:19 AM > >>>>>>> *To:* sfc@ietf.org > >>>>>>> *Subject:* [sfc] Fwd: New Version Notification for > >>>>>>> draft-merged-sfc-architecture-01.txt > >>>>>>> > >>>>>>> SFCers, > >>>>>>> > >>>>>>> After Toronto, Joel and I have been working on resolving the key > >>>>>>> open discussion items, and incorporating all the input and > >>>>>>> feedback received thus into this document as the vehicle for a > >>>>>>> single SFC Architecture item to progress. > >>>>>>> > >>>>>>> While we are still working on the document, we wanted to get a > >>>>>>> version out early to the WG to test the resolution to key open > >>>>>>> items, see what we might still be missing, and iterate. > >>>>>>> > >>>>>>> Please review and let us know. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> Carlos & Joel. > >>>>>>> > >>>>>>> Begin forwarded message: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> *From: * >>>>>>> > > >>>>>>> > >>>>>>> *Subject: New Version Notification for > >>>>>>> draft-merged-sfc-architecture-01.txt* > >>>>>>> > >>>>>>> *Date: *August 3, 2014 at 5:15:58 PM EDT > >>>>>>> > >>>>>>> *To: *Joel Halpern >>>>>>> >, Carlos Pignataro > >>>>>>> >, "Joel M. > >>>>>>> Halpern" >, > >>>>>>> Carlos Pignataro >>>>>>> > > >>>>>>> > >>>>>>> > >>>>>>> A new version of I-D, draft-merged-sfc-architecture-01.txt > >>>>>>> has been successfully submitted by Carlos Pignataro and posted > >>>>>>> to the IETF repository. > >>>>>>> > >>>>>>> Name:draft-merged-sfc-architecture > >>>>>>> Revision:01 > >>>>>>> Title:Service Function Chaining (SFC) Architecture Document > >>>>>>> date:2014-08-03 Group:Individual Submission > >>>>>>> Pages:25 > >>>>>>> URL: > >>>>>>> http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture= -01. > >>>>>>> t > >>>>>>> xt > >>>>>>> Status: > >>>>>>> https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ > >>>>>>> Htmlized: > >>>>>>> http://tools.ietf.org/html/draft-merged-sfc-architecture-01 > >>>>>>> Diff: > >>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-= 0 > >>>>>>> 1 > >>>>>>> > >>>>>>> Abstract: > >>>>>>> This document describes an architecture for the specificatio= n, > >>>>>>> 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.ietf.org . > >>>>>>> > >>>>>>> The IETF Secretariat > >>>>>>> > >>>>>>> ---------------------------------------------------------------- > >>>>>>> -- > >>>>>>> -- > >>>>>>> - > >>>>>>> - > >>>>>>> -- This message is intended only for the designated recipient(s). > >>>>>>> It may contain confidential or proprietary information. If you > >>>>>>> are not the designated recipient, you may not review, copy or > >>>>>>> distribute this message. If you have mistakenly received this > >>>>>>> message, please notify the sender by a reply e-mail and delete > >>>>>>> this > >> message. Thank you. > >>>>>>> > >>>>>>> ---------------------------------------------------------------- > >>>>>>> -- > >>>>>>> -- > >>>>>>> - > >>>>>>> - > >>>>>>> -- > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> sfc mailing list > >>>>>>> sfc@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>> > >>>>>> > >>>> > >> > ############################################################# > >>>> ######## > >>>>>> # ######################## This message is intended only for the > >>>>>> designated recipient(s).It may contain confidential or > >>>>>> proprietary > >>>> information. > >>>>>> If you are not the designated recipient, you may not review, copy > >>>>>> or > >>>> distribute this message. > >>>>>> If you have mistakenly received this message, please notify the > >>>>>> sender by a > >>>> reply e-mail and delete this message. > >>>>>> Thank you. > >>>>>> > >>>> > >> > ############################################################# > >>>> ######## > >>>>>> # > >>>>>> ######################## > >>>>>> > >>>>> > >>>> > >> > ############################################################# > >>>> ######### > >>>>> ######################## This message is intended only for the > >>>>> designated recipient(s).It may contain confidential or proprietary > >> information. > >>>>> If you are not the designated recipient, you may not review, copy > >>>>> or distribute > >>>> this message. > >>>>> If you have mistakenly received this message, please notify the > >>>>> sender by a > >>>> reply e-mail and delete this message. > >>>>> Thank you. > >>>>> > >>>> > >> > ############################################################# > >>>> ######### > >>>>> ######################## > >>>>> > >>>> > >>>> _______________________________________________ > >>>> 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 Wed Aug 13 02:04: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 6688D1A802C for ; Wed, 13 Aug 2014 02:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 bA7ORtgHsCe1 for ; Wed, 13 Aug 2014 02:04:30 -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 6D2421A8028 for ; Wed, 13 Aug 2014 02:04:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLE56043; Wed, 13 Aug 2014 09:04:27 +0000 (GMT) Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 Aug 2014 10:04:26 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.138]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Wed, 13 Aug 2014 17:04:23 +0800 From: Jiangyuanlong To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: SFC Problem Statement to IESG Thread-Index: AQHPs0HEU7eygBQELkiKupzFgFkUdpvOQmVw Date: Wed, 13 Aug 2014 09:04:22 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A7AFF31@szxema506-mbs.china.huawei.com> References: 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.66.76.118] Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A7AFF31szxema506mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Ic3WVmzzrLWfRNlvQRAo9ncWaig Subject: Re: [sfc] SFC Problem Statement to IESG 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, 13 Aug 2014 09:04:32 -0000 --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A7AFF31szxema506mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim and all, I had posted some comments on PS draft, and did not see any response from t= he authors: http://www.ietf.org/mail-archive/web/sfc/current/msg02201.html I would like to see them be resolved in the WG, or at least some reasons wh= y they could not be resolved. Thanks, Yuanlong From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Saturday, August 09, 2014 3:49 AM To: sfc@ietf.org Subject: [sfc] SFC Problem Statement to IESG Dear WG: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ has been = updated in accordance with the comments and suggestions made on the mailing= list and during our recent face-to-face meeting in Toronto. The next step = is to send the document to the IESG for review and approval. For the authors of this document, please confirm to the mailing list that a= ll relevant IPR you are aware of has been properly disclosed. If you are on the SFC WG mailing list but are not listed as an author or co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. Jim --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A7AFF31szxema506mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim and= all,

 = ;

I had post= ed some comments on PS draft, and did not see any response from the authors= :

http://www= .ietf.org/mail-archive/web/sfc/current/msg02201.html

 = ;

I would li= ke to see them be resolved in the WG, or at least some reasons why they cou= ld not be resolved.

 = ;

Thanks,

Yuanlong

 = ;

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Saturday, August 09, 2014 3:49 AM
To: sfc@ietf.org
Subject: [sfc] SFC Problem Statement to IESG

 

Dear WG:

 <= /o:p>

http://da= tatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ has been updated in accordance with the comments and suggestions made on the m= ailing list and during our recent face-to-face meeting in Toronto. The next= step is to send the document to the IESG for review and approval. 

 <= /o:p>

For the auth= ors of this document, please confirm to the mailing list that all relevant = IPR you are aware of has been properly disclosed. =

 

If you are o= n the SFC WG mailing list but are not listed as an author or contributor, t= hen please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

 <= /o:p>

Jim

 

 

 

 

 

--_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A7AFF31szxema506mbschi_-- From nobody Wed Aug 13 06:12: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 0F8AF1A006A for ; Wed, 13 Aug 2014 06:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, 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 ZyayN2aEFhdB for ; Wed, 13 Aug 2014 06:11:59 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9B84B1A0097 for ; Wed, 13 Aug 2014 06:11:58 -0700 (PDT) Received: from [10.74.85.99] (unknown [129.33.193.254]) by lucidvision.com (Postfix) with ESMTP id 8FDE42854226; Wed, 13 Aug 2014 09:11:56 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_657225D4-12D3-49C2-829D-21CC9471F560"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Wed, 13 Aug 2014 09:11:55 -0400 Message-Id: <825D44BE-6C79-4026-9054-8B6D0CD2E3D4@lucidvision.com> References: To: sfc , jiangyuanlong@huawei.com X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ESgu89Nk2a3HpY0AndHjvWMSAP0 Cc: Thomas Narten , Guichard Jim , "Paul \(paulq\) Quinn" Subject: Re: [sfc] SFC Problem Statement to IESG 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, 13 Aug 2014 13:12:04 -0000 --Apple-Mail=_657225D4-12D3-49C2-829D-21CC9471F560 Content-Type: multipart/alternative; boundary="Apple-Mail=_ED159E26-FA7B-44E7-B788-011607068A22" --Apple-Mail=_ED159E26-FA7B-44E7-B788-011607068A22 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii =09 Apologies for not replying to the original. I seem to have = deleted it so I will respond as a top post. Yuanlong, The document editors did review and consider your comments; = however, there was no other input from the mailing list for those = specific changes. Given the late timing of the comments and where we = were with the document, we did not feel that making such non-editorial = changes was appropriate without additional WG desire for such changes. = We did however, incorporate all of your editorial suggestions. --Tom > From: Jiangyuanlong > Date: Wednesday, August 13, 2014 at 5:04 AM > To: Jim Guichard , "sfc@ietf.org" > Subject: Re: [sfc] SFC Problem Statement to IESG >=20 > Hi Jim and all, > =20 > I had posted some comments on PS draft, and did not see any response = from the authors: > http://www.ietf.org/mail-archive/web/sfc/current/msg02201.html > =20 > I would like to see them be resolved in the WG, or at least some = reasons why they could not be resolved. > =20 > Thanks, > Yuanlong > =20 > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard = (jguichar) > Sent: Saturday, August 09, 2014 3:49 AM > To: sfc@ietf.org > Subject: [sfc] SFC Problem Statement to IESG > =20 > Dear WG: > =20 > http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ has = been updated in accordance with the comments and suggestions made on the = mailing list and during our recent face-to-face meeting in Toronto. The = next step is to send the document to the IESG for review and approval.=20= > =20 > For the authors of this document, please confirm to the mailing list = that all relevant IPR you are aware of has been properly disclosed.=20 > =20 > If you are on the SFC WG mailing list but are not listed as an author = or contributor, then please explicitly respond only if you are aware of = any IPR that has not yet been disclosed in conformance with IETF rules. > =20 > Jim > =20 > =20 > =20 > =20 > =20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail=_ED159E26-FA7B-44E7-B788-011607068A22 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii =
= Apologies for not replying to the original. I seem to have = deleted it so I will respond as a top = post.


= Yuanlong,

The document editors did review = and consider your comments; however, there was no other input from the = mailing list for those specific changes. Given the late timing of the = comments and where we were with the document, we did not feel that = making such non-editorial changes was appropriate without additional WG = desire for such changes.  We did however, incorporate all of your = editorial suggestions.

= --Tom




From: Jiangyuanlong <jiangyuanlong@huawei.com>
Date: Wednesday, August = 13, 2014 at 5:04 AM
To: Jim Guichard <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] SFC = Problem Statement to IESG

Hi Jim and all,
 
I had posted some comments on PS = draft, and did not see any response from the = authors:
 
I would like = to see them be resolved in the WG, or at least some reasons why they = could not be resolved.
 
Thanks,
Yuanlong
 
From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard = (jguichar)
Sent: Saturday, August 09, 2014 = 3:49 AM
To: sfc@ietf.org
Subject: [sfc] SFC Problem Statement = to IESG
 
Dear WG:
 
http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-stateme= nt/ has been updated in accordance with the comments and = suggestions made on the mailing list and during our recent face-to-face = meeting in Toronto. The next step is to send the document to the IESG = for review and approval. 
 
For the authors of this document, = please confirm to the mailing list that all relevant IPR you are aware = of has been properly disclosed. 
 
If you are on the SFC WG mailing list = but are not listed as an author or contributor, then please explicitly = respond only if you are aware of any IPR that has not yet been disclosed = in conformance with IETF rules.
 
Jim
 
 
 
 
 
__= _____________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

= --Apple-Mail=_ED159E26-FA7B-44E7-B788-011607068A22-- --Apple-Mail=_657225D4-12D3-49C2-829D-21CC9471F560 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 iQIcBAEBCgAGBQJT62QbAAoJEPcO+I7eiUJZ580QAKZ0YpDkyLL/AcLranfdwE3z ewjSrAWkwPULBml44ZxR40Eh+t+9xjdZFfr9wB56pv3z8/KcubCBrkA7chFflsIw ArPsf7tseQTE/EyA9NpVA9kdgW2FTwMiwkUf44ZOLg+L5rxh2D02C+bGMFwPv12w 3Buuj6TTeE6xDd/x5SanfPaOZzMQM+uzPKv4B+PFj/T2l6KjImnCH2cpsXybOSdJ EdmZYPUHdZUbyXgE5sQD79f8OLy+NcE0U5gS1Pn+UAtSr4UNpTPsdyzJNQ0sPQOa hh7O6NQ2gj8HkdQKkvLiUm+/JatXGZIzfFhjb7Ox8Z6N+j9/kkjVaNhBoR+E891g faVfnSCSjvQS/xhwQ3UGFcjMb4R+7p7fY6QUEpOrHHovl0K49GWkntl45jmNgZoc xXp/DvO6eF5VASGxLH1ejTV4E1tADEab5o/SZ7qAUsrOLRlqER1xVJ84iSa067U2 yNfWnKUKPq4aG5sf+xIGhMVaPu2b1lEYEAkPzpJW+ZzMZ6+pbdxflBF+5p8+XOr/ hUpaRG+hN7zPbE3NSbGS3Dfij1XEQFAliiZ45gWbRbllgY7ALdTFOwE87v8RzDHR N5cSm2ukEXuECQnZu1MQ+/9PtTjF2QpE4+y9foQsTleBRswNYbBj0fwpdLCR8I3d 10IuJKMe1Au47h5kV9mg =pX73 -----END PGP SIGNATURE----- --Apple-Mail=_657225D4-12D3-49C2-829D-21CC9471F560-- From nobody Wed Aug 13 06:48: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 967191A0202 for ; Wed, 13 Aug 2014 06:48:18 -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 j_1i_pfHoORn for ; Wed, 13 Aug 2014 06:48:15 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE9621A01F9 for ; Wed, 13 Aug 2014 06:48:14 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id i8so4198975qcq.27 for ; Wed, 13 Aug 2014 06:48:13 -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=bB0AKxcD+c9TZsdXVAlgRvikz9H9vQgPDWVXyuj3wS0=; b=k5n+lA3i9Q/KiOgkzmR3ghmPAJLsiAYAPXy96/sezTJMfVQqKHBHWazChjXLhs7aDL iw/iUR4iRucH2faptcTu4davDt69jTOxdSS5Kw3I56ANGGg/HnFn6cpQTn3YZT25v3wW kGY2DxdM4MPYlSwYItV4OXg9jJU9fj+m19sX5rKMcrl6JbDUfzdykdvytGC+aLFyncPa tWWl8r8t2B1iM43s0lcYlJOgl6RFUarIBbklvjyst/Hg31B0IOD5kG6ed/sY9yLcqje4 aS/lQdjgeACRQYjJoArqob9l21qt8WDsiXh3tQUnyQBNCTVT7BLFrBLlKhRD8RcCF2sx L1Ug== X-Received: by 10.140.28.6 with SMTP id 6mr6656095qgy.90.1407937693847; Wed, 13 Aug 2014 06:48:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.166 with HTTP; Wed, 13 Aug 2014 06:47:53 -0700 (PDT) In-Reply-To: <5F8C4A2F-3C60-459D-92F7-31EA1DA9E469@cisco.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A4805@NKGEML512-MBS.china.huawei.com> <57B2ECF6-8DB4-4E23-BB14-E030EB74E09C@alcatel-lucent.com> <2691CE0099834E4A9C5044EEC662BB9D453CBFBE@dfweml701-chm.china.huawei.com> <5F8C4A2F-3C60-459D-92F7-31EA1DA9E469@cisco.com> From: "Andrew G. Malis" Date: Wed, 13 Aug 2014 09:47:53 -0400 Message-ID: To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=001a113980761b96a30500830aea Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/B9mhnLUqTIYqNSbgsqCfN5b9lHA Cc: Xiaohu Xu , "Dolganow, Andrew \(Andrew\)" , "sfc@ietf.org" , Lucy yong , "Joel M. Halpern" Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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, 13 Aug 2014 13:48:18 -0000 --001a113980761b96a30500830aea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Carlos, I see your point, but there's also been discussion of cases where only the metadata is required. In that case, you woud either be carrying a null SFP ID along with the metadata, or just the metadata. It seems more efficient to me to just carry the metadata, but if you want to insist that there's always an SPF ID, then we need to make sure that it can be a null ID. Cheers, Andy On Tue, Aug 12, 2014 at 9:51 PM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Hi, Andy, Lucy, > > Flexibility is certainly good as long as it does not get in the way of > interoperability. This architecture drives a balance and tradeoff in whic= h > options are maximized while having interoperability as the goal. > > From a technical perspective, the SFC Encapsulation specifies the > Service Function Path to allow for end-to-end SFPs and interoperable > implementations. One of the key principles of this architecture is that t= he > SFC Encapsulation is transport-independent. The text is flexible such tha= t > any transport may be used to carry the SFC encapsulation. However, two SF= s > part of an SFP that are not adjacent in the services topology can have > different transport encapsulations but need the SFC-encapsulation (minimu= m > invariant encap) to specify the SPF. This is within the service topology, > which again is independent from the underlay topology as an architectural > principle. Please note that the use of the SFC encapsulation to specify t= he > SFP and the SFFs and SFs use of this is articulated throughout the > architecture. This architecture also allows for flexibility in bringing > SFC-unaware SFs by proxy as the one gateway, to provide backwards > compatibility, but attempts to carry forward interoperability. > Consequently, for "SFC Aware" chains, the architectural choice that follo= ws > the principles is to carry the SFP id. It is (also) to convey shared > context (when demanded by the use case) using the SFC-encapsulation for > similar reasons. As a WG, I believe we should first strive for a > single service-level data plane encapsulation as per the current WG chart= er > and based on that provide the most optimal placement of functions and > identifiers. > > Note also that I was pointing to the charter because I believe these > points were discussed already to get to the current charter text. > > Best, > > Carlos. > > On Aug 11, 2014, at 10:47 AM, Lucy yong wrote: > > I agree Andy=E2=80=99s point. > > Lucy > > *From:* sfc [mailto:sfc-bounces@ietf.org ] *On > Behalf Of *Andrew G. Malis > *Sent:* Friday, August 08, 2014 4:47 PM > *To:* Carlos Pignataro (cpignata) > *Cc:* Xuxiaohu; Dolganow, Andrew (Andrew); sfc@ietf.org; Joel M. Halpern > *Subject:* Re: [sfc] Definition of SFC Encapsulation in > draft-merged-sfc-architecture-01.txt > > Carlos, > > I agree that the charter requires the encapsulation to support each of > the bullet items, but there's no requirement that every encapsulated pack= et > will need all of the bullet items supported, so I'm trying to keep the te= xt > as flexible as possible to not preclude possible solutions. > > Cheers, > Andy > > > On Fri, Aug 8, 2014 at 11:09 AM, Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > Hi, Andrew, > > > On Aug 8, 2014, at 8:53 AM, Dolganow, Andrew (Andrew) < > andrew.dolganow@alcatel-lucent.com> wrote: > > > I agree that we should have stronger separation of two functions: SFP > and metadata. > > > > How about small edit to what Andy proposed: > > > > SFC Encapsulation: A data plane encapsulation that encodes either one > or both of > > - the SFP > > - metadata (data plane context information). > Looking at http://datatracker.ietf.org/wg/sfc/charter/, there is no > "either one or both of". In fact, looking at the history of the charter > text, the text for SFC Encapsulation is a bullet list form of a longer > sentence that includes "and" only (see 00-09). > > Thanks, > > Carlos. > > > >> The SFP Encapsulation is used by the SFC-aware functions, such as the > SFF and SFC-aware SFs, and is not used for network packet forwarding. > > > > > > Andrew > > > > Sent from my iPhone > > > >> On Aug 7, 2014, at 9:13 PM, "Xuxiaohu" wrote: > >> > >> I fully agree with Andy=E2=80=99s point that not every usage of the > encapsulation will need both the SFP identification and the metadata. It= =E2=80=99s > better that the SFC encapsulation could be flexibly used for carrying SFP > identification, metadata or both. Otherwise, it seems that those SFC > approaches which don=E2=80=99t use the SFC encapsulation for SFC selectio= n would > have to separately define the way of carrying metadata. > >> > >> Best regards, > >> Xiaohu > >> > >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Andrew G. Malis > >> Sent: Thursday, August 07, 2014 9:06 PM > >> To: Carlos Pignataro (cpignata) > >> Cc: Joel M. Halpern; sfc@ietf.org > >> Subject: Re: [sfc] Definition of SFC Encapsulation in > draft-merged-sfc-architecture-01.txt > >> > >> Carlos, > >> > >> When I re-read the definition, it seemed to me to be more of a string > of thoughts than a concise definition, which is why I was trying to tight= en > it up. A definition is meant to be a short summary for quick reference, > while the discussion in 4.1 goes into the more formal details. Otherwise= , > you would just repeat the entire section 4.1 in section 1.3. This is why > it doesn't need to be in separate sentences. The "and/or" is because not > every usage of the encapsulation will need both the SFP identification an= d > the metadata, so the definition needs to concisely convey that. > >> > >> Cheers, > >> Andy > >> > >> On Thu, Aug 7, 2014 at 8:51 AM, Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > >> Thank you for going back and checking, Andy! > >> > >> Which specific part of the current definition do you believe is loose > enough to need tightening? > >> > >> I believe that your new proposal falls shorter than the existing text > in a few areas: > >> =E2=80=A2 First, it combines two different functions (SFP identificati= on and > metadata/context information) into a single sentence. This opposes the > change we just made based on your preference in Section 4.1, which breaks > the two functions into two sentences, for reader clarity. While longer, > it's simpler. > >> =E2=80=A2 Second, it introduces an extraneous "and/or" that would chan= ge the > meaning, and negate the "at a minimum" existing bit. That would not be > simplifying. > >> =E2=80=A2 Third, there is no third but three bullets look better :-) > >> > >> Net-net, the original text, even when longer in character count, seems > more clear and simpler to the reader (because of the separated sentences)= , > IMHO. > >> > >> Thanks, > >> > >> Carlos. > >> > >> On Aug 7, 2014, at 8:20 AM, Andrew G. Malis wrote: > >> > >> > >> Carlos and Joel, > >> > >> In light of the previous discussions, I went back and re-read this > current definition of SFC Encapsulation in the text (section 1.3): > >> > >> SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP > >> identification, and is used by the SFC-aware functions, such as > >> the SFF and SFC-aware SFs. The SFC Encapsulation is not used > >> for network packet forwarding. In addition to SFP > >> identification, the SFC encapsulation carries dataplane context > >> information, also referred to as metadata. > >> > >> I think this could be tightened up to make simpler for the reader: > >> > >> SFC Encapsulation: A data plane encapsulation that identifies the SFP > and/or provides metadata (data plane context information). The SFP > Encapsulation is used by the SFC-aware functions, such as the SFF and > SFC-aware SFs, and is not used for network packet forwarding. > >> > >> Thanks, > >> Andy > >> > >> > >> > >> _______________________________________________ > >> sfc mailing list > >> sfc@ietf.org > >> https://www.ietf.org/mailman/listinfo/sfc > > > --001a113980761b96a30500830aea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Carlos,

I see your point, but there'= ;s also been discussion of cases where only the metadata is required. In th= at case, you woud either be carrying a null SFP ID along with the metadata,= or just the metadata. It seems more efficient to me to just carry the meta= data, but if you want to insist that there's always an SPF ID, then we = need to make sure that it can be a null ID.

Cheers,
Andy


On Tue, Aug 12, 2014 at 9:51 PM, C= arlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
Hi, Andy, Lucy,

Flexibility is certainly good as long as it does not get in the way of= interoperability. This architecture drives a balance and tradeoff in which= options are maximized while having interoperability as the goal.

From a technical perspective, the SFC Encapsulation specifies the Serv= ice Function Path to allow for end-to-end SFPs and interoperable implementa= tions. One of the key principles of this architecture is that the SFC Encap= sulation is transport-independent. The text is flexible such that any transport may be used to carry the SFC = encapsulation. However, two SFs part of an SFP that are not adjacent in the= services topology can have different transport encapsulations but need the= SFC-encapsulation (minimum invariant encap) to specify the SPF. This is within the service topology, which agai= n is independent from the underlay topology as an architectural principle. = Please note that the use of the SFC encapsulation to specify the SFP and th= e SFFs and SFs use of this is articulated throughout the architecture. This architecture also allows for flexibility= in bringing SFC-unaware SFs by proxy as the one gateway, to provide backwa= rds compatibility, but attempts to carry forward interoperability. Conseque= ntly, for "SFC Aware" chains, the architectural choice that follows the principles is to carry the SFP id. I= t is (also) to convey shared context (when demanded by the use case) using = the SFC-encapsulation for similar reasons. As a WG, I believe we should fir= st strive for a single=C2=A0service-level data plane encapsulation as per the current WG charter and based on that p= rovide the most optimal placement of functions and identifiers.

Note also that I was pointing to the charter because I believe these p= oints were discussed already to get to the current charter text.

Best,

Carlos.

On Aug 11, 2014, at 10:47 AM, Lucy yong <lucy.yong@huawei.com> wrote:

I agree Andy=E2=80=99s point.
=C2=A0
Lucy
=C2=A0
=C2=A0
Carlos,
=C2=A0
I agree that the charter requires the encapsulation to support each of the = bullet items, but there's no requirement that every encapsulated packet= will need all of the bullet items supported, so I'm trying to keep the= text as flexible as possible to not preclude possible solutions.
=C2=A0
Cheers,
Andy

=C2=A0

On Fri, Aug 8, 2014 at 11:09 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
Hi, Andrew,


On Aug 8, 2014, at 8:53 AM, Dolganow, Andrew (Andrew) <andrew.dolganow@alcatel-lucent.com> wro= te:

> I agree that we should have stronger separation of two functions: SFP = and metadata.
>
> How about small edit to what Andy proposed:
>
> SFC Encapsulation: =C2=A0A data plane encapsulation that encodes eithe= r one or both of
> - the SFP
> - metadata (data plane context information).

Looking at=C2=A0http://datatracker.ietf.org/wg/sfc/charter/, there is no "either= one or both of". In fact, looking at the history of the charter text, the text for SFC Enca= psulation is a bullet list form of a longer sentence that includes "an= d" only (see 00-09).

Thanks,

Carlos.


>> The SFP Encapsulation is used by the SFC-aware functions, such as = the SFF and SFC-aware SFs, and is not used for network packet forwarding. >
>
> Andrew
>
> Sent from my iPhone
>
>> On Aug 7, 2014, at 9:13 PM, "Xuxiaohu" <xuxiaohu@huawei.com> wrote:
>>
>> I fully agree with Andy=E2=80=99s point that not every usage of th= e encapsulation will need both the SFP identification and the metadata. It= =E2=80=99s better that the SFC encapsulation could be flexibly used for car= rying SFP identification, metadata or both. Otherwise, it seems that those SFC approaches which don=E2=80=99t use the SFC encapsu= lation for SFC selection would have to separately define the way of carryin= g metadata.
>>
>> Best regards,
>> Xiaohu
>>
>> From: sfc [mailto:sfc-bounces@ietf= .org] On Behalf Of Andrew G. Malis
>> Sent: Thursday, August 07, 2014 9:06 PM
>> To: Carlos Pignataro (cpignata)
>> Cc: Joel M. Halpern;=C2=A0sfc= @ietf.org
>> Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged= -sfc-architecture-01.txt
>>
>> Carlos,
>>
>> When I re-read the definition, it seemed to me to be more of a str= ing of thoughts than a concise definition, which is why I was trying to tig= hten it up. A definition is meant to be a short summary for quick reference= , while the discussion in 4.1 goes into the more formal details. =C2=A0Otherwise, you would just repeat the entire= section 4.1 in section 1.3. =C2=A0This is why it doesn't need to be in= separate sentences. The "and/or" is because not every usage of t= he encapsulation will need both the SFP identification and the metadata, so the definition needs to concisely convey that.
>>
>> Cheers,
>> Andy
>>
>> On Thu, Aug 7, 2014 at 8:51 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
>> Thank you for going back and checking, Andy!
>>
>> Which specific part of the current definition do you believe is lo= ose enough to need tightening?
>>
>> I believe that your new proposal falls shorter than the existing t= ext in a few areas:
>> =E2=80=A2 First, it combines two different functions (SFP identifi= cation and metadata/context information) into a single sentence. This oppos= es the change we just made based on your preference in Section 4.1, which b= reaks the two functions into two sentences, for reader clarity. While longer, it's simpler.
>> =E2=80=A2 Second, it introduces an extraneous "and/or" t= hat would change the meaning, and negate the "at a minimum" exist= ing bit. That would not be simplifying.
>> =E2=80=A2 Third, there is no third but three bullets look better := -)
>>
>> Net-net, the original text, even when longer in character count, s= eems more clear and simpler to the reader (because of the separated sentenc= es), IMHO.
>>
>> Thanks,
>>
>> Carlos.
>>
>> On Aug 7, 2014, at 8:20 AM, Andrew G. Malis <agmalis@gmail.com> wrote:
>>
>>
>> Carlos and Joel,
>>
>> In light of the previous discussions, I went back and re-read this= current definition of SFC Encapsulation in the text (section 1.3):
>>
>> =C2=A0 SFC Encapsulation: =C2=A0The SFC Encapsulation provides at = a minimum SFP
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0identification, and is used by the SFC-= aware functions, such as
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0the SFF and SFC-aware SFs. =C2=A0The SF= C Encapsulation is not used
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0for network packet forwarding. =C2=A0In= addition to SFP
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0identification, the SFC encapsulation c= arries dataplane context
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0information, also referred to as metada= ta.
>>
>> I think this could be tightened up to make simpler for the reader:=
>>
>> SFC Encapsulation: =C2=A0A data plane encapsulation that identifie= s the SFP and/or provides metadata (data plane context information). The SF= P Encapsulation is used by the SFC-aware functions, such as the SFF and SFC= -aware SFs, and is not used for network packet forwarding.
>>
>> Thanks,
>> Andy
>>
>>
>>
>> _______________________________________________
>> sfc mailing list
>>=C2=A0sfc@ietf.org
>>=C2=A0ht= tps://www.ietf.org/mailman/listinfo/sfc



--001a113980761b96a30500830aea-- From nobody Wed Aug 13 10:38: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 E1BBA1A0185 for ; Wed, 13 Aug 2014 10:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 hqwCxAc21bxQ for ; Wed, 13 Aug 2014 10:38:00 -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 C19F11A00CD for ; Wed, 13 Aug 2014 10:37:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIF29069; Wed, 13 Aug 2014 17:37:58 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.212.94.47) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 Aug 2014 18:37:57 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.137]) by SJCEML701-CHM.china.huawei.com ([169.254.3.190]) with mapi id 14.03.0158.001; Wed, 13 Aug 2014 10:37:43 -0700 From: Cathy Zhang To: "Andrew G. Malis" , "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt Thread-Index: AQHPsj5aR2ay6wbnkk6WcLRNRKcBZZvFkYqAgADLN4CAAMN6gIAAJg6AgABvCICABEHTgIACS/2AgADIFoD//8QrsA== Date: Wed, 13 Aug 2014 17:37:42 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A4805@NKGEML512-MBS.china.huawei.com> <57B2ECF6-8DB4-4E23-BB14-E030EB74E09C@alcatel-lucent.com> <2691CE0099834E4A9C5044EEC662BB9D453CBFBE@dfweml701-chm.china.huawei.com> <5F8C4A2F-3C60-459D-92F7-31EA1DA9E469@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.145.72] Content-Type: multipart/alternative; boundary="_000_A2C96F6779E6A041BC7023CC207FC99418F74C63SJCEML702CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/bbv25LP1_7lxtxpG0vcFgg0JVAg Cc: Xuxiaohu , "Dolganow, Andrew \(Andrew\)" , Lucy yong , "sfc@ietf.org" , "Joel M. Halpern" Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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, 13 Aug 2014 17:38:09 -0000 --_000_A2C96F6779E6A041BC7023CC207FC99418F74C63SJCEML702CHMchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIEFuZHkgdGhhdCB0aGUgY2FzZSBvZiBjYXJyeWluZyBvbmx5IG1ldGFkYXRh IG5lZWRzIHRvIGJlIGNvbnNpZGVyZWQuIEFjdHVhbGx5IG91ciBzZXJ2aWNlIGNoYWluIGhlYWRl ciBkcmFmdCBhbHJlYWR5IHRha2VzIHRoaXMgaW50byBjb25zaWRlcmF0aW9uLiBUaGUgcHJvcG9z YWwgaW4gdGhlIHNlcnZpY2UgY2hhaW4gaGVhZGVyIGRyYWZ0IGlzIHRvIGNhcnJ5IG1ldGFkYXRh IGFuZCBzZXQgU1BGIElEIHRvIGJlIE5VTEwuIEhlcmUgaXMgYSBzbmlwIG9mIHRoZSBkcmFmdDoN Cg0KICAgVGhlIFNDSCBtYXkgYmUgdXNlZCB0byBjYXJyeTogKDEpIGJvdGggU0ZDIHBhdGggc3Rl ZXJpbmcgaW5mb3JtYXRpb24NCiAgIGFuZCBtZXRhZGF0YTsgKDIpIG9ubHkgU0ZDIHBhdGggc3Rl ZXJpbmcgaW5mb3JtYXRpb24sIGluIHdoaWNoIGNhc2UNCiAgIHRoZSBNZXRhZGF0YSBMZW5ndGgg ZmllbGQgc2hhbGwgYmUgc2V0IHRvIHplcm87IG9yICgzKSBvbmx5IG1ldGFkYXRhLA0KICAgaW4g d2hpY2ggY2FzZSB0aGUgUGF0aCBJZGVudGlmaWVyIGFuZCBTRiBJbmRleCBmaWVsZHMgc2hhbGwg YmUgc2V0IHRvDQogICB6ZXJvIGZvciB0cmFuc21pdCBhbmQgaWdub3JlZCB1cG9uIHJlY2VpcHQu DQoNClRoYW5rcywNCkNhdGh5DQoNCg0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmRyZXcgRy4gTWFsaXMNClNlbnQ6IFdlZG5lc2RheSwgQXVn dXN0IDEzLCAyMDE0IDY6NDggQU0NClRvOiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkNCkNj OiBYdXhpYW9odTsgRG9sZ2Fub3csIEFuZHJldyAoQW5kcmV3KTsgc2ZjQGlldGYub3JnOyBMdWN5 IHlvbmc7IEpvZWwgTS4gSGFscGVybg0KU3ViamVjdDogUmU6IFtzZmNdIERlZmluaXRpb24gb2Yg U0ZDIEVuY2Fwc3VsYXRpb24gaW4gZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUtMDEudHh0 DQoNCkNhcmxvcywNCg0KSSBzZWUgeW91ciBwb2ludCwgYnV0IHRoZXJlJ3MgYWxzbyBiZWVuIGRp c2N1c3Npb24gb2YgY2FzZXMgd2hlcmUgb25seSB0aGUgbWV0YWRhdGEgaXMgcmVxdWlyZWQuIElu IHRoYXQgY2FzZSwgeW91IHdvdWQgZWl0aGVyIGJlIGNhcnJ5aW5nIGEgbnVsbCBTRlAgSUQgYWxv bmcgd2l0aCB0aGUgbWV0YWRhdGEsIG9yIGp1c3QgdGhlIG1ldGFkYXRhLiBJdCBzZWVtcyBtb3Jl IGVmZmljaWVudCB0byBtZSB0byBqdXN0IGNhcnJ5IHRoZSBtZXRhZGF0YSwgYnV0IGlmIHlvdSB3 YW50IHRvIGluc2lzdCB0aGF0IHRoZXJlJ3MgYWx3YXlzIGFuIFNQRiBJRCwgdGhlbiB3ZSBuZWVk IHRvIG1ha2Ugc3VyZSB0aGF0IGl0IGNhbiBiZSBhIG51bGwgSUQuDQoNCkNoZWVycywNCkFuZHkN Cg0KT24gVHVlLCBBdWcgMTIsIDIwMTQgYXQgOTo1MSBQTSwgQ2FybG9zIFBpZ25hdGFybyAoY3Bp Z25hdGEpIDxjcGlnbmF0YUBjaXNjby5jb208bWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbT4+IHdy b3RlOg0KSGksIEFuZHksIEx1Y3ksDQoNCkZsZXhpYmlsaXR5IGlzIGNlcnRhaW5seSBnb29kIGFz IGxvbmcgYXMgaXQgZG9lcyBub3QgZ2V0IGluIHRoZSB3YXkgb2YgaW50ZXJvcGVyYWJpbGl0eS4g VGhpcyBhcmNoaXRlY3R1cmUgZHJpdmVzIGEgYmFsYW5jZSBhbmQgdHJhZGVvZmYgaW4gd2hpY2gg b3B0aW9ucyBhcmUgbWF4aW1pemVkIHdoaWxlIGhhdmluZyBpbnRlcm9wZXJhYmlsaXR5IGFzIHRo ZSBnb2FsLg0KDQpGcm9tIGEgdGVjaG5pY2FsIHBlcnNwZWN0aXZlLCB0aGUgU0ZDIEVuY2Fwc3Vs YXRpb24gc3BlY2lmaWVzIHRoZSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGggdG8gYWxsb3cgZm9yIGVu ZC10by1lbmQgU0ZQcyBhbmQgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMuIE9uZSBvZiB0 aGUga2V5IHByaW5jaXBsZXMgb2YgdGhpcyBhcmNoaXRlY3R1cmUgaXMgdGhhdCB0aGUgU0ZDIEVu Y2Fwc3VsYXRpb24gaXMgdHJhbnNwb3J0LWluZGVwZW5kZW50LiBUaGUgdGV4dCBpcyBmbGV4aWJs ZSBzdWNoIHRoYXQgYW55IHRyYW5zcG9ydCBtYXkgYmUgdXNlZCB0byBjYXJyeSB0aGUgU0ZDIGVu Y2Fwc3VsYXRpb24uIEhvd2V2ZXIsIHR3byBTRnMgcGFydCBvZiBhbiBTRlAgdGhhdCBhcmUgbm90 IGFkamFjZW50IGluIHRoZSBzZXJ2aWNlcyB0b3BvbG9neSBjYW4gaGF2ZSBkaWZmZXJlbnQgdHJh bnNwb3J0IGVuY2Fwc3VsYXRpb25zIGJ1dCBuZWVkIHRoZSBTRkMtZW5jYXBzdWxhdGlvbiAobWlu aW11bSBpbnZhcmlhbnQgZW5jYXApIHRvIHNwZWNpZnkgdGhlIFNQRi4gVGhpcyBpcyB3aXRoaW4g dGhlIHNlcnZpY2UgdG9wb2xvZ3ksIHdoaWNoIGFnYWluIGlzIGluZGVwZW5kZW50IGZyb20gdGhl IHVuZGVybGF5IHRvcG9sb2d5IGFzIGFuIGFyY2hpdGVjdHVyYWwgcHJpbmNpcGxlLiBQbGVhc2Ug bm90ZSB0aGF0IHRoZSB1c2Ugb2YgdGhlIFNGQyBlbmNhcHN1bGF0aW9uIHRvIHNwZWNpZnkgdGhl IFNGUCBhbmQgdGhlIFNGRnMgYW5kIFNGcyB1c2Ugb2YgdGhpcyBpcyBhcnRpY3VsYXRlZCB0aHJv dWdob3V0IHRoZSBhcmNoaXRlY3R1cmUuIFRoaXMgYXJjaGl0ZWN0dXJlIGFsc28gYWxsb3dzIGZv ciBmbGV4aWJpbGl0eSBpbiBicmluZ2luZyBTRkMtdW5hd2FyZSBTRnMgYnkgcHJveHkgYXMgdGhl IG9uZSBnYXRld2F5LCB0byBwcm92aWRlIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LCBidXQgYXR0 ZW1wdHMgdG8gY2FycnkgZm9yd2FyZCBpbnRlcm9wZXJhYmlsaXR5LiBDb25zZXF1ZW50bHksIGZv ciAiU0ZDIEF3YXJlIiBjaGFpbnMsIHRoZSBhcmNoaXRlY3R1cmFsIGNob2ljZSB0aGF0IGZvbGxv d3MgdGhlIHByaW5jaXBsZXMgaXMgdG8gY2FycnkgdGhlIFNGUCBpZC4gSXQgaXMgKGFsc28pIHRv IGNvbnZleSBzaGFyZWQgY29udGV4dCAod2hlbiBkZW1hbmRlZCBieSB0aGUgdXNlIGNhc2UpIHVz aW5nIHRoZSBTRkMtZW5jYXBzdWxhdGlvbiBmb3Igc2ltaWxhciByZWFzb25zLiBBcyBhIFdHLCBJ IGJlbGlldmUgd2Ugc2hvdWxkIGZpcnN0IHN0cml2ZSBmb3IgYSBzaW5nbGUgc2VydmljZS1sZXZl bCBkYXRhIHBsYW5lIGVuY2Fwc3VsYXRpb24gYXMgcGVyIHRoZSBjdXJyZW50IFdHIGNoYXJ0ZXIg YW5kIGJhc2VkIG9uIHRoYXQgcHJvdmlkZSB0aGUgbW9zdCBvcHRpbWFsIHBsYWNlbWVudCBvZiBm dW5jdGlvbnMgYW5kIGlkZW50aWZpZXJzLg0KDQpOb3RlIGFsc28gdGhhdCBJIHdhcyBwb2ludGlu ZyB0byB0aGUgY2hhcnRlciBiZWNhdXNlIEkgYmVsaWV2ZSB0aGVzZSBwb2ludHMgd2VyZSBkaXNj dXNzZWQgYWxyZWFkeSB0byBnZXQgdG8gdGhlIGN1cnJlbnQgY2hhcnRlciB0ZXh0Lg0KDQpCZXN0 LA0KDQpDYXJsb3MuDQoNCk9uIEF1ZyAxMSwgMjAxNCwgYXQgMTA6NDcgQU0sIEx1Y3kgeW9uZyA8 bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4gd3JvdGU6 DQoNCg0KSSBhZ3JlZSBBbmR54oCZcyBwb2ludC4NCg0KTHVjeQ0KDQpGcm9tOiBzZmMgW21haWx0 bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHJldyBHLiBNYWxpcw0KU2Vu dDogRnJpZGF5LCBBdWd1c3QgMDgsIDIwMTQgNDo0NyBQTQ0KVG86IENhcmxvcyBQaWduYXRhcm8g KGNwaWduYXRhKQ0KQ2M6IFh1eGlhb2h1OyBEb2xnYW5vdywgQW5kcmV3IChBbmRyZXcpOyBzZmNA aWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz47IEpvZWwgTS4gSGFscGVybg0KU3ViamVjdDog UmU6IFtzZmNdIERlZmluaXRpb24gb2YgU0ZDIEVuY2Fwc3VsYXRpb24gaW4gZHJhZnQtbWVyZ2Vk LXNmYy1hcmNoaXRlY3R1cmUtMDEudHh0DQoNCkNhcmxvcywNCg0KSSBhZ3JlZSB0aGF0IHRoZSBj aGFydGVyIHJlcXVpcmVzIHRoZSBlbmNhcHN1bGF0aW9uIHRvIHN1cHBvcnQgZWFjaCBvZiB0aGUg YnVsbGV0IGl0ZW1zLCBidXQgdGhlcmUncyBubyByZXF1aXJlbWVudCB0aGF0IGV2ZXJ5IGVuY2Fw c3VsYXRlZCBwYWNrZXQgd2lsbCBuZWVkIGFsbCBvZiB0aGUgYnVsbGV0IGl0ZW1zIHN1cHBvcnRl ZCwgc28gSSdtIHRyeWluZyB0byBrZWVwIHRoZSB0ZXh0IGFzIGZsZXhpYmxlIGFzIHBvc3NpYmxl IHRvIG5vdCBwcmVjbHVkZSBwb3NzaWJsZSBzb2x1dGlvbnMuDQoNCkNoZWVycywNCkFuZHkNCg0K T24gRnJpLCBBdWcgOCwgMjAxNCBhdCAxMTowOSBBTSwgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25h dGEpIDxjcGlnbmF0YUBjaXNjby5jb208bWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbT4+IHdyb3Rl Og0KSGksIEFuZHJldywNCg0KT24gQXVnIDgsIDIwMTQsIGF0IDg6NTMgQU0sIERvbGdhbm93LCBB bmRyZXcgKEFuZHJldykgPGFuZHJldy5kb2xnYW5vd0BhbGNhdGVsLWx1Y2VudC5jb208bWFpbHRv OmFuZHJldy5kb2xnYW5vd0BhbGNhdGVsLWx1Y2VudC5jb20+PiB3cm90ZToNCg0KPiBJIGFncmVl IHRoYXQgd2Ugc2hvdWxkIGhhdmUgc3Ryb25nZXIgc2VwYXJhdGlvbiBvZiB0d28gZnVuY3Rpb25z OiBTRlAgYW5kIG1ldGFkYXRhLg0KPg0KPiBIb3cgYWJvdXQgc21hbGwgZWRpdCB0byB3aGF0IEFu ZHkgcHJvcG9zZWQ6DQo+DQo+IFNGQyBFbmNhcHN1bGF0aW9uOiAgQSBkYXRhIHBsYW5lIGVuY2Fw c3VsYXRpb24gdGhhdCBlbmNvZGVzIGVpdGhlciBvbmUgb3IgYm90aCBvZg0KPiAtIHRoZSBTRlAN Cj4gLSBtZXRhZGF0YSAoZGF0YSBwbGFuZSBjb250ZXh0IGluZm9ybWF0aW9uKS4NCkxvb2tpbmcg YXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL3NmYy9jaGFydGVyLywgdGhlcmUgaXMg bm8gImVpdGhlciBvbmUgb3IgYm90aCBvZiIuIEluIGZhY3QsIGxvb2tpbmcgYXQgdGhlIGhpc3Rv cnkgb2YgdGhlIGNoYXJ0ZXIgdGV4dCwgdGhlIHRleHQgZm9yIFNGQyBFbmNhcHN1bGF0aW9uIGlz IGEgYnVsbGV0IGxpc3QgZm9ybSBvZiBhIGxvbmdlciBzZW50ZW5jZSB0aGF0IGluY2x1ZGVzICJh bmQiIG9ubHkgKHNlZSAwMC0wOSkuDQoNClRoYW5rcywNCg0KQ2FybG9zLg0KDQo+PiBUaGUgU0ZQ IEVuY2Fwc3VsYXRpb24gaXMgdXNlZCBieSB0aGUgU0ZDLWF3YXJlIGZ1bmN0aW9ucywgc3VjaCBh cyB0aGUgU0ZGIGFuZCBTRkMtYXdhcmUgU0ZzLCBhbmQgaXMgbm90IHVzZWQgZm9yIG5ldHdvcmsg cGFja2V0IGZvcndhcmRpbmcuDQo+DQo+DQo+IEFuZHJldw0KPg0KPiBTZW50IGZyb20gbXkgaVBo b25lDQo+DQo+PiBPbiBBdWcgNywgMjAxNCwgYXQgOToxMyBQTSwgIlh1eGlhb2h1IiA8eHV4aWFv aHVAaHVhd2VpLmNvbTxtYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbT4+IHdyb3RlOg0KPj4NCj4+ IEkgZnVsbHkgYWdyZWUgd2l0aCBBbmR54oCZcyBwb2ludCB0aGF0IG5vdCBldmVyeSB1c2FnZSBv ZiB0aGUgZW5jYXBzdWxhdGlvbiB3aWxsIG5lZWQgYm90aCB0aGUgU0ZQIGlkZW50aWZpY2F0aW9u IGFuZCB0aGUgbWV0YWRhdGEuIEl04oCZcyBiZXR0ZXIgdGhhdCB0aGUgU0ZDIGVuY2Fwc3VsYXRp b24gY291bGQgYmUgZmxleGlibHkgdXNlZCBmb3IgY2FycnlpbmcgU0ZQIGlkZW50aWZpY2F0aW9u LCBtZXRhZGF0YSBvciBib3RoLiBPdGhlcndpc2UsIGl0IHNlZW1zIHRoYXQgdGhvc2UgU0ZDIGFw cHJvYWNoZXMgd2hpY2ggZG9u4oCZdCB1c2UgdGhlIFNGQyBlbmNhcHN1bGF0aW9uIGZvciBTRkMg c2VsZWN0aW9uIHdvdWxkIGhhdmUgdG8gc2VwYXJhdGVseSBkZWZpbmUgdGhlIHdheSBvZiBjYXJy eWluZyBtZXRhZGF0YS4NCj4+DQo+PiBCZXN0IHJlZ2FyZHMsDQo+PiBYaWFvaHUNCj4+DQo+PiBG cm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNA aWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgQW5kcmV3IEcuIE1hbGlzDQo+PiBTZW50OiBUaHVyc2Rh eSwgQXVndXN0IDA3LCAyMDE0IDk6MDYgUE0NCj4+IFRvOiBDYXJsb3MgUGlnbmF0YXJvIChjcGln bmF0YSkNCj4+IENjOiBKb2VsIE0uIEhhbHBlcm47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGll dGYub3JnPg0KPj4gU3ViamVjdDogUmU6IFtzZmNdIERlZmluaXRpb24gb2YgU0ZDIEVuY2Fwc3Vs YXRpb24gaW4gZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUtMDEudHh0DQo+Pg0KPj4gQ2Fy bG9zLA0KPj4NCj4+IFdoZW4gSSByZS1yZWFkIHRoZSBkZWZpbml0aW9uLCBpdCBzZWVtZWQgdG8g bWUgdG8gYmUgbW9yZSBvZiBhIHN0cmluZyBvZiB0aG91Z2h0cyB0aGFuIGEgY29uY2lzZSBkZWZp bml0aW9uLCB3aGljaCBpcyB3aHkgSSB3YXMgdHJ5aW5nIHRvIHRpZ2h0ZW4gaXQgdXAuIEEgZGVm aW5pdGlvbiBpcyBtZWFudCB0byBiZSBhIHNob3J0IHN1bW1hcnkgZm9yIHF1aWNrIHJlZmVyZW5j ZSwgd2hpbGUgdGhlIGRpc2N1c3Npb24gaW4gNC4xIGdvZXMgaW50byB0aGUgbW9yZSBmb3JtYWwg ZGV0YWlscy4gIE90aGVyd2lzZSwgeW91IHdvdWxkIGp1c3QgcmVwZWF0IHRoZSBlbnRpcmUgc2Vj dGlvbiA0LjEgaW4gc2VjdGlvbiAxLjMuICBUaGlzIGlzIHdoeSBpdCBkb2Vzbid0IG5lZWQgdG8g YmUgaW4gc2VwYXJhdGUgc2VudGVuY2VzLiBUaGUgImFuZC9vciIgaXMgYmVjYXVzZSBub3QgZXZl cnkgdXNhZ2Ugb2YgdGhlIGVuY2Fwc3VsYXRpb24gd2lsbCBuZWVkIGJvdGggdGhlIFNGUCBpZGVu dGlmaWNhdGlvbiBhbmQgdGhlIG1ldGFkYXRhLCBzbyB0aGUgZGVmaW5pdGlvbiBuZWVkcyB0byBj b25jaXNlbHkgY29udmV5IHRoYXQuDQo+Pg0KPj4gQ2hlZXJzLA0KPj4gQW5keQ0KPj4NCj4+IE9u IFRodSwgQXVnIDcsIDIwMTQgYXQgODo1MSBBTSwgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEp IDxjcGlnbmF0YUBjaXNjby5jb208bWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbT4+IHdyb3RlOg0K Pj4gVGhhbmsgeW91IGZvciBnb2luZyBiYWNrIGFuZCBjaGVja2luZywgQW5keSENCj4+DQo+PiBX aGljaCBzcGVjaWZpYyBwYXJ0IG9mIHRoZSBjdXJyZW50IGRlZmluaXRpb24gZG8geW91IGJlbGll dmUgaXMgbG9vc2UgZW5vdWdoIHRvIG5lZWQgdGlnaHRlbmluZz8NCj4+DQo+PiBJIGJlbGlldmUg dGhhdCB5b3VyIG5ldyBwcm9wb3NhbCBmYWxscyBzaG9ydGVyIHRoYW4gdGhlIGV4aXN0aW5nIHRl eHQgaW4gYSBmZXcgYXJlYXM6DQo+PiDigKIgRmlyc3QsIGl0IGNvbWJpbmVzIHR3byBkaWZmZXJl bnQgZnVuY3Rpb25zIChTRlAgaWRlbnRpZmljYXRpb24gYW5kIG1ldGFkYXRhL2NvbnRleHQgaW5m b3JtYXRpb24pIGludG8gYSBzaW5nbGUgc2VudGVuY2UuIFRoaXMgb3Bwb3NlcyB0aGUgY2hhbmdl IHdlIGp1c3QgbWFkZSBiYXNlZCBvbiB5b3VyIHByZWZlcmVuY2UgaW4gU2VjdGlvbiA0LjEsIHdo aWNoIGJyZWFrcyB0aGUgdHdvIGZ1bmN0aW9ucyBpbnRvIHR3byBzZW50ZW5jZXMsIGZvciByZWFk ZXIgY2xhcml0eS4gV2hpbGUgbG9uZ2VyLCBpdCdzIHNpbXBsZXIuDQo+PiDigKIgU2Vjb25kLCBp dCBpbnRyb2R1Y2VzIGFuIGV4dHJhbmVvdXMgImFuZC9vciIgdGhhdCB3b3VsZCBjaGFuZ2UgdGhl IG1lYW5pbmcsIGFuZCBuZWdhdGUgdGhlICJhdCBhIG1pbmltdW0iIGV4aXN0aW5nIGJpdC4gVGhh dCB3b3VsZCBub3QgYmUgc2ltcGxpZnlpbmcuDQo+PiDigKIgVGhpcmQsIHRoZXJlIGlzIG5vIHRo aXJkIGJ1dCB0aHJlZSBidWxsZXRzIGxvb2sgYmV0dGVyIDotKQ0KPj4NCj4+IE5ldC1uZXQsIHRo ZSBvcmlnaW5hbCB0ZXh0LCBldmVuIHdoZW4gbG9uZ2VyIGluIGNoYXJhY3RlciBjb3VudCwgc2Vl bXMgbW9yZSBjbGVhciBhbmQgc2ltcGxlciB0byB0aGUgcmVhZGVyIChiZWNhdXNlIG9mIHRoZSBz ZXBhcmF0ZWQgc2VudGVuY2VzKSwgSU1ITy4NCj4+DQo+PiBUaGFua3MsDQo+Pg0KPj4gQ2FybG9z Lg0KPj4NCj4+IE9uIEF1ZyA3LCAyMDE0LCBhdCA4OjIwIEFNLCBBbmRyZXcgRy4gTWFsaXMgPGFn bWFsaXNAZ21haWwuY29tPG1haWx0bzphZ21hbGlzQGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4NCj4+ DQo+PiBDYXJsb3MgYW5kIEpvZWwsDQo+Pg0KPj4gSW4gbGlnaHQgb2YgdGhlIHByZXZpb3VzIGRp c2N1c3Npb25zLCBJIHdlbnQgYmFjayBhbmQgcmUtcmVhZCB0aGlzIGN1cnJlbnQgZGVmaW5pdGlv biBvZiBTRkMgRW5jYXBzdWxhdGlvbiBpbiB0aGUgdGV4dCAoc2VjdGlvbiAxLjMpOg0KPj4NCj4+ ICAgU0ZDIEVuY2Fwc3VsYXRpb246ICBUaGUgU0ZDIEVuY2Fwc3VsYXRpb24gcHJvdmlkZXMgYXQg YSBtaW5pbXVtIFNGUA0KPj4gICAgICAgIGlkZW50aWZpY2F0aW9uLCBhbmQgaXMgdXNlZCBieSB0 aGUgU0ZDLWF3YXJlIGZ1bmN0aW9ucywgc3VjaCBhcw0KPj4gICAgICAgIHRoZSBTRkYgYW5kIFNG Qy1hd2FyZSBTRnMuICBUaGUgU0ZDIEVuY2Fwc3VsYXRpb24gaXMgbm90IHVzZWQNCj4+ICAgICAg ICBmb3IgbmV0d29yayBwYWNrZXQgZm9yd2FyZGluZy4gIEluIGFkZGl0aW9uIHRvIFNGUA0KPj4g ICAgICAgIGlkZW50aWZpY2F0aW9uLCB0aGUgU0ZDIGVuY2Fwc3VsYXRpb24gY2FycmllcyBkYXRh cGxhbmUgY29udGV4dA0KPj4gICAgICAgIGluZm9ybWF0aW9uLCBhbHNvIHJlZmVycmVkIHRvIGFz IG1ldGFkYXRhLg0KPj4NCj4+IEkgdGhpbmsgdGhpcyBjb3VsZCBiZSB0aWdodGVuZWQgdXAgdG8g bWFrZSBzaW1wbGVyIGZvciB0aGUgcmVhZGVyOg0KPj4NCj4+IFNGQyBFbmNhcHN1bGF0aW9uOiAg QSBkYXRhIHBsYW5lIGVuY2Fwc3VsYXRpb24gdGhhdCBpZGVudGlmaWVzIHRoZSBTRlAgYW5kL29y IHByb3ZpZGVzIG1ldGFkYXRhIChkYXRhIHBsYW5lIGNvbnRleHQgaW5mb3JtYXRpb24pLiBUaGUg U0ZQIEVuY2Fwc3VsYXRpb24gaXMgdXNlZCBieSB0aGUgU0ZDLWF3YXJlIGZ1bmN0aW9ucywgc3Vj aCBhcyB0aGUgU0ZGIGFuZCBTRkMtYXdhcmUgU0ZzLCBhbmQgaXMgbm90IHVzZWQgZm9yIG5ldHdv cmsgcGFja2V0IGZvcndhcmRpbmcuDQo+Pg0KPj4gVGhhbmtzLA0KPj4gQW5keQ0KPj4NCj4+DQo+ Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ IHNmYyBtYWlsaW5nIGxpc3QNCj4+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0K Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0KDQo= --_000_A2C96F6779E6A041BC7023CC207FC99418F74C63SJCEML702CHMchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgd2l0aCBBbmR5IHRoYXQgdGhlIGNhc2Ugb2YgY2Fy cnlpbmcgb25seSBtZXRhZGF0YSBuZWVkcyB0byBiZSBjb25zaWRlcmVkLiBBY3R1YWxseSBvdXIg c2VydmljZSBjaGFpbiBoZWFkZXIgZHJhZnQgYWxyZWFkeSB0YWtlcyB0aGlzIGludG8gY29uc2lk ZXJhdGlvbi4gVGhlIHByb3Bvc2FsIGluIHRoZSBzZXJ2aWNlIGNoYWluIGhlYWRlciBkcmFmdA0K IGlzIHRvIGNhcnJ5IG1ldGFkYXRhIGFuZCBzZXQgU1BGIElEIHRvIGJlIE5VTEwuIEhlcmUgaXMg YSBzbmlwIG9mIHRoZSBkcmFmdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE0LjRwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBUaGUgU0NIIG1heSBiZSB1c2VkIHRv IGNhcnJ5OiAoMSkgYm90aCBTRkMgcGF0aCBzdGVlcmluZyBpbmZvcm1hdGlvbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNC40 cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYW5kIG1ldGFkYXRhOyAoMikg b25seSBTRkMgcGF0aCBzdGVlcmluZyBpbmZvcm1hdGlvbiwgaW4gd2hpY2ggY2FzZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDox NC40cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgdGhlIE1ldGFkYXRhIExl bmd0aCBmaWVsZCBzaGFsbCBiZSBzZXQgdG8gemVybzsgb3IgKDMpIG9ubHkgbWV0YWRhdGEsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVp Z2h0OjE0LjRwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBpbiB3aGljaCBj YXNlIHRoZSBQYXRoIElkZW50aWZpZXIgYW5kIFNGIEluZGV4IGZpZWxkcyBzaGFsbCBiZSBzZXQg dG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTQuNHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHplcm8g Zm9yIHRyYW5zbWl0IGFuZCBpZ25vcmVkIHVwb24gcmVjZWlwdC4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5DYXRoeTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYu b3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbmRyZXcgRy4gTWFsaXM8YnI+DQo8Yj5TZW50Ojwv Yj4gV2VkbmVzZGF5LCBBdWd1c3QgMTMsIDIwMTQgNjo0OCBBTTxicj4NCjxiPlRvOjwvYj4gQ2Fy bG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpPGJyPg0KPGI+Q2M6PC9iPiBYdXhpYW9odTsgRG9sZ2Fu b3csIEFuZHJldyAoQW5kcmV3KTsgc2ZjQGlldGYub3JnOyBMdWN5IHlvbmc7IEpvZWwgTS4gSGFs cGVybjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NmY10gRGVmaW5pdGlvbiBvZiBTRkMgRW5j YXBzdWxhdGlvbiBpbiBkcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZS0wMS50eHQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNhcmxvcyw8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc2VlIHlvdXIgcG9pbnQsIGJ1 dCB0aGVyZSdzIGFsc28gYmVlbiBkaXNjdXNzaW9uIG9mIGNhc2VzIHdoZXJlIG9ubHkgdGhlIG1l dGFkYXRhIGlzIHJlcXVpcmVkLiBJbiB0aGF0IGNhc2UsIHlvdSB3b3VkIGVpdGhlciBiZSBjYXJy eWluZyBhIG51bGwgU0ZQIElEIGFsb25nIHdpdGggdGhlIG1ldGFkYXRhLCBvciBqdXN0IHRoZSBt ZXRhZGF0YS4gSXQgc2VlbXMgbW9yZSBlZmZpY2llbnQgdG8gbWUgdG8ganVzdA0KIGNhcnJ5IHRo ZSBtZXRhZGF0YSwgYnV0IGlmIHlvdSB3YW50IHRvIGluc2lzdCB0aGF0IHRoZXJlJ3MgYWx3YXlz IGFuIFNQRiBJRCwgdGhlbiB3ZSBuZWVkIHRvIG1ha2Ugc3VyZSB0aGF0IGl0IGNhbiBiZSBhIG51 bGwgSUQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEF1ZyAxMiwgMjAx NCBhdCA5OjUxIFBNLCBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgJmx0OzxhIGhyZWY9Im1h aWx0bzpjcGlnbmF0YUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5jcGlnbmF0YUBjaXNjby5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5IaSwgQW5keSwgTHVjeSwgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5GbGV4aWJpbGl0eSBpcyBjZXJ0YWlubHkgZ29vZCBhcyBsb25nIGFzIGl0IGRv ZXMgbm90IGdldCBpbiB0aGUgd2F5IG9mIGludGVyb3BlcmFiaWxpdHkuIFRoaXMgYXJjaGl0ZWN0 dXJlIGRyaXZlcyBhIGJhbGFuY2UgYW5kIHRyYWRlb2ZmIGluIHdoaWNoIG9wdGlvbnMgYXJlIG1h eGltaXplZCB3aGlsZSBoYXZpbmcgaW50ZXJvcGVyYWJpbGl0eSBhcyB0aGUgZ29hbC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RnJvbSBhIHRl Y2huaWNhbCBwZXJzcGVjdGl2ZSwgdGhlIFNGQyBFbmNhcHN1bGF0aW9uIHNwZWNpZmllcyB0aGUg U2VydmljZSBGdW5jdGlvbiBQYXRoIHRvIGFsbG93IGZvciBlbmQtdG8tZW5kIFNGUHMgYW5kIGlu dGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25zLiBPbmUgb2YgdGhlIGtleSBwcmluY2lwbGVzIG9m IHRoaXMgYXJjaGl0ZWN0dXJlIGlzIHRoYXQgdGhlIFNGQyBFbmNhcHN1bGF0aW9uIGlzIHRyYW5z cG9ydC1pbmRlcGVuZGVudC4NCiBUaGUgdGV4dCBpcyBmbGV4aWJsZSBzdWNoIHRoYXQgYW55IHRy YW5zcG9ydCBtYXkgYmUgdXNlZCB0byBjYXJyeSB0aGUgU0ZDIGVuY2Fwc3VsYXRpb24uIEhvd2V2 ZXIsIHR3byBTRnMgcGFydCBvZiBhbiBTRlAgdGhhdCBhcmUgbm90IGFkamFjZW50IGluIHRoZSBz ZXJ2aWNlcyB0b3BvbG9neSBjYW4gaGF2ZSBkaWZmZXJlbnQgdHJhbnNwb3J0IGVuY2Fwc3VsYXRp b25zIGJ1dCBuZWVkIHRoZSBTRkMtZW5jYXBzdWxhdGlvbiAobWluaW11bSBpbnZhcmlhbnQNCiBl bmNhcCkgdG8gc3BlY2lmeSB0aGUgU1BGLiBUaGlzIGlzIHdpdGhpbiB0aGUgc2VydmljZSB0b3Bv bG9neSwgd2hpY2ggYWdhaW4gaXMgaW5kZXBlbmRlbnQgZnJvbSB0aGUgdW5kZXJsYXkgdG9wb2xv Z3kgYXMgYW4gYXJjaGl0ZWN0dXJhbCBwcmluY2lwbGUuIFBsZWFzZSBub3RlIHRoYXQgdGhlIHVz ZSBvZiB0aGUgU0ZDIGVuY2Fwc3VsYXRpb24gdG8gc3BlY2lmeSB0aGUgU0ZQIGFuZCB0aGUgU0ZG cyBhbmQgU0ZzIHVzZSBvZiB0aGlzIGlzIGFydGljdWxhdGVkDQogdGhyb3VnaG91dCB0aGUgYXJj aGl0ZWN0dXJlLiBUaGlzIGFyY2hpdGVjdHVyZSBhbHNvIGFsbG93cyBmb3IgZmxleGliaWxpdHkg aW4gYnJpbmdpbmcgU0ZDLXVuYXdhcmUgU0ZzIGJ5IHByb3h5IGFzIHRoZSBvbmUgZ2F0ZXdheSwg dG8gcHJvdmlkZSBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSwgYnV0IGF0dGVtcHRzIHRvIGNhcnJ5 IGZvcndhcmQgaW50ZXJvcGVyYWJpbGl0eS4gQ29uc2VxdWVudGx5LCBmb3IgJnF1b3Q7U0ZDIEF3 YXJlJnF1b3Q7IGNoYWlucywgdGhlDQogYXJjaGl0ZWN0dXJhbCBjaG9pY2UgdGhhdCBmb2xsb3dz IHRoZSBwcmluY2lwbGVzIGlzIHRvIGNhcnJ5IHRoZSBTRlAgaWQuIEl0IGlzIChhbHNvKSB0byBj b252ZXkgc2hhcmVkIGNvbnRleHQgKHdoZW4gZGVtYW5kZWQgYnkgdGhlIHVzZSBjYXNlKSB1c2lu ZyB0aGUgU0ZDLWVuY2Fwc3VsYXRpb24gZm9yIHNpbWlsYXIgcmVhc29ucy4gQXMgYSBXRywgSSBi ZWxpZXZlIHdlIHNob3VsZCBmaXJzdCBzdHJpdmUgZm9yIGEgc2luZ2xlJm5ic3A7c2VydmljZS1s ZXZlbA0KIGRhdGEgcGxhbmUgZW5jYXBzdWxhdGlvbiBhcyBwZXIgdGhlIGN1cnJlbnQgV0cgY2hh cnRlciBhbmQgYmFzZWQgb24gdGhhdCBwcm92aWRlIHRoZSBtb3N0IG9wdGltYWwgcGxhY2VtZW50 IG9mIGZ1bmN0aW9ucyBhbmQgaWRlbnRpZmllcnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdGUgYWxzbyB0aGF0IEkgd2FzIHBvaW50aW5n IHRvIHRoZSBjaGFydGVyIGJlY2F1c2UgSSBiZWxpZXZlIHRoZXNlIHBvaW50cyB3ZXJlIGRpc2N1 c3NlZCBhbHJlYWR5IHRvIGdldCB0byB0aGUgY3VycmVudCBjaGFydGVyIHRleHQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QsPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNhcmxvcy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gQXVnIDExLCAyMDE0LCBhdCAxMDo0NyBBTSwgTHVjeSB5b25n ICZsdDs8YSBocmVmPSJtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5r Ij5sdWN5LnlvbmdAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFncmVlIEFuZHnigJlzIHBvaW50Ljwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+THVjeTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDtzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi Pm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XSZuYnNwOzxiPk9uDQogQmVo YWxmIE9mJm5ic3A7PC9iPkFuZHJldyBHLiBNYWxpczxicj4NCjxiPlNlbnQ6PC9iPiZuYnNwO0Zy aWRheSwgQXVndXN0IDA4LCAyMDE0IDQ6NDcgUE08YnI+DQo8Yj5Ubzo8L2I+Jm5ic3A7Q2FybG9z IFBpZ25hdGFybyAoY3BpZ25hdGEpPGJyPg0KPGI+Q2M6PC9iPiZuYnNwO1h1eGlhb2h1OyBEb2xn YW5vdywgQW5kcmV3IChBbmRyZXcpOyZuYnNwOzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5zZmNAaWV0Zi5vcmc8 L3NwYW4+PC9hPjsgSm9lbCBNLiBIYWxwZXJuPGJyPg0KPGI+U3ViamVjdDo8L2I+Jm5ic3A7UmU6 IFtzZmNdIERlZmluaXRpb24gb2YgU0ZDIEVuY2Fwc3VsYXRpb24gaW4gZHJhZnQtbWVyZ2VkLXNm Yy1hcmNoaXRlY3R1cmUtMDEudHh0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DYXJsb3MsPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIGFncmVlIHRoYXQgdGhlIGNoYXJ0ZXIgcmVxdWlyZXMgdGhlIGVuY2Fwc3Vs YXRpb24gdG8gc3VwcG9ydCBlYWNoIG9mIHRoZSBidWxsZXQgaXRlbXMsIGJ1dCB0aGVyZSdzIG5v IHJlcXVpcmVtZW50IHRoYXQgZXZlcnkgZW5jYXBzdWxhdGVkIHBhY2tldCB3aWxsIG5lZWQgYWxs IG9mIHRoZSBidWxsZXQgaXRlbXMgc3VwcG9ydGVkLCBzbyBJJ20gdHJ5aW5nIHRvIGtlZXAgdGhl IHRleHQgYXMgZmxleGlibGUgYXMNCiBwb3NzaWJsZSB0byBub3QgcHJlY2x1ZGUgcG9zc2libGUg c29sdXRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B bmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBBdWcg OCwgMjAxNCBhdCAxMTowOSBBTSwgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpICZsdDs8YSBo cmVmPSJtYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+Y3BpZ25hdGFAY2lzY28uY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGks IEFuZHJldyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gQXVnIDgsIDIwMTQsIGF0 IDg6NTMgQU0sIERvbGdhbm93LCBBbmRyZXcgKEFuZHJldykgJmx0OzxhIGhyZWY9Im1haWx0bzph bmRyZXcuZG9sZ2Fub3dAYWxjYXRlbC1sdWNlbnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+YW5kcmV3LmRvbGdhbm93QGFsY2F0ZWwtbHVjZW50LmNvbTwv c3Bhbj48L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7IEkgYWdyZWUgdGhhdCB3ZSBzaG91 bGQgaGF2ZSBzdHJvbmdlciBzZXBhcmF0aW9uIG9mIHR3byBmdW5jdGlvbnM6IFNGUCBhbmQgbWV0 YWRhdGEuPGJyPg0KJmd0Ozxicj4NCiZndDsgSG93IGFib3V0IHNtYWxsIGVkaXQgdG8gd2hhdCBB bmR5IHByb3Bvc2VkOjxicj4NCiZndDs8YnI+DQomZ3Q7IFNGQyBFbmNhcHN1bGF0aW9uOiAmbmJz cDtBIGRhdGEgcGxhbmUgZW5jYXBzdWxhdGlvbiB0aGF0IGVuY29kZXMgZWl0aGVyIG9uZSBvciBi b3RoIG9mPGJyPg0KJmd0OyAtIHRoZSBTRlA8YnI+DQomZ3Q7IC0gbWV0YWRhdGEgKGRhdGEgcGxh bmUgY29udGV4dCBpbmZvcm1hdGlvbikuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Mb29raW5nIGF0Jm5ic3A7PGEgaHJlZj0iaHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL3dnL3NmYy9jaGFydGVyLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9zZmMvY2hh cnRlci88L3NwYW4+PC9hPiwgdGhlcmUgaXMgbm8gJnF1b3Q7ZWl0aGVyIG9uZSBvciBib3RoIG9m JnF1b3Q7LiBJbiBmYWN0LCBsb29raW5nIGF0IHRoZSBoaXN0b3J5IG9mDQogdGhlIGNoYXJ0ZXIg dGV4dCwgdGhlIHRleHQgZm9yIFNGQyBFbmNhcHN1bGF0aW9uIGlzIGEgYnVsbGV0IGxpc3QgZm9y bSBvZiBhIGxvbmdlciBzZW50ZW5jZSB0aGF0IGluY2x1ZGVzICZxdW90O2FuZCZxdW90OyBvbmx5 IChzZWUgMDAtMDkpLjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQo8YnI+DQpDYXJsb3MuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxicj4NCiZndDsmZ3Q7IFRoZSBTRlAgRW5jYXBzdWxhdGlvbiBp cyB1c2VkIGJ5IHRoZSBTRkMtYXdhcmUgZnVuY3Rpb25zLCBzdWNoIGFzIHRoZSBTRkYgYW5kIFNG Qy1hd2FyZSBTRnMsIGFuZCBpcyBub3QgdXNlZCBmb3IgbmV0d29yayBwYWNrZXQgZm9yd2FyZGlu Zy48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgQW5kcmV3PGJyPg0KJmd0Ozxicj4NCiZn dDsgU2VudCBmcm9tIG15IGlQaG9uZTxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyBPbiBBdWcgNywg MjAxNCwgYXQgOToxMyBQTSwgJnF1b3Q7WHV4aWFvaHUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzp4dXhpYW9odUBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+eHV4aWFvaHVAaHVhd2VpLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEkgZnVsbHkgYWdyZWUgd2l0aCBBbmR54oCZcyBwb2ludCB0 aGF0IG5vdCBldmVyeSB1c2FnZSBvZiB0aGUgZW5jYXBzdWxhdGlvbiB3aWxsIG5lZWQgYm90aCB0 aGUgU0ZQIGlkZW50aWZpY2F0aW9uIGFuZCB0aGUgbWV0YWRhdGEuIEl04oCZcyBiZXR0ZXIgdGhh dCB0aGUgU0ZDIGVuY2Fwc3VsYXRpb24gY291bGQgYmUgZmxleGlibHkgdXNlZCBmb3IgY2Fycnlp bmcgU0ZQIGlkZW50aWZpY2F0aW9uLCBtZXRhZGF0YSBvciBib3RoLiBPdGhlcndpc2UsDQogaXQg c2VlbXMgdGhhdCB0aG9zZSBTRkMgYXBwcm9hY2hlcyB3aGljaCBkb27igJl0IHVzZSB0aGUgU0ZD IGVuY2Fwc3VsYXRpb24gZm9yIFNGQyBzZWxlY3Rpb24gd291bGQgaGF2ZSB0byBzZXBhcmF0ZWx5 IGRlZmluZSB0aGUgd2F5IG9mIGNhcnJ5aW5nIG1ldGFkYXRhLjxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgQmVzdCByZWdhcmRzLDxicj4NCiZndDsmZ3Q7IFhpYW9odTxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgRnJvbTogc2ZjIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl0gT24gQmVoYWxmIE9mIEFuZHJldyBHLiBN YWxpczxicj4NCiZndDsmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMDcsIDIwMTQgOTowNiBQ TTxicj4NCiZndDsmZ3Q7IFRvOiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSk8YnI+DQomZ3Q7 Jmd0OyBDYzogSm9lbCBNLiBIYWxwZXJuOyZuYnNwOzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5zZmNAaWV0Zi5v cmc8L3NwYW4+PC9hPjxicj4NCiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbc2ZjXSBEZWZpbml0aW9u IG9mIFNGQyBFbmNhcHN1bGF0aW9uIGluIGRyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAx LnR4dDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQ2FybG9zLDxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgV2hlbiBJIHJlLXJlYWQgdGhlIGRlZmluaXRpb24sIGl0IHNlZW1lZCB0byBt ZSB0byBiZSBtb3JlIG9mIGEgc3RyaW5nIG9mIHRob3VnaHRzIHRoYW4gYSBjb25jaXNlIGRlZmlu aXRpb24sIHdoaWNoIGlzIHdoeSBJIHdhcyB0cnlpbmcgdG8gdGlnaHRlbiBpdCB1cC4gQSBkZWZp bml0aW9uIGlzIG1lYW50IHRvIGJlIGEgc2hvcnQgc3VtbWFyeSBmb3IgcXVpY2sgcmVmZXJlbmNl LCB3aGlsZSB0aGUgZGlzY3Vzc2lvbiBpbiA0LjEgZ29lcyBpbnRvDQogdGhlIG1vcmUgZm9ybWFs IGRldGFpbHMuICZuYnNwO090aGVyd2lzZSwgeW91IHdvdWxkIGp1c3QgcmVwZWF0IHRoZSBlbnRp cmUgc2VjdGlvbiA0LjEgaW4gc2VjdGlvbiAxLjMuICZuYnNwO1RoaXMgaXMgd2h5IGl0IGRvZXNu J3QgbmVlZCB0byBiZSBpbiBzZXBhcmF0ZSBzZW50ZW5jZXMuIFRoZSAmcXVvdDthbmQvb3ImcXVv dDsgaXMgYmVjYXVzZSBub3QgZXZlcnkgdXNhZ2Ugb2YgdGhlIGVuY2Fwc3VsYXRpb24gd2lsbCBu ZWVkIGJvdGggdGhlIFNGUCBpZGVudGlmaWNhdGlvbiBhbmQNCiB0aGUgbWV0YWRhdGEsIHNvIHRo ZSBkZWZpbml0aW9uIG5lZWRzIHRvIGNvbmNpc2VseSBjb252ZXkgdGhhdC48YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7IENoZWVycyw8YnI+DQomZ3Q7Jmd0OyBBbmR5PGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyBPbiBUaHUsIEF1ZyA3LCAyMDE0IGF0IDg6NTEgQU0sIENhcmxvcyBQaWdu YXRhcm8gKGNwaWduYXRhKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmNwaWduYXRhQGNpc2Nv LmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBUaGFuayB5b3UgZm9yIGdv aW5nIGJhY2sgYW5kIGNoZWNraW5nLCBBbmR5ITxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg V2hpY2ggc3BlY2lmaWMgcGFydCBvZiB0aGUgY3VycmVudCBkZWZpbml0aW9uIGRvIHlvdSBiZWxp ZXZlIGlzIGxvb3NlIGVub3VnaCB0byBuZWVkIHRpZ2h0ZW5pbmc/PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyBJIGJlbGlldmUgdGhhdCB5b3VyIG5ldyBwcm9wb3NhbCBmYWxscyBzaG9ydGVy IHRoYW4gdGhlIGV4aXN0aW5nIHRleHQgaW4gYSBmZXcgYXJlYXM6PGJyPg0KJmd0OyZndDsg4oCi IEZpcnN0LCBpdCBjb21iaW5lcyB0d28gZGlmZmVyZW50IGZ1bmN0aW9ucyAoU0ZQIGlkZW50aWZp Y2F0aW9uIGFuZCBtZXRhZGF0YS9jb250ZXh0IGluZm9ybWF0aW9uKSBpbnRvIGEgc2luZ2xlIHNl bnRlbmNlLiBUaGlzIG9wcG9zZXMgdGhlIGNoYW5nZSB3ZSBqdXN0IG1hZGUgYmFzZWQgb24geW91 ciBwcmVmZXJlbmNlIGluIFNlY3Rpb24gNC4xLCB3aGljaCBicmVha3MgdGhlIHR3byBmdW5jdGlv bnMgaW50byB0d28gc2VudGVuY2VzLCBmb3INCiByZWFkZXIgY2xhcml0eS4gV2hpbGUgbG9uZ2Vy LCBpdCdzIHNpbXBsZXIuPGJyPg0KJmd0OyZndDsg4oCiIFNlY29uZCwgaXQgaW50cm9kdWNlcyBh biBleHRyYW5lb3VzICZxdW90O2FuZC9vciZxdW90OyB0aGF0IHdvdWxkIGNoYW5nZSB0aGUgbWVh bmluZywgYW5kIG5lZ2F0ZSB0aGUgJnF1b3Q7YXQgYSBtaW5pbXVtJnF1b3Q7IGV4aXN0aW5nIGJp dC4gVGhhdCB3b3VsZCBub3QgYmUgc2ltcGxpZnlpbmcuPGJyPg0KJmd0OyZndDsg4oCiIFRoaXJk LCB0aGVyZSBpcyBubyB0aGlyZCBidXQgdGhyZWUgYnVsbGV0cyBsb29rIGJldHRlciA6LSk8YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE5ldC1uZXQsIHRoZSBvcmlnaW5hbCB0ZXh0LCBldmVu IHdoZW4gbG9uZ2VyIGluIGNoYXJhY3RlciBjb3VudCwgc2VlbXMgbW9yZSBjbGVhciBhbmQgc2lt cGxlciB0byB0aGUgcmVhZGVyIChiZWNhdXNlIG9mIHRoZSBzZXBhcmF0ZWQgc2VudGVuY2VzKSwg SU1ITy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7IENhcmxvcy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE9uIEF1ZyA3 LCAyMDE0LCBhdCA4OjIwIEFNLCBBbmRyZXcgRy4gTWFsaXMgJmx0OzxhIGhyZWY9Im1haWx0bzph Z21hbGlzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPmFnbWFsaXNAZ21haWwuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBDYXJsb3MgYW5kIEpvZWwsPGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyBJbiBsaWdodCBvZiB0aGUgcHJldmlvdXMgZGlzY3Vzc2lvbnMsIEkg d2VudCBiYWNrIGFuZCByZS1yZWFkIHRoaXMgY3VycmVudCBkZWZpbml0aW9uIG9mIFNGQyBFbmNh cHN1bGF0aW9uIGluIHRoZSB0ZXh0IChzZWN0aW9uIDEuMyk6PGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyAmbmJzcDsgU0ZDIEVuY2Fwc3VsYXRpb246ICZuYnNwO1RoZSBTRkMgRW5jYXBzdWxh dGlvbiBwcm92aWRlcyBhdCBhIG1pbmltdW0gU0ZQPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7aWRlbnRpZmljYXRpb24sIGFuZCBpcyB1c2VkIGJ5IHRoZSBTRkMtYXdh cmUgZnVuY3Rpb25zLCBzdWNoIGFzPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7dGhlIFNGRiBhbmQgU0ZDLWF3YXJlIFNGcy4gJm5ic3A7VGhlIFNGQyBFbmNhcHN1bGF0 aW9uIGlzIG5vdCB1c2VkPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Zm9yIG5ldHdvcmsgcGFja2V0IGZvcndhcmRpbmcuICZuYnNwO0luIGFkZGl0aW9uIHRvIFNGUDxi cj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2lkZW50aWZpY2F0aW9uLCB0 aGUgU0ZDIGVuY2Fwc3VsYXRpb24gY2FycmllcyBkYXRhcGxhbmUgY29udGV4dDxicj4NCiZndDsm Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2luZm9ybWF0aW9uLCBhbHNvIHJlZmVycmVk IHRvIGFzIG1ldGFkYXRhLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSB0aGluayB0aGlz IGNvdWxkIGJlIHRpZ2h0ZW5lZCB1cCB0byBtYWtlIHNpbXBsZXIgZm9yIHRoZSByZWFkZXI6PGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBTRkMgRW5jYXBzdWxhdGlvbjogJm5ic3A7QSBkYXRh IHBsYW5lIGVuY2Fwc3VsYXRpb24gdGhhdCBpZGVudGlmaWVzIHRoZSBTRlAgYW5kL29yIHByb3Zp ZGVzIG1ldGFkYXRhIChkYXRhIHBsYW5lIGNvbnRleHQgaW5mb3JtYXRpb24pLiBUaGUgU0ZQIEVu Y2Fwc3VsYXRpb24gaXMgdXNlZCBieSB0aGUgU0ZDLWF3YXJlIGZ1bmN0aW9ucywgc3VjaCBhcyB0 aGUgU0ZGIGFuZCBTRkMtYXdhcmUgU0ZzLCBhbmQgaXMgbm90IHVzZWQgZm9yIG5ldHdvcmsgcGFj a2V0DQogZm9yd2FyZGluZy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoYW5rcyw8YnI+ DQomZ3Q7Jmd0OyBBbmR5PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7Jmd0OyBzZmMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsmbmJzcDs8 YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+c2ZjQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQomZ3Q7Jmd0OyZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_A2C96F6779E6A041BC7023CC207FC99418F74C63SJCEML702CHMchi_-- From nobody Wed Aug 13 11:11: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 360D61A03F8 for ; Wed, 13 Aug 2014 11:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.669 X-Spam-Level: X-Spam-Status: No, score=-3.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_55=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 LZQtMoxX4ZBw for ; Wed, 13 Aug 2014 11:11: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 1E9AC1A03D7 for ; Wed, 13 Aug 2014 11:11:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIF30734; Wed, 13 Aug 2014 18:11:46 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.212.94.47) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 Aug 2014 19:11:44 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.137]) by SJCEML701-CHM.china.huawei.com ([169.254.3.190]) with mapi id 14.03.0158.001; Wed, 13 Aug 2014 11:11:39 -0700 From: Cathy Zhang To: Ron Parker , Alla Goldner , "Joel M. Halpern" , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.txt Thread-Index: AQHPtUH2M51XE8vuAEm8pr18QvUl4JvL5MGAgAALj4CAAACQAIAACg6AgAA0PYCAAqTqQA== Date: Wed, 13 Aug 2014 18:11:38 +0000 Message-ID: References: <20140803211558.28482.8328.idtracker@ietfa.amsl.com> <0EE8F6C7-DFB7-4DF3-BD00-2B93EFF56E78@cisco.com> <53E8CD15.7010002@joelhalpern.com> <53E8D740.6090501@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.145.72] 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/SI56vhcyxp81vWo-sNUN3fsJjlQ Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.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, 13 Aug 2014 18:11:54 -0000 Agree with Ron. I think the SFF has two key functionalities. One is doing t= he transport encapsulation in a way that the packet can be routed/switched = through the network to the next SFF or SF Proxy. Given that the network cou= ld be of different types(could be L2 or L3, could be various tunnel mechani= sms), the transport encapsulation could be different. The other is forwardi= ng the packet to the selected connecting service function instance (A SFF c= ould connect to multiple service function instances of the same type or dif= ferent types).=20 Thanks, Cathy =20 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Monday, August 11, 2014 11:29 AM To: Alla Goldner; Joel M. Halpern; Carlos Pignataro (cpignata); sfc@ietf.or= g Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-archi= tecture-01.txt Alla, I'm trying to clarify, in my mind, the distinction of network encapsulation= and network transport. For reasons that Joel states, I feel the transpor= t encapsulation and de-encapsulation must happen at the SFF (i.e., the SFF = terminates the transport tunnels). The networking path followed by those = transport tunnels is based on the network switching/routing behavior and ne= ed not be visible to the SFF. In an SDN overlay type of network, the SFF= would be the Virtual Tunnel Endpoint (VTEP) in this way of thinking. =20 Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Alla Goldner Sent: Monday, August 11, 2014 11:22 AM To: Joel M. Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-archi= tecture-01.txt Dear Joel, all, SFF and transport network connectivity point need to be co-located (this is= not mandatory but makes sense). This means that a simple L2 connectivity between SFF and the network connec= tivity point can be used as this interface. That can be some VLAN or VXLAN or any other L2 protocol. This shouldn't imp= ose a big overhead on the SFF. Also, the same interface you are talking about should exist also between SF= F and SF proxy. So if we already need to solve it there, we can use it between SFF and netw= ork component. I strongly believe we should decouple network transport functions from the = SFF and thus correct the section 4.3. Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972= 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com www.a= llot.com -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Monday, August 11, 2014 5:46 PM To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-archi= tecture-01.txt That is how we had drawn the figure before. And described the functions. The problem is that this creates an interface between a network component a= nd the SFF which can not exist visibly. There is no way I know of to ship = the packets between those two. So the Encaps / decaps has to be co-located with the SFF. This archtiecture tries not to get into the internal structure of the logic= al components or to describe separately components that must be co-located.= Some architectures do describe that. Yours, Joel On 8/11/14, 10:44 AM, Alla Goldner wrote: > Dear Joel, all, > > One of the motivations of SFC is be agnostic to the underlay transport ne= twork. > When you couple the SFF with the encapsulation/de-capsulation process it = has to be aware of the network transport and it has to be capable to suppor= t different types of transport protocols. > For me it doesn't make too much sense and it makes the SFF very complex. > I think that a cleaner architecture is to have the SFF handle the SFC tas= ks and handle the SFC encapsulations (that is the metadata and SFC headers)= but leave the transport to be handled by the network layer which can be an= y type of network. > > Best regards, > > > Alla Goldner > Director of Mobile Technologies and Standards Allot Communications Tel=20 > +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626=20 > agoldner@allot.com www.allot.com > > > > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Monday, August 11, 2014 5:03 PM > To: Alla Goldner; Carlos Pignataro (cpignata); sfc@ietf.org > Subject: Re: [sfc] Fwd: New Version Notification for=20 > draft-merged-sfc-architecture-01.txt > > I would say instead that we need to fix section 4.5, to make it clear tha= t the SFF is responsible for the encaps decaps, while the network uses the= outer encapsulation for its forwarding. > > Yours, > Joel > > On 8/11/14, 4:56 AM, Alla Goldner wrote: >> Dear Carlos, Joel, all, >> >> Thanks for providing this merged architecture document! >> >> According to the model in figure 3 and section 4.5, the network >> (underlay) components are responsible for: >> >> * Finding the network path to reach the next SF (next SFF) in >> the SFP. >> >> * Encapsulate/de-capsulate the underlay network transport. >> >> Section 4.3 (SFF) contradicts this and says the network=20 >> encapsulation/de-capsulation is done by the SFF. >> >> I believe that the section 4.3 should be fixed in this regard. The=20 >> reason is that network transport functions should not necessarily be=20 >> coupled with the SFF. >> >> Best regards, >> >> *Alla Goldner* >> >> *Director of Mobile Technologies and Standards* >> >> Allot Communications >> >> Tel +972 9 7619251 >> >> Cell +972 54 2493985 >> >> Fax +972 9 7443626 >> >> *agoldner@allot.com **__* >> >> *www.allot.com* *__* >> >> *__* >> >> *291X55_signature (2)* >> >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Carlos=20 >> Pignataro >> (cpignata) >> *Sent:* Monday, August 04, 2014 12:19 AM >> *To:* sfc@ietf.org >> *Subject:* [sfc] Fwd: New Version Notification for=20 >> draft-merged-sfc-architecture-01.txt >> >> SFCers, >> >> After Toronto, Joel and I have been working on resolving the key open=20 >> discussion items, and incorporating all the input and feedback=20 >> received thus into this document as the vehicle for a single SFC=20 >> Architecture item to progress. >> >> While we are still working on the document, we wanted to get a=20 >> version out early to the WG to test the resolution to key open items,=20 >> see what we might still be missing, and iterate. >> >> Please review and let us know. >> >> Thanks, >> >> Carlos & Joel. >> >> Begin forwarded message: >> >> >> >> *From: *> >> >> *Subject: New Version Notification for >> draft-merged-sfc-architecture-01.txt* >> >> *Date: *August 3, 2014 at 5:15:58 PM EDT >> >> *To: *Joel Halpern > >, Carlos Pignataro > >, "Joel M. Halpern" > >, Carlos Pignataro > > >> >> >> A new version of I-D, draft-merged-sfc-architecture-01.txt >> has been successfully submitted by Carlos Pignataro and posted to the=20 >> IETF repository. >> >> Name:draft-merged-sfc-architecture >> Revision:01 >> Title:Service Function Chaining (SFC) Architecture Document >> date:2014-08-03 Group:Individual Submission >> Pages:25 >> URL: >> http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-01. >> t >> xt >> Status: >> https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ >> Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-01 >> Diff: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-01 >> >> Abstract: >> This document describes an architecture for the specification, >> creation, and ongoing maintenance of Service Function Chains (SFC) i= n >> 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=20 >> submission until the htmlized version and diff are available at=20 >> tools.ietf.org . >> >> The IETF Secretariat >> >> --------------------------------------------------------------------- >> - >> -- This message is intended only for the designated recipient(s). It=20 >> may contain confidential or proprietary information. If you are not=20 >> the designated recipient, you may not review, copy or distribute this=20 >> message. If you have mistakenly received this message, please notify=20 >> the sender by a reply e-mail and delete this message. Thank you. >> >> --------------------------------------------------------------------- >> - >> -- >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > ###################################################################### > ######################## This message is intended only for the=20 > designated recipient(s).It may contain confidential or proprietary inform= ation. > If you are not the designated recipient, you may not review, copy or dist= ribute this message. > If you have mistakenly received this message, please notify the sender by= a reply e-mail and delete this message. > Thank you. > ###################################################################### > ######################## > ###########################################################################= ################### This message is intended only for the designated recipient(s).It may contai= n confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distri= bute this message. If you have mistakenly received this message, please notify the sender by a= reply e-mail and delete this message.=20 Thank you. ###########################################################################= ################### _______________________________________________ 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 Wed Aug 13 21:01: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 6E76A1A00AB for ; Wed, 13 Aug 2014 21:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 d8gY5wbDoAts for ; Wed, 13 Aug 2014 21:01:40 -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 A604F1A00A5 for ; Wed, 13 Aug 2014 21:01:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLG04973; Thu, 14 Aug 2014 04:01:37 +0000 (GMT) Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 14 Aug 2014 05:01:36 +0100 Received: from SZXEMA509-MBX.china.huawei.com ([169.254.1.59]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Thu, 14 Aug 2014 12:01:28 +0800 From: "Hongyu Li (Julio)" To: Cathy Zhang , "Andrew G. Malis" , "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt Thread-Index: AQHPsj5aLLMeiGPAKE+4WkNpLSA+FJvElhWAgADLN4CAAMN6gIAAJg6AgABvCICABEHTgIACS/2AgADIFoCAAEA2AIABMpHA Date: Thu, 14 Aug 2014 04:01:26 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97EA562B1@SZXEMA509-MBX.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A4805@NKGEML512-MBS.china.huawei.com> <57B2ECF6-8DB4-4E23-BB14-E030EB74E09C@alcatel-lucent.com> <2691CE0099834E4A9C5044EEC662BB9D453CBFBE@dfweml701-chm.china.huawei.com> <5F8C4A2F-3C60-459D-92F7-31EA1DA9E469@cisco.com> 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.66.114.234] Content-Type: multipart/alternative; boundary="_000_6EB34CB5D82C4645B826C56144826EA97EA562B1SZXEMA509MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/5F9obAlDhYOmhC72wTkoQOK0syY Cc: Xuxiaohu , "Dolganow, Andrew \(Andrew\)" , "sfc@ietf.org" , Lucy yong , "Joel M. Halpern" Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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, 14 Aug 2014 04:01:44 -0000 --_000_6EB34CB5D82C4645B826C56144826EA97EA562B1SZXEMA509MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIG5vdGljZWQgdGhlcmUgd2VyZSBzb21lIGRpc2N1c3Npb24gdGhhdCBTRlAg SUQgY291bGQgYmUgbnVsbCBvciB6ZXJvLiBIb3dldmVyLCB0aGVyZSB3ZXMgbm90IGFueSBwZXJz dWFzaXZlIHVzZSBjYXNlIG9yIHNjZW5hcmlvIHByb3ZpZGVkIHNvIGZhci4gSW4gY2FzZSBvZiBl eHBlY3RpbmcgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIGxlZ2FjeSBkZXZpY2VzLCBhbiBleGlzdGlu ZyBwcm90b2NvbCBpcyBuZWVkZWQsIG1lYW5pbmcgY2FycnlpbmcgbWV0YWRhdGEgd2l0aCBzdWNo IGEgcHJvdG9jb2wgaXMgbm90IHBvc3NpYmxlIGVpdGhlciwgYXMgYW55IG1vZGlmaWNhdGlvbiB0 byB0aGUgcHJvdG9jb2wgd2lsbCBsZWFkIHRvIG1vZGlmaWNhdGlvbiBvZiBsZWdhY3kgZGV2aWNl cy4NCg0KSWYgU0ZQIElEIGlzIG51bGwgb3IgemVybywgaG93IGNvdWxkIHlvdSBmaW5kIHRoZSBu ZXh0IGhvcCBpbiBlYWNoIFNGRj8gV2hlcmUgaXMgdGhlIFNGQy9TRlAgbGF5ZXI/DQoNCkNoZWVy cywNCkhvbmd5dQ0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIENhdGh5IFpoYW5nDQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDE0LCAyMDE0IDE6 MzggQU0NClRvOiBBbmRyZXcgRy4gTWFsaXM7IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKQ0K Q2M6IFh1eGlhb2h1OyBEb2xnYW5vdywgQW5kcmV3IChBbmRyZXcpOyBMdWN5IHlvbmc7IHNmY0Bp ZXRmLm9yZzsgSm9lbCBNLiBIYWxwZXJuDQpTdWJqZWN0OiBSZTogW3NmY10gRGVmaW5pdGlvbiBv ZiBTRkMgRW5jYXBzdWxhdGlvbiBpbiBkcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZS0wMS50 eHQNCg0KSSBhZ3JlZSB3aXRoIEFuZHkgdGhhdCB0aGUgY2FzZSBvZiBjYXJyeWluZyBvbmx5IG1l dGFkYXRhIG5lZWRzIHRvIGJlIGNvbnNpZGVyZWQuIEFjdHVhbGx5IG91ciBzZXJ2aWNlIGNoYWlu IGhlYWRlciBkcmFmdCBhbHJlYWR5IHRha2VzIHRoaXMgaW50byBjb25zaWRlcmF0aW9uLiBUaGUg cHJvcG9zYWwgaW4gdGhlIHNlcnZpY2UgY2hhaW4gaGVhZGVyIGRyYWZ0IGlzIHRvIGNhcnJ5IG1l dGFkYXRhIGFuZCBzZXQgU1BGIElEIHRvIGJlIE5VTEwuIEhlcmUgaXMgYSBzbmlwIG9mIHRoZSBk cmFmdDoNCg0KICAgVGhlIFNDSCBtYXkgYmUgdXNlZCB0byBjYXJyeTogKDEpIGJvdGggU0ZDIHBh dGggc3RlZXJpbmcgaW5mb3JtYXRpb24NCiAgIGFuZCBtZXRhZGF0YTsgKDIpIG9ubHkgU0ZDIHBh dGggc3RlZXJpbmcgaW5mb3JtYXRpb24sIGluIHdoaWNoIGNhc2UNCiAgIHRoZSBNZXRhZGF0YSBM ZW5ndGggZmllbGQgc2hhbGwgYmUgc2V0IHRvIHplcm87IG9yICgzKSBvbmx5IG1ldGFkYXRhLA0K ICAgaW4gd2hpY2ggY2FzZSB0aGUgUGF0aCBJZGVudGlmaWVyIGFuZCBTRiBJbmRleCBmaWVsZHMg c2hhbGwgYmUgc2V0IHRvDQogICB6ZXJvIGZvciB0cmFuc21pdCBhbmQgaWdub3JlZCB1cG9uIHJl Y2VpcHQuDQoNClRoYW5rcywNCkNhdGh5DQoNCg0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmRyZXcgRy4gTWFsaXMNClNlbnQ6IFdlZG5lc2Rh eSwgQXVndXN0IDEzLCAyMDE0IDY6NDggQU0NClRvOiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0 YSkNCkNjOiBYdXhpYW9odTsgRG9sZ2Fub3csIEFuZHJldyAoQW5kcmV3KTsgc2ZjQGlldGYub3Jn PG1haWx0bzpzZmNAaWV0Zi5vcmc+OyBMdWN5IHlvbmc7IEpvZWwgTS4gSGFscGVybg0KU3ViamVj dDogUmU6IFtzZmNdIERlZmluaXRpb24gb2YgU0ZDIEVuY2Fwc3VsYXRpb24gaW4gZHJhZnQtbWVy Z2VkLXNmYy1hcmNoaXRlY3R1cmUtMDEudHh0DQoNCkNhcmxvcywNCg0KSSBzZWUgeW91ciBwb2lu dCwgYnV0IHRoZXJlJ3MgYWxzbyBiZWVuIGRpc2N1c3Npb24gb2YgY2FzZXMgd2hlcmUgb25seSB0 aGUgbWV0YWRhdGEgaXMgcmVxdWlyZWQuIEluIHRoYXQgY2FzZSwgeW91IHdvdWQgZWl0aGVyIGJl IGNhcnJ5aW5nIGEgbnVsbCBTRlAgSUQgYWxvbmcgd2l0aCB0aGUgbWV0YWRhdGEsIG9yIGp1c3Qg dGhlIG1ldGFkYXRhLiBJdCBzZWVtcyBtb3JlIGVmZmljaWVudCB0byBtZSB0byBqdXN0IGNhcnJ5 IHRoZSBtZXRhZGF0YSwgYnV0IGlmIHlvdSB3YW50IHRvIGluc2lzdCB0aGF0IHRoZXJlJ3MgYWx3 YXlzIGFuIFNQRiBJRCwgdGhlbiB3ZSBuZWVkIHRvIG1ha2Ugc3VyZSB0aGF0IGl0IGNhbiBiZSBh IG51bGwgSUQuDQoNCkNoZWVycywNCkFuZHkNCg0KT24gVHVlLCBBdWcgMTIsIDIwMTQgYXQgOTo1 MSBQTSwgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIDxjcGlnbmF0YUBjaXNjby5jb208bWFp bHRvOmNwaWduYXRhQGNpc2NvLmNvbT4+IHdyb3RlOg0KSGksIEFuZHksIEx1Y3ksDQoNCkZsZXhp YmlsaXR5IGlzIGNlcnRhaW5seSBnb29kIGFzIGxvbmcgYXMgaXQgZG9lcyBub3QgZ2V0IGluIHRo ZSB3YXkgb2YgaW50ZXJvcGVyYWJpbGl0eS4gVGhpcyBhcmNoaXRlY3R1cmUgZHJpdmVzIGEgYmFs YW5jZSBhbmQgdHJhZGVvZmYgaW4gd2hpY2ggb3B0aW9ucyBhcmUgbWF4aW1pemVkIHdoaWxlIGhh dmluZyBpbnRlcm9wZXJhYmlsaXR5IGFzIHRoZSBnb2FsLg0KDQpGcm9tIGEgdGVjaG5pY2FsIHBl cnNwZWN0aXZlLCB0aGUgU0ZDIEVuY2Fwc3VsYXRpb24gc3BlY2lmaWVzIHRoZSBTZXJ2aWNlIEZ1 bmN0aW9uIFBhdGggdG8gYWxsb3cgZm9yIGVuZC10by1lbmQgU0ZQcyBhbmQgaW50ZXJvcGVyYWJs ZSBpbXBsZW1lbnRhdGlvbnMuIE9uZSBvZiB0aGUga2V5IHByaW5jaXBsZXMgb2YgdGhpcyBhcmNo aXRlY3R1cmUgaXMgdGhhdCB0aGUgU0ZDIEVuY2Fwc3VsYXRpb24gaXMgdHJhbnNwb3J0LWluZGVw ZW5kZW50LiBUaGUgdGV4dCBpcyBmbGV4aWJsZSBzdWNoIHRoYXQgYW55IHRyYW5zcG9ydCBtYXkg YmUgdXNlZCB0byBjYXJyeSB0aGUgU0ZDIGVuY2Fwc3VsYXRpb24uIEhvd2V2ZXIsIHR3byBTRnMg cGFydCBvZiBhbiBTRlAgdGhhdCBhcmUgbm90IGFkamFjZW50IGluIHRoZSBzZXJ2aWNlcyB0b3Bv bG9neSBjYW4gaGF2ZSBkaWZmZXJlbnQgdHJhbnNwb3J0IGVuY2Fwc3VsYXRpb25zIGJ1dCBuZWVk IHRoZSBTRkMtZW5jYXBzdWxhdGlvbiAobWluaW11bSBpbnZhcmlhbnQgZW5jYXApIHRvIHNwZWNp ZnkgdGhlIFNQRi4gVGhpcyBpcyB3aXRoaW4gdGhlIHNlcnZpY2UgdG9wb2xvZ3ksIHdoaWNoIGFn YWluIGlzIGluZGVwZW5kZW50IGZyb20gdGhlIHVuZGVybGF5IHRvcG9sb2d5IGFzIGFuIGFyY2hp dGVjdHVyYWwgcHJpbmNpcGxlLiBQbGVhc2Ugbm90ZSB0aGF0IHRoZSB1c2Ugb2YgdGhlIFNGQyBl bmNhcHN1bGF0aW9uIHRvIHNwZWNpZnkgdGhlIFNGUCBhbmQgdGhlIFNGRnMgYW5kIFNGcyB1c2Ug b2YgdGhpcyBpcyBhcnRpY3VsYXRlZCB0aHJvdWdob3V0IHRoZSBhcmNoaXRlY3R1cmUuIFRoaXMg YXJjaGl0ZWN0dXJlIGFsc28gYWxsb3dzIGZvciBmbGV4aWJpbGl0eSBpbiBicmluZ2luZyBTRkMt dW5hd2FyZSBTRnMgYnkgcHJveHkgYXMgdGhlIG9uZSBnYXRld2F5LCB0byBwcm92aWRlIGJhY2t3 YXJkcyBjb21wYXRpYmlsaXR5LCBidXQgYXR0ZW1wdHMgdG8gY2FycnkgZm9yd2FyZCBpbnRlcm9w ZXJhYmlsaXR5LiBDb25zZXF1ZW50bHksIGZvciAiU0ZDIEF3YXJlIiBjaGFpbnMsIHRoZSBhcmNo aXRlY3R1cmFsIGNob2ljZSB0aGF0IGZvbGxvd3MgdGhlIHByaW5jaXBsZXMgaXMgdG8gY2Fycnkg dGhlIFNGUCBpZC4gSXQgaXMgKGFsc28pIHRvIGNvbnZleSBzaGFyZWQgY29udGV4dCAod2hlbiBk ZW1hbmRlZCBieSB0aGUgdXNlIGNhc2UpIHVzaW5nIHRoZSBTRkMtZW5jYXBzdWxhdGlvbiBmb3Ig c2ltaWxhciByZWFzb25zLiBBcyBhIFdHLCBJIGJlbGlldmUgd2Ugc2hvdWxkIGZpcnN0IHN0cml2 ZSBmb3IgYSBzaW5nbGUgc2VydmljZS1sZXZlbCBkYXRhIHBsYW5lIGVuY2Fwc3VsYXRpb24gYXMg cGVyIHRoZSBjdXJyZW50IFdHIGNoYXJ0ZXIgYW5kIGJhc2VkIG9uIHRoYXQgcHJvdmlkZSB0aGUg bW9zdCBvcHRpbWFsIHBsYWNlbWVudCBvZiBmdW5jdGlvbnMgYW5kIGlkZW50aWZpZXJzLg0KDQpO b3RlIGFsc28gdGhhdCBJIHdhcyBwb2ludGluZyB0byB0aGUgY2hhcnRlciBiZWNhdXNlIEkgYmVs aWV2ZSB0aGVzZSBwb2ludHMgd2VyZSBkaXNjdXNzZWQgYWxyZWFkeSB0byBnZXQgdG8gdGhlIGN1 cnJlbnQgY2hhcnRlciB0ZXh0Lg0KDQpCZXN0LA0KDQpDYXJsb3MuDQoNCk9uIEF1ZyAxMSwgMjAx NCwgYXQgMTA6NDcgQU0sIEx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1 Y3kueW9uZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQoNCkkgYWdyZWUgQW5keeKAmXMgcG9pbnQuDQoN Ckx1Y3kNCg0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBBbmRyZXcgRy4gTWFsaXMNClNlbnQ6IEZyaWRheSwgQXVndXN0IDA4LCAyMDE0IDQ6NDcg UE0NClRvOiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkNCkNjOiBYdXhpYW9odTsgRG9sZ2Fu b3csIEFuZHJldyAoQW5kcmV3KTsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+OyBK b2VsIE0uIEhhbHBlcm4NClN1YmplY3Q6IFJlOiBbc2ZjXSBEZWZpbml0aW9uIG9mIFNGQyBFbmNh cHN1bGF0aW9uIGluIGRyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAxLnR4dA0KDQpDYXJs b3MsDQoNCkkgYWdyZWUgdGhhdCB0aGUgY2hhcnRlciByZXF1aXJlcyB0aGUgZW5jYXBzdWxhdGlv biB0byBzdXBwb3J0IGVhY2ggb2YgdGhlIGJ1bGxldCBpdGVtcywgYnV0IHRoZXJlJ3Mgbm8gcmVx dWlyZW1lbnQgdGhhdCBldmVyeSBlbmNhcHN1bGF0ZWQgcGFja2V0IHdpbGwgbmVlZCBhbGwgb2Yg dGhlIGJ1bGxldCBpdGVtcyBzdXBwb3J0ZWQsIHNvIEknbSB0cnlpbmcgdG8ga2VlcCB0aGUgdGV4 dCBhcyBmbGV4aWJsZSBhcyBwb3NzaWJsZSB0byBub3QgcHJlY2x1ZGUgcG9zc2libGUgc29sdXRp b25zLg0KDQpDaGVlcnMsDQpBbmR5DQoNCk9uIEZyaSwgQXVnIDgsIDIwMTQgYXQgMTE6MDkgQU0s IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSA8Y3BpZ25hdGFAY2lzY28uY29tPG1haWx0bzpj cGlnbmF0YUBjaXNjby5jb20+PiB3cm90ZToNCkhpLCBBbmRyZXcsDQoNCk9uIEF1ZyA4LCAyMDE0 LCBhdCA4OjUzIEFNLCBEb2xnYW5vdywgQW5kcmV3IChBbmRyZXcpIDxhbmRyZXcuZG9sZ2Fub3dA YWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzphbmRyZXcuZG9sZ2Fub3dAYWxjYXRlbC1sdWNlbnQu Y29tPj4gd3JvdGU6DQoNCj4gSSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBoYXZlIHN0cm9uZ2VyIHNl cGFyYXRpb24gb2YgdHdvIGZ1bmN0aW9uczogU0ZQIGFuZCBtZXRhZGF0YS4NCj4NCj4gSG93IGFi b3V0IHNtYWxsIGVkaXQgdG8gd2hhdCBBbmR5IHByb3Bvc2VkOg0KPg0KPiBTRkMgRW5jYXBzdWxh dGlvbjogIEEgZGF0YSBwbGFuZSBlbmNhcHN1bGF0aW9uIHRoYXQgZW5jb2RlcyBlaXRoZXIgb25l IG9yIGJvdGggb2YNCj4gLSB0aGUgU0ZQDQo+IC0gbWV0YWRhdGEgKGRhdGEgcGxhbmUgY29udGV4 dCBpbmZvcm1hdGlvbikuDQpMb29raW5nIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93 Zy9zZmMvY2hhcnRlci8sIHRoZXJlIGlzIG5vICJlaXRoZXIgb25lIG9yIGJvdGggb2YiLiBJbiBm YWN0LCBsb29raW5nIGF0IHRoZSBoaXN0b3J5IG9mIHRoZSBjaGFydGVyIHRleHQsIHRoZSB0ZXh0 IGZvciBTRkMgRW5jYXBzdWxhdGlvbiBpcyBhIGJ1bGxldCBsaXN0IGZvcm0gb2YgYSBsb25nZXIg c2VudGVuY2UgdGhhdCBpbmNsdWRlcyAiYW5kIiBvbmx5IChzZWUgMDAtMDkpLg0KDQpUaGFua3Ms DQoNCkNhcmxvcy4NCg0KPj4gVGhlIFNGUCBFbmNhcHN1bGF0aW9uIGlzIHVzZWQgYnkgdGhlIFNG Qy1hd2FyZSBmdW5jdGlvbnMsIHN1Y2ggYXMgdGhlIFNGRiBhbmQgU0ZDLWF3YXJlIFNGcywgYW5k IGlzIG5vdCB1c2VkIGZvciBuZXR3b3JrIHBhY2tldCBmb3J3YXJkaW5nLg0KPg0KPg0KPiBBbmRy ZXcNCj4NCj4gU2VudCBmcm9tIG15IGlQaG9uZQ0KPg0KPj4gT24gQXVnIDcsIDIwMTQsIGF0IDk6 MTMgUE0sICJYdXhpYW9odSIgPHh1eGlhb2h1QGh1YXdlaS5jb208bWFpbHRvOnh1eGlhb2h1QGh1 YXdlaS5jb20+PiB3cm90ZToNCj4+DQo+PiBJIGZ1bGx5IGFncmVlIHdpdGggQW5keeKAmXMgcG9p bnQgdGhhdCBub3QgZXZlcnkgdXNhZ2Ugb2YgdGhlIGVuY2Fwc3VsYXRpb24gd2lsbCBuZWVkIGJv dGggdGhlIFNGUCBpZGVudGlmaWNhdGlvbiBhbmQgdGhlIG1ldGFkYXRhLiBJdOKAmXMgYmV0dGVy IHRoYXQgdGhlIFNGQyBlbmNhcHN1bGF0aW9uIGNvdWxkIGJlIGZsZXhpYmx5IHVzZWQgZm9yIGNh cnJ5aW5nIFNGUCBpZGVudGlmaWNhdGlvbiwgbWV0YWRhdGEgb3IgYm90aC4gT3RoZXJ3aXNlLCBp dCBzZWVtcyB0aGF0IHRob3NlIFNGQyBhcHByb2FjaGVzIHdoaWNoIGRvbuKAmXQgdXNlIHRoZSBT RkMgZW5jYXBzdWxhdGlvbiBmb3IgU0ZDIHNlbGVjdGlvbiB3b3VsZCBoYXZlIHRvIHNlcGFyYXRl bHkgZGVmaW5lIHRoZSB3YXkgb2YgY2FycnlpbmcgbWV0YWRhdGEuDQo+Pg0KPj4gQmVzdCByZWdh cmRzLA0KPj4gWGlhb2h1DQo+Pg0KPj4gRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEFuZHJldyBH LiBNYWxpcw0KPj4gU2VudDogVGh1cnNkYXksIEF1Z3VzdCAwNywgMjAxNCA5OjA2IFBNDQo+PiBU bzogQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpDQo+PiBDYzogSm9lbCBNLiBIYWxwZXJuOyBz ZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBE ZWZpbml0aW9uIG9mIFNGQyBFbmNhcHN1bGF0aW9uIGluIGRyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0 ZWN0dXJlLTAxLnR4dA0KPj4NCj4+IENhcmxvcywNCj4+DQo+PiBXaGVuIEkgcmUtcmVhZCB0aGUg ZGVmaW5pdGlvbiwgaXQgc2VlbWVkIHRvIG1lIHRvIGJlIG1vcmUgb2YgYSBzdHJpbmcgb2YgdGhv dWdodHMgdGhhbiBhIGNvbmNpc2UgZGVmaW5pdGlvbiwgd2hpY2ggaXMgd2h5IEkgd2FzIHRyeWlu ZyB0byB0aWdodGVuIGl0IHVwLiBBIGRlZmluaXRpb24gaXMgbWVhbnQgdG8gYmUgYSBzaG9ydCBz dW1tYXJ5IGZvciBxdWljayByZWZlcmVuY2UsIHdoaWxlIHRoZSBkaXNjdXNzaW9uIGluIDQuMSBn b2VzIGludG8gdGhlIG1vcmUgZm9ybWFsIGRldGFpbHMuICBPdGhlcndpc2UsIHlvdSB3b3VsZCBq dXN0IHJlcGVhdCB0aGUgZW50aXJlIHNlY3Rpb24gNC4xIGluIHNlY3Rpb24gMS4zLiAgVGhpcyBp cyB3aHkgaXQgZG9lc24ndCBuZWVkIHRvIGJlIGluIHNlcGFyYXRlIHNlbnRlbmNlcy4gVGhlICJh bmQvb3IiIGlzIGJlY2F1c2Ugbm90IGV2ZXJ5IHVzYWdlIG9mIHRoZSBlbmNhcHN1bGF0aW9uIHdp bGwgbmVlZCBib3RoIHRoZSBTRlAgaWRlbnRpZmljYXRpb24gYW5kIHRoZSBtZXRhZGF0YSwgc28g dGhlIGRlZmluaXRpb24gbmVlZHMgdG8gY29uY2lzZWx5IGNvbnZleSB0aGF0Lg0KPj4NCj4+IENo ZWVycywNCj4+IEFuZHkNCj4+DQo+PiBPbiBUaHUsIEF1ZyA3LCAyMDE0IGF0IDg6NTEgQU0sIENh cmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSA8Y3BpZ25hdGFAY2lzY28uY29tPG1haWx0bzpjcGln bmF0YUBjaXNjby5jb20+PiB3cm90ZToNCj4+IFRoYW5rIHlvdSBmb3IgZ29pbmcgYmFjayBhbmQg Y2hlY2tpbmcsIEFuZHkhDQo+Pg0KPj4gV2hpY2ggc3BlY2lmaWMgcGFydCBvZiB0aGUgY3VycmVu dCBkZWZpbml0aW9uIGRvIHlvdSBiZWxpZXZlIGlzIGxvb3NlIGVub3VnaCB0byBuZWVkIHRpZ2h0 ZW5pbmc/DQo+Pg0KPj4gSSBiZWxpZXZlIHRoYXQgeW91ciBuZXcgcHJvcG9zYWwgZmFsbHMgc2hv cnRlciB0aGFuIHRoZSBleGlzdGluZyB0ZXh0IGluIGEgZmV3IGFyZWFzOg0KPj4g4oCiIEZpcnN0 LCBpdCBjb21iaW5lcyB0d28gZGlmZmVyZW50IGZ1bmN0aW9ucyAoU0ZQIGlkZW50aWZpY2F0aW9u IGFuZCBtZXRhZGF0YS9jb250ZXh0IGluZm9ybWF0aW9uKSBpbnRvIGEgc2luZ2xlIHNlbnRlbmNl LiBUaGlzIG9wcG9zZXMgdGhlIGNoYW5nZSB3ZSBqdXN0IG1hZGUgYmFzZWQgb24geW91ciBwcmVm ZXJlbmNlIGluIFNlY3Rpb24gNC4xLCB3aGljaCBicmVha3MgdGhlIHR3byBmdW5jdGlvbnMgaW50 byB0d28gc2VudGVuY2VzLCBmb3IgcmVhZGVyIGNsYXJpdHkuIFdoaWxlIGxvbmdlciwgaXQncyBz aW1wbGVyLg0KPj4g4oCiIFNlY29uZCwgaXQgaW50cm9kdWNlcyBhbiBleHRyYW5lb3VzICJhbmQv b3IiIHRoYXQgd291bGQgY2hhbmdlIHRoZSBtZWFuaW5nLCBhbmQgbmVnYXRlIHRoZSAiYXQgYSBt aW5pbXVtIiBleGlzdGluZyBiaXQuIFRoYXQgd291bGQgbm90IGJlIHNpbXBsaWZ5aW5nLg0KPj4g 4oCiIFRoaXJkLCB0aGVyZSBpcyBubyB0aGlyZCBidXQgdGhyZWUgYnVsbGV0cyBsb29rIGJldHRl ciA6LSkNCj4+DQo+PiBOZXQtbmV0LCB0aGUgb3JpZ2luYWwgdGV4dCwgZXZlbiB3aGVuIGxvbmdl ciBpbiBjaGFyYWN0ZXIgY291bnQsIHNlZW1zIG1vcmUgY2xlYXIgYW5kIHNpbXBsZXIgdG8gdGhl IHJlYWRlciAoYmVjYXVzZSBvZiB0aGUgc2VwYXJhdGVkIHNlbnRlbmNlcyksIElNSE8uDQo+Pg0K Pj4gVGhhbmtzLA0KPj4NCj4+IENhcmxvcy4NCj4+DQo+PiBPbiBBdWcgNywgMjAxNCwgYXQgODoy MCBBTSwgQW5kcmV3IEcuIE1hbGlzIDxhZ21hbGlzQGdtYWlsLmNvbTxtYWlsdG86YWdtYWxpc0Bn bWFpbC5jb20+PiB3cm90ZToNCj4+DQo+Pg0KPj4gQ2FybG9zIGFuZCBKb2VsLA0KPj4NCj4+IElu IGxpZ2h0IG9mIHRoZSBwcmV2aW91cyBkaXNjdXNzaW9ucywgSSB3ZW50IGJhY2sgYW5kIHJlLXJl YWQgdGhpcyBjdXJyZW50IGRlZmluaXRpb24gb2YgU0ZDIEVuY2Fwc3VsYXRpb24gaW4gdGhlIHRl eHQgKHNlY3Rpb24gMS4zKToNCj4+DQo+PiAgIFNGQyBFbmNhcHN1bGF0aW9uOiAgVGhlIFNGQyBF bmNhcHN1bGF0aW9uIHByb3ZpZGVzIGF0IGEgbWluaW11bSBTRlANCj4+ICAgICAgICBpZGVudGlm aWNhdGlvbiwgYW5kIGlzIHVzZWQgYnkgdGhlIFNGQy1hd2FyZSBmdW5jdGlvbnMsIHN1Y2ggYXMN Cj4+ICAgICAgICB0aGUgU0ZGIGFuZCBTRkMtYXdhcmUgU0ZzLiAgVGhlIFNGQyBFbmNhcHN1bGF0 aW9uIGlzIG5vdCB1c2VkDQo+PiAgICAgICAgZm9yIG5ldHdvcmsgcGFja2V0IGZvcndhcmRpbmcu ICBJbiBhZGRpdGlvbiB0byBTRlANCj4+ICAgICAgICBpZGVudGlmaWNhdGlvbiwgdGhlIFNGQyBl bmNhcHN1bGF0aW9uIGNhcnJpZXMgZGF0YXBsYW5lIGNvbnRleHQNCj4+ICAgICAgICBpbmZvcm1h dGlvbiwgYWxzbyByZWZlcnJlZCB0byBhcyBtZXRhZGF0YS4NCj4+DQo+PiBJIHRoaW5rIHRoaXMg Y291bGQgYmUgdGlnaHRlbmVkIHVwIHRvIG1ha2Ugc2ltcGxlciBmb3IgdGhlIHJlYWRlcjoNCj4+ DQo+PiBTRkMgRW5jYXBzdWxhdGlvbjogIEEgZGF0YSBwbGFuZSBlbmNhcHN1bGF0aW9uIHRoYXQg aWRlbnRpZmllcyB0aGUgU0ZQIGFuZC9vciBwcm92aWRlcyBtZXRhZGF0YSAoZGF0YSBwbGFuZSBj b250ZXh0IGluZm9ybWF0aW9uKS4gVGhlIFNGUCBFbmNhcHN1bGF0aW9uIGlzIHVzZWQgYnkgdGhl IFNGQy1hd2FyZSBmdW5jdGlvbnMsIHN1Y2ggYXMgdGhlIFNGRiBhbmQgU0ZDLWF3YXJlIFNGcywg YW5kIGlzIG5vdCB1c2VkIGZvciBuZXR3b3JrIHBhY2tldCBmb3J3YXJkaW5nLg0KPj4NCj4+IFRo YW5rcywNCj4+IEFuZHkNCj4+DQo+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+PiBzZmMgbWFpbGluZyBsaXN0DQo+PiBzZmNAaWV0Zi5v cmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjDQoNCg0K --_000_6EB34CB5D82C4645B826C56144826EA97EA562B1SZXEMA509MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiLmibnms6jmoYbmlofm nKwgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjkuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bh bi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8 jyI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KcC5IVE1MUHJlZm9ybWF0dGVkLCBsaS5IVE1MUHJlZm9y bWF0dGVkLCBkaXYuSFRNTFByZWZvcm1hdHRlZA0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVm b3JtYXR0ZWQiOw0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCglt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5IVE1MUHJlZm9y bWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl ZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1l OiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOuaJueazqOahhuaWh+acrDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkhpIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBu b3RpY2VkIHRoZXJlIHdlcmUgc29tZSBkaXNjdXNzaW9uIHRoYXQgU0ZQIElEIGNvdWxkIGJlIG51 bGwgb3IgemVyby4gSG93ZXZlciwgdGhlcmUgd2VzIG5vdCBhbnkgcGVyc3Vhc2l2ZSB1c2UgY2Fz ZSBvciBzY2VuYXJpbyBwcm92aWRlZCBzbw0KIGZhci4gSW4gY2FzZSBvZiBleHBlY3RpbmcgaW50 ZXJvcGVyYWJpbGl0eSB3aXRoIGxlZ2FjeSBkZXZpY2VzLCBhbiBleGlzdGluZyBwcm90b2NvbCBp cyBuZWVkZWQsIG1lYW5pbmcgY2FycnlpbmcgbWV0YWRhdGEgd2l0aCBzdWNoIGEgcHJvdG9jb2wg aXMgbm90IHBvc3NpYmxlIGVpdGhlciwgYXMgYW55IG1vZGlmaWNhdGlvbiB0byB0aGUgcHJvdG9j b2wgd2lsbCBsZWFkIHRvIG1vZGlmaWNhdGlvbiBvZiBsZWdhY3kgZGV2aWNlcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgU0ZQIElEIGlzIG51bGwgb3IgemVybywgaG93 IGNvdWxkIHlvdSBmaW5kIHRoZSBuZXh0IGhvcCBpbiBlYWNoIFNGRj8gV2hlcmUgaXMgdGhlIFNG Qy9TRlAgbGF5ZXI/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhvbmd5dTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNmYyBb bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DYXRoeSBa aGFuZzxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXVndXN0IDE0LCAyMDE0IDE6MzggQU08 YnI+DQo8Yj5Ubzo8L2I+IEFuZHJldyBHLiBNYWxpczsgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25h dGEpPGJyPg0KPGI+Q2M6PC9iPiBYdXhpYW9odTsgRG9sZ2Fub3csIEFuZHJldyAoQW5kcmV3KTsg THVjeSB5b25nOyBzZmNAaWV0Zi5vcmc7IEpvZWwgTS4gSGFscGVybjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW3NmY10gRGVmaW5pdGlvbiBvZiBTRkMgRW5jYXBzdWxhdGlvbiBpbiBkcmFmdC1t ZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZS0wMS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB3aXRoIEFuZHkgdGhhdCB0aGUg Y2FzZSBvZiBjYXJyeWluZyBvbmx5IG1ldGFkYXRhIG5lZWRzIHRvIGJlIGNvbnNpZGVyZWQuIEFj dHVhbGx5IG91ciBzZXJ2aWNlIGNoYWluIGhlYWRlciBkcmFmdCBhbHJlYWR5IHRha2VzIHRoaXMg aW50byBjb25zaWRlcmF0aW9uLiBUaGUgcHJvcG9zYWwgaW4gdGhlIHNlcnZpY2UgY2hhaW4NCiBo ZWFkZXIgZHJhZnQgaXMgdG8gY2FycnkgbWV0YWRhdGEgYW5kIHNldCBTUEYgSUQgdG8gYmUgTlVM TC4gSGVyZSBpcyBhIHNuaXAgb2YgdGhlIGRyYWZ0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImxpbmUtaGVpZ2h0OjE0LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsgVGhlIFNDSCBtYXkgYmUgdXNlZCB0byBjYXJyeTogKDEpIGJvdGggU0ZD IHBhdGggc3RlZXJpbmcgaW5mb3JtYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0Ij48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBhbmQgbWV0YWRhdGE7ICgyKSBvbmx5IFNG QyBwYXRoIHN0ZWVyaW5nIGluZm9ybWF0aW9uLCBpbiB3aGljaCBjYXNlPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE0LjRwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgdGhlIE1ldGFk YXRhIExlbmd0aCBmaWVsZCBzaGFsbCBiZSBzZXQgdG8gemVybzsgb3IgKDMpIG9ubHkgbWV0YWRh dGEsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjE0LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsgaW4gd2hpY2ggY2FzZSB0aGUgUGF0aCBJZGVudGlmaWVyIGFuZCBTRiBJbmRleCBm aWVsZHMgc2hhbGwgYmUgc2V0IHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE0LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgemVybyBmb3IgdHJhbnNtaXQgYW5kIGlnbm9yZWQg dXBvbiByZWNlaXB0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PkNhdGh5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNmYyBbPGEgaHJlZj0ibWFpbHRv OnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5BbmRyZXcgRy4gTWFsaXM8YnI+DQo8Yj5TZW50OjwvYj4gV2Vk bmVzZGF5LCBBdWd1c3QgMTMsIDIwMTQgNjo0OCBBTTxicj4NCjxiPlRvOjwvYj4gQ2FybG9zIFBp Z25hdGFybyAoY3BpZ25hdGEpPGJyPg0KPGI+Q2M6PC9iPiBYdXhpYW9odTsgRG9sZ2Fub3csIEFu ZHJldyAoQW5kcmV3KTsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3Jn PC9hPjsgTHVjeSB5b25nOyBKb2VsIE0uIEhhbHBlcm48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtzZmNdIERlZmluaXRpb24gb2YgU0ZDIEVuY2Fwc3VsYXRpb24gaW4gZHJhZnQtbWVyZ2VkLXNm Yy1hcmNoaXRlY3R1cmUtMDEudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5D YXJsb3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBzZWUgeW91 ciBwb2ludCwgYnV0IHRoZXJlJ3MgYWxzbyBiZWVuIGRpc2N1c3Npb24gb2YgY2FzZXMgd2hlcmUg b25seSB0aGUgbWV0YWRhdGEgaXMgcmVxdWlyZWQuIEluIHRoYXQgY2FzZSwgeW91IHdvdWQgZWl0 aGVyIGJlIGNhcnJ5aW5nIGEgbnVsbCBTRlAgSUQgYWxvbmcgd2l0aCB0aGUgbWV0YWRhdGEsIG9y IGp1c3QgdGhlIG1ldGFkYXRhLiBJdCBzZWVtcyBtb3JlIGVmZmljaWVudA0KIHRvIG1lIHRvIGp1 c3QgY2FycnkgdGhlIG1ldGFkYXRhLCBidXQgaWYgeW91IHdhbnQgdG8gaW5zaXN0IHRoYXQgdGhl cmUncyBhbHdheXMgYW4gU1BGIElELCB0aGVuIHdlIG5lZWQgdG8gbWFrZSBzdXJlIHRoYXQgaXQg Y2FuIGJlIGEgbnVsbCBJRC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QW5keTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5PbiBUdWUsIEF1ZyAxMiwgMjAxNCBhdCA5OjUxIFBNLCBDYXJsb3MgUGlnbmF0YXJv IChjcGlnbmF0YSkgJmx0OzxhIGhyZWY9Im1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20iIHRhcmdl dD0iX2JsYW5rIj5jcGlnbmF0YUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PkhpLCBBbmR5LCBMdWN5LCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5GbGV4aWJpbGl0eSBpcyBjZXJ0YWlubHkgZ29vZCBhcyBsb25nIGFzIGl0IGRvZXMgbm90IGdl dCBpbiB0aGUgd2F5IG9mIGludGVyb3BlcmFiaWxpdHkuIFRoaXMgYXJjaGl0ZWN0dXJlIGRyaXZl cyBhIGJhbGFuY2UgYW5kIHRyYWRlb2ZmIGluIHdoaWNoIG9wdGlvbnMgYXJlIG1heGltaXplZCB3 aGlsZSBoYXZpbmcgaW50ZXJvcGVyYWJpbGl0eSBhcyB0aGUgZ29hbC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb20gYSB0ZWNobmljYWwgcGVyc3Bl Y3RpdmUsIHRoZSBTRkMgRW5jYXBzdWxhdGlvbiBzcGVjaWZpZXMgdGhlIFNlcnZpY2UgRnVuY3Rp b24gUGF0aCB0byBhbGxvdyBmb3IgZW5kLXRvLWVuZCBTRlBzIGFuZCBpbnRlcm9wZXJhYmxlIGlt cGxlbWVudGF0aW9ucy4gT25lIG9mIHRoZSBrZXkgcHJpbmNpcGxlcyBvZiB0aGlzIGFyY2hpdGVj dHVyZSBpcyB0aGF0IHRoZSBTRkMgRW5jYXBzdWxhdGlvbg0KIGlzIHRyYW5zcG9ydC1pbmRlcGVu ZGVudC4gVGhlIHRleHQgaXMgZmxleGlibGUgc3VjaCB0aGF0IGFueSB0cmFuc3BvcnQgbWF5IGJl IHVzZWQgdG8gY2FycnkgdGhlIFNGQyBlbmNhcHN1bGF0aW9uLiBIb3dldmVyLCB0d28gU0ZzIHBh cnQgb2YgYW4gU0ZQIHRoYXQgYXJlIG5vdCBhZGphY2VudCBpbiB0aGUgc2VydmljZXMgdG9wb2xv Z3kgY2FuIGhhdmUgZGlmZmVyZW50IHRyYW5zcG9ydCBlbmNhcHN1bGF0aW9ucyBidXQgbmVlZCB0 aGUgU0ZDLWVuY2Fwc3VsYXRpb24NCiAobWluaW11bSBpbnZhcmlhbnQgZW5jYXApIHRvIHNwZWNp ZnkgdGhlIFNQRi4gVGhpcyBpcyB3aXRoaW4gdGhlIHNlcnZpY2UgdG9wb2xvZ3ksIHdoaWNoIGFn YWluIGlzIGluZGVwZW5kZW50IGZyb20gdGhlIHVuZGVybGF5IHRvcG9sb2d5IGFzIGFuIGFyY2hp dGVjdHVyYWwgcHJpbmNpcGxlLiBQbGVhc2Ugbm90ZSB0aGF0IHRoZSB1c2Ugb2YgdGhlIFNGQyBl bmNhcHN1bGF0aW9uIHRvIHNwZWNpZnkgdGhlIFNGUCBhbmQgdGhlIFNGRnMgYW5kIFNGcw0KIHVz ZSBvZiB0aGlzIGlzIGFydGljdWxhdGVkIHRocm91Z2hvdXQgdGhlIGFyY2hpdGVjdHVyZS4gVGhp cyBhcmNoaXRlY3R1cmUgYWxzbyBhbGxvd3MgZm9yIGZsZXhpYmlsaXR5IGluIGJyaW5naW5nIFNG Qy11bmF3YXJlIFNGcyBieSBwcm94eSBhcyB0aGUgb25lIGdhdGV3YXksIHRvIHByb3ZpZGUgYmFj a3dhcmRzIGNvbXBhdGliaWxpdHksIGJ1dCBhdHRlbXB0cyB0byBjYXJyeSBmb3J3YXJkIGludGVy b3BlcmFiaWxpdHkuIENvbnNlcXVlbnRseSwNCiBmb3IgJnF1b3Q7U0ZDIEF3YXJlJnF1b3Q7IGNo YWlucywgdGhlIGFyY2hpdGVjdHVyYWwgY2hvaWNlIHRoYXQgZm9sbG93cyB0aGUgcHJpbmNpcGxl cyBpcyB0byBjYXJyeSB0aGUgU0ZQIGlkLiBJdCBpcyAoYWxzbykgdG8gY29udmV5IHNoYXJlZCBj b250ZXh0ICh3aGVuIGRlbWFuZGVkIGJ5IHRoZSB1c2UgY2FzZSkgdXNpbmcgdGhlIFNGQy1lbmNh cHN1bGF0aW9uIGZvciBzaW1pbGFyIHJlYXNvbnMuIEFzIGEgV0csIEkgYmVsaWV2ZSB3ZSBzaG91 bGQgZmlyc3Qgc3RyaXZlDQogZm9yIGEgc2luZ2xlJm5ic3A7c2VydmljZS1sZXZlbCBkYXRhIHBs YW5lIGVuY2Fwc3VsYXRpb24gYXMgcGVyIHRoZSBjdXJyZW50IFdHIGNoYXJ0ZXIgYW5kIGJhc2Vk IG9uIHRoYXQgcHJvdmlkZSB0aGUgbW9zdCBvcHRpbWFsIHBsYWNlbWVudCBvZiBmdW5jdGlvbnMg YW5kIGlkZW50aWZpZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+Tm90ZSBhbHNvIHRoYXQgSSB3YXMgcG9pbnRpbmcgdG8gdGhlIGNoYXJ0ZXIgYmVj YXVzZSBJIGJlbGlldmUgdGhlc2UgcG9pbnRzIHdlcmUgZGlzY3Vzc2VkIGFscmVhZHkgdG8gZ2V0 IHRvIHRoZSBjdXJyZW50IGNoYXJ0ZXIgdGV4dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJlc3QsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5DYXJsb3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBBdWcgMTEsIDIwMTQs IGF0IDEwOjQ3IEFNLCBMdWN5IHlvbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpsdWN5LnlvbmdAaHVh d2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmx1Y3kueW9uZ0BodWF3ZWkuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkkgYWdyZWUgQW5keeKAmXMgcG9pbnQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MdWN5PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m bmJzcDtzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZzwvc3Bhbj48L2E+XSZuYnNwOzxiPk9uDQogQmVoYWxmIE9mJm5ic3A7PC9iPkFuZHJldyBH LiBNYWxpczxicj4NCjxiPlNlbnQ6PC9iPiZuYnNwO0ZyaWRheSwgQXVndXN0IDA4LCAyMDE0IDQ6 NDcgUE08YnI+DQo8Yj5Ubzo8L2I+Jm5ic3A7Q2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpPGJy Pg0KPGI+Q2M6PC9iPiZuYnNwO1h1eGlhb2h1OyBEb2xnYW5vdywgQW5kcmV3IChBbmRyZXcpOyZu YnNwOzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5zZmNAaWV0Zi5vcmc8L3NwYW4+PC9hPjsgSm9lbCBNLiBIYWxw ZXJuPGJyPg0KPGI+U3ViamVjdDo8L2I+Jm5ic3A7UmU6IFtzZmNdIERlZmluaXRpb24gb2YgU0ZD IEVuY2Fwc3VsYXRpb24gaW4gZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUtMDEudHh0PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNhcmxvcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGFn cmVlIHRoYXQgdGhlIGNoYXJ0ZXIgcmVxdWlyZXMgdGhlIGVuY2Fwc3VsYXRpb24gdG8gc3VwcG9y dCBlYWNoIG9mIHRoZSBidWxsZXQgaXRlbXMsIGJ1dCB0aGVyZSdzIG5vIHJlcXVpcmVtZW50IHRo YXQgZXZlcnkgZW5jYXBzdWxhdGVkIHBhY2tldCB3aWxsIG5lZWQgYWxsIG9mIHRoZSBidWxsZXQg aXRlbXMgc3VwcG9ydGVkLCBzbyBJJ20gdHJ5aW5nIHRvIGtlZXAgdGhlDQogdGV4dCBhcyBmbGV4 aWJsZSBhcyBwb3NzaWJsZSB0byBub3QgcHJlY2x1ZGUgcG9zc2libGUgc29sdXRpb25zLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5BbmR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIEZyaSwgQXVn IDgsIDIwMTQgYXQgMTE6MDkgQU0sIENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPmNwaWduYXRhQGNpc2NvLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGksIEFuZHJldyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpPbiBBdWcgOCwgMjAxNCwgYXQgODo1 MyBBTSwgRG9sZ2Fub3csIEFuZHJldyAoQW5kcmV3KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHJl dy5kb2xnYW5vd0BhbGNhdGVsLWx1Y2VudC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5hbmRyZXcuZG9sZ2Fub3dAYWxjYXRlbC1sdWNlbnQuY29tPC9zcGFu PjwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZndDsgSSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBo YXZlIHN0cm9uZ2VyIHNlcGFyYXRpb24gb2YgdHdvIGZ1bmN0aW9uczogU0ZQIGFuZCBtZXRhZGF0 YS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBIb3cgYWJvdXQgc21hbGwgZWRpdCB0byB3aGF0IEFuZHkg cHJvcG9zZWQ6PGJyPg0KJmd0Ozxicj4NCiZndDsgU0ZDIEVuY2Fwc3VsYXRpb246ICZuYnNwO0Eg ZGF0YSBwbGFuZSBlbmNhcHN1bGF0aW9uIHRoYXQgZW5jb2RlcyBlaXRoZXIgb25lIG9yIGJvdGgg b2Y8YnI+DQomZ3Q7IC0gdGhlIFNGUDxicj4NCiZndDsgLSBtZXRhZGF0YSAoZGF0YSBwbGFuZSBj b250ZXh0IGluZm9ybWF0aW9uKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TG9va2luZyBhdCZuYnNw OzxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9zZmMvY2hhcnRlci8iIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvd2cvc2ZjL2NoYXJ0ZXIvPC9zcGFuPjwvYT4sIHRoZXJlIGlzIG5vICZxdW90 O2VpdGhlciBvbmUgb3IgYm90aCBvZiZxdW90Oy4gSW4gZmFjdCwgbG9va2luZw0KIGF0IHRoZSBo aXN0b3J5IG9mIHRoZSBjaGFydGVyIHRleHQsIHRoZSB0ZXh0IGZvciBTRkMgRW5jYXBzdWxhdGlv biBpcyBhIGJ1bGxldCBsaXN0IGZvcm0gb2YgYSBsb25nZXIgc2VudGVuY2UgdGhhdCBpbmNsdWRl cyAmcXVvdDthbmQmcXVvdDsgb25seSAoc2VlIDAwLTA5KS48YnI+DQo8YnI+DQpUaGFua3MsPGJy Pg0KPGJyPg0KQ2FybG9zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxicj4NCiZndDsmZ3Q7IFRoZSBTRlAgRW5jYXBzdWxhdGlvbiBpcyB1c2VkIGJ5 IHRoZSBTRkMtYXdhcmUgZnVuY3Rpb25zLCBzdWNoIGFzIHRoZSBTRkYgYW5kIFNGQy1hd2FyZSBT RnMsIGFuZCBpcyBub3QgdXNlZCBmb3IgbmV0d29yayBwYWNrZXQgZm9yd2FyZGluZy48YnI+DQom Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgQW5kcmV3PGJyPg0KJmd0Ozxicj4NCiZndDsgU2VudCBm cm9tIG15IGlQaG9uZTxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyBPbiBBdWcgNywgMjAxNCwgYXQg OToxMyBQTSwgJnF1b3Q7WHV4aWFvaHUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp4dXhpYW9o dUBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ eHV4aWFvaHVAaHVhd2VpLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7IEkgZnVsbHkgYWdyZWUgd2l0aCBBbmR54oCZcyBwb2ludCB0aGF0IG5vdCBl dmVyeSB1c2FnZSBvZiB0aGUgZW5jYXBzdWxhdGlvbiB3aWxsIG5lZWQgYm90aCB0aGUgU0ZQIGlk ZW50aWZpY2F0aW9uIGFuZCB0aGUgbWV0YWRhdGEuIEl04oCZcyBiZXR0ZXIgdGhhdCB0aGUgU0ZD IGVuY2Fwc3VsYXRpb24gY291bGQgYmUgZmxleGlibHkgdXNlZCBmb3IgY2FycnlpbmcgU0ZQIGlk ZW50aWZpY2F0aW9uLCBtZXRhZGF0YSBvciBib3RoLiBPdGhlcndpc2UsDQogaXQgc2VlbXMgdGhh dCB0aG9zZSBTRkMgYXBwcm9hY2hlcyB3aGljaCBkb27igJl0IHVzZSB0aGUgU0ZDIGVuY2Fwc3Vs YXRpb24gZm9yIFNGQyBzZWxlY3Rpb24gd291bGQgaGF2ZSB0byBzZXBhcmF0ZWx5IGRlZmluZSB0 aGUgd2F5IG9mIGNhcnJ5aW5nIG1ldGFkYXRhLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg QmVzdCByZWdhcmRzLDxicj4NCiZndDsmZ3Q7IFhpYW9odTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgRnJvbTogc2ZjIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+c2ZjLWJvdW5j ZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl0gT24gQmVoYWxmIE9mIEFuZHJldyBHLiBNYWxpczxicj4N CiZndDsmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMDcsIDIwMTQgOTowNiBQTTxicj4NCiZn dDsmZ3Q7IFRvOiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSk8YnI+DQomZ3Q7Jmd0OyBDYzog Sm9lbCBNLiBIYWxwZXJuOyZuYnNwOzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5zZmNAaWV0Zi5vcmc8L3NwYW4+ PC9hPjxicj4NCiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbc2ZjXSBEZWZpbml0aW9uIG9mIFNGQyBF bmNhcHN1bGF0aW9uIGluIGRyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAxLnR4dDxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQ2FybG9zLDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgV2hlbiBJIHJlLXJlYWQgdGhlIGRlZmluaXRpb24sIGl0IHNlZW1lZCB0byBtZSB0byBiZSBt b3JlIG9mIGEgc3RyaW5nIG9mIHRob3VnaHRzIHRoYW4gYSBjb25jaXNlIGRlZmluaXRpb24sIHdo aWNoIGlzIHdoeSBJIHdhcyB0cnlpbmcgdG8gdGlnaHRlbiBpdCB1cC4gQSBkZWZpbml0aW9uIGlz IG1lYW50IHRvIGJlIGEgc2hvcnQgc3VtbWFyeSBmb3IgcXVpY2sgcmVmZXJlbmNlLCB3aGlsZSB0 aGUgZGlzY3Vzc2lvbiBpbiA0LjEgZ29lcyBpbnRvDQogdGhlIG1vcmUgZm9ybWFsIGRldGFpbHMu ICZuYnNwO090aGVyd2lzZSwgeW91IHdvdWxkIGp1c3QgcmVwZWF0IHRoZSBlbnRpcmUgc2VjdGlv biA0LjEgaW4gc2VjdGlvbiAxLjMuICZuYnNwO1RoaXMgaXMgd2h5IGl0IGRvZXNuJ3QgbmVlZCB0 byBiZSBpbiBzZXBhcmF0ZSBzZW50ZW5jZXMuIFRoZSAmcXVvdDthbmQvb3ImcXVvdDsgaXMgYmVj YXVzZSBub3QgZXZlcnkgdXNhZ2Ugb2YgdGhlIGVuY2Fwc3VsYXRpb24gd2lsbCBuZWVkIGJvdGgg dGhlIFNGUCBpZGVudGlmaWNhdGlvbiBhbmQNCiB0aGUgbWV0YWRhdGEsIHNvIHRoZSBkZWZpbml0 aW9uIG5lZWRzIHRvIGNvbmNpc2VseSBjb252ZXkgdGhhdC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7IENoZWVycyw8YnI+DQomZ3Q7Jmd0OyBBbmR5PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyBPbiBUaHUsIEF1ZyA3LCAyMDE0IGF0IDg6NTEgQU0sIENhcmxvcyBQaWduYXRhcm8gKGNw aWduYXRhKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmNwaWduYXRhQGNpc2NvLmNvbTwvc3Bh bj48L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBUaGFuayB5b3UgZm9yIGdvaW5nIGJhY2sg YW5kIGNoZWNraW5nLCBBbmR5ITxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgV2hpY2ggc3Bl Y2lmaWMgcGFydCBvZiB0aGUgY3VycmVudCBkZWZpbml0aW9uIGRvIHlvdSBiZWxpZXZlIGlzIGxv b3NlIGVub3VnaCB0byBuZWVkIHRpZ2h0ZW5pbmc/PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyBJIGJlbGlldmUgdGhhdCB5b3VyIG5ldyBwcm9wb3NhbCBmYWxscyBzaG9ydGVyIHRoYW4gdGhl IGV4aXN0aW5nIHRleHQgaW4gYSBmZXcgYXJlYXM6PGJyPg0KJmd0OyZndDsg4oCiIEZpcnN0LCBp dCBjb21iaW5lcyB0d28gZGlmZmVyZW50IGZ1bmN0aW9ucyAoU0ZQIGlkZW50aWZpY2F0aW9uIGFu ZCBtZXRhZGF0YS9jb250ZXh0IGluZm9ybWF0aW9uKSBpbnRvIGEgc2luZ2xlIHNlbnRlbmNlLiBU aGlzIG9wcG9zZXMgdGhlIGNoYW5nZSB3ZSBqdXN0IG1hZGUgYmFzZWQgb24geW91ciBwcmVmZXJl bmNlIGluIFNlY3Rpb24gNC4xLCB3aGljaCBicmVha3MgdGhlIHR3byBmdW5jdGlvbnMgaW50byB0 d28gc2VudGVuY2VzLCBmb3INCiByZWFkZXIgY2xhcml0eS4gV2hpbGUgbG9uZ2VyLCBpdCdzIHNp bXBsZXIuPGJyPg0KJmd0OyZndDsg4oCiIFNlY29uZCwgaXQgaW50cm9kdWNlcyBhbiBleHRyYW5l b3VzICZxdW90O2FuZC9vciZxdW90OyB0aGF0IHdvdWxkIGNoYW5nZSB0aGUgbWVhbmluZywgYW5k IG5lZ2F0ZSB0aGUgJnF1b3Q7YXQgYSBtaW5pbXVtJnF1b3Q7IGV4aXN0aW5nIGJpdC4gVGhhdCB3 b3VsZCBub3QgYmUgc2ltcGxpZnlpbmcuPGJyPg0KJmd0OyZndDsg4oCiIFRoaXJkLCB0aGVyZSBp cyBubyB0aGlyZCBidXQgdGhyZWUgYnVsbGV0cyBsb29rIGJldHRlciA6LSk8YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7IE5ldC1uZXQsIHRoZSBvcmlnaW5hbCB0ZXh0LCBldmVuIHdoZW4gbG9u Z2VyIGluIGNoYXJhY3RlciBjb3VudCwgc2VlbXMgbW9yZSBjbGVhciBhbmQgc2ltcGxlciB0byB0 aGUgcmVhZGVyIChiZWNhdXNlIG9mIHRoZSBzZXBhcmF0ZWQgc2VudGVuY2VzKSwgSU1ITy48YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7IENhcmxvcy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE9uIEF1ZyA3LCAyMDE0LCBh dCA4OjIwIEFNLCBBbmRyZXcgRy4gTWFsaXMgJmx0OzxhIGhyZWY9Im1haWx0bzphZ21hbGlzQGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmFnbWFs aXNAZ21haWwuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyBDYXJsb3MgYW5kIEpvZWwsPGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyBJbiBsaWdodCBvZiB0aGUgcHJldmlvdXMgZGlzY3Vzc2lvbnMsIEkgd2VudCBiYWNr IGFuZCByZS1yZWFkIHRoaXMgY3VycmVudCBkZWZpbml0aW9uIG9mIFNGQyBFbmNhcHN1bGF0aW9u IGluIHRoZSB0ZXh0IChzZWN0aW9uIDEuMyk6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAm bmJzcDsgU0ZDIEVuY2Fwc3VsYXRpb246ICZuYnNwO1RoZSBTRkMgRW5jYXBzdWxhdGlvbiBwcm92 aWRlcyBhdCBhIG1pbmltdW0gU0ZQPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7aWRlbnRpZmljYXRpb24sIGFuZCBpcyB1c2VkIGJ5IHRoZSBTRkMtYXdhcmUgZnVuY3Rp b25zLCBzdWNoIGFzPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhl IFNGRiBhbmQgU0ZDLWF3YXJlIFNGcy4gJm5ic3A7VGhlIFNGQyBFbmNhcHN1bGF0aW9uIGlzIG5v dCB1c2VkPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Zm9yIG5ldHdv cmsgcGFja2V0IGZvcndhcmRpbmcuICZuYnNwO0luIGFkZGl0aW9uIHRvIFNGUDxicj4NCiZndDsm Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2lkZW50aWZpY2F0aW9uLCB0aGUgU0ZDIGVu Y2Fwc3VsYXRpb24gY2FycmllcyBkYXRhcGxhbmUgY29udGV4dDxicj4NCiZndDsmZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2luZm9ybWF0aW9uLCBhbHNvIHJlZmVycmVkIHRvIGFzIG1l dGFkYXRhLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSB0aGluayB0aGlzIGNvdWxkIGJl IHRpZ2h0ZW5lZCB1cCB0byBtYWtlIHNpbXBsZXIgZm9yIHRoZSByZWFkZXI6PGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyBTRkMgRW5jYXBzdWxhdGlvbjogJm5ic3A7QSBkYXRhIHBsYW5lIGVu Y2Fwc3VsYXRpb24gdGhhdCBpZGVudGlmaWVzIHRoZSBTRlAgYW5kL29yIHByb3ZpZGVzIG1ldGFk YXRhIChkYXRhIHBsYW5lIGNvbnRleHQgaW5mb3JtYXRpb24pLiBUaGUgU0ZQIEVuY2Fwc3VsYXRp b24gaXMgdXNlZCBieSB0aGUgU0ZDLWF3YXJlIGZ1bmN0aW9ucywgc3VjaCBhcyB0aGUgU0ZGIGFu ZCBTRkMtYXdhcmUgU0ZzLCBhbmQgaXMgbm90IHVzZWQgZm9yIG5ldHdvcmsgcGFja2V0DQogZm9y d2FyZGluZy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0 OyBBbmR5PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQomZ3Q7Jmd0OyBzZmMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsmbmJzcDs8YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+c2ZjQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQomZ3Q7Jmd0OyZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_6EB34CB5D82C4645B826C56144826EA97EA562B1SZXEMA509MBXchi_-- From nobody Thu Aug 14 04:07: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 5FCD41A0A0D for ; Thu, 14 Aug 2014 04:07:38 -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 ylNvA11IG5E1 for ; Thu, 14 Aug 2014 04:07:36 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B191A0A06 for ; Thu, 14 Aug 2014 04:07:35 -0700 (PDT) Received: by mail-ig0-f180.google.com with SMTP id l13so4596671iga.7 for ; Thu, 14 Aug 2014 04:07:35 -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=gwnnKxVJLCZlz2qBvsy/Hg3iPhPhpfzFmMQarwUKURE=; b=u25djTPh6oKWWf/Z5k1I813FTp80MrbFrfvACywW0/HFhPpNAbi+6Lom28Z+XKzOLU snaQ5GGAQK+CYefbhNYSqU2WeCPgwfn02SjWempCppM497pjQWbP7EeQ5jLNXsOd6f/n G3RVXwikVsL4rm2BH6OReyOmwPjNmeROeG7wsZvvDovhmGp8RLTMuCGFO5sRrTCD4UiN zErWsLzMw6o0cwVZ1laxD5JbpccHUCS2JcbIEvyg9c1yGLCSZgwezL5r8uT1EUUC2Clw +8y8KqP3XAbLofiz+BY2facDstI6plP5Ep7mVxPOFTx+OgZ89wX7sN68Jyh6qod/hW7I hu7Q== X-Received: by 10.50.117.106 with SMTP id kd10mr15861187igb.5.1408014455446; Thu, 14 Aug 2014 04:07:35 -0700 (PDT) Received: from [192.168.97.172] ([67.210.160.130]) by mx.google.com with ESMTPSA id u7sm83582160igb.10.2014.08.14.04.07.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Aug 2014 04:07:35 -0700 (PDT) Message-ID: <53EC9876.8070809@gmail.com> Date: Thu, 14 Aug 2014 07:07:34 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Hongyu Li (Julio)" , Cathy Zhang , "Andrew G. Malis" , "Carlos Pignataro (cpignata)" References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A4805@NKGEML512-MBS.china.huawei.com> <57B2ECF6-8DB4-4E23-BB14-E030EB74E09C@alcatel-lucent.com> <2691CE0099834E4A9C5044EEC662BB9D453CBFBE@dfweml701-chm.china.huawei.com> <5F8C4A2F-3C60-459D-92F7-31EA1DA9E469@cisco.com> <6EB34CB5D82C4645B826C56144826EA97EA562B1@SZXEMA509-MBX.china.huawei.com> In-Reply-To: <6EB34CB5D82C4645B826C56144826EA97EA562B1@SZXEMA509-MBX.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/dxgKpRDqsNEzJBfUU0GJRcdOV7g Cc: Xuxiaohu , "Dolganow, Andrew \(Andrew\)" , Lucy yong , "sfc@ietf.org" , "Joel M. Halpern" Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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, 14 Aug 2014 11:07:38 -0000 I would think an SFF receiving an SFP ID value of zero would interpret it to mean that there is no next hop. Tom Taylor On 14/08/2014 12:01 AM, Hongyu Li (Julio) wrote: > Hi all, > > I noticed there were some discussion that SFP ID could be null or > zero. However, there wes not any persuasive use case or scenario > provided so far. In case of expecting interoperability with legacy > devices, an existing protocol is needed, meaning carrying metadata > with such a protocol is not possible either, as any modification to > the protocol will lead to modification of legacy devices. > > If SFP ID is null or zero, how could you find the next hop in each > SFF? Where is the SFC/SFP layer? > ... From nobody Thu Aug 14 08:40: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 6F25E1A0AB1 for ; Thu, 14 Aug 2014 08:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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.668, 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 MNQUx7kZVMA7 for ; Thu, 14 Aug 2014 08:40:39 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CB2F1A074B for ; Thu, 14 Aug 2014 08:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26598; q=dns/txt; s=iport; t=1408030839; x=1409240439; h=from:to:cc:subject:date:message-id:references: mime-version; bh=wSo5IwvQMcaP54Wiq602vkkQ79dMw/v5Ykniuqhln4M=; b=IeRsVPtKUxwhceXCx7D7l/mev/Ucol8WzarBHH1XGUHDOmVKjf5J1kDd kOOQs3oUsfYu6nFrz0WJhF3UCHOsEvS8oJkJ7JIk9v95K0xENObbm4Yud e2YBVpLaa+L8clkfNvdi8y3hrZL6D9baP2veBbtrlH22aasRo4/oJOp1j I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcFACLY7FOtJV2b/2dsb2JhbABZgkcjI1NXBLItmV2BWQEJh0kBgRcWd4QDAQEBAwEBAQELD0gCBwsFCwIBCBEBAwEBASAHByEGCxQDBggCBA4FG4gTAwkIAQzAEg2FSBeJf4MggikEBoMwgR0FjwqCE4QmhGiCDoFXjHSGM4IWgUZsgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.01,863,1400025600"; d="scan'208,217";a="347539881" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 14 Aug 2014 15:40:38 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s7EFebpV006704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Aug 2014 15:40:37 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Thu, 14 Aug 2014 10:40:37 -0500 From: "Carlos Pignataro (cpignata)" To: "Andrew G. Malis" Thread-Topic: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt Thread-Index: AQHPsjoEpUaq91+aSUyfBy1ywE3Zow== Date: Thu, 14 Aug 2014 15:40:36 +0000 Message-ID: <3DCDEFE3-081D-470A-B330-1A01A618111E@cisco.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A4805@NKGEML512-MBS.china.huawei.com> <57B2ECF6-8DB4-4E23-BB14-E030EB74E09C@alcatel-lucent.com> <2691CE0099834E4A9C5044EEC662BB9D453CBFBE@dfweml701-chm.china.huawei.com> <5F8C4A2F-3C60-459D-92F7-31EA1DA9E469@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.168.134] Content-Type: multipart/alternative; boundary="_000_3DCDEFE3081D470AB3301A01A618111Eciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/4MA-iQOP1N7HhYadxHKhCfe3SJo Cc: Xiaohu Xu , "Dolganow, Andrew \(Andrew\)" , "sfc@ietf.org" , Lucy yong , "Joel M. Halpern" Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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, 14 Aug 2014 15:40:42 -0000 --_000_3DCDEFE3081D470AB3301A01A618111Eciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Andy, Thanks for the response -- from an architecture perspective, what I think i= s important to capture is that the SFC Encapsulation carries the specificat= ion of the Service Function Path. I believe that the specifics of how that = happens in the SFP ID belongs in the encapsulation document. But architectu= rally we want to capture that the SFC encapsulation specifies the SFP and h= ave a clean and simple architecture independent of transports and underlyin= g topologies. Now, separately from this specific discussion, you do mention discussion of= specific cases and a potential encap value for that. Could you share some = more specifics? This would be useful for the discussion of the encapsulatio= n WG deliverable. Xiaohu shared two pointers to two individual I-Ds, and it= seems (again, not an architectural comment but jumping ahead) that a null = SPF ID would not make those cases interoperate. Does that call for a per-tr= ansport solution against the charter? Looking at the draft-ietf-sfc-problem= -statement, specifically Sections 2.1 and 2.6, the reason why SFC exists is= to provide that transport and topological independence as opposed to exist= ing (transport dependent) ways of chaining network services. Thanks, Carlos. On Aug 13, 2014, at 9:47 AM, Andrew G. Malis > wrote: Carlos, I see your point, but there's also been discussion of cases where only the = metadata is required. In that case, you woud either be carrying a null SFP = ID along with the metadata, or just the metadata. It seems more efficient t= o me to just carry the metadata, but if you want to insist that there's alw= ays an SPF ID, then we need to make sure that it can be a null ID. Cheers, Andy On Tue, Aug 12, 2014 at 9:51 PM, Carlos Pignataro (cpignata) > wrote: Hi, Andy, Lucy, Flexibility is certainly good as long as it does not get in the way of inte= roperability. This architecture drives a balance and tradeoff in which opti= ons are maximized while having interoperability as the goal. >From a technical perspective, the SFC Encapsulation specifies the Service F= unction Path to allow for end-to-end SFPs and interoperable implementations= . One of the key principles of this architecture is that the SFC Encapsulat= ion is transport-independent. The text is flexible such that any transport = may be used to carry the SFC encapsulation. However, two SFs part of an SFP= that are not adjacent in the services topology can have different transpor= t encapsulations but need the SFC-encapsulation (minimum invariant encap) t= o specify the SPF. This is within the service topology, which again is inde= pendent from the underlay topology as an architectural principle. Please no= te that the use of the SFC encapsulation to specify the SFP and the SFFs an= d SFs use of this is articulated throughout the architecture. This architec= ture also allows for flexibility in bringing SFC-unaware SFs by proxy as th= e one gateway, to provide backwards compatibility, but attempts to carry fo= rward interoperability. Consequently, for "SFC Aware" chains, the architect= ural choice that follows the principles is to carry the SFP id. It is (also= ) to convey shared context (when demanded by the use case) using the SFC-en= capsulation for similar reasons. As a WG, I believe we should first strive = for a single service-level data plane encapsulation as per the current WG c= harter and based on that provide the most optimal placement of functions an= d identifiers. Note also that I was pointing to the charter because I believe these points= were discussed already to get to the current charter text. Best, Carlos. On Aug 11, 2014, at 10:47 AM, Lucy yong > wrote: I agree Andy=B9s point. Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Andrew G. Malis Sent: Friday, August 08, 2014 4:47 PM To: Carlos Pignataro (cpignata) Cc: Xuxiaohu; Dolganow, Andrew (Andrew); sfc@ietf.org;= Joel M. Halpern Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-arch= itecture-01.txt Carlos, I agree that the charter requires the encapsulation to support each of the = bullet items, but there's no requirement that every encapsulated packet wil= l need all of the bullet items supported, so I'm trying to keep the text as= flexible as possible to not preclude possible solutions. Cheers, Andy On Fri, Aug 8, 2014 at 11:09 AM, Carlos Pignataro (cpignata) > wrote: Hi, Andrew, On Aug 8, 2014, at 8:53 AM, Dolganow, Andrew (Andrew) > wrote: > I agree that we should have stronger separation of two functions: SFP and= metadata. > > How about small edit to what Andy proposed: > > SFC Encapsulation: A data plane encapsulation that encodes either one or= both of > - the SFP > - metadata (data plane context information). Looking at http://datatracker.ietf.org/wg/sfc/charter/, there is no "either= one or both of". In fact, looking at the history of the charter text, the = text for SFC Encapsulation is a bullet list form of a longer sentence that = includes "and" only (see 00-09). Thanks, Carlos. >> The SFP Encapsulation is used by the SFC-aware functions, such as the SF= F and SFC-aware SFs, and is not used for network packet forwarding. > > > Andrew > > Sent from my iPhone > >> On Aug 7, 2014, at 9:13 PM, "Xuxiaohu" > wrote: >> >> I fully agree with Andy=B9s point that not every usage of the encapsulat= ion will need both the SFP identification and the metadata. It=B9s better t= hat the SFC encapsulation could be flexibly used for carrying SFP identific= ation, metadata or both. Otherwise, it seems that those SFC approaches whic= h don=B9t use the SFC encapsulation for SFC selection would have to separat= ely define the way of carrying metadata. >> >> Best regards, >> Xiaohu >> >> From: sfc [mailto:sfc-bounces@ietf.org] On = Behalf Of Andrew G. Malis >> Sent: Thursday, August 07, 2014 9:06 PM >> To: Carlos Pignataro (cpignata) >> Cc: Joel M. Halpern; sfc@ietf.org >> Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-a= rchitecture-01.txt >> >> Carlos, >> >> When I re-read the definition, it seemed to me to be more of a string of= thoughts than a concise definition, which is why I was trying to tighten i= t up. A definition is meant to be a short summary for quick reference, whil= e the discussion in 4.1 goes into the more formal details. Otherwise, you = would just repeat the entire section 4.1 in section 1.3. This is why it do= esn't need to be in separate sentences. The "and/or" is because not every u= sage of the encapsulation will need both the SFP identification and the met= adata, so the definition needs to concisely convey that. >> >> Cheers, >> Andy >> >> On Thu, Aug 7, 2014 at 8:51 AM, Carlos Pignataro (cpignata) > wrote: >> Thank you for going back and checking, Andy! >> >> Which specific part of the current definition do you believe is loose en= ough to need tightening? >> >> I believe that your new proposal falls shorter than the existing text in= a few areas: >> =80 First, it combines two different functions (SFP identification and m= etadata/context information) into a single sentence. This opposes the chang= e we just made based on your preference in Section 4.1, which breaks the tw= o functions into two sentences, for reader clarity. While longer, it's simp= ler. >> =80 Second, it introduces an extraneous "and/or" that would change the m= eaning, and negate the "at a minimum" existing bit. That would not be simpl= ifying. >> =80 Third, there is no third but three bullets look better :-) >> >> Net-net, the original text, even when longer in character count, seems m= ore clear and simpler to the reader (because of the separated sentences), I= MHO. >> >> Thanks, >> >> Carlos. >> >> On Aug 7, 2014, at 8:20 AM, Andrew G. Malis > wrote: >> >> >> Carlos and Joel, >> >> In light of the previous discussions, I went back and re-read this curre= nt definition of SFC Encapsulation in the text (section 1.3): >> >> SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP >> identification, and is used by the SFC-aware functions, such as >> the SFF and SFC-aware SFs. The SFC Encapsulation is not used >> for network packet forwarding. In addition to SFP >> identification, the SFC encapsulation carries dataplane context >> information, also referred to as metadata. >> >> I think this could be tightened up to make simpler for the reader: >> >> SFC Encapsulation: A data plane encapsulation that identifies the SFP a= nd/or provides metadata (data plane context information). The SFP Encapsula= tion is used by the SFC-aware functions, such as the SFF and SFC-aware SFs,= and is not used for network packet forwarding. >> >> Thanks, >> Andy >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc --_000_3DCDEFE3081D470AB3301A01A618111Eciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi, Andy,

Thanks for the response -- from an architecture perspective, what I th= ink is important to capture is that the SFC Encapsulation carries the speci= fication of the Service Function Path. I believe that the specifics of how = that happens in the SFP ID belongs in the encapsulation document. But architecturally we want to capture that= the SFC encapsulation specifies the SFP and have a clean and simple archit= ecture independent of transports and underlying topologies.

Now, separately from this specific discussion, you do mention discussi= on of specific cases and a potential encap value for that. Could you share = some more specifics? This would be useful for the discussion of the encapsu= lation WG deliverable. Xiaohu shared two pointers to two individual I-Ds, and it seems (again, not an architect= ural comment but jumping ahead) that a null SPF ID would not make those cas= es interoperate. Does that call for a per-transport solution against the ch= arter? Looking at the draft-ietf-sfc-problem-statement, specifically Sections 2.1 and 2.6, the reason why SFC exists is to provide= that transport and topological independence as opposed to existing (transp= ort dependent) ways of chaining network services. 

Thanks,

Carlos.

On Aug 13, 2014, at 9:47 AM, Andrew G. Malis <agmalis@gmail.com> wrote:

Carlos,

I see your point, but there's also been discussion of cases where only= the metadata is required. In that case, you woud either be carrying a null= SFP ID along with the metadata, or just the metadata. It seems more effici= ent to me to just carry the metadata, but if you want to insist that there's always an SPF ID, then we need to m= ake sure that it can be a null ID.

Cheers,
Andy


On Tue, Aug 12, 2014 at 9:51 PM, Carlos Pignatar= o (cpignata) <cpignata@cisco.com> wrote:
Hi, Andy, Lucy,

Flexibility is certainly good as long as it does not get in the way of= interoperability. This architecture drives a balance and tradeoff in which= options are maximized while having interoperability as the goal.

From a technical perspective, the SFC Encapsulation specifies the Serv= ice Function Path to allow for end-to-end SFPs and interoperable implementa= tions. One of the key principles of this architecture is that the SFC Encap= sulation is transport-independent. The text is flexible such that any transport may be used to carry the SFC = encapsulation. However, two SFs part of an SFP that are not adjacent in the= services topology can have different transport encapsulations but need the= SFC-encapsulation (minimum invariant encap) to specify the SPF. This is within the service topology, which agai= n is independent from the underlay topology as an architectural principle. = Please note that the use of the SFC encapsulation to specify the SFP and th= e SFFs and SFs use of this is articulated throughout the architecture. This architecture also allows for flexibility= in bringing SFC-unaware SFs by proxy as the one gateway, to provide backwa= rds compatibility, but attempts to carry forward interoperability. Conseque= ntly, for "SFC Aware" chains, the architectural choice that follows the principles is to carry the SFP id. I= t is (also) to convey shared context (when demanded by the use case) using = the SFC-encapsulation for similar reasons. As a WG, I believe we should fir= st strive for a single service-level data plane encapsulation as per the current WG charter and based on that p= rovide the most optimal placement of functions and identifiers.

Note also that I was pointing to the charter because I believe these p= oints were discussed already to get to the current charter text.

Best,

Carlos.

On Aug 11, 2014, at 10:47 AM, Lucy yong <lucy.yong@huawei.com> wrote:

I agree Andy=B9s point.
 
Lucy
 
 
Carlos,
 
I agree that the charter requires the encapsulation to support each of the = bullet items, but there's no requirement that every encapsulated packet wil= l need all of the bullet items supported, so I'm trying to keep the text as= flexible as possible to not preclude possible solutions.
 
Cheers,
Andy

 

On Fri, Aug 8, 2014 at 11:09 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
Hi, Andrew,


On Aug 8, 2014, at 8:53 AM, Dolganow, Andrew (Andrew) <andrew.dolganow@alcatel-lucent.com> wro= te:

> I agree that we should have stronger separation of two functions: SFP = and metadata.
>
> How about small edit to what Andy proposed:
>
> SFC Encapsulation:  A data plane encapsulation that encodes eithe= r one or both of
> - the SFP
> - metadata (data plane context information).

Looking at http://datatracker.ietf.org/wg/sfc/charter/, there is no "either= one or both of". In fact, looking at the history of the charter text, the text for SFC Encapsulation is a bullet list form = of a longer sentence that includes "and" only (see 00-09).

Thanks,

Carlos.


>> The SFP Encapsulation is used by the SFC-aware functions, such as = the SFF and SFC-aware SFs, and is not used for network packet forwarding. >
>
> Andrew
>
> Sent from my iPhone
>
>> On Aug 7, 2014, at 9:13 PM, "Xuxiaohu" <xuxiaohu@huawei.com> wrote:
>>
>> I fully agree with Andy=B9s point that not every usage of the enca= psulation will need both the SFP identification and the metadata. It=B9s be= tter that the SFC encapsulation could be flexibly used for carrying SFP ide= ntification, metadata or both. Otherwise, it seems that those SFC approaches which don=B9t use the SFC encapsulation= for SFC selection would have to separately define the way of carrying meta= data.
>>
>> Best regards,
>> Xiaohu
>>
>> From: sfc [mailto:sfc-bounces@ietf= .org] On Behalf Of Andrew G. Malis
>> Sent: Thursday, August 07, 2014 9:06 PM
>> To: Carlos Pignataro (cpignata)
>> Cc: Joel M. Halpern; sfc= @ietf.org
>> Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged= -sfc-architecture-01.txt
>>
>> Carlos,
>>
>> When I re-read the definition, it seemed to me to be more of a str= ing of thoughts than a concise definition, which is why I was trying to tig= hten it up. A definition is meant to be a short summary for quick reference= , while the discussion in 4.1 goes into the more formal details.  Otherwise, you would just repeat the entire= section 4.1 in section 1.3.  This is why it doesn't need to be in sep= arate sentences. The "and/or" is because not every usage of the e= ncapsulation will need both the SFP identification and the metadata, so the definition needs to concisely convey that.
>>
>> Cheers,
>> Andy
>>
>> On Thu, Aug 7, 2014 at 8:51 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
>> Thank you for going back and checking, Andy!
>>
>> Which specific part of the current definition do you believe is lo= ose enough to need tightening?
>>
>> I believe that your new proposal falls shorter than the existing t= ext in a few areas:
>> =80 First, it combines two different functions (SFP identification= and metadata/context information) into a single sentence. This opposes the= change we just made based on your preference in Section 4.1, which breaks = the two functions into two sentences, for reader clarity. While longer, it's simpler.
>> =80 Second, it introduces an extraneous "and/or" that wo= uld change the meaning, and negate the "at a minimum" existing bi= t. That would not be simplifying.
>> =80 Third, there is no third but three bullets look better :-)
>>
>> Net-net, the original text, even when longer in character count, s= eems more clear and simpler to the reader (because of the separated sentenc= es), IMHO.
>>
>> Thanks,
>>
>> Carlos.
>>
>> On Aug 7, 2014, at 8:20 AM, Andrew G. Malis <agmalis@gmail.com> wrote:
>>
>>
>> Carlos and Joel,
>>
>> In light of the previous discussions, I went back and re-read this= current definition of SFC Encapsulation in the text (section 1.3):
>>
>>   SFC Encapsulation:  The SFC Encapsulation provides at = a minimum SFP
>>        identification, and is used by the SFC-= aware functions, such as
>>        the SFF and SFC-aware SFs.  The SF= C Encapsulation is not used
>>        for network packet forwarding.  In= addition to SFP
>>        identification, the SFC encapsulation c= arries dataplane context
>>        information, also referred to as metada= ta.
>>
>> I think this could be tightened up to make simpler for the reader:=
>>
>> SFC Encapsulation:  A data plane encapsulation that identifie= s the SFP and/or provides metadata (data plane context information). The SF= P Encapsulation is used by the SFC-aware functions, such as the SFF and SFC= -aware SFs, and is not used for network packet forwarding.
>>
>> Thanks,
>> Andy
>>
>>
>>
>> _______________________________________________
>> sfc mailing list
>> sfc@ietf.org
>> ht= tps://www.ietf.org/mailman/listinfo/sfc




--_000_3DCDEFE3081D470AB3301A01A618111Eciscocom_-- From nobody Thu Aug 14 10:12: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 8F6221A6F52 for ; Thu, 14 Aug 2014 10:12:32 -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 5FzRvppm_qV0 for ; Thu, 14 Aug 2014 10:12:31 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABA101A0A0E for ; Thu, 14 Aug 2014 10:12:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 51AEE1CA5BC0 for ; Thu, 14 Aug 2014 10:12:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-126.clppva.east.verizon.net [70.106.135.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id B6DEB1CA5BBE for ; Thu, 14 Aug 2014 10:12:30 -0700 (PDT) Message-ID: <53ECEDFE.8080007@joelhalpern.com> Date: Thu, 14 Aug 2014 13:12:30 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "sfc@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ppsPj4uRCUiIRiadbzVtQL6ikMI Subject: [sfc] Proposed SFC Architecture - SFC Proxy 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, 14 Aug 2014 17:12:32 -0000 In the recent discussion on the SFC Proxy, Carlos and I understood that the current text is unclear. We need to fix it. It turned out that even he and I had different perspectives on what it meant. He has persuaded me that the cleanest approach is not the one I suggested earlier on the list. So I am writing a bit of text to fix the proxy description (and then we will fix any other dangling references.) Since the group is considering adoption of the document, we wanted to make sure that the proposal is one other folks can live with. The approach is to treat the SFC Proxy as a logical element between the SFF and the SF. When the SFF wants to send a packet to an SF which requires proxy support, the packet goes instead to the proxy. The proxy does what is necessary, works with the SF however it needs to, and when the packet comes back puts things back together and hands them back to the SFF. Just as we do not specify the delivery mechanism between the SFF and the SF, we will not specify the delivery mechanism between the SFF and the SFC Proxy or between the SFC Proxy and the SF. I hope this is understandable and acceptable to folks. Thank you, Joel From nobody Thu Aug 14 11:08: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 7E97E1A0248 for ; Thu, 14 Aug 2014 11:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytBoZzqMMUcJ for ; Thu, 14 Aug 2014 11:08:39 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43EC01A00E6 for ; Thu, 14 Aug 2014 11:08:39 -0700 (PDT) Received: from emg-ca-1-2 (localhost [127.0.0.1]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id C2A0753E47; Thu, 14 Aug 2014 11:08:06 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Thu, 14 Aug 2014 11:08:06.757 -0700 x-echoworx-msg-id: 08ca36ea-1744-458f-a670-b74269f0d880 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-2 (JAMES SMTP Server 2.3.2) with SMTP ID 633; Thu, 14 Aug 2014 11:08:06 -0700 (PDT) Received: from HUB021-CA-4.exch021.domain.local (unknown [10.254.4.39]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id A336853E47; Thu, 14 Aug 2014 11:08:06 -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; Thu, 14 Aug 2014 11:08:38 -0700 From: Ron Parker To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Proposed SFC Architecture - SFC Proxy Thread-Index: AQHPt+LzAdfuPDRLkUGmP+KOPuf21JvQZa2Q Date: Thu, 14 Aug 2014 18:08:37 +0000 Message-ID: References: <53ECEDFE.8080007@joelhalpern.com> In-Reply-To: <53ECEDFE.8080007@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] x-source-routing-agent: Processed Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/149octwXVbKiN-9-u6Ok9M_QPcI Subject: Re: [sfc] Proposed SFC Architecture - SFC Proxy 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, 14 Aug 2014 18:08:40 -0000 Joel, That approach sounds reasonable to me. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Thursday, August 14, 2014 1:13 PM To: sfc@ietf.org Subject: [sfc] Proposed SFC Architecture - SFC Proxy In the recent discussion on the SFC Proxy, Carlos and I understood that the= current text is unclear. We need to fix it. It turned out that even he and I had different perspectives on what it mean= t. He has persuaded me that the cleanest approach is not the one I suggest= ed earlier on the list. So I am writing a bit of text to fix the proxy description (and then we wil= l fix any other dangling references.) Since the group is considering adopt= ion of the document, we wanted to make sure that the proposal is one other = folks can live with. The approach is to treat the SFC Proxy as a logical element between the SFF= and the SF. When the SFF wants to send a packet to an SF which requires p= roxy support, the packet goes instead to the proxy. The proxy does what is= necessary, works with the SF however it needs to, and when the packet come= s back puts things back together and hands them back to the SFF. Just as we do not specify the delivery mechanism between the SFF and the SF= , we will not specify the delivery mechanism between the SFF and the SFC Pr= oxy or between the SFC Proxy and the SF. I hope this is understandable and acceptable to folks. Thank you, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Aug 14 18:08:21 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 4C9301A89D8 for ; Thu, 14 Aug 2014 18:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 3jdBfGMn6wOU for ; Thu, 14 Aug 2014 18:08:18 -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 4C5111A89D4 for ; Thu, 14 Aug 2014 18:08:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIG47295; Fri, 15 Aug 2014 01:08:15 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Aug 2014 02:08:15 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.204]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Fri, 15 Aug 2014 09:08:09 +0800 From: Xuxiaohu To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Proposed SFC Architecture - SFC Proxy Thread-Index: AQHPt+TRHm71NG35A0CvhZ4mnfcgXpvQ2nKg Date: Fri, 15 Aug 2014 01:08:08 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A767E@NKGEML512-MBS.china.huawei.com> References: <53ECEDFE.8080007@joelhalpern.com> In-Reply-To: <53ECEDFE.8080007@joelhalpern.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/8PxjMQyvYSATrl4AEWq6KN08wec Subject: Re: [sfc] Proposed SFC Architecture - SFC Proxy 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, 15 Aug 2014 01:08:20 -0000 Hi Joel, The proposed approach looks understandable and acceptable to me. Thanks for= this work. Best regards, Xiaohu -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Friday, August 15, 2014 1:13 AM To: sfc@ietf.org Subject: [sfc] Proposed SFC Architecture - SFC Proxy In the recent discussion on the SFC Proxy, Carlos and I understood that the= current text is unclear. We need to fix it. It turned out that even he and I had different perspectives on what it mean= t. He has persuaded me that the cleanest approach is not the one I suggest= ed earlier on the list. So I am writing a bit of text to fix the proxy description (and then we wil= l fix any other dangling references.) Since the group is considering adopt= ion of the document, we wanted to make sure that the proposal is one other = folks can live with. The approach is to treat the SFC Proxy as a logical element between the SFF= and the SF. When the SFF wants to send a packet to an SF which requires p= roxy support, the packet goes instead to the proxy. The proxy does what is= necessary, works with the SF however it needs to, and when the packet come= s back puts things back together and hands them back to the SFF. Just as we do not specify the delivery mechanism between the SFF and the SF= , we will not specify the delivery mechanism between the SFF and the SFC Pr= oxy or between the SFC Proxy and the SF. I hope this is understandable and acceptable to folks. Thank you, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Aug 15 06:24: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 46A4D1A0AC2 for ; Fri, 15 Aug 2014 06:24:58 -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 IWPo9lmWtwXL for ; Fri, 15 Aug 2014 06:24:56 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2FCE1A0ABF for ; Fri, 15 Aug 2014 06:24:56 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id l6so2279784qcy.5 for ; Fri, 15 Aug 2014 06:24:55 -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=+o5yq0DFgBTbR3nGeeg+kMuAuJiRhuyMNMayrR27bSQ=; b=WAMbTcKKEPjn+Avk/9xrIMscPjNizMJ6tNJn32upjriMMvP5H8G3E2sHAGmCVaeMEv 4xBuSnjL5kHU2DMwyVU0KP86BiNRsXX66KP62Ga92yXIvZSw1b16LHplsnHeLY5wPMoV 6MsF74VHHCBeLdecKSUrkQO6Ba78XAhIv/Ls/RFYM/2V+2Cz0e15TJpAR0EQWOJQr+cO pf7zRixvXYmXSAfhAitacDwn3NYStdp0htA1b1Z4tHNosR3+HqBKlArVhOkL+8Jo6kTc 5Tmj3HPOKO1paiLPxcXtSmiTpJW72JQwAco24ZKpkrGxOZKaUI2/NEF963J8LS2jSttH QvIQ== X-Received: by 10.224.79.139 with SMTP id p11mr26910243qak.93.1408109095815; Fri, 15 Aug 2014 06:24:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.91.99 with HTTP; Fri, 15 Aug 2014 06:24:34 -0700 (PDT) In-Reply-To: <3DCDEFE3-081D-470A-B330-1A01A618111E@cisco.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A4805@NKGEML512-MBS.china.huawei.com> <57B2ECF6-8DB4-4E23-BB14-E030EB74E09C@alcatel-lucent.com> <2691CE0099834E4A9C5044EEC662BB9D453CBFBE@dfweml701-chm.china.huawei.com> <5F8C4A2F-3C60-459D-92F7-31EA1DA9E469@cisco.com> <3DCDEFE3-081D-470A-B330-1A01A618111E@cisco.com> From: "Andrew G. Malis" Date: Fri, 15 Aug 2014 09:24:34 -0400 Message-ID: To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=047d7bdc801a7610fa0500aaf23c Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/2VhDJBi8F_KTUQz-2L5hm540o6E Cc: Xiaohu Xu , "Dolganow, Andrew \(Andrew\)" , "sfc@ietf.org" , Lucy yong , "Joel M. Halpern" Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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, 15 Aug 2014 13:24:58 -0000 --047d7bdc801a7610fa0500aaf23c Content-Type: text/plain; charset=UTF-8 Carlos, Our goal as a WG should be to design the SFC encapsulation is to allow flexibility and wide use in different use case and implementation scenarios. Another practical goal should be encapsulation compactness to the greatest extent possible to avoid packet MTU and fragmentation issues. One scenario/use case that has been discussed is the use of a control plane to install state such that just the metadata (or even just packet header/data) is all that's required to forward packets on the proper path. So for this case, we should be able to have a nonexistent or very compact null value for the SFP ID. Thanks,, Andy On Thu, Aug 14, 2014 at 11:40 AM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Hi, Andy, > > Thanks for the response -- from an architecture perspective, what I > think is important to capture is that the SFC Encapsulation carries the > specification of the Service Function Path. I believe that the specifics of > how that happens in the SFP ID belongs in the encapsulation document. But > architecturally we want to capture that the SFC encapsulation specifies the > SFP and have a clean and simple architecture independent of transports and > underlying topologies. > > Now, separately from this specific discussion, you do mention discussion > of specific cases and a potential encap value for that. Could you share > some more specifics? This would be useful for the discussion of the > encapsulation WG deliverable. Xiaohu shared two pointers to two individual > I-Ds, and it seems (again, not an architectural comment but jumping ahead) > that a null SPF ID would not make those cases interoperate. Does that call > for a per-transport solution against the charter? Looking at > the draft-ietf-sfc-problem-statement, specifically Sections 2.1 and 2.6, > the reason why SFC exists is to provide that transport and topological > independence as opposed to existing (transport dependent) ways of chaining > network services. > > Thanks, > > Carlos. > > > --047d7bdc801a7610fa0500aaf23c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Carlos,

Our goal as a WG should be to= =C2=A0design the SFC encapsulation is to allow flexibility and wide use in = different use case and implementation scenarios. Another practical goal sho= uld be encapsulation compactness to the greatest extent possible to avoid p= acket MTU and fragmentation issues. One scenario/use case that has been dis= cussed is the use of a control plane to install state such that just the me= tadata (or even just packet header/data) is all that's required to forw= ard packets on the proper path. So for this case, we should be able to have= a nonexistent or very compact null value for the SFP ID.

Thanks,,
Andy



On Thu, Aug 14, 2014 at= 11:40 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com>= wrote:
Hi, Andy,

Thanks for the response -- from an architecture perspective, what I th= ink is important to capture is that the SFC Encapsulation carries the speci= fication of the Service Function Path. I believe that the specifics of how = that happens in the SFP ID belongs in the encapsulation document. But architecturally we want to capture that= the SFC encapsulation specifies the SFP and have a clean and simple archit= ecture independent of transports and underlying topologies.

Now, separately from this specific discussion, you do mention discussi= on of specific cases and a potential encap value for that. Could you share = some more specifics? This would be useful for the discussion of the encapsu= lation WG deliverable. Xiaohu shared two pointers to two individual I-Ds, and it seems (again, not an architect= ural comment but jumping ahead) that a null SPF ID would not make those cas= es interoperate. Does that call for a per-transport solution against the ch= arter? Looking at the=C2=A0draft-ietf-sfc-problem-statement, specifically Sections 2.1 and 2.6, the reason why SFC exists is to provide= that transport and topological independence as opposed to existing (transp= ort dependent) ways of chaining network services.=C2=A0

Thanks,

Carlos.


--047d7bdc801a7610fa0500aaf23c-- From nobody Fri Aug 15 07:44: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 85F761A8A81 for ; Fri, 15 Aug 2014 07:43:52 -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 prkOjcZzMG3L for ; Fri, 15 Aug 2014 07:43:49 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69E1B1A8A6D for ; Fri, 15 Aug 2014 07:43:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 3E9E71C455D7; Fri, 15 Aug 2014 07:43:49 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-126.clppva.east.verizon.net [70.106.135.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 05B291C455C7; Fri, 15 Aug 2014 07:43:47 -0700 (PDT) Message-ID: <53EE1CA5.2000609@joelhalpern.com> Date: Fri, 15 Aug 2014 10:43:49 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Andrew G. Malis" , "Carlos Pignataro (cpignata)" References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A4805@NKGEML512-MBS.china.huawei.com> <57B2ECF6-8DB4-4E23-BB14-E030EB74E09C@alcatel-lucent.com> <2691CE0099834E4A9C5044EEC662BB9D453CBFBE@dfweml701-chm.china.huawei.com> <5F8C4A2F-3C60-459D-92F7-31EA1DA9E469@cisco.com> <3DCDEFE3-081D-470A-B330-1A01A618111E@cisco.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/pN9xKPU9W604YjkausP42rVu9Xs Cc: Xiaohu Xu , "Dolganow, Andrew \(Andrew\)" , "sfc@ietf.org" , Lucy yong Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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, 15 Aug 2014 14:43:53 -0000 I would have phrased the goal you state as one where we want to enable such data forwarding. But we want such data forwarding to interoperate with other modes. You don't even list interoperability in there. And that is the primary goal for IETF work. Yours, Joel On 8/15/14, 9:24 AM, Andrew G. Malis wrote: > Carlos, > > Our goal as a WG should be to design the SFC encapsulation is to allow > flexibility and wide use in different use case and implementation > scenarios. Another practical goal should be encapsulation compactness to > the greatest extent possible to avoid packet MTU and fragmentation > issues. One scenario/use case that has been discussed is the use of a > control plane to install state such that just the metadata (or even just > packet header/data) is all that's required to forward packets on the > proper path. So for this case, we should be able to have a nonexistent > or very compact null value for the SFP ID. > > Thanks,, > Andy > > > > On Thu, Aug 14, 2014 at 11:40 AM, Carlos Pignataro (cpignata) > > wrote: > > Hi, Andy, > > Thanks for the response -- from an architecture perspective, what I > think is important to capture is that the SFC Encapsulation carries > the specification of the Service Function Path. I believe that the > specifics of how that happens in the SFP ID belongs in the > encapsulation document. But architecturally we want to capture that > the SFC encapsulation specifies the SFP and have a clean and simple > architecture independent of transports and underlying topologies. > > Now, separately from this specific discussion, you do mention > discussion of specific cases and a potential encap value for that. > Could you share some more specifics? This would be useful for the > discussion of the encapsulation WG deliverable. Xiaohu shared two > pointers to two individual I-Ds, and it seems (again, not an > architectural comment but jumping ahead) that a null SPF ID would > not make those cases interoperate. Does that call for a > per-transport solution against the charter? Looking at > the draft-ietf-sfc-problem-statement, specifically Sections 2.1 and > 2.6, the reason why SFC exists is to provide that transport and > topological independence as opposed to existing (transport > dependent) ways of chaining network services. > > Thanks, > > Carlos. > > From nobody Fri Aug 15 08:36: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 078281A0369 for ; Fri, 15 Aug 2014 08:36:02 -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 sasr0tpflPib for ; Fri, 15 Aug 2014 08:36:00 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 666B51A02DE for ; Fri, 15 Aug 2014 08:36:00 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id f51so2283184qge.25 for ; Fri, 15 Aug 2014 08:35:59 -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=FDe29tKkLAlneH4eDR0lDpfHHwYKR4GGX1BcBKZ2RPc=; b=CWXwFhpdnYl8TUHNPcS0Z34HFWiaqI0xTGkojP8S75UOVvNbMYgLu7DYPnbTo4QA4g 1DAAzPTEOIMo8xzB4Xvh78iTnJaeeY0GB9knBozkY16Sz/y7x/sIPxA9MaTs7eUtefHU n/DSuDFhZkOcU7xz7xvukJGPRjvYgk9EJFcrxDEgyz+MLXWqk66raY9QiGx2O8B521o0 vCAhAdhpeYFzhENryFHNnlvcezChuVYQ1+rZo32r48sOyrzDK9xb4V1BxrJnIH/HkHEG iOt/wlBUE2/gI9tJnPtHAI8OCCDvT3008turIRDofn03nQ6s7vp9/jyOT1yCiPb2D8K2 N8iQ== X-Received: by 10.224.28.202 with SMTP id n10mr28379403qac.47.1408116959592; Fri, 15 Aug 2014 08:35:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.91.99 with HTTP; Fri, 15 Aug 2014 08:35:39 -0700 (PDT) In-Reply-To: <53EE1CA5.2000609@joelhalpern.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A4805@NKGEML512-MBS.china.huawei.com> <57B2ECF6-8DB4-4E23-BB14-E030EB74E09C@alcatel-lucent.com> <2691CE0099834E4A9C5044EEC662BB9D453CBFBE@dfweml701-chm.china.huawei.com> <5F8C4A2F-3C60-459D-92F7-31EA1DA9E469@cisco.com> <3DCDEFE3-081D-470A-B330-1A01A618111E@cisco.com> <53EE1CA5.2000609@joelhalpern.com> From: "Andrew G. Malis" Date: Fri, 15 Aug 2014 11:35:39 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a11c34c2a2dcce70500acc730 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/tntB097UIs23i3ddK9pI14qwEUk Cc: "Carlos Pignataro \(cpignata\)" , Xiaohu Xu , "Dolganow, Andrew \(Andrew\)" , "sfc@ietf.org" , Lucy yong Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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, 15 Aug 2014 15:36:02 -0000 --001a11c34c2a2dcce70500acc730 Content-Type: text/plain; charset=UTF-8 Joel, Sorry, I was taking interoperability as a given, of course that's required. But interoperability isn't the only goal, flexibility and efficiency should be goals as well. Cheers, Andy On Fri, Aug 15, 2014 at 10:43 AM, Joel M. Halpern wrote: > I would have phrased the goal you state as one where we want to enable > such data forwarding. But we want such data forwarding to interoperate > with other modes. You don't even list interoperability in there. And that > is the primary goal for IETF work. > > Yours, > Joel > > > On 8/15/14, 9:24 AM, Andrew G. Malis wrote: > >> Carlos, >> >> Our goal as a WG should be to design the SFC encapsulation is to allow >> flexibility and wide use in different use case and implementation >> scenarios. Another practical goal should be encapsulation compactness to >> the greatest extent possible to avoid packet MTU and fragmentation >> issues. One scenario/use case that has been discussed is the use of a >> control plane to install state such that just the metadata (or even just >> packet header/data) is all that's required to forward packets on the >> proper path. So for this case, we should be able to have a nonexistent >> or very compact null value for the SFP ID. >> >> Thanks,, >> Andy >> >> >> >> On Thu, Aug 14, 2014 at 11:40 AM, Carlos Pignataro (cpignata) >> > wrote: >> >> Hi, Andy, >> >> Thanks for the response -- from an architecture perspective, what I >> think is important to capture is that the SFC Encapsulation carries >> the specification of the Service Function Path. I believe that the >> specifics of how that happens in the SFP ID belongs in the >> encapsulation document. But architecturally we want to capture that >> the SFC encapsulation specifies the SFP and have a clean and simple >> architecture independent of transports and underlying topologies. >> >> Now, separately from this specific discussion, you do mention >> discussion of specific cases and a potential encap value for that. >> Could you share some more specifics? This would be useful for the >> discussion of the encapsulation WG deliverable. Xiaohu shared two >> pointers to two individual I-Ds, and it seems (again, not an >> architectural comment but jumping ahead) that a null SPF ID would >> not make those cases interoperate. Does that call for a >> per-transport solution against the charter? Looking at >> the draft-ietf-sfc-problem-statement, specifically Sections 2.1 and >> 2.6, the reason why SFC exists is to provide that transport and >> topological independence as opposed to existing (transport >> dependent) ways of chaining network services. >> >> Thanks, >> >> Carlos. >> >> >> --001a11c34c2a2dcce70500acc730 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Joel,

Sorry, I was taking interoperabil= ity as a given, of course that's required. But interoperability isn'= ;t the only goal, flexibility and efficiency should be goals as well.

Cheers,
Andy
=

On Fri, Aug 15, 2014 at 10:43 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
I would have phrased the goal you state as one where we want to enable such= data forwarding.=C2=A0 But we want such data forwarding to interoperate wi= th other modes.=C2=A0 You don't even list interoperability in there.=C2= =A0 And that is the primary goal for IETF work.

Yours,
Joel


On 8/15/14, 9:24 AM, Andrew G. Malis wrote:
Carlos,

Our goal as a WG should be to design the SFC encapsulation is to allow
flexibility and wide use in different use case and implementation
scenarios. Another practical goal should be encapsulation compactness to the greatest extent possible to avoid packet MTU and fragmentation
issues. One scenario/use case that has been discussed is the use of a
control plane to install state such that just the metadata (or even just packet header/data) is all that's required to forward packets on the proper path. So for this case, we should be able to have a nonexistent
or very compact null value for the SFP ID.

Thanks,,
Andy



On Thu, Aug 14, 2014 at 11:40 AM, Carlos Pignataro (cpignata)
<cpignata@cisco.= com <mailto:= cpignata@cisco.com>> wrote:

=C2=A0 =C2=A0 Hi, Andy,

=C2=A0 =C2=A0 Thanks for the response -- from an architecture perspective, = what I
=C2=A0 =C2=A0 think is important to capture is that the SFC Encapsulation c= arries
=C2=A0 =C2=A0 the specification of the Service Function Path. I believe tha= t the
=C2=A0 =C2=A0 specifics of how that happens in the SFP ID belongs in the =C2=A0 =C2=A0 encapsulation document. But architecturally we want to captur= e that
=C2=A0 =C2=A0 the SFC encapsulation specifies the SFP and have a clean and = simple
=C2=A0 =C2=A0 architecture independent of transports and underlying topolog= ies.

=C2=A0 =C2=A0 Now, separately from this specific discussion, you do mention=
=C2=A0 =C2=A0 discussion of specific cases and a potential encap value for = that.
=C2=A0 =C2=A0 Could you share some more specifics? This would be useful for= the
=C2=A0 =C2=A0 discussion of the encapsulation WG deliverable. Xiaohu shared= two
=C2=A0 =C2=A0 pointers to two individual I-Ds, and it seems (again, not an<= br> =C2=A0 =C2=A0 architectural comment but jumping ahead) that a null SPF ID w= ould
=C2=A0 =C2=A0 not make those cases interoperate. Does that call for a
=C2=A0 =C2=A0 per-transport solution against the charter? Looking at
=C2=A0 =C2=A0 the draft-ietf-sfc-problem-statement, specifically Sec= tions 2.1 and
=C2=A0 =C2=A0 2.6, the reason why SFC exists is to provide that transport a= nd
=C2=A0 =C2=A0 topological independence as opposed to existing (transport =C2=A0 =C2=A0 dependent) ways of chaining network services.

=C2=A0 =C2=A0 Thanks,

=C2=A0 =C2=A0 Carlos.



--001a11c34c2a2dcce70500acc730-- From nobody Fri Aug 15 09:14: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 3AFF21A074F for ; Fri, 15 Aug 2014 09:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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.668, 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 G7uu1Kz-c_xy for ; Fri, 15 Aug 2014 09:14:24 -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 20DE01A069E for ; Fri, 15 Aug 2014 09:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9153; q=dns/txt; s=iport; t=1408119264; x=1409328864; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=RZA0SA/w3FhEr85wNGDERoEyF3mACeJTWS0rPeV88fE=; b=TgKlzaOG8p3Tr1JkR3o/Qa3788kSrBIznoMAmZYortTZc9ZG4g02ryON dt/UfFDqfDM2HEEB6vTgM+KlcKBFkTMa9p1n90pkKr9rqunQ8WKIbRhJe NJ2unBM+lsO8sNScQyUIQHgwf6mEML0pRbokCX2A2YCNz1TLMGrVVKBC+ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFALkw7lOtJA2J/2dsb2JhbABZgkcjI4Eu1WUBgRIWd4QDAQEBBB1KEhACAQgRAQIBAigHIREUAwYIAgQBDQUbiBMDEQG+Hg2FLxeNH4IcEQeETAWPDYITiQ6CD45LhjOCFoFGbIFIgQcBAQE X-IronPort-AV: E=Sophos;i="5.01,871,1400025600"; d="scan'208,217";a="347825383" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-8.cisco.com with ESMTP; 15 Aug 2014 16:14:23 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s7FGENKT007563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Aug 2014 16:14:23 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Fri, 15 Aug 2014 11:14:23 -0500 From: "Ken Gray (kegray)" To: "Andrew G. Malis" , "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt Thread-Index: AQHPsj5ZGE1SNN/VKUSIZ356OGtoPpvSB9YA///sYQA= Date: Fri, 15 Aug 2014 16:14:22 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A4805@NKGEML512-MBS.china.huawei.com> <57B2ECF6-8DB4-4E23-BB14-E030EB74E09C@alcatel-lucent.com> <2691CE0099834E4A9C5044EEC662BB9D453CBFBE@dfweml701-chm.china.huawei.com> <5F8C4A2F-3C60-459D-92F7-31EA1DA9E469@cisco.com> <3DCDEFE3-081D-470A-B330-1A01A618111E@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.95.91] Content-Type: multipart/alternative; boundary="_000_D013A7F53D60Akegrayciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/-vrTestWPrg64L6ZB2HFvMsPbmY Cc: Xiaohu Xu , "Dolganow, Andrew \(Andrew\)" , Lucy yong , "sfc@ietf.org" , "Joel M. Halpern" Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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, 15 Aug 2014 16:14:28 -0000 --_000_D013A7F53D60Akegrayciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The variability of the offset has a cost in performance just as the length = will inevitably cause concerns about the MTU. >From a practical perspective, how many service chains will actually travers= e spaces outside of a walled garden or a macro space where a single operato= r is in control (personally or as a proxy, as in cell site backhaul)? In t= hose cases, can't the normal concerns over the MTU can be mitigated operati= onally by supporting jumbo packets or turning on PMTUD (assuming you set up= the right filters to avoid outside-the-domain-PMTDU attacks) =85outside of= those scenarios (multi-domain), you have a valid concern =85but are they t= he minority or majority case? From: "Andrew G. Malis" > Date: Friday, August 15, 2014 9:24 AM To: "Carlos Pignataro (cpignata)" > Cc: Xiaohu Xu >, "Dolganow,= Andrew (Andrew)" >, "sfc@ietf.org" >, Lucy yong >, "Joel M. Halpern" > Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-arch= itecture-01.txt Carlos, Our goal as a WG should be to design the SFC encapsulation is to allow flex= ibility and wide use in different use case and implementation scenarios. An= other practical goal should be encapsulation compactness to the greatest ex= tent possible to avoid packet MTU and fragmentation issues. One scenario/us= e case that has been discussed is the use of a control plane to install sta= te such that just the metadata (or even just packet header/data) is all tha= t's required to forward packets on the proper path. So for this case, we sh= ould be able to have a nonexistent or very compact null value for the SFP I= D. Thanks,, Andy On Thu, Aug 14, 2014 at 11:40 AM, Carlos Pignataro (cpignata) > wrote: Hi, Andy, Thanks for the response -- from an architecture perspective, what I think i= s important to capture is that the SFC Encapsulation carries the specificat= ion of the Service Function Path. I believe that the specifics of how that = happens in the SFP ID belongs in the encapsulation document. But architectu= rally we want to capture that the SFC encapsulation specifies the SFP and h= ave a clean and simple architecture independent of transports and underlyin= g topologies. Now, separately from this specific discussion, you do mention discussion of= specific cases and a potential encap value for that. Could you share some = more specifics? This would be useful for the discussion of the encapsulatio= n WG deliverable. Xiaohu shared two pointers to two individual I-Ds, and it= seems (again, not an architectural comment but jumping ahead) that a null = SPF ID would not make those cases interoperate. Does that call for a per-tr= ansport solution against the charter? Looking at the draft-ietf-sfc-problem= -statement, specifically Sections 2.1 and 2.6, the reason why SFC exists is= to provide that transport and topological independence as opposed to exist= ing (transport dependent) ways of chaining network services. Thanks, Carlos. --_000_D013A7F53D60Akegrayciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3E972DD8F0D6F941A68295E6AAB6F176@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
The variability of the offset has a cost in performance just as the le= ngth will inevitably cause concerns about the MTU.  

From a practical perspective, how many service chains will actually tr= averse spaces outside of a walled garden or a macro space where a single op= erator is in control (personally or as a proxy, as in cell site backhaul)? =  In those cases, can't the normal concerns over the MTU can be mitigated operationally by supporting jumbo p= ackets or turning on PMTUD (assuming you set up the right filters to avoid = outside-the-domain-PMTDU attacks) =85outside of those scenarios (multi-doma= in), you have a valid concern =85but are they the minority or majority case?

From: "Andrew G. Malis" &= lt;agmalis@gmail.com>
Date: Friday, August 15, 2014 9:24 = AM
To: "Carlos Pignataro (cpignat= a)" <cpignata@cisco.com&g= t;
Cc: Xiaohu Xu <xuxiaohu@huawei.com>, "Dolganow, Andrew (= Andrew)" <and= rew.dolganow@alcatel-lucent.com>, "sfc@ietf.org" <sfc@ietf.org>, Lucy yong <lucy.yong@huawei.com>, "J= oel M. Halpern" <jmh@joelhal= pern.com>
Subject: Re: [sfc] Definition of SF= C Encapsulation in draft-merged-sfc-architecture-01.txt

Carlos,

Our goal as a WG should be to design the SFC encapsulation is to = allow flexibility and wide use in different use case and implementation sce= narios. Another practical goal should be encapsulation compactness to the g= reatest extent possible to avoid packet MTU and fragmentation issues. One scenario/use case that has been discusse= d is the use of a control plane to install state such that just the metadat= a (or even just packet header/data) is all that's required to forward packe= ts on the proper path. So for this case, we should be able to have a nonexistent or very compact null value f= or the SFP ID.

Thanks,,
Andy



On Thu, Aug 14, 2014 at 11:40 AM, Carlos Pignata= ro (cpignata) <cpignata@cisco.com> wrote:
Hi, Andy,

Thanks for the response -- from an architecture perspective, what I th= ink is important to capture is that the SFC Encapsulation carries the speci= fication of the Service Function Path. I believe that the specifics of how = that happens in the SFP ID belongs in the encapsulation document. But architecturally we want to capture that= the SFC encapsulation specifies the SFP and have a clean and simple archit= ecture independent of transports and underlying topologies.

Now, separately from this specific discussion, you do mention discussi= on of specific cases and a potential encap value for that. Could you share = some more specifics? This would be useful for the discussion of the encapsu= lation WG deliverable. Xiaohu shared two pointers to two individual I-Ds, and it seems (again, not an architect= ural comment but jumping ahead) that a null SPF ID would not make those cas= es interoperate. Does that call for a per-transport solution against the ch= arter? Looking at the draft-ietf-sfc-problem-statement, specifically Sections 2.1 and 2.6, the reason why SFC exists is to provide= that transport and topological independence as opposed to existing (transp= ort dependent) ways of chaining network services. 

Thanks,

Carlos.


 --_000_D013A7F53D60Akegrayciscocom_-- From nobody Sat Aug 16 10:32: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 574F31A0047 for ; Sat, 16 Aug 2014 10:32:22 -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 ovCgpENvm2uy for ; Sat, 16 Aug 2014 10:32:21 -0700 (PDT) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B30C61A0026 for ; Sat, 16 Aug 2014 10:32:20 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id k15so3148535qaq.27 for ; Sat, 16 Aug 2014 10:32:19 -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=guxDfzzqQsVuJ6JGAWhLglWqyi92ckH9YegiUsEa1L0=; b=y2tiDtA3f6WqrPhe4j0GP6IxS71BC6yBdvy0dtWTGc+TNBFEUBR3w/tzRs4QeOzQUc Dysb6b6g5weRbWLAbayE/fJFIQmw+dUhBmfZDIETVchX4HfzgJ1Rn+KD/dndgU4CdDM+ kUc4KlJFrfs/bb+j1hLlOoS3jKQXDZKl7S0xWqVOzNCn5seZRMkC6D2/UQgU7OGE9SSo R2iA3fZR8hMg0p0HTprQ8o1QRWHtzjJNCQGgAWhoNFhfpSxzJQckw6BdP6L9YtN3jmdc lo+1azFs9msmKxZQyZdMbEcl4N8GzSlcL3WDWqzmx8zns1HSUVU4CeKCQHXJ3/SQnqDP wekw== X-Received: by 10.229.67.69 with SMTP id q5mr39684918qci.25.1408210339946; Sat, 16 Aug 2014 10:32:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.91.99 with HTTP; Sat, 16 Aug 2014 10:31:59 -0700 (PDT) In-Reply-To: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A4805@NKGEML512-MBS.china.huawei.com> <57B2ECF6-8DB4-4E23-BB14-E030EB74E09C@alcatel-lucent.com> <2691CE0099834E4A9C5044EEC662BB9D453CBFBE@dfweml701-chm.china.huawei.com> <5F8C4A2F-3C60-459D-92F7-31EA1DA9E469@cisco.com> <3DCDEFE3-081D-470A-B330-1A01A618111E@cisco.com> From: "Andrew G. Malis" Date: Sat, 16 Aug 2014 13:31:59 -0400 Message-ID: To: "Ken Gray (kegray)" Content-Type: multipart/alternative; boundary=001a11c308ec14e57d0500c28540 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/WAfCnus9auzLJWAQ7fcepK-6IT4 Cc: "Carlos Pignataro \(cpignata\)" , "sfc@ietf.org" , "Dolganow, Andrew \(Andrew\)" , Lucy yong , Xiaohu Xu , "Joel M. Halpern" Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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: Sat, 16 Aug 2014 17:32:22 -0000 --001a11c308ec14e57d0500c28540 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ken, I agree, there are always tradeoffs to consider. We don't yet know the answers to the questions in your email. However, at some point, the WG will need to come to agreement on a specific SFC encapsulation. So right now, I just think it's prudent to keep the architecture document as flexible as possible so that it doesn't preclude any particular alternatives when it comes time for the WG to come to agreement on the encapsulation. Cheers, Andy On Fri, Aug 15, 2014 at 12:14 PM, Ken Gray (kegray) wrote: > The variability of the offset has a cost in performance just as the > length will inevitably cause concerns about the MTU. > > From a practical perspective, how many service chains will actually > traverse spaces outside of a walled garden or a macro space where a singl= e > operator is in control (personally or as a proxy, as in cell site > backhaul)? In those cases, can't the normal concerns over the MTU can be > mitigated operationally by supporting jumbo packets or turning on PMTUD > (assuming you set up the right filters to avoid outside-the-domain-PMTDU > attacks) =E2=80=A6outside of those scenarios (multi-domain), you have a v= alid > concern =E2=80=A6but are they the minority or majority case? > > --001a11c308ec14e57d0500c28540 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ken,

I agree, there are always tradeoff= s to consider. We don't yet know the answers to the questions in your e= mail. However, at some point, the WG will need to come to agreement on a sp= ecific SFC encapsulation. So right now, I just think it's prudent to ke= ep the architecture document as flexible as possible so that it doesn't= preclude any particular alternatives when it comes time for the WG to come= to agreement on the encapsulation.

Cheers,
Andy
=
On Fri, Aug 15, 2014 at 12:14 PM, Ken Gray (= kegray) <kegray@cisco.com> wrote:
The variability of the offset has a cost in performance just as the le= ngth will inevitably cause concerns about the MTU. =C2=A0

From a practical perspective, how many service chains will actually tr= averse spaces outside of a walled garden or a macro space where a single op= erator is in control (personally or as a proxy, as in cell site backhaul)? = =C2=A0In those cases, can't the normal concerns over the MTU can be mitigated operationally by supporting jumbo p= ackets or turning on PMTUD (assuming you set up the right filters to avoid = outside-the-domain-PMTDU attacks) =E2=80=A6outside of those scenarios (mult= i-domain), you have a valid concern =E2=80=A6but are they the minority or majority case?

--001a11c308ec14e57d0500c28540-- From nobody Mon Aug 18 11:31: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 38A771A0ADE for ; Mon, 18 Aug 2014 11:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 QZHrfthXSA1f for ; Mon, 18 Aug 2014 11:31:37 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33A761A0AD2 for ; Mon, 18 Aug 2014 11:31:36 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id E8825F37E7649; Mon, 18 Aug 2014 18:31:31 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s7IIVXaR022342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Aug 2014 14:31:34 -0400 Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.186]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Mon, 18 Aug 2014 14:31:31 -0400 From: "Dolganow, Andrew (Andrew)" To: "Andrew G. Malis" , "Carlos Pignataro (cpignata)" , Lucy yong Thread-Topic: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt Thread-Index: AQHPuxKhJBxKZXD+YUqud3r/Y87/ow== Date: Mon, 18 Aug 2014 18:31:30 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A4805@NKGEML512-MBS.china.huawei.com> <57B2ECF6-8DB4-4E23-BB14-E030EB74E09C@alcatel-lucent.com> <2691CE0099834E4A9C5044EEC662BB9D453CBFBE@dfweml701-chm.china.huawei.com> <5F8C4A2F-3C60-459D-92F7-31EA1DA9E469@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_D017BD5459A76andrewdolganowalcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/cUSCnZ4490oeavUmW3WJ9PauQRs Cc: Xiaohu Xu , "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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, 18 Aug 2014 18:31:40 -0000 --_000_D017BD5459A76andrewdolganowalcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Andy, Carlos, Lucy We should be careful how much overhead we introduce to implement various op= tions. Although NULL ID would satisfy the requirement we have, I would pref= er we support metadata withoutSPF ID (there are bits we can use to indicate= no SPF presence). Andrew On 2014-08-13, 9:47 AM, "Andrew G. Malis" wrote: Carlos, I see your point, but there's also been discussion of cases where only the = metadata is required. In that case, you woud either be carrying a null SFP = ID along with the metadata, or just the metadata. It seems more efficient t= o me to just carry the metadata, but if you want to insist that there's alw= ays an SPF ID, then we need to make sure that it can be a null ID. Cheers, Andy On Tue, Aug 12, 2014 at 9:51 PM, Carlos Pignataro (cpignata) > wrote: Hi, Andy, Lucy, Flexibility is certainly good as long as it does not get in the way of inte= roperability. This architecture drives a balance and tradeoff in which opti= ons are maximized while having interoperability as the goal. >From a technical perspective, the SFC Encapsulation specifies the Service F= unction Path to allow for end-to-end SFPs and interoperable implementations= . One of the key principles of this architecture is that the SFC Encapsulat= ion is transport-independent. The text is flexible such that any transport = may be used to carry the SFC encapsulation. However, two SFs part of an SFP= that are not adjacent in the services topology can have different transpor= t encapsulations but need the SFC-encapsulation (minimum invariant encap) t= o specify the SPF. This is within the service topology, which again is inde= pendent from the underlay topology as an architectural principle. Please no= te that the use of the SFC encapsulation to specify the SFP and the SFFs an= d SFs use of this is articulated throughout the architecture. This architec= ture also allows for flexibility in bringing SFC-unaware SFs by proxy as th= e one gateway, to provide backwards compatibility, but attempts to carry fo= rward interoperability. Consequently, for "SFC Aware" chains, the architect= ural choice that follows the principles is to carry the SFP id. It is (also= ) to convey shared context (when demanded by the use case) using the SFC-en= capsulation for similar reasons. As a WG, I believe we should first strive = for a single service-level data plane encapsulation as per the current WG c= harter and based on that provide the most optimal placement of functions an= d identifiers. Note also that I was pointing to the charter because I believe these points= were discussed already to get to the current charter text. Best, Carlos. On Aug 11, 2014, at 10:47 AM, Lucy yong > wrote: I agree Andy=92s point. Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Andrew G. Malis Sent: Friday, August 08, 2014 4:47 PM To: Carlos Pignataro (cpignata) Cc: Xuxiaohu; Dolganow, Andrew (Andrew); sfc@ietf.org;= Joel M. Halpern Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-arch= itecture-01.txt Carlos, I agree that the charter requires the encapsulation to support each of the = bullet items, but there's no requirement that every encapsulated packet wil= l need all of the bullet items supported, so I'm trying to keep the text as= flexible as possible to not preclude possible solutions. Cheers, Andy On Fri, Aug 8, 2014 at 11:09 AM, Carlos Pignataro (cpignata) > wrote: Hi, Andrew, On Aug 8, 2014, at 8:53 AM, Dolganow, Andrew (Andrew) > wrote: > I agree that we should have stronger separation of two functions: SFP and= metadata. > > How about small edit to what Andy proposed: > > SFC Encapsulation: A data plane encapsulation that encodes either one or= both of > - the SFP > - metadata (data plane context information). Looking at http://datatracker.ietf.org/wg/sfc/charter/, there is no "either= one or both of". In fact, looking at the history of the charter text, the = text for SFC Encapsulation is a bullet list form of a longer sentence that = includes "and" only (see 00-09). Thanks, Carlos. >> The SFP Encapsulation is used by the SFC-aware functions, such as the SF= F and SFC-aware SFs, and is not used for network packet forwarding. > > > Andrew > > Sent from my iPhone > >> On Aug 7, 2014, at 9:13 PM, "Xuxiaohu" > wrote: >> >> I fully agree with Andy=92s point that not every usage of the encapsulat= ion will need both the SFP identification and the metadata. It=92s better t= hat the SFC encapsulation could be flexibly used for carrying SFP identific= ation, metadata or both. Otherwise, it seems that those SFC approaches whic= h don=92t use the SFC encapsulation for SFC selection would have to separat= ely define the way of carrying metadata. >> >> Best regards, >> Xiaohu >> >> From: sfc [mailto:sfc-bounces@ietf.org] On = Behalf Of Andrew G. Malis >> Sent: Thursday, August 07, 2014 9:06 PM >> To: Carlos Pignataro (cpignata) >> Cc: Joel M. Halpern; sfc@ietf.org >> Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-a= rchitecture-01.txt >> >> Carlos, >> >> When I re-read the definition, it seemed to me to be more of a string of= thoughts than a concise definition, which is why I was trying to tighten i= t up. A definition is meant to be a short summary for quick reference, whil= e the discussion in 4.1 goes into the more formal details. Otherwise, you = would just repeat the entire section 4.1 in section 1.3. This is why it do= esn't need to be in separate sentences. The "and/or" is because not every u= sage of the encapsulation will need both the SFP identification and the met= adata, so the definition needs to concisely convey that. >> >> Cheers, >> Andy >> >> On Thu, Aug 7, 2014 at 8:51 AM, Carlos Pignataro (cpignata) > wrote: >> Thank you for going back and checking, Andy! >> >> Which specific part of the current definition do you believe is loose en= ough to need tightening? >> >> I believe that your new proposal falls shorter than the existing text in= a few areas: >> =95 First, it combines two different functions (SFP identification and m= etadata/context information) into a single sentence. This opposes the chang= e we just made based on your preference in Section 4.1, which breaks the tw= o functions into two sentences, for reader clarity. While longer, it's simp= ler. >> =95 Second, it introduces an extraneous "and/or" that would change the m= eaning, and negate the "at a minimum" existing bit. That would not be simpl= ifying. >> =95 Third, there is no third but three bullets look better :-) >> >> Net-net, the original text, even when longer in character count, seems m= ore clear and simpler to the reader (because of the separated sentences), I= MHO. >> >> Thanks, >> >> Carlos. >> >> On Aug 7, 2014, at 8:20 AM, Andrew G. Malis > wrote: >> >> >> Carlos and Joel, >> >> In light of the previous discussions, I went back and re-read this curre= nt definition of SFC Encapsulation in the text (section 1.3): >> >> SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP >> identification, and is used by the SFC-aware functions, such as >> the SFF and SFC-aware SFs. The SFC Encapsulation is not used >> for network packet forwarding. In addition to SFP >> identification, the SFC encapsulation carries dataplane context >> information, also referred to as metadata. >> >> I think this could be tightened up to make simpler for the reader: >> >> SFC Encapsulation: A data plane encapsulation that identifies the SFP a= nd/or provides metadata (data plane context information). The SFP Encapsula= tion is used by the SFC-aware functions, such as the SFF and SFC-aware SFs,= and is not used for network packet forwarding. >> >> Thanks, >> Andy >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc --_000_D017BD5459A76andrewdolganowalcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Andy, Carlos, Lucy

We should be careful how much overhead we introduce to implement vario= us options. Although NULL ID would satisfy the requirement we have, I would= prefer we support metadata withoutSPF ID (there are bits we can use to ind= icate no SPF presence).

Andrew

On 2014-08-13, 9:47 AM, "Andrew G. Malis" wrote:

Carlos,

I see your point, but there's also been discussion of cases where only= the metadata is required. In that case, you woud either be carrying a null= SFP ID along with the metadata, or just the metadata. It seems more effici= ent to me to just carry the metadata, but if you want to insist that there's always an SPF ID, then we need to m= ake sure that it can be a null ID.

Cheers,
Andy


On Tue, Aug 12, 2014 at 9:51 PM, Carlos Pignatar= o (cpignata) <cpignata@cisco.com> wrote:
Hi, Andy, Lucy,

Flexibility is certainly good as long as it does not get in the way of= interoperability. This architecture drives a balance and tradeoff in which= options are maximized while having interoperability as the goal.

From a technical perspective, the SFC Encapsulation specifies the Serv= ice Function Path to allow for end-to-end SFPs and interoperable implementa= tions. One of the key principles of this architecture is that the SFC Encap= sulation is transport-independent. The text is flexible such that any transport may be used to carry the SFC = encapsulation. However, two SFs part of an SFP that are not adjacent in the= services topology can have different transport encapsulations but need the= SFC-encapsulation (minimum invariant encap) to specify the SPF. This is within the service topology, which agai= n is independent from the underlay topology as an architectural principle. = Please note that the use of the SFC encapsulation to specify the SFP and th= e SFFs and SFs use of this is articulated throughout the architecture. This architecture also allows for flexibility= in bringing SFC-unaware SFs by proxy as the one gateway, to provide backwa= rds compatibility, but attempts to carry forward interoperability. Conseque= ntly, for "SFC Aware" chains, the architectural choice that follows the principles is to carry the SFP id. I= t is (also) to convey shared context (when demanded by the use case) using = the SFC-encapsulation for similar reasons. As a WG, I believe we should fir= st strive for a single service-level data plane encapsulation as per the current WG charter and based on that p= rovide the most optimal placement of functions and identifiers.

Note also that I was pointing to the charter because I believe these p= oints were discussed already to get to the current charter text.

Best,

Carlos.

On Aug 11, 2014, at 10:47 AM, Lucy yong <lucy.yong@huawei.com> wrote:

I agree Andy=92s point.
 
Lucy
 
From:<= /span> sfc [mailto:sfc-bounces= @ietf.org] On Behalf Of Andrew G. Malis
Sent: Friday, August 08, 2014 4:47 PM
To: Carlos Pignataro (cpignata)
Cc: Xuxiaohu; Dolganow, Andrew (Andrew);&nbs= p;sfc@ietf.org; Joel M. Halpern
Subject: Re: [sfc] Definition of SFC Encapsulation= in draft-merged-sfc-architecture-01.txt
 
Carlos,
 
I agree that the charter requires the encapsulation to support each of the = bullet items, but there's no requirement that every encapsulated packet wil= l need all of the bullet items supported, so I'm trying to keep the text as= flexible as possible to not preclude possible solutions.
 
Cheers,
Andy

 

On Fri, Aug 8, 2014 at 11:09 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
Hi, Andrew,


On Aug 8, 2014, at 8:53 AM, Dolganow, Andrew (Andrew) <andrew.dolganow@alcatel-lucent.com> wro= te:

> I agree that we should have stronger separation of two functions: SFP = and metadata.
>
> How about small edit to what Andy proposed:
>
> SFC Encapsulation:  A data plane encapsulation that encodes eithe= r one or both of
> - the SFP
> - metadata (data plane context information).

Looking at http://datatracker.ietf.org/wg/sfc/charter/, there is no "either= one or both of". In fact, looking at the history of the charter text, the text for SFC Encapsulation is a bullet list form = of a longer sentence that includes "and" only (see 00-09).

Thanks,

Carlos.


>> The SFP Encapsulation is used by the SFC-aware functions, such as = the SFF and SFC-aware SFs, and is not used for network packet forwarding. >
>
> Andrew
>
> Sent from my iPhone
>
>> On Aug 7, 2014, at 9:13 PM, "Xuxiaohu" <xuxiaohu@huawei.com> wrote:
>>
>> I fully agree with Andy=92s point that not every usage of the enca= psulation will need both the SFP identification and the metadata. It=92s be= tter that the SFC encapsulation could be flexibly used for carrying SFP ide= ntification, metadata or both. Otherwise, it seems that those SFC approaches which don=92t use the SFC encapsulation= for SFC selection would have to separately define the way of carrying meta= data.
>>
>> Best regards,
>> Xiaohu
>>
>> From: sfc [mailto:sfc-bounces@ietf= .org] On Behalf Of Andrew G. Malis
>> Sent: Thursday, August 07, 2014 9:06 PM
>> To: Carlos Pignataro (cpignata)
>> Cc: Joel M. Halpern; sfc= @ietf.org
>> Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged= -sfc-architecture-01.txt
>>
>> Carlos,
>>
>> When I re-read the definition, it seemed to me to be more of a str= ing of thoughts than a concise definition, which is why I was trying to tig= hten it up. A definition is meant to be a short summary for quick reference= , while the discussion in 4.1 goes into the more formal details.  Otherwise, you would just repeat the entire= section 4.1 in section 1.3.  This is why it doesn't need to be in sep= arate sentences. The "and/or" is because not every usage of the e= ncapsulation will need both the SFP identification and the metadata, so the definition needs to concisely convey that.
>>
>> Cheers,
>> Andy
>>
>> On Thu, Aug 7, 2014 at 8:51 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
>> Thank you for going back and checking, Andy!
>>
>> Which specific part of the current definition do you believe is lo= ose enough to need tightening?
>>
>> I believe that your new proposal falls shorter than the existing t= ext in a few areas:
>> =95 First, it combines two different functions (SFP identification= and metadata/context information) into a single sentence. This opposes the= change we just made based on your preference in Section 4.1, which breaks = the two functions into two sentences, for reader clarity. While longer, it's simpler.
>> =95 Second, it introduces an extraneous "and/or" that wo= uld change the meaning, and negate the "at a minimum" existing bi= t. That would not be simplifying.
>> =95 Third, there is no third but three bullets look better :-)
>>
>> Net-net, the original text, even when longer in character count, s= eems more clear and simpler to the reader (because of the separated sentenc= es), IMHO.
>>
>> Thanks,
>>
>> Carlos.
>>
>> On Aug 7, 2014, at 8:20 AM, Andrew G. Malis <agmalis@gmail.com> wrote:
>>
>>
>> Carlos and Joel,
>>
>> In light of the previous discussions, I went back and re-read this= current definition of SFC Encapsulation in the text (section 1.3):
>>
>>   SFC Encapsulation:  The SFC Encapsulation provides at = a minimum SFP
>>        identification, and is used by the SFC-= aware functions, such as
>>        the SFF and SFC-aware SFs.  The SF= C Encapsulation is not used
>>        for network packet forwarding.  In= addition to SFP
>>        identification, the SFC encapsulation c= arries dataplane context
>>        information, also referred to as metada= ta.
>>
>> I think this could be tightened up to make simpler for the reader:=
>>
>> SFC Encapsulation:  A data plane encapsulation that identifie= s the SFP and/or provides metadata (data plane context information). The SF= P Encapsulation is used by the SFC-aware functions, such as the SFF and SFC= -aware SFs, and is not used for network packet forwarding.
>>
>> Thanks,
>> Andy
>>
>>
>>
>> _______________________________________________
>> sfc mailing list
>> sfc@ietf.org
>> ht= tps://www.ietf.org/mailman/listinfo/sfc



 --_000_D017BD5459A76andrewdolganowalcatellucentcom_-- From nobody Mon Aug 18 11:35: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 108711A0AE6 for ; Mon, 18 Aug 2014 11:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 QXN9pWLuoPLD for ; Mon, 18 Aug 2014 11:35:32 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08C391A0AE3 for ; Mon, 18 Aug 2014 11:35:32 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 7248544F5A086; Mon, 18 Aug 2014 18:35:28 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s7IIZURX003460 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Aug 2014 14:35:31 -0400 Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.186]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Mon, 18 Aug 2014 14:35:30 -0400 From: "Dolganow, Andrew (Andrew)" To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Proposed SFC Architecture - SFC Proxy Thread-Index: AQHPuxMwzDIL4DpWjk+MVDCTb1moYw== Date: Mon, 18 Aug 2014 18:35:30 +0000 Message-ID: References: <53ECEDFE.8080007@joelhalpern.com> In-Reply-To: <53ECEDFE.8080007@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-ID: <7D0F79280359914AA7790039DDBB37C5@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/x9sYiu4aWkzvcFtkRwuBC2wC8ts Subject: Re: [sfc] Proposed SFC Architecture - SFC Proxy 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, 18 Aug 2014 18:35:33 -0000 Joel, The approach you proposing is OK with me. Andrew On 2014-08-14, 1:12 PM, "Joel M. Halpern" wrote: >In the recent discussion on the SFC Proxy, Carlos and I understood that >the current text is unclear. We need to fix it. > >It turned out that even he and I had different perspectives on what it >meant. He has persuaded me that the cleanest approach is not the one I >suggested earlier on the list. >So I am writing a bit of text to fix the proxy description (and then we >will fix any other dangling references.) Since the group is considering >adoption of the document, we wanted to make sure that the proposal is >one other folks can live with. > >The approach is to treat the SFC Proxy as a logical element between the >SFF and the SF. When the SFF wants to send a packet to an SF which >requires proxy support, the packet goes instead to the proxy. The proxy >does what is necessary, works with the SF however it needs to, and when >the packet comes back puts things back together and hands them back to >the SFF. > >Just as we do not specify the delivery mechanism between the SFF and the >SF, we will not specify the delivery mechanism between the SFF and the >SFC Proxy or between the SFC Proxy and the SF. > >I hope this is understandable and acceptable to folks. >Thank you, >Joel > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Aug 19 15:15: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 C5BBE1A017E for ; Tue, 19 Aug 2014 15:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 vg-jIn1XSl86 for ; Tue, 19 Aug 2014 15:15:28 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90C741A6F74 for ; Tue, 19 Aug 2014 15:15:28 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id l4so6115405lbv.16 for ; Tue, 19 Aug 2014 15:15:26 -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=3OzG4GKwg/aKSpyi0tiGKENLqqdS3FNX4H2dCEIfTJg=; b=ZumgqzlII6OILMtrRMMkgTyT2FH/Ob6st4DuMU0q4/NRMS03ubPX7jUcjBbXDGz7yY 6zcaz/zoScdkC0WeiDBS4pAYuOknVmbAECud0goDQxU7O85nyiVaSDAWeT/XmUcLxvAn iiF9Nfy6VDGg0qKgvyZebOiSVkkeClmt4COf6Kbj4JOkN3Z7zwlSH/bTRFsTwW4fpgDa wvBouQCBK3i30ToAoaugqJjSoTXsib6r4v0HG1wAOhNYDVnGwi4LscJkSHslZWUjuHQD hbRqD1Bh+SB/SuzzXkpQjIxx7cfxNUZ8UabOsNd+zjN47NzolSONeGJod3a3vLwEa0uf uZQw== MIME-Version: 1.0 X-Received: by 10.152.22.199 with SMTP id g7mr38711297laf.6.1408486526741; Tue, 19 Aug 2014 15:15:26 -0700 (PDT) Received: by 10.114.191.228 with HTTP; Tue, 19 Aug 2014 15:15:26 -0700 (PDT) In-Reply-To: <53ECEDFE.8080007@joelhalpern.com> References: <53ECEDFE.8080007@joelhalpern.com> Date: Tue, 19 Aug 2014 17:15:26 -0500 Message-ID: From: Behcet Sarikaya To: "Joel M. Halpern" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/yGL9nTKeNhwOgVvfKMUs4zsnlI4 Cc: "sfc@ietf.org" Subject: Re: [sfc] Proposed SFC Architecture - SFC Proxy 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: Tue, 19 Aug 2014 22:15:29 -0000 Hi Joel, When reading Section 4.6 on SFC Proxy, I got confused. I think that the proxy function is explained in somewhat reverse order. It starts by the traffic received from an SFF. Why? How does the SFF forward the traffic to the proxy instead of to the SF? I hope you can shed some light into this. Regards, Behcet On Thu, Aug 14, 2014 at 12:12 PM, Joel M. Halpern wrote: > In the recent discussion on the SFC Proxy, Carlos and I understood that the > current text is unclear. We need to fix it. > > It turned out that even he and I had different perspectives on what it > meant. He has persuaded me that the cleanest approach is not the one I > suggested earlier on the list. > So I am writing a bit of text to fix the proxy description (and then we will > fix any other dangling references.) Since the group is considering adoption > of the document, we wanted to make sure that the proposal is one other folks > can live with. > > The approach is to treat the SFC Proxy as a logical element between the SFF > and the SF. When the SFF wants to send a packet to an SF which requires > proxy support, the packet goes instead to the proxy. The proxy does what is > necessary, works with the SF however it needs to, and when the packet comes > back puts things back together and hands them back to the SFF. > > Just as we do not specify the delivery mechanism between the SFF and the SF, > we will not specify the delivery mechanism between the SFF and the SFC Proxy > or between the SFC Proxy and the SF. > > I hope this is understandable and acceptable to folks. > Thank you, > Joel > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Aug 19 15:25: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 051791A6F03 for ; Tue, 19 Aug 2014 15:25:02 -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 BpEc9Mm_teaP for ; Tue, 19 Aug 2014 15:25:00 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 924401A06F4 for ; Tue, 19 Aug 2014 15:25:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 586E13E1574; Tue, 19 Aug 2014 15:25:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-198.clppva.east.verizon.net [70.106.135.198]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 7C5BF3E1573; Tue, 19 Aug 2014 15:24:59 -0700 (PDT) Message-ID: <53F3CEBC.40309@joelhalpern.com> Date: Tue, 19 Aug 2014 18:25:00 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sarikaya@ieee.org References: <53ECEDFE.8080007@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/l91Q2yiXp7FpC7LxLLITAPq9llg Cc: "sfc@ietf.org" Subject: Re: [sfc] Proposed SFC Architecture - SFC Proxy 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, 19 Aug 2014 22:25:02 -0000 Traffic arrives at the SFF from elsewhere (a prior SFF or the ingress classifier.) The SFF determines where to send it. It hinks, in this case, that it is sending it to an SF. However, the local information which tells the SFF how to do that (which is not specified by the architecture, and may or may not be in scope for the WG) actually directs it to send the traffic to the proxy. The proxy takes care of the actual interaction with the legacy service function. And then delivers the resulting packet back to the SFF, with the SFC encapsulation, as if it were an SFC-compliant service function. Yours, Joel On 8/19/14, 6:15 PM, Behcet Sarikaya wrote: > Hi Joel, > > When reading Section 4.6 on SFC Proxy, I got confused. I think that > the proxy function is explained in somewhat reverse order. It starts > by the traffic received from an SFF. Why? How does the SFF forward the > traffic to the proxy instead of to the SF? > > I hope you can shed some light into this. > > Regards, > > Behcet > > On Thu, Aug 14, 2014 at 12:12 PM, Joel M. Halpern wrote: >> In the recent discussion on the SFC Proxy, Carlos and I understood that the >> current text is unclear. We need to fix it. >> >> It turned out that even he and I had different perspectives on what it >> meant. He has persuaded me that the cleanest approach is not the one I >> suggested earlier on the list. >> So I am writing a bit of text to fix the proxy description (and then we will >> fix any other dangling references.) Since the group is considering adoption >> of the document, we wanted to make sure that the proposal is one other folks >> can live with. >> >> The approach is to treat the SFC Proxy as a logical element between the SFF >> and the SF. When the SFF wants to send a packet to an SF which requires >> proxy support, the packet goes instead to the proxy. The proxy does what is >> necessary, works with the SF however it needs to, and when the packet comes >> back puts things back together and hands them back to the SFF. >> >> Just as we do not specify the delivery mechanism between the SFF and the SF, >> we will not specify the delivery mechanism between the SFF and the SFC Proxy >> or between the SFC Proxy and the SF. >> >> I hope this is understandable and acceptable to folks. >> Thank you, >> Joel >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Aug 20 08:55: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 78CDB1A0ACB for ; Wed, 20 Aug 2014 08:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.35 X-Spam-Level: X-Spam-Status: No, score=-0.35 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 qFAP7DMHHblN for ; Wed, 20 Aug 2014 08:55:11 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7167D1A04C2 for ; Wed, 20 Aug 2014 08:55:10 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id l4so7021585lbv.30 for ; Wed, 20 Aug 2014 08:55:07 -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=kOQ7D6j5peeL8OsqfH2KttP1neXDGZv1vUZ389wX1MQ=; b=voenqmUtf2yDDKjTNOk+QkrAc7dX9yv70qDNPedjzgiB4SQKM0hS3AwU76mMkppGot BN3avcUy3y1F62PSOvUgp6pF1KLW+19f0bdIPwP8XaCnr/5LMDgfHRyoguLechTTsCcG onsi/EWJRHe5yGEEJ58TZJ50XdvCxYE94k2qx9V4qS+1VYdVt1RsY8NzNKB1mJ5p7gyo 6sxyWrDWJgzug0l579UlEfmi/mPooA6tOEBjb22XauAkBr5VFmnmgSzM/24MIA2PyaGC mTdEqmrbzQREaHXWMOqExEA1ClBnZkjVKH0h0lwLT7m/UUiYtm9qL7cKRYKfrAVygvri 7Mxg== MIME-Version: 1.0 X-Received: by 10.112.56.206 with SMTP id c14mr39976108lbq.27.1408550107754; Wed, 20 Aug 2014 08:55:07 -0700 (PDT) Received: by 10.114.191.228 with HTTP; Wed, 20 Aug 2014 08:55:07 -0700 (PDT) In-Reply-To: <53F3CEBC.40309@joelhalpern.com> References: <53ECEDFE.8080007@joelhalpern.com> <53F3CEBC.40309@joelhalpern.com> Date: Wed, 20 Aug 2014 10:55:07 -0500 Message-ID: From: Behcet Sarikaya To: "Joel M. Halpern" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/0bod7hccuk-GN4dA4WgnEgdSO_E Cc: "sfc@ietf.org" Subject: Re: [sfc] Proposed SFC Architecture - SFC Proxy 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, 20 Aug 2014 15:55:12 -0000 On Tue, Aug 19, 2014 at 5:25 PM, Joel M. Halpern wrote: > Traffic arrives at the SFF from elsewhere (a prior SFF or the ingress > classifier.) > The SFF determines where to send it. It hinks, in this case, that it is > sending it to an SF. However, the local information which tells the SFF how > to do that (which is not specified by the architecture, and may or may not > be in scope for the WG) actually directs it to send the traffic to the > proxy. The proxy takes care of the actual interaction with the legacy > service function. And then delivers the resulting packet back to the SFF, > with the SFC encapsulation, as if it were an SFC-compliant service function. > Sorry but I still don't understand. Why not start with SFC-unaware SF? Isn't this where the need for proxy arises? Regards, Behcet > Yours, > Joel > > > On 8/19/14, 6:15 PM, Behcet Sarikaya wrote: >> >> Hi Joel, >> >> When reading Section 4.6 on SFC Proxy, I got confused. I think that >> the proxy function is explained in somewhat reverse order. It starts >> by the traffic received from an SFF. Why? How does the SFF forward the >> traffic to the proxy instead of to the SF? >> >> I hope you can shed some light into this. >> >> Regards, >> >> Behcet >> >> On Thu, Aug 14, 2014 at 12:12 PM, Joel M. Halpern >> wrote: >>> >>> In the recent discussion on the SFC Proxy, Carlos and I understood that >>> the >>> current text is unclear. We need to fix it. >>> >>> It turned out that even he and I had different perspectives on what it >>> meant. He has persuaded me that the cleanest approach is not the one I >>> suggested earlier on the list. >>> So I am writing a bit of text to fix the proxy description (and then we >>> will >>> fix any other dangling references.) Since the group is considering >>> adoption >>> of the document, we wanted to make sure that the proposal is one other >>> folks >>> can live with. >>> >>> The approach is to treat the SFC Proxy as a logical element between the >>> SFF >>> and the SF. When the SFF wants to send a packet to an SF which requires >>> proxy support, the packet goes instead to the proxy. The proxy does what >>> is >>> necessary, works with the SF however it needs to, and when the packet >>> comes >>> back puts things back together and hands them back to the SFF. >>> >>> Just as we do not specify the delivery mechanism between the SFF and the >>> SF, >>> we will not specify the delivery mechanism between the SFF and the SFC >>> Proxy >>> or between the SFC Proxy and the SF. >>> >>> I hope this is understandable and acceptable to folks. >>> Thank you, >>> Joel >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Aug 20 09:00: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 7535B1A093B for ; Wed, 20 Aug 2014 09:00:40 -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 Zf39Hd4KtY5U for ; Wed, 20 Aug 2014 09:00:37 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAFA91A6F5D for ; Wed, 20 Aug 2014 09:00:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 8914D80476; Wed, 20 Aug 2014 09:00:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-198.clppva.east.verizon.net [70.106.135.198]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 8DA1E8049B; Wed, 20 Aug 2014 09:00:06 -0700 (PDT) Message-ID: <53F4C604.5020901@joelhalpern.com> Date: Wed, 20 Aug 2014 12:00:04 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sarikaya@ieee.org References: <53ECEDFE.8080007@joelhalpern.com> <53F3CEBC.40309@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/Cfxw5RqgyQ1vJBlsWkFgLW42Q7M Cc: "sfc@ietf.org" Subject: Re: [sfc] Proposed SFC Architecture - SFC Proxy 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, 20 Aug 2014 16:00:40 -0000 You ask "why not start with the SFC-unaware SF?". The reason is that one of the points of the proxy is to send a packet to that SFC_unaware SF in such a way that the SF can understand the packet, evne though it does not understand the SFC encapsulation. So we have to start with a packet arriving with the SFC encapsulation. And talk about the transforms necessary to deliver that to the SFC-unaware SF. The problem to be dealt with is to avoid demanding modification of the existing SFC-unaware SF, so that SFC is deployable. Yours, Joel On 8/20/14, 11:55 AM, Behcet Sarikaya wrote: > On Tue, Aug 19, 2014 at 5:25 PM, Joel M. Halpern wrote: >> Traffic arrives at the SFF from elsewhere (a prior SFF or the ingress >> classifier.) >> The SFF determines where to send it. It hinks, in this case, that it is >> sending it to an SF. However, the local information which tells the SFF how >> to do that (which is not specified by the architecture, and may or may not >> be in scope for the WG) actually directs it to send the traffic to the >> proxy. The proxy takes care of the actual interaction with the legacy >> service function. And then delivers the resulting packet back to the SFF, >> with the SFC encapsulation, as if it were an SFC-compliant service function. >> > > Sorry but I still don't understand. > > Why not start with SFC-unaware SF? > > Isn't this where the need for proxy arises? > > Regards, > > Behcet >> Yours, >> Joel >> >> >> On 8/19/14, 6:15 PM, Behcet Sarikaya wrote: >>> >>> Hi Joel, >>> >>> When reading Section 4.6 on SFC Proxy, I got confused. I think that >>> the proxy function is explained in somewhat reverse order. It starts >>> by the traffic received from an SFF. Why? How does the SFF forward the >>> traffic to the proxy instead of to the SF? >>> >>> I hope you can shed some light into this. >>> >>> Regards, >>> >>> Behcet >>> >>> On Thu, Aug 14, 2014 at 12:12 PM, Joel M. Halpern >>> wrote: >>>> >>>> In the recent discussion on the SFC Proxy, Carlos and I understood that >>>> the >>>> current text is unclear. We need to fix it. >>>> >>>> It turned out that even he and I had different perspectives on what it >>>> meant. He has persuaded me that the cleanest approach is not the one I >>>> suggested earlier on the list. >>>> So I am writing a bit of text to fix the proxy description (and then we >>>> will >>>> fix any other dangling references.) Since the group is considering >>>> adoption >>>> of the document, we wanted to make sure that the proposal is one other >>>> folks >>>> can live with. >>>> >>>> The approach is to treat the SFC Proxy as a logical element between the >>>> SFF >>>> and the SF. When the SFF wants to send a packet to an SF which requires >>>> proxy support, the packet goes instead to the proxy. The proxy does what >>>> is >>>> necessary, works with the SF however it needs to, and when the packet >>>> comes >>>> back puts things back together and hands them back to the SFF. >>>> >>>> Just as we do not specify the delivery mechanism between the SFF and the >>>> SF, >>>> we will not specify the delivery mechanism between the SFF and the SFC >>>> Proxy >>>> or between the SFC Proxy and the SF. >>>> >>>> I hope this is understandable and acceptable to folks. >>>> Thank you, >>>> Joel >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Aug 20 09:52: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 B606A1A049A for ; Wed, 20 Aug 2014 09:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 i08cdh8YpRbg for ; Wed, 20 Aug 2014 09:52:06 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38BC01A0481 for ; Wed, 20 Aug 2014 09:52:06 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id 10so7125797lbg.12 for ; Wed, 20 Aug 2014 09:52:04 -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=OGoal22/HcRs7g2xhpxHErTS74euHvzj0bCYjQ/4tTk=; b=BuAbKL62/FVpXXvgM6NVvrCINOU6IX2lmHG7y+kk4Lh6uBviYLZnbd7QSZnmHlhfi1 6rfBtWYH1B3ytSAYxV4SEJo9StjSOps05VrA1NeDA09IsiR6Ov+VDW+SYLpSoreaLakR rOag5rPeIxxnx13IGy3/vGrNCdACx4g/IIQlLPRD+cmJuaLMiTRMTKXZJOdpUIJHhaUV M0VaokqrV10996xcU/PQ7T5ZkKjwPeoG4cd1XsgcVXyqSmy87UaaSBB/schv6k//K7Fn EYwKAfgYl9i0SzPiuxH+lbJxkLBjameDw9xbnejPC0hiJndSeCXRA7pG9OCkz5WjvrPF Zeiw== MIME-Version: 1.0 X-Received: by 10.112.150.106 with SMTP id uh10mr41029444lbb.11.1408553524424; Wed, 20 Aug 2014 09:52:04 -0700 (PDT) Received: by 10.114.191.228 with HTTP; Wed, 20 Aug 2014 09:52:04 -0700 (PDT) In-Reply-To: <53F4C604.5020901@joelhalpern.com> References: <53ECEDFE.8080007@joelhalpern.com> <53F3CEBC.40309@joelhalpern.com> <53F4C604.5020901@joelhalpern.com> Date: Wed, 20 Aug 2014 11:52:04 -0500 Message-ID: From: Behcet Sarikaya To: "Joel M. Halpern" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/p34gEp66jhc1Pq94QiSXANu_wOE Cc: "sfc@ietf.org" Subject: Re: [sfc] Proposed SFC Architecture - SFC Proxy 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, 20 Aug 2014 16:52:07 -0000 I have a feeling that proxy is introduced to deal with packets coming from specific attachment circuits such as VLANs, tunnel-based circuits like GRE, VXLAN, etc. Proxy is not necessarily SF specific. So these attachment circuits may contains various SFs such as firewalls, DPI, LI, etc. On Wed, Aug 20, 2014 at 11:00 AM, Joel M. Halpern wrote: > You ask "why not start with the SFC-unaware SF?". > The reason is that one of the points of the proxy is to send a packet to > that SFC_unaware SF in such a way that the SF can understand the packet, > evne though it does not understand the SFC encapsulation. > So we have to start with a packet arriving with the SFC encapsulation. And > talk about the transforms necessary to deliver that to the SFC-unaware SF. > The problem to be dealt with is to avoid demanding modification of the > existing SFC-unaware SF, so that SFC is deployable. > > Yours, > Joel > > > On 8/20/14, 11:55 AM, Behcet Sarikaya wrote: >> >> On Tue, Aug 19, 2014 at 5:25 PM, Joel M. Halpern >> wrote: >>> >>> Traffic arrives at the SFF from elsewhere (a prior SFF or the ingress >>> classifier.) >>> The SFF determines where to send it. It hinks, in this case, that it is >>> sending it to an SF. However, the local information which tells the SFF >>> how >>> to do that (which is not specified by the architecture, and may or may >>> not >>> be in scope for the WG) actually directs it to send the traffic to the >>> proxy. The proxy takes care of the actual interaction with the legacy >>> service function. And then delivers the resulting packet back to the >>> SFF, >>> with the SFC encapsulation, as if it were an SFC-compliant service >>> function. >>> >> >> Sorry but I still don't understand. >> >> Why not start with SFC-unaware SF? >> >> Isn't this where the need for proxy arises? >> >> Regards, >> >> Behcet >>> >>> Yours, >>> Joel >>> >>> >>> On 8/19/14, 6:15 PM, Behcet Sarikaya wrote: >>>> >>>> >>>> Hi Joel, >>>> >>>> When reading Section 4.6 on SFC Proxy, I got confused. I think that >>>> the proxy function is explained in somewhat reverse order. It starts >>>> by the traffic received from an SFF. Why? How does the SFF forward the >>>> traffic to the proxy instead of to the SF? >>>> >>>> I hope you can shed some light into this. >>>> >>>> Regards, >>>> >>>> Behcet >>>> >>>> On Thu, Aug 14, 2014 at 12:12 PM, Joel M. Halpern >>>> wrote: >>>>> >>>>> >>>>> In the recent discussion on the SFC Proxy, Carlos and I understood that >>>>> the >>>>> current text is unclear. We need to fix it. >>>>> >>>>> It turned out that even he and I had different perspectives on what it >>>>> meant. He has persuaded me that the cleanest approach is not the one I >>>>> suggested earlier on the list. >>>>> So I am writing a bit of text to fix the proxy description (and then we >>>>> will >>>>> fix any other dangling references.) Since the group is considering >>>>> adoption >>>>> of the document, we wanted to make sure that the proposal is one other >>>>> folks >>>>> can live with. >>>>> >>>>> The approach is to treat the SFC Proxy as a logical element between the >>>>> SFF >>>>> and the SF. When the SFF wants to send a packet to an SF which >>>>> requires >>>>> proxy support, the packet goes instead to the proxy. The proxy does >>>>> what >>>>> is >>>>> necessary, works with the SF however it needs to, and when the packet >>>>> comes >>>>> back puts things back together and hands them back to the SFF. >>>>> >>>>> Just as we do not specify the delivery mechanism between the SFF and >>>>> the >>>>> SF, >>>>> we will not specify the delivery mechanism between the SFF and the SFC >>>>> Proxy >>>>> or between the SFC Proxy and the SF. >>>>> >>>>> I hope this is understandable and acceptable to folks. >>>>> Thank you, >>>>> Joel >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Aug 20 10:00: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 C7EEF1A0487 for ; Wed, 20 Aug 2014 10:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.569 X-Spam-Level: X-Spam-Status: No, score=-7.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 BO8uPoZZqoFS for ; Wed, 20 Aug 2014 10:00:02 -0700 (PDT) Received: from mxebdp04ex-public.idz.gs.com (mxe6.gs.com [207.17.33.102]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21FF31A047C for ; Wed, 20 Aug 2014 10:00:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,903,1400040000"; d="scan'208";a="128000144" Received: from unknown (HELO mxpbd02-public.ny.fw.gs.com) ([148.86.115.129]) by mxebdp04ex.idz.gs.com with ESMTP; 20 Aug 2014 13:00:00 -0400 From: "Zarny, Myo" X-sendergroup: RELAYLIST Received: from gshcbdp09ex.firmwide.corp.gs.com ([10.135.172.18]) by mxpbd02.ny.fw.gs.com with ESMTP; 20 Aug 2014 13:00:00 -0400 Received: from GSHCNHP01EX.firmwide.corp.gs.com (154.4.115.137) by gshcbdp09ex.firmwide.corp.gs.com (10.135.172.18) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 20 Aug 2014 13:00:00 -0400 Received: from GSCMAMP19EX.firmwide.corp.gs.com ([139.172.38.36]) by gshcnhp01ex.firmwide.corp.gs.com ([154.4.115.137]) with mapi; Wed, 20 Aug 2014 13:00:00 -0400 To: "'sarikaya@ieee.org'" , "'Joel M. Halpern'" Date: Wed, 20 Aug 2014 12:59:58 -0400 Thread-Topic: [sfc] Proposed SFC Architecture - SFC Proxy Thread-Index: Ac+8lxe836O5FSWtSPucy2B5dHJELgAAIdFA Message-ID: References: <53ECEDFE.8080007@joelhalpern.com> <53F3CEBC.40309@joelhalpern.com> <53F4C604.5020901@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-retentionstamp: Firmwide,Firmwide Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-WiganSS: 01000000010020gshcbdp09ex.firmwide.corp.gs.com ID004D Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/KwlKGhi5yihCTL2f-SWpW9OX4qg Cc: "'sfc@ietf.org'" Subject: Re: [sfc] Proposed SFC Architecture - SFC Proxy 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, 20 Aug 2014 17:00:06 -0000 SFP itself should be SF chain specific. It is to proxy in front of non-SFC = header-speaking SFs. SFP could be handling VXLAN, GRE, etc. (whatever the transport encap mechan= ism) but it does need to strip off the SF header before forwarding the rema= ining traffic to be consumed by the SF. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: 20 August 2014 12:52 PM To: Joel M. Halpern Cc: sfc@ietf.org Subject: Re: [sfc] Proposed SFC Architecture - SFC Proxy I have a feeling that proxy is introduced to deal with packets coming from = specific attachment circuits such as VLANs, tunnel-based circuits like GRE,= VXLAN, etc. Proxy is not necessarily SF specific. So these attachment circ= uits may contains various SFs such as firewalls, DPI, LI, etc. On Wed, Aug 20, 2014 at 11:00 AM, Joel M. Halpern wro= te: > You ask "why not start with the SFC-unaware SF?". > The reason is that one of the points of the proxy is to send a packet=20 > to that SFC_unaware SF in such a way that the SF can understand the=20 > packet, evne though it does not understand the SFC encapsulation. > So we have to start with a packet arriving with the SFC encapsulation.=20 > And talk about the transforms necessary to deliver that to the SFC-unawar= e SF. > The problem to be dealt with is to avoid demanding modification of the=20 > existing SFC-unaware SF, so that SFC is deployable. > > Yours, > Joel > > > On 8/20/14, 11:55 AM, Behcet Sarikaya wrote: >> >> On Tue, Aug 19, 2014 at 5:25 PM, Joel M. Halpern=20 >> >> wrote: >>> >>> Traffic arrives at the SFF from elsewhere (a prior SFF or the=20 >>> ingress >>> classifier.) >>> The SFF determines where to send it. It hinks, in this case, that=20 >>> it is sending it to an SF. However, the local information which=20 >>> tells the SFF how to do that (which is not specified by the=20 >>> architecture, and may or may not be in scope for the WG) actually=20 >>> directs it to send the traffic to the proxy. The proxy takes care=20 >>> of the actual interaction with the legacy service function. And=20 >>> then delivers the resulting packet back to the SFF, with the SFC=20 >>> encapsulation, as if it were an SFC-compliant service function. >>> >> >> Sorry but I still don't understand. >> >> Why not start with SFC-unaware SF? >> >> Isn't this where the need for proxy arises? >> >> Regards, >> >> Behcet >>> >>> Yours, >>> Joel >>> >>> >>> On 8/19/14, 6:15 PM, Behcet Sarikaya wrote: >>>> >>>> >>>> Hi Joel, >>>> >>>> When reading Section 4.6 on SFC Proxy, I got confused. I think that=20 >>>> the proxy function is explained in somewhat reverse order. It=20 >>>> starts by the traffic received from an SFF. Why? How does the SFF=20 >>>> forward the traffic to the proxy instead of to the SF? >>>> >>>> I hope you can shed some light into this. >>>> >>>> Regards, >>>> >>>> Behcet >>>> >>>> On Thu, Aug 14, 2014 at 12:12 PM, Joel M. Halpern=20 >>>> >>>> wrote: >>>>> >>>>> >>>>> In the recent discussion on the SFC Proxy, Carlos and I understood=20 >>>>> that the current text is unclear. We need to fix it. >>>>> >>>>> It turned out that even he and I had different perspectives on=20 >>>>> what it meant. He has persuaded me that the cleanest approach is=20 >>>>> not the one I suggested earlier on the list. >>>>> So I am writing a bit of text to fix the proxy description (and=20 >>>>> then we will fix any other dangling references.) Since the group=20 >>>>> is considering adoption of the document, we wanted to make sure=20 >>>>> that the proposal is one other folks can live with. >>>>> >>>>> The approach is to treat the SFC Proxy as a logical element=20 >>>>> between the SFF and the SF. When the SFF wants to send a packet=20 >>>>> to an SF which requires proxy support, the packet goes instead to=20 >>>>> the proxy. The proxy does what is necessary, works with the SF=20 >>>>> however it needs to, and when the packet comes back puts things=20 >>>>> back together and hands them back to the SFF. >>>>> >>>>> Just as we do not specify the delivery mechanism between the SFF=20 >>>>> and the SF, we will not specify the delivery mechanism between the=20 >>>>> SFF and the SFC Proxy or between the SFC Proxy and the SF. >>>>> >>>>> I hope this is understandable and acceptable to folks. >>>>> Thank you, >>>>> Joel >>>>> >>>>> _______________________________________________ >>>>> 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 Wed Aug 20 10:05: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 C75FA1A048F for ; Wed, 20 Aug 2014 10:05:39 -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 Ikb2G-H9UtLg for ; Wed, 20 Aug 2014 10:05:37 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC9C41A0491 for ; Wed, 20 Aug 2014 10:05:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id CD61E80524; Wed, 20 Aug 2014 10:05:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-198.clppva.east.verizon.net [70.106.135.198]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id B6B9D80528; Wed, 20 Aug 2014 10:05:35 -0700 (PDT) Message-ID: <53F4D55D.7020605@joelhalpern.com> Date: Wed, 20 Aug 2014 13:05:33 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Zarny, Myo" , "'sarikaya@ieee.org'" References: <53ECEDFE.8080007@joelhalpern.com> <53F3CEBC.40309@joelhalpern.com> <53F4C604.5020901@joelhalpern.com> 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/rwX0OfOaitqJ3ai5m18SJcxSlXk Cc: "'sfc@ietf.org'" Subject: Re: [sfc] Proposed SFC Architecture - SFC Proxy 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, 20 Aug 2014 17:05:41 -0000 a) Please do not use SFP as an abbreviation for SFC Proxy. We already have SFP meaning something else entirely. b) The SFC Proxy described in the archtiecture is not for the problem of handling transport mechanisms between SFF. THe assumption of the work as described in the charter is that adjacent SFF will have a transport in common, and that the SFC Encapsulation provides a means for the SFF to get the needed information independent of the various transports. c) The existing diagrams and text is very clear about the SFC Proxy being about support for SFC-unaware service functions. If we ned other kinds of transforming functions, please spell out the problems, but do not re-purpose things which are solving important and distinct problems already. Yours, Joel On 8/20/14, 12:59 PM, Zarny, Myo wrote: > SFP itself should be SF chain specific. It is to proxy in front of non-SFC header-speaking SFs. > > SFP could be handling VXLAN, GRE, etc. (whatever the transport encap mechanism) but it does need to strip off the SF header before forwarding the remaining traffic to be consumed by the SF. > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Behcet Sarikaya > Sent: 20 August 2014 12:52 PM > To: Joel M. Halpern > Cc: sfc@ietf.org > Subject: Re: [sfc] Proposed SFC Architecture - SFC Proxy > > I have a feeling that proxy is introduced to deal with packets coming from specific attachment circuits such as VLANs, tunnel-based circuits like GRE, VXLAN, etc. Proxy is not necessarily SF specific. So these attachment circuits may contains various SFs such as firewalls, DPI, LI, etc. > > > > On Wed, Aug 20, 2014 at 11:00 AM, Joel M. Halpern wrote: >> You ask "why not start with the SFC-unaware SF?". >> The reason is that one of the points of the proxy is to send a packet >> to that SFC_unaware SF in such a way that the SF can understand the >> packet, evne though it does not understand the SFC encapsulation. >> So we have to start with a packet arriving with the SFC encapsulation. >> And talk about the transforms necessary to deliver that to the SFC-unaware SF. >> The problem to be dealt with is to avoid demanding modification of the >> existing SFC-unaware SF, so that SFC is deployable. >> >> Yours, >> Joel >> >> >> On 8/20/14, 11:55 AM, Behcet Sarikaya wrote: >>> >>> On Tue, Aug 19, 2014 at 5:25 PM, Joel M. Halpern >>> >>> wrote: >>>> >>>> Traffic arrives at the SFF from elsewhere (a prior SFF or the >>>> ingress >>>> classifier.) >>>> The SFF determines where to send it. It hinks, in this case, that >>>> it is sending it to an SF. However, the local information which >>>> tells the SFF how to do that (which is not specified by the >>>> architecture, and may or may not be in scope for the WG) actually >>>> directs it to send the traffic to the proxy. The proxy takes care >>>> of the actual interaction with the legacy service function. And >>>> then delivers the resulting packet back to the SFF, with the SFC >>>> encapsulation, as if it were an SFC-compliant service function. >>>> >>> >>> Sorry but I still don't understand. >>> >>> Why not start with SFC-unaware SF? >>> >>> Isn't this where the need for proxy arises? >>> >>> Regards, >>> >>> Behcet >>>> >>>> Yours, >>>> Joel >>>> >>>> >>>> On 8/19/14, 6:15 PM, Behcet Sarikaya wrote: >>>>> >>>>> >>>>> Hi Joel, >>>>> >>>>> When reading Section 4.6 on SFC Proxy, I got confused. I think that >>>>> the proxy function is explained in somewhat reverse order. It >>>>> starts by the traffic received from an SFF. Why? How does the SFF >>>>> forward the traffic to the proxy instead of to the SF? >>>>> >>>>> I hope you can shed some light into this. >>>>> >>>>> Regards, >>>>> >>>>> Behcet >>>>> >>>>> On Thu, Aug 14, 2014 at 12:12 PM, Joel M. Halpern >>>>> >>>>> wrote: >>>>>> >>>>>> >>>>>> In the recent discussion on the SFC Proxy, Carlos and I understood >>>>>> that the current text is unclear. We need to fix it. >>>>>> >>>>>> It turned out that even he and I had different perspectives on >>>>>> what it meant. He has persuaded me that the cleanest approach is >>>>>> not the one I suggested earlier on the list. >>>>>> So I am writing a bit of text to fix the proxy description (and >>>>>> then we will fix any other dangling references.) Since the group >>>>>> is considering adoption of the document, we wanted to make sure >>>>>> that the proposal is one other folks can live with. >>>>>> >>>>>> The approach is to treat the SFC Proxy as a logical element >>>>>> between the SFF and the SF. When the SFF wants to send a packet >>>>>> to an SF which requires proxy support, the packet goes instead to >>>>>> the proxy. The proxy does what is necessary, works with the SF >>>>>> however it needs to, and when the packet comes back puts things >>>>>> back together and hands them back to the SFF. >>>>>> >>>>>> Just as we do not specify the delivery mechanism between the SFF >>>>>> and the SF, we will not specify the delivery mechanism between the >>>>>> SFF and the SFC Proxy or between the SFC Proxy and the SF. >>>>>> >>>>>> I hope this is understandable and acceptable to folks. >>>>>> Thank you, >>>>>> Joel >>>>>> >>>>>> _______________________________________________ >>>>>> 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 Wed Aug 20 18:15: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 731091A6FBB for ; Wed, 20 Aug 2014 18:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 tzkYmMZgntvZ for ; Wed, 20 Aug 2014 18:15: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 67E3B1A6F99 for ; Wed, 20 Aug 2014 18:15:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLM42923; Thu, 21 Aug 2014 01:15:10 +0000 (GMT) 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, 21 Aug 2014 02:15:08 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.209]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Thu, 21 Aug 2014 09:15:05 +0800 From: "Songhaibin (A)" To: "sarikaya@ieee.org" , "Joel M. Halpern" Thread-Topic: [sfc] Proposed SFC Architecture - SFC Proxy Thread-Index: AQHPt+TPo38ABPGyXUWnEDaXaHE5r5vYAEEAgAACrACAASVngIAAAWIAgAAOhwCAARFNUA== Date: Thu, 21 Aug 2014 01:15:04 +0000 Message-ID: References: <53ECEDFE.8080007@joelhalpern.com> <53F3CEBC.40309@joelhalpern.com> <53F4C604.5020901@joelhalpern.com> 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: 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/jKoU_-8Mco98DHid0c0LpOzfb6A Cc: "sfc@ietf.org" Subject: Re: [sfc] Proposed SFC Architecture - SFC Proxy 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, 21 Aug 2014 01:15:15 -0000 SFC Proxy is used for translation between the legacy service functions and = SFF. Since all service functions are middle boxes, so the traffic is not st= arted from a SF instance.=20 I agree that the architecture draft should not specify any detail of the SF= C proxy translation process. You can look at the following draft for more d= etails on the translation. http://tools.ietf.org/html/draft-song-sfc-legacy-sf-mapping-02 Best Regards! -Haibin > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Behcet Sarikaya > Sent: Thursday, August 21, 2014 12:52 AM > To: Joel M. Halpern > Cc: sfc@ietf.org > Subject: Re: [sfc] Proposed SFC Architecture - SFC Proxy >=20 > I have a feeling that proxy is introduced to deal with packets coming fro= m > specific attachment circuits such as VLANs, tunnel-based circuits like GR= E, > VXLAN, etc. Proxy is not necessarily SF specific. So these attachment cir= cuits > may contains various SFs such as firewalls, DPI, LI, etc. >=20 >=20 >=20 > On Wed, Aug 20, 2014 at 11:00 AM, Joel M. Halpern > wrote: > > You ask "why not start with the SFC-unaware SF?". > > The reason is that one of the points of the proxy is to send a packet > > to that SFC_unaware SF in such a way that the SF can understand the > > packet, evne though it does not understand the SFC encapsulation. > > So we have to start with a packet arriving with the SFC encapsulation. > > And talk about the transforms necessary to deliver that to the SFC-unaw= are > SF. > > The problem to be dealt with is to avoid demanding modification of the > > existing SFC-unaware SF, so that SFC is deployable. > > > > Yours, > > Joel > > > > > > On 8/20/14, 11:55 AM, Behcet Sarikaya wrote: > >> > >> On Tue, Aug 19, 2014 at 5:25 PM, Joel M. Halpern > >> > >> wrote: > >>> > >>> Traffic arrives at the SFF from elsewhere (a prior SFF or the > >>> ingress > >>> classifier.) > >>> The SFF determines where to send it. It hinks, in this case, that > >>> it is sending it to an SF. However, the local information which > >>> tells the SFF how to do that (which is not specified by the > >>> architecture, and may or may not be in scope for the WG) actually > >>> directs it to send the traffic to the proxy. The proxy takes care > >>> of the actual interaction with the legacy service function. And > >>> then delivers the resulting packet back to the SFF, with the SFC > >>> encapsulation, as if it were an SFC-compliant service function. > >>> > >> > >> Sorry but I still don't understand. > >> > >> Why not start with SFC-unaware SF? > >> > >> Isn't this where the need for proxy arises? > >> > >> Regards, > >> > >> Behcet > >>> > >>> Yours, > >>> Joel > >>> > >>> > >>> On 8/19/14, 6:15 PM, Behcet Sarikaya wrote: > >>>> > >>>> > >>>> Hi Joel, > >>>> > >>>> When reading Section 4.6 on SFC Proxy, I got confused. I think that > >>>> the proxy function is explained in somewhat reverse order. It > >>>> starts by the traffic received from an SFF. Why? How does the SFF > >>>> forward the traffic to the proxy instead of to the SF? > >>>> > >>>> I hope you can shed some light into this. > >>>> > >>>> Regards, > >>>> > >>>> Behcet > >>>> > >>>> On Thu, Aug 14, 2014 at 12:12 PM, Joel M. Halpern > >>>> > >>>> wrote: > >>>>> > >>>>> > >>>>> In the recent discussion on the SFC Proxy, Carlos and I understood > >>>>> that the current text is unclear. We need to fix it. > >>>>> > >>>>> It turned out that even he and I had different perspectives on > >>>>> what it meant. He has persuaded me that the cleanest approach is > >>>>> not the one I suggested earlier on the list. > >>>>> So I am writing a bit of text to fix the proxy description (and > >>>>> then we will fix any other dangling references.) Since the group > >>>>> is considering adoption of the document, we wanted to make sure > >>>>> that the proposal is one other folks can live with. > >>>>> > >>>>> The approach is to treat the SFC Proxy as a logical element > >>>>> between the SFF and the SF. When the SFF wants to send a packet > >>>>> to an SF which requires proxy support, the packet goes instead to > >>>>> the proxy. The proxy does what is necessary, works with the SF > >>>>> however it needs to, and when the packet comes back puts things > >>>>> back together and hands them back to the SFF. > >>>>> > >>>>> Just as we do not specify the delivery mechanism between the SFF > >>>>> and the SF, we will not specify the delivery mechanism between the > >>>>> SFF and the SFC Proxy or between the SFC Proxy and the SF. > >>>>> > >>>>> I hope this is understandable and acceptable to folks. > >>>>> Thank you, > >>>>> Joel > >>>>> > >>>>> _______________________________________________ > >>>>> 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 From nobody Wed Aug 20 20:04: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 D9A5D1A007B for ; Wed, 20 Aug 2014 20:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 AnhbqnBVl0X7 for ; Wed, 20 Aug 2014 20:03: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 948ED1A6F54 for ; Wed, 20 Aug 2014 20:03:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIL71955; Thu, 21 Aug 2014 03:03:49 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 21 Aug 2014 04:03:48 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.204]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Thu, 21 Aug 2014 11:03:37 +0800 From: Xuxiaohu To: "Carlos Pignataro (cpignata)" , "Andrew G. Malis" Thread-Topic: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.txt Thread-Index: AQHPsj5Zo8zwYtoiUEi/TNVKSSoPaJvac05g Date: Thu, 21 Aug 2014 03:03:37 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A9F33@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A4805@NKGEML512-MBS.china.huawei.com> <57B2ECF6-8DB4-4E23-BB14-E030EB74E09C@alcatel-lucent.com> <2691CE0099834E4A9C5044EEC662BB9D453CBFBE@dfweml701-chm.china.huawei.com> <5F8C4A2F-3C60-459D-92F7-31EA1DA9E469@cisco.com> <3DCDEFE3-081D-470A-B330-1A01A618111E@cisco.com> In-Reply-To: <3DCDEFE3-081D-470A-B330-1A01A618111E@cisco.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: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A9F33NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/5LhKvuikPbXRq45HthT6zc7oqTE Cc: "Dolganow, Andrew \(Andrew\)" , "sfc@ietf.org" , Lucy yong , "Joel M. Halpern" Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-architecture-01.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, 21 Aug 2014 03:04:00 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A9F33NKGEML512MBSchi_ Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable Hi Carlos, Please see my comment inline. From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] Sent: Thursday, August 14, 2014 11:41 PM To: Andrew G. Malis Cc: Lucy yong; Xuxiaohu; Dolganow, Andrew (Andrew); sfc@ietf.org; Joel M. H= alpern Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-arch= itecture-01.txt Hi, Andy, Thanks for the response -- from an architecture perspective, what I think i= s important to capture is that the SFC Encapsulation carries the specificat= ion of the Service Function Path. I believe that the specifics of how that = happens in the SFP ID belongs in the encapsulation document. But architectu= rally we want to capture that the SFC encapsulation specifies the SFP and h= ave a clean and simple architecture independent of transports and underlyin= g topologies. Now, separately from this specific discussion, you do mention discussion of= specific cases and a potential encap value for that. Could you share some = more specifics? This would be useful for the discussion of the encapsulatio= n WG deliverable. Xiaohu shared two pointers to two individual I-Ds, and it= seems (again, not an architectural comment but jumping ahead) that a null = SPF ID would not make those cases interoperate. Does that call for a per-tr= ansport solution against the charter? Looking at the draft-ietf-sfc-problem= -statement, specifically Sections 2.1 and 2.6, the reason why SFC exists is= to provide that transport and topological independence as opposed to exist= ing (transport dependent) ways of chaining network services. [Xiaohu] In fact, the MPLS-SPRING-based SFC approach fully meets the transp= ort-independent requirement of SFC. The underlay (a.k.a. transport) could = be IP, MPLS or even Ethernet network. It just happened that the MPLS techno= logy which had been widely deemed as a transport technology is now used as = the service function overlay (i.e., encoding the SFC or the SFP information= by an MPLS label stack). Best Regards, Xiaohu Thanks, Carlos. On Aug 13, 2014, at 9:47 AM, Andrew G. Malis > wrote: Carlos, I see your point, but there's also been discussion of cases where only the = metadata is required. In that case, you woud either be carrying a null SFP = ID along with the metadata, or just the metadata. It seems more efficient t= o me to just carry the metadata, but if you want to insist that there's alw= ays an SPF ID, then we need to make sure that it can be a null ID. Cheers, Andy On Tue, Aug 12, 2014 at 9:51 PM, Carlos Pignataro (cpignata) > wrote: Hi, Andy, Lucy, Flexibility is certainly good as long as it does not get in the way of inte= roperability. This architecture drives a balance and tradeoff in which opti= ons are maximized while having interoperability as the goal. >From a technical perspective, the SFC Encapsulation specifies the Service F= unction Path to allow for end-to-end SFPs and interoperable implementations= . One of the key principles of this architecture is that the SFC Encapsulat= ion is transport-independent. The text is flexible such that any transport = may be used to carry the SFC encapsulation. However, two SFs part of an SFP= that are not adjacent in the services topology can have different transpor= t encapsulations but need the SFC-encapsulation (minimum invariant encap) t= o specify the SPF. This is within the service topology, which again is inde= pendent from the underlay topology as an architectural principle. Please no= te that the use of the SFC encapsulation to specify the SFP and the SFFs an= d SFs use of this is articulated throughout the architecture. This architec= ture also allows for flexibility in bringing SFC-unaware SFs by proxy as th= e one gateway, to provide backwards compatibility, but attempts to carry fo= rward interoperability. Consequently, for "SFC Aware" chains, the architect= ural choice that follows the principles is to carry the SFP id. It is (also= ) to convey shared context (when demanded by the use case) using the SFC-en= capsulation for similar reasons. As a WG, I believe we should first strive = for a single service-level data plane encapsulation as per the current WG c= harter and based on that provide the most optimal placement of functions an= d identifiers. Note also that I was pointing to the charter because I believe these points= were discussed already to get to the current charter text. Best, Carlos. On Aug 11, 2014, at 10:47 AM, Lucy yong > wrote: I agree Andy=B9s point. Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Andrew G. Malis Sent: Friday, August 08, 2014 4:47 PM To: Carlos Pignataro (cpignata) Cc: Xuxiaohu; Dolganow, Andrew (Andrew); sfc@ietf.org;= Joel M. Halpern Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-arch= itecture-01.txt Carlos, I agree that the charter requires the encapsulation to support each of the = bullet items, but there's no requirement that every encapsulated packet wil= l need all of the bullet items supported, so I'm trying to keep the text as= flexible as possible to not preclude possible solutions. Cheers, Andy On Fri, Aug 8, 2014 at 11:09 AM, Carlos Pignataro (cpignata) > wrote: Hi, Andrew, On Aug 8, 2014, at 8:53 AM, Dolganow, Andrew (Andrew) > wrote: > I agree that we should have stronger separation of two functions: SFP and= metadata. > > How about small edit to what Andy proposed: > > SFC Encapsulation: A data plane encapsulation that encodes either one or= both of > - the SFP > - metadata (data plane context information). Looking at http://datatracker.ietf.org/wg/sfc/charter/, there is no "either= one or both of". In fact, looking at the history of the charter text, the = text for SFC Encapsulation is a bullet list form of a longer sentence that = includes "and" only (see 00-09). Thanks, Carlos. >> The SFP Encapsulation is used by the SFC-aware functions, such as the SF= F and SFC-aware SFs, and is not used for network packet forwarding. > > > Andrew > > Sent from my iPhone > >> On Aug 7, 2014, at 9:13 PM, "Xuxiaohu" > wrote: >> >> I fully agree with Andy=B9s point that not every usage of the encapsulat= ion will need both the SFP identification and the metadata. It=B9s better t= hat the SFC encapsulation could be flexibly used for carrying SFP identific= ation, metadata or both. Otherwise, it seems that those SFC approaches whic= h don=B9t use the SFC encapsulation for SFC selection would have to separat= ely define the way of carrying metadata. >> >> Best regards, >> Xiaohu >> >> From: sfc [mailto:sfc-bounces@ietf.org] On = Behalf Of Andrew G. Malis >> Sent: Thursday, August 07, 2014 9:06 PM >> To: Carlos Pignataro (cpignata) >> Cc: Joel M. Halpern; sfc@ietf.org >> Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-sfc-a= rchitecture-01.txt >> >> Carlos, >> >> When I re-read the definition, it seemed to me to be more of a string of= thoughts than a concise definition, which is why I was trying to tighten i= t up. A definition is meant to be a short summary for quick reference, whil= e the discussion in 4.1 goes into the more formal details. Otherwise, you = would just repeat the entire section 4.1 in section 1.3. This is why it do= esn't need to be in separate sentences. The "and/or" is because not every u= sage of the encapsulation will need both the SFP identification and the met= adata, so the definition needs to concisely convey that. >> >> Cheers, >> Andy >> >> On Thu, Aug 7, 2014 at 8:51 AM, Carlos Pignataro (cpignata) > wrote: >> Thank you for going back and checking, Andy! >> >> Which specific part of the current definition do you believe is loose en= ough to need tightening? >> >> I believe that your new proposal falls shorter than the existing text in= a few areas: >> =80 First, it combines two different functions (SFP identification and m= etadata/context information) into a single sentence. This opposes the chang= e we just made based on your preference in Section 4.1, which breaks the tw= o functions into two sentences, for reader clarity. While longer, it's simp= ler. >> =80 Second, it introduces an extraneous "and/or" that would change the m= eaning, and negate the "at a minimum" existing bit. That would not be simpl= ifying. >> =80 Third, there is no third but three bullets look better :-) >> >> Net-net, the original text, even when longer in character count, seems m= ore clear and simpler to the reader (because of the separated sentences), I= MHO. >> >> Thanks, >> >> Carlos. >> >> On Aug 7, 2014, at 8:20 AM, Andrew G. Malis > wrote: >> >> >> Carlos and Joel, >> >> In light of the previous discussions, I went back and re-read this curre= nt definition of SFC Encapsulation in the text (section 1.3): >> >> SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP >> identification, and is used by the SFC-aware functions, such as >> the SFF and SFC-aware SFs. The SFC Encapsulation is not used >> for network packet forwarding. In addition to SFP >> identification, the SFC encapsulation carries dataplane context >> information, also referred to as metadata. >> >> I think this could be tightened up to make simpler for the reader: >> >> SFC Encapsulation: A data plane encapsulation that identifies the SFP a= nd/or provides metadata (data plane context information). The SFP Encapsula= tion is used by the SFC-aware functions, such as the SFF and SFC-aware SFs,= and is not used for network packet forwarding. >> >> Thanks, >> Andy >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A9F33NKGEML512MBSchi_ Content-Type: text/html; charset="windows-1257" Content-Transfer-Encoding: quoted-printable

Hi Carlos,=

 = ;

Please see= my comment inline.

 = ;

From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.co= m]
Sent: Thursday, August 14, 2014 11:41 PM
To: Andrew G. Malis
Cc: Lucy yong; Xuxiaohu; Dolganow, Andrew (Andrew); sfc@ietf.org; Jo= el M. Halpern
Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged-s= fc-architecture-01.txt

 

Hi, Andy,

 

Thanks for the response -- from= an architecture perspective, what I think is important to capture is that = the SFC Encapsulation carries the specification of the Service Function Pat= h. I believe that the specifics of how that happens in the SFP ID belongs in the encapsulation document. But arch= itecturally we want to capture that the SFC encapsulation specifies the SFP= and have a clean and simple architecture independent of transports and und= erlying topologies.

 

Now, separately from this speci= fic discussion, you do mention discussion of specific cases and a potential= encap value for that. Could you share some more specifics? This would be u= seful for the discussion of the encapsulation WG deliverable. Xiaohu shared two pointers to two individual I-Ds, and it = seems (again, not an architectural comment but jumping ahead) that a null S= PF ID would not make those cases interoperate. Does that call for a per-tra= nsport solution against the charter? Looking at the draft-ietf-sfc-problem-statement, specifically Section= s 2.1 and 2.6, the reason why SFC exists is to provide that transport and t= opological independence as opposed to existing (transport dependent) ways o= f chaining network services. 

 = ;

[Xiaohu] In fact, the MPLS-SPRING-b= ased SFC approach fully meets the transport-independent requirement of SFC.=  The underlay (a.k.a. transport) could be IP, MPLS or even Ethernet network. It just happened that the MPLS technology which had been= widely deemed as a transport technology is now used as the service functio= n overlay (i.e., encoding the SFC or the SFP information by an MPLS label s= tack).

 = ;

Best Regar= ds,

Xiaohu

 

Thanks,

 

Carlos.

 

On Aug 13, 2014, at 9:47 AM, An= drew G. Malis <agmalis@gmail.com> wrote:



Carlos,

 

I see your point, but there's a= lso been discussion of cases where only the metadata is required. In that c= ase, you woud either be carrying a null SFP ID along with the metadata, or = just the metadata. It seems more efficient to me to just carry the metadata, but if you want to insist that there's a= lways an SPF ID, then we need to make sure that it can be a null ID.

 

Cheers,

Andy

=  

On Tue, Aug 12, 2014 at 9:51 PM= , Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:

Hi, Andy, Lucy,

 

Flexibility is certainly good a= s long as it does not get in the way of interoperability. This architecture= drives a balance and tradeoff in which options are maximized while having = interoperability as the goal.

 

From a technical perspective, t= he SFC Encapsulation specifies the Service Function Path to allow for end-t= o-end SFPs and interoperable implementations. One of the key principles of = this architecture is that the SFC Encapsulation is transport-independent. The text is flexible such that any transport may= be used to carry the SFC encapsulation. However, two SFs part of an SFP th= at are not adjacent in the services topology can have different transport e= ncapsulations but need the SFC-encapsulation (minimum invariant encap) to specify the SPF. This is within the service t= opology, which again is independent from the underlay topology as an archit= ectural principle. Please note that the use of the SFC encapsulation to spe= cify the SFP and the SFFs and SFs use of this is articulated throughout the architecture. This architecture = also allows for flexibility in bringing SFC-unaware SFs by proxy as the one= gateway, to provide backwards compatibility, but attempts to carry forward= interoperability. Consequently, for "SFC Aware" chains, the architectural choice that follows th= e principles is to carry the SFP id. It is (also) to convey shared context = (when demanded by the use case) using the SFC-encapsulation for similar rea= sons. As a WG, I believe we should first strive for a single service-level data plane encapsulation as per the curren= t WG charter and based on that provide the most optimal placement of functi= ons and identifiers.

 

Note also that I was pointing t= o the charter because I believe these points were discussed already to get = to the current charter text.

 

Best,

 

Carlos.

 

On Aug 11, 2014, at 10:47 AM, L= ucy yong <lucy= .yong@huawei.com> wrote:



I agree An= dy=B9s point.

 

Lucy

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Andrew G. Malis
Sent: Friday, August 08, 2014 4:47 PM
To: Carlos Pignataro (cpignata)
Cc: Xuxiaohu; Dolganow, Andrew (Andrew); sfc@ietf.org<= /span>; Joel M. Halpern
Subject: Re: [sfc] Definition of SFC Encapsulation in draft-mer= ged-sfc-architecture-01.txt

 

Carlos,

 

I agree that the charter requir= es the encapsulation to support each of the bullet items, but there's no re= quirement that every encapsulated packet will need all of the bullet items = supported, so I'm trying to keep the text as flexible as possible to not preclude possible solutions.

 

Cheers,

Andy

=  

On Fri, Aug 8, 2014 at 11:09 AM= , Carlos Pignataro (cpignata) <cpignata@cisco.com&g= t; wrote:

Hi, Andrew,

=
On Aug 8, 2014, at 8:53 AM, Dolganow, Andrew (Andrew) <andrew.dolganow@alcatel-lucent.com> wrote:

> I agree that we should have stronger separation of two functions: SFP = and metadata.
>
> How about small edit to what Andy proposed:
>
> SFC Encapsulation:  A data plane encapsulation that encodes eithe= r one or both of
> - the SFP
> - metadata (data plane context information).

Looking at http://datatracker.ietf.org/wg/sfc/charter/, there = is no "either one or both of". In fact, looking at the history of the charter text, the text for SFC Encapsulation is a bu= llet list form of a longer sentence that includes "and" only (see= 00-09).

Thanks,

Carlos.

=
>> The SFP Encapsulation is used by the SFC-aware functions, such as = the SFF and SFC-aware SFs, and is not used for network packet forwarding. >
>
> Andrew
>
> Sent from my iPhone
>
>> On Aug 7, 2014, at 9:13 PM, "Xuxiaohu" <xu= xiaohu@huawei.com> wrote:
>>
>> I fully agree with Andy=B9s point that not every usage of the enca= psulation will need both the SFP identification and the metadata. It=B9s be= tter that the SFC encapsulation could be flexibly used for carrying SFP ide= ntification, metadata or both. Otherwise, it seems that those SFC approaches which don=B9t use the SFC encapsulation= for SFC selection would have to separately define the way of carrying meta= data.
>>
>> Best regards,
>> Xiaohu
>>
>> From: sfc [mailto:sfc-bounces@ietf.org] O= n Behalf Of Andrew G. Malis
>> Sent: Thursday, August 07, 2014 9:06 PM
>> To: Carlos Pignataro (cpignata)
>> Cc: Joel M. Halpern; sfc@ietf.org
>> Subject: Re: [sfc] Definition of SFC Encapsulation in draft-merged= -sfc-architecture-01.txt
>>
>> Carlos,
>>
>> When I re-read the definition, it seemed to me to be more of a str= ing of thoughts than a concise definition, which is why I was trying to tig= hten it up. A definition is meant to be a short summary for quick reference= , while the discussion in 4.1 goes into the more formal details.  Otherwise, you would just repeat the entire= section 4.1 in section 1.3.  This is why it doesn't need to be in sep= arate sentences. The "and/or" is because not every usage of the e= ncapsulation will need both the SFP identification and the metadata, so the definition needs to concisely convey that.
>>
>> Cheers,
>> Andy
>>
>> On Thu, Aug 7, 2014 at 8:51 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
>> Thank you for going back and checking, Andy!
>>
>> Which specific part of the current definition do you believe is lo= ose enough to need tightening?
>>
>> I believe that your new proposal falls shorter than the existing t= ext in a few areas:
>> =80 First, it combines two different functions (SFP identification= and metadata/context information) into a single sentence. This opposes the= change we just made based on your preference in Section 4.1, which breaks = the two functions into two sentences, for reader clarity. While longer, it's simpler.
>> =80 Second, it introduces an extraneous "and/or" that wo= uld change the meaning, and negate the "at a minimum" existing bi= t. That would not be simplifying.
>> =80 Third, there is no third but three bullets look better :-)
>>
>> Net-net, the original text, even when longer in character count, s= eems more clear and simpler to the reader (because of the separated sentenc= es), IMHO.
>>
>> Thanks,
>>
>> Carlos.
>>
>> On Aug 7, 2014, at 8:20 AM, Andrew G. Malis <agmalis@g= mail.com> wrote:
>>
>>
>> Carlos and Joel,
>>
>> In light of the previous discussions, I went back and re-read this= current definition of SFC Encapsulation in the text (section 1.3):
>>
>>   SFC Encapsulation:  The SFC Encapsulation provides at = a minimum SFP
>>        identification, and is used by the SFC-= aware functions, such as
>>        the SFF and SFC-aware SFs.  The SF= C Encapsulation is not used
>>        for network packet forwarding.  In= addition to SFP
>>        identification, the SFC encapsulation c= arries dataplane context
>>        information, also referred to as metada= ta.
>>
>> I think this could be tightened up to make simpler for the reader:=
>>
>> SFC Encapsulation:  A data plane encapsulation that identifie= s the SFP and/or provides metadata (data plane context information). The SF= P Encapsulation is used by the SFC-aware functions, such as the SFF and SFC= -aware SFs, and is not used for network packet forwarding.
>>
>> Thanks,
>> Andy
>>
>>
>>
>> _______________________________________________
>> sfc mailing list
>> sfc@ietf.org
>> https://www.ietf.org/mailman/listi= nfo/sfc

 

 

 

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A9F33NKGEML512MBSchi_-- From nobody Fri Aug 22 00:53: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 1E97B1A0119 for ; Fri, 22 Aug 2014 00:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 FnB9NNZGjyIt for ; Fri, 22 Aug 2014 00:53:46 -0700 (PDT) Received: from mc30.lon.server.colt.net (mc30.lon.server.colt.net [212.74.77.110]) by ietfa.amsl.com (Postfix) with ESMTP id C42C01A010E for ; Fri, 22 Aug 2014 00:53:45 -0700 (PDT) Received: from mc30.lon.server.colt.net (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 95F8D1CB6F1 for ; Fri, 22 Aug 2014 07:53:13 +0000 (UTC) Received: from mx3.qosmos.com (unknown [195.68.92.43]) by mc30.lon.server.colt.net (Postfix) with ESMTP id 7F6A71CB283 for ; Fri, 22 Aug 2014 07:53:13 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.04,378,1406584800"; d="scan'208";a="1196116" Received: from unknown (HELO mailbox.jungle.qosmos.com) ([10.12.1.9]) by mx3.qosmos.com with ESMTP; 22 Aug 2014 09:53:13 +0200 Received: from CAROUBIER.jungle.qosmos.com ([169.254.1.52]) by LILAS.jungle.qosmos.com ([fe80::5524:2c18:b2c3:74d4%14]) with mapi id 14.01.0438.000; Fri, 22 Aug 2014 09:54:09 +0200 From: Nicolas BOUTHORS To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Proposed SFC Architecture - SFC Proxy Thread-Index: AQHPuKQWIfz454E2AkCXo0YdLyfWDpvcSXMd Date: Fri, 22 Aug 2014 07:53:47 +0000 Message-ID: <76B41B8FACE1514795D30EC137FF391D45A5B0@CAROUBIER.jungle.qosmos.com> References: <53ECEDFE.8080007@joelhalpern.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A767E@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A767E@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.0.22] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No X-TM-AS-Product-Ver: IMSVA-8.2.0.1679-7.5.0.1018-20898.005 X-TM-AS-Result: No--11.707-5.0-31-10 X-imss-scan-details: No--11.707-5.0-31-10 X-TM-AS-User-Approved-Sender: No X-TMASE-Version: IMSVA-8.2.0.1679-7.5.1018-20898.005 X-TMASE-Result: 10--11.706600-5.000000 X-TMASE-MatchedRID: hls5oAVArl9Cl9DEsHnSbUKcYi5Qw/RVW9oi9MZ8/xIrquwya2HlJnLO APNCmmpADBD37DJ+PFh/KLaJof5FW1L+KwgRcYO/VU3yVpaj3QwGF+E6mzeNqCIWzbRXGr/CFEc adR8cJwYPuYGWrR7Mjy+BdvF32Rrz+uobhwVz9gBHL73iZZtH5lsChor7BLiNknle09V58D0Kxu bA4ug3e0+GEYcMYNslXAoIGDy0fnzIpfkf1HYPC8+ayFtEW0uYnbR1KGab5XkzFWOYrWw6Aw42c I60OgkFmoTKpjV2t0UcOfC+voH6NBgHZ8655DOP/sToY2qzpx5dT8gO3hPj4foLR4+zsDTtCx9q oxmS2x3ZmQ+yOuoPRO5YfDO8Jygr2z6zdkD7YG/KoGoCFzScWA== Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ph6T4eA1iWsT_Uk6S6KijaFhl3U Subject: Re: [sfc] Proposed SFC Architecture - SFC Proxy 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, 22 Aug 2014 07:53:48 -0000 I understand and support this proposal when it comes to "legacy" SF working= still as transparent middleboxes. =0A= =0A= There are however many Legacy SF which are not transparent, in which case I= can see two options=0A= 1) consider that such Legacy SF always in effect terminate a chain=0A= 2) introduce the concept of Re-classification of the modified traffic, to i= dentify the target chain and restore forwarding=0A= =0A= The latter would seem preferable as it would also allow room for relaying m= etadata.=0A= =0A= I am not sure if this should be seen as part of an SF-Proxy, or as an SFF f= unction for "non transparent SF".=0A= =0A= Nicolas=0A= -----Original Message-----=0A= From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern=0A= Sent: Friday, August 15, 2014 1:13 AM=0A= To: sfc@ietf.org=0A= Subject: [sfc] Proposed SFC Architecture - SFC Proxy=0A= =0A= In the recent discussion on the SFC Proxy, Carlos and I understood that the= current text is unclear. We need to fix it.=0A= =0A= It turned out that even he and I had different perspectives on what it mean= t. He has persuaded me that the cleanest approach is not the one I suggest= ed earlier on the list.=0A= So I am writing a bit of text to fix the proxy description (and then we wil= l fix any other dangling references.) Since the group is considering adopt= ion of the document, we wanted to make sure that the proposal is one other = folks can live with.=0A= =0A= The approach is to treat the SFC Proxy as a logical element between the SFF= and the SF. When the SFF wants to send a packet to an SF which requires p= roxy support, the packet goes instead to the proxy. The proxy does what is= necessary, works with the SF however it needs to, and when the packet come= s back puts things back together and hands them back to the SFF.=0A= =0A= Just as we do not specify the delivery mechanism between the SFF and the SF= , we will not specify the delivery mechanism between the SFF and the SFC Pr= oxy or between the SFC Proxy and the SF.=0A= =0A= I hope this is understandable and acceptable to folks.=0A= Thank you,=0A= Joel=0A= =0A= _______________________________________________=0A= sfc mailing list=0A= sfc@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sfc=0A= =0A= =0A= From nobody Fri Aug 22 06:44: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 DD3811A03A8 for ; Fri, 22 Aug 2014 06:44:23 -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 C_ErlUV1Wf23 for ; Fri, 22 Aug 2014 06:44:22 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E9D1A03B4 for ; Fri, 22 Aug 2014 06:44:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id C8B961BC1641; Fri, 22 Aug 2014 06:44:21 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-198.clppva.east.verizon.net [70.106.135.198]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 0312E1BC163F; Fri, 22 Aug 2014 06:44:20 -0700 (PDT) Message-ID: <53F74934.5000401@joelhalpern.com> Date: Fri, 22 Aug 2014 09:44: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.6.0 MIME-Version: 1.0 To: Nicolas BOUTHORS , "sfc@ietf.org" References: <53ECEDFE.8080007@joelhalpern.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A767E@NKGEML512-MBS.china.huawei.com> <76B41B8FACE1514795D30EC137FF391D45A5B0@CAROUBIER.jungle.qosmos.com> In-Reply-To: <76B41B8FACE1514795D30EC137FF391D45A5B0@CAROUBIER.jungle.qosmos.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/uCqDyFD_fJ6Ek1AVY1Jzp8cTLOU Subject: Re: [sfc] Proposed SFC Architecture - SFC Proxy 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, 22 Aug 2014 13:44:24 -0000 Nicolas, the architecture already has provision for reclassification. And we have been quite careful not to specify what techniques the proxy will or can use to do its job. In the abstract it can use any technique up to and including intuition (if only we could make that work) to do its job. So the architecture does not require that the legacy SFC-unaware service function be transparent. Many likely techniques for building the proxy require specific kinds of transparency. That is why we are not specifying how the proxy works. My expectation is that there will be a range of proxy techniques, each used with a subset of sfc-unaware SFs. Yes, deployment will be somewhat harder. Working around limitations is harder. Also, I expect that there are some (I hope a very small portion) sfc-unaware SFs that are sufficiently difficult that the only practical solution will be for the vendor to upgrade their system. But that is also not for the WG to mandate. Yours, Joel On 8/22/14, 3:53 AM, Nicolas BOUTHORS wrote: > I understand and support this proposal when it comes to "legacy" SF working still as transparent middleboxes. > > There are however many Legacy SF which are not transparent, in which case I can see two options > 1) consider that such Legacy SF always in effect terminate a chain > 2) introduce the concept of Re-classification of the modified traffic, to identify the target chain and restore forwarding > > The latter would seem preferable as it would also allow room for relaying metadata. > > I am not sure if this should be seen as part of an SF-Proxy, or as an SFF function for "non transparent SF". > > Nicolas > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Friday, August 15, 2014 1:13 AM > To: sfc@ietf.org > Subject: [sfc] Proposed SFC Architecture - SFC Proxy > > In the recent discussion on the SFC Proxy, Carlos and I understood that the current text is unclear. We need to fix it. > > It turned out that even he and I had different perspectives on what it meant. He has persuaded me that the cleanest approach is not the one I suggested earlier on the list. > So I am writing a bit of text to fix the proxy description (and then we will fix any other dangling references.) Since the group is considering adoption of the document, we wanted to make sure that the proposal is one other folks can live with. > > The approach is to treat the SFC Proxy as a logical element between the SFF and the SF. When the SFF wants to send a packet to an SF which requires proxy support, the packet goes instead to the proxy. The proxy does what is necessary, works with the SF however it needs to, and when the packet comes back puts things back together and hands them back to the SFF. > > Just as we do not specify the delivery mechanism between the SFF and the SF, we will not specify the delivery mechanism between the SFF and the SFC Proxy or between the SFC Proxy and the SF. > > I hope this is understandable and acceptable to folks. > Thank you, > Joel > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > From nobody Sat Aug 23 13:47:29 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 7D3F41A88EE for ; Sat, 23 Aug 2014 13:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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.668, 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 ufgYwBncl1Zz for ; Sat, 23 Aug 2014 13:47:25 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C52111A88EB for ; Sat, 23 Aug 2014 13:47:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9643; q=dns/txt; s=iport; t=1408826845; x=1410036445; h=from:to:cc:subject:date:message-id:references: mime-version; bh=7/pFyv4JfGrCVu77rV2w4y22dvlWchCbhgFoisAnKQo=; b=NIrMmWWmgKNAiMQ6zZgQzkDHZ8zn4EFYQqkh3jrzFPn4ASEwu7VVzin6 7TKYzBPMpVGkEtq2vNL8NC+81GZFnwqT2rz/WiE81Lw0C5S3TYHoHAbd1 0nTohnYlKjpr7bYLtIioMGPLpG+sORE876fa1WQMZRP82aXKFoLa6zKNr E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAJH9+FOtJA2E/2dsb2JhbABZgmojU1MEBMp9gWeHSQGBBxZ3hAMBAQECAh1aAhACARkBAgECKAcyFAMEAggCBA4FCRKIJwEHBcNrF45qEQE/DQQGBwOEQwWRJoQphCmCUYEyJpM0g15sAYEOOYEHAQEB X-IronPort-AV: E=Sophos; i="5.04,387,1406592000"; d="scan'208,217"; a="71793150" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-6.cisco.com with ESMTP; 23 Aug 2014 20:47:13 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s7NKlDX9011933 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 23 Aug 2014 20:47:13 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Sat, 23 Aug 2014 15:47:12 -0500 From: "Carlos Pignataro (cpignata)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-merged-sfc-architecture-02.txt Thread-Index: AQHPvip0xbyexgrsaUWFFp9W7AAmpQ== Date: Sat, 23 Aug 2014 20:47:12 +0000 Message-ID: References: <20140822165913.29275.92328.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.227.20] Content-Type: multipart/alternative; boundary="_000_AB349F4EC2F04A87A77E262329945FEBciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/TDGtEPe88qXhq08zf58A3QOjOGo Cc: "sfc-chairs@tools.ietf.org" Subject: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-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: Sat, 23 Aug 2014 20:47:27 -0000 --_000_AB349F4EC2F04A87A77E262329945FEBciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable SFC, Please find below the email notice of a new revision of draft-merged-sfc-ar= chitecture. Full set of diffs from -00 (IETF90) to -02 (now) can be seen here: http://w= ww.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-02&url1=3Ddraft-me= rged-sfc-architecture-00 We still expect further changes to the document; but we also believe that t= his revision captures the key points and addresses the key open items, as p= lanned in Toronto. The key objective being to create a single document basis for the SFC archi= tecture. SFC Chairs, We believe that this revision fulfills the next steps agreed in Toronto (ht= tp://tools.ietf.org/agenda/90/slides/slides-90-sfc-3.pdf). This revision, while we expect changes, is now close enough that we think i= t makes sense for the WG to take it as the basis for the WG document to add= ress the deliverable. draft-merged-sfc-architecture-02 addressed the key points -- and we believe= is ready to start a poll for adoption. Can you please initiate that WG ado= ption call for draft-merged-sfc-architecture-02? Thanks, Carlos & Joel. Begin forwarded message: From: > Subject: New Version Notification for draft-merged-sfc-architecture-02.txt Date: August 22, 2014 at 12:59:13 PM EDT To: Joel Halpern >, Carlos = Pignataro >, "Joel M. Halpern= " >, Carlos Pignataro > A new version of I-D, draft-merged-sfc-architecture-02.txt has been successfully submitted by Carlos Pignataro and posted to the IETF repository. Name: draft-merged-sfc-architecture Revision: 02 Title: Service Function Chaining (SFC) Architecture Document date: 2014-08-22 Group: Individual Submission Pages: 26 URL: http://www.ietf.org/internet-drafts/draft-merged-sfc-archit= ecture-02.txt Status: https://datatracker.ietf.org/doc/draft-merged-sfc-architect= ure/ Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-archite= cture-02 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 submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_AB349F4EC2F04A87A77E262329945FEBciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable SFC,

Please find below the email notice of a new revision of draft-mer= ged-sfc-architecture.

Full set of diffs from -00 (IETF90) to -02 (now) can be seen here:&nbs= p;http://www.ietf.org/rfcd= iff?url2=3Ddraft-merged-sfc-architecture-02&url1=3Ddraft-merged-sfc-arc= hitecture-00

We still expect further changes to the document; but we also believe t= hat this revision captures the key points and addresses the key open items,= as planned in Toronto.

The key objective being to create a single document basis for the SFC = architecture.

SFC Chairs,

We believe that this revision fulfills the next steps agreed in Toront= o (h= ttp://tools.ietf.org/agenda/90/slides/slides-90-sfc-3.pdf). 

This revision, while we expect changes, is now close enough that = we think it makes sense for the WG to take it as the basis for the WG docum= ent to address the deliverable.

draft-merged-sfc-architecture-02 addressed the key points -- and we be= lieve is ready to start a poll for adoption. Can you please initiate that W= G adoption call for draft-merged-sfc-architecture-02?

Thanks,

Carlos & Joel.


Begin forwarded message:

Subje= ct: New Version Notification= for draft-merged-sfc-architecture-02.txt
Date:= August 22, 2014 at 12:= 59:13 PM EDT
To: <= /b>Joel Halpern <jmh@joelhalpern.com>, Carlos Pignata= ro <cpignata@cisco.com>, "Joel M. Halpern" <jmh= @joelhalpern.com>, Carlos Pignataro <cpignata@cisco.com>


A new version of I-D, draft-merged-sfc-architecture-02.txt
has been successfully submitted by Carlos Pignataro and posted to the
IETF repository.

Name: draft-merged-sfc= -architecture
Revision: 0= 2
Title: Service Functio= n Chaining (SFC) Architecture
Document date: 2014-08-22
Group: Individual Subm= ission
Pages: 26
URL:            http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-02.= txt
Status:         https://datatracke= r.ietf.org/doc/draft-merged-sfc-architecture/
Htmlized:       http://tools.ietf.org/html/draft= -merged-sfc-architecture-02
Diff:           ht= tp://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-02

Abstract:
  This document describes an architecture for the specification,<= br>   creation, and ongoing maintenance of Service Function Chains (S= FC) in
  a network.  It includes architectural concepts, principles= , and
  components used in the construction of composite services throu= gh
  deployment of SFCs.  This document does not propose soluti= ons,
  protocols, or extensions to existing protocols.




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

The IETF Secretariat


--_000_AB349F4EC2F04A87A77E262329945FEBciscocom_-- From nobody Mon Aug 25 10:07: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 0CAE81A0052 for ; Mon, 25 Aug 2014 10:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.568 X-Spam-Level: X-Spam-Status: No, score=-14.568 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, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 8d4da3U8eX3U for ; Mon, 25 Aug 2014 10:07:27 -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 68DDB1A00EC for ; Mon, 25 Aug 2014 10:07:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13088; q=dns/txt; s=iport; t=1408986427; x=1410196027; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=BcMR17EhSUOsJeDX68kaBrevwCnRpKUh/oTjXoGTl8I=; b=Jt5861cvGamohe1plSjtw3iHUPJzh/RiQi0CTcKTnmDn+W7Ipw2N8qxT 0KVPC5irhVxRj2Bttmje8tdxsf1p+qIzP7vUovAn7vALRfCl2x3Rnb1Jl js4OYEqdYEFDxgbxORFKwvI0LpCzL/kvEGUfAr6u8Z7aFabMaXy707pQY Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAIps+1OtJA2B/2dsb2JhbABagw1TUwQEzEsBDYdJAYEiFneEAwEBAQICAQEBGlEJARELEQECAQIBCRYIBwkDAgECARUfAwYIBg0GAgEBBRKIJwgFwAQXjmoRAT8XAQaERgWLIoothCmCUYEyJoVXjV2DfkwBgQ45gQcBAQE X-IronPort-AV: E=Sophos;i="5.04,398,1406592000"; d="scan'208,217";a="350117362" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP; 25 Aug 2014 17:07:06 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s7PH76Gr027032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 25 Aug 2014 17:07:06 GMT Received: from [10.21.64.225] (10.21.64.225) by xhc-rcd-x04.cisco.com (173.37.183.78) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 25 Aug 2014 12:07:05 -0500 Message-ID: <53FB6D2E.3010202@cisco.com> Date: Mon, 25 Aug 2014 10:06:54 -0700 From: Reinaldo Penno Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: References: <20140822165913.29275.92328.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000302060805020804070205" X-Originating-IP: [10.21.64.225] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/JQ8d5ERJSx4h7O-tOejVZnonUqw Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-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: Mon, 25 Aug 2014 17:07:30 -0000 --------------000302060805020804070205 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit A couple of points about SFF definition. You mention "one or more connected service functions" But in our implementation we have two types of SFFs that do not have SFs: - A SFF that maps from one overlay to another, say, VXLAN to GRE - A SFF that only has a classifier (no SFs in itself) Where would they fit or how to to make sure the architecture can predict their usage? thanks, On 8/23/14 1:47 PM, Carlos Pignataro (cpignata) wrote: > SFC, > > Please find below the email notice of a new revision > of draft-merged-sfc-architecture. > > Full set of diffs from -00 (IETF90) to -02 (now) can be seen here: > http://www.ietf.org/rfcdiff?url2=draft-merged-sfc-architecture-02&url1=draft-merged-sfc-architecture-00 > > We still expect further changes to the document; but we also believe > that this revision captures the key points and addresses the key open > items, as planned in Toronto. > > The key objective being to create a single document basis for the SFC > architecture. > > SFC Chairs, > > We believe that this revision fulfills the next steps agreed in > Toronto (http://tools.ietf.org/agenda/90/slides/slides-90-sfc-3.pdf). > > This revision, while we expect changes, is now close enough that we > think it makes sense for the WG to take it as the basis for the WG > document to address the deliverable. > > draft-merged-sfc-architecture-02 addressed the key points -- and we > believe is ready to start a poll for adoption. Can you please initiate > that WG adoption call for draft-merged-sfc-architecture-02? > > Thanks, > > Carlos & Joel. > > > Begin forwarded message: > >> *From: *> >> *Subject: * *New Version Notification for >> draft-merged-sfc-architecture-02.txt* >> *Date: *August 22, 2014 at 12:59:13 PM EDT >> *To: *Joel Halpern > >, Carlos Pignataro > >, "Joel M. Halpern" > >, Carlos Pignataro > > >> >> >> A new version of I-D, draft-merged-sfc-architecture-02.txt >> has been successfully submitted by Carlos Pignataro and posted to the >> IETF repository. >> >> Name:draft-merged-sfc-architecture >> Revision:02 >> Title:Service Function Chaining (SFC) Architecture >> Document date:2014-08-22 >> Group:Individual Submission >> Pages:26 >> URL: >> http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-02.txt >> Status: https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ >> Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-02 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-merged-sfc-architecture-02 >> >> 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.ietf.org >> . >> >> The IETF Secretariat >> > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --------------000302060805020804070205 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit A couple of points about SFF definition. You mention "one or more connected service functions"

But in our implementation we have two types of SFFs that do not have SFs:

- A SFF that maps from one overlay to another, say, VXLAN to GRE
- A SFF that only has a classifier (no SFs in itself)

Where would they fit or how to to make sure the architecture can predict their usage?

thanks,

On 8/23/14 1:47 PM, Carlos Pignataro (cpignata) wrote:
SFC,

Please find below the email notice of a new revision of draft-merged-sfc-architecture.


We still expect further changes to the document; but we also believe that this revision captures the key points and addresses the key open items, as planned in Toronto.

The key objective being to create a single document basis for the SFC architecture.

SFC Chairs,

We believe that this revision fulfills the next steps agreed in Toronto (http://tools.ietf.org/agenda/90/slides/slides-90-sfc-3.pdf). 

This revision, while we expect changes, is now close enough that we think it makes sense for the WG to take it as the basis for the WG document to address the deliverable.

draft-merged-sfc-architecture-02 addressed the key points -- and we believe is ready to start a poll for adoption. Can you please initiate that WG adoption call for draft-merged-sfc-architecture-02?

Thanks,

Carlos & Joel.


Begin forwarded message:

Subject: New Version Notification for draft-merged-sfc-architecture-02.txt
Date: August 22, 2014 at 12:59:13 PM EDT
To: Joel Halpern <jmh@joelhalpern.com>, Carlos Pignataro <cpignata@cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Carlos Pignataro <cpignata@cisco.com>


A new version of I-D, draft-merged-sfc-architecture-02.txt
has been successfully submitted by Carlos Pignataro and posted to the
IETF repository.

Name: draft-merged-sfc-architecture
Revision: 02
Title: Service Function Chaining (SFC) Architecture
Document date: 2014-08-22
Group: Individual Submission
Pages: 26
URL:            http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-02.txt
Status:         https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/
Htmlized:       http://tools.ietf.org/html/draft-merged-sfc-architecture-02
Diff:           http://www.ietf.org/rfcdiff?url2=draft-merged-sfc-architecture-02

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.ietf.org.

The IETF Secretariat




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

--------------000302060805020804070205-- From nobody Mon Aug 25 12:14: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 70A321A02C1 for ; Mon, 25 Aug 2014 12:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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.668, 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 WDBssHEXZnjm for ; Mon, 25 Aug 2014 12:14:51 -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 D82261A026F for ; Mon, 25 Aug 2014 12:14:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15023; q=dns/txt; s=iport; t=1408994091; x=1410203691; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vlG4naFEQ9okqiywWwwRtDizyjN0ciLcUXKyuPuKUrs=; b=dGlS4Q8C11KVtOWX2+QJYA7SNCfu3HNpT+8UaOtJbicxLjOT1sPI4IhV hdVSVnMrBYaQ89VkVww8EIwNSQVBX7/DZE7csO7YuekOax/5CjUVDrAnt 2UZH5roRmpYzZBcKIK0gwdwSfyYB15p9Qjr71BIrUVPq7VSG3b/TjFMnk o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAIqK+1OtJA2M/2dsb2JhbABagmojU00GBATMTAENh0kBgSMWd4QDAQEBAgIBAQEaSgcJAhACAQgRAQIBAigHJwsUAwYIAgQOBQkSiCcBBwW/fBeOahEBPxEGAQYDgyaBHQWPE4IThCmEKYJRgTImkzSCGIFGbAGBDjmBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,398,1406592000"; d="scan'208,217";a="350100698" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-2.cisco.com with ESMTP; 25 Aug 2014 19:14:50 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s7PJEnG0030131 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 25 Aug 2014 19:14:50 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Mon, 25 Aug 2014 14:14:49 -0500 From: "Carlos Pignataro (cpignata)" To: "Reinaldo Penno (repenno)" Thread-Topic: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-02.txt Thread-Index: AQHPvip0xbyexgrsaUWFFp9W7AAmpZvh5W0AgAAjvAA= Date: Mon, 25 Aug 2014 19:14:49 +0000 Message-ID: References: <20140822165913.29275.92328.idtracker@ietfa.amsl.com> <53FB6D2E.3010202@cisco.com> In-Reply-To: <53FB6D2E.3010202@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.229.69] Content-Type: multipart/alternative; boundary="_000_CFE7F8D76B8347289984DE47CFA9D8BAciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/H6QxrT_j1tC3T5TfzN_etI5MKE8 Cc: "sfc@ietf.org" Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-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: Mon, 25 Aug 2014 19:14:53 -0000 --_000_CFE7F8D76B8347289984DE47CFA9D8BAciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Reinaldo, Thanks for the comment, good set of points. It does seem that the definitio= n itself might be unnecessarily overly restrictive. We could say "zero or more" or we could say "typically one or more", but I = think it is better to spell out the function. Here's one more comprehensive= proposal: Old: Service Function Forwarder (SFF): A service function forwarder is responsible for delivering traffic received from the network to one or more connected service functions according to information carried in the SFC encapsulation. New: Service Function Forwarder (SFF): A service function forwarder is responsible for delivering traffic received from the network to one or more connected service functions according to information carried in the SFC encapsulation, as well as for delivering traffic= to a classifier or mapping out traffic to another SFF (in the same or different type of overlay). WG, Reinaldo, Thoughts? Thanks, Carlos. On Aug 25, 2014, at 1:06 PM, Reinaldo Penno > wrote: A couple of points about SFF definition. You mention "one or more connected= service functions" But in our implementation we have two types of SFFs that do not have SFs: - A SFF that maps from one overlay to another, say, VXLAN to GRE - A SFF that only has a classifier (no SFs in itself) Where would they fit or how to to make sure the architecture can predict th= eir usage? thanks, On 8/23/14 1:47 PM, Carlos Pignataro (cpignata) wrote: SFC, Please find below the email notice of a new revision of draft-merged-sfc-ar= chitecture. Full set of diffs from -00 (IETF90) to -02 (now) can be seen here: http://w= ww.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-02&url1=3Ddraft-me= rged-sfc-architecture-00 We still expect further changes to the document; but we also believe that t= his revision captures the key points and addresses the key open items, as p= lanned in Toronto. The key objective being to create a single document basis for the SFC archi= tecture. SFC Chairs, We believe that this revision fulfills the next steps agreed in Toronto (ht= tp://tools.ietf.org/agenda/90/slides/slides-90-sfc-3.pdf). This revision, while we expect changes, is now close enough that we think i= t makes sense for the WG to take it as the basis for the WG document to add= ress the deliverable. draft-merged-sfc-architecture-02 addressed the key points -- and we believe= is ready to start a poll for adoption. Can you please initiate that WG ado= ption call for draft-merged-sfc-architecture-02? Thanks, Carlos & Joel. Begin forwarded message: From: > Subject: New Version Notification for draft-merged-sfc-architecture-02.txt Date: August 22, 2014 at 12:59:13 PM EDT To: Joel Halpern >, Carlos = Pignataro >, "Joel M. Halpern= " >, Carlos Pignataro > A new version of I-D, draft-merged-sfc-architecture-02.txt has been successfully submitted by Carlos Pignataro and posted to the IETF repository. Name: draft-merged-sfc-architecture Revision: 02 Title: Service Function Chaining (SFC) Architecture Document date: 2014-08-22 Group: Individual Submission Pages: 26 URL: http://www.ietf.org/internet-drafts/draft-merged-sfc-archit= ecture-02.txt Status: https://datatracker.ietf.org/doc/draft-merged-sfc-architect= ure/ Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-archite= cture-02 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 submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ 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 --_000_CFE7F8D76B8347289984DE47CFA9D8BAciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <67ADE5BBC2ED5341B9B39B25C77445F7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Reinaldo,

Thanks for the comment, good set of points. It does seem that the defi= nition itself might be unnecessarily overly restrictive.

We could say "zero or more" or we could say "typically = one or more", but I think it is better to spell out the function. Here= 's one more comprehensive proposal:

Old:
   Service Function Forwarder (SFF):  A service functio= n forwarder is
        responsible for delivering traffic receive= d from the network to
        one or more connected service functions ac= cording to information
        carried in the SFC encapsulation.

New:
   Service Function Forwarder (SFF):  A service functio= n forwarder is
        responsible for delivering traffic receive= d from the network to
        one or more connected service functions ac= cording to information
        carried in the SFC encapsulation, as well = as for delivering traffic to
        a classifier or mapping out traffic to ano= ther SFF (in the same or
        different type of overlay).

WG, Reinaldo,

Thoughts?

Thanks,

Carlos.

On Aug 25, 2014, at 1:06 PM, Reinaldo Penno <repenno@cisco.com> wrote:

A couple of points about SFF defi= nition. You mention "one or more connected service functions"

But in our implementation we have two types of SFFs that do not have SFs:
- A SFF that maps from one overlay to another, say, VXLAN to GRE
- A SFF that only has a classifier (no SFs in itself)

Where would they fit or how to to make sure the architecture can predict th= eir usage?

thanks,

On 8/23/14 1:47 PM, Carlos Pignataro (cpigna= ta) wrote:
SFC,

Please find below the email notice of a new revision of draft-mer= ged-sfc-architecture.

Full set of diffs from -00 (IETF90) to -02 (now) can be seen here:&nbs= p;http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-02&ur= l1=3Ddraft-merged-sfc-architecture-00

We still expect further changes to the document; but we also believe t= hat this revision captures the key points and addresses the key open items,= as planned in Toronto.

The key objective being to create a single document basis for the SFC = architecture.

SFC Chairs,

We believe that this revision fulfills the next steps agreed in Toront= o (http://tools.ietf.org/agenda/90/slides/slides-90-sf= c-3.pdf). 

This revision, while we expect changes, is now close enough that = we think it makes sense for the WG to take it as the basis for the WG docum= ent to address the deliverable.

draft-merged-sfc-architecture-02 addressed the key points -- and we be= lieve is ready to start a poll for adoption. Can you please initiate that W= G adoption call for draft-merged-sfc-architecture-02?

Thanks,

Carlos & Joel.


Begin forwarded message:

Subject: New Version Notification for draft-merged-= sfc-architecture-02.txt
Date: August 22, 2014 at 12:59:13 PM EDT
To: Joel Halpern <jmh@joelhalpern.com>, Carlos Pignata= ro <cpign= ata@cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Carlos Pignataro <cpignata@cisco.= com>


A new version of I-D, draft-merged-sfc-architecture-02.txt
has been successfully submitted by Carlos Pignataro and posted to the
IETF repository.

Name: draft-merged-sfc= -architecture
Revision: 0= 2
Title: Service Functio= n Chaining (SFC) Architecture
Document date: 2014-08-22
Group: Individual Subm= ission
Pages: 26
URL:            http://www.ietf.org/internet-drafts/draft-me= rged-sfc-architecture-02.txt
Status:         https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/=
Htmlized:       http://= tools.ietf.org/html/draft-merged-sfc-architecture-02
Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-ar= chitecture-02

Abstract:
  This document describes an architecture for the specification,<= br>   creation, and ongoing maintenance of Service Function Chains (S= FC) in
  a network.  It includes architectural concepts, principles= , and
  components used in the construction of composite services throu= gh
  deployment of SFCs.  This document does not propose soluti= ons,
  protocols, or extensions to existing protocols.




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

The IETF Secretariat




_______________________________________________
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

--_000_CFE7F8D76B8347289984DE47CFA9D8BAciscocom_-- From nobody Mon Aug 25 13:13: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 43CA61A0314 for ; Mon, 25 Aug 2014 13:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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.668, 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 uVtW_3VO9OSu for ; Mon, 25 Aug 2014 13:13:49 -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 298B41A0303 for ; Mon, 25 Aug 2014 13:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1452; q=dns/txt; s=iport; t=1408997629; x=1410207229; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=57weohBislAKyF7ombgBap08gq+1GZhb74D+HuWzNT8=; b=gau8L3hyUchyCiuCZ8S2thl78uTtrK6VBJpboFlGrIKAxm7frcxa1IK5 L7iEK3h/gh+b5ZghZwfSS3lJdHC33jcLBP/IlLoSVOc9o49Ia9MiF15hA ev91srRlQNbbFPnPWDn7oXaQFIShqCipJydFQuY2pYJs+NWA+visU/4gI M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAPmX+1OtJV2d/2dsb2JhbABagw2BIAoE1CMBgSMWd4QEAQEDAWcQAgULAgEIEjQyFw4CBA4FiDoIv3gXjxkzB4MvgR0BBJEmiyOVDIIYgUZsgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,398,1406592000"; d="scan'208";a="350159499" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 25 Aug 2014 20:13:47 +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 s7PKDlu8009279 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 25 Aug 2014 20:13:47 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.10]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Mon, 25 Aug 2014 15:13:47 -0500 From: "Guy Meador III (meadorg)" To: "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-02.txt Thread-Index: AQHPwIcVFj8SsfUs8kef1Yn00+mR6ZviBHGAgAAQeAA= Date: Mon, 25 Aug 2014 20:13:46 +0000 Message-ID: <71B70920-7353-4FD0-952C-EA32A5C20BF3@cisco.com> References: <20140822165913.29275.92328.idtracker@ietfa.amsl.com> <53FB6D2E.3010202@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.94.199] Content-Type: text/plain; charset="Windows-1252" Content-ID: <77CC56BECE5A9D46B1A7F3C93014A30C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/hk9EslEv2RFvWkfQnFEqqU8Knc4 Cc: "Reinaldo Penno \(repenno\)" , "sfc@ietf.org" Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-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: Mon, 25 Aug 2014 20:13:51 -0000 Carlos, While you are contemplating refinements to the definition of SFF, it would = seem that SFF handling of traffic received from associated SF instances sho= uld also be mentioned here, too. Thoughts? -Guy On Aug 25, 2014, at 3:14 PM, "Carlos Pignataro (cpignata)" wrote: > Reinaldo, >=20 > Thanks for the comment, good set of points. It does seem that the definit= ion itself might be unnecessarily overly restrictive. >=20 > We could say "zero or more" or we could say "typically one or more", but = I think it is better to spell out the function. Here's one more comprehensi= ve proposal: >=20 > Old: > Service Function Forwarder (SFF): A service function forwarder is > responsible for delivering traffic received from the network to > one or more connected service functions according to information > carried in the SFC encapsulation. >=20 > New: > Service Function Forwarder (SFF): A service function forwarder is > responsible for delivering traffic received from the network to > one or more connected service functions according to information > carried in the SFC encapsulation, as well as for delivering traff= ic to > a classifier or mapping out traffic to another SFF (in the same o= r > different type of overlay). >=20 > WG, Reinaldo, >=20 > Thoughts? >=20 > Thanks, >=20 > Carlos. >=20 From nobody Mon Aug 25 13:18: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 CBAC81A01D5 for ; Mon, 25 Aug 2014 13:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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.668, 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 Uygucoul43Ae for ; Mon, 25 Aug 2014 13:18:35 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBCA51A0316 for ; Mon, 25 Aug 2014 13:18:34 -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=1408997915; x=1410207515; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MNfymiWt8l1rdd0YOj2E3wFHGVRaHb/T/T/NEfp+d+s=; b=OBDDBYQDagfTQ2tViKyGY8UWPfyygRgixzNxWXrNz1uyfGjQxKiALVV6 OaSnO69q0pGsQzuEh7G4WF22+U3XE6sWn1z/BD0IUL4dgM2tdA+bZmiL2 MokCIl9xSOpdpNlwmdLtZTo6FRSovKt4LdYqLQmoGAi7GxxygLPYGYGCy U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAFCZ+1OtJA2G/2dsb2JhbABagmojgSAKBNQjAYEjFneEAwEBAQMBZxACBQsCAQgSBi4yFw4CBA4FiDoIAb94F48ZMweDL4EdAQSPE4ITiyOVDINebIFIgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,398,1406592000"; d="scan'208";a="72211801" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP; 25 Aug 2014 20:18:34 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s7PKIXoq015239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 25 Aug 2014 20:18:33 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Mon, 25 Aug 2014 15:18:33 -0500 From: "Carlos Pignataro (cpignata)" To: "Guy Meador III (meadorg)" Thread-Topic: [sfc] New Version Notification for draft-merged-sfc-architecture-02.txt Thread-Index: AQHPwKG+sZam2ET1wkSROKSQeJQt+A== Date: Mon, 25 Aug 2014 20:18:33 +0000 Message-ID: References: <20140822165913.29275.92328.idtracker@ietfa.amsl.com> <53FB6D2E.3010202@cisco.com> <71B70920-7353-4FD0-952C-EA32A5C20BF3@cisco.com> In-Reply-To: <71B70920-7353-4FD0-952C-EA32A5C20BF3@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.229.69] Content-Type: text/plain; charset="Windows-1252" Content-ID: <23B8A81B6D34684AADFC497BBEEB373B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/qyQ1bDjbBoXi7emN7qAjKOUt_s0 Cc: "Reinaldo Penno \(repenno\)" , "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-merged-sfc-architecture-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: Mon, 25 Aug 2014 20:18:37 -0000 Guy, Sure -- perhaps add ", handling traffic coming back from the SF"? Thanks, Carlos. On Aug 25, 2014, at 4:13 PM, Guy Meador III (meadorg) w= rote: > Carlos, >=20 > While you are contemplating refinements to the definition of SFF, it woul= d seem that SFF handling of traffic received from associated SF instances s= hould also be mentioned here, too. Thoughts? >=20 > -Guy >=20 > On Aug 25, 2014, at 3:14 PM, "Carlos Pignataro (cpignata)" > wrote: >=20 >> Reinaldo, >>=20 >> Thanks for the comment, good set of points. It does seem that the defini= tion itself might be unnecessarily overly restrictive. >>=20 >> We could say "zero or more" or we could say "typically one or more", but= I think it is better to spell out the function. Here's one more comprehens= ive proposal: >>=20 >> Old: >> Service Function Forwarder (SFF): A service function forwarder is >> responsible for delivering traffic received from the network to >> one or more connected service functions according to information >> carried in the SFC encapsulation. >>=20 >> New: >> Service Function Forwarder (SFF): A service function forwarder is >> responsible for delivering traffic received from the network to >> one or more connected service functions according to information >> carried in the SFC encapsulation, as well as for delivering traff= ic to >> a classifier or mapping out traffic to another SFF (in the same o= r >> different type of overlay). >>=20 >> WG, Reinaldo, >>=20 >> Thoughts? >>=20 >> Thanks, >>=20 >> Carlos. >>=20 >=20 From nobody Mon Aug 25 13:21: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 456781A032E for ; Mon, 25 Aug 2014 13:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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.668, 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 paog3A9vW3jx for ; Mon, 25 Aug 2014 13:20:55 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D051A0324 for ; Mon, 25 Aug 2014 13:20:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2084; q=dns/txt; s=iport; t=1408998053; x=1410207653; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Od/G/3UVyqoYUliIOrRcamJwS2PdDLY6dVvvwO1T0do=; b=RjagNwJXNqwY1To50ZUxeW4dukxbVkn6gVLI33b3BBfUoLfeRbzuSuKT BAgJjIc0hY/mRXlcw5PKWR1YD5cRmG9Za9H3FZ91546BDM+h7vY+e9LmA pKcpX48/DPkuSZS8rmVnn2cWorxHr/6Fw0fWk6N3cSV3dzccyfDAag9rx 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAAia+1OtJV2R/2dsb2JhbABagw2BIAoE1CMBgSMWd4QEAQEEdwIQAgEIBAENLQcyFAMOAgQOBYhCwAAXj0wHgy+BHQEEkSaLI5UMg15sgUiBBwEBAQ X-IronPort-AV: E=Sophos; i="5.04,398,1406592000"; d="scan'208,217"; a="72221339" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-7.cisco.com with ESMTP; 25 Aug 2014 20:20:53 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s7PKKq4n027546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 25 Aug 2014 20:20:52 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.10]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Mon, 25 Aug 2014 15:20:52 -0500 From: "Guy Meador III (meadorg)" To: "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] New Version Notification for draft-merged-sfc-architecture-02.txt Thread-Index: AQHPwKG+sZam2ET1wkSROKSQeJQt+JviFq+A Date: Mon, 25 Aug 2014 20:20:51 +0000 Message-ID: <8B40D0B8-872B-4C50-A786-4962C3656D57@cisco.com> References: <20140822165913.29275.92328.idtracker@ietfa.amsl.com> <53FB6D2E.3010202@cisco.com> <71B70920-7353-4FD0-952C-EA32A5C20BF3@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.94.199] Content-Type: multipart/alternative; boundary="_000_8B40D0B8872B4C50A7864962C3656D57ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/dcueL1fvDYHYFeIgkNwJVP7EgP0 Cc: "Reinaldo Penno \(repenno\)" , "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-merged-sfc-architecture-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: Mon, 25 Aug 2014 20:20:58 -0000 --_000_8B40D0B8872B4C50A7864962C3656D57ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable That works, thanks. On Aug 25, 2014, at 4:18 PM, "Carlos Pignataro (cpignata)" > wrote: Sure -- perhaps add ", handling traffic coming back from the SF"? --_000_8B40D0B8872B4C50A7864962C3656D57ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7877DC11E536934A950A530735753CB1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable That works, thanks.

On Aug 25, 2014, at 4:18 PM, "Carlos Pignataro (cpignata)" &= lt;cpignata@cisco.com>
 wrote:

Sure -- perhaps add ", handling traffic coming back from the SF"?


--_000_8B40D0B8872B4C50A7864962C3656D57ciscocom_-- From nobody Mon Aug 25 13:36: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 654F91A033D for ; Mon, 25 Aug 2014 13:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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.668, 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 wJ4xgmA-sBf4 for ; Mon, 25 Aug 2014 13:36:12 -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 869AB1A033C for ; Mon, 25 Aug 2014 13:36:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18247; q=dns/txt; s=iport; t=1408998972; x=1410208572; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=tAuFew1n/L/7EqMaeHldAve46f/xrPY5i6Td3FYXi/U=; b=bXNrlNanC80gwS8w82AdW7m73J8Ah0jar+FGvmXA6fHZ5jhzm09Sr/TC t5H01xPGv3EiP9nfXIDqZBk4k8H8RwB0u067E/iO1X3LhCqCZGl1D0wnF 62zxpOUV/1un8m+mXhl6FuzYDPKq8R0OKnqxb6bgnTZocu4ObEY6rioqz w=; X-IronPort-AV: E=Sophos; i="5.04,398,1406592000"; d="scan'208,217"; a="72216765" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP; 25 Aug 2014 20:36:12 +0000 Received: from [10.154.165.6] ([10.154.165.6]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s7PKaAv5026232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Aug 2014 20:36:11 GMT Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_CCF21A1D-5A54-497B-BD4F-796317767715" From: Naiming Shen In-Reply-To: Date: Mon, 25 Aug 2014 13:36:11 -0700 Message-Id: References: <20140822165913.29275.92328.idtracker@ietfa.amsl.com> <53FB6D2E.3010202@cisco.com> To: "Carlos Pignataro (cpignata)" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/AM-7KiCoRxQ-HTYPp7FZV_0V96Y Cc: sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-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: Mon, 25 Aug 2014 20:36:15 -0000 --Apple-Mail=_CCF21A1D-5A54-497B-BD4F-796317767715 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Carlos, One of the function of SFF could be to "de-encapsulate" the SFC, it can = be the case of the last hop on the SFC list, there may not be any SF associated with the SFF, = but only to remove the service transport and NSH header and to forward the packet normally. Otherwise, after the last SF/SFF service function, service header and = transport is removed, the packet could route through the original "classifier" device again = and it has no information that packet has already gone through the SFC defined. This can cause = looping. This of course depends on where the location of the last SFF in the topology. One way = to solve this can be to define the SFC last item being the SFF which is the next-hop of = the classifier device in normal routing/forwarding to make sure the classifier device will to see = this packet in original format(without NSH and transport) twice. thanks. - Naiming On Aug 25, 2014, at 12:14 PM, "Carlos Pignataro (cpignata)" = wrote: > Reinaldo, >=20 > Thanks for the comment, good set of points. It does seem that the = definition itself might be unnecessarily overly restrictive. >=20 > We could say "zero or more" or we could say "typically one or more", = but I think it is better to spell out the function. Here's one more = comprehensive proposal: >=20 > Old: > Service Function Forwarder (SFF): A service function forwarder is > responsible for delivering traffic received from the network = to > one or more connected service functions according to = information > carried in the SFC encapsulation. >=20 > New: > Service Function Forwarder (SFF): A service function forwarder is > responsible for delivering traffic received from the network = to > one or more connected service functions according to = information > carried in the SFC encapsulation, as well as for delivering = traffic to > a classifier or mapping out traffic to another SFF (in the = same or > different type of overlay). >=20 > WG, Reinaldo, >=20 > Thoughts? >=20 > Thanks, >=20 > Carlos. >=20 > On Aug 25, 2014, at 1:06 PM, Reinaldo Penno wrote: >=20 >> A couple of points about SFF definition. You mention "one or more = connected service functions"=20 >>=20 >> But in our implementation we have two types of SFFs that do not have = SFs: >>=20 >> - A SFF that maps from one overlay to another, say, VXLAN to GRE >> - A SFF that only has a classifier (no SFs in itself) >>=20 >> Where would they fit or how to to make sure the architecture can = predict their usage? >>=20 >> thanks, >>=20 >> On 8/23/14 1:47 PM, Carlos Pignataro (cpignata) wrote: >>> SFC, >>>=20 >>> Please find below the email notice of a new revision of = draft-merged-sfc-architecture. >>>=20 >>> Full set of diffs from -00 (IETF90) to -02 (now) can be seen here: = http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-02&url1=3D= draft-merged-sfc-architecture-00 >>>=20 >>> We still expect further changes to the document; but we also believe = that this revision captures the key points and addresses the key open = items, as planned in Toronto. >>>=20 >>> The key objective being to create a single document basis for the = SFC architecture. >>>=20 >>> SFC Chairs, >>>=20 >>> We believe that this revision fulfills the next steps agreed in = Toronto (http://tools.ietf.org/agenda/90/slides/slides-90-sfc-3.pdf).=20 >>>=20 >>> This revision, while we expect changes, is now close enough that we = think it makes sense for the WG to take it as the basis for the WG = document to address the deliverable. >>>=20 >>> draft-merged-sfc-architecture-02 addressed the key points -- and we = believe is ready to start a poll for adoption. Can you please initiate = that WG adoption call for draft-merged-sfc-architecture-02? >>>=20 >>> Thanks, >>>=20 >>> Carlos & Joel. >>>=20 >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: >>>> Subject: New Version Notification for = draft-merged-sfc-architecture-02.txt >>>> Date: August 22, 2014 at 12:59:13 PM EDT >>>> To: Joel Halpern , Carlos Pignataro = , "Joel M. Halpern" , Carlos = Pignataro >>>>=20 >>>>=20 >>>> A new version of I-D, draft-merged-sfc-architecture-02.txt >>>> has been successfully submitted by Carlos Pignataro and posted to = the >>>> IETF repository. >>>>=20 >>>> Name: draft-merged-sfc-architecture >>>> Revision: 02 >>>> Title: Service Function Chaining (SFC) Architecture >>>> Document date: 2014-08-22 >>>> Group: Individual Submission >>>> Pages: 26 >>>> URL: = http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-02.txt >>>> Status: = https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ >>>> Htmlized: = http://tools.ietf.org/html/draft-merged-sfc-architecture-02 >>>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-02 >>>>=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 = submission >>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>=20 >>>> The IETF Secretariat >>>>=20 >>>=20 >>>=20 >>>=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 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail=_CCF21A1D-5A54-497B-BD4F-796317767715 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
hop on the SFC list, there may not be any SF associated = with the SFF, but only to remove the service
transport and NSH = header and to forward the packet = normally.

Otherwise, after the last SF/SFF = service function, service header and transport is removed,
the = packet could route through the original "classifier" device again and it = has no information
that packet has already gone through the = SFC defined. This can cause looping. This of course
depends on = where the location of the last SFF in the topology. One way to solve = this can
be to define the SFC last item being the SFF which is = the next-hop of the classifier device in
normal = routing/forwarding to make sure the classifier device will to see this = packet in original
format(without NSH and transport) = twice.

thanks.
- = Naiming

On Aug 25, 2014, at 12:14 PM, "Carlos = Pignataro (cpignata)" <cpignata@cisco.com> = wrote:

Reinaldo,

Thanks for the comment, good set of points. It does seem that the = definition itself might be unnecessarily overly restrictive.

We could say "zero or more" or we could say "typically one or = more", but I think it is better to spell out the function. Here's one = more comprehensive proposal:

Old:
   Service Function Forwarder (SFF):  A service = function forwarder is
        responsible for delivering traffic = received from the network to
        one or more connected service functions = according to information
        carried in the SFC encapsulation.

New:
   Service Function Forwarder (SFF):  A service = function forwarder is
        responsible for delivering traffic = received from the network to
        one or more connected service functions = according to information
        carried in the SFC encapsulation, as = well as for delivering traffic to
        a classifier or mapping out traffic to = another SFF (in the same or
        different type of overlay).

WG, Reinaldo,

Thoughts?

Thanks,

Carlos.

On Aug 25, 2014, at 1:06 PM, Reinaldo Penno <repenno@cisco.com> wrote:

A couple of points about SFF = definition. You mention "one or more connected service functions"

But in our implementation we have two types of SFFs that do not have = SFs:

- A SFF that maps from one overlay to another, say, VXLAN to GRE
- A SFF that only has a classifier (no SFs in itself)

Where would they fit or how to to make sure the architecture can predict = their usage?

thanks,

On 8/23/14 1:47 PM, Carlos Pignataro = (cpignata) wrote:
SFC,

Please find below the email notice of a new revision = of draft-merged-sfc-architecture.


We still expect further changes to the document; but we also = believe that this revision captures the key points and addresses the key = open items, as planned in Toronto.

The key objective being to create a single document basis for the = SFC architecture.

SFC Chairs,

We believe that this revision fulfills the next steps agreed in = Toronto (http:/= /tools.ietf.org/agenda/90/slides/slides-90-sfc-3.pdf). 

This revision, while we expect changes, is now close enough = that we think it makes sense for the WG to take it as the basis for the = WG document to address the deliverable.

draft-merged-sfc-architecture-02 addressed the key points -- and we = believe is ready to start a poll for adoption. Can you please initiate = that WG adoption call for draft-merged-sfc-architecture-02?

Thanks,

Carlos & Joel.


Begin forwarded message:

From: <internet-drafts@ietf.org><= br>
Subject: New Version Notification for = draft-merged-sfc-architecture-02.txt
Date: August 22, 2014 at 12:59:13 PM = EDT
To: Joel Halpern <jmh@joelhalpern.com>, Carlos = Pignataro <cpignata@cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Carlos = Pignataro <cpignata@cisco.com>


A new version of I-D, draft-merged-sfc-architecture-02.txt
has been successfully submitted by Carlos Pignataro and posted to = the
IETF repository.

Name: = draft-merged-sfc-architecture
Revision: = 02
Title: = Service Function Chaining (SFC) = Architecture
Document date: = 2014-08-22
Group: = Individual Submission
Pages: = 26
URL: =            http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-= 02.txt
Status:         h= ttps://datatracker.ietf.org/doc/draft-merged-sfc-architecture/
Htmlized:       http:= //tools.ietf.org/html/draft-merged-sfc-architecture-02
Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-02=

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.ietf.org.

The IETF Secretariat




_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/sfc

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/ma= ilman/listinfo/sfc

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

= --Apple-Mail=_CCF21A1D-5A54-497B-BD4F-796317767715-- From nobody Mon Aug 25 13:47: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 4D0A61A0344 for ; Mon, 25 Aug 2014 13:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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.668, 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 8y_LRrQ_JaqU for ; Mon, 25 Aug 2014 13:47:31 -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 ABFA51A0347 for ; Mon, 25 Aug 2014 13:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19178; q=dns/txt; s=iport; t=1408999650; x=1410209250; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=LoCbpIiiik1c4Cuw07r9tmmbb9+hS6v8AiOrhH1jya0=; b=Zokait8uuuG4e5lBXIXwbcxqK3Dgp6QY59Dou2gPTaJD9gHhMRbpP+jj UDD+n9kuIyIaH96x0rxNEgM0GEdV4TttpbKKUijAAxC4cJYqdPL+sfx+X 9W4fU5VR0s8Zp1Gz2yEoqzCdjk2k8SPoxS8EUeVkay1zfUlA4Gg412T5z c=; X-IronPort-AV: E=Sophos; i="5.04,398,1406592000"; d="scan'208,217"; a="72218959" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-3.cisco.com with ESMTP; 25 Aug 2014 20:47:30 +0000 Received: from [10.154.165.6] ([10.154.165.6]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s7PKlSpf032037 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Aug 2014 20:47:29 GMT Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_B44B2E41-2591-45BC-AD60-B7E72922911E" From: Naiming Shen In-Reply-To: Date: Mon, 25 Aug 2014 13:47:29 -0700 Message-Id: <5DE5431F-8519-4E8C-8A0B-49465A4A7857@cisco.com> References: <20140822165913.29275.92328.idtracker@ietfa.amsl.com> <53FB6D2E.3010202@cisco.com> To: "Carlos Pignataro (cpignata)" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Hqh5Es8i0VmZI15D5LuAYvTafVQ Cc: sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-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: Mon, 25 Aug 2014 20:47:36 -0000 --Apple-Mail=_B44B2E41-2591-45BC-AD60-B7E72922911E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 25, 2014, at 1:36 PM, Naiming Shen wrote: >=20 > Carlos, >=20 > One of the function of SFF could be to "de-encapsulate" the SFC, it = can be the case of the last > hop on the SFC list, there may not be any SF associated with the SFF, = but only to remove the service > transport and NSH header and to forward the packet normally. >=20 > Otherwise, after the last SF/SFF service function, service header and = transport is removed, > the packet could route through the original "classifier" device again = and it has no information > that packet has already gone through the SFC defined. This can cause = looping. This of course > depends on where the location of the last SFF in the topology. One way = to solve this can > be to define the SFC last item being the SFF which is the next-hop of = the classifier device in > normal routing/forwarding to make sure the classifier device will to = see this packet in original typo, "=85 will not see this =85" > format(without NSH and transport) twice. >=20 > thanks. > - Naiming >=20 > On Aug 25, 2014, at 12:14 PM, "Carlos Pignataro (cpignata)" = wrote: >=20 >> Reinaldo, >>=20 >> Thanks for the comment, good set of points. It does seem that the = definition itself might be unnecessarily overly restrictive. >>=20 >> We could say "zero or more" or we could say "typically one or more", = but I think it is better to spell out the function. Here's one more = comprehensive proposal: >>=20 >> Old: >> Service Function Forwarder (SFF): A service function forwarder is >> responsible for delivering traffic received from the network = to >> one or more connected service functions according to = information >> carried in the SFC encapsulation. >>=20 >> New: >> Service Function Forwarder (SFF): A service function forwarder is >> responsible for delivering traffic received from the network = to >> one or more connected service functions according to = information >> carried in the SFC encapsulation, as well as for delivering = traffic to >> a classifier or mapping out traffic to another SFF (in the = same or >> different type of overlay). >>=20 >> WG, Reinaldo, >>=20 >> Thoughts? >>=20 >> Thanks, >>=20 >> Carlos. >>=20 >> On Aug 25, 2014, at 1:06 PM, Reinaldo Penno = wrote: >>=20 >>> A couple of points about SFF definition. You mention "one or more = connected service functions"=20 >>>=20 >>> But in our implementation we have two types of SFFs that do not have = SFs: >>>=20 >>> - A SFF that maps from one overlay to another, say, VXLAN to GRE >>> - A SFF that only has a classifier (no SFs in itself) >>>=20 >>> Where would they fit or how to to make sure the architecture can = predict their usage? >>>=20 >>> thanks, >>>=20 >>> On 8/23/14 1:47 PM, Carlos Pignataro (cpignata) wrote: >>>> SFC, >>>>=20 >>>> Please find below the email notice of a new revision of = draft-merged-sfc-architecture. >>>>=20 >>>> Full set of diffs from -00 (IETF90) to -02 (now) can be seen here: = http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-02&url1=3D= draft-merged-sfc-architecture-00 >>>>=20 >>>> We still expect further changes to the document; but we also = believe that this revision captures the key points and addresses the key = open items, as planned in Toronto. >>>>=20 >>>> The key objective being to create a single document basis for the = SFC architecture. >>>>=20 >>>> SFC Chairs, >>>>=20 >>>> We believe that this revision fulfills the next steps agreed in = Toronto (http://tools.ietf.org/agenda/90/slides/slides-90-sfc-3.pdf).=20 >>>>=20 >>>> This revision, while we expect changes, is now close enough that we = think it makes sense for the WG to take it as the basis for the WG = document to address the deliverable. >>>>=20 >>>> draft-merged-sfc-architecture-02 addressed the key points -- and we = believe is ready to start a poll for adoption. Can you please initiate = that WG adoption call for draft-merged-sfc-architecture-02? >>>>=20 >>>> Thanks, >>>>=20 >>>> Carlos & Joel. >>>>=20 >>>>=20 >>>> Begin forwarded message: >>>>=20 >>>>> From: >>>>> Subject: New Version Notification for = draft-merged-sfc-architecture-02.txt >>>>> Date: August 22, 2014 at 12:59:13 PM EDT >>>>> To: Joel Halpern , Carlos Pignataro = , "Joel M. Halpern" , Carlos = Pignataro >>>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-merged-sfc-architecture-02.txt >>>>> has been successfully submitted by Carlos Pignataro and posted to = the >>>>> IETF repository. >>>>>=20 >>>>> Name: draft-merged-sfc-architecture >>>>> Revision: 02 >>>>> Title: Service Function Chaining (SFC) Architecture >>>>> Document date: 2014-08-22 >>>>> Group: Individual Submission >>>>> Pages: 26 >>>>> URL: = http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-02.txt >>>>> Status: = https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ >>>>> Htmlized: = http://tools.ietf.org/html/draft-merged-sfc-architecture-02 >>>>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-02 >>>>>=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 = submission >>>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>>=20 >>>>> The IETF Secretariat >>>>>=20 >>>>=20 >>>>=20 >>>>=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 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >=20 --Apple-Mail=_B44B2E41-2591-45BC-AD60-B7E72922911E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 naiming@cisco.com> = wrote:

hop on the SFC list, there may not be any SF associated = with the SFF, but only to remove the service
transport and NSH = header and to forward the packet = normally.

Otherwise, after the last SF/SFF = service function, service header and transport is removed,
the = packet could route through the original "classifier" device again and it = has no information
that packet has already gone through the = SFC defined. This can cause looping. This of course
depends on = where the location of the last SFF in the topology. One way to solve = this can
be to define the SFC last item being the SFF which is = the next-hop of the classifier device in
normal = routing/forwarding to make sure the classifier device will to see this = packet in original

typo, "=85 = will not see this =85"

format(without NSH and = transport) twice.

thanks.
- = Naiming

On Aug 25, 2014, at 12:14 PM, "Carlos = Pignataro (cpignata)" <cpignata@cisco.com> = wrote:

Reinaldo,

Thanks for the comment, good set of points. It does seem that the = definition itself might be unnecessarily overly restrictive.

We could say "zero or more" or we could say "typically one or = more", but I think it is better to spell out the function. Here's one = more comprehensive proposal:

Old:
   Service Function Forwarder (SFF):  A service = function forwarder is
        responsible for delivering traffic = received from the network to
        one or more connected service functions = according to information
        carried in the SFC encapsulation.

New:
   Service Function Forwarder (SFF):  A service = function forwarder is
        responsible for delivering traffic = received from the network to
        one or more connected service functions = according to information
        carried in the SFC encapsulation, as = well as for delivering traffic to
        a classifier or mapping out traffic to = another SFF (in the same or
        different type of overlay).

WG, Reinaldo,

Thoughts?

Thanks,

Carlos.

On Aug 25, 2014, at 1:06 PM, Reinaldo Penno <repenno@cisco.com> wrote:

A couple of points about SFF = definition. You mention "one or more connected service functions"

But in our implementation we have two types of SFFs that do not have = SFs:

- A SFF that maps from one overlay to another, say, VXLAN to GRE
- A SFF that only has a classifier (no SFs in itself)

Where would they fit or how to to make sure the architecture can predict = their usage?

thanks,

On 8/23/14 1:47 PM, Carlos Pignataro = (cpignata) wrote:
SFC,

Please find below the email notice of a new revision = of draft-merged-sfc-architecture.


We still expect further changes to the document; but we also = believe that this revision captures the key points and addresses the key = open items, as planned in Toronto.

The key objective being to create a single document basis for the = SFC architecture.

SFC Chairs,

We believe that this revision fulfills the next steps agreed in = Toronto (http:/= /tools.ietf.org/agenda/90/slides/slides-90-sfc-3.pdf). 

This revision, while we expect changes, is now close enough = that we think it makes sense for the WG to take it as the basis for the = WG document to address the deliverable.

draft-merged-sfc-architecture-02 addressed the key points -- and we = believe is ready to start a poll for adoption. Can you please initiate = that WG adoption call for draft-merged-sfc-architecture-02?

Thanks,

Carlos & Joel.


Begin forwarded message:

From: <internet-drafts@ietf.org><= br>
Subject: New Version Notification for = draft-merged-sfc-architecture-02.txt
Date: August 22, 2014 at 12:59:13 PM = EDT
To: Joel Halpern <jmh@joelhalpern.com>, Carlos = Pignataro <cpignata@cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Carlos = Pignataro <cpignata@cisco.com>


A new version of I-D, draft-merged-sfc-architecture-02.txt
has been successfully submitted by Carlos Pignataro and posted to = the
IETF repository.

Name: = draft-merged-sfc-architecture
Revision: = 02
Title: = Service Function Chaining (SFC) = Architecture
Document date: = 2014-08-22
Group: = Individual Submission
Pages: = 26
URL: =            http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-= 02.txt
Status:         h= ttps://datatracker.ietf.org/doc/draft-merged-sfc-architecture/
Htmlized:       http:= //tools.ietf.org/html/draft-merged-sfc-architecture-02
Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-02=

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.ietf.org.

The IETF Secretariat




_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/sfc

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/ma= ilman/listinfo/sfc

_______________________________________________
sfc mailing = list
sfc@ietf.org
https://www.ietf.org/ma= ilman/listinfo/sfc

=

= --Apple-Mail=_B44B2E41-2591-45BC-AD60-B7E72922911E-- From nobody Mon Aug 25 16:42: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 70A381A040D for ; Mon, 25 Aug 2014 16:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.568 X-Spam-Level: X-Spam-Status: No, score=-14.568 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, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 Mr3U05IDz5_t for ; Mon, 25 Aug 2014 16:42:40 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2471C1A03F6 for ; Mon, 25 Aug 2014 16:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19451; q=dns/txt; s=iport; t=1409010160; x=1410219760; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=TaOyIpBInbzmUwiEqTvBotEjP8HOtyVYTTSxuyVm/js=; b=TSk02/9K3y0O+lZI0xn0C4ZALXH8aV6i4FIC3GzIoBg95wSSBYkYtUiX F7BT7o78l1GTML81Pu+Cy9u9Xu9mDeZJDj7dFQMwnk3SwiISELaWbfeCn BZ8qUt+pnOgrrFeOJML9CqYFBy7+UPM/iVgWoosGuIHZw5nQQ6rPhSjAw I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFAJXJ+1OtJA2N/2dsb2JhbABZgw1TUwQEzEwBDYdJAYEeFneEAwEBAQICAQEBGkoHCQIQCxEBAgECAQkeBw8CFh8DBggGDQEFAgEBBRKIJwgFvz4XjmoRAT8RBgEGA4RDBYsig3GGPIQpglGBMiaFV41dg35MAYEOOYEHAQEB X-IronPort-AV: E=Sophos; i="5.04,400,1406592000"; d="scan'208,217"; a="72271100" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP; 25 Aug 2014 23:42:39 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s7PNgcQw009244 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 25 Aug 2014 23:42:38 GMT Received: from [10.21.64.225] (10.21.64.225) by xhc-rcd-x04.cisco.com (173.37.183.78) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 25 Aug 2014 18:42:38 -0500 Message-ID: <53FBC9F1.200@cisco.com> Date: Mon, 25 Aug 2014 16:42:41 -0700 From: Reinaldo Penno Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" References: <20140822165913.29275.92328.idtracker@ietfa.amsl.com> <53FB6D2E.3010202@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040503050406080401020506" X-Originating-IP: [10.21.64.225] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/-DLJXhpeZOOpFJbsKmfs34a_rp4 Cc: "sfc@ietf.org" Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-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: Mon, 25 Aug 2014 23:42:42 -0000 --------------040503050406080401020506 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit New definition looks good, leaves door open to naked SFFs. thanks, On 8/25/14 12:14 PM, Carlos Pignataro (cpignata) wrote: > Reinaldo, > > Thanks for the comment, good set of points. It does seem that the > definition itself might be unnecessarily overly restrictive. > > We could say "zero or more" or we could say "typically one or more", > but I think it is better to spell out the function. Here's one more > comprehensive proposal: > > Old: > Service Function Forwarder (SFF): A service function forwarder is > responsible for delivering traffic received from the network to > one or more connected service functions according to information > carried in the SFC encapsulation. > > New: > Service Function Forwarder (SFF): A service function forwarder is > responsible for delivering traffic received from the network to > one or more connected service functions according to information > carried in the SFC encapsulation, as well as for delivering > traffic to > a classifier or mapping out traffic to another SFF (in the same or > different type of overlay). > > WG, Reinaldo, > > Thoughts? > > Thanks, > > Carlos. > > On Aug 25, 2014, at 1:06 PM, Reinaldo Penno > wrote: > >> A couple of points about SFF definition. You mention "one or more >> connected service functions" >> >> But in our implementation we have two types of SFFs that do not have SFs: >> >> - A SFF that maps from one overlay to another, say, VXLAN to GRE >> - A SFF that only has a classifier (no SFs in itself) >> >> Where would they fit or how to to make sure the architecture can >> predict their usage? >> >> thanks, >> >> On 8/23/14 1:47 PM, Carlos Pignataro (cpignata) wrote: >>> SFC, >>> >>> Please find below the email notice of a new revision >>> of draft-merged-sfc-architecture. >>> >>> Full set of diffs from -00 (IETF90) to -02 (now) can be seen here: >>> http://www.ietf.org/rfcdiff?url2=draft-merged-sfc-architecture-02&url1=draft-merged-sfc-architecture-00 >>> >>> We still expect further changes to the document; but we also believe >>> that this revision captures the key points and addresses the key >>> open items, as planned in Toronto. >>> >>> The key objective being to create a single document basis for the >>> SFC architecture. >>> >>> SFC Chairs, >>> >>> We believe that this revision fulfills the next steps agreed in >>> Toronto (http://tools.ietf.org/agenda/90/slides/slides-90-sfc-3.pdf). >>> >>> This revision, while we expect changes, is now close enough that we >>> think it makes sense for the WG to take it as the basis for the WG >>> document to address the deliverable. >>> >>> draft-merged-sfc-architecture-02 addressed the key points -- and we >>> believe is ready to start a poll for adoption. Can you please >>> initiate that WG adoption call for draft-merged-sfc-architecture-02? >>> >>> Thanks, >>> >>> Carlos & Joel. >>> >>> >>> Begin forwarded message: >>> >>>> *From: *> >>>> *Subject: **New Version Notification for >>>> draft-merged-sfc-architecture-02.txt* >>>> *Date: *August 22, 2014 at 12:59:13 PM EDT >>>> *To: *Joel Halpern >>> >, Carlos Pignataro >>> >, "Joel M. Halpern" >>>> >, Carlos >>>> Pignataro > >>>> >>>> >>>> A new version of I-D, draft-merged-sfc-architecture-02.txt >>>> has been successfully submitted by Carlos Pignataro and posted to the >>>> IETF repository. >>>> >>>> Name:draft-merged-sfc-architecture >>>> Revision:02 >>>> Title:Service Function Chaining (SFC) Architecture >>>> Document date:2014-08-22 >>>> Group:Individual Submission >>>> Pages:26 >>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-02.txt >>>> Status: https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ >>>> Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-02 >>>> Diff: http://www.ietf.org/rfcdiff?url2=draft-merged-sfc-architecture-02 >>>> >>>> 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.ietf.org >>>> . >>>> >>>> The IETF Secretariat >>>> >>> >>> >>> >>> _______________________________________________ >>> 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 > --------------040503050406080401020506 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit New definition looks good, leaves door open to naked SFFs.

thanks,



On 8/25/14 12:14 PM, Carlos Pignataro (cpignata) wrote:
Reinaldo,

Thanks for the comment, good set of points. It does seem that the definition itself might be unnecessarily overly restrictive.

We could say "zero or more" or we could say "typically one or more", but I think it is better to spell out the function. Here's one more comprehensive proposal:

Old:
   Service Function Forwarder (SFF):  A service function forwarder is
        responsible for delivering traffic received from the network to
        one or more connected service functions according to information
        carried in the SFC encapsulation.

New:
   Service Function Forwarder (SFF):  A service function forwarder is
        responsible for delivering traffic received from the network to
        one or more connected service functions according to information
        carried in the SFC encapsulation, as well as for delivering traffic to
        a classifier or mapping out traffic to another SFF (in the same or
        different type of overlay).

WG, Reinaldo,

Thoughts?

Thanks,

Carlos.

On Aug 25, 2014, at 1:06 PM, Reinaldo Penno <repenno@cisco.com> wrote:

A couple of points about SFF definition. You mention "one or more connected service functions"

But in our implementation we have two types of SFFs that do not have SFs:

- A SFF that maps from one overlay to another, say, VXLAN to GRE
- A SFF that only has a classifier (no SFs in itself)

Where would they fit or how to to make sure the architecture can predict their usage?

thanks,

On 8/23/14 1:47 PM, Carlos Pignataro (cpignata) wrote:
SFC,

Please find below the email notice of a new revision of draft-merged-sfc-architecture.


We still expect further changes to the document; but we also believe that this revision captures the key points and addresses the key open items, as planned in Toronto.

The key objective being to create a single document basis for the SFC architecture.

SFC Chairs,

We believe that this revision fulfills the next steps agreed in Toronto (http://tools.ietf.org/agenda/90/slides/slides-90-sfc-3.pdf). 

This revision, while we expect changes, is now close enough that we think it makes sense for the WG to take it as the basis for the WG document to address the deliverable.

draft-merged-sfc-architecture-02 addressed the key points -- and we believe is ready to start a poll for adoption. Can you please initiate that WG adoption call for draft-merged-sfc-architecture-02?

Thanks,

Carlos & Joel.


Begin forwarded message:

Subject: New Version Notification for draft-merged-sfc-architecture-02.txt
Date: August 22, 2014 at 12:59:13 PM EDT
To: Joel Halpern <jmh@joelhalpern.com>, Carlos Pignataro <cpignata@cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Carlos Pignataro <cpignata@cisco.com>


A new version of I-D, draft-merged-sfc-architecture-02.txt
has been successfully submitted by Carlos Pignataro and posted to the
IETF repository.

Name: draft-merged-sfc-architecture
Revision: 02
Title: Service Function Chaining (SFC) Architecture
Document date: 2014-08-22
Group: Individual Submission
Pages: 26
URL:            http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-02.txt
Status:         https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/
Htmlized:       http://tools.ietf.org/html/draft-merged-sfc-architecture-02
Diff:           http://www.ietf.org/rfcdiff?url2=draft-merged-sfc-architecture-02

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.ietf.org.

The IETF Secretariat




_______________________________________________
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


--------------040503050406080401020506-- From nobody Mon Aug 25 17:58: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 244A11A0545 for ; Mon, 25 Aug 2014 17:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 6ppNmuQtf2Om for ; Mon, 25 Aug 2014 17:58: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 30C201A0537 for ; Mon, 25 Aug 2014 17:58:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLT65842; Tue, 26 Aug 2014 00:58:02 +0000 (GMT) Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 26 Aug 2014 01:58:01 +0100 Received: from SZXEMA509-MBX.china.huawei.com ([169.254.1.59]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Tue, 26 Aug 2014 08:57:54 +0800 From: "Hongyu Li (Julio)" To: "Carlos Pignataro (cpignata)" , "Reinaldo Penno (repenno)" Thread-Topic: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-02.txt Thread-Index: AQHPwIcVuQ+tiNh5S0SAR221zFD0IZvhKoOAgADlDiA= Date: Tue, 26 Aug 2014 00:57:54 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97EA59B54@SZXEMA509-MBX.china.huawei.com> References: <20140822165913.29275.92328.idtracker@ietfa.amsl.com> <53FB6D2E.3010202@cisco.com> 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.66.114.234] Content-Type: multipart/alternative; boundary="_000_6EB34CB5D82C4645B826C56144826EA97EA59B54SZXEMA509MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/MvmUJU2Vx1xOMmVhOVk8558OOSU Cc: "sfc@ietf.org" Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-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: Tue, 26 Aug 2014 00:58:10 -0000 --_000_6EB34CB5D82C4645B826C56144826EA97EA59B54SZXEMA509MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2FybG9zLA0KDQpGb3IgdGhlIG5ldyBkZWZpbml0aW9uLCBub3Qgc3VyZSDigJxkZWxpdmVy aW5nIHRyYWZmaWMgdG8gYSBjbGFzc2lmaWVy4oCdIGlzIHRoZSBiZXN0IHdheSB0byBzYXkuIElu IGNhc2UgdGhlIGNsYXNzaWZpZXIgaXMgaW5zaWRlIHRoZSBjdXJyZW50IFNGRiwgaXQgaXMgYmV0 dGVyIHRvIHNheSB0aGUgU0ZGIHJlLS9jbGFzc2lmeSB0aGUgdHJhZmZpYyB0aGFuIGRlbGl2ZXIg aXQgdG8gYSBjbGFzc2lmaWVyLiBJbiBjYXNlIHRoZSBjbGFzc2lmaWVyIGlzIGluIHRoZSBuZXh0 IFNGRiwgdGhlIGN1cnJlbnQgU0ZGIHdvdWxkIG9ubHkgZm9yd2FyZCB0aGUgdHJhZmZpYyB0byB0 aGUgbmV4dCBTRkYsIHdpdGhvdXQga25vd2luZyBvciBjYXJpbmcgYWJvdXQgaWYgdGhlcmUgaXMg YSBjbGFzc2lmaWVyIHRoZXJlLg0KDQpDaGVlcnMsDQpIb25neXUNCg0KRnJvbTogc2ZjIFttYWls dG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDYXJsb3MgUGlnbmF0YXJvIChj cGlnbmF0YSkNClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAyNiwgMjAxNCAzOjE1IEFNDQpUbzogUmVp bmFsZG8gUGVubm8gKHJlcGVubm8pDQpDYzogc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Nm Y10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1lcmdlZC1zZmMtYXJj aGl0ZWN0dXJlLTAyLnR4dA0KDQpSZWluYWxkbywNCg0KVGhhbmtzIGZvciB0aGUgY29tbWVudCwg Z29vZCBzZXQgb2YgcG9pbnRzLiBJdCBkb2VzIHNlZW0gdGhhdCB0aGUgZGVmaW5pdGlvbiBpdHNl bGYgbWlnaHQgYmUgdW5uZWNlc3NhcmlseSBvdmVybHkgcmVzdHJpY3RpdmUuDQoNCldlIGNvdWxk IHNheSAiemVybyBvciBtb3JlIiBvciB3ZSBjb3VsZCBzYXkgInR5cGljYWxseSBvbmUgb3IgbW9y ZSIsIGJ1dCBJIHRoaW5rIGl0IGlzIGJldHRlciB0byBzcGVsbCBvdXQgdGhlIGZ1bmN0aW9uLiBI ZXJlJ3Mgb25lIG1vcmUgY29tcHJlaGVuc2l2ZSBwcm9wb3NhbDoNCg0KT2xkOg0KICAgU2Vydmlj ZSBGdW5jdGlvbiBGb3J3YXJkZXIgKFNGRik6ICBBIHNlcnZpY2UgZnVuY3Rpb24gZm9yd2FyZGVy IGlzDQogICAgICAgIHJlc3BvbnNpYmxlIGZvciBkZWxpdmVyaW5nIHRyYWZmaWMgcmVjZWl2ZWQg ZnJvbSB0aGUgbmV0d29yayB0bw0KICAgICAgICBvbmUgb3IgbW9yZSBjb25uZWN0ZWQgc2Vydmlj ZSBmdW5jdGlvbnMgYWNjb3JkaW5nIHRvIGluZm9ybWF0aW9uDQogICAgICAgIGNhcnJpZWQgaW4g dGhlIFNGQyBlbmNhcHN1bGF0aW9uLg0KDQpOZXc6DQogICBTZXJ2aWNlIEZ1bmN0aW9uIEZvcndh cmRlciAoU0ZGKTogIEEgc2VydmljZSBmdW5jdGlvbiBmb3J3YXJkZXIgaXMNCiAgICAgICAgcmVz cG9uc2libGUgZm9yIGRlbGl2ZXJpbmcgdHJhZmZpYyByZWNlaXZlZCBmcm9tIHRoZSBuZXR3b3Jr IHRvDQogICAgICAgIG9uZSBvciBtb3JlIGNvbm5lY3RlZCBzZXJ2aWNlIGZ1bmN0aW9ucyBhY2Nv cmRpbmcgdG8gaW5mb3JtYXRpb24NCiAgICAgICAgY2FycmllZCBpbiB0aGUgU0ZDIGVuY2Fwc3Vs YXRpb24sIGFzIHdlbGwgYXMgZm9yIGRlbGl2ZXJpbmcgdHJhZmZpYyB0bw0KICAgICAgICBhIGNs YXNzaWZpZXIgb3IgbWFwcGluZyBvdXQgdHJhZmZpYyB0byBhbm90aGVyIFNGRiAoaW4gdGhlIHNh bWUgb3INCiAgICAgICAgZGlmZmVyZW50IHR5cGUgb2Ygb3ZlcmxheSkuDQoNCldHLCBSZWluYWxk bywNCg0KVGhvdWdodHM/DQoNClRoYW5rcywNCg0KQ2FybG9zLg0KDQpPbiBBdWcgMjUsIDIwMTQs IGF0IDE6MDYgUE0sIFJlaW5hbGRvIFBlbm5vIDxyZXBlbm5vQGNpc2NvLmNvbTxtYWlsdG86cmVw ZW5ub0BjaXNjby5jb20+PiB3cm90ZToNCg0KDQpBIGNvdXBsZSBvZiBwb2ludHMgYWJvdXQgU0ZG IGRlZmluaXRpb24uIFlvdSBtZW50aW9uICJvbmUgb3IgbW9yZSBjb25uZWN0ZWQgc2VydmljZSBm dW5jdGlvbnMiDQoNCkJ1dCBpbiBvdXIgaW1wbGVtZW50YXRpb24gd2UgaGF2ZSB0d28gdHlwZXMg b2YgU0ZGcyB0aGF0IGRvIG5vdCBoYXZlIFNGczoNCg0KLSBBIFNGRiB0aGF0IG1hcHMgZnJvbSBv bmUgb3ZlcmxheSB0byBhbm90aGVyLCBzYXksIFZYTEFOIHRvIEdSRQ0KLSBBIFNGRiB0aGF0IG9u bHkgaGFzIGEgY2xhc3NpZmllciAobm8gU0ZzIGluIGl0c2VsZikNCg0KV2hlcmUgd291bGQgdGhl eSBmaXQgb3IgaG93IHRvIHRvIG1ha2Ugc3VyZSB0aGUgYXJjaGl0ZWN0dXJlIGNhbiBwcmVkaWN0 IHRoZWlyIHVzYWdlPw0KDQp0aGFua3MsDQpPbiA4LzIzLzE0IDE6NDcgUE0sIENhcmxvcyBQaWdu YXRhcm8gKGNwaWduYXRhKSB3cm90ZToNClNGQywNCg0KUGxlYXNlIGZpbmQgYmVsb3cgdGhlIGVt YWlsIG5vdGljZSBvZiBhIG5ldyByZXZpc2lvbiBvZiBkcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVj dHVyZS4NCg0KRnVsbCBzZXQgb2YgZGlmZnMgZnJvbSAtMDAgKElFVEY5MCkgdG8gLTAyIChub3cp IGNhbiBiZSBzZWVuIGhlcmU6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAyJnVybDE9ZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRl Y3R1cmUtMDANCg0KV2Ugc3RpbGwgZXhwZWN0IGZ1cnRoZXIgY2hhbmdlcyB0byB0aGUgZG9jdW1l bnQ7IGJ1dCB3ZSBhbHNvIGJlbGlldmUgdGhhdCB0aGlzIHJldmlzaW9uIGNhcHR1cmVzIHRoZSBr ZXkgcG9pbnRzIGFuZCBhZGRyZXNzZXMgdGhlIGtleSBvcGVuIGl0ZW1zLCBhcyBwbGFubmVkIGlu IFRvcm9udG8uDQoNClRoZSBrZXkgb2JqZWN0aXZlIGJlaW5nIHRvIGNyZWF0ZSBhIHNpbmdsZSBk b2N1bWVudCBiYXNpcyBmb3IgdGhlIFNGQyBhcmNoaXRlY3R1cmUuDQoNClNGQyBDaGFpcnMsDQoN CldlIGJlbGlldmUgdGhhdCB0aGlzIHJldmlzaW9uIGZ1bGZpbGxzIHRoZSBuZXh0IHN0ZXBzIGFn cmVlZCBpbiBUb3JvbnRvIChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvYWdlbmRhLzkwL3NsaWRlcy9z bGlkZXMtOTAtc2ZjLTMucGRmKS4NCg0KVGhpcyByZXZpc2lvbiwgd2hpbGUgd2UgZXhwZWN0IGNo YW5nZXMsIGlzIG5vdyBjbG9zZSBlbm91Z2ggdGhhdCB3ZSB0aGluayBpdCBtYWtlcyBzZW5zZSBm b3IgdGhlIFdHIHRvIHRha2UgaXQgYXMgdGhlIGJhc2lzIGZvciB0aGUgV0cgZG9jdW1lbnQgdG8g YWRkcmVzcyB0aGUgZGVsaXZlcmFibGUuDQoNCmRyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJl LTAyIGFkZHJlc3NlZCB0aGUga2V5IHBvaW50cyAtLSBhbmQgd2UgYmVsaWV2ZSBpcyByZWFkeSB0 byBzdGFydCBhIHBvbGwgZm9yIGFkb3B0aW9uLiBDYW4geW91IHBsZWFzZSBpbml0aWF0ZSB0aGF0 IFdHIGFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAyPw0K DQpUaGFua3MsDQoNCkNhcmxvcyAmIEpvZWwuDQoNCg0KQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6 DQoNCg0KRnJvbTogPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnPj4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUtMDIudHh0DQpEYXRlOiBBdWd1c3QgMjIsIDIwMTQg YXQgMTI6NTk6MTMgUE0gRURUDQpUbzogSm9lbCBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29t PG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4sIENhcmxvcyBQaWduYXRhcm8gPGNwaWduYXRh QGNpc2NvLmNvbTxtYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tPj4sICJKb2VsIE0uIEhhbHBlcm4i IDxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4sIENhcmxv cyBQaWduYXRhcm8gPGNwaWduYXRhQGNpc2NvLmNvbTxtYWlsdG86Y3BpZ25hdGFAY2lzY28uY29t Pj4NCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1 cmUtMDIudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IENhcmxvcyBQaWdu YXRhcm8gYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogZHJhZnQt bWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUNClJldmlzaW9uOiAwMg0KVGl0bGU6IFNlcnZpY2UgRnVu Y3Rpb24gQ2hhaW5pbmcgKFNGQykgQXJjaGl0ZWN0dXJlDQpEb2N1bWVudCBkYXRlOiAyMDE0LTA4 LTIyDQpHcm91cDogSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogMjYNClVSTDogICAgICAg ICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tZXJnZWQtc2Zj LWFyY2hpdGVjdHVyZS0wMi50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZS8NCkh0bWxpemVkOiAg ICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVj dHVyZS0wMg0KRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAyDQoNCkFic3RyYWN0Og0KICBUaGlzIGRv Y3VtZW50IGRlc2NyaWJlcyBhbiBhcmNoaXRlY3R1cmUgZm9yIHRoZSBzcGVjaWZpY2F0aW9uLA0K ICBjcmVhdGlvbiwgYW5kIG9uZ29pbmcgbWFpbnRlbmFuY2Ugb2YgU2VydmljZSBGdW5jdGlvbiBD aGFpbnMgKFNGQykgaW4NCiAgYSBuZXR3b3JrLiAgSXQgaW5jbHVkZXMgYXJjaGl0ZWN0dXJhbCBj b25jZXB0cywgcHJpbmNpcGxlcywgYW5kDQogIGNvbXBvbmVudHMgdXNlZCBpbiB0aGUgY29uc3Ry dWN0aW9uIG9mIGNvbXBvc2l0ZSBzZXJ2aWNlcyB0aHJvdWdoDQogIGRlcGxveW1lbnQgb2YgU0ZD cy4gIFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgcHJvcG9zZSBzb2x1dGlvbnMsDQogIHByb3RvY29s cywgb3IgZXh0ZW5zaW9ucyB0byBleGlzdGluZyBwcm90b2NvbHMuDQoNCg0KDQoNClBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m IHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnLz4uDQoNClRoZSBJ RVRGIFNlY3JldGFyaWF0DQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0Kc2ZjIG1haWxpbmcgbGlzdA0KDQpzZmNAaWV0Zi5vcmc8bWFp bHRvOnNmY0BpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZmMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0K --_000_6EB34CB5D82C4645B826C56144826EA97EA59B54SZXEMA509MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNh Ow0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsN CglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFw5ODg0XDhCQkVcNjgzQ1w1RjBGIENoYXIiOw0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5N c29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiXDYy NzlcNkNFOFw2ODQ2XDY1ODdcNjcyQyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjt9DQpzcGFuLmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFw cGxlLXRhYi1zcGFuO30NCnNwYW4uSFRNTENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgXDk4 ODRcOEJCRVw2ODNDXDVGMEYgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFw5ODg0XDhCQkVcNjgzQ1w1RjBGIjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6Ilw2Mjc5XDZDRThcNjg0Nlw2NTg3 XDY3MkMgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOlw2 Mjc5XDZDRThcNjg0Nlw2NTg3XDY3MkM7DQoJZm9udC1mYW1pbHk6U2ltU3VuO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5IaSBDYXJsb3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZv ciB0aGUgbmV3IGRlZmluaXRpb24sIG5vdCBzdXJlIOKAnGRlbGl2ZXJpbmcgdHJhZmZpYyB0byBh IGNsYXNzaWZpZXLigJ0gaXMgdGhlIGJlc3Qgd2F5IHRvIHNheS4gSW4gY2FzZSB0aGUgY2xhc3Np ZmllciBpcyBpbnNpZGUgdGhlIGN1cnJlbnQgU0ZGLA0KIGl0IGlzIGJldHRlciB0byBzYXkgdGhl IFNGRiByZS0vY2xhc3NpZnkgdGhlIHRyYWZmaWMgdGhhbiBkZWxpdmVyIGl0IHRvIGEgY2xhc3Np Zmllci4gSW4gY2FzZSB0aGUgY2xhc3NpZmllciBpcyBpbiB0aGUgbmV4dCBTRkYsIHRoZSBjdXJy ZW50IFNGRiB3b3VsZCBvbmx5IGZvcndhcmQgdGhlIHRyYWZmaWMgdG8gdGhlIG5leHQgU0ZGLCB3 aXRob3V0IGtub3dpbmcgb3IgY2FyaW5nIGFib3V0IGlmIHRoZXJlIGlzIGEgY2xhc3NpZmllciB0 aGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hlZXJzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SG9uZ3l1PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gc2ZjIFttYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkNhcmxvcyBQaWduYXRh cm8gKGNwaWduYXRhKTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBdWd1c3QgMjYsIDIwMTQg MzoxNSBBTTxicj4NCjxiPlRvOjwvYj4gUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pPGJyPg0KPGI+ Q2M6PC9iPiBzZmNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzZmNdIEZ3ZDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVy ZS0wMi50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWluYWxkbywgPG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzIGZvciB0aGUgY29t bWVudCwgZ29vZCBzZXQgb2YgcG9pbnRzLiBJdCBkb2VzIHNlZW0gdGhhdCB0aGUgZGVmaW5pdGlv biBpdHNlbGYgbWlnaHQgYmUgdW5uZWNlc3NhcmlseSBvdmVybHkgcmVzdHJpY3RpdmUuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5XZSBjb3VsZCBzYXkg JnF1b3Q7emVybyBvciBtb3JlJnF1b3Q7IG9yIHdlIGNvdWxkIHNheSAmcXVvdDt0eXBpY2FsbHkg b25lIG9yIG1vcmUmcXVvdDssIGJ1dCBJIHRoaW5rIGl0IGlzIGJldHRlciB0byBzcGVsbCBvdXQg dGhlIGZ1bmN0aW9uLiBIZXJlJ3Mgb25lIG1vcmUgY29tcHJlaGVuc2l2ZSBwcm9wb3NhbDo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9sZDo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDtTZXJ2aWNlIEZ1bmN0aW9uIEZvcndh cmRlciAoU0ZGKTogJm5ic3A7QSBzZXJ2aWNlIGZ1bmN0aW9uIGZvcndhcmRlciBpczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcmVzcG9uc2libGUgZm9y IGRlbGl2ZXJpbmcgdHJhZmZpYyByZWNlaXZlZCBmcm9tIHRoZSBuZXR3b3JrIHRvPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBvbmUgb3IgbW9yZSBjb25u ZWN0ZWQgc2VydmljZSBmdW5jdGlvbnMgYWNjb3JkaW5nIHRvIGluZm9ybWF0aW9uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjYXJyaWVkIGluIHRoZSBT RkMgZW5jYXBzdWxhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+TmV3OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 ICZuYnNwO1NlcnZpY2UgRnVuY3Rpb24gRm9yd2FyZGVyIChTRkYpOiAmbmJzcDtBIHNlcnZpY2Ug ZnVuY3Rpb24gZm9yd2FyZGVyIGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyByZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZyB0cmFmZmljIHJlY2VpdmVk IGZyb20gdGhlIG5ldHdvcmsgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IG9uZSBvciBtb3JlIGNvbm5lY3RlZCBzZXJ2aWNlIGZ1bmN0aW9ucyBhY2Nv cmRpbmcgdG8gaW5mb3JtYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IGNhcnJpZWQgaW4gdGhlIFNGQyBlbmNhcHN1bGF0aW9uLCBhcyB3ZWxsIGFz IGZvciBkZWxpdmVyaW5nIHRyYWZmaWMgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IGEgY2xhc3NpZmllciBvciBtYXBwaW5nIG91dCB0cmFmZmljIHRv IGFub3RoZXIgU0ZGIChpbiB0aGUgc2FtZSBvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgZGlmZmVyZW50IHR5cGUgb2Ygb3ZlcmxheSkuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPldHLCBSZWlu YWxkbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRo b3VnaHRzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ Q2FybG9zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5P biBBdWcgMjUsIDIwMTQsIGF0IDE6MDYgUE0sIFJlaW5hbGRvIFBlbm5vICZsdDs8YSBocmVmPSJt YWlsdG86cmVwZW5ub0BjaXNjby5jb20iPnJlcGVubm9AY2lzY28uY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiPkEgY291cGxlIG9mIHBvaW50cyBhYm91dCBTRkYgZGVmaW5pdGlvbi4gWW91 IG1lbnRpb24gJnF1b3Q7b25lIG9yIG1vcmUgY29ubmVjdGVkIHNlcnZpY2UgZnVuY3Rpb25zJnF1 b3Q7DQo8YnI+DQo8YnI+DQpCdXQgaW4gb3VyIGltcGxlbWVudGF0aW9uIHdlIGhhdmUgdHdvIHR5 cGVzIG9mIFNGRnMgdGhhdCBkbyBub3QgaGF2ZSBTRnM6PGJyPg0KPGJyPg0KLSBBIFNGRiB0aGF0 IG1hcHMgZnJvbSBvbmUgb3ZlcmxheSB0byBhbm90aGVyLCBzYXksIFZYTEFOIHRvIEdSRTxicj4N Ci0gQSBTRkYgdGhhdCBvbmx5IGhhcyBhIGNsYXNzaWZpZXIgKG5vIFNGcyBpbiBpdHNlbGYpPGJy Pg0KPGJyPg0KV2hlcmUgd291bGQgdGhleSBmaXQgb3IgaG93IHRvIHRvIG1ha2Ugc3VyZSB0aGUg YXJjaGl0ZWN0dXJlIGNhbiBwcmVkaWN0IHRoZWlyIHVzYWdlPzxicj4NCjxicj4NCnRoYW5rcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPk9uIDgvMjMvMTQgMTo0NyBQTSwgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25h dGEpIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U0ZDLCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5QbGVhc2UgZmluZCBiZWxvdyB0aGUgZW1haWwgbm90aWNlIG9mIGEg bmV3IHJldmlzaW9uIG9mJm5ic3A7ZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5GdWxsIHNldCBvZiBk aWZmcyBmcm9tIC0wMCAoSUVURjkwKSB0byAtMDIgKG5vdykgY2FuIGJlIHNlZW4gaGVyZTombmJz cDs8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1tZXJnZWQt c2ZjLWFyY2hpdGVjdHVyZS0wMiZhbXA7dXJsMT1kcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVy ZS0wMCI+aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbWVyZ2VkLXNmYy1h cmNoaXRlY3R1cmUtMDImYW1wO3VybDE9ZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUtMDA8 L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5XZSBz dGlsbCBleHBlY3QgZnVydGhlciBjaGFuZ2VzIHRvIHRoZSBkb2N1bWVudDsgYnV0IHdlIGFsc28g YmVsaWV2ZSB0aGF0IHRoaXMgcmV2aXNpb24gY2FwdHVyZXMgdGhlIGtleSBwb2ludHMgYW5kIGFk ZHJlc3NlcyB0aGUga2V5IG9wZW4gaXRlbXMsIGFzIHBsYW5uZWQgaW4gVG9yb250by48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBrZXkgb2JqZWN0 aXZlIGJlaW5nIHRvIGNyZWF0ZSBhIHNpbmdsZSBkb2N1bWVudCBiYXNpcyBmb3IgdGhlIFNGQyBh cmNoaXRlY3R1cmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5TRkMgQ2hhaXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+V2UgYmVsaWV2ZSB0aGF0IHRoaXMgcmV2aXNpb24gZnVsZmlsbHMgdGhlIG5leHQg c3RlcHMgYWdyZWVkIGluIFRvcm9udG8gKDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9h Z2VuZGEvOTAvc2xpZGVzL3NsaWRlcy05MC1zZmMtMy5wZGYiPmh0dHA6Ly90b29scy5pZXRmLm9y Zy9hZ2VuZGEvOTAvc2xpZGVzL3NsaWRlcy05MC1zZmMtMy5wZGY8L2E+KS4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoaXMgcmV2aXNpb24s IHdoaWxlIHdlIGV4cGVjdCBjaGFuZ2VzLCBpcyBub3cmbmJzcDtjbG9zZSBlbm91Z2ggdGhhdCB3 ZSB0aGluayBpdCBtYWtlcyBzZW5zZSBmb3IgdGhlIFdHIHRvIHRha2UgaXQgYXMgdGhlIGJhc2lz IGZvciB0aGUgV0cgZG9jdW1lbnQgdG8gYWRkcmVzcyB0aGUgZGVsaXZlcmFibGUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5kcmFmdC1tZXJnZWQtc2Zj LWFyY2hpdGVjdHVyZS0wMiBhZGRyZXNzZWQgdGhlIGtleSBwb2ludHMgLS0gYW5kIHdlIGJlbGll dmUgaXMgcmVhZHkgdG8gc3RhcnQgYSBwb2xsIGZvciBhZG9wdGlvbi4gQ2FuIHlvdSBwbGVhc2Ug aW5pdGlhdGUgdGhhdCBXRyBhZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1tZXJnZWQtc2ZjLWFyY2hp dGVjdHVyZS0wMj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPkNhcmxvcyAmYW1wOyBKb2VsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QmVnaW4gZm9yd2FyZGVk IG1lc3NhZ2U6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZsdDs8YSBo cmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc8L2E+Jmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZS0wMi50eHQ8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EYXRlOg0KPC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BdWd1c3QgMjIsIDIwMTQgYXQgMTI6NTk6MTMgUE0g RURUPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5UbzoNCjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Sm9lbCBIYWxw ZXJuICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxw ZXJuLmNvbTwvYT4mZ3Q7LCBDYXJsb3MgUGlnbmF0YXJvICZsdDs8YSBocmVmPSJtYWlsdG86Y3Bp Z25hdGFAY2lzY28uY29tIj5jcGlnbmF0YUBjaXNjby5jb208L2E+Jmd0OywgJnF1b3Q7Sm9lbCBN LiBIYWxwZXJuJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+ am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7LA0KIENhcmxvcyBQaWduYXRhcm8gJmx0OzxhIGhy ZWY9Im1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20iPmNwaWduYXRhQGNpc2NvLmNvbTwvYT4mZ3Q7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAyLnR4dDxicj4NCmhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQ2FybG9zIFBpZ25hdGFybyBhbmQgcG9zdGVkIHRvIHRo ZTxicj4NCklFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOjxzcGFuIGNsYXNzPSJhcHBs ZS10YWItc3BhbiI+IDwvc3Bhbj5kcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZTxicj4NClJl dmlzaW9uOjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+IDwvc3Bhbj4wMjxicj4NClRpdGxl OjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+IDwvc3Bhbj5TZXJ2aWNlIEZ1bmN0aW9uIENo YWluaW5nIChTRkMpIEFyY2hpdGVjdHVyZTxicj4NCkRvY3VtZW50IGRhdGU6PHNwYW4gY2xhc3M9 ImFwcGxlLXRhYi1zcGFuIj4gPC9zcGFuPjIwMTQtMDgtMjI8YnI+DQpHcm91cDo8c3BhbiBjbGFz cz0iYXBwbGUtdGFiLXNwYW4iPiA8L3NwYW4+SW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KUGFn ZXM6PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4gPC9zcGFuPjI2PGJyPg0KVVJMOiAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDs8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1t ZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZS0wMi50eHQiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAyLnR4dDwvYT48YnI+DQpT dGF0dXM6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxh IGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1lcmdlZC1zZmMt YXJjaGl0ZWN0dXJlLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWVy Z2VkLXNmYy1hcmNoaXRlY3R1cmUvPC9hPjxicj4NCkh0bWxpemVkOiAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZS0wMiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUtMDI8L2E+PGJyPg0KRGlmZjogJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEg aHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbWVyZ2VkLXNmYy1h cmNoaXRlY3R1cmUtMDIiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW1l cmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAyPC9hPjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZu YnNwOyZuYnNwO1RoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIGFyY2hpdGVjdHVyZSBmb3IgdGhl IHNwZWNpZmljYXRpb24sPGJyPg0KJm5ic3A7Jm5ic3A7Y3JlYXRpb24sIGFuZCBvbmdvaW5nIG1h aW50ZW5hbmNlIG9mIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5zIChTRkMpIGluPGJyPg0KJm5ic3A7 Jm5ic3A7YSBuZXR3b3JrLiAmbmJzcDtJdCBpbmNsdWRlcyBhcmNoaXRlY3R1cmFsIGNvbmNlcHRz LCBwcmluY2lwbGVzLCBhbmQ8YnI+DQombmJzcDsmbmJzcDtjb21wb25lbnRzIHVzZWQgaW4gdGhl IGNvbnN0cnVjdGlvbiBvZiBjb21wb3NpdGUgc2VydmljZXMgdGhyb3VnaDxicj4NCiZuYnNwOyZu YnNwO2RlcGxveW1lbnQgb2YgU0ZDcy4gJm5ic3A7VGhpcyBkb2N1bWVudCBkb2VzIG5vdCBwcm9w b3NlIHNvbHV0aW9ucyw8YnI+DQombmJzcDsmbmJzcDtwcm90b2NvbHMsIG9yIGV4dGVuc2lvbnMg dG8gZXhpc3RpbmcgcHJvdG9jb2xzLjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NClBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mIHN1Ym1pc3Npb248YnI+DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy8iPg0KdG9vbHMu aWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4NClRoZSBJRVRGIFNlY3JldGFyaWF0PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJFTi1VUyI+c2ZjIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRm Lm9yZyI+c2ZjQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2ZjIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_6EB34CB5D82C4645B826C56144826EA97EA59B54SZXEMA509MBXchi_-- From nobody Tue Aug 26 04:10: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 04A941A6F3C for ; Tue, 26 Aug 2014 04:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, 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 OlTXrDg6vuH0 for ; Tue, 26 Aug 2014 04:10:39 -0700 (PDT) Received: from mailgw.allot.com (mailgw.allot.com [199.203.223.210]) by ietfa.amsl.com (Postfix) with ESMTP id 326AF1A0346 for ; Tue, 26 Aug 2014 04:10:37 -0700 (PDT) Received: from PUMA.ALLOT.LOCAL (Not Verified[199.203.223.202]) by mailgw.allot.com with MailMarshal (v7, 2, 3, 6978) id ; Tue, 26 Aug 2014 14:10:34 +0300 Received: from LION.ALLOT.LOCAL ([172.20.20.40]) by PUMA.ALLOT.LOCAL ([199.203.223.202]) with mapi id 14.03.0123.003; Tue, 26 Aug 2014 14:12:53 +0300 From: Alla Goldner To: "Hongyu Li (Julio)" , "Carlos Pignataro (cpignata)" , "Reinaldo Penno (repenno)" Thread-Topic: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-02.txt Thread-Index: AQHPwIdlfEmpxoDFMUyeGZJu/IQziJvhflSAgABf2wCAANzVYA== Date: Tue, 26 Aug 2014 11:12:53 +0000 Message-ID: References: <20140822165913.29275.92328.idtracker@ietfa.amsl.com> <53FB6D2E.3010202@cisco.com> <6EB34CB5D82C4645B826C56144826EA97EA59B54@SZXEMA509-MBX.china.huawei.com> In-Reply-To: <6EB34CB5D82C4645B826C56144826EA97EA59B54@SZXEMA509-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.17.17.191] Content-Type: multipart/related; boundary="_004_A6B8F2A767638641889989BC1BA7047936014236LIONALLOTLOCAL_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/xPjEKibsmsgy3koR0Lb19K2biuM Cc: "sfc@ietf.org" Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-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: Tue, 26 Aug 2014 11:10:49 -0000 --_004_A6B8F2A767638641889989BC1BA7047936014236LIONALLOTLOCAL_ Content-Type: multipart/alternative; boundary="_000_A6B8F2A767638641889989BC1BA7047936014236LIONALLOTLOCAL_" --_000_A6B8F2A767638641889989BC1BA7047936014236LIONALLOTLOCAL_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCkkgaGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnQ6DQrigJwNCklmIHRoZXJl IGFyZSBtdWx0aXBsZSBjaG9pY2VzLCB0aGUgU0ZGIG5lZWRzIHRvIHByZXNlcnZlIHRoZSBwcm9w ZXJ0eQ0KICAgdGhhdCBhbGwgcGFja2V0cyBvZiBhIGdpdmVuIGZsb3cgYXJlIGhhbmRsZWQgdGhl IHNhbWUgd2F5LCBzaW5jZSB0aGUNCiAgIFNGIG1heSB3ZWxsIGJlIHN0YXRlZnVsLg0K4oCcDQoN CkEgc2VydmljZSBtYXkgbmVlZCBhZGRpdGlvbmFsIGxldmVscyBvZiDigJxwZXJzaXN0ZW5jeeKA nSBvbiB0b3Agb2YgYSBmbG93IChlLmcuIOKAkyBhbGwgZmxvd3MgcmVsYXRlZCB0byB0aGUgc2Ft ZSBzdWJzY3JpYmVyIC9zZXNzaW9uIGR1ZSB0byBlLmcuIHNlY3VyaXR5IHJlYXNvbnMsIGFsbCBm bG93cyByZWxhdGVkIHRvIHRoZSBzYW1lIGFwcGxpY2F0aW9uIGluc3RhbmNlKS4NCg0KSSBiZWxp ZXZlIGl0IHNob3VsZCBhbHNvIGJlIHJlZmxlY3RlZC4NCg0KQmVzdCByZWdhcmRzLA0KDQoNCg0K QWxsYSBHb2xkbmVyDQpEaXJlY3RvciBvZiBNb2JpbGUgVGVjaG5vbG9naWVzIGFuZCBTdGFuZGFy ZHMNCkFsbG90IENvbW11bmljYXRpb25zDQpUZWwgKzk3MiA5IDc2MTkyNTENCkNlbGwgKzk3MiA1 NCAyNDkzOTg1DQpGYXggKzk3MiA5IDc0NDM2MjYNCmFnb2xkbmVyQGFsbG90LmNvbTxtYWlsdG86 YWdvbGRuZXJAYWxsb3QuY29tPg0Kd3d3LmFsbG90LmNvbTxodHRwOi8vd3d3LmFsbG90LmNvbS8+ DQoNClsyOTFYNTVfc2lnbmF0dXJlICgyKV0NCg0KDQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSG9uZ3l1IExpIChKdWxpbykNClNlbnQ6IFR1 ZXNkYXksIEF1Z3VzdCAyNiwgMjAxNCAzOjU4IEFNDQpUbzogQ2FybG9zIFBpZ25hdGFybyAoY3Bp Z25hdGEpOyBSZWluYWxkbyBQZW5ubyAocmVwZW5ubykNCkNjOiBzZmNAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbc2ZjXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWVy Z2VkLXNmYy1hcmNoaXRlY3R1cmUtMDIudHh0DQoNCkhpIENhcmxvcywNCg0KRm9yIHRoZSBuZXcg ZGVmaW5pdGlvbiwgbm90IHN1cmUg4oCcZGVsaXZlcmluZyB0cmFmZmljIHRvIGEgY2xhc3NpZmll cuKAnSBpcyB0aGUgYmVzdCB3YXkgdG8gc2F5LiBJbiBjYXNlIHRoZSBjbGFzc2lmaWVyIGlzIGlu c2lkZSB0aGUgY3VycmVudCBTRkYsIGl0IGlzIGJldHRlciB0byBzYXkgdGhlIFNGRiByZS0vY2xh c3NpZnkgdGhlIHRyYWZmaWMgdGhhbiBkZWxpdmVyIGl0IHRvIGEgY2xhc3NpZmllci4gSW4gY2Fz ZSB0aGUgY2xhc3NpZmllciBpcyBpbiB0aGUgbmV4dCBTRkYsIHRoZSBjdXJyZW50IFNGRiB3b3Vs ZCBvbmx5IGZvcndhcmQgdGhlIHRyYWZmaWMgdG8gdGhlIG5leHQgU0ZGLCB3aXRob3V0IGtub3dp bmcgb3IgY2FyaW5nIGFib3V0IGlmIHRoZXJlIGlzIGEgY2xhc3NpZmllciB0aGVyZS4NCg0KQ2hl ZXJzLA0KSG9uZ3l1DQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpDQpTZW50OiBUdWVzZGF5LCBB dWd1c3QgMjYsIDIwMTQgMzoxNSBBTQ0KVG86IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKQ0KQ2M6 IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzZmNdIEZ3 ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVj dHVyZS0wMi50eHQNCg0KUmVpbmFsZG8sDQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnQsIGdvb2Qg c2V0IG9mIHBvaW50cy4gSXQgZG9lcyBzZWVtIHRoYXQgdGhlIGRlZmluaXRpb24gaXRzZWxmIG1p Z2h0IGJlIHVubmVjZXNzYXJpbHkgb3Zlcmx5IHJlc3RyaWN0aXZlLg0KDQpXZSBjb3VsZCBzYXkg Inplcm8gb3IgbW9yZSIgb3Igd2UgY291bGQgc2F5ICJ0eXBpY2FsbHkgb25lIG9yIG1vcmUiLCBi dXQgSSB0aGluayBpdCBpcyBiZXR0ZXIgdG8gc3BlbGwgb3V0IHRoZSBmdW5jdGlvbi4gSGVyZSdz IG9uZSBtb3JlIGNvbXByZWhlbnNpdmUgcHJvcG9zYWw6DQoNCk9sZDoNCiAgIFNlcnZpY2UgRnVu Y3Rpb24gRm9yd2FyZGVyIChTRkYpOiAgQSBzZXJ2aWNlIGZ1bmN0aW9uIGZvcndhcmRlciBpcw0K ICAgICAgICByZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZyB0cmFmZmljIHJlY2VpdmVkIGZyb20g dGhlIG5ldHdvcmsgdG8NCiAgICAgICAgb25lIG9yIG1vcmUgY29ubmVjdGVkIHNlcnZpY2UgZnVu Y3Rpb25zIGFjY29yZGluZyB0byBpbmZvcm1hdGlvbg0KICAgICAgICBjYXJyaWVkIGluIHRoZSBT RkMgZW5jYXBzdWxhdGlvbi4NCg0KTmV3Og0KICAgU2VydmljZSBGdW5jdGlvbiBGb3J3YXJkZXIg KFNGRik6ICBBIHNlcnZpY2UgZnVuY3Rpb24gZm9yd2FyZGVyIGlzDQogICAgICAgIHJlc3BvbnNp YmxlIGZvciBkZWxpdmVyaW5nIHRyYWZmaWMgcmVjZWl2ZWQgZnJvbSB0aGUgbmV0d29yayB0bw0K ICAgICAgICBvbmUgb3IgbW9yZSBjb25uZWN0ZWQgc2VydmljZSBmdW5jdGlvbnMgYWNjb3JkaW5n IHRvIGluZm9ybWF0aW9uDQogICAgICAgIGNhcnJpZWQgaW4gdGhlIFNGQyBlbmNhcHN1bGF0aW9u LCBhcyB3ZWxsIGFzIGZvciBkZWxpdmVyaW5nIHRyYWZmaWMgdG8NCiAgICAgICAgYSBjbGFzc2lm aWVyIG9yIG1hcHBpbmcgb3V0IHRyYWZmaWMgdG8gYW5vdGhlciBTRkYgKGluIHRoZSBzYW1lIG9y DQogICAgICAgIGRpZmZlcmVudCB0eXBlIG9mIG92ZXJsYXkpLg0KDQpXRywgUmVpbmFsZG8sDQoN ClRob3VnaHRzPw0KDQpUaGFua3MsDQoNCkNhcmxvcy4NCg0KT24gQXVnIDI1LCAyMDE0LCBhdCAx OjA2IFBNLCBSZWluYWxkbyBQZW5ubyA8cmVwZW5ub0BjaXNjby5jb208bWFpbHRvOnJlcGVubm9A Y2lzY28uY29tPj4gd3JvdGU6DQoNCg0KDQpBIGNvdXBsZSBvZiBwb2ludHMgYWJvdXQgU0ZGIGRl ZmluaXRpb24uIFlvdSBtZW50aW9uICJvbmUgb3IgbW9yZSBjb25uZWN0ZWQgc2VydmljZSBmdW5j dGlvbnMiDQoNCkJ1dCBpbiBvdXIgaW1wbGVtZW50YXRpb24gd2UgaGF2ZSB0d28gdHlwZXMgb2Yg U0ZGcyB0aGF0IGRvIG5vdCBoYXZlIFNGczoNCg0KLSBBIFNGRiB0aGF0IG1hcHMgZnJvbSBvbmUg b3ZlcmxheSB0byBhbm90aGVyLCBzYXksIFZYTEFOIHRvIEdSRQ0KLSBBIFNGRiB0aGF0IG9ubHkg aGFzIGEgY2xhc3NpZmllciAobm8gU0ZzIGluIGl0c2VsZikNCg0KV2hlcmUgd291bGQgdGhleSBm aXQgb3IgaG93IHRvIHRvIG1ha2Ugc3VyZSB0aGUgYXJjaGl0ZWN0dXJlIGNhbiBwcmVkaWN0IHRo ZWlyIHVzYWdlPw0KDQp0aGFua3MsDQpPbiA4LzIzLzE0IDE6NDcgUE0sIENhcmxvcyBQaWduYXRh cm8gKGNwaWduYXRhKSB3cm90ZToNClNGQywNCg0KUGxlYXNlIGZpbmQgYmVsb3cgdGhlIGVtYWls IG5vdGljZSBvZiBhIG5ldyByZXZpc2lvbiBvZiBkcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVy ZS4NCg0KRnVsbCBzZXQgb2YgZGlmZnMgZnJvbSAtMDAgKElFVEY5MCkgdG8gLTAyIChub3cpIGNh biBiZSBzZWVuIGhlcmU6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW1l cmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAyJnVybDE9ZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1 cmUtMDANCg0KV2Ugc3RpbGwgZXhwZWN0IGZ1cnRoZXIgY2hhbmdlcyB0byB0aGUgZG9jdW1lbnQ7 IGJ1dCB3ZSBhbHNvIGJlbGlldmUgdGhhdCB0aGlzIHJldmlzaW9uIGNhcHR1cmVzIHRoZSBrZXkg cG9pbnRzIGFuZCBhZGRyZXNzZXMgdGhlIGtleSBvcGVuIGl0ZW1zLCBhcyBwbGFubmVkIGluIFRv cm9udG8uDQoNClRoZSBrZXkgb2JqZWN0aXZlIGJlaW5nIHRvIGNyZWF0ZSBhIHNpbmdsZSBkb2N1 bWVudCBiYXNpcyBmb3IgdGhlIFNGQyBhcmNoaXRlY3R1cmUuDQoNClNGQyBDaGFpcnMsDQoNCldl IGJlbGlldmUgdGhhdCB0aGlzIHJldmlzaW9uIGZ1bGZpbGxzIHRoZSBuZXh0IHN0ZXBzIGFncmVl ZCBpbiBUb3JvbnRvIChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvYWdlbmRhLzkwL3NsaWRlcy9zbGlk ZXMtOTAtc2ZjLTMucGRmKS4NCg0KVGhpcyByZXZpc2lvbiwgd2hpbGUgd2UgZXhwZWN0IGNoYW5n ZXMsIGlzIG5vdyBjbG9zZSBlbm91Z2ggdGhhdCB3ZSB0aGluayBpdCBtYWtlcyBzZW5zZSBmb3Ig dGhlIFdHIHRvIHRha2UgaXQgYXMgdGhlIGJhc2lzIGZvciB0aGUgV0cgZG9jdW1lbnQgdG8gYWRk cmVzcyB0aGUgZGVsaXZlcmFibGUuDQoNCmRyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAy IGFkZHJlc3NlZCB0aGUga2V5IHBvaW50cyAtLSBhbmQgd2UgYmVsaWV2ZSBpcyByZWFkeSB0byBz dGFydCBhIHBvbGwgZm9yIGFkb3B0aW9uLiBDYW4geW91IHBsZWFzZSBpbml0aWF0ZSB0aGF0IFdH IGFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAyPw0KDQpU aGFua3MsDQoNCkNhcmxvcyAmIEpvZWwuDQoNCg0KQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQoN Cg0KDQpGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZS0wMi50eHQNCkRhdGU6IEF1Z3VzdCAyMiwgMjAxNCBh dCAxMjo1OToxMyBQTSBFRFQNClRvOiBKb2VsIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb208 bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PiwgQ2FybG9zIFBpZ25hdGFybyA8Y3BpZ25hdGFA Y2lzY28uY29tPG1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20+PiwgIkpvZWwgTS4gSGFscGVybiIg PGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PiwgQ2FybG9z IFBpZ25hdGFybyA8Y3BpZ25hdGFAY2lzY28uY29tPG1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20+ Pg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVy ZS0wMi50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQ2FybG9zIFBpZ25h dGFybyBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiBkcmFmdC1t ZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZQ0KUmV2aXNpb246IDAyDQpUaXRsZTogU2VydmljZSBGdW5j dGlvbiBDaGFpbmluZyAoU0ZDKSBBcmNoaXRlY3R1cmUNCkRvY3VtZW50IGRhdGU6IDIwMTQtMDgt MjINCkdyb3VwOiBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAyNg0KVVJMOiAgICAgICAg ICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1lcmdlZC1zZmMt YXJjaGl0ZWN0dXJlLTAyLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLw0KSHRtbGl6ZWQ6ICAg ICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0 dXJlLTAyDQpEaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUtMDINCg0KQWJzdHJhY3Q6DQogIFRoaXMgZG9j dW1lbnQgZGVzY3JpYmVzIGFuIGFyY2hpdGVjdHVyZSBmb3IgdGhlIHNwZWNpZmljYXRpb24sDQog IGNyZWF0aW9uLCBhbmQgb25nb2luZyBtYWludGVuYW5jZSBvZiBTZXJ2aWNlIEZ1bmN0aW9uIENo YWlucyAoU0ZDKSBpbg0KICBhIG5ldHdvcmsuICBJdCBpbmNsdWRlcyBhcmNoaXRlY3R1cmFsIGNv bmNlcHRzLCBwcmluY2lwbGVzLCBhbmQNCiAgY29tcG9uZW50cyB1c2VkIGluIHRoZSBjb25zdHJ1 Y3Rpb24gb2YgY29tcG9zaXRlIHNlcnZpY2VzIHRocm91Z2gNCiAgZGVwbG95bWVudCBvZiBTRkNz LiAgVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBwcm9wb3NlIHNvbHV0aW9ucywNCiAgcHJvdG9jb2xz LCBvciBleHRlbnNpb25zIHRvIGV4aXN0aW5nIHByb3RvY29scy4NCg0KDQoNCg0KUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Yg c3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvPi4NCg0KVGhlIElF VEYgU2VjcmV0YXJpYXQNCg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQoNCnNmYyBtYWlsaW5nIGxpc3QNCg0Kc2ZjQGlldGYub3JnPG1h aWx0bzpzZmNAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCg0KIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KVGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIG9ubHkg Zm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudChzKS5JdCBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgb3IgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24uDQpJZiB5b3UgYXJlIG5vdCB0aGUgZGVzaWdu YXRlZCByZWNpcGllbnQsIHlvdSBtYXkgbm90IHJldmlldywgY29weSBvciBkaXN0cmlidXRlIHRo aXMgbWVzc2FnZS4NCklmIHlvdSBoYXZlIG1pc3Rha2VubHkgcmVjZWl2ZWQgdGhpcyBtZXNzYWdl LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkgYSByZXBseSBlLW1haWwgYW5kIGRlbGV0ZSB0 aGlzIG1lc3NhZ2UuIA0KVGhhbmsgeW91Lg0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIw0K --_000_A6B8F2A767638641889989BC1BA7047936014236LIONALLOTLOCAL_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAw IDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9z ZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxp YnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0x OjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0Fj ZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQt ZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm Ijt9DQpzcGFuLmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFu O30NCnAuSFRNTCwgbGkuSFRNTCwgZGl2LkhUTUwNCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE 6K6+5qC85byPIjsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJ bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uSFRNTENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8iOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCnAuYSwgbGkuYSwgZGl2LmENCgl7bXNvLXN0eWxlLW5hbWU65om55rOo5qGG 5paH5pysOw0KCW1zby1zdHlsZS1saW5rOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uQ2hhcg0KCXttc28tc3R5 bGUtbmFtZToi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk6U2ltU3VuO30N CnNwYW4uRW1haWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5E ZWFyIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgaGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnQ6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JZiB0aGVyZSBhcmUgbXVsdGlwbGUgY2hvaWNlcywgdGhl IFNGRiBuZWVkcyB0byBwcmVzZXJ2ZSB0aGUgcHJvcGVydHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHRoYXQgYWxsIHBh Y2tldHMgb2YgYSBnaXZlbiBmbG93IGFyZSBoYW5kbGVkIHRoZSBzYW1lIHdheSwgc2luY2UgdGhl PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyBTRiBtYXkgd2VsbCBiZSBzdGF0ZWZ1bC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+4oCcPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BIHNlcnZpY2UgbWF5IG5lZWQgYWRkaXRpb25hbCBsZXZl bHMgb2Yg4oCccGVyc2lzdGVuY3nigJ0gb24gdG9wIG9mIGEgZmxvdyAoZS5nLiDigJMgYWxsIGZs b3dzIHJlbGF0ZWQgdG8gdGhlIHNhbWUgc3Vic2NyaWJlciAvc2Vzc2lvbiBkdWUgdG8gZS5nLiBz ZWN1cml0eSByZWFzb25zLA0KIGFsbCBmbG93cyByZWxhdGVkIHRvIHRoZSBzYW1lIGFwcGxpY2F0 aW9uIGluc3RhbmNlKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYmVsaWV2ZSBpdCBzaG91bGQgYWxzbyBiZSByZWZs ZWN0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgZGlyPSJSVEwiIHN0eWxl PSJ0ZXh0LWFsaWduOnJpZ2h0O2RpcmVjdGlvbjpydGw7dW5pY29kZS1iaWRpOmVtYmVkIj4NCjxz cGFuIGRpcj0iTFRSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29UYWJsZUdyaWQiIGJvcmRl cj0iMSIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiBzdHlsZT0iYm9yZGVyLWNvbGxh cHNlOmNvbGxhcHNlO2JvcmRlcjpub25lIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB3aWR0aD0iNTkw IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjQ0Mi44cHQ7Ym9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0ZGQ0MwMCAyLjI1cHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9y OiMwMDRBOEUiPkFsbGEgR29sZG5lcjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjojMDA0 QThFIj5EaXJlY3RvciBvZiBNb2JpbGUgVGVjaG5vbG9naWVzIGFuZCBTdGFuZGFyZHM8bzpwPjwv bzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzAwNEE4RSI+QWxsb3QgQ29tbXVuaWNhdGlvbnM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtjb2xvcjojMDA0QThFIj5UZWwgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2NvbG9yOmdyYXkiPiYjNDM7OTcyIDkgNzYxOTI1MTwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjojMDA0QThFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xv cjojMDA0QThFIj5DZWxsIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xv cjpncmF5Ij4mIzQzOzk3MiA1NCAyNDkzOTg1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzAwNEE4 RSI+RmF4IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpncmF5Ij4m IzQzOzk3MiA5IDc0NDM2MjY8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29s b3I6IzAwNEE4RSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0i bWFpbHRvOmFnb2xkbmVyQGFsbG90LmNvbSI+YWdvbGRuZXJAYWxsb3QuY29tPC9hPjwvc3Bhbj48 L2I+PGI+PHU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzAwNEE4RSI+DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3U+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHA6Ly93 d3cuYWxsb3QuY29tLyI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDRBOEUiPnd3dy5hbGxvdC5j b208L3NwYW4+PC9iPjwvYT48L3NwYW4+PGI+PHU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Y29sb3I6IzAwNEE4RSI+PG86cD48L286cD48L3NwYW4+PC91PjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48dT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjQuMHB0O2NvbG9yOiMw MDRBOEUiPjxvOnA+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lIj4mbmJzcDs8L3Nw YW4+PC9vOnA+PC9zcGFuPjwvdT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzAwNEE4RSI+PGltZyBib3JkZXI9IjAi IHdpZHRoPSIyOTEiIGhlaWdodD0iNTUiIGlkPSJQaWN0dXJlX3gwMDIwXzEiIHNyYz0iY2lkOmlt YWdlMDAxLmpwZ0AwMUNGQzEzNy43RkE1MzgxMCIgYWx0PSIyOTFYNTVfc2lnbmF0dXJlICgyKSI+ PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjojMUY0OTdEIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgZGlyPSJSVEwiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0O2Rp cmVjdGlvbjpydGw7dW5pY29kZS1iaWRpOmVtYmVkIj4NCjxzcGFuIGRpcj0iTFRSIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+SG9uZ3l1IExpIChKdWxpbyk8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgQXVndXN0 IDI2LCAyMDE0IDM6NTggQU08YnI+DQo8Yj5Ubzo8L2I+IENhcmxvcyBQaWduYXRhcm8gKGNwaWdu YXRhKTsgUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pPGJyPg0KPGI+Q2M6PC9iPiBzZmNAaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzZmNdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZS0wMi50eHQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SGkgQ2Fy bG9zLDwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Rm9yIHRo ZSBuZXcgZGVmaW5pdGlvbiwgbm90IHN1cmUg4oCcZGVsaXZlcmluZyB0cmFmZmljIHRvIGEgY2xh c3NpZmllcuKAnSBpcyB0aGUgYmVzdCB3YXkgdG8gc2F5LiBJbiBjYXNlIHRoZSBjbGFzc2lmaWVy IGlzIGluc2lkZSB0aGUNCiBjdXJyZW50IFNGRiwgaXQgaXMgYmV0dGVyIHRvIHNheSB0aGUgU0ZG IHJlLS9jbGFzc2lmeSB0aGUgdHJhZmZpYyB0aGFuIGRlbGl2ZXIgaXQgdG8gYSBjbGFzc2lmaWVy LiBJbiBjYXNlIHRoZSBjbGFzc2lmaWVyIGlzIGluIHRoZSBuZXh0IFNGRiwgdGhlIGN1cnJlbnQg U0ZGIHdvdWxkIG9ubHkgZm9yd2FyZCB0aGUgdHJhZmZpYyB0byB0aGUgbmV4dCBTRkYsIHdpdGhv dXQga25vd2luZyBvciBjYXJpbmcgYWJvdXQgaWYgdGhlcmUgaXMgYSBjbGFzc2lmaWVyDQogdGhl cmUuPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5DaGVlcnMs PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkhvbmd5dTwv c3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+IHNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2Vz QGlldGYub3JnIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5DYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSk8YnI+DQo8Yj5TZW50OjwvYj4gVHVl c2RheSwgQXVndXN0IDI2LCAyMDE0IDM6MTUgQU08YnI+DQo8Yj5Ubzo8L2I+IFJlaW5hbGRvIFBl bm5vIChyZXBlbm5vKTxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9y ZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NmY10gRndkOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJl LTAyLnR4dDwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+UmVpbmFsZG8sIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+VGhhbmtzIGZvciB0aGUgY29tbWVudCwgZ29vZCBzZXQgb2YgcG9pbnRzLiBJdCBkb2VzIHNl ZW0gdGhhdCB0aGUgZGVmaW5pdGlvbiBpdHNlbGYgbWlnaHQgYmUgdW5uZWNlc3NhcmlseSBvdmVy bHkgcmVzdHJpY3RpdmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPldlIGNv dWxkIHNheSAmcXVvdDt6ZXJvIG9yIG1vcmUmcXVvdDsgb3Igd2UgY291bGQgc2F5ICZxdW90O3R5 cGljYWxseSBvbmUgb3IgbW9yZSZxdW90OywgYnV0IEkgdGhpbmsgaXQgaXMgYmV0dGVyIHRvIHNw ZWxsIG91dCB0aGUgZnVuY3Rpb24uIEhlcmUncyBvbmUgbW9yZSBjb21wcmVoZW5zaXZlIHByb3Bv c2FsOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5PbGQ6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7ICZuYnNwO1NlcnZp Y2UgRnVuY3Rpb24gRm9yd2FyZGVyIChTRkYpOiAmbmJzcDtBIHNlcnZpY2UgZnVuY3Rpb24gZm9y d2FyZGVyIGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcmVzcG9uc2libGUgZm9yIGRlbGl2ZXJpbmcgdHJhZmZp YyByZWNlaXZlZCBmcm9tIHRoZSBuZXR3b3JrIHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgb25lIG9yIG1vcmUg Y29ubmVjdGVkIHNlcnZpY2UgZnVuY3Rpb25zIGFjY29yZGluZyB0byBpbmZvcm1hdGlvbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IGNhcnJpZWQgaW4gdGhlIFNGQyBlbmNhcHN1bGF0aW9uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPk5ldzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDsgJm5ic3A7U2VydmljZSBGdW5jdGlv biBGb3J3YXJkZXIgKFNGRik6ICZuYnNwO0Egc2VydmljZSBmdW5jdGlvbiBmb3J3YXJkZXIgaXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyByZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZyB0cmFmZmljIHJlY2VpdmVk IGZyb20gdGhlIG5ldHdvcmsgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBvbmUgb3IgbW9yZSBjb25uZWN0ZWQg c2VydmljZSBmdW5jdGlvbnMgYWNjb3JkaW5nIHRvIGluZm9ybWF0aW9uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Y2FycmllZCBpbiB0aGUgU0ZDIGVuY2Fwc3VsYXRpb24sIGFzIHdlbGwgYXMgZm9yIGRlbGl2ZXJp bmcgdHJhZmZpYyB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGEgY2xhc3NpZmllciBvciBtYXBwaW5nIG91dCB0 cmFmZmljIHRvIGFub3RoZXIgU0ZGIChpbiB0aGUgc2FtZSBvcjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRpZmZl cmVudCB0eXBlIG9mIG92ZXJsYXkpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPldHLCBSZWluYWxkbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+VGhvdWdodHM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlRoYW5rcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Q2FybG9zLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPk9uIEF1ZyAyNSwgMjAxNCwgYXQgMTowNiBQTSwgUmVpbmFs ZG8gUGVubm8gJmx0OzxhIGhyZWY9Im1haWx0bzpyZXBlbm5vQGNpc2NvLmNvbSI+cmVwZW5ub0Bj aXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5BIGNvdXBsZSBvZiBwb2ludHMgYWJvdXQgU0ZG IGRlZmluaXRpb24uIFlvdSBtZW50aW9uICZxdW90O29uZSBvciBtb3JlIGNvbm5lY3RlZCBzZXJ2 aWNlIGZ1bmN0aW9ucyZxdW90Ow0KPGJyPg0KPGJyPg0KQnV0IGluIG91ciBpbXBsZW1lbnRhdGlv biB3ZSBoYXZlIHR3byB0eXBlcyBvZiBTRkZzIHRoYXQgZG8gbm90IGhhdmUgU0ZzOjxicj4NCjxi cj4NCi0gQSBTRkYgdGhhdCBtYXBzIGZyb20gb25lIG92ZXJsYXkgdG8gYW5vdGhlciwgc2F5LCBW WExBTiB0byBHUkU8YnI+DQotIEEgU0ZGIHRoYXQgb25seSBoYXMgYSBjbGFzc2lmaWVyIChubyBT RnMgaW4gaXRzZWxmKTxicj4NCjxicj4NCldoZXJlIHdvdWxkIHRoZXkgZml0IG9yIGhvdyB0byB0 byBtYWtlIHN1cmUgdGhlIGFyY2hpdGVjdHVyZSBjYW4gcHJlZGljdCB0aGVpciB1c2FnZT88YnI+ DQo8YnI+DQp0aGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+T24gOC8y My8xNCAxOjQ3IFBNLCBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgd3JvdGU6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+U0ZDLCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPlBsZWFzZSBmaW5kIGJlbG93IHRoZSBlbWFpbCBub3RpY2Ugb2YgYSBuZXcgcmV2aXNp b24gb2YmbmJzcDtkcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+RnVsbCBzZXQgb2YgZGlmZnMgZnJvbSAtMDAgKElFVEY5MCkg dG8gLTAyIChub3cpIGNhbiBiZSBzZWVuIGhlcmU6Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUtMDImYW1w O3VybDE9ZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUtMDAiPmh0dHA6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAyJmFtcDt1cmwx PWRyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAwPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj5XZSBzdGlsbCBleHBlY3QgZnVydGhlciBjaGFuZ2VzIHRvIHRoZSBk b2N1bWVudDsgYnV0IHdlIGFsc28gYmVsaWV2ZSB0aGF0IHRoaXMgcmV2aXNpb24gY2FwdHVyZXMg dGhlIGtleSBwb2ludHMgYW5kIGFkZHJlc3NlcyB0aGUga2V5IG9wZW4gaXRlbXMsIGFzIHBsYW5u ZWQgaW4gVG9yb250by48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+VGhlIGtl eSBvYmplY3RpdmUgYmVpbmcgdG8gY3JlYXRlIGEgc2luZ2xlIGRvY3VtZW50IGJhc2lzIGZvciB0 aGUgU0ZDIGFyY2hpdGVjdHVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ U0ZDIENoYWlycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+V2UgYmVsaWV2 ZSB0aGF0IHRoaXMgcmV2aXNpb24gZnVsZmlsbHMgdGhlIG5leHQgc3RlcHMgYWdyZWVkIGluIFRv cm9udG8gKDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9hZ2VuZGEvOTAvc2xpZGVzL3Ns aWRlcy05MC1zZmMtMy5wZGYiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9hZ2VuZGEvOTAvc2xpZGVz L3NsaWRlcy05MC1zZmMtMy5wZGY8L2E+KS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+VGhpcyByZXZpc2lvbiwgd2hpbGUgd2UgZXhwZWN0IGNoYW5nZXMsIGlzIG5v dyZuYnNwO2Nsb3NlIGVub3VnaCB0aGF0IHdlIHRoaW5rIGl0IG1ha2VzIHNlbnNlIGZvciB0aGUg V0cgdG8gdGFrZSBpdCBhcyB0aGUgYmFzaXMgZm9yIHRoZSBXRyBkb2N1bWVudCB0byBhZGRyZXNz IHRoZSBkZWxpdmVyYWJsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ZHJh ZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUtMDIgYWRkcmVzc2VkIHRoZSBrZXkgcG9pbnRzIC0t IGFuZCB3ZSBiZWxpZXZlIGlzIHJlYWR5IHRvIHN0YXJ0IGEgcG9sbCBmb3IgYWRvcHRpb24uIENh biB5b3UgcGxlYXNlIGluaXRpYXRlIHRoYXQgV0cgYWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtbWVy Z2VkLXNmYy1hcmNoaXRlY3R1cmUtMDI/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Q2FybG9zICZh bXA7IEpvZWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5CZWdpbiBmb3J3YXJkZWQgbWVz c2FnZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PGJyPg0KPGJyPg0KPGJy Pg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RnJvbToNCjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbHQ7PGEgaHJlZj0i bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn PC9hPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUt MDIudHh0PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RGF0ZToNCjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5BdWd1c3Qg MjIsIDIwMTQgYXQgMTI6NTk6MTMgUE0gRURUPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj5UbzoNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj5Kb2VsIEhhbHBlcm4gJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4u Y29tIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDssIENhcmxvcyBQaWduYXRhcm8gJmx0Ozxh IGhyZWY9Im1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20iPmNwaWduYXRhQGNpc2NvLmNvbTwvYT4m Z3Q7LCAmcXVvdDtKb2VsIE0uIEhhbHBlcm4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpt aEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OywgQ2FybG9zIFBp Z25hdGFybyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbSI+Y3BpZ25hdGFA Y2lzY28uY29tPC9hPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij48YnI+DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1 cmUtMDIudHh0PGJyPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBDYXJsb3Mg UGlnbmF0YXJvIGFuZCBwb3N0ZWQgdG8gdGhlPGJyPg0KSUVURiByZXBvc2l0b3J5Ljxicj4NCjxi cj4NCk5hbWU6PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4gPC9zcGFuPmRyYWZ0LW1lcmdl ZC1zZmMtYXJjaGl0ZWN0dXJlPGJyPg0KUmV2aXNpb246PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1z cGFuIj4gPC9zcGFuPjAyPGJyPg0KVGl0bGU6PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4g PC9zcGFuPlNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgKFNGQykgQXJjaGl0ZWN0dXJlPGJyPg0K RG9jdW1lbnQgZGF0ZTo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiA8L3NwYW4+MjAxNC0w OC0yMjxicj4NCkdyb3VwOjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+IDwvc3Bhbj5JbmRp dmlkdWFsIFN1Ym1pc3Npb248YnI+DQpQYWdlczo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4i PiA8L3NwYW4+MjY8YnI+DQpVUkw6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAyLnR4dCI+ aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbWVyZ2VkLXNmYy1hcmNo aXRlY3R1cmUtMDIudHh0PC9hPjxicj4NClN0YXR1czogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUvIj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZS88L2E+PGJyPg0K SHRtbGl6ZWQ6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAy Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVy ZS0wMjwvYT48YnI+DQpEaWZmOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZS0wMiI+aHR0cDovL3d3dy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUtMDI8L2E+PGJy Pg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7Jm5ic3A7VGhpcyBkb2N1bWVudCBkZXNjcmli ZXMgYW4gYXJjaGl0ZWN0dXJlIGZvciB0aGUgc3BlY2lmaWNhdGlvbiw8YnI+DQombmJzcDsmbmJz cDtjcmVhdGlvbiwgYW5kIG9uZ29pbmcgbWFpbnRlbmFuY2Ugb2YgU2VydmljZSBGdW5jdGlvbiBD aGFpbnMgKFNGQykgaW48YnI+DQombmJzcDsmbmJzcDthIG5ldHdvcmsuICZuYnNwO0l0IGluY2x1 ZGVzIGFyY2hpdGVjdHVyYWwgY29uY2VwdHMsIHByaW5jaXBsZXMsIGFuZDxicj4NCiZuYnNwOyZu YnNwO2NvbXBvbmVudHMgdXNlZCBpbiB0aGUgY29uc3RydWN0aW9uIG9mIGNvbXBvc2l0ZSBzZXJ2 aWNlcyB0aHJvdWdoPGJyPg0KJm5ic3A7Jm5ic3A7ZGVwbG95bWVudCBvZiBTRkNzLiAmbmJzcDtU aGlzIGRvY3VtZW50IGRvZXMgbm90IHByb3Bvc2Ugc29sdXRpb25zLDxicj4NCiZuYnNwOyZuYnNw O3Byb3RvY29scywgb3IgZXh0ZW5zaW9ucyB0byBleGlzdGluZyBwcm90b2NvbHMuPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxicj4NCnVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0cDov L3Rvb2xzLmlldGYub3JnLyI+DQp0b29scy5pZXRmLm9yZzwvYT4uPGJyPg0KPGJyPg0KVGhlIElF VEYgU2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+c2ZjIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm YyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCnNmYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KDQo8UD48Rk9OVCBj b2xvcj0jMDAwMDgwPjxGT05UIHNpemU9MT4NCjxIUj4NClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRl ZCBvbmx5IGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQocykuIEl0IG1heSBjb250YWluIA0K Y29uZmlkZW50aWFsIG9yIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLiBJZiB5b3UgYXJlIG5vdCB0 aGUgZGVzaWduYXRlZCANCnJlY2lwaWVudCwgeW91IG1heSBub3QgcmV2aWV3LCBjb3B5IG9yIGRp c3RyaWJ1dGUgdGhpcyBtZXNzYWdlLiBJZiB5b3UgaGF2ZSANCm1pc3Rha2VubHkgcmVjZWl2ZWQg dGhpcyBtZXNzYWdlLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkgYSByZXBseSBlLW1haWwg YW5kIA0KZGVsZXRlIHRoaXMgbWVzc2FnZS4gVGhhbmsgeW91LjwvRk9OVD4NCjxQPjwvUD48Rk9O VCBzaXplPTE+DQo8SFI+DQo8L0ZPTlQ+PC9GT05UPg0KPFA+PEZPTlQgc2l6ZT0xPjwvRk9OVD48 L1A+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A6B8F2A767638641889989BC1BA7047936014236LIONALLOTLOCAL_-- --_004_A6B8F2A767638641889989BC1BA7047936014236LIONALLOTLOCAL_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=29141; creation-date="Tue, 26 Aug 2014 11:12:53 GMT"; modification-date="Tue, 26 Aug 2014 11:12:53 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABkAAD/7gAOQWRvYmUA ZMAAAAAB/9sAhAABAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAgIC AgICAgICAgIDAwMDAwMDAwMDAQEBAQEBAQIBAQICAgECAgMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwP/wAARCAA3ASMDAREAAhEBAxEB/8QAyAAAAQQCAwEB AAAAAAAAAAAACAUGBwkECgACAwsBAQABBQADAQEAAAAAAAAAAAAIBAUGBwkAAQMCChAAAAcAAQMD AgMEBAkLBQAAAQIDBAUGBwgAERITFAkhFTEiFkFRMiNhQjUXcWJyMzQ3GDgKUqJzVHQlVTZWVxlj JGRlZhEAAgIBAwMCAwUDCAcFCAMAAQIDBAUREgYAEwchCDEiFEFhMiMVUTMWcaFCUmJyNAmBkUNT JFQXY3ODZDWx0ZKiRHQmNjcYOP/aAAwDAQACEQMRAD8A365KSYQ8e9lZV43j42ObLPHz52qRBs0a t0zKruF1lBAiaSSZREREfw6bsvlsZgcXYzeasRVcRUheWaaVgkcUcalnd2OgVVUEknpRUqWr9qOl SjeW3K4REUEszMdAoA9SSfQdBK63TYdsl38Hx0rreKq8e5OxkNQtaAJMyrkEoKfb0HSLpAFSFOBv blbPHQEMUyhW49yhnbd9yHnz3EZy1xz2oYqKhw2rKYZuQ5JNse8aamBJEkQEAhuyILVnYyPIlYkq CKh8bcC8d0Isl5YttPmZUDpjqx1YqfhvKlTodNN5kij1BCGUevWeXA+SLlIZB9yckkJsf5gM2EQ/ CCBX8fAUyTDMpku4dvo2KHb+r+zpyX2xe7W5H+q5HzFdiz/4uzDWm+k3faugswgrr9orKNP6H2FK fJ/iSF/pa3DoWx3w3vKne0/bqYn9f/EP8vSM70zkfx/USdbBEx2n52VRNN5daqkkhIRBFjEIVR+k VtH+1TSMfx7u0PRVOIF92Tpiu+Xfdt7YJkt+dqNXmfiveFlyuOVUsVQxAUyqI4NgUnb/AMTB25XK oLsZI6cIOH+JPKKmHgU8uG5WQSlSySY5SATohLPuJ01/KfcoBPYbozajbq9eq/HWeryKMpDSaXqN 3CXcpyHKPis2comAFWztsoAkUTOAGIYOwh1oBwXnXFvJPFqnMuGW47mAuJuSRfQgj0aORDo0csba rJGwDKw0I+HQ/Z3BZXjWUlw2ZiaHIQtoyn4EfYykejKw9VYehHTk6l3TR1zrnXOtd35KvnhpfF+0 WHC+McFX9c2euOXMRdLjOruV8vzqcbnOg8rxUIh2ykLxbopYhk3qCDpoxjnHZJVddwm5aIlH4m9t +Q5hTi5Hy+SWjgJQGiiQAWJ0PqH1YFYYmHqhKs7r8wVVKOw1+UfcFR4pbl4/xWOO7nIiVlkckwQu PQpopBlkX4MAyqh9CzMGRdc+wfLd8pGsSzyVj+Q2lIkTcKOAiszqsBXomLTMIHI1BvVKwgso2QIU AKLtVdQS/UxzCIiJT1fCXh3CwrDLi6hJGm6xI7s336ySEan+yAP2AdDPZ8x+WcxM0seStAa67YI0 RV+7SNAdB/aJP7Sep1wD59ufmK2Fu31Weg+QVTbuUkpeqaNXomtWZFskXwcIw90qURESsdJqdg/m ybaXSIICPoCIj3jnJvbT405BVLYaOTGXSDtkgdpIyT8C0UjMrL90bRE/1upBx33EeRMFZC5eSPJU wfmjmRUcD7Qssaqyt97rIB/V63D+EXOzCuemWm0bHJZw3lIRVnHaFnU8Ldvc89nHiKqrZnNM0FVU XcTKlbLHjpNuY7N8RFQpTEcIOW6AK+QvHPI/G2Y/Ss8gMMgLQTpqYp0BAJQkAhl1AeNtGQkEgqyM xqcD8gcf8hYn9TwjkSxkLNC+glhcjUBgPQq2h2OuquAR6MrKpndQLqcdc651zqB9r3quY60YsTM3 Nmu894J1unRYHUkH6iypm7ddyCCThdBqs5KKaQETUWcKFMVMggRQ6Y0e4f3NcU8C0q+NNebMeRsn oKGKratNMXYxo8mxXeOJpAY4wqPLPIGSGNgkzxWZ478Y5bn08lkSJT45W1Ni1JoEQAbmVdSoZguj NqyqikF2BZFeE2dP5g6eBZayX+HxuJeACiFcgmXu5pogcAUSFYzNYqzZYxD9jEVklTkMHYxSj9AH ilwL35eY1Ga5bymhwHC2NGSjSi7lqJD6rvMTB0YqdGSS+7owIZFIK9WJPnvAvDSaOIxc/IL0fo08 z7YWYeh03ghhqPQrXUEHUEj169nWV8tKR3kaXtbHQiNwBY9fuLEzVxJeP4tUnkirNN0/UAR+vrtP +kD8eva34U98PjkHK+P/ACJBykRfMaWUi7bzgf7JZJ2tIpb19e/W/wC8U+vXnDzXwdyP/hOQ8dkx Rf0E9V9yx/2isYiY6f3JP7p+HUg43yLSvM45zu/QDjP9VjAOVzXn5FUGst6SRllFYgXJzqlOLcgr FRE6xVEA9RFZYpVPTtLwF7rovI3IpfFXlDFy8X81VAQ9KYMkVrYu9mq9wlg2wGVYS0geD86CedBI Y4tz/wATycbxycr4xaXKcJm02zoQWi1OgEu0AabiELaKVf5JEjJXcTvRjdU51zrnXOmHo+kVTK6w 7tdufe0YNx9Fs3SAij+TemIdRKPjkDnTKs5UImYwiYxU00ymOoYpCmMFZ+WvLnCvCvDpua85s9nG xnZHGgDT2ZiCUgroSoeRgpPqyoiK0kjpGrMJNxLiOb5rmUwmCi32m9WY6hI01ALyMAdFBIHoCzEh VDMQCJjCy8q94IWYpqcRitAddzxchNNzObBMMj9vTcpILs1pBRNVJQDpLEJHJHDt4GOH5xB7F8u9 6/uXQZ7ga0fHnjCY615rSdy7ahPwkVXieZgykPHKkdKJ102PIPnN42sP4T8Zt9ByAz8i5QnpJHE2 2CJx8VLBggII0ZCZ2H9IKfl6V1cH5LRRCvq/yYeyMqH5jtLFFPjRJj/tKQFZCcTIT/Kan/wdPcvt n93uEjGR4z5gs281pqYr1ab6bd92+e4oX+Wu3SFPJniC6xrZTh8cVL7GglTu6ffokJJ/kkH8vXWu 8iNAzeyR9H5K1hGCGUVFvCaNDFKetyRiAUBO7O3D2hv4gMqZIrdVsUxRUbATyVL3xT3VeUfEnLKv jr3d4ePHC4+ypnqgBoTkaAmXZrHpqQZGjEMkAZDLTWMtKveW8U8X5diJeSeIbjWeyu6ahL6WI9fs UN833KGLrIQdsxbRCa6aiayZFUjkVSVIVRJVMxTpqJnKBiHIcoiU5DlEBAQHsIdaGxSxTxLPAyvC 6hlZSCrKRqCCPQgj1BHoR6jod3Ro2KOCrqdCD6EEfEEfYR1369OvnrGevWkazdyEg6QZMGDZd49e OlSINWjRskZZw5cLqmKmiggiQTHMYQKUoCI/TpHkMhQxNCfK5SaKvjK0LyyyyMEjiijUu8kjsQqI igszMQFAJJ0HXtXrz27CVaqNJZlcIiKCzMzHRVUD1JJIAA9SfToL3m3avssu/guPUG3jq0wWFo/0 uytgTQ9X8vc8c2eJLN0C+BwOVMyDt4ZMxTmRR/DrO3Je5Tzh7guQW+K+03FxV+KVJe1Y5DkE2RK/ pqYUlV0X0IcRGC1aaNkkeCvqR0RNbxrwfx/j4sr5ZtO+VmXfHj651cj+2UIJ9QQW3xRBgVDyfHrN DB+Qjovv33JKYQlh/OLNiyfhEAp+PgAJSDBD0vL/APCAO39Xpevtk921xP1TI+YLcWdPzdmGvP8A S7v2arYgTbr/AOUA0/ofZ14Hyb4jhb6Wtw+J6Pw3vJH3dP2+sbnX/wAb/T0lOdF5C4Oqi41eNZab QBWIk6ttbRRRlooqpiFIZcEm0akAEE/iBXbdMiyggQroBEAFkueYPdZ7YZ47PnulW5f4sMirJlsc qrYrbyAplAjrhdCdoFqBElkKxrdDEArYeHeKfJ8bR8BnlxHKgpK1LJJjl01J26tJrrpr+VIWVQWM JHRg1W0wN1gI2z1mRRlIWVQ9dm7R8g79jCmqiskcCqtnTZYhk1UjgVRNQolMACAh1oDwrmvGfIfG KnMeH247vHr0e+KVNf2kMjqdGSSNgUkjcB43VlYAgjofs1hcnx7JzYfMRNBkIG2sp/1ggj0ZWGhV gSGUggkHpwdSnpr651zrnQiaVyRlv1YrleGVn+8LQkxUSk3g9zVyuCkoCDgz1yVdqgcWaw+Cyqq6 LZBXsn3VUA6RQV8ue7XOnm7+F/bdh/4p8ooWWxMfWhQKnbJ3XDxoxiY7JZJJYq8MpWMtNKJIUvbi HiOj+hrzXyTc/SuKnQxr/t59RquxdGI3j1RVR5HX5tEQq5b7bGOU1oD39x5ChV3KoeqSKp8asdFo ZT8/tlnDNWtt1QRMPj3BM/cA/iH8eopW9vnvR5mgyXPPKn6Lcf5hXxcDlI9fURs0LUEOz8J0STXT 0c/EusvkHwthj9LgOK/Wwj0MlqQAtp6bgriww1+Pqw/kHWE8i+YWREGXZWKH3KuNB8nkIoxOhZva JiBlFmyKgFkXboxREClReuTgP19BT8OkF/C+/PwShzuPy1DyPxOD1lptCUyBjX1Z41IE8jkahVit 2GB0P08vw6UV7vgXnbfQWKljjeWf8EwcNX3H4BiPkVftJeGMfZ3F+PRCY3ttT2iEWkIMVY6YjTAj PVp+cv3KIceRkxEfypi5ZHVIYpFQIQfIolUImoAkAp/AXuJ4R7gePSZLjvcp8gpkLdx85H1FVzqN fgvchZgwSUKp1BWRIpA0Yqvn/jrOePsitXJbZsfMNYbCfu5V+P37XAIJXUjQgqzqQxmTq/eoB0E3 Jd9MaTf8643wD1xHNrScLRe37UwFVb1mOVXVIRMxjgmc6JY9ZUEzgIC6M0MH8IgOd/u8yOd8ueT+ Ke0zjNiWrSzJGRzE0foyUIGdlUEnaSggmlEbghrH0TD1XQkT4frUOI8Xy3lvKRrLNSH09NG+DWJA ASfTXQ70UsD+7E4+30iHadT0XP4YYfIftub5hn98c5AghFx7Z5YH07H1llZFn8gtJsnjGPinSTs3 tgJ5PHi3qOF1DAoUAor3D+Z/LHi7jhwvgw1eJeH+M8lk4yiwQJJenuQUYrzzTPZhliiryiRjAUJt WZBPZsyOZFVJ5484VxPlGQ+v533svzLKYxcoTI7JAkL2HrhEEbq7yKVHc10iiXbFGo2kkXh5CbsJ /U/vYt3fv37AeJAn49+3phFeHb+jt0GX/wDa33J9zufxpmt396DT/wCHsbf9GmnVzf8ASvxrt2/o dDT+SXX/AF9zXopeP266zOKF/X0nHXuiTl4reWvWk1HMGk2hK2+Ofrt3UYqxYN2E3GJIpFLJM3JD KFbn9UhgKVQpzS9rfuS83cjIPlK3W5J44yfI6HHnjtQQR2lsZSGZkeBooY4bVdETS9WnV3ELCWMq olD0t5S8a8Hxq/8A4vDNjOS1sbPkUaKR2hMdWRAyyB3Z4ZCSTBLGQpcbGBJUrImdMz8fOR7/ACRm soTNtVj17PTGSyxzpQcu3I4FWORUWObxIgLFRoUPqqqiqzKYwikHe1fFVKX2u+7S14QpSOPEnNqr 5DFxMxKU7SB9YVZidNvZkrAesksb0BI7NF6xTlk6+U/EsXOp1B5dhJRXtuAAZomK6SEAfFt6yH4K rLYIAD+h39aV9DR1Vx8wnLyc4ccJ7vc6RJKRGoaLLR2Q5rLNznI7gZ+1spR7K2ZkdL86EjXKhCyT pkt/AlIkbibuH5TXF4L4PX535Br0MggfD1UazOp+DpGVCxn9qvK6K4+JQvp+0VN5p5nY4TwSe9QY plrLrXgYfFHkDFnH7Ckauyn7H26/s61Zvhd+MyI516baNQ2pGRX485DIR6E7FoOnzFzqV+kCBJNa T94aHQdM4ONjPF7OLN103wJuWiCIkF2Zw3Mbz75cn8c4iHD8fKjlF5WKMQCK8K/KZdp1Bdm+SEMC mquza7AjCX4N8WQ+QMrLls6GPG6TAOoJBnmPzCLcNCEVfmlIIbRkVdN5Zd0w9nwrjBDwOV0KjsK4 0bNCqQuaZJT45v7NiUoJ+8NDxRY1g3FYqXcTqGBdfxE/5+wm6xj83+63hXjfkkOH5fPmM95BvR91 aNCFr98xan82RWkRY0Oh2h5FZlDFEKqSNQfH/h/J5nENLx6GhjOMV22d2ZlrVw3p8q7VJZvhuIUg Ejc2p6Fnkxw04a/JrntiZ2Cvx0Rp8c0O0iNTiIJvCa1ns4ZFQkYaa+jNxaa8VVESKxr5Vdg4IVUq CiDkhXCNw+2P3jYbk6SZbxdlJbFSlKqX8VaV4ZYCxb5J60mphdtrhLEO5C6MoeTZJH1W/mn28w2I hR5lSjhvTxk1b8G192gGjJKuglQajdDJodrA6IWR+tNPjLrGu/Ev8hnsbsZePHOb2tlm8V+PO5Xi rjl8pIMyy8hHIqCwUkm6sOdrY6+ooCPm4RaHUKCZlEzax8uwuD81+L+5j9G+qrCxTdtA0VhVO1WP rtO7dBMBroC4HqAes4uK5jM+HvJPbv6r9NYNe2g1KyQMRuKj03DbtmhJ01IQn0JHX0YUF0XKKLls sk4buEk10F0FCKorIqkBRJZFVMTEUSUIYBKYBEBAe4dZYMrIxVgQwOhB9CCPsPWmCsrKGUgqRqCP gR+0dYUzKs4GHlZyQP6TCGjX0q9U7gHptI9sq7cn7mEC/lRREfqIB0z8gzdDjOBu8jyrbMZj6k1m Zv6sUEbSyH10Hoik+vS3H0Z8nfgxtUbrViZI0H7Wdgqj/WR0GPFmqr36Ws3JO7pg+s1qmJaNpqTg BVb12vMVjRzlWM9T6EUcKImZJqAHmRm2AAN/OV8s/fZdwuz5PzOX93HkVBZ5fmr9mHFB9Xjo0Ym7 DtX3egZirU43A3pWrkBz9RMCQXmnNRcYo0/EXHD28PSrxSWyvo087juKJNPiFBErD4GWTUj8tNDg 60Z6HHqHdX3XOscYivbJkppZZA60dWIsCPbDJAQO/mkxBQhWjX97hydFuHYfz9/p1Q3mz3JeKfAm MNnnF8HNPGWgx9fSW9PoCdVh3ARRnQ/nTtFD6Eby3ymfcI8a8s59Z7eDrkUVYCSxJqkEev2F9Dub /s4w7n+rp69Dxr1ZmtcxKA3hGEJTNPqUf/eBWCRrhU8s2qKLgZlKDkpEyTczp+SGIV+n4pgRCQL4 pdinUMcV/PXD895w9vOO9yVWgmC8vYKuc1jjXdzYTGJIbUdaedkRpJRVC3o9IlENsGOEKssrSWtw PMY7gvkW140ksnIcNvS/RWDIoETWivaM0cerBUMpMDasS8B1fUqgUo8kvSelZxUrqUEiLTcUmo/T REPSSlGiijGUTSDyMJUQkGqnpgI+XpiHfoyfBnkqLy94lwXkNAiz5GkrTKn4VsxM0NlVGpIQTxyb AfXZt19eqX5zxp+IctvcdbcY605CE/ExsA8ZP37GXdp6a66dSN1bHUT6r5WauuQm/wBtmXUWW1UH B1m0RB1FR6g2jbLbF33pLKu1nnlHqNEF2CzxYDAYrhJuzSMU5O4Gy2sVL3uj9z2d5Dbo/rfjXxpJ HVpYxpkir38i8xR2keUGBo1eGW1Lrqs0dejBIkiMwYpopoPFni+jj4pzR5PyZWlmtBGaSvWCagKE +cMwdIk00KM9hwVbQgm7pdNahqhY5iCyxs+mY6KdOYyPLZySzly7KQASBKKjowi8kZITeYt010lF gIJCGAxgHouvIXkXzvgOB5bPcZ4TBYz9WlI9eH9SFp3kGgUirXrCSxs17hgjmjklCGONw7Keqi45 xvgWR5BTx+UzjxY6adVkk+mMSqpPrrLJIVj1/DvZGVCdzAgHoQIzkzyIzgIew7Rnx3dJsr1Zm0VC FLVZxmuiHkKTZA7tdJNVVLyUQbSJEFHhEzCkt9B6AfD+8z3YeIvoOWe4niUknjfL2Hiif6UY+5E6 aEoiFyFYpvkhgvRxPbWNjDOFVmBB3fC/iLmP1GJ8cZYR8lpRh2HeNqB1P2swRSQDoryVy6xFhvj9 R1Otg2TjRulcDPZq3NBPbVGkfHMJKNlouYjJ92oVGIdMHLuPK1ZTLJ+qX0lAVFMT/kMJkzGKYneQ +4n2fe5fiv8A0szWehabONHBBBPWtQWq9yQ7K0kUkkHaisxSsNj9wxE6o5eF3VqsxvjfzL40yp5X j8fJsoK8kkkckUsUkCjWVXVZNzxOgO4bQ2nzAKygjF4mWqfQjrnjNxcGcWXIZw8Kg4MBuzqvKKLE jjImMJjHboih6iPceybVygmUOxOvH2P8z5NUxXIPb/z2VpeWcEyJqxudfzKLM6wbCdSyIULREnRa 89eJQFj9OeccLjJbeP8AIOAUJiM9WEzL/VnABk1/Yx12t/Wkjkc+rdF/0eHVDdBxybkpi5WXOuP9 edKs1L29LM2t0kQTHRrMeuoKYeInKRw2KZg7dqpiJRMZikUDdjmAc+vefm+Q8/5ZxL2scQnkr2uV WhZyUqDVo8dA7HXTUB0UQWrMiaqS9OFA2kjAkH4XpY7AYrLeU8wiyRYqIx1kJ9GsOAP2EqTviiVv UATOdNVB6Kir1iEpsBGVmusUo6HiWxGrRskAd+xfqouup283DtyqIqLKm7nVUMJjCIiPRtcH4Txn xzxWlwvh9VKfHsfCI4o1+71Z3b4ySyMTJLK2rySMzuSzE9UlnM3k+R5WfNZiVpsjYcs7H+ZVHwVF Gioo9FUBQAB0v9Svpp68HTVs+bOGT1ug8Zu0FWrto6RTcNnTZdMyS7dwgqU6SyCyRhKchgEpiiIC HbpLeo0snSmxuShisY6xE0csUqLJHJG6lXjkRgVdHUlWVgVZSQQQevWCeerOlms7R2Y2DI6kqysp 1VlYaEMCAQQdQfUdBTlzdbDuQE5jiSyxqLoTBa20tuuoop9vkkUF1l2yZziYO/tY1y2UExjKKlaN zGHyEQHOTwfUse2r3TZT27wySN4z5PVbKYdJGZuxKEdniVm1/ClexXYszPIlam7HcxBI7nMsfkvx ZV8iuqjk2MlFW4VAHcUlQHIH7WkjkAACqZJgBoBobvWkvQ2dDxyf0t/mOUyb+DOoSzWJ41qtcOiY SuEZCVIuZV03EpiqJuUWLdUEFA+ibkyQj3D6CKvvI8vZPw/4TuZLjjMnL8tYjxtFkJ3pNZDlpU2k MHjhjk7Tj8E7QsQR6G1fDfEKvMebQ1ckAcPUjazOCNVKREaK32FS7LvU/ijDgft6bVNjM94iY+2k Lg7IhMSajNe0SLVt72btFteIGOSGiUEhMs7bRpAOi0SAxUUUEzrHEvkqoMT4BhvFnsX8EQ5PnU6x Zy40T5CZEEtvIZKVCwqV1U6yJAN8ddAyxRxJJYkKGSeQvHILnKvO3PXq4GMtQhDLXRm2Q16ytp3Z SfRWkOjStoXZ2WNQ21FGbm/LbJ9GkncMVeVqMm3ZO5JFG3N2ce2fsI9Azl+qzkWr58wFZk2IZRRF RRNX0wExQMUphKu8R++bwh5Zys+CWW7gstFBLOiZNIYEmhgQyTNFNHNNFuijDSPG7o+xWdFdVcqn 5d4L5xxKmmQKwX6byLGTVZnZHc7UDRsiPo7EKrKpXcQpIJALYac48Uc2AsSf9UtIdRyDZK4O4UqV fMBjgRN6sn7sZprFqd+4LqNCgUv5jgUvcwRKj/mM+3u7y0cdb9Zgwry9tcnJVVaR1ICyMvdNuOFt fSR6ykfF0RdSHif24eQ4cUby/RSXwm41Vl1n+GpQHb2mkH9RZTqfRST6dNLkBDkxnQabyVpCZEWE jLs4HS42OMQGk+xmAAEJgqZDlbqu5JukKCin1IZyDVwICdMxjQX3Q4FfAPlDj/u58dIExtm9HTz1 evt7d2C16iyFBCNJPGrRu/qhsLTslTKjyM++Lr7eQeLZDxDyMlrUUDTY+STXdA8X4otSNwWNjvUf ERmeIEKwANv9QQ3/AIi2/sf9Qf5wP7G/8R/7N/jdaIfxRx//AJuH/AfW/i/+k/3/AP3f9rodP0vI f7p/8R2Ph/tf93/e+7oQYP0i85bl9z/zx8ta/pv1P+SCNU+4e37/AL+y/ft/jf09Afxrtr/mQ8h/ V9e43DIvoN3w/Bju9s+/0n+H9v7+r4yQc+27Hmn+7Gab6jT9utnZu/8Ak/m6cnIrjkjpUNZJ+nun 8dd3beMerQpJErasXWQrpTEiRnWK6Z0E55tGqKtWb8h0DkA5CLmOiUAJMvdf7UIPMHHcryLg09mp 5BlSCZqqzLHQy09Iba5uROpX6yOuZK9S2skJQOsc7NAPkafE/lmTiGQqYvPJFLxxHkQSmPdYqJP6 y9lwQxhaQLJLCQ4JDNGFkJLVGKQc6lNjWFYKYTtASJIf9MmYLffhl1AKZOLLGgArHeqkOBilDuBi CBwHw/N1hPNxblEHJP4Mmxt9eYfVCt9CYJPq/qGICwiDbvMjagqANGUhgdp16OpcljHx36ylmucN 2jL9RvHZ7Q+Mnc+AQEEE/YflI19OrZuN/HEKBA1uxXhxJu7girITzerKyCS1WpkzNNisFnrFg2TB F5awgkyNHD9VRb0yiok38ExEx9yfaP7UT4r4ti+SeQZrk3Nw81xcc0yNj8XasoIWlihjXbLkPpFS Ce1JJME+eKttjG9wd8t+Wv4oydvFccSFMCypC1kIRZtxRNvCO7HVK3eJlSFVTcQry7mACp3JEUB2 riqVDwGTC+vTqgT/AEgIoJCq+sJ/H8/tvVD9v5e4D/T0x+7k1z7hvCa1dv6wOTzFtPx/Td/G7t2n rs3a/drr9/SvxGJB485s0uv0f6YgGv4e5ss6afZu0/0/Do0OtCOh761j/wDic28ybj/xmdoCp+nk diszeUABH0RmXVKWUghOH4CoDJpI+A/sDy/f0XXtEauOTZdG0+qNCMr+3YJRv/nKfzdCt7qlnPHM U66/TC64b9m4xHZ/MH/n6m//AIfK0Umu/GxZp1A6CKtV2fVZDQTIEAHJ5lrX6hItjKFHsK7paomj E0u38fiUgfUO3VZe9nk9TgfI8hzXk7snH8bgBaJ+J7EAnd1Qfa7SLIqIPVnYKPVh1N/afjTnuG18 JiADk7GXeFh/2snaClj9gEZQlvgFGv2dF7mdqt9sPdNAJcIfJ2UnNqur1qUuxbSr986cgCsFntTb ypgTKxhY5EhjJonBwbun5iYhUUx/Op4X5z5B56/JPLEfIcdwPG3cm0ua5NbhjtTzSyDdSwOLjtHa IKddEZo4WFhtYi5eNa8R1T5pguP4FcbxNsdYz1mCsFpYyJ2ijRV9J79povXfNISAzgxjR9oDGRgk obAtVtpptr/XEBfmSxggbDdIaGcViVn6u8cpMjtbjAKNmKAyVfEhV2q5Cm9ZJFHyWUAoFJHYvcRL wD3Gce8gPyfE8qxLf8HkMxUpyY2zexkjrE0eWotHAhs0NqzVZ1Dd6KKuHsShAsS+Tx4md8b5HAjG W8VaUd+vTmmWzFBZRS4apOGdu3PqUlQkbGeTbGm7VtWv/iCjQo/JJePtQoi+DMsnCyekKQn+9DWS mQ9x6f5vV/TpmHbz/N6fj/V8ev2He2RbA8TVWm17TWrJj/ud0g6fd3A/w9Ndft16/P8Ae47sf9T7 Ai07n0tff/e2emv37Nnx+zT7Ot33jEZ6bjXx6NI+f3A2HZMZ/wCp3FT3o0KAF16gm/N5+v5d+/17 9Z58v7Y5ZlBF+6/UbOn8nefT+bo8uKbzxfGmX979BX1/l7Ka/wA/StvSThbGNNI2Kc6v6NmziVMB E3opNDquR7B9fEGxDiP9Hfoafc3Dase3zmMdMMZv4fuHQfHYsRaT/QIwxP3a9Wz4yeKPyDh2mICf qEI9f2lgF/8AmI0+/pu8Xl2avH7LjtTJ+kjWU0FxKIACbxq7doSJVP2FUI9SU8+/18u/fqM+zi3j rHth4dNj2T6ZMTsYjQASxyypOD+wiVX3a/bqT06+ZorCeUs0s4O9rhYfejKpj0+4oV0+7oe7hyk0 Gbu8s7xCpnu+ZZaU394j1s19f9TA7OZFc0G9S7vGyMQkgqq2ValWOv4HWOmZsBDHFznnvL8o8h8h Xb3t2wb8j8Q8OB/W5o0DC+JG2Oaso/NRK6pI9eWuJDJtksyRyVEUtaeB8L8Wx3HIIPI14Y3mOa/w KM2n0+0ajvIfkYykqsiyFQmqxq4mLBRSgMMvOxTLHQYeszaGc6BoaUeMhNzDmwWVtWVnIKSE1JPX Y+/lYVNuis1I8FQfFYSlKApFBUQn457bPJnnrklfyliMRkIPFnI+UJB3bdqS3kY6JkUS2p5XXuz1 0jSSL6pn17o2alQJWu7J+SeN8Bx8nFr9ys3LMXii+yGJYK7WAuiQxovyRylikhi2+q6k6OSguKsY RkXT54HJEUIeOrcoC6QgBUEYxpFr+qQQH6Aim1TEP8kOt5+WDD4bgWTFtY4sBUxFjevwRK8Vd9w0 +G1Y1I/kHQDYn6y7nq3aLNfluR7T9pkaQaH+Usf9fQ18IkXCWBQZliKESXmZxVl5gIALUF00B9Pv /UK6RVKPb+sA9CL/AJdUFyH2x4+S0G7UuRuNET8DH3FQlfu7iSD0/pBvt6t73GSRP5PsrGQXWvCH 0/rbSfX79pU/yEdFx0dHVFdABxesjqpZxrU41rchaXkZqNofWOPh1macyhHMa9HPActWrxVAZRyc qBiJNkzAqocexe4j26y59mvMMhwPxFznk1LD283ep8zyM16Cq8K20rw0oJe5FHMyfUudjpHXRhI7 khNSdOij8x4aDP8ALsFi57kNGCfC1kryShzC0jzum1mQHtKNwZpGG1R8dB69TBmHLHMNCavSyrsc /mo9vJSLqHti6bUpYWOMiJpUsuJE4rsZJwUTIGUK5IIG/IYpfMb58M++Xwv5Xgs18vY/hjkdRJ5p KuScRr9NDsJnW2VSsdQ/rCzrOpSQiN41ErQjm3gbm3Ep4zQj/VsbK8cazVVLEzSa/ldrUy/FSA4U xsCvzBjtEk6eNWtFEeRMjFM7xDWOKCR+yR79uMpL11AzNy/nakBAVNJycK1dJPGoICU6igJlTOU5 yCNs+aX4TzTxhYweVo1+S8fy9IWPo4J4zZtUEMUk93FgB/qbFSKWO3WWEhpXESRSLJJGTDuE/rmE 5THfpzyYzI05+33pEbtRWG3qkFrXTtxzMrQylwQqly6lVbSp6wYBosXcmsNnzBxobF4wZXOk2eIW YotpOvA8RVjH0m4cumjeNfNnZU0lwESgYwgoQPE3YuF3Kfan5Ww3kivgfEkEvKMTaqw5bE5Gq0Qj noGVTBNM8kkSQSo+2OUMy6to6fKyno8cT5X4he47JkeWSpiLUcr07laUOWjn2ESJGqq7SIybmQgH Qaq3qNSbOXKrOOYmxuEGxWaSmfVs0+0SUKsk1sh2FLM4bGWT7pLLoD6hROAiBvEwh+PWlfhea1b9 +/PrcEIrwvxXHm7ErBkjvtDiTJHuX5XdD3FLD0YhyCdT0MHNEjh8CYCKRzI4ytjsORoWrh7YVtD6 hW+U6H1GoB6N7rRrocug0lQFDmxWhfgIg8zNYIQTfgApt7D64JiP7vbuu4B+8es8uQA1v8x3BNlA Stjh8opk/AFYrpfb/ojs6/yn9vRD489324XxV+MeYTvf6Wg01/8Aii/1dSZpOwSme6hmNTdRkYWp X1ZVg5sLxR0RwzlCOCtStkRIcrVMgKPGgiZQBDsqIiIAXv1dfl3z3mvFfmXh3B71OmvBeTu0Ml6V pA8VkSCMRroRGq7pa2rSAjSRiSoUnqE8R4FS5Tw3M5yCaY53GKHWBApV4yu7cdRuJ0SXQL9qgepO nU/9FF1V3UAm2GRecgUMehIyOfxEfWVZm2y4quQkIh57ZZdBsiQhvanSEXccU3kHkAuTfUBL26F9 /PeWv+6SLwJxynUtYKrh2t5O0Wk79WXtu6RoAe2V1loq24ag2GGoKgG0BwKpB4tbnuRmlivS3BFW i0XZKu4KWJPzA/LORodNIx6aHXqMth7rcoOPjdl9JBNGUcOPEweX24BkDqAIfj4C3bOQ/cP16pLz 7rY97Xiqrjv/AFRK1qSTQ+v0+6YnX7tkdj+X1/YepvwHSPwlyuWx/hWliVf+80T+fVo/5ujL60N6 HjoKuWoty2vjgeT/ALBLqjL7qKn+j/WTrntvW7/l/Yft3/q+X7O/WeXvk7C838SyZbX+GhzSL6nX 8GnfobN/2aaCT4/0d/2a9EP4MEpwnLVp/wDqZwr9vT8X7ufdp/N/p06bXPesTcjUqNa2TZZzCVGZ ly2EyJROWNSnmjNowlnJCgJiNEXTYUDqj+VL3ICbsAiIRT/M04XyXNcH47zLFRyy8fwl60LuwaiJ bkcMcE8gHwjWSIxM59FaZAfxah39sWYx1TO5LCWXVMjerxGDX07hhZ2eJT9rFW3hfi3bOnqAOqvz FKcAAwAYvcDAAh3DuH1KYOsYmRJF0cAr6H/3HoywSp1Hoeu5Wzp+qjHsWa8lISaycfHxrVI7h3JP nhvRbMGyCYGUXXcqnAoFAB/HuP0AR6U1qF7LWosTi4JLOUtyLDDDGrPJNLKdkcSIoLMzsQoVQSde vgzQ1ka1ZkWGrCpd5GIVY0X1Z2Y+gCga6n/29W2bpBr1Xhw4rdicpuZmDqFAhzrLHTUOedYyldbA RsoAmBRRJdIxSGKIiYhe/wC/rcv3KcbscL9gUvEeVyrNn8bgcLVZmIYm5DYoR6RtqdxV1ZUYEkqu uvqegZ8bZKPNefly+JQpQs37soABAELxztqw+wEEEg/AnTpv+El+5b/cU8PwP/aX7v8Apv8AndRb ZmP2Sf8A+atPt/xH7P738/Tpup/2f/5K1+z93/7v5ulXkzGTWe3bPeR9aYuJEKcoWu3iObD/ADXl WfqrpgJQEhkk/UCRXR9Q34OTNf2AIg/e8DEZ/wAWeReLe7TiVeW0mBYUcvBHrukx8zOqkDTYu7vz QmR9ds709AQCVReHrmO5TxzK+JMxIsJyA79ORvgtlAD+3U6dtG2j4xif7SASHe6czd5420HPoOV0 9vKINlISJqyjAjx+o5MJBI6Wk3TRvFlYKAYrv1R9VuYhiimZQPDorbnl/HZLxhB5N8Y0LfLal2NG qV6BjEkrPqNJWlZRXELArZ7gMkDKyGIyDZ1VVfhtiDlT8W5TZgw0sLMJpbIcogX11URqzSFxoYtv yyAghwp3dAgu55ILbk33AOObor5tXjVklcGYizInZmBUv3I8wC4KhNFSWFIFAb+AIh4fh1mtYue7 Kf3Gxe4ceKZBkIsZ9AKX1MBUx6OvfNrdu+p2v29/Y07QCaaenRLxw+JI/G7+OP4sQ1ntfUGftSah /T8sRaadrUbiN+u/5vj1YFTrm8nqkay22rSuaOWYOxmYm1uosPtibFMFnD8JRm7VYLw/oiJyuDCl +UpvMhBAQ61B4Pz27yHhbcs5riLfFLNcSG1XyEkIEAiQPJMLCP2nrBSSJ2EX4X3Im3oXM/x+vjM4 MPg7sGYik29qWssn5hc6KnbdQ6y6+hQBvUjaza9CbmLpbkFyHktmQbqlzjM49eqUVy4ROmE1JrJr gvIkSVTKIlXJIqu+xvFVBP2XkUBOPiDnh+3Y90Xurt+fa8Ug8T8OqvjcQ7qVFqywcNMEYDXcs8tr 5tssKHHhlDMdt48xhj8W+KYfH0jKeW5iUWbiqQe1GCukeoJ/D21i9NVdvqNDoo1O7rSroaOq6PlR 4fO+a/DXRMrrbduvpVeWY6ZkxXAokK4vtPRfChCFXcKIotVbdX5CQhiLKKJpIKSBVVB8CGAbT8Nc 5Tx/zyrmbZIxMoNezpr6QykavoNSe06pKQASQhUepHVZ+XOFvzrhFnEVQDlIiJ6+unrLGDoup0A7 iF4wSQAXBPoD1pP8Duc9w4VT+k5HeWc4ljerSsHG6zXTMHf6mo9opL6QSj7FHQbw6CiDli7cmbzr Eqabx0g2RDuZRomka3f8xr2o8u94ftru8K8TZKjR8jQyQ26gsMqVMtBFLFZfFy2xr9KbDwQy1LTb oEmQxTbIbEkyDr7SfPGO8AeUEyHMq00vFpiYpwobu05tGjFlYj+PYrPHPH6OUO9Q8kKRPug8MI7F ttoda0dtqWb7BX2aBl6fWKraYefgquaQBN5IPLXDNnB1G9ydqCQHLN+iRdmCRSLk9QhCN8Rfb17C ud8Dx1C37r8LPDmsXv8A0zAWkDU6PdYPPcsxrurW7lpwvzq08IijiLPIywpU1Q5x7iONcqeb/pFe jejcCm1ejcCebaNI4UOolghiUn5SI33M3ypq5ljD5LeXfB/jpmsqvdrVVZLbGDJRTP8ANs3cw8ho MxLAgc8bH2ZnFHOFapjs6Piu/lPRTQTAwtAWcgVuqWXkb/LoxPu+wH6FiqFXjWYjGkGdFMIldRoG jkSMRG7GyaqkAYmNysgMahy1Hw+62t4Mme3kLzZFJAQ2OE3ckkJBIZdd4rtr695wFI1BWQ6L1qF8 XMi2n5Xee8aW/vpKxv75Z2V73e4olVTbVTKqsWIjJFJu5BFwDBNnW2LKuwRVAMAulWaZx8fM5dns zZ437e/DVTA4WWeWnh8bFQotaZXtW7CoQJ7JUKrzzy9y5aKBVBaXYNAo6zNw9PN+cfKs2Qvoqvfu NZtdsFYoK4YapGDuKIibYIFYtoe2pY+rdfRzbt27Rug1aoItmrZFJu2bN0iIt27dEhU0UEEUylTS RSTKBSlKAFKUAAA7dZdszOxdyS5OpJ9SSfiSftJ60mVVRQiABANAB6AAfAAfs66PWbaQZu2DxIq7 R82XZukT9/FZs5SOiukbt2HxUSOID/QPSHIUKmVoT4u+gko2YXikQ/Bo5FKOp+5lJB/l6UV7EtWw lquxWeN1dSPiGUgg/wCggHqt2oshoyuh8QtFskvT4a5LP3uYX1i5KxFy2m1hMMSo5V8WopTKyAmF uIlTcLHeMhOBjJeWS3AaQ8bWOUexXy1lr2DwGdllm4/mIpBCJYrT6/StIdqbLZQ7oCVSaVr9AzB5 IdS4ztj+JExXnfidSC/kMeqJkaTrv2tCP3oUatrEDpvALIogsBdA+h3ZnnFZymnRVLqrUEI+OT83 Dk5S+9l5NUpPfTEkqUA9d8+UIAmH+EhAKmQCpkIUulPiHxPxHwpwKl4/4ZD28ZVXWSRgO7asMB3b U7D8U0pA1/oogSKMLFHGijRzDluY5vn5+Q5t91qU6Ko/BFGNdkUY+xEB9PtJJdiXZiX0mkmimRJF MiSSZSkTSTIUiaZCh2KQhCgBSlKAdgAA7B1ZEUMVeJYIFVIUACqoAVQPQAAegA+wD06jTu8jF5CW cnUknUk/tJPx6DXlDpi8qghx9zo33nRNDOhEzKLBQDhW626H1H4STggmIzdy7NM5BIf6oMBWcKeB ATMcAveV5fs5mrF7XfFB/UPKnKnStaSFgRQoyfNMLDjVY5LMQZXRx+TSNizN2k7LOQHhnh8VKRvK XLB9PxTFAyRFxp9RYX0TtqfV1icggj8c3biTcxcKTmf09ln9KrVNjz+q3r8U3Yiv4+AunQAKr56J O4+mL18qoqJQ+hRP2D8OjD8W8Bx3i7x3h/H+LbfUxVJId+mnck9Wml0/o92ZpJCvwXfoPQdU5ynP 2OUciucgtDSW1Oz7fjtX4Imv27ECrr9umvTx6n3TB0BKUqnxr5HWEZ4SsMr3NVOSbzRyelHQNsTc KHEXi3iCLVoR5ILIrj+UiSDlqocwEIfxzKgzMXtF92WVPJj9N4X8kOtiO2Rtgp5IOzHuv+CKNZZ5 YpdAqRw2ak0jrHE+hOPSfy94lqjGfm8142pjMQ9ZJqxUD5R8WYqiunxLPHMigsy6q+08OIrRJuSu dMsYQVhn5E0pNs5xNSXrsgsdoggRwxBuKbyJXEyHmYxRcJnE4iBC9g7uHuO/y+MF5e5Ha8h8Ay/6 byvJWGntRW1+oozs0aqHiMYE1diylnOs6vvIVY1UA+fjf3EXuI4yHjnI6f1WIqw9uF4CIrEYDMxV 92qSr82gB7bLoNWOvoq55j2x1qrVeqPpeCBxUn5nkVaX8q+mVq89M9WHvUI5BhHuXdSVrDk8W4ip B039Q4+omZIhSlM+eJ/b/wCf+G8NwfCMnfxn1GBtiWtkZrU9p6MveYE4uBIIZJMZJjXfHWMbesQ7 5GM0LQRIqMh5d5C8eZrOXs7Vr2uzfi2S1kiSEWE2D/FyM8ipaFlRZS1BHJtA2OrsSRK8ovn/AB1o 8/cphUh3ax1ncpImSbJTdvsT9dy8QiYtoiVNu3F9IOFPbsm5CNWpDHUEClKqr1euVk8Xe0/xxk+e 511fISF5bNgrGlzKXppJZ1rV40Cxx92eSQwVIFStWRpJWCos03UAqjlXlrklXj9BSK6ALFGCxhq1 0VUMsjtqzbI1XuTSFpJCFUEkonUb8TahPhEW/YLmgKNr1+bPPgibyD2tf81VowqRTgUybdcXJgRD t2OzRbnD+LqqfZDwXk36JnfPPP4zHzPneQNxUOv5dHV3r7QfVEkMjdoeoNaOs6nRtBK/OGexZvUO B8fbdhMDWEOv9afQCTUj4sNoLfsleVT8Oi76OrqiehK5QVGebFqG1UtuK9myx8L2SappqHPIVYyp XLv1wREF1WsYoQ/rJl8f/s3Tk4mDwDoEfepwDlMEOB9xHjiLuc34Ra78sYDEz4/cJJQ+w72ihIcS ou3/AIWzbdmAQA3v4V5Binkv+O+SPtwmci7aMSPy7Gm1SuvoGfVdjHX82KJQPm6dkixzfldlaXou xKmqKbls4QFI83TbImgIGRdNxEAMdMFTEVTN2SdtzeaZgAyapZ1fqeIPfL4RRqs5WNyroy7TcxGQ VNDHLGSPmXcUkjbSOzAwkicBoZlYoJeX+DebsJU1YAqQdezbrk+jI37DoCrD5opBtcah0MWN6HzI hGhanFaTTZGGTIDRlaJMgqTbViUoJEBY7qBePTugS/rHF0oA/gt9AEKbqeM/f/xyiOEYTl3H7fH0 URQ5GwN1uOEDaN5kpSymTb/SY2XB+E/oCJjLybwBkZznLuIyEWQJ3PXjOkLP8ToFmRAuv2Dtgj4x /EdSfm2a1PjzWLHbbdZwkp+V/wC87reJk5wUcKeZ1isWBVTuHhyKO1zCBe6jp85OAiAj6SSdxeJv EnA/adwvL8959mha5JcH1GXzFskFzqWEMIYySsGlckKDJZu2GUkM3Zhih/LOW57yxmqeAwFIxY2H 8upThA0UaAb30CoNFA1OixwxggEDe7RthjaV2DVrLyGmWSzCvNG7ip5wydFAFRapAdq8fkHuYOyD c6xFDEMdIzt44IU3ZEQ6pr2x0c75883Zr3Z8kqyVOMRxPjMBBKBvECaxyTD4/hRpRIVLRtZtWo0f SAjqZ+T56HAeEUvEuNlWbJsws5B1PoZG0ZU/0kIVBAYRRRMw/M16NbrRvoceh+5NZm91HKZWKhin NZYJ03tFbKl/nlZSKIuBmyHYBEzlyxcLFQL3AoufT8hAAEQFz3g+H8h5l8KXcNgFZuW4yePI0Av4 nsVg4MSaepeWGSVYl1AM/a3EKCRaXh7mFfhnNoLuQIGIso1exr8BHIR8zf2VdVLn4iPfp6+nXthG uQu20BM74rQ1mjmhIO/Vt0RJQyT8W4t3DhRisQAWhJ9MDKoiJBTMUx0h7nTUAFHtq858d9xHjBXy Agbl1SAU81QlCkrNsKPI0LDRql1Q0keqmMhpICS8UgHn5M4LkPHfKCKxkGHmczUrC6jVN25VDg+k 0J0VwDuBCuPldSRk2rhMR05LPYn7ONUdvm6clSpV2ZvCNk3jgiS8tAvjgqtHIsPUFdZiPmmdIpwb +BwIkcP/AHDf5dsGRuDk3t9MFKaewosYqxIVqIJXAaxUlOrQrESZZarb1aPf9NsdY4JLi8ee4loY jjPIncmWONjHbjXdMxVSVimQaCQvpsSYaMGKmXcu51IbEeM9IxxNCXEv6mvh2xknlskUSgZp65fF w1rrDuojCMjlESCYomcqlEQUVMUfECo9uvtB8deA4Y82F/V/JDQ7ZclOoHb3DR0ow6slWMglSylp 5FZhJMUbYtVeRfMHI+fM1AH6PjIfVa0Z/Fp+Fp39DM/2gHSNTptQEamHd7nR3XS6px1pzj3kVETT ex6nNMjAq2i0osQ7RBXJCKJlexqa4qKh3EhXyjVAwgcVCloT3Nckb3I+XcJ7U+AymfDUsgl7kVuE 7o66Vzoa/cAZe7Ars0gOqfWSVKzssolVZ94xxv8A004fe8r59O3dnrtXx0T+jSGT/a7SQdkhUKv2 mFZpQCu0k3vssT/1Bt/Zf2X/ADYf2T/1D/s3+L1or/D2D/5WH/BfSfh/+m/3H/d/2ehz/Ub3+9f9 93vj/tf6/wDe+/rKfMWcmzdx0i1bvmD9sszesnaRF2rtq4TMku3cIKlMmsiskcSmKYBAQHsPSzJY 7H5jHz4nKwxWcZZieKaKVQ8cscilXjdGBVkdSVZSCCCQR14VrNinYS3Udo7UThkdSVZWU6qykeoI IBBHqD0E0hx+1XIpyQsfG21NyQsm4F3J5paFhcRSy5uwGFmq7VI3VU7ABSqmWZuiplADrr9Z3ZT2 u+a/BHIrXK/aPmohx25L3bGAyL767Ppp+U8rBGPwAkaWrZWNQr2Z+iKq+UuE87xsWJ8uUmOQhTbH kKw2ygf2goLAfaVCSxliSscfWT/fVyrakGPe8cGjiX/gB8ynXX2cVPwA4gkm/RKn3+vb3gh/jft6 VJ7iPerVT9Kv+JYpc5+EzRWpBV3ft0AmTbr/AOb00/penXifHfhOZvqq/LXSh8djwr3dP2epQ6/+ ED93SWvkPIXd3CBNysUdRaERdFyvQKeoideR9MxVSpvlknMmiuAD28TOnTkiZygINe/5gaLHgr3U e5W1EnuOytXjPjVZUkfDYplMk+07gsrrJOjD4aNZsWFjdQy1N3zBbFzzxX4ziZvG9SXJcmKlRdtA gR6+hKArGV+8RxxlgdO9p6dGdV6tA0uBjq1WY1CKhYtH0WjNuBhAO5hOqssqcTLOXThUwnVVUMZR RQwmMIiIj1oHwzhfGPHvGanEOH1IqPHqUeyKJNfTUkszMSWkkdiXkkcs8jks7FiT0PmazWT5Dk5c xmJmnyEzaszf6gAB6KqjQKqgKqgAAAdODqUdNfXOudc6o1+SX4Sck5qzUrsWVzrLE+Qj9MFJuTGN M7z3SnSSfgk5u0THlLIRViOBSENNMQVVOmA+5auz+B0yJ8Ue4PN8ArpgszG2Q4wp+Rd2k8A/ZEzf KyfE9p9AD+B0GoNB+T/BGG51O+bxEi0OSMPmbbrDOf2yqPVX+A7qakj8SOdCNaC/fBj8mNAl12cf hjO/MU3CzZtZM70ahP4x+Qg9iuW7ObsNctDZquX6lF1HtzdvoYpR+nRa433FeJMnAJJci1aQgExz wTKw+4lEeMkf2Xb7iehayPgLynjpikdBbEYJAeGaEqfvAZ0kAP8AaRfvHUy4F/w8/O3T5tiGts6X x3qBjN1ZGXs9mg7vZhZqKlKsEJUqDLTKDqSSSETAjISMUmPbsKoD9OmHkvug8cYiu36I1jKXvUKs cbwx6/ZvkmVSFP7USQ/d0+cd9t3kDKzr+srBjaXoWaR1lfT7dscLMC33O8Y+/rb24R8EsJ4F5cfO sciHDiUnFGUhoOiz/t3N00KbZIqpNnc08QSSRaRMWVyqWOjGxU2bEiyhilO4XcuFwd8heR+R+Scx +qZ5wIYwVhgTURQITqQgJJLNoC8jas5ABIVUVTN4H4/4/wCPcT+m4RCZpCDNM+hlmYDQFiPQKup2 IuipqToWZmYzuoD1OOudc651GGqZFS9hr4wNvj/VFH1FIuWa+mlLQ66gEBRVi4UTVIKS3pl9VFQp 0VfEomL5EIYtOeavBPj3z1xf+Gud1S7RlmrWotq2artpq0MhVhtfavcidXik2qWTekbpMuFc75Dw LKfqeBl2htBJE2pilUa6B1BB1Gp2spDLqQDozAjU0znltlhAj6DoNd0isNv5UdF3VI4yrVsQABFI rl4sg5TSRIPiUoyaxQAodilDsACHT8Ue+bwwn6X4y5TieXcQi+WCvllP1EaD8K75WR1VR8qqMhIo CjRFGg6t+flvgvmjfVcnxVvEZh/WSSoR22Y/E7UBUkn1J+nU6n1JPqfVevc1b6UY6Zs9Jy2KUD03 bmuEKrMqJHECnFm6QWnl0lSlERD012hu4fRQB+vXrY4t/mG+TUOK5BmOO8Lw7ekslABrTKfQ9qRG uOrgEkFJ6x1H7wH16848r7eOMH6vH08jmro9VWwdIgR8N6kQqQft3JKP7J6mvHMApmOIOXUcLiet kp6gzVwmP5sq9MucqrhNDzUXMybOFygdQPUUWWMACqqp4k8SI8B+2DgHgSvNfxZlyfObu428pa+a zKXYO6xgl+zG7je43vLIwUzTS7I9ld8/8ocg59IkFvZWwcOnaqxekaaDRS2gG9lHovoqqNdiJubW dOiS6rbrnXOudMq/59VtNrL2qW6PK/i3fZQhiiCbxg8TIciEhHOBKf27xAFDAA9jEOQxiKFOmc5D V55Q8W8L8w8QscJ51VFnDT/MpB2ywSqCEngk0PblQMwB0ZWVmjkR4ndGkPF+U5rh2YjzeClMV2P0 P2q6EglJF1G5G0HpqCCAylXVWAiMKLylwgv2vOJSG12gNu4RlfsqoNpiIaFH8rRqu5fs3LdJIg+K aaTl2j+XuRBIB8OgVxnjf3oe2tRhvE9zH868Yw+lelfYR2qsQP7uNpJoXQKpCokVixF8pKV4tdnV 72uS+FvJZ+t5bDYwXJ3/AHk9cbopW/rMFR1Yk+pZo4m9dGkf8XSsfZOV8wUI+E47sIeSP/LPIzk0 4UjUjCAAKxCOfsKJwII9wAXIh/h6eZPP/vczy/pXHPFVahlz8vfuWnNdSfQuBIaaaD4gfUMD8PX7 UK8A8IUD9VkeVy2Kg9RHDCokP3Er3iNfh+7/ANXXtV+N1xvNlY37klaUrfIR4irDUWNH06vEiYxT gk4RSIizMn+UAVRSIcXHiALOFk/JMVPDfaVz/wAk8ureTfdxmkzuSqndVw1c6Y6tqQ22RVCRFfQC WKJG7+xfqLU8e6JvPNeXMBxvDycY8RUmoVZfSW5J62Jfs1UkltftVmI2antxRto4NIpSkKUhClIQ hQKQhQApSlKHYpSlDsBSlAOwAH4daEoiRoI4wFjUAAAaAAegAA+AH2DoeiSxLMSWJ9T126+uuuuC ACAgIdwH6CA/UBAfxAQ66IBGh9QeufD1Hx6ES18ZZCJsLm64RcVcznnZvN7BdlTVR8YxhOYCoIpu fZNxOYT+3O3dtQN29NNIADoCueezPJYjlk3kj2zcgl4Zy2c6zVV3fps5JJI7arII49SW7EkFmuG0 7UUIA6vvA+Zq9vEpxvybj1zWIj/BKdPqU+z8RKlm0AG9ZIpCPxs5PSWD/m00D7f9kzeTEvZL7767 JP1P2e5FL7nH9h/b29kX/J/Z0xi//mRUdMT9Hw67t+X609pS32dzYLUA+/T6Rf7n2dLux7bp/wDi +9mYdfXs/MQP7OvakP3fvT/e6/WPHG/aFKsprkJoR7KyYrlctaTWzrM4QDiAiJXDhJvFpoB4mFNT 2zYq6hPp7kOu8V7QPJvlTO1uS+6/lj5unVkEkWIoloqSt6/iZI66J6ExuYIBM6en1Y66teYOM8Vo y4zxRiVoyyrte3OA85H3AtIW+G5Q8mxT/sujCjo5hEMGcXFs20fGx7dJoxYs0U27Vo1QICaLdugk UqaSSRCgAFAAAA60BxWKxmCxsGGwteGriasSxQwxIsccUaAKqIigKqqAAAAAOh/tW7N6zJcuyPLb lcs7uSzMzHUsxPqST8Seszpw6T9c651zoTNR42O5G0jqGNWY2caV3VUeqI+ScHYDrGBRx9wRTQdJ oneHDycAdu5buDh5mSKqYywg75m9o9/K80PmX2/5c8T8ufO0xXUU7zOQXM6KsgRpWAacNDPBYcB5 IBKzztePDPLsFTC/wZ5ApjLcQ9AgPrNAB6LsJKkhB6IQ8bxj5VcoFjDVQ1Pl3VShH2jDoa5qpgCa c1WpQzMrzt9PXXbsFJ5FIT/iIeLf/IDqFQ+avfXwlP0zmPjejyCdPRbWPsGMSj+u6QtcVSftASD+ 4vw6e5OFeCc2fqsNySxj0J1MViMNt+4M4hJ0/lf+8esR6nzE2AgxLplAYdVnnkm+fMngurKqzN9F EkXKbpzJt1jlN9PSRjzD27esX8RQ5BPft55jOEt1sZ454VYBWaaOUvkGiI0ZVdZZLCOdfl7cdInT QzqCdfeu3gPgTfXQyWuSZqP1RHTbXDfYSpVY2A/tPOB8e2eiMyDF6fjECeJrSCjh++FNWcsD4CHk 5hymBhAVTlAQbs0lFDikgURKQTmMYTqGOocsfBHt84H7f+NNhOJRvNlLO1rl6bQ2LUig6biPwRIS xihUlU3MzNJK8kr1NzzyFn/IOTF7LsErR6iGBNe3Ep/YP6TEABnPqdAAFRVVZc6vTqC9axnMflzy lrvM/mzlWOb3vTPUMwHia44g8d80x6C0yhaJK3umVyW1yE0xcuazbqIhwTMLxFy/n4f0QcuVETOC olQIXfA+EcOtcB4/ms9jca2HufqQyd6xaevNAsMrrWeuO+gZv6JVIZddqBgu7cRP5xzTl1XnWew+ DyORXLVP0442lBWSeGZpokayk57DlV/pBnmj03MVLbdosYcfJg+aADEcWRezZfknY/HEKKOgC2Yq 2d3nRLeOlgsenuFG8WnPm+3mjOyhytwFyDsxg9AasXxJG/5n6gVr/wAJnOamHUiMT9rsad0ats+f uegLfJsA+bqzm8qyJ+X9AGsfxUMJoJtB3DD3O/r2zou/5Nnqdvz7z+HpB4F8peV2hcPuSWybBSob R9Eyy/8AItHO67XLfEA9vq+aydnM2y0qsHRYhhBEjJaJTg4yUO3fLySChHiyZTD4HU+SeHcLxnOs TgcFYkqYu5Womd3ibSETrHrY0eZi+5WM0ke5BGQY1JHqE/jrl3MclwnKZzNwR2snTs3RCiSLrMYG k0r/ACRKE2soijk0cuCHYD4Fml+YJhY2NJSzvHoazWTSapwmhKjGuNRWRiEORnNpOyy9cyK0TkbQ ZQIaBzOoUuVkpqaBBVyqdBNsWPROqByrz4MkqSWGyl6SGpUmyzysK4LGjie2r2Y0aZd72JZY44ot QoBLmVgNCh/62x2o64xlFJbVqHFrGpsEKLuU3slaR1hbakEcUjyy6FjoFEak6h70H5Sl7ZeMIzCX xBOIveh3fnHlWptGGjJy0RmOkcIaswslhYQUiaoMjXyv3wko3Bo7EkYoxIsAmSX8R6bsn4cWljsl mIMiXxtWviLFcmDa1iDLSNGhde6ey8O1ty6yByPQrr0vxvl1rmQx2Jnx4TI2bGVr2AJ9ywT4qMO4 Ru2O8k25draRlAfUNp16cfvko1HklqGF59nnFP1IfScHyvkRpd4ebNDoRuQ0XQ5+81122+0vKfHy V4mWT+poFZJM/RO8ByqdUjYjbur1ybxPh+J4fI5PKZrSepkrFGCEVWLWZoEhcHcJWWFSsh3ltQu1 QC5f5frjflPL8py+PxuMw+sFrHV7s8psqFrRTPKhG0xhpWBjG0LoW3EkKF9RZ5n81eSWGc8Nno8P f3sJx8DiZ+m49daKglonLOQ+oUDXZ3E76aQWhHDtFWZu+WpwxBfLLRvuJJMiiJhOQSTLgPj/AIny LxvQyM9ZZOT/AK33GAZw1ilXmrJbh2hwDthsGU7AJNsZIb0OsQ51zzlPH/Il/HwWWj41+jbFJVCt e7PDZerNuKEjdLXEQ3kpucAr6jTJyL5kk4VpxzzO6xNdvM+lkvCJHdLpP6IyqmrWrQOUue16eeWL JMiYUx0x0KvZupMtHlucEkoozMsiBWzY4IiJ/jOeBzYfK5fHvLWrG7ljTiSAyVo4cfO6BLNlpQYH n2stZTHJu2fO43en1hfOIgTF4q+kViyKWKFuV5hHYkmvwo5etWEREyQblay2+Pbv+VDt9cnjl8mf IWkvbqly5otdkalJc0uYuLIaDAX2PVa5GOE57ZdGZZcnGx+ZV5O3RDReprRMTMu120jJoqndLplM gCSvxyvxHxfIR124RYlS8mAxdowPCwNn6yeOA2NzWH7TESCSWJQyRkBFOjbl++L+VuS0JJ15pXia k+dydUTJMNK30kLzivtECdxQYzHHKxV3BLsNV0LshPm9qL3HUdYm8LlYRzCcb7/u2kUlK7qSc5Sr JGchonjbk+UuDkpLQxZbV7jNt5D3ztBn9rh/Nf2rrt26RWPb1ejzpwtfIpIkmWhpwS9raksbUmvW bI/NPy1okZNilu5Lou9Ollfz7SkwYzNjHvG8eLmtzxd3c8TrdWjXrn8ofNYlcPvYL249W2P0+bp8 pWt56EhmctxVgbZymg+Umf8AF+Sx6l7qgSqSUrsONyevZZc4HTLLnEQ1CGlUGHsJFB8xaHjTFUXM qYABIW7H+HMJlNuXgzMkHDZMNNkFtS0z3FWraWtYievHOx3KW3oUdg/ooA+PThf8u5nGbsVNh45u Xx5eGg1aK2O2zWazWa8qTyQKNrAbHDopT1Yk/Dpl8YPkD1uw8stn4oy7NXWNje8qbQm6p0jMxVXq 3GfjVU8/oMhcp1K0saudfQzxeh2FzBwUeVAruWVSM5XdNUOwmcOYeMcJV4VQ5pAwpYFcNHpKqtJJ fvyTTLEnbMmkG6BFmmfdtjBCKjt8EPEvJOas8yvcOnU3M42Yk1iZljjo0Y4YTK/cEes22Z2iiTTd IQXZ0X4ldz8542XhQ0j55PMKDO0xCmTl1mLXpm6QGTEtL+Dk2LIuO41WUa9d7louxS0e6UkSomjm MMzZIlFZ6KivgnC/Gnjep5BdqxuWY75sJEsdem9ntq6k/VWpC8MUFVWATXe8rOTtj0GpmHkfyJb4 Ei2BUrSURA8rST20r9wowH01ZAkss1llJfTYkSoPmk1OgYnE7k/yJ2Pn3zDzmyx0J/s80vN+OV0z dgpYIgtgo6Om06QsMEr9raVBlLzz3SY8q7yYTdSSyNcdR6LZsZyR0KvTjzXiHFsD40wWVqNJ/FFi 3einbY2yY15VR/mMpVBA2ixFYwZ1dncIU06b+G8t5PnPI2bxdpY/4agq0pYBvXfEJ4mdPlEYZzOu rShnIgZFRSwfXqv6+84eezS7bVDkdwsc6pvym8ZcEzunwNtp6qNgq96ZOTy+CyVld5ogaEq9wjTM 3y1ndpOH7J44VbFJ4ICJrNxnjzxs+Px85WR0n4bfuTyvFKCkkJG24sYnO+SJtyCupVHVVcnVvSt8 jz/yKl+/AGjR4OX0acMSSRkPHKDuqM5gGyORdrmdgzqzFANF9Z5ufzRzFKqkRHz2E55Vdpb6dyuz e71W+8hmlUzONkeJRohGxx9S0s2dSD21WbS5aeaxNaZHhmZFpL1fXWTQIRRWN0PAUGQuvLWyVqbA Gnjp4pIaRksMuS3FGkg76iOOBUaSdxKxEe3apYkLIr3naehTSKzjq0OeFvIQSxzXRHArY7bvEc/Z YySTs6xwL2lBfXcwUAmfuZPMm5veBOI7bx6lpbL7Hyuu3HOiVmyysPFydmy+O2+YjhnHZomSQfwr iywUUV0wAwlVRTcH9ZEwiVJTqM8D4HQj8lZDj3KES5Uwte9NJGrMsdhqitsG5SHEbttf7CVG1h6k dSPnPOb0njqhn+NO9S1mbFKKN2VWkrraZd52sCpkRdyfaA3zKfQHqN7nyI2z42Y1/SNk2ymcko7X t5hKPxdte9abH57MZ1Tz01efvz/lFrELmCEOyjK67aJnjRZQ8hIPRegQBKmJE2ztQ4vx/wAsSrkM Dj7GJlo415shHTrtOs8vdCQrj6z2CxZwSJN8qIuzX1Opdrvcmz3iyJqGcvwZWK7kVioSW51haGPt F5jfsLAFCoQCm2N3bdp6DQLHhvmvtllpkTaMw4kjOro8MLLzLvrG6bWyo4U2tZvslwx3SKyxMGeT p7WunJ1VN1BOkganlW0giY7ZuJTk6dB7fqVS+9PL5vtqc/Hi4TFUM3dknqxWoJD+enbG2QrMp3CN kYB31B6bD55uWqKW8The4wwT5OYS2hF2kgsy1p4x+S/cO6MNEw2mRXUlF0I6TXfyhbZmGqc+9Svd MjbRxzyfKuHdqxqimutcrs1A2TkixaNs/Zy0opTEVkY/QBl15O0O3j18FUShwTZIPwXEevVPD/H8 xhuM4bG2Hh5Vdu5SO1N2ndHjokmYqvdILQ7RHXVUT6gy6yNFt68n8t57E5jkeXyECTcYp08bJWi7 qIyPeAEIZu0CFm3GSdmZ/pxFpGsm7p9Rny96NcIrOIHJOLlU2rXb5yB2XjqhCULkbBJ5lMz2X0Cu 6PE6Fn2oTtDj2lrze11efO5Mu7aRTpl7Bwl6aynpAo3TeDsVQmt2c3mJsfg62Mq3i81F/qESxM8D QT10mYxzxyIF0VpFbep1UbtHCLzXlLsNWthcRDfzVjJWaQWG6nYZ68KTrNDYeFRJBJG5bVljZdjD Rjt1MDmJzVvXHW0ZZmGY4tFa5q2iZ9sesP4iwaQTOarWqLhdUZ2e3iaxEqtteSljnF3ycfENiMk2 5lxMq5XQSJ3NBuCeP8dymnczGXyD0cLVtVawZIO/JJNckMcXydyILGgBeVi5bTQIrMfSbc355kOM W6eJxNBLuYtVrNgq8/YjSGpGJJPn7chZ3JCRqFA11Lsqj1ErCOVG+coPkhyZ9COJup8U5ngpSOSF YzxtfoRoMghp55+C/VOl1xGkSTyw2WLuorwacQ2mm7NknFtZYjlQVlWSs25Jw3jXD/FN2OwI5+aR 8jmoyTmFztNfY/bgcyqEjaLSYytEzOZHgKDasghvHuX8j5b5RpSVzJDw+Tj0V2OETINRPvTuToIm LususQjWUKgjSYOdxjIscqudXOqkaT8ptbgJNlXarx40HgzE5X+np+mupyjRmtWSutft8KEzmyCd kcbvVHjiRlRl3ahKk8ArJsZ0kYXJJjwzxz45yGJ4bbso0tzKVcu1jekoSZq0bnc+yc9sU5AqR9pQ bK6yOEb5DD+YeQvIVDKcvq1nWKnjLOJWvseIvEth0G1d0A3m3GS8ncYiu35alx84LSb+XaVrETKV S95HlOTbtG8or1xweQ+m8i0obC4FvRMyj9Vf3qy7YjmR1GTZ9HSraIaMSQhlXMuumHqJlOJCwqv4 PhuTpdxt67d44+HhvBq9EvbczWGriGOobHqQytKz93RYgfQkamZ2PNM1SF6eRpU6XIVy8tIrPd21 EEUC2DK9rsegKssap2tWkI9QDoHdyf5wW67fD9dObmCr2LG7rNUGp2Kug+bRklO0qaDXK5SLXF/9 8xCsbKoJLpSDRF0oyIDpqcq5E0hOUCIeH+PKOP8AOdfx7yQRX8fHZkR9CypKn00ksbfK25SRsYqH O1gVJOh1W8t5/dv+E5+fcdMtG/JWjdNQrPE31KRSL8ylWGu9QxUblIYAajQMN35RbrxgrnNzLLzv 287DU6Jxv4sciM/vcZL5dmvIGmutM2Ws0C3VaN0iHyuRqDiJeuXQLid3WXK5I8yzVISqH9yM+45w 7jnMLfHszjsZjaF2zlcjRmhZbE9KUV6sk0UjQNYWUMANPlsKC+121A2dQXkPLuQ8Sq5/EZDJZG9S r4vH3YZlavBciM9mOGSNZ1rtGVJOvzQMdm5F0J3dGnHfKLapbkI0zWE47ISOKv8AmxK8EmOzPdaa x1nHVKbVk7BdJhxlwUd0detpqGOSPXSlwByRuYy3t1FE0eoBL4epQcYbLWMoU5AvH1zBqisWj+nl k2RKLHdGknwLgx/KWAXcAW6ncXlu5NyVcVXxgbAtnmxIsmwFk+oij3ysa/aOqD1CESfMAS20kL0H nD7nNyqvGhcII+sRV2v2IaVhXK+8WGF03V6Bdd30SUy3YrHXpF+8m2eW57ErWOqPGKEXWY1BaJjp Fi8D3rlIWh1xnXOvHXDMdi+Qy23r1uQ1MjjoUevWmipwLYqo6qENidgkgJksSESOjr+Wh3heoRwn yDzDIZPAR1EsWcBax+QldJ7EMtuZq9l0YlxXhUvGQI4EBjR0b8xhsLdK28fKbsF443cqWlFToGNb VhjXirc/1JiuxVrkNF16J2jeKzn1ly22zilEiqrHavSkFlmc2gxCYjQOuYEHXkmAm8eN+G8FjuV4 Z8ibN/j+RbIxdu3VkpM7Vack0diNO80jVpSA0RftPoBuTQ9e3IvL2byHFswmPFajnseMfLvq2Uuq i2raQvXkftLGtiIErKE7iak7X1HrYdzI2XUM55W/G/Q6RcH1ep+zbJp9a0+Cas4lw2t8JCZ4nNxL B6u/j3b5mmykiioUzRVucwmEDCYOwBV3A8Dh8rwvleSyMCy3qFCvJXclgYnefYxAVgDqvp8wYfs6 sznGcy+L5jxbHY+doqV69Ok6AKRIiQ71BJUkaN6/KQf29Bb8i/L3ZMWsfPGPxKxaBF3nLuK+HXGO dy93rKmZUyLvmkvKrO3Kj0RxnjqUR0lq3MRH1XUw4bOirAomk3O2L60/8WcHwOfq8bl5DFVfHXMz biYLFJ9RK0MAkSKaYThTAT66LErLpoSwc7YJ5O5rnMDa5FFgJbKZCph6kqlpY+xEs05jeWKIwlhO B6atKVbXUBSg3LlU+UKUxHWcq4i6JT0brZqlcOP/ABz1+yTW9Q103x7rev09nNubxWKPFZxWkNOy mky8tHx07YRNAOTO3w+1jVAQ8Vk13w/DyHCXecYuc16k8F29VjSm0VMVq0pQQyTNPIa9mVVd4YPz l2p88o3fKop+WpsBmafC8nALFuGenSsu1tZbhs2Yw5ljiWCMT14mZElm/Jbc/wAkR2/My7F8qu+7 VxJ5a6ji+R0fM5fNMluNvrk+pvFJsOl47J1fQ5WiyVc3TFp6mJWKkauaAh1rHCx3sJeAkkPFmrJo uQ8DOFXwzxrj/NsJh8/esW4Ld6KKRPo5UgtLJAsyyU7SSmOatvYQSvvimjOrrCyeoQ2fMHI89wzM 5fBUq9SapSlkR/q4nnrNHM0TJbqvFvisbFM8SbJIXHyGVX9DLtD+UzRYeQisd2HAo1htwaVwVyaK cwmphM1LQ0uY9fmJdHTY+QRzeIdNI6is6pIqyrVuxXbi6IKCbkhCiqDHkvDmLnifO4LJu3HvpMvZ YPX2SQfpbqprspnYFpjIgjYuDtO4oSdOnrHeXcnDImDzeOVc/wDVYmupWxujm/U0Zu+pECkLEI3M iqhG4bQwA16HOj/LZeMO4950vozyobZp9td8x9IXntT0WOxRCUzPAtptNIrmfUs0Hntnb2rZL0jF gyrsKm0QIudEBXc9zAPUqyPhLHci5PaXFLPj8PAuLgCV4GtlZ7lWOaSaXfPGY6sJbfPKWJAPyp6d RfH+Zshx/jVVso0F/LTNk5y9iZaoaCnakiSGLZDIJLMu3bDEFAJHzN69Wkf/ACD5T/6J1X/cM/8A kH/8rof6qf8A0T/aX+tX/wDV/wAH/wBbqnf+mGa/5il/+yfov7w/4n/e/h/w/wD2nx/s9W7/ANSs P/y9z/8AXf1n92P8P/uvxf4j/s/h/a6ceM41llQ5jc0NhqWyMLfpuvsOOrXXsfZzFZdvcgLQs9kY HPHM1ERTxWxxB73Ancv2gyqKIuEwUM2E6QD2SZ/PZm9wTAYK7QaDEUWvGtaKyAWe9OrzhGYBG7L7 Ubtk7ToH0bpTgsHiKXOM7m6V5Z8tdWkLNYNGTW7MLJCWVTvXvJude4BqNSmo6Bd7wnxBfdnehhz4 immcD8ldZ5BReEkXxM8e15vsocidkyeQu7lytc5O82KtppJNKomdrIRrHzUBo4WOVySxo/IPIV44 uL/hp2yv8JSUmuaW9xxJb8uysIAiWFJNS1khkkfQb1UbDXz8CwDchbJjkaLi/wCKo7i1Nau0ZUL8 9cyk91pXTQLXBV0TU7GY7wX3EPHa1x6zXe3OD7AvycpVh1HWdDo9HjpvNVGlUvj6Zn5e35ZGX6EO iyWkXtyW9m4UmnIDGOCdlQRAFe8G5xnbfKMtjU5JRGIyEVOtBNMyT6yQhUWKw0L6kKIhuURL+Yp9 N3y9TbhWEq8axWRbjt45ahLbsTRRK8GkcxZ2krrMugLGU7SZW/LYeu35uqguF/D/AI3TXE2Siz8j cFxDX7T8g9b5BYO6zvccX3dbDdcixkW/GXDZyRhbOaj7JaEKsymVE4NuqmaXQfuBQIBkT+F5c+5z yuvzVJhislkcHDxiSlcE9S1TFus2037aK8feqxmQxAzMD2ii7jow1pTgnCeLWOGvCcpjsfm5uSpc qGG3VtmpZXcKNR2WTtWZBGJSIlI7gdto1U6E2HBbBXr7BmdD+QuKrvJCh7LzTsdr0OvOcIl7br2m bLEQhOY8OxzZ6u+g6naqRXW7NJVs0avVKayVIo7bnVFJckQ/6jckjjyUmS4u8vFLNDFJHA4uLFWr 1Wf9LYzgB5I5XLEMzILTAhGA3KZX/wBPeOySY5MdyZIuU172UeSZDUaSzPZVP1NRASUjkiQKCqqx rKQXUnawJzhDxp48YveKvN5ByWgNnlozh5kuSR0HEWOgTJ5LKqtd7pNVTWU0arIPXqsTZZaXeMkH afeOWM0OVNVRQpvGI+Q+W8oz+Omr5zEy0IHztmyzsky7bMkUSSVtZFADRqquVPzjcCQARrLOAcV4 zgshDYwmVjvzJhK9dUV4W3V45ZWjsaRsTtdmZAw+Q7ToSQdGhy/4q8TtUmuZcluXKGrZux2DDMFo OpQs/dM7rTTH2VP0N/PY7o8otPyjFzFKWC7mO2j/ALkZBpIqlVbomUMYSlXcG5nzXDV8DFx3DzW5 KORuTV3SKeQ2jLAqWoFCKQ2yLRn7erICGYDTUoubcP4bmJ85LyDLw1Y7uPqQ2FeWFBWEUxetOxdg V3y6qm/RXOqqTroGDiXB/Ho7TYSb41c8zJV6FpHDdpyYoOXzGZWGe1wuB0CLZ4bNzNzhZh7P5JVd cpTJsvMMY5AqNrijD6C5EFTGM5ch8h52XESV+W8b1tSWMoaE1hbCJW+smY20WJ1CWZK0pYRO51ry fiUsAA3YDgGEiy0c/FeRaVY6+MF6Gu0DvZ+jhUVGaVGL1o7MQUyIg0sR/hYKTqwdu4J8P7pifJKn 3bnpX6pjms83bDsbGVkLhiEXFYjyRXC+PdXzKCtyzmM9ewykHMu2zqEkXIyMUwjR7JAIvTrOfHvI 3OaHIMTex/G5Zs7S48lUqsVtmt0R2RWsPEA2iK6qyyouyR5Pxfuwrbn/AB7wm/gcpSv8iihwdzPv ZDGSqq1bx7xsQJISursjMrRO2+NE+H7wsoW3hj8b0+7+R5xNcscujGfJRlmBNbZsNZyiGLxpc1e5 x7yqvfWJOF/T6Nh2H7UuCEwVBF0+RRZEAwqiBvKjz7yvWTii18Lcd8S1j6YmtZf68SRMJBps+cpV 7g1i1KoWkP4fT0u8F8XWX5Q0+ZqImVWD6kCxXX6ExygxnXf8gez2zpJoGcLGPj6vyL4f4ix0atSW z836ffOU0VzfxXdNGsByZFndjuupVXH3tRxTCS5hHTbkaehJZcC75iwS9xNSxDLvUzHT8RSbZudc hkxU0OA49PW4c/HrdOBP+JnSKvJaEtu59QyDulbGiO50ijO2MgHXc5Q8JwEeUilzufgscuTP1bc7 /wDDQvLYjrGOrU7Cse2Gg1dEGssg3SAkabekXxK4fr8qJiw5/wAu85i+YxuZFm5GItK5YcfkNsYN V6J9g1HjTL1lCTPcJbM5GnN1nD5msgm9ju6joBIJljKdzc25yvDY6uTwdp+CfoMdEl0tLUYibfXv rIV7S2FlIVGBKP6J66KB1FwzhLcvezjc1VTm/wCuSXQEes1oAw7LFFow3caBogS6kBk9X9NWJXee HErD9v3KZuNm5n1fjhc5jh9eMl1qmzamRS0vKcZ3dmk5yTu8M30SRbSmaRDCyOXDaYsbdFRuuyJ7 UFmipTLim8b825Dx7jsdCpgJsrQjzsNmtKn1Kqt8RqiwsYFKzsYwrRQMQyud+1wQvSjyJwzj+f5A 963nYcXefCS17MT/AEzM1EyM7SqJmDQKHLLJOAQVGzchBbqcuO3HXMqDym0vWMu5MpXWcncJ4/0P acYjX2dziAjS6YjEYnp8qWI9e2Uwk9T2cgvHt/JNhKFeOF0zKpppAlHeU8py+T4bUwuYxBr148ld mq2mE6H82Utbrru0jl2SlA59Xj2qpCknWQcZ4xicdy+1mcRlRPYkx1OG1VUwuPyottWdtuskW+MO UHokm5mBYAaD/aeHfGeR26+3x5zKiYxCwc9uNu2P8teWfJzNq5yozgCKV3LSvlnLayJWjUIcySKE Auf7l6JSHbIqj9Rk1PnXLYuPVsamBd2i41fqCwI7OsmOn/HY0AMfbrtqTMB29dQ7DqN3OEcUlz9n IvnERZeR0bRrmSvomQg/BX1JD9yddAIT8+mhVT0ypPg7jM1pclJYX8gcTnfIWV5H81r0wdQKmN3q xxTfc5Copch8iiKY6lkpdGzZNNxDNRCWKqEpWn7wfeIH80U03GLyJnq+JSHkfGHtcXTFYqFg/wBV CjGosppWWlClTHZRmDR6dudF/LYaMSgl4Bgp8q8vHuSJV5M+UykoKfTSuotmP62ssRbcJK7KpEgP cgdvnU6qAanJ7jviF24kVLAtY3aYoUJCvMkhc13m8aBXQ0EuuUl/Fnze0L2u4C3irjoNknYsPdIC Qq8ud04IiCSihDp1/wAQ5TyHH83n5LhcbHZsSLZeenDC/Z+mlDd+MRxatFDGjfKddIgqltwBBnnL eM4C/wAMh45mci9avG1ZYLcsyd76mIr2JDJJosszuvzDTWQswXaSCAeNwhyFq9kWst8htVfc9F+V EDrrjaJiMwr74nsDHJ31VjMwcccfuqEMWJfZM8WefZSKpSpwKR8muVBIqfVhjyFnHjR4OLzL42GG esKqtc2fSmyJGsC9tL7hZAXu6GMesZUsdeq//gHCJIyTcmhbyKcwlk2mWpv+pFcxrAaW4LtNclu1 qJD6SBgo06ctq4K8c4qWv8XqHOOTkdBf/G3e+POkyur6FQX1/Rx+0bZMaFbeSVkVsMshKx9YibpK LQrVVyUsHGNEUWXuBURARSUvI3Kpoa02H46iYteWQ3YFrQTCE2o6iwR0E2KVaRolErBfzpGLSbNG 6V3PHvGIZrMOX5A7ZJuLS0p2sTQmYVpLTTSXnLsGWNZWMSlvyo1Cx7tV6R7/AMIOKlhT3gXPOqNq 9fu+I8OKJpTAlsxEWlVv+UlrX+x9s0nIyYHdwZrUEKr9uhVVG8dayybj26hxBsKCjGeQ+Z1TjdvH Hms18hlJoG7dvWSGz3P1Oqqr6P2943ygM9btruA+fd4ZLgHD7IyO/kKw1rGPxkM47lXSOavs/TbT M3qnc2HZESqWO420n5ds4wfECr1bWOJtt3LmxM6XuVK2fb9RqDS5uaBVk9WtGgZdB1GcomU56D5V 3UqLntPhU5BCDg1XwN1Hbl0uYQWKZOO2Oc3LmFzdLjvH46nHbFCpXlMQmk+mjhsPKk1mfTSSaeVy hmmCbgqIo+Ugv8HCalTM4a7yDPSWuQQX7ViMSmGP6iSaBI3hrw66xxQxKHEURfQs7sfmGjt5y8ba JumhZRMs+VcZxi3Kp51uUDDrrpZ7ZHtww6912MitrKFGu0jGulUa5EtUF055qp6MEoqKrlNYpiAR D465ZkuOYy7Xkwr5jjs9qo7AGeMRW4XZqn50SsNXYkGFhrMBtQqQdVvkDi2O5Dkqc6ZhMTyCGrbR Sey5lqTIq2vypWU6IoBEynSInVg2o09eMXHfjTnG459d8V5AQV6Xr/A3LcKoecx1uoVodSmDVS8v 5Ws7aLyvLhLTzKz2UztsMs3QThnLo6pEh8ilTT65fynluV47ax/IMZJWWXkli5NO0U0YW5JCqyVN HG1DHHtbtsTKqhS3oST9cT4zxXF8grZDA5KOw0XHa9SGBZIZC1SOUtHa1Q7nEkm5e4AImYsB6gAD tya4XcaNL1jmXcZ3m/FZK31tfiUXk5nTixYyo0oV6zKTqbnjvMz72zKJWPP3txhoQzSLj3qqCM0a TVWTK5ErYiUo4jz7luJwuBoVuPPdaiMl9BOEtazQ2FkF5UEeqTCJ33SOgJi7aqSnzloxyvgnFMrm c7esZ9KS3Tjvr4S9XSGWBozSZzJ88JlVNsaMQJe4WAf5QvrbeHuFSmu2yx5Nzio+c8qJfmBpWwUO Rco41o81SdFsWLNKTq+NnymfmUQtqjbLzIyKjVcqMtEdkXw9iAIqdUudcjhwcFXN8dsWuGpgoKsy g2oElgS2Za1r6lEPb1saoGGscvzR/H4d3eE8emzU1rDcgr1eYPm57MLEVp3imeqIrFb6d2Hc0g0c qdJI/lk+HxJvkJxkyyZ+PO0cZNk5Jz9dzT9H1WCunJXV7lXHVgOpFXuv2A9itduuTlnXQcT9jZkZ fz1UyJFclQRMByp9RHi/LszX8oQ8uwOJily3fkeKhWicJ80LpsjiiBfRIyX9AddpZhoT1LOS8TxE /jSbimcyskWK7EaS3rEqF/lmR98kkpCau4C+pGm4KvqB0IOn8F+OT7JOWFJ5L8+0bBqew5xgjDVN n0Gw4hQ3+WYnQNJh5fKWzGixwV2r1Go221svYjJPQ8JZ8uHoqe57+c5w/kXlUebwuQ4lxkxYajbu NXqwJbmWxbmgZbJMzb5JZYozv7aesaD5hs+EJy3j7i8mFzNDlXIxJl71WmLFqZ6sJr1YZ1auBEuy OOOSQbN7ekjn5Tu+I3tsMkJrnTWbBSJGLz3IYf5Rbtp08d9yx43XzCLTrbbNhaWeIpdFhvtfIaF5 UXxdADv6VJIuWdYSBcUDqoLionK35FFX8czVcij2s5Jw+KummNvQ3I6xn1jaWZt1J8dCDoluMq1g 7dwDLoYuvH5Z/IUVmg6VsKnLpZ31yNGapJZEGkixRLturkJiNXquGWAbtpKtqJ1o3BDhzH5Rx5qt Y54Rbym51gvMilytkr19xY6Wz8c9bvNmmN6fDKgtKsa/EZtYZRZo/sUQIEiVW3g5OioUQCN5HyRz uXNZS7b42637WSxcqxvDa/4W9WhjWmNuil2nRQyQS+sgbVAwPUhx/jzg8eHxlOpyJGo1cdk4mdJq v/FUrEsjXDu1YIsDsVeaP0jK6MVI6akXwL40/wBxOlVC/wDyNUGzV22ceuJ9DLeokMCodfoeMZTu bG2YHZYttFTjmHVi75ZWIwyMvJOXSc9KOFjoqqKmTbJLpvJPLf4jqXsZxWzDagymSm7LfWTPNas1 DHcjYsgbdDGe6Yo1UwxqoZQoLlHD464r/D1ulkuUVpas2Mx0PdX6OFIate2JKbqFcrtmcdoSOzCa RmKknRBYJzf45VfetA4sSQcqFuMWx5vdb5L4a5jCZ1JWO7WaaqrVhYGNdq+geqSzvIattlVFUGrd yKbdc6ipOwEMWsfHnKrnGsZmYv0YZjBW68K2w3fVIo0kJQvJDp2w8hADMV1YAA/EGyef8XqciyWH l/WDic5VnmaoV7LPLI0YDhI5te4VQEkKG0BJI+BAt7Vwnwqxx/JaL5Cc82f94V94u5PmO63G3yOL UqdrFMq+uKXCq6nZ6+RWGiqqys0kdOCRVXQaMFik/lKHcj5BMeP+QeR1ZcTNxjjbfpdbMWbFOKJb UqSSyVu1JXjf52kMa6zEAs419QE9OojnuBcetRZWHkvIl/U7OIrwW5ZGqxPHFHZ7sdiRPlWMSNpE CQqH7CX9epmacQa1YeVV/wBLzjmnY4Cuu9Ty7QOROAZo/orScldnz+jwMLWo2zX6AekvtJp1xr7K MezdRcoqJy4GA6aqCKxSgwvzm3V4ZWxOV4/FLaWnYho3Z1mKLVmmd5GjhcdmWWJzIkVlSDF8CGZS en1OFVbPMLOVxeeljqtcrzXacBiDtahiRY1kmQ96KKVBG0tZgRJ8QVVgOhrjOC/G+AunKaI3X5BI TR9JnOIug4landpk8JpezZpx7ss5CS85pW9TrZcbNpVirzxvEtU7XY0WDJszAiR0vUWIqErm8i8r s0MNPxzjElTEx5yC3GI1uS1Z7saOqQU0I7cCODIxrQF3ZtWDaKV6isXj7i9a9l4eQ8kjtZSTCzVZ DI1SKzBTd0Z57bg9yd0IjUWJwiqugI1YN01K5gMW3+T3iHK6bp+dyjPjfxsjKrQNCvGxYiy0HlvN T8PeEMkkKrx/qUq1sEU3z1jbbORpMqsjBKLQ6ijXz9M65ltrk0zeIM5DiKdpJMtlmkmghq2zDjUR oTZWS7KpRjOY65aIP+WJQH01ChHV45CvlnCzZa3VdMXiljhmls1RNkWdZRWMdONg6iESThZSv5hj JTXQsXdXeCeJLwmMVfjf8hkPUdNgavygrLC81FfHL1cL9jGubE9s2vMqrHITibis2jONFUUYs7dC HK5gX/mi4TOoBUiIrXkfkK2L9zlfF5J8RLNj5GhlFqGKG1WqiOsZGKaSRzwaO1aYbZk0ZSBqStq+ PcA1ehU4tyZIMtHDfjEsZrSyzVbNkyWRGofWOSCbVFsxHdC+qsCdALSv9n6rf+7e0/7tn+z9/rbl v/K3/u3+P+un/wDrv9L6pz+J7n/I4/8A9W+t/wAMv7z/AJb/AO0/8t+Hq3f4bqf87f8A/Svo/wDE t+7/AOY/+6/8z+Lr/9k= --_004_A6B8F2A767638641889989BC1BA7047936014236LIONALLOTLOCAL_-- From nobody Tue Aug 26 04:41: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 2B3011A6F6B for ; Tue, 26 Aug 2014 04:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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.668, 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 uwKhg0v5YIo5 for ; Tue, 26 Aug 2014 04:41:01 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E30D1A6F84 for ; Tue, 26 Aug 2014 04:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2934; q=dns/txt; s=iport; t=1409053262; x=1410262862; h=from:to:subject:date:message-id:mime-version; bh=O6q46YVHb8txJ0HB24AclDY5Co9IF40BQbvK1Fssbtc=; b=SVdgoepX7sVbwS510DBPH+esB+kTQwhz5aKN1Y6uoK81IX+nd+mWk4mQ JbAIxqw+3VyDCkWvl3mSk92XTLoBVl3ro5MdHrL57FGPFzyKT/o0KP1OZ dm95uQMuomCpVe0Cf7D58gRsn5P6cVSuaHtzdvzrXZV5k2tcSi0Otv3jC A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoHAOBx/FOtJV2S/2dsb2JhbABagkdGU1gDskyYIoFjiGMWd4QKHVEdAQwOZhcQBIhVDZoBpFEXlB8FkSaEKYZ6gViTNINegjSBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,404,1406592000"; d="scan'208,217";a="350306004" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-5.cisco.com with ESMTP; 26 Aug 2014 11:41:01 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s7QBexvZ002640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 26 Aug 2014 11:40:59 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Tue, 26 Aug 2014 06:40:59 -0500 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: Call for WG adoption of draft-merged-sfc-architecture-02 Thread-Index: AQHPwSKarKFwlbPq2EakRGFWvH7bzw== Date: Tue, 26 Aug 2014 11:40:58 +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_D021EA6933AE5jguicharciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/A5N3OZDM_iVAO0DQuDvxsTD17fc Subject: [sfc] Call for WG adoption of draft-merged-sfc-architecture-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: Tue, 26 Aug 2014 11:41:03 -0000 --_000_D021EA6933AE5jguicharciscocom_ 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-merged-sfc-arc= hitecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-architecture= /] ending September 9th 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. 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_D021EA6933AE5jguicharciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7A148EA2E7DC2B4A921D6369CC9BF3E7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Greetings WG:

This message begins a two week call for WG adoption of draft-merged-sf= c-architecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-archite= cture/] ending September 9th 2014.

Please respond to the SFC mailing list with any statements of approval= or disapproval.

As always, please note:
  1. This is not WG Last C= all. The document is not final, and the WG is expected to modify the docume= nt=92s content until there is WG consensus that the content is solid. There= fore, 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 conten= t, by all means raise those issues and we can begin a dialog about how best= to address them.
--_000_D021EA6933AE5jguicharciscocom_-- From nobody Tue Aug 26 10:08:02 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 2C6191A02D1 for ; Tue, 26 Aug 2014 10:07:58 -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 WHpeVB3G-x6k for ; Tue, 26 Aug 2014 10:07:56 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83E9D1A0066 for ; Tue, 26 Aug 2014 10:07:51 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id l6so15613533qcy.5 for ; Tue, 26 Aug 2014 10:07:50 -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=VF+Y7pFRq/z/aDwDPeCitS/riDJZ7+7iPkojppQl204=; b=km2CPpkZnWS5LAA3D69He8FK5ZKormAXqgmmHYKZ+ZonebJStu6VpG2SL2yxyXRO6Z nssG11B11d20TOHnXDRZgmagGYtWioHGitVJTxqX14t6rYRASCP1sN0Ecc74qML90Xxf VK9Nujp5VeytAvFZx115cNvxQN1o5FPZsnXKEzawbFJ9yR2KPCUdmKZTjagydDE0w42h HWzpa504l3PuAJDA1VCtWbARF+jlQa+NDAjU3BQLdBzXdJVzM04+4PkY+zC9H4xT8oak e6kGy/L08c7B9XVZix3o2TKX1XKRaHLOclj5bPZZehNBpndB4ESjagFTS1nBk+PvFiHL CqEA== X-Received: by 10.224.136.200 with SMTP id s8mr48435035qat.44.1409072870788; Tue, 26 Aug 2014 10:07:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.91.99 with HTTP; Tue, 26 Aug 2014 10:07:29 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Tue, 26 Aug 2014 13:07:29 -0400 Message-ID: To: "Jim Guichard (jguichar)" Content-Type: multipart/alternative; boundary=001a11c2caa2ed176405018b572c Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/AniHtCeh9I5VhC51n_61CUbbU1g Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-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: Tue, 26 Aug 2014 17:07:58 -0000 --001a11c2caa2ed176405018b572c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jim, I support the adoption of this draft by the WG. During the discussion of revision -01, although a number of WG participants requested a more flexible wording of the SFC encapsulation definition, it was unchanged from -01 to -02. This is within the rights of individual authors, of course. However, once this becomes a WG draft, I hope we can revisit that discussion. Thanks, Andy On Tue, Aug 26, 2014 at 7:40 AM, Jim Guichard (jguichar) wrote: > Greetings WG: > > This message begins a two week call for WG adoption of > draft-merged-sfc-architecture-02 [ > http://datatracker.ietf.org/doc/draft-merged-sfc-architecture/] ending > September 9th 2014. > > 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 WG is > expected to modify the document=E2=80=99s content until there is WG co= nsensus that > the content is solid. Therefore, please don=E2=80=99t 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 conce= rns. > 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 > > --001a11c2caa2ed176405018b572c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jim,

I support the adoption of this dra= ft by the WG.

During the discussion of revision -0= 1, although a number of WG participants requested a more flexible wording o= f the SFC encapsulation definition, it was unchanged from -01 to -02. This = is within the rights of individual authors, of course. However, once this b= ecomes a WG draft, I hope we can revisit that discussion.

Thanks,
Andy



On Tue, Aug 26, 201= 4 at 7:40 AM, Jim Guichard (jguichar) <jguichar@cisco.com> = wrote:
Greetings WG:

This message begins a two week call for WG adoption of draft-merged-sf= c-architecture-02 [http://datatracker.ietf.org/doc/draft-= merged-sfc-architecture/]=C2=A0ending September 9th 2014.

Please respond to the SFC mailing list with any statements of approval= or disapproval.

As always, please note:
  1. This is not WG Last Cal= l. The document is not final, and the WG is expected to modify the document= =E2=80=99s content until there is WG consensus that the content is solid. T= herefore, please don=E2=80=99t oppose adoption just because you want to see changes to its content.
    2. <= li>If you have objections t= o adoption of the document, please state your reasons why, and explain what= it would take to address your concerns.
  2. If you have issues with= the content, by all means raise those issues and we can begin a dialog abo= ut how best to address them.

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


--001a11c2caa2ed176405018b572c-- From nobody Tue Aug 26 11:25: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 1584B1A00F9 for ; Tue, 26 Aug 2014 11:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.668 X-Spam-Level: X-Spam-Status: No, score=-7.668 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.668, 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 r0ow83e8TaiY for ; Tue, 26 Aug 2014 11:25:26 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8CC01A0097 for ; Tue, 26 Aug 2014 11:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1409077526; x=1440613526; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6xbqSldw4CoXUS/Cqy/THEJV1g+10TkMMXSP/uPpjho=; b=MMqTRbVC/czyy4Lgn8j/9zL9f/ELtLWhH67Fl2RHEAbuPBQEcEr0UAER b4drTxW6zsJqZ8g1m5HsAuB37uQl4npbKAecb59XtbuUURAEKvvEWw+4P SjQ4F53AoEWPhOUvHfCbxzzt/4XC7OeduCZDtR5ppUMNmUjQ7Kt/XPSux M=; X-IronPort-AV: E=Sophos;i="5.04,405,1406592000"; d="scan'208,217";a="127462170" X-IPAS-Result: AssEAOjP/FPAqArr/2dsb2JhbABbgkeBGVeyV5gigTghAQmHTQGBLXeEBAEBAQMBAQEaUQsQAgEIBA4tBycLFAMOAgQOBYhPv0AXj0gEB4MvgR0FlU+IUpcSbIJPAQEB Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 26 Aug 2014 18:25:26 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by SEAECAS04.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Tue, 26 Aug 2014 11:25:26 -0700 From: Sumandra Majee To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 Thread-Index: AQHPwVsajjT4O/XlBUWhy0sus5Gcrw== Date: Tue, 26 Aug 2014 18:25:25 +0000 Message-ID: <3A9E5A05-79B1-41E1-875C-C466E496A711@F5.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3A9E5A0579B141E1875CC466E496A711F5com_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/X99QtzxjJGT6dJjwmzEIJ7Gdb3Q Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-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: Tue, 26 Aug 2014 18:25:29 -0000 --_000_3A9E5A0579B141E1875CC466E496A711F5com_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Support Sent from my iPhone On Aug 26, 2014, at 4:41 AM, "Jim Guichard (jguichar)" > wrote: Greetings WG: This message begins a two week call for WG adoption of draft-merged-sfc-arc= hitecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-architecture= /] ending September 9th 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. 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_3A9E5A0579B141E1875CC466E496A711F5com_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Support

Sent from my iPhone

On Aug 26, 2014, at 4:41 AM, "Jim Guichard (jguichar)" <jguichar@cisco.com> wrote:

Greetings WG:

This message begins a two week call for WG adoption of draft-merged-sf= c-architecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-archite= cture/] ending September 9th 2014.

Please respond to the SFC mailing list with any statements of approval= or disapproval.

As always, please note:
  1. This is not WG Last C= all. The document is not final, and the WG is expected to modify the docume= nt=92s content until there is WG consensus that the content is solid. There= fore, 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 conten= t, 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.iet= f.org/mailman/listinfo/sfc
--_000_3A9E5A0579B141E1875CC466E496A711F5com_-- From nobody Tue Aug 26 11: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 8727A1A011B for ; Tue, 26 Aug 2014 11:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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.668, 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 DTGsA-lmP0Aq for ; Tue, 26 Aug 2014 11:32:37 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 139DD1A01FA for ; Tue, 26 Aug 2014 11:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3927; q=dns/txt; s=iport; t=1409077955; x=1410287555; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NAzyqdCW3dKEiFwe27zWXnsbA1r++FJikF4MmnCMNgQ=; b=bt9accdUbrYDgfvVtIV0V3fhmhgWny/PydfdQ8AFRpUToOfzvGAlm3AI 785sHUyTZFNhaaEH/GmEC5GwTIVAn3CJUxdxf0BuNfNU+dHfryEE8OTj5 6zgcJtVRfp0G3MNaCcjFUTVdWDXqSMxvDm6Pw3IQa0Ri98Gj7PT4ZKh27 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAEPS/FOtJV2P/2dsb2JhbABbgkdGU00KBLJTmCKBWQEJh00BgRcWd4QEAQEEAQEBGlELEAIBCAQOLQcnCxQDDgIEDgWIQg2/PBePTAeDL4EdBZEmhCmGeoFYkzSDXmyBSIEHAQEB X-IronPort-AV: E=Sophos; i="5.04,405,1406592000"; d="scan'208,217"; a="72526659" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-7.cisco.com with ESMTP; 26 Aug 2014 18:32:34 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s7QIWYOS003509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 26 Aug 2014 18:32:34 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.204]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Tue, 26 Aug 2014 13:32:34 -0500 From: "Paul Quinn (paulq)" To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 Thread-Index: AQHPwSKarKFwlbPq2EakRGFWvH7bz5vjib+A Date: Tue, 26 Aug 2014 18:32:33 +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: [10.82.101.41] Content-Type: multipart/alternative; boundary="_000_D74C79462D6D4980A877C60C4FB3E226ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/E23TtQPnbSEozJ0JbBWNlS-ran8 Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-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: Tue, 26 Aug 2014 18:32:39 -0000 --_000_D74C79462D6D4980A877C60C4FB3E226ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I support the adoption of this version of the architecture draft. On Aug 26, 2014, at 7:40 AM, Jim Guichard (jguichar) > wrote: Greetings WG: This message begins a two week call for WG adoption of draft-merged-sfc-arc= hitecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-architecture= /] ending September 9th 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. 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_D74C79462D6D4980A877C60C4FB3E226ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <80C9B659FAA7134E809820E952EE8220@emea.cisco.com> Content-Transfer-Encoding: quoted-printable I support the adoption of this version of the architecture draft.


On Aug 26, 2014, at 7:40 AM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:

Greetings WG:

This message begins a two week call for WG adoption of draft-merged-sf= c-architecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-archite= cture/] ending September 9th 2014.

Please respond to the SFC mailing list with any statements of approval= or disapproval.

As always, please note:
  1. This is not WG Last C= all. The document is not final, and the WG is expected to modify the docume= nt=92s content until there is WG consensus that the content is solid. There= fore, 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 conten= t, 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_D74C79462D6D4980A877C60C4FB3E226ciscocom_-- From nobody Tue Aug 26 11:46: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 3F0271A0089 for ; Tue, 26 Aug 2014 11:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, 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 Y5Kgb07bLuwK for ; Tue, 26 Aug 2014 11:46:29 -0700 (PDT) Received: from smtp1.riverbed.com (incomingmail.riverbed.com [208.70.196.45]) by ietfa.amsl.com (Postfix) with ESMTP id B02F71A0079 for ; Tue, 26 Aug 2014 11:46:29 -0700 (PDT) Received: from unknown (HELO 365EXCH-HUB-P3.nbttech.com) ([10.16.4.1]) by smtp1.riverbed.com with ESMTP; 26 Aug 2014 11:46:29 -0700 Received: from SFO1EXC-MBXP14.nbttech.com ([fe80::48a3:fcd6:284c:af72]) by 365EXCH-HUB-P3.nbttech.com ([::1]) with mapi id 14.03.0195.001; Tue, 26 Aug 2014 11:46:29 -0700 From: Kevin Glavin To: "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 Thread-Index: AQHPwV4LrKFwlbPq2EakRGFWvH7bzw== Date: Tue, 26 Aug 2014 18:46:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.205.250] Content-Type: multipart/alternative; boundary="_000_D02223D22B7AAkevinglavinriverbedcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/vrHtmVAjX5flbukQm6yb4DMbGj4 Cc: "Jim Guichard \(jguichar\)" Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-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: Tue, 26 Aug 2014 18:46:33 -0000 --_000_D02223D22B7AAkevinglavinriverbedcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I support the adoption of this version of merged architecture. Kevin From: "Jim Guichard (jguichar)" > Date: Tuesday, August 26, 2014 4:40 AM To: "sfc@ietf.org" > Subject: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 Greetings WG: This message begins a two week call for WG adoption of draft-merged-sfc-arc= hitecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-architecture= /] ending September 9th 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. 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_D02223D22B7AAkevinglavinriverbedcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I support the adoption of this version of merged architecture. 

Kevin


From: "Jim Guichard (jguichar)= " <jguichar@cisco.com>=
Date: Tuesday, August 26, 2014 4:40= AM
To: "sfc@ietf.org" <sfc@ietf.= org>
Subject: [sfc] Call for WG adoption= of draft-merged-sfc-architecture-02

Greetings WG:

This message begins a two week call for WG adoption of draft-merged-sf= c-architecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-archite= cture/] ending September 9th 2014.

Please respond to the SFC mailing list with any statements of approval= or disapproval.

As always, please note:
  1. This is not WG Last C= all. The document is not final, and the WG is expected to modify the docume= nt=92s content until there is WG consensus that the content is solid. There= fore, 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 conten= t, by all means raise those issues and we can begin a dialog about how best= to address them.
--_000_D02223D22B7AAkevinglavinriverbedcom_-- From nobody Tue Aug 26 11:54: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 4C52B1A014E for ; Tue, 26 Aug 2014 11:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.867 X-Spam-Level: X-Spam-Status: No, score=-4.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 RSf2NVpbEUNn for ; Tue, 26 Aug 2014 11:29:59 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBE251A0125 for ; Tue, 26 Aug 2014 11:29:58 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 622dcf35.2acd4585b940.1353940.00-2419.3788510.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 26 Aug 2014 18:29:58 +0000 (UTC) X-MXL-Hash: 53fcd2261b5416cc-63bfa66d6a37514b130f33f05fbf3ba123663fb9 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 522dcf35.0.1353920.00-2246.3788437.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 26 Aug 2014 18:29:58 +0000 (UTC) X-MXL-Hash: 53fcd2265d8fe40e-1d08bafe03c600ca7b432a17c32d22b411b7f940 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s7QITutS028378; Tue, 26 Aug 2014 14:29:57 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s7QITkJO028225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Aug 2014 14:29:51 -0400 Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com [130.9.129.150]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Tue, 26 Aug 2014 18:29:34 GMT Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.175]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0195.001; Tue, 26 Aug 2014 14:29:33 -0400 From: "UTTARO, JAMES" To: "'Sumandra Majee'" , "'Jim Guichard (jguichar)'" Thread-Topic: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 Thread-Index: AQHPwSKarKFwlbPq2EakRGFWvH7bz5vjdv6A//++pxA= Date: Tue, 26 Aug 2014 18:29:33 +0000 Message-ID: References: <3A9E5A05-79B1-41E1-875C-C466E496A711@F5.com> In-Reply-To: <3A9E5A05-79B1-41E1-875C-C466E496A711@F5.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.205.11] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550F06D7F152MISOUT7MSGUSRCD_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=TNjyvSZa c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=t_MuBpRJa2UA:10 a=cn-s5AlbVPAA:10 a=ofMgfj31e3cA:10 a=mCL] X-AnalysisOut: [VOu6BPzMA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=LZ-rTN4J8hvhok-] X-AnalysisOut: [qgrIA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=JfD0Fch1gWkA] X-AnalysisOut: [:10 a=Kyuxm8M5sySPg0w8:21 a=LoX_apz9ZuftG_Se:21 a=yMhMjlub] X-AnalysisOut: [AAAA:8 a=SSmOFEACAAAA:8 a=rpC01cX5CnZlvGPCIuwA:9 a=gKO2Hq4] X-AnalysisOut: [RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hU] X-AnalysisOut: [A:10 a=L2ZLBLpE17ivIH1R:21 a=CotGQkwG9g5jEk5X:21 a=0X0AQEZ] X-AnalysisOut: [KTVdBYJUX:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/NFSNicdcGuRhmVYdefTUxS0Xsgo X-Mailman-Approved-At: Tue, 26 Aug 2014 11:54:42 -0700 Cc: "'sfc@ietf.org'" Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-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: Tue, 26 Aug 2014 18:30:01 -0000 --_000_B17A6910EEDD1F45980687268941550F06D7F152MISOUT7MSGUSRCD_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sumandra Majee Sent: Tuesday, August 26, 2014 2:25 PM To: Jim Guichard (jguichar) Cc: sfc@ietf.org Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 Support Sent from my iPhone On Aug 26, 2014, at 4:41 AM, "Jim Guichard (jguichar)" > wrote: Greetings WG: This message begins a two week call for WG adoption of draft-merged-sfc-arc= hitecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-architecture= /] ending September 9th 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. 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. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_B17A6910EEDD1F45980687268941550F06D7F152MISOUT7MSGUSRCD_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1<= /p>

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Sumandra Majee
Sent: Tuesday, August 26, 2014 2:25 PM
To: Jim Guichard (jguichar)
Cc: sfc@ietf.org
Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architec= ture-02

 

Support

Sent from my iPhone


On Aug 26, 2014, at 4:41 AM, "Jim Guichard (jguichar)" <jguichar@cisco.com> wrote:

Greetings WG:

 

This message begins a two week call for WG adoption = of draft-merged-sfc-architecture-02 [http://datatracker.ietf.org/doc/draft-= merged-sfc-architecture/] ending September 9th 2014.

 

Please respond to the SFC mailing list with any stat= ements of approval or disapproval.

 

As always, please n= ote:

  1. This is not WG Last Call. The document is = not final, and the WG is expected to modify the document’s content un= til there is WG consensus that the content is solid. Therefore, please don&= #8217;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 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

--_000_B17A6910EEDD1F45980687268941550F06D7F152MISOUT7MSGUSRCD_-- From nobody Tue Aug 26 12:03: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 B339A1A0252 for ; Tue, 26 Aug 2014 12:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 JqK3p7gigm7T for ; Tue, 26 Aug 2014 12:03:46 -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 5021F1A01F1 for ; Tue, 26 Aug 2014 12:03:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIT46029; Tue, 26 Aug 2014 19:03:25 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 26 Aug 2014 20:03:24 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0158.001; Tue, 26 Aug 2014 12:03:18 -0700 From: Lucy yong To: "Andrew G. Malis" , "Jim Guichard (jguichar)" Thread-Topic: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 Thread-Index: AQHPwSKarKFwlbPq2EakRGFWvH7bz5vjk4KA//+qZfA= Date: Tue, 26 Aug 2014 19:03:17 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453DC968@dfweml701-chm> 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.132.114] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D453DC968dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/D9Iblp_q2ODDxjwvhBb0P2SBuj4 Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-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: Tue, 26 Aug 2014 19:03:48 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D453DC968dfweml701chm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCB0aGUgV0cgYWRvcHRpb24gYW5kIEFuZHnigJlzIHBvaW50Lg0KTHVjeQ0KDQpGcm9t OiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHJldyBH LiBNYWxpcw0KU2VudDogVHVlc2RheSwgQXVndXN0IDI2LCAyMDE0IDEyOjA3IFBNDQpUbzogSmlt IEd1aWNoYXJkIChqZ3VpY2hhcikNCkNjOiBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2Zj XSBDYWxsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZS0w Mg0KDQpKaW0sDQoNCkkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhpcyBkcmFmdCBieSB0aGUg V0cuDQoNCkR1cmluZyB0aGUgZGlzY3Vzc2lvbiBvZiByZXZpc2lvbiAtMDEsIGFsdGhvdWdoIGEg bnVtYmVyIG9mIFdHIHBhcnRpY2lwYW50cyByZXF1ZXN0ZWQgYSBtb3JlIGZsZXhpYmxlIHdvcmRp bmcgb2YgdGhlIFNGQyBlbmNhcHN1bGF0aW9uIGRlZmluaXRpb24sIGl0IHdhcyB1bmNoYW5nZWQg ZnJvbSAtMDEgdG8gLTAyLiBUaGlzIGlzIHdpdGhpbiB0aGUgcmlnaHRzIG9mIGluZGl2aWR1YWwg YXV0aG9ycywgb2YgY291cnNlLiBIb3dldmVyLCBvbmNlIHRoaXMgYmVjb21lcyBhIFdHIGRyYWZ0 LCBJIGhvcGUgd2UgY2FuIHJldmlzaXQgdGhhdCBkaXNjdXNzaW9uLg0KDQpUaGFua3MsDQpBbmR5 DQoNCg0KT24gVHVlLCBBdWcgMjYsIDIwMTQgYXQgNzo0MCBBTSwgSmltIEd1aWNoYXJkIChqZ3Vp Y2hhcikgPGpndWljaGFyQGNpc2NvLmNvbTxtYWlsdG86amd1aWNoYXJAY2lzY28uY29tPj4gd3Jv dGU6DQpHcmVldGluZ3MgV0c6DQoNClRoaXMgbWVzc2FnZSBiZWdpbnMgYSB0d28gd2VlayBjYWxs IGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZS0wMiBbaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVy ZS9dIGVuZGluZyBTZXB0ZW1iZXIgOXRoIDIwMTQuDQoNClBsZWFzZSByZXNwb25kIHRvIHRoZSBT RkMgbWFpbGluZyBsaXN0IHdpdGggYW55IHN0YXRlbWVudHMgb2YgYXBwcm92YWwgb3IgZGlzYXBw cm92YWwuDQoNCkFzIGFsd2F5cywgcGxlYXNlIG5vdGU6DQoNCiAgMS4gIFRoaXMgaXMgbm90IFdH IExhc3QgQ2FsbC4gVGhlIGRvY3VtZW50IGlzIG5vdCBmaW5hbCwgYW5kIHRoZSBXRyBpcyBleHBl Y3RlZCB0byBtb2RpZnkgdGhlIGRvY3VtZW504oCZcyBjb250ZW50IHVudGlsIHRoZXJlIGlzIFdH IGNvbnNlbnN1cyB0aGF0IHRoZSBjb250ZW50IGlzIHNvbGlkLiBUaGVyZWZvcmUsIHBsZWFzZSBk b27igJl0IG9wcG9zZSBhZG9wdGlvbiBqdXN0IGJlY2F1c2UgeW91IHdhbnQgdG8gc2VlIGNoYW5n ZXMgdG8gaXRzIGNvbnRlbnQuDQogIDIuICBJZiB5b3UgaGF2ZSBvYmplY3Rpb25zIHRvIGFkb3B0 aW9uIG9mIHRoZSBkb2N1bWVudCwgcGxlYXNlIHN0YXRlIHlvdXIgcmVhc29ucyB3aHksIGFuZCBl eHBsYWluIHdoYXQgaXQgd291bGQgdGFrZSB0byBhZGRyZXNzIHlvdXIgY29uY2VybnMuDQogIDMu ICBJZiB5b3UgaGF2ZSBpc3N1ZXMgd2l0aCB0aGUgY29udGVudCwgYnkgYWxsIG1lYW5zIHJhaXNl IHRob3NlIGlzc3VlcyBhbmQgd2UgY2FuIGJlZ2luIGEgZGlhbG9nIGFib3V0IGhvdyBiZXN0IHRv IGFkZHJlc3MgdGhlbS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0K --_000_2691CE0099834E4A9C5044EEC662BB9D453DC968dfweml701chm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1p ZDoyNjkxNjg4ODE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMzE4MjYxOTYyO30NCm9sDQoJ e21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U3VwcG9ydCB0aGUgV0cgYWRvcHRpb24gYW5k IEFuZHnigJlzIHBvaW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MdWN5PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+QW5kcmV3IEcuIE1hbGlzPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEF1Z3VzdCAy NiwgMjAxNCAxMjowNyBQTTxicj4NCjxiPlRvOjwvYj4gSmltIEd1aWNoYXJkIChqZ3VpY2hhcik8 YnI+DQo8Yj5DYzo8L2I+IHNmY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Nm Y10gQ2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUt MDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkppbSw8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc3VwcG9ydCB0aGUg YWRvcHRpb24gb2YgdGhpcyBkcmFmdCBieSB0aGUgV0cuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkR1cmluZyB0aGUgZGlzY3Vzc2lvbiBvZiBy ZXZpc2lvbiAtMDEsIGFsdGhvdWdoIGEgbnVtYmVyIG9mIFdHIHBhcnRpY2lwYW50cyByZXF1ZXN0 ZWQgYSBtb3JlIGZsZXhpYmxlIHdvcmRpbmcgb2YgdGhlIFNGQyBlbmNhcHN1bGF0aW9uIGRlZmlu aXRpb24sIGl0IHdhcyB1bmNoYW5nZWQgZnJvbSAtMDEgdG8gLTAyLiBUaGlzIGlzIHdpdGhpbiB0 aGUgcmlnaHRzIG9mIGluZGl2aWR1YWwgYXV0aG9ycywgb2YgY291cnNlLg0KIEhvd2V2ZXIsIG9u Y2UgdGhpcyBiZWNvbWVzIGEgV0cgZHJhZnQsIEkgaG9wZSB3ZSBjYW4gcmV2aXNpdCB0aGF0IGRp c2N1c3Npb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgQXVnIDI2 LCAyMDE0IGF0IDc6NDAgQU0sIEppbSBHdWljaGFyZCAoamd1aWNoYXIpICZsdDs8YSBocmVmPSJt YWlsdG86amd1aWNoYXJAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+amd1aWNoYXJAY2lzY28u Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+R3Jl ZXRpbmdzIFdHOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhp cyBtZXNzYWdlIGJlZ2lucyBhIHR3byB3ZWVrIGNhbGwgZm9yIFdHIGFkb3B0aW9uIG9mIGRyYWZ0 LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAyIFs8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLyIgdGFyZ2V0PSJfYmxh bmsiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWVyZ2VkLXNmYy1hcmNo aXRlY3R1cmUvPC9hPl0mbmJzcDtlbmRpbmcNCiBTZXB0ZW1iZXIgOXRoIDIwMTQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlBsZWFzZSByZXNwb25kIHRvIHRoZSBTRkMgbWFp bGluZyBsaXN0IHdpdGggYW55IHN0YXRlbWVudHMgb2YgYXBwcm92YWwgb3IgZGlzYXBwcm92YWwu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFzIGFsd2F5cywgcGxlYXNlIG5v dGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEi Pg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEg bGZvMSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoaXMgaXMgbm90IFdHIExhc3Qg Q2FsbC4gVGhlIGRvY3VtZW50IGlzIG5vdCBmaW5hbCwgYW5kIHRoZSBXRyBpcyBleHBlY3RlZCB0 byBtb2RpZnkgdGhlIGRvY3VtZW504oCZcyBjb250ZW50IHVudGlsIHRoZXJlIGlzIFdHIGNvbnNl bnN1cyB0aGF0IHRoZSBjb250ZW50IGlzIHNvbGlkLiBUaGVyZWZvcmUsIHBsZWFzZSBkb27igJl0 IG9wcG9zZQ0KIGFkb3B0aW9uIGp1c3QgYmVjYXVzZSB5b3Ugd2FudCB0byBzZWUgY2hhbmdlcyB0 byBpdHMgY29udGVudC48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5JZiB5b3UgaGF2ZSBvYmplY3Rpb25zIHRvIGFkb3B0aW9uIG9mIHRoZSBk b2N1bWVudCwgcGxlYXNlIHN0YXRlIHlvdXIgcmVhc29ucyB3aHksIGFuZCBleHBsYWluIHdoYXQg aXQgd291bGQgdGFrZSB0byBhZGRyZXNzIHlvdXIgY29uY2VybnMuPG86cD48L286cD48L3NwYW4+ PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVs MSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91IGhhdmUgaXNzdWVz IHdpdGggdGhlIGNvbnRlbnQsIGJ5IGFsbCBtZWFucyByYWlzZSB0aG9zZSBpc3N1ZXMgYW5kIHdl IGNhbiBiZWdpbiBhIGRpYWxvZyBhYm91dCBob3cgYmVzdCB0byBhZGRyZXNzIHRoZW0uPG86cD48 L286cD48L3NwYW4+PC9saT48L29sPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzZmMgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2691CE0099834E4A9C5044EEC662BB9D453DC968dfweml701chm_-- From nobody Tue Aug 26 14:56: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 201401A0115 for ; Tue, 26 Aug 2014 14:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NkOZQWvwWt8R for ; Tue, 26 Aug 2014 14:56:48 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 737841A00E1 for ; Tue, 26 Aug 2014 14:56:48 -0700 (PDT) Received: from emg-ca-1-2 (localhost [127.0.0.1]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id D898D53E64; Tue, 26 Aug 2014 14:55:28 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Tue, 26 Aug 2014 14:55:28.863 -0700 x-echoworx-msg-id: 4813615a-7e2d-4b49-a4a9-ff1c49691680 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-2 (JAMES SMTP Server 2.3.2) with SMTP ID 223; Tue, 26 Aug 2014 14:55:28 -0700 (PDT) Received: from HUB021-CA-6.exch021.domain.local (unknown [10.254.4.92]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id BC3BB53E64; Tue, 26 Aug 2014 14:55:28 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0174.001; Tue, 26 Aug 2014 14:56:47 -0700 From: Ron Parker To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: Call for WG adoption of draft-merged-sfc-architecture-02 Thread-Index: AQHPwSKarKFwlbPq2EakRGFWvH7bz5vjbuRg Date: Tue, 26 Aug 2014 21:56:47 +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] x-source-routing-agent: Processed Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A90A9BAMBX021W3CA2exch_" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/zc11XR1LmQGI1oOc__y3Jac3Rsk Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-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: Tue, 26 Aug 2014 21:56:50 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A90A9BAMBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Tuesday, August 26, 2014 7:41 AM To: sfc@ietf.org Subject: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 Greetings WG: This message begins a two week call for WG adoption of draft-merged-sfc-arc= hitecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-architecture= /] ending September 9th 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. 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_CDF2F015F4429F458815ED2A6C2B6B0B1A90A9BAMBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 <= /p>

   Ron

 

From: sfc [m= ailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, August 26, 2014 7:41 AM
To: sfc@ietf.org
Subject: [sfc] Call for WG adoption of draft-merged-sfc-architecture= -02

 

Greetings WG:

 

This message begins a two w= eek call for WG adoption of draft-merged-sfc-architecture-02 [http://datatr= acker.ietf.org/doc/draft-merged-sfc-architecture/] ending September 9th 2014.

 

Please respond to the SFC m= ailing 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_CDF2F015F4429F458815ED2A6C2B6B0B1A90A9BAMBX021W3CA2exch_-- From nobody Tue Aug 26 15:26: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 7B3A51A00EC for ; Tue, 26 Aug 2014 15:26:29 -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 uEkWhNMVfVMl for ; Tue, 26 Aug 2014 15:26:28 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 040751A0118 for ; Tue, 26 Aug 2014 15:26:27 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id fp1so23579837pdb.13 for ; Tue, 26 Aug 2014 15:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=FQwtCZYUcSgoHw8hk9OioIv8eJLH+CxSKbdCaBJPlEs=; b=dj4LsfhppYxn3BMrhiYrasM4SXbUWNat76VeDoalbqhJmICJAqVITTT4rBw9GC5SVQ /lKdnfjhfzTi24RCb4XQ/cTorpzStuWGkM88pLlM5Qs64DuOAOtQQo/OdBzaJ5EQhwOl 7Bt+tUrLsz0mlNt7tcOJXlPdGN75pz4eSZ8HH9P/vlHMhM6tf/VhlmzlBeqbSSTIzXbb Cv/zkcylLTbWXjph+QI2BkWC7AbKmdfDiug0+aWZBB89Rq5HmGtWqz3LGUa6WIm6EO9K Xzq8fCC+jP9oPxcFsK95A0sE0AktJPmYDoGNI4lC0ADJhx4NxkRgFHpdKi5TauodMbvs IEQw== X-Received: by 10.66.222.132 with SMTP id qm4mr16991283pac.140.1409091987693; Tue, 26 Aug 2014 15:26:27 -0700 (PDT) Received: from [10.94.182.211] (mobile-166-171-251-186.mycingular.net. [166.171.251.186]) by mx.google.com with ESMTPSA id td4sm4332923pbc.36.2014.08.26.15.26.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Aug 2014 15:26:26 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-A08ACC4D-8349-4115-8A24-82BAA67CC981 Content-Transfer-Encoding: 7bit Message-Id: <872C5C6A-7A30-4685-97B2-04274F553807@gmail.com> X-Mailer: iPhone Mail (11D257) From: Sam Aldrin Date: Tue, 26 Aug 2014 15:26:24 -0700 To: "Jim Guichard (jguichar)" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/X-5b0V9RnlJJPqpym_hVtaiblLY Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-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: Tue, 26 Aug 2014 22:26:29 -0000 --Apple-Mail-A08ACC4D-8349-4115-8A24-82BAA67CC981 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Support adoption of this version as WG doc. Cheers Sam Sent from my iPhone > On Aug 26, 2014, at 4:40 AM, "Jim Guichard (jguichar)" wrote: >=20 > Greetings WG: >=20 > This message begins a two week call for WG adoption of draft-merged-sfc-ar= chitecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-architecture= /] ending September 9th 2014. >=20 > Please respond to the SFC mailing list with any statements of approval or d= isapproval. >=20 > As always, please note: > This is not WG Last Call. The document is not final, and the WG is expecte= d to modify the document=E2=80=99s content until there is WG consensus that t= he content is solid. Therefore, please don=E2=80=99t oppose adoption just be= cause you want to see changes to its content. > If you have objections to adoption of the document, please state your reas= ons why, and explain what it would take to address your concerns. > If you have issues with the content, by all means raise those issues and w= e can begin a dialog about how best to address them. > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail-A08ACC4D-8349-4115-8A24-82BAA67CC981 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Support adoption of this version as WG= doc.

Cheers
Sam

Sent from my iPho= ne

On Aug 26, 2014, at 4:40 AM, "Jim Guichard (jguichar)" <= jguichar@cisco.com> wrote:
<= br>
Greetings WG:

This message begins a two week call for WG adoption of draft-merged-sfc= -architecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-architectu= re/] ending September 9th 2014.

Please respond to the SFC mailing list with any statements of approval o= r disapproval.

As always, please note:
=
  1. This is not WG Last Ca= ll. The document is not final, and the WG is expected to modify the document= =E2=80=99s content until there is WG consensus that the content is solid. Th= erefore, please don=E2=80=99t oppose adoption just because you want to see changes to its content.
  2. <= span lang=3D"EN-US" style=3D"font-size: 10.5pt;">If you have objections to a= doption 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 a= ll 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/lis= tinfo/sfc
= --Apple-Mail-A08ACC4D-8349-4115-8A24-82BAA67CC981-- From nobody Tue Aug 26 15:47: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 42A281A008F for ; Tue, 26 Aug 2014 15:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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.668, 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 d-2B-lb04-q8 for ; Tue, 26 Aug 2014 15:47:49 -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 F0F741A0030 for ; Tue, 26 Aug 2014 15:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19705; q=dns/txt; s=iport; t=1409093270; x=1410302870; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=RTxo5mgY3fLDjucN0JZHPTPPs25Tpa6a2Wf2eaZzDxU=; b=T1uZpUD6+xQWTtSphGh5UC1LQuRUf7NhN60gIG5zWhZYvC0ItW8aOK4K LRQl6+U1F1SqRq/rwcPyB4H+I29t1Tfmys1lnTzesEMOXLXhNRknKW51G fOLyoAw7T9ZNTXv1HGqPG/VxoVY9MfyOhzfnD5u8qyfyUM5kfWrHCsKk+ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFADMO/VOtJV2b/2dsb2JhbABbgmojU00GBATMUAENh0gBgRIWd4QDAQEBAgIBAQEaSgcJAhACAQgRAQIBAigHJwsUAwYIAgQOBQkSiCcBBwW/TxeOahEBPw0EBgEGA4MmgR0FjxmCFIQrhCuCUYEyJpM8g15sAYEOOYEHAQEB X-IronPort-AV: E=Sophos;i="5.04,407,1406592000"; d="scan'208,217";a="350530340" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 26 Aug 2014 22:47:40 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s7QMlceT024775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 26 Aug 2014 22:47:38 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Tue, 26 Aug 2014 17:47:38 -0500 From: "Carlos Pignataro (cpignata)" To: "Naiming Shen (naiming)" Thread-Topic: [sfc] New Version Notification for draft-merged-sfc-architecture-02.txt Thread-Index: AQHPwX+823D98hH+hEyK09QTQQiCow== Date: Tue, 26 Aug 2014 22:47:37 +0000 Message-ID: <4B25B0E0-F6D5-49A6-BA1C-17B8195038CD@cisco.com> References: <20140822165913.29275.92328.idtracker@ietfa.amsl.com> <53FB6D2E.3010202@cisco.com> <5DE5431F-8519-4E8C-8A0B-49465A4A7857@cisco.com> In-Reply-To: <5DE5431F-8519-4E8C-8A0B-49465A4A7857@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.238.17] Content-Type: multipart/alternative; boundary="_000_4B25B0E0F6D549A6BA1C17B8195038CDciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/vFiOOCFRATtbM7hkMzDPy6PlvUw Cc: "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-merged-sfc-architecture-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: Tue, 26 Aug 2014 22:47:51 -0000 --_000_4B25B0E0F6D549A6BA1C17B8195038CDciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Naiming, You are right -- this is covered in Section 4.3, under "Terminating SFPs", = we can massage the definition some more. THanks, Carlos. On Aug 25, 2014, at 4:47 PM, Naiming Shen > wrote: On Aug 25, 2014, at 1:36 PM, Naiming Shen > wrote: Carlos, One of the function of SFF could be to "de-encapsulate" the SFC, it can be = the case of the last hop on the SFC list, there may not be any SF associated with the SFF, but o= nly to remove the service transport and NSH header and to forward the packet normally. Otherwise, after the last SF/SFF service function, service header and trans= port is removed, the packet could route through the original "classifier" device again and i= t has no information that packet has already gone through the SFC defined. This can cause loopin= g. This of course depends on where the location of the last SFF in the topology. One way to s= olve this can be to define the SFC last item being the SFF which is the next-hop of the c= lassifier device in normal routing/forwarding to make sure the classifier device will to see th= is packet in original typo, "=85 will not see this =85" format(without NSH and transport) twice. thanks. - Naiming On Aug 25, 2014, at 12:14 PM, "Carlos Pignataro (cpignata)" > wrote: Reinaldo, Thanks for the comment, good set of points. It does seem that the definitio= n itself might be unnecessarily overly restrictive. We could say "zero or more" or we could say "typically one or more", but I = think it is better to spell out the function. Here's one more comprehensive= proposal: Old: Service Function Forwarder (SFF): A service function forwarder is responsible for delivering traffic received from the network to one or more connected service functions according to information carried in the SFC encapsulation. New: Service Function Forwarder (SFF): A service function forwarder is responsible for delivering traffic received from the network to one or more connected service functions according to information carried in the SFC encapsulation, as well as for delivering traffic= to a classifier or mapping out traffic to another SFF (in the same or different type of overlay). WG, Reinaldo, Thoughts? Thanks, Carlos. On Aug 25, 2014, at 1:06 PM, Reinaldo Penno > wrote: A couple of points about SFF definition. You mention "one or more connected= service functions" But in our implementation we have two types of SFFs that do not have SFs: - A SFF that maps from one overlay to another, say, VXLAN to GRE - A SFF that only has a classifier (no SFs in itself) Where would they fit or how to to make sure the architecture can predict th= eir usage? thanks, On 8/23/14 1:47 PM, Carlos Pignataro (cpignata) wrote: SFC, Please find below the email notice of a new revision of draft-merged-sfc-ar= chitecture. Full set of diffs from -00 (IETF90) to -02 (now) can be seen here: http://w= ww.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-02&url1=3Ddraft-me= rged-sfc-architecture-00 We still expect further changes to the document; but we also believe that t= his revision captures the key points and addresses the key open items, as p= lanned in Toronto. The key objective being to create a single document basis for the SFC archi= tecture. SFC Chairs, We believe that this revision fulfills the next steps agreed in Toronto (ht= tp://tools.ietf.org/agenda/90/slides/slides-90-sfc-3.pdf). This revision, while we expect changes, is now close enough that we think i= t makes sense for the WG to take it as the basis for the WG document to add= ress the deliverable. draft-merged-sfc-architecture-02 addressed the key points -- and we believe= is ready to start a poll for adoption. Can you please initiate that WG ado= ption call for draft-merged-sfc-architecture-02? Thanks, Carlos & Joel. Begin forwarded message: From: > Subject: New Version Notification for draft-merged-sfc-architecture-02.txt Date: August 22, 2014 at 12:59:13 PM EDT To: Joel Halpern >, Carlos = Pignataro >, "Joel M. Halpern= " >, Carlos Pignataro > A new version of I-D, draft-merged-sfc-architecture-02.txt has been successfully submitted by Carlos Pignataro and posted to the IETF repository. Name: draft-merged-sfc-architecture Revision: 02 Title: Service Function Chaining (SFC) Architecture Document date: 2014-08-22 Group: Individual Submission Pages: 26 URL: http://www.ietf.org/internet-drafts/draft-merged-sfc-archit= ecture-02.txt Status: https://datatracker.ietf.org/doc/draft-merged-sfc-architect= ure/ Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-archite= cture-02 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 submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ 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 --_000_4B25B0E0F6D549A6BA1C17B8195038CDciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Naiming,

You are right -- this is covered in Section 4.3, under "Terminati= ng SFPs", we can massage the definition some more.

THanks,

Carlos.

On Aug 25, 2014, at 4:47 PM, Naiming Shen <naiming@cisco.com> wrote:


On Aug 25, 2014, at 1:36 PM, Naiming Shen <naiming@cisco.com> wrote:


Carlos,

One of the function of SFF could be to "de-encapsulate" the = SFC, it can be the case of the last
hop on the SFC list, there may not be any SF associated with the SFF, = but only to remove the service
transport and NSH header and to forward the packet normally.

Otherwise, after the last SF/SFF service function, service header and = transport is removed,
the packet could route through the original "classifier" dev= ice again and it has no information
that packet has already gone through the SFC defined. This can cause l= ooping. This of course
depends on where the location of the last SFF in the topology. One way= to solve this can
be to define the SFC last item being the SFF which is the next-hop of = the classifier device in
normal routing/forwarding to make sure the classifier device will to s= ee this packet in original

typo, "=85 will not see this =85"

format(without NSH and transport) twice.

thanks.
- Naiming

On Aug 25, 2014, at 12:14 PM, "Carlos Pignataro (cpignata)" = <cpignata@cisco.com> wrote:=

Reinaldo,

Thanks for the comment, good set of points. It does seem that the defi= nition itself might be unnecessarily overly restrictive.

We could say "zero or more" or we could say "typically = one or more", but I think it is better to spell out the function. Here= 's one more comprehensive proposal:

Old:
   Service Function Forwarder (SFF):  A service functio= n forwarder is
        responsible for delivering traffic receive= d from the network to
        one or more connected service functions ac= cording to information
        carried in the SFC encapsulation.

New:
   Service Function Forwarder (SFF):  A service functio= n forwarder is
        responsible for delivering traffic receive= d from the network to
        one or more connected service functions ac= cording to information
        carried in the SFC encapsulation, as well = as for delivering traffic to
        a classifier or mapping out traffic to ano= ther SFF (in the same or
        different type of overlay).

WG, Reinaldo,

Thoughts?

Thanks,

Carlos.

On Aug 25, 2014, at 1:06 PM, Reinaldo Penno <repenno@cisco.com> wrote:

A couple of points about SFF defi= nition. You mention "one or more connected service functions"

But in our implementation we have two types of SFFs that do not have SFs:
- A SFF that maps from one overlay to another, say, VXLAN to GRE
- A SFF that only has a classifier (no SFs in itself)

Where would they fit or how to to make sure the architecture can predict th= eir usage?

thanks,

On 8/23/14 1:47 PM, Carlos Pignataro (cpigna= ta) wrote:
SFC,

Please find below the email notice of a new revision of draft-mer= ged-sfc-architecture.

Full set of diffs from -00 (IETF90) to -02 (now) can be seen here:&nbs= p;http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-02&ur= l1=3Ddraft-merged-sfc-architecture-00

We still expect further changes to the document; but we also believe t= hat this revision captures the key points and addresses the key open items,= as planned in Toronto.

The key objective being to create a single document basis for the SFC = architecture.

SFC Chairs,

We believe that this revision fulfills the next steps agreed in Toront= o (http://tools.ietf.org/agenda/90/slides/slides-90-sf= c-3.pdf). 

This revision, while we expect changes, is now close enough that = we think it makes sense for the WG to take it as the basis for the WG docum= ent to address the deliverable.

draft-merged-sfc-architecture-02 addressed the key points -- and we be= lieve is ready to start a poll for adoption. Can you please initiate that W= G adoption call for draft-merged-sfc-architecture-02?

Thanks,

Carlos & Joel.


Begin forwarded message:

Subject: New Version Notification for draft-merged-= sfc-architecture-02.txt
Date: August 22, 2014 at 12:59:13 PM EDT
To: Joel Halpern <jmh@joelhalpern.com>, Carlos Pignata= ro <cpign= ata@cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Carlos Pignataro <cpignata@cisco.= com>


A new version of I-D, draft-merged-sfc-architecture-02.txt
has been successfully submitted by Carlos Pignataro and posted to the
IETF repository.

Name: draft-merged-sfc= -architecture
Revision: 0= 2
Title: Service Functio= n Chaining (SFC) Architecture
Document date: 2014-08-22
Group: Individual Subm= ission
Pages: 26
URL:            http://www.ietf.org/internet-drafts/draft-me= rged-sfc-architecture-02.txt
Status:         https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/=
Htmlized:       http://= tools.ietf.org/html/draft-merged-sfc-architecture-02
Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-ar= chitecture-02

Abstract:
  This document describes an architecture for the specification,<= br>   creation, and ongoing maintenance of Service Function Chains (S= FC) in
  a network.  It includes architectural concepts, principles= , and
  components used in the construction of composite services throu= gh
  deployment of SFCs.  This document does not propose soluti= ons,
  protocols, or extensions to existing protocols.




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

The IETF Secretariat




_______________________________________________
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



--_000_4B25B0E0F6D549A6BA1C17B8195038CDciscocom_-- From nobody Tue Aug 26 15:56: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 6F7701A0032 for ; Tue, 26 Aug 2014 15:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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.668, 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 J-ixgHu3uwkF for ; Tue, 26 Aug 2014 15:56:42 -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 0C6CE1A0041 for ; Tue, 26 Aug 2014 15:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31880; q=dns/txt; s=iport; t=1409093802; x=1410303402; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zDtmwl+QO2CQj0UWu1Mox/IxLS4n9oOnfwpBom+jpi4=; b=P1UfUbjxnitDZXVMCKjJKSTzVoiuvUBVW1foPYC7qbddaStrR/3G7k+h M3jjWKilNV0E4v3HGohqFGfpI2f7ZOgF/KgkRGUeg8gvqACfM7EsN7q0i GkEDhKegrPBtex7XNrqJEmZnePolTd6noxwG1VmT5pVigbgi84WHkJdWf Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAOsP/VOtJV2U/2dsb2JhbABbgkcjI1NTBATKdoFaAQ2HSAGBEhZ3hAMBAQECAgEBARpKBwkCEAIBCBEBAgEBASEBBgcnCxQDBggCBA4FCRKIJwEHBb9PF4l/hGsRAT8NBAYBBgODJoEdBY8ZghSEK4QrglGBMiaTPIFHghdsAYEOOYEHAQEB X-IronPort-AV: E=Sophos;i="5.04,407,1406592000"; d="scan'208,217";a="350486189" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP; 26 Aug 2014 22:56:41 +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 s7QMue9E014116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Aug 2014 22:56:40 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Tue, 26 Aug 2014 17:56:40 -0500 From: "Carlos Pignataro (cpignata)" To: "Hongyu Li (Julio)" Thread-Topic: [sfc] New Version Notification for draft-merged-sfc-architecture-02.txt Thread-Index: AQHPwYD+wyhYF61HnU2/LlB5ZDWM6g== Date: Tue, 26 Aug 2014 22:56:39 +0000 Message-ID: <670D50FB-EC3D-4741-B0CE-207CC75FFF14@cisco.com> References: <20140822165913.29275.92328.idtracker@ietfa.amsl.com> <53FB6D2E.3010202@cisco.com> <6EB34CB5D82C4645B826C56144826EA97EA59B54@SZXEMA509-MBX.china.huawei.com> In-Reply-To: <6EB34CB5D82C4645B826C56144826EA97EA59B54@SZXEMA509-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.238.17] Content-Type: multipart/alternative; boundary="_000_670D50FBEC3D4741B0CE207CC75FFF14ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/TmmwPkix5whQIFHjINJfuvdI3Rc Cc: "Reinaldo Penno \(repenno\)" , "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-merged-sfc-architecture-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: Tue, 26 Aug 2014 22:56:44 -0000 --_000_670D50FBEC3D4741B0CE207CC75FFF14ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Hongyu, Thanks for this comment. Functionally, the Classifier is an architectural c= omponent different and separated from the SFF. This architecture does not p= revent an implementation of a classifier and SFF in a discrete element and = the delivery via an internal interface. But I believe architecturally is im= portant to separate the functions of SFF versus the functions of a Classifi= er, instead of saying that a classifier can be "inside an SFF" or be "the n= ext SFF". Thanks, Carlos. On Aug 25, 2014, at 8:57 PM, Hongyu Li (Julio) > wrote: Hi Carlos, For the new definition, not sure =93delivering traffic to a classifier=94 i= s the best way to say. In case the classifier is inside the current SFF, it= is better to say the SFF re-/classify the traffic than deliver it to a cla= ssifier. In case the classifier is in the next SFF, the current SFF would o= nly forward the traffic to the next SFF, without knowing or caring about if= there is a classifier there. Cheers, Hongyu From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpig= nata) Sent: Tuesday, August 26, 2014 3:15 AM To: Reinaldo Penno (repenno) Cc: sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-archi= tecture-02.txt Reinaldo, Thanks for the comment, good set of points. It does seem that the definitio= n itself might be unnecessarily overly restrictive. We could say "zero or more" or we could say "typically one or more", but I = think it is better to spell out the function. Here's one more comprehensive= proposal: Old: Service Function Forwarder (SFF): A service function forwarder is responsible for delivering traffic received from the network to one or more connected service functions according to information carried in the SFC encapsulation. New: Service Function Forwarder (SFF): A service function forwarder is responsible for delivering traffic received from the network to one or more connected service functions according to information carried in the SFC encapsulation, as well as for delivering traffic= to a classifier or mapping out traffic to another SFF (in the same or different type of overlay). WG, Reinaldo, Thoughts? Thanks, Carlos. On Aug 25, 2014, at 1:06 PM, Reinaldo Penno > wrote: A couple of points about SFF definition. You mention "one or more connected= service functions" But in our implementation we have two types of SFFs that do not have SFs: - A SFF that maps from one overlay to another, say, VXLAN to GRE - A SFF that only has a classifier (no SFs in itself) Where would they fit or how to to make sure the architecture can predict th= eir usage? thanks, On 8/23/14 1:47 PM, Carlos Pignataro (cpignata) wrote: SFC, Please find below the email notice of a new revision of draft-merged-sfc-ar= chitecture. Full set of diffs from -00 (IETF90) to -02 (now) can be seen here: http://w= ww.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-02&url1=3Ddraft-me= rged-sfc-architecture-00 We still expect further changes to the document; but we also believe that t= his revision captures the key points and addresses the key open items, as p= lanned in Toronto. The key objective being to create a single document basis for the SFC archi= tecture. SFC Chairs, We believe that this revision fulfills the next steps agreed in Toronto (ht= tp://tools.ietf.org/agenda/90/slides/slides-90-sfc-3.pdf). This revision, while we expect changes, is now close enough that we think i= t makes sense for the WG to take it as the basis for the WG document to add= ress the deliverable. draft-merged-sfc-architecture-02 addressed the key points -- and we believe= is ready to start a poll for adoption. Can you please initiate that WG ado= ption call for draft-merged-sfc-architecture-02? Thanks, Carlos & Joel. Begin forwarded message: From: > Subject: New Version Notification for draft-merged-sfc-architecture-02.txt Date: August 22, 2014 at 12:59:13 PM EDT To: Joel Halpern >, Carlos = Pignataro >, "Joel M. Halpern= " >, Carlos Pignataro > A new version of I-D, draft-merged-sfc-architecture-02.txt has been successfully submitted by Carlos Pignataro and posted to the IETF repository. Name: draft-merged-sfc-architecture Revision: 02 Title: Service Function Chaining (SFC) Architecture Document date: 2014-08-22 Group: Individual Submission Pages: 26 URL: http://www.ietf.org/internet-drafts/draft-merged-sfc-archit= ecture-02.txt Status: https://datatracker.ietf.org/doc/draft-merged-sfc-architect= ure/ Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-archite= cture-02 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 submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ 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 --_000_670D50FBEC3D4741B0CE207CC75FFF14ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi, Hongyu,

Thanks for this comment. Functionally, the Classifier is an architectu= ral component different and separated from the SFF. This architecture does = not prevent an implementation of a classifier and SFF in a discrete element= and the delivery via an internal interface. But I believe architecturally is important to separate the func= tions of SFF versus the functions of a Classifier, instead of saying that a= classifier can be "inside an SFF" or be "the next SFF"= .

Thanks,

Carlos.

On Aug 25, 2014, at 8:57 PM, Hongyu Li (Julio) <hongyu.li@huawei.com> wrote:

Hi Carlos,
 
For the new definition, not sure =93deliv= ering traffic to a classifier=94 is the best way to say. In case the classi= fier is inside the current SFF, it is better to say the SFF re-/classify the traffic than deliver it to a classifier. I= n case the classifier is in the next SFF, the current SFF would only forwar= d the traffic to the next SFF, without knowing or caring about if there is = a classifier there.
 
Cheers,
Hongyu
 
From: = sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pig= nataro (cpignata)
Sent: Tuesday, Aug= ust 26, 2014 3:15 AM
To: Reinaldo Penno= (repenno)
Cc: sfc@= ietf.org
Subject: Re: [sfc]= Fwd: New Version Notification for draft-merged-sfc-architecture-02.txt
 
Reinaldo,
 
Thanks for the comment, good set of points. It does se= em that the definition itself might be unnecessarily overly restrictive.
 
We could say "zero or more" or we could say = "typically one or more", but I think it is better to spell out th= e function. Here's one more comprehensive proposal:
 
Old:
   Service Function Forwarder (SFF):  A= service function forwarder is
        responsible for delivering= traffic received from the network to
        one or more connected serv= ice functions according to information
        carried in the SFC encapsu= lation.
 
New:
   Service Function Forwarder (SFF):  A= service function forwarder is
        responsible for delivering= traffic received from the network to
        one or more connected serv= ice functions according to information
        carried in the SFC encapsu= lation, as well as for delivering traffic to
        a classifier or mapping ou= t traffic to another SFF (in the same or
        different type of overlay)= .
 
WG, Reinaldo,
 
Thoughts?
 
Thanks,
 
Carlos.
 
On Aug 25, 2014, at 1:06 PM, Reinaldo Penno <repenno@cisco.com> wrote:


A couple of points about SFF definition. You mention &= quot;one or more connected service functions" 

But in our implementation we have two types of SFFs that do not have SFs:
- A SFF that maps from one overlay to another, say, VXLAN to GRE
- A SFF that only has a classifier (no SFs in itself)

Where would they fit or how to to make sure the architecture can predict th= eir usage?

thanks,

On 8/23/14 1:47 PM, Carlos Pignataro (cpignata) wrote:=
SFC,
 
Please find below the email notice of a new revision o= f draft-merged-sfc-architecture.
 
 
We still expect further changes to the document; but w= e also believe that this revision captures the key points and addresses the= key open items, as planned in Toronto.
 
The key objective being to create a single document ba= sis for the SFC architecture.
 
SFC Chairs,
 
We believe that this revision fulfills the next steps = agreed in Toronto (http://= tools.ietf.org/agenda/90/slides/slides-90-sfc-3.pdf). <= /span>
 
This revision, while we expect changes, is now cl= ose enough that we think it makes sense for the WG to take it as the basis = for the WG document to address the deliverable.
 
draft-merged-sfc-architecture-02 addressed the key poi= nts -- and we believe is ready to start a poll for adoption. Can you please= initiate that WG adoption call for draft-merged-sfc-architecture-02?<= /o:p>
 
Thanks,
 
Carlos & Joel.
 
 
Begin forwarded message:


Subje= ct: New Version Notification for draft-merged-sfc-architecture-02.txt
Date:=  August 22, 2014 at 12= :59:13 PM EDT
To: Joel Halpern <jmh@joelhalpern.com>, Carlos Pignataro <cpignata@cisco.com>, "Joe= l M. Halpern" <jmh@joelhalpern.com>, Carlos Pignataro <cpignata@cisco.com>
 


A new version of I-D, draft-merged-sfc-architecture-02.txt
has been successfully submitted by Carlos Pignataro and posted to the
IETF repository.

Name:&= nbsp;draft-merged-sfc-architecture
Revision: 02
Title:=  Service Function Chaining (SFC) Architecture
Document date: 2014-08-22
Group:=  Individual Submission
Pages:=  26
URL:            http://www.ietf.= org/internet-drafts/draft-merged-sfc-architecture-02.txt
Status:         https://datatracker.ietf.org/doc/draft-m= erged-sfc-architecture/
Htmlized:       http://tools.ietf.org/html/draft-merged-sfc-architectu= re-02
Diff:           http://www.ietf.org/rfcd= iff?url2=3Ddraft-merged-sfc-architecture-02

Abstract:
  This document describes an architecture for the specification,<= br>   creation, and ongoing maintenance of Service Function Chains (S= FC) in
  a network.  It includes architectural concepts, principles= , and
  components used in the construction of composite services throu= gh
  deployment of SFCs.  This document does not propose soluti= ons,
  protocols, or extensions to existing protocols.




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

The IETF Secretariat

 



___________________________________________=
____
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

--_000_670D50FBEC3D4741B0CE207CC75FFF14ciscocom_-- From nobody Tue Aug 26 15:58: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 380871A0068 for ; Tue, 26 Aug 2014 15:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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.668, 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 ZaZVoZo4DnFw for ; Tue, 26 Aug 2014 15:58:15 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60A801A0041 for ; Tue, 26 Aug 2014 15:58:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2566; q=dns/txt; s=iport; t=1409093895; x=1410303495; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UuNbi1tjEczz2kYhoVXSI5xcI0rdjNCEVrfwvSowTQc=; b=XoGkFn470JpNBFg6bqDI17t97iMo+cQGpJCUNKblSoVZqE/PoD/5oGXJ ECFuDkwA5wgOSc/m5CFkh00sv8ZFDs/3ujqyCeDIHRkKP+Rv5WiWMcu3n Ue90pa/FQPSOWiMZzO906+UW74fyQaVOiLvkt26w6MQCnKPUbeH82PrLW o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAFAQ/VOtJA2I/2dsb2JhbABbgmojgSAKBNQmAYESFneEBAEBBHcCEAIBCAQOLQcyFAMOAgQOBYhCAb9cF49MB4MvgR0BBJEtiyeVFINebIFIgQcBAQE X-IronPort-AV: E=Sophos; i="5.04,407,1406592000"; d="scan'208,217"; a="72646182" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP; 26 Aug 2014 22:58:14 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s7QMwEIp005383 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 26 Aug 2014 22:58:14 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Tue, 26 Aug 2014 17:58:14 -0500 From: "Carlos Pignataro (cpignata)" To: "Guy Meador III (meadorg)" Thread-Topic: [sfc] New Version Notification for draft-merged-sfc-architecture-02.txt Thread-Index: AQHPwKG+sZam2ET1wkSROKSQeJQt+JviFq+AgAG+T4A= Date: Tue, 26 Aug 2014 22:58:13 +0000 Message-ID: <03CB338C-3F84-4F44-94E3-EB336524227D@cisco.com> References: <20140822165913.29275.92328.idtracker@ietfa.amsl.com> <53FB6D2E.3010202@cisco.com> <71B70920-7353-4FD0-952C-EA32A5C20BF3@cisco.com> <8B40D0B8-872B-4C50-A786-4962C3656D57@cisco.com> In-Reply-To: <8B40D0B8-872B-4C50-A786-4962C3656D57@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.238.17] Content-Type: multipart/alternative; boundary="_000_03CB338C3F844F4494E3EB336524227Dciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/6A8qGwFwZbR5J_xgscTfXbJxIBs Cc: "Reinaldo Penno \(repenno\)" , "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-merged-sfc-architecture-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: Tue, 26 Aug 2014 22:58:17 -0000 --_000_03CB338C3F844F4494E3EB336524227Dciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thank you, Guy. On Aug 25, 2014, at 4:20 PM, Guy Meador III (meadorg) > wrote: That works, thanks. On Aug 25, 2014, at 4:18 PM, "Carlos Pignataro (cpignata)" > wrote: Sure -- perhaps add ", handling traffic coming back from the SF"? --_000_03CB338C3F844F4494E3EB336524227Dciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <67089B9ACE91E9418BF40CAA2CEB8C00@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Thank you, Guy.


That works, thanks.

On Aug 25, 2014, at 4:18 PM, "Carlos Pignataro (cpignata)" &= lt;cpignata@cisco.com>
 wrote:

Sure -- perhaps add ", handling traffic coming back from the SF"?



--_000_03CB338C3F844F4494E3EB336524227Dciscocom_-- From nobody Tue Aug 26 16:07: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 2D0F51A00B5 for ; Tue, 26 Aug 2014 16:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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.668, 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 OPL3Ksn9J8O1 for ; Tue, 26 Aug 2014 16:07:35 -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 024661A008F for ; Tue, 26 Aug 2014 16:07:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42380; q=dns/txt; s=iport; t=1409094455; x=1410304055; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZDvDASuxo0ZsvaoN8tNajHc9+zFIMYapJylLf/e8bZI=; b=McvQzaITdPUi4DP7taxLrVzfwvUucQapxdUzYO9wB2PN4jrKTA9G6QgC sexnKWXrslwy3OsIhO+9V4alXqD/8xkca9ruwrqKTCGvLXIbZH9HkjTmm PgASxbn8IXzH1OniF3Wt24CU0b7af3Mm3R4u2Pt+b9S7Z81pn/GxU6tF0 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMFALsS/VOtJA2H/2dsb2JhbABbgkcjI1NTBATKdoFaAQ2HSAGBEhZ3hAMBAQECAgEBARosHgcJAhACAQgHBwMBAgEBASEBBgcnCxQDBggCBA4FCRKIJwEHBb9RF4l/hGsRAT4BBwYBAwYBBgODJoEdBY8ZghSEK4QrglGBMiaTPINebAGBDjmBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,407,1406592000"; d="scan'208,217";a="350539264" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-8.cisco.com with ESMTP; 26 Aug 2014 23:07:34 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s7QN7XsW023340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Aug 2014 23:07:33 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Tue, 26 Aug 2014 18:07:33 -0500 From: "Carlos Pignataro (cpignata)" To: Alla Goldner Thread-Topic: [sfc] New Version Notification for draft-merged-sfc-architecture-02.txt Thread-Index: AQHPwYKEZBPXqTq7vESwxUMg8qfomA== Date: Tue, 26 Aug 2014 23:07:32 +0000 Message-ID: References: <20140822165913.29275.92328.idtracker@ietfa.amsl.com> <53FB6D2E.3010202@cisco.com> <6EB34CB5D82C4645B826C56144826EA97EA59B54@SZXEMA509-MBX.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.238.17] Content-Type: multipart/alternative; boundary="_000_B33506418642441788362EA521C6E27Cciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/GGXeIHcFbncRl1TXioOVluVMFJ8 Cc: "Hongyu Li \(Julio\)" , "Reinaldo Penno \(repenno\)" , "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-merged-sfc-architecture-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: Tue, 26 Aug 2014 23:07:38 -0000 --_000_B33506418642441788362EA521C6E27Cciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Alla, That's a good callout. How about adding the following following the sentenc= e you quoted? "Additionally, the SFF may preserve the handling of packets based on other = properties on top of a flow, such as a subscriber, session, or application = instance identification." Thanks, Carlos. On Aug 26, 2014, at 7:12 AM, Alla Goldner > wrote: Dear all, I have the following comment: =93 If there are multiple choices, the SFF needs to preserve the property that all packets of a given flow are handled the same way, since the SF may well be stateful. =93 A service may need additional levels of =93persistency=94 on top of a flow = (e.g. =96 all flows related to the same subscriber /session due to e.g. sec= urity reasons, all flows related to the same application instance). I believe it should also be reflected. Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com www.allot.com From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Hongyu Li (Julio) Sent: Tuesday, August 26, 2014 3:58 AM To: Carlos Pignataro (cpignata); Reinaldo Penno (repenno) Cc: sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-archi= tecture-02.txt Hi Carlos, For the new definition, not sure =93delivering traffic to a classifier=94 i= s the best way to say. In case the classifier is inside the current SFF, it= is better to say the SFF re-/classify the traffic than deliver it to a cla= ssifier. In case the classifier is in the next SFF, the current SFF would o= nly forward the traffic to the next SFF, without knowing or caring about if= there is a classifier there. Cheers, Hongyu From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpig= nata) Sent: Tuesday, August 26, 2014 3:15 AM To: Reinaldo Penno (repenno) Cc: sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-archi= tecture-02.txt Reinaldo, Thanks for the comment, good set of points. It does seem that the definitio= n itself might be unnecessarily overly restrictive. We could say "zero or more" or we could say "typically one or more", but I = think it is better to spell out the function. Here's one more comprehensive= proposal: Old: Service Function Forwarder (SFF): A service function forwarder is responsible for delivering traffic received from the network to one or more connected service functions according to information carried in the SFC encapsulation. New: Service Function Forwarder (SFF): A service function forwarder is responsible for delivering traffic received from the network to one or more connected service functions according to information carried in the SFC encapsulation, as well as for delivering traffic= to a classifier or mapping out traffic to another SFF (in the same or different type of overlay). WG, Reinaldo, Thoughts? Thanks, Carlos. On Aug 25, 2014, at 1:06 PM, Reinaldo Penno > wrote: A couple of points about SFF definition. You mention "one or more connected= service functions" But in our implementation we have two types of SFFs that do not have SFs: - A SFF that maps from one overlay to another, say, VXLAN to GRE - A SFF that only has a classifier (no SFs in itself) Where would they fit or how to to make sure the architecture can predict th= eir usage? thanks, On 8/23/14 1:47 PM, Carlos Pignataro (cpignata) wrote: SFC, Please find below the email notice of a new revision of draft-merged-sfc-ar= chitecture. Full set of diffs from -00 (IETF90) to -02 (now) can be seen here: http://w= ww.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-02&url1=3Ddraft-me= rged-sfc-architecture-00 We still expect further changes to the document; but we also believe that t= his revision captures the key points and addresses the key open items, as p= lanned in Toronto. The key objective being to create a single document basis for the SFC archi= tecture. SFC Chairs, We believe that this revision fulfills the next steps agreed in Toronto (ht= tp://tools.ietf.org/agenda/90/slides/slides-90-sfc-3.pdf). This revision, while we expect changes, is now close enough that we think i= t makes sense for the WG to take it as the basis for the WG document to add= ress the deliverable. draft-merged-sfc-architecture-02 addressed the key points -- and we believe= is ready to start a poll for adoption. Can you please initiate that WG ado= ption call for draft-merged-sfc-architecture-02? Thanks, Carlos & Joel. Begin forwarded message: From: > Subject: New Version Notification for draft-merged-sfc-architecture-02.txt Date: August 22, 2014 at 12:59:13 PM EDT To: Joel Halpern >, Carlos = Pignataro >, "Joel M. Halpern= " >, Carlos Pignataro > A new version of I-D, draft-merged-sfc-architecture-02.txt has been successfully submitted by Carlos Pignataro and posted to the IETF repository. Name: draft-merged-sfc-architecture Revision: 02 Title: Service Function Chaining (SFC) Architecture Document date: 2014-08-22 Group: Individual Submission Pages: 26 URL: http://www.ietf.org/internet-drafts/draft-merged-sfc-archit= ecture-02.txt Status: https://datatracker.ietf.org/doc/draft-merged-sfc-architect= ure/ Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-archite= cture-02 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 submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ 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 ________________________________ This message is intended only for the designated recipient(s). It may conta= in confidential or proprietary information. If you are not the designated r= ecipient, you may not review, copy or distribute this message. If you have = mistakenly received this message, please notify the sender by a reply e-mai= l and delete this message. Thank you. --_000_B33506418642441788362EA521C6E27Cciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6DEC67FFD4372942B214D1FC0E0D3930@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Alla,

That's a good callout. How about adding the following following the se= ntence you quoted?

"Additionally, the SFF may preserve the handling of packets based= on other properties on top of a flow, such as a subscriber, session, or ap= plication instance identification."

Thanks,

Carlos.

On Aug 26, 2014, at 7:12 AM, Alla Goldner <agoldner@allot.com> wrote:

Dear all,
 
I have the following comment:
=93
If there are m= ultiple choices, the SFF needs to preserve the property
   t= hat all packets of a given flow are handled the same way, since the
   S= F may well be stateful.
=93
 
A service may need additional levels of =93persistency=94 = on top of a flow (e.g. =96 all flows related to the same subscriber /sessio= n due to e.g. security reasons, all flows related to the same application instance).
 
I believe it should also be reflected.
 
Best regards,
 
 
 
Alla Goldner
Director of Mob= ile Technologies and Standards
Allot Communicatio= ns
Tel +972 9 7619251
Cell +972 54 2493985
Fax +972 9 7443626
 =
<image001.jp= g><= o:p>
 
 
From:<= /span> sfc [= mailto:sfc-bounces@ietf.org] = ;On Behalf Of Hongyu Li = (Julio)
Sent: Tuesday, Aug= ust 26, 2014 3:58 AM
To: Carlos Pignata= ro (cpignata); Reinaldo Penno (repenno)
Cc: sfc@= ietf.org
Subject: Re: [sfc]= Fwd: New Version Notification for draft-merged-sfc-architecture-02.txt
 
Hi Carlos,
 
For the new definition, not sure =93delivering traffic t= o a classifier=94 is the best way to say. In case the classifier is inside = the current SFF, it is better to say the SFF re-/classify the traffic than deliver it to a classifier. In case the = classifier is in the next SFF, the current SFF would only forward the traff= ic to the next SFF, without knowing or caring about if there is a classifie= r there.
 
Cheers,
Hongyu
 
From:<= /span> sfc [= mailto:sfc-bounces@ietf.org] = ;On Behalf Of Carlos Pig= nataro (cpignata)
Sent: Tuesday, Aug= ust 26, 2014 3:15 AM
To: Reinaldo Penno= (repenno)
Cc: sfc@= ietf.org
Subject: Re: [sfc]= Fwd: New Version Notification for draft-merged-sfc-architecture-02.txt
 
Reinaldo,
 
Thanks for the comment, good set of points. It does seem that the def= inition itself might be unnecessarily overly restrictive.=
 
We could say "zero or more" or we could say "typically= one or more", but I think it is better to spell out the function. Her= e's one more comprehensive proposal:
 
Old:
   Service Function Forwarder (SFF):  A service functi= on forwarder is
        responsible for delivering traffic receiv= ed from the network to
        one or more connected service functions a= ccording to information
        carried in the SFC encapsulation.
 
New:
   Service Function Forwarder (SFF):  A service functi= on forwarder is
        responsible for delivering traffic receiv= ed from the network to
        one or more connected service functions a= ccording to information
        carried in the SFC encapsulation, as well= as for delivering traffic to
        a classifier or mapping out traffic to an= other SFF (in the same or
        different type of overlay).
 
WG, Reinaldo,
 
Thoughts?
 
Thanks,
 
Carlos.
 
On Aug 25, 2014, at 1:06 PM, Reinaldo Penno <repenn= o@cisco.com> wrote:



A couple of points about SFF definition. You mention "one or mor= e connected service functions"&n= bsp;

But in our implementation we have two types of SFFs that do not have SFs:
- A SFF that maps from one overlay to another, say, VXLAN to GRE
- A SFF that only has a classifier (no SFs in itself)

Where would they fit or how to to make sure the architecture can predict th= eir usage?

thanks,

On 8/23/14 1:47 PM, Carlos Pignataro (cpignata) wrote:
SFC,
 
Please find below the email notice of a new revision of draft-me= rged-sfc-architecture.
 
Full set of diffs from -00 (IETF90) to -02 (now) can be seen here:&nb= sp;http://www.ietf.org/rfcdiff?url2=3Ddraft-merg= ed-sfc-architecture-02&url1=3Ddraft-merged-sfc-architecture-00=
 
We still expect further changes to the document; but we also believe = that this revision captures the key points and addresses the key open items= , as planned in Toronto.
 
The key objective being to create a single document basis for the SFC= architecture.
 
SFC Chairs,
 
We believe that this revision fulfills the next steps agreed in Toron= to (http://tools.ietf.org/= agenda/90/slides/slides-90-sfc-3.pdf). 
 
This revision, while we expect changes, is now close enough that= we think it makes sense for the WG to take it as the basis for the WG docu= ment to address the deliverable.
 
draft-merged-sfc-architecture-02 addressed the key points -- and we b= elieve is ready to start a poll for adoption. Can you please initiate that = WG adoption call for draft-merged-sfc-architecture-02?
 
Thanks,
 
Carlos & Joel.
 
 
Begin forwarded message:



Subject: New Version= Notification for draft-merged-sfc-architecture-02.txt
Date: August 22, 2014 at 12:59:13 PM EDT
To: Joel Halpern <jmh@joelhalpern.com= >, Carlos Pignataro <cpignata@cisco.com>, "Joe= l M. Halpern" <jmh@joelhalpern.com>, Carlos Pignataro <cpignata@cisco.com>
 


A new version of I-D, draft-merged-sfc-architecture-02.txt
has been successfully submitted by Carlos Pignataro and posted to the
IETF repository.

Name:&= nbsp;draft-merged-sfc-architecture
Revision: 02
Title:=  Service Function Chaining (SFC) Architecture
Document date: 2014-08-22
Group:=  Individual Submission
Pages:=  26
URL:            http://www.ietf.= org/internet-drafts/draft-merged-sfc-architecture-02.txt
Status:         https://datatracker.ietf.org/doc/draft-m= erged-sfc-architecture/
Htmlized:       http://tools.ietf.org/html/draft-merged-sfc-architectu= re-02
Diff:           http://www.ietf.org/rfcd= iff?url2=3Ddraft-merged-sfc-architecture-02

Abstract:
  This document describes an architecture for the specification,<= br>   creation, and ongoing maintenance of Service Function Chains (S= FC) in
  a network.  It includes architectural concepts, principles= , and
  components used in the construction of composite services throu= gh
  deployment of SFCs.  This document does not propose soluti= ons,
  protocols, or extensions to existing protocols.




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

The IETF Secretariat

 




_______________________________________________=

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

This message is intended only for = the designated recipient(s). It may contain confidential or proprietary inf= ormation. If you are not the designated recipient, you may not review, copy= or distribute this message. If you have mistakenly received this message, please notify the sender by a reply= e-mail and delete this message. Thank you.

--_000_B33506418642441788362EA521C6E27Cciscocom_-- From nobody Tue Aug 26 16:35: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 3DA821A00B5 for ; Tue, 26 Aug 2014 16:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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.668, 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 Kg3hocBn55nC for ; Tue, 26 Aug 2014 16:35:12 -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 228A11A01D8 for ; Tue, 26 Aug 2014 16:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7732; q=dns/txt; s=iport; t=1409096113; x=1410305713; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Fe9C7PPvqyG37sOpLAfwmyAyHBIGt7GDivtN93T88jo=; b=f5iUdW57IyDBUKRGWW3d+Xov6rGACVEb0KlKv8KT+5jOYvgBTqAZkurV 0YJCvXUJ7CbDsRPJqUOfPq980+uGSy38k11xnP71RRtJXU9h6r8BCIP7d EJ36Kzvaboxb7zlun9jnGbhqjNaJecIMBdHZH6A1nWa/WfvoOaXsQqKAB U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8FANEY/VOtJV2a/2dsb2JhbABbgkcjI1NXBLJUmCKBWgEJh0wBgRIWd4QEAQEEAQEBGlELEAIBCBItByEGCxQDDgIEDgWILgMRAQy6AA2FPxeNH4IpBAeDL4EdBY8ZghSEK4RsghCBWI0FhjeDXmyBSIEHAQEB X-IronPort-AV: E=Sophos;i="5.04,407,1406592000"; d="scan'208,217";a="350549400" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 26 Aug 2014 23:35:12 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s7QNZBwO008991 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Aug 2014 23:35:11 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Tue, 26 Aug 2014 18:35:11 -0500 From: "Carlos Pignataro (cpignata)" To: "Andrew G. Malis" Thread-Topic: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 Thread-Index: AQHPwSKarKFwlbPq2EakRGFWvH7bz5vjcfuAgABsVAA= Date: Tue, 26 Aug 2014 23:35:10 +0000 Message-ID: <75DFCA29-88B6-44F4-8A97-0335B56351E0@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.82.238.17] Content-Type: multipart/alternative; boundary="_000_75DFCA2988B644F48A970335B56351E0ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/8x44UTT2DLzejvCMqGHnxp-sOyQ Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-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: Tue, 26 Aug 2014 23:35:17 -0000 --_000_75DFCA2988B644F48A970335B56351E0ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Andy, I hope you don't mind me commenting on part of your note below. Regarding the definition of "SFC Encapsulation", indeed there were particip= ants that requested a looser wording; but for completeness, there were also= participants that requested the definition to stay as. Of course, as a WG document the editors capture the results of the group's = work, and the document reflects decisions made by the WG. In fact, that has= been our attempt all along even as an individual submission (with the goal= of converging the sfc architecture). And I expect the WG to continue discu= ssing the architecture. Thank you again, Carlos. PS: From a technical perspective (not to re-open the discussion here, but o= nly to point at where that discussion faded out), the proposed text would h= amper interoperability while the mentioned downsides seemed adequately cove= red in the "MTU and Fragmentation Considerations" section of the document. On Aug 26, 2014, at 1:07 PM, Andrew G. Malis > wrote: Jim, I support the adoption of this draft by the WG. During the discussion of revision -01, although a number of WG participants= requested a more flexible wording of the SFC encapsulation definition, it = was unchanged from -01 to -02. This is within the rights of individual auth= ors, of course. However, once this becomes a WG draft, I hope we can revisi= t that discussion. Thanks, Andy On Tue, Aug 26, 2014 at 7:40 AM, Jim Guichard (jguichar) > wrote: Greetings WG: This message begins a two week call for WG adoption of draft-merged-sfc-arc= hitecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-architecture= /] ending September 9th 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. 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 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_75DFCA2988B644F48A970335B56351E0ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Andy,

I hope you don't mind me commenting on part of your note below.

Regarding the definition of "SFC Encapsulation", indeed ther= e were participants that requested a looser wording; but for completeness, = there were also participants that requested the definition to stay as.

Of course, as a WG document the editors capture the results of the gro= up's work, and the document reflects decisions made by the WG. In fact, tha= t has been our attempt all along even as an individual submission (with the= goal of converging the sfc architecture). And I expect the WG to continue discussing the architecture.

Thank you again,

Carlos.
PS: From a technical perspective (not to re-open the discussion here, = but only to point at where that discussion faded out), the proposed text wo= uld hamper interoperability while the mentioned downsides seemed adequately= covered in the "MTU and Fragmentation Considerations" section of the document.



Jim,

I support the adoption of this draft by the WG.

During the discussion of revision -01, although a number of WG partici= pants requested a more flexible wording of the SFC encapsulation definition= , it was unchanged from -01 to -02. This is within the rights of individual= authors, of course. However, once this becomes a WG draft, I hope we can revisit that discussion.

Thanks,
Andy



On Tue, Aug 26, 2014 at 7:40 AM, Jim Guichard (j= guichar) <jguichar@cisco.com> wrote:
Greetings WG:

This message begins a two week call for WG adoption of draft-merged-sf= c-architecture-02 [http://datatracker.ietf.org/doc/draft-= merged-sfc-architecture/] ending September 9th 2014.

Please respond to the SFC mailing list with any statements of approval= or disapproval.

As always, please note:
  1. This is not WG Last Cal= l. 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. Therefo= re, please don=92t oppose adoption just because you want to see changes to its content.
    2. <= li>If you have objections t= o adoption of the document, please state your reasons why, and explain what= it would take to address your concerns.
  2. If you have issues= with the content, by all means raise those issues and we can begin a dialo= g about how best to address them.

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


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

--_000_75DFCA2988B644F48A970335B56351E0ciscocom_-- From nobody Tue Aug 26 17:44: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 B06E51A02BE for ; Tue, 26 Aug 2014 17:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.839 X-Spam-Level: * X-Spam-Status: No, score=1.839 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, 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 Fp_EJBjEs-R1 for ; Tue, 26 Aug 2014 17:44:56 -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 963BD1A02A2 for ; Tue, 26 Aug 2014 17:44:56 -0700 (PDT) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id s7R0itXx012231 for ; Wed, 27 Aug 2014 09:44:55 +0900 Received: from mfs5.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id AF13DE011A for ; Wed, 27 Aug 2014 09:44:55 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id A3282E0117 for ; Wed, 27 Aug 2014 09:44:55 +0900 (JST) Received: from [127.0.0.1] ([129.60.20.75]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id s7R0is80003699 for ; Wed, 27 Aug 2014 09:44:55 +0900 Message-ID: <53FD29C5.4040201@lab.ntt.co.jp> Date: Wed, 27 Aug 2014 09:43:49 +0900 From: Kengo Naito User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "sfc@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000709070105060000080609" X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/OTRuR9CTbJ-HnkBz0dQrqzAtS3E Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-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, 27 Aug 2014 00:44:58 -0000 This is a multi-part message in MIME format. --------------000709070105060000080609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Support. Cheers, Kengo (2014/08/26 20:40), Jim Guichard (jguichar) wrote: > Greetings WG: > > This message begins a two week call for WG adoption of > draft-merged-sfc-architecture-02 > [http://datatracker.ietf.org/doc/draft-merged-sfc-architecture/] ending September > 9th 2014. > > 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 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 -- ---------------------------------------- NTT Network Technology Laboratories Kengo Naito E-Mail: naito.kengo@lab.ntt.co.jp TEL: +81 422-59-4949 ---------------------------------------- --------------000709070105060000080609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit  Support.

Cheers,
 Kengo

(2014/08/26 20:40), Jim Guichard (jguichar) wrote:
Greetings WG:

This message begins a two week call for WG adoption of draft-merged-sfc-architecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-architecture/] ending September 9th 2014.

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


-- 
----------------------------------------
NTT Network Technology Laboratories
Kengo Naito
E-Mail: naito.kengo@lab.ntt.co.jp
TEL: +81 422-59-4949
----------------------------------------
--------------000709070105060000080609-- From nobody Tue Aug 26 18:04: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 4D6991A02EB; Tue, 26 Aug 2014 18:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.867 X-Spam-Level: X-Spam-Status: No, score=-104.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, USER_IN_WHITELIST=-100] 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 xa5HMPy-wPSK; Tue, 26 Aug 2014 18:04:45 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 273F71A02D2; Tue, 26 Aug 2014 18:04:45 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id AEE00193F7B9; Wed, 27 Aug 2014 09:04:35 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 78F015F729D; Wed, 27 Aug 2014 09:04:33 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s7R14YFu025359; Wed, 27 Aug 2014 09:04:34 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn) In-Reply-To: To: "Jim Guichard (jguichar)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: meng.wei2@zte.com.cn Date: Wed, 27 Aug 2014 09:04:33 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2014-08-27 09:04:14, Serialize complete at 2014-08-27 09:04:14 Content-Type: multipart/alternative; boundary="=_alternative 0005FB4F48257D41_=" X-MAIL: mse01.zte.com.cn s7R14YFu025359 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Ru99djwfXPqZUTzPsUVa5FF10gU Cc: sfc , "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-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, 27 Aug 2014 01:04:48 -0000 This is a multipart message in MIME format. --=_alternative 0005FB4F48257D41_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 U3VwcG9ydCArMQ0KDQoic2ZjIiA8c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+ICAyMDE0LzA4LzI2IDE5 OjQwOjU4Og0KDQo+IEdyZWV0aW5ncyBXRzoNCj4gDQo+IFRoaXMgbWVzc2FnZSBiZWdpbnMgYSB0 d28gd2VlayBjYWxsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1tZXJnZWQtDQo+IHNmYy1hcmNo aXRlY3R1cmUtMDIgW2h0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWVyZ2Vk LQ0KPiBzZmMtYXJjaGl0ZWN0dXJlL10gZW5kaW5nIFNlcHRlbWJlciA5dGggMjAxNC4NCj4gDQo+ IFBsZWFzZSByZXNwb25kIHRvIHRoZSBTRkMgbWFpbGluZyBsaXN0IHdpdGggYW55IHN0YXRlbWVu dHMgb2YgDQo+IGFwcHJvdmFsIG9yIGRpc2FwcHJvdmFsLg0KPiANCj4gQXMgYWx3YXlzLCBwbGVh c2Ugbm90ZToNCj4gMS4gVGhpcyBpcyBub3QgV0cgTGFzdCBDYWxsLiBUaGUgZG9jdW1lbnQgaXMg bm90IGZpbmFsLCBhbmQgdGhlIFdHIA0KPiBpcyBleHBlY3RlZCB0byBtb2RpZnkgdGhlIGRvY3Vt ZW50oa9zIGNvbnRlbnQgdW50aWwgdGhlcmUgaXMgV0cgDQo+IGNvbnNlbnN1cyB0aGF0IHRoZSBj b250ZW50IGlzIHNvbGlkLiBUaGVyZWZvcmUsIHBsZWFzZSBkb26hr3Qgb3Bwb3NlIA0KPiBhZG9w dGlvbiBqdXN0IGJlY2F1c2UgeW91IHdhbnQgdG8gc2VlIGNoYW5nZXMgdG8gaXRzIGNvbnRlbnQu DQo+IDIuIElmIHlvdSBoYXZlIG9iamVjdGlvbnMgdG8gYWRvcHRpb24gb2YgdGhlIGRvY3VtZW50 LCBwbGVhc2Ugc3RhdGUgDQo+IHlvdXIgcmVhc29ucyB3aHksIGFuZCBleHBsYWluIHdoYXQgaXQg d291bGQgdGFrZSB0byBhZGRyZXNzIHlvdXIgDQpjb25jZXJucy4NCj4gMy4gSWYgeW91IGhhdmUg aXNzdWVzIHdpdGggdGhlIGNvbnRlbnQsIGJ5IGFsbCBtZWFucyByYWlzZSB0aG9zZSANCj4gaXNz dWVzIGFuZCB3ZSBjYW4gYmVnaW4gYSBkaWFsb2cgYWJvdXQgaG93IGJlc3QgdG8gYWRkcmVzcyB0 aGVtLg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBzZmMgbWFpbGluZyBsaXN0DQo+IHNmY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQo= --=_alternative 0005FB4F48257D41_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlN1cHBvcnQgKzE8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mcXVvdDtzZmMmcXVvdDsgJmx0O3NmYy1ib3VuY2Vz QGlldGYub3JnJmd0OyAmbmJzcDsyMDE0LzA4LzI2DQoxOTo0MDo1ODo8YnI+DQo8YnI+DQomZ3Q7 IEdyZWV0aW5ncyBXRzo8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgPGJy Pg0KJmd0OyBUaGlzIG1lc3NhZ2UgYmVnaW5zIGEgdHdvIHdlZWsgY2FsbCBmb3IgV0cgYWRvcHRp b24gb2YgZHJhZnQtbWVyZ2VkLTxicj4NCiZndDsgc2ZjLWFyY2hpdGVjdHVyZS0wMiBbaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tZXJnZWQtPGJyPg0KJmd0OyBzZmMtYXJj aGl0ZWN0dXJlL10gZW5kaW5nIFNlcHRlbWJlciA5dGggMjAxNC48L3R0PjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTI+PHR0PiZndDsgPGJyPg0KJmd0OyBQbGVhc2UgcmVzcG9uZCB0byB0aGUgU0ZD IG1haWxpbmcgbGlzdCB3aXRoIGFueSBzdGF0ZW1lbnRzIG9mIDxicj4NCiZndDsgYXBwcm92YWwg b3IgZGlzYXBwcm92YWwuPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IDxi cj4NCiZndDsgQXMgYWx3YXlzLCBwbGVhc2Ugbm90ZTo8L3R0PjwvZm9udD4NCjxicj48Zm9udCBz aXplPTI+PHR0PiZndDsgMS4gVGhpcyBpcyBub3QgV0cgTGFzdCBDYWxsLiBUaGUgZG9jdW1lbnQg aXMNCm5vdCBmaW5hbCwgYW5kIHRoZSBXRyA8YnI+DQomZ3Q7IGlzIGV4cGVjdGVkIHRvIG1vZGlm eSB0aGUgZG9jdW1lbnShr3MgY29udGVudCB1bnRpbCB0aGVyZSBpcyBXRyA8YnI+DQomZ3Q7IGNv bnNlbnN1cyB0aGF0IHRoZSBjb250ZW50IGlzIHNvbGlkLiBUaGVyZWZvcmUsIHBsZWFzZSBkb26h r3Qgb3Bwb3NlDQo8YnI+DQomZ3Q7IGFkb3B0aW9uIGp1c3QgYmVjYXVzZSB5b3Ugd2FudCB0byBz ZWUgY2hhbmdlcyB0byBpdHMgY29udGVudC48L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+ PHR0PiZndDsgMi4gSWYgeW91IGhhdmUgb2JqZWN0aW9ucyB0byBhZG9wdGlvbiBvZiB0aGUNCmRv Y3VtZW50LCBwbGVhc2Ugc3RhdGUgPGJyPg0KJmd0OyB5b3VyIHJlYXNvbnMgd2h5LCBhbmQgZXhw bGFpbiB3aGF0IGl0IHdvdWxkIHRha2UgdG8gYWRkcmVzcyB5b3VyIGNvbmNlcm5zLjwvdHQ+PC9m b250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyAzLiBJZiB5b3UgaGF2ZSBpc3N1ZXMgd2l0 aCB0aGUgY29udGVudCwgYnkgYWxsDQptZWFucyByYWlzZSB0aG9zZSA8YnI+DQomZ3Q7IGlzc3Vl cyBhbmQgd2UgY2FuIGJlZ2luIGEgZGlhbG9nIGFib3V0IGhvdyBiZXN0IHRvIGFkZHJlc3MgdGhl bS48YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJmd0OyBzZmMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBzZmNAaWV0Zi5vcmc8YnI+ DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPGJyPg0KPC90 dD48L2ZvbnQ+DQo= --=_alternative 0005FB4F48257D41_=-- From nobody Tue Aug 26 18:21: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 D5C831A02EB for ; Tue, 26 Aug 2014 18:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 nyXLqGlJ3Yoy for ; Tue, 26 Aug 2014 18:21:31 -0700 (PDT) Received: from mail-yh0-f42.google.com (mail-yh0-f42.google.com [209.85.213.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 026841A02D2 for ; Tue, 26 Aug 2014 18:21:30 -0700 (PDT) Received: by mail-yh0-f42.google.com with SMTP id a41so12927249yho.29 for ; Tue, 26 Aug 2014 18:21:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=nQXQYNoU0oMtZMkHD18KEpeSqR+e5gVlwzawUnAHFLE=; b=dcCRbUXK3zHtxdCjSNJmk/IaHUeBNTIaxgNXJB6ZalcSsQFCtLMk7MGNdHdiZuuwUN e6acrNjjz5cYzWyOmIaLEIBy/BF+KLCYXArqxyyg/Z4biHznhbGpFHpXuOh1lWvux2Rx ICDbIyMLWzwvH8dF3Vry9K2vYd2pYfqgK9VZUPk5Z9UokQ3LISC/xakUMHaJKksw3lxu xDpUi1LGFixOSUDSM3gbdJOQFSZUnf/+q2l1x6aimxr3htVH42LlbI9PHEZoCagJoAVU JOrH2zS6+k1NiQfxOMio8CRdv5k27IOG6/PzefSeSO68PDIBTr14DyyGQO0kx/4y1ER6 3dkg== X-Gm-Message-State: ALoCoQm2qUtdMw54fmgydMSrWVWreLDPSiJzBr4w1kTPif1XhNN9eJTcuePLXndQlbplcMjDJi7c X-Received: by 10.236.27.105 with SMTP id d69mr49111948yha.72.1409102490216; Tue, 26 Aug 2014 18:21:30 -0700 (PDT) Received: from ?IPv6:2602:100:4473:9afe:e4fc:f65a:71c6:a155? ([2602:100:4473:9afe:e4fc:f65a:71c6:a155]) by mx.google.com with ESMTPSA id e97sm2765707yhq.48.2014.08.26.18.21.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Aug 2014 18:21:29 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_0ED41693-B6F5-464B-AC89-941A3C3B0E25" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Benson Schliesser In-Reply-To: Date: Tue, 26 Aug 2014 21:21:28 -0400 Message-Id: References: To: "Jim Guichard (jguichar)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/jp5nHJa73hAC6U1zmnsRi4Wx7K8 Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-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, 27 Aug 2014 01:21:33 -0000 --Apple-Mail=_0ED41693-B6F5-464B-AC89-941A3C3B0E25 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I support adoption of this draft. -Benson On Aug 26, 2014, at 7:40 AM, Jim Guichard (jguichar) = wrote: > Greetings WG: >=20 > This message begins a two week call for WG adoption of = draft-merged-sfc-architecture-02 = [http://datatracker.ietf.org/doc/draft-merged-sfc-architecture/] ending = September 9th 2014. >=20 > Please respond to the SFC mailing list with any statements of approval = or disapproval. >=20 > 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. > If you have objections to adoption of the document, please state your = reasons why, and explain what it would take to address your concerns. > 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 --Apple-Mail=_0ED41693-B6F5-464B-AC89-941A3C3B0E25 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
I = support adoption of this = draft.
-Benson


On Aug 26, = 2014, at 7:40 AM, Jim Guichard (jguichar) <jguichar@cisco.com> = wrote:

Greetings WG:

This message begins a two week call for WG adoption of = draft-merged-sfc-architecture-02 [ht= tp://datatracker.ietf.org/doc/draft-merged-sfc-architecture/] end= ing September 9th 2014.

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 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.
  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/mail= man/listinfo/sfc

= --Apple-Mail=_0ED41693-B6F5-464B-AC89-941A3C3B0E25-- From nobody Tue Aug 26 19:18:02 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 BD6481A0363 for ; Tue, 26 Aug 2014 19:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 niyWFXE1XUla for ; Tue, 26 Aug 2014 19:17:59 -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 459711A0360 for ; Tue, 26 Aug 2014 19:17:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIT64890; Wed, 27 Aug 2014 02:17:56 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Aug 2014 03:17:55 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.204]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Wed, 27 Aug 2014 10:17:49 +0800 From: Xuxiaohu To: "Andrew G. Malis" , "Jim Guichard (jguichar)" Thread-Topic: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 Thread-Index: AQHPwSKarKFwlbPq2EakRGFWvH7bz5vimA2AgAEflhA= Date: Wed, 27 Aug 2014 02:17:49 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082AB308@NKGEML512-MBS.china.huawei.com> References: 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.111.98.134] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082AB308NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/J1p9lGJx7_CDV5VrB0ef0Wzgm4g Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-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, 27 Aug 2014 02:18:00 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082AB308NKGEML512MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCB0aGUgYWRvcHRpb24gYW5kIGFncmVlIHdpdGggQW5keeKAmXMgcG9pbnQuDQoNClhp YW9odQ0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEFuZHJldyBHLiBNYWxpcw0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMjcsIDIwMTQgMTow NyBBTQ0KVG86IEppbSBHdWljaGFyZCAoamd1aWNoYXIpDQpDYzogc2ZjQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW3NmY10gQ2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtbWVyZ2VkLXNmYy1h cmNoaXRlY3R1cmUtMDINCg0KSmltLA0KDQpJIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoaXMg ZHJhZnQgYnkgdGhlIFdHLg0KDQpEdXJpbmcgdGhlIGRpc2N1c3Npb24gb2YgcmV2aXNpb24gLTAx LCBhbHRob3VnaCBhIG51bWJlciBvZiBXRyBwYXJ0aWNpcGFudHMgcmVxdWVzdGVkIGEgbW9yZSBm bGV4aWJsZSB3b3JkaW5nIG9mIHRoZSBTRkMgZW5jYXBzdWxhdGlvbiBkZWZpbml0aW9uLCBpdCB3 YXMgdW5jaGFuZ2VkIGZyb20gLTAxIHRvIC0wMi4gVGhpcyBpcyB3aXRoaW4gdGhlIHJpZ2h0cyBv ZiBpbmRpdmlkdWFsIGF1dGhvcnMsIG9mIGNvdXJzZS4gSG93ZXZlciwgb25jZSB0aGlzIGJlY29t ZXMgYSBXRyBkcmFmdCwgSSBob3BlIHdlIGNhbiByZXZpc2l0IHRoYXQgZGlzY3Vzc2lvbi4NCg0K VGhhbmtzLA0KQW5keQ0KDQoNCk9uIFR1ZSwgQXVnIDI2LCAyMDE0IGF0IDc6NDAgQU0sIEppbSBH dWljaGFyZCAoamd1aWNoYXIpIDxqZ3VpY2hhckBjaXNjby5jb208bWFpbHRvOmpndWljaGFyQGNp c2NvLmNvbT4+IHdyb3RlOg0KR3JlZXRpbmdzIFdHOg0KDQpUaGlzIG1lc3NhZ2UgYmVnaW5zIGEg dHdvIHdlZWsgY2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRl Y3R1cmUtMDIgW2h0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWVyZ2VkLXNm Yy1hcmNoaXRlY3R1cmUvXSBlbmRpbmcgU2VwdGVtYmVyIDl0aCAyMDE0Lg0KDQpQbGVhc2UgcmVz cG9uZCB0byB0aGUgU0ZDIG1haWxpbmcgbGlzdCB3aXRoIGFueSBzdGF0ZW1lbnRzIG9mIGFwcHJv dmFsIG9yIGRpc2FwcHJvdmFsLg0KDQpBcyBhbHdheXMsIHBsZWFzZSBub3RlOg0KDQogIDEuICBU aGlzIGlzIG5vdCBXRyBMYXN0IENhbGwuIFRoZSBkb2N1bWVudCBpcyBub3QgZmluYWwsIGFuZCB0 aGUgV0cgaXMgZXhwZWN0ZWQgdG8gbW9kaWZ5IHRoZSBkb2N1bWVudOKAmXMgY29udGVudCB1bnRp bCB0aGVyZSBpcyBXRyBjb25zZW5zdXMgdGhhdCB0aGUgY29udGVudCBpcyBzb2xpZC4gVGhlcmVm b3JlLCBwbGVhc2UgZG9u4oCZdCBvcHBvc2UgYWRvcHRpb24ganVzdCBiZWNhdXNlIHlvdSB3YW50 IHRvIHNlZSBjaGFuZ2VzIHRvIGl0cyBjb250ZW50Lg0KICAyLiAgSWYgeW91IGhhdmUgb2JqZWN0 aW9ucyB0byBhZG9wdGlvbiBvZiB0aGUgZG9jdW1lbnQsIHBsZWFzZSBzdGF0ZSB5b3VyIHJlYXNv bnMgd2h5LCBhbmQgZXhwbGFpbiB3aGF0IGl0IHdvdWxkIHRha2UgdG8gYWRkcmVzcyB5b3VyIGNv bmNlcm5zLg0KICAzLiAgSWYgeW91IGhhdmUgaXNzdWVzIHdpdGggdGhlIGNvbnRlbnQsIGJ5IGFs bCBtZWFucyByYWlzZSB0aG9zZSBpc3N1ZXMgYW5kIHdlIGNhbiBiZWdpbiBhIGRpYWxvZyBhYm91 dCBob3cgYmVzdCB0byBhZGRyZXNzIHRoZW0uDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmc8bWFp bHRvOnNmY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2ZjDQoNCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082AB308NKGEML512MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21z by1saXN0LWlkOjMxMDUyMzg0NDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTAxMDM0MTI3Njt9 DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBs MDpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDMN Cgl7bXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1s ZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFi LXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIx Ni4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30N CkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBs MDpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDENCgl7bXNv LWxpc3QtaWQ6MzkyNDYyMTgyOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNzA5ODQ5ODQ2O30N Cm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlN1cHBvcnQg dGhlIGFkb3B0aW9uIGFuZCBhZ3JlZSB3aXRoIEFuZHnigJlzIHBvaW50LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5YaWFvaHU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbmRyZXcgRy4gTWFsaXM8YnI+DQo8Yj5TZW50OjwvYj4g V2VkbmVzZGF5LCBBdWd1c3QgMjcsIDIwMTQgMTowNyBBTTxicj4NCjxiPlRvOjwvYj4gSmltIEd1 aWNoYXJkIChqZ3VpY2hhcik8YnI+DQo8Yj5DYzo8L2I+IHNmY0BpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW3NmY10gQ2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtbWVyZ2Vk LXNmYy1hcmNoaXRlY3R1cmUtMDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkpp bSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHN1cHBvcnQgdGhl IGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQgYnkgdGhlIFdHLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RHVyaW5nIHRoZSBkaXNjdXNzaW9uIG9mIHJldmlz aW9uIC0wMSwgYWx0aG91Z2ggYSBudW1iZXIgb2YgV0cgcGFydGljaXBhbnRzIHJlcXVlc3RlZCBh IG1vcmUgZmxleGlibGUgd29yZGluZyBvZiB0aGUgU0ZDIGVuY2Fwc3VsYXRpb24gZGVmaW5pdGlv biwgaXQgd2FzIHVuY2hhbmdlZCBmcm9tIC0wMSB0byAtMDIuIFRoaXMgaXMgd2l0aGluIHRoZSBy aWdodHMgb2YgaW5kaXZpZHVhbA0KIGF1dGhvcnMsIG9mIGNvdXJzZS4gSG93ZXZlciwgb25jZSB0 aGlzIGJlY29tZXMgYSBXRyBkcmFmdCwgSSBob3BlIHdlIGNhbiByZXZpc2l0IHRoYXQgZGlzY3Vz c2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRo YW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QW5keTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gVHVlLCBBdWcgMjYsIDIwMTQgYXQgNzo0MCBBTSwg SmltIEd1aWNoYXJkIChqZ3VpY2hhcikgJmx0OzxhIGhyZWY9Im1haWx0bzpqZ3VpY2hhckBjaXNj by5jb20iIHRhcmdldD0iX2JsYW5rIj5qZ3VpY2hhckBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkdy ZWV0aW5ncyBXRzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhpcyBtZXNzYWdlIGJlZ2lucyBhIHR3byB3ZWVrIGNh bGwgZm9yIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAyIFs8 YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1lcmdlZC1zZmMt YXJjaGl0ZWN0dXJlLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUvPC9hPl0mbmJzcDtlbmRpbmcNCiBT ZXB0ZW1iZXIgOXRoIDIwMTQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UGxlYXNlIHJlc3BvbmQgdG8gdGhlIFNGQyBtYWlsaW5n IGxpc3Qgd2l0aCBhbnkgc3RhdGVtZW50cyBvZiBhcHByb3ZhbCBvciBkaXNhcHByb3ZhbC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5BcyBhbHdheXMsIHBsZWFzZSBub3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29s b3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+VGhpcyBpcyBub3QgV0cgTGFzdCBDYWxsLiBUaGUgZG9jdW1lbnQgaXMg bm90IGZpbmFsLCBhbmQgdGhlIFdHIGlzIGV4cGVjdGVkIHRvIG1vZGlmeSB0aGUgZG9jdW1lbnTi gJlzIGNvbnRlbnQgdW50aWwgdGhlcmUgaXMgV0cgY29uc2Vuc3VzIHRoYXQgdGhlIGNvbnRlbnQg aXMgc29saWQuIFRoZXJlZm9yZSwgcGxlYXNlDQogZG9u4oCZdCBvcHBvc2UgYWRvcHRpb24ganVz dCBiZWNhdXNlIHlvdSB3YW50IHRvIHNlZSBjaGFuZ2VzIHRvIGl0cyBjb250ZW50LjxvOnA+PC9v OnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjaztt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlz dDpsMCBsZXZlbDEgbGZvMyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5JZiB5b3UgaGF2ZSBvYmplY3Rpb25zIHRvIGFkb3B0aW9uIG9mIHRoZSBkb2N1bWVudCwg cGxlYXNlIHN0YXRlIHlvdXIgcmVhc29ucyB3aHksIGFuZCBleHBsYWluIHdoYXQgaXQgd291bGQg dGFrZSB0byBhZGRyZXNzIHlvdXIgY29uY2VybnMuPG86cD48L286cD48L3NwYW4+PC9saT48bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj4N CjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklmIHlvdSBoYXZlIGlz c3VlcyB3aXRoIHRoZSBjb250ZW50LCBieSBhbGwgbWVhbnMgcmFpc2UgdGhvc2UgaXNzdWVzIGFu ZCB3ZSBjYW4gYmVnaW4gYSBkaWFsb2cgYWJvdXQgaG93IGJlc3QgdG8gYWRkcmVzcyB0aGVtLjxv OnA+PC9vOnA+PC9zcGFuPjwvbGk+PC9vbD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CnNmYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082AB308NKGEML512MBSchi_-- From nobody Tue Aug 26 19: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 5CE931A0376 for ; Tue, 26 Aug 2014 19:22:50 -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 BbYsha_ALije for ; Tue, 26 Aug 2014 19:22:48 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D6A81A0363 for ; Tue, 26 Aug 2014 19:22:48 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id a108so15635349qge.16 for ; Tue, 26 Aug 2014 19:22:47 -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=b5NFDZ3Lguyw4/qn68c8FSYz7awfWJsyRYuFsqBShvY=; b=vWAeoDxSRL9Y8ixiPnpQYBVUMSiFXXqF52STapyET43JYUsGBescIm93lrd1vnFd/1 Jz+YBLrfzYY2y2EF0x46mU72FnY/wqHeOzpq1JLLCJD5mmYr6iwq/mZdb/bxpXHK8ajt z88TPx2l2EcgJ1WmtMVA7dYyWiBJ0VoOzb/v2tB4ir8Mh1qe7ZBZ6q6g9WwpmUh9F9jf 0wa46AHTWOqoa+2FjtE/b8nwGBH6BO14QMx5M7xESciORCu1Wd1Ynvg3FmidLOvEQRuc ciNgurEKvS8p/vsmjRVxnGbT8WoHuTr9Hx/rU//ZQm69m/lQHDYBn2RGPXinTatJkUBG pecg== X-Received: by 10.229.84.133 with SMTP id j5mr51806672qcl.14.1409106167614; Tue, 26 Aug 2014 19:22:47 -0700 (PDT) Received: from [192.168.1.102] (108-214-96-27.lightspeed.sntcca.sbcglobal.net. [108.214.96.27]) by mx.google.com with ESMTPSA id v1sm15154846qat.17.2014.08.26.19.22.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Aug 2014 19:22:47 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-CA93392C-524D-4E63-B3D5-3E1C572306A3 Mime-Version: 1.0 (1.0) From: Sharon X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Tue, 26 Aug 2014 19:22:45 -0700 Content-Transfer-Encoding: 7bit Message-Id: <308400DD-B6EA-46AE-ACFD-6F9A60702D6C@gmail.com> References: To: "Jim Guichard (jguichar)" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/eejq8PddOQq2LurtEcYJq9zm8gM Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-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, 27 Aug 2014 02:22:50 -0000 --Apple-Mail-CA93392C-524D-4E63-B3D5-3E1C572306A3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Support=20 --szb > On Aug 26, 2014, at 4:40 AM, "Jim Guichard (jguichar)" wrote: >=20 > Greetings WG: >=20 > This message begins a two week call for WG adoption of draft-merged-sfc-ar= chitecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-architecture= /] ending September 9th 2014. >=20 > Please respond to the SFC mailing list with any statements of approval or d= isapproval. >=20 > As always, please note: > This is not WG Last Call. The document is not final, and the WG is expecte= d to modify the document=E2=80=99s content until there is WG consensus that t= he content is solid. Therefore, please don=E2=80=99t oppose adoption just be= cause you want to see changes to its content. > If you have objections to adoption of the document, please state your reas= ons why, and explain what it would take to address your concerns. > If you have issues with the content, by all means raise those issues and w= e can begin a dialog about how best to address them. > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail-CA93392C-524D-4E63-B3D5-3E1C572306A3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Support 

--szb
<= br>On Aug 26, 2014, at 4:40 AM, "Jim Guichard (jguichar)" <jguichar@cisco.com> wrote:

Greetings WG:

This message begins a two week call for WG adoption of draft-merged-sfc= -architecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-architectu= re/] ending September 9th 2014.

Please respond to the SFC mailing list with any statements of approval o= r disapproval.

As always, please note:
=
  1. This is not WG Last Ca= ll. The document is not final, and the WG is expected to modify the document= =E2=80=99s content until there is WG consensus that the content is solid. Th= erefore, please don=E2=80=99t oppose adoption just because you want to see changes to its content.
  2. <= span lang=3D"EN-US" style=3D"font-size: 10.5pt;">If you have objections to a= doption 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 a= ll 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/lis= tinfo/sfc
= --Apple-Mail-CA93392C-524D-4E63-B3D5-3E1C572306A3-- From nobody Tue Aug 26 20:26: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 150211A0398 for ; Tue, 26 Aug 2014 20:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.838 X-Spam-Level: * X-Spam-Status: No, score=1.838 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, 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 8OadLuAOZEEx for ; Tue, 26 Aug 2014 20:26:39 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id BAEBA1A0396 for ; Tue, 26 Aug 2014 20:26:38 -0700 (PDT) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id s7R3QaMP032156 for ; Wed, 27 Aug 2014 12:26:36 +0900 Received: from mfs5.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 6D1D8E0121 for ; Wed, 27 Aug 2014 12:26:36 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 61BDCE0117 for ; Wed, 27 Aug 2014 12:26:36 +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 s7R3QPbp030786 for ; Wed, 27 Aug 2014 12:26:36 +0900 Message-ID: <53FD5016.5050202@lab.ntt.co.jp> Date: Wed, 27 Aug 2014 12:27:18 +0900 From: Shunsuke Homma User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit To: "sfc@ietf.org" X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/zxGYXOYTGefvMWg0OldLEv8jdNs Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-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, 27 Aug 2014 03:26:40 -0000 I support adoption of this draft. Shunsuke (2014/08/26 20:40), Jim Guichard (jguichar) wrote: > Greetings WG: > > This message begins a two week call for WG adoption of > draft-merged-sfc-architecture-02 > [http://datatracker.ietf.org/doc/draft-merged-sfc-architecture/] ending > September 9th 2014. > > 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 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 > -- ---------------------------------- Shunsuke Homma TEL: +81 422 59 3486 FAX: +81 422 60 7460 NTT Network Service System Labs. Musashino city, Tokyo, Japan ---------------------------------- From nobody Tue Aug 26 20:44: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 59AB31A039F for ; Tue, 26 Aug 2014 20:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, 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 AEX2onCd1mfH for ; Tue, 26 Aug 2014 20:44:02 -0700 (PDT) Received: from mailgw.allot.com (mailgw.allot.com [199.203.223.210]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB8C1A038B for ; Tue, 26 Aug 2014 20:44:00 -0700 (PDT) Received: from PUMA.ALLOT.LOCAL (Not Verified[199.203.223.202]) by mailgw.allot.com with MailMarshal (v7, 2, 3, 6978) id ; Wed, 27 Aug 2014 06:43:59 +0300 Received: from LION.ALLOT.LOCAL ([172.20.20.40]) by PUMA.ALLOT.LOCAL ([199.203.223.202]) with mapi id 14.03.0123.003; Wed, 27 Aug 2014 06:46:17 +0300 From: Alla Goldner To: "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] New Version Notification for draft-merged-sfc-architecture-02.txt Thread-Index: AQHPwYLbHqIcI7aXiUayLF1qF0tMP5vjzxNw Date: Wed, 27 Aug 2014 03:46:17 +0000 Message-ID: References: <20140822165913.29275.92328.idtracker@ietfa.amsl.com> <53FB6D2E.3010202@cisco.com> <6EB34CB5D82C4645B826C56144826EA97EA59B54@SZXEMA509-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [37.142.232.97] Content-Type: multipart/related; boundary="_004_A6B8F2A767638641889989BC1BA7047936014919LIONALLOTLOCAL_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Ng5-TbtZKBA9kQUX5CCr2GEmomc Cc: "Hongyu Li \(Julio\)" , "Reinaldo Penno \(repenno\)" , "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-merged-sfc-architecture-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: Wed, 27 Aug 2014 03:44:08 -0000 --_004_A6B8F2A767638641889989BC1BA7047936014919LIONALLOTLOCAL_ Content-Type: multipart/alternative; boundary="_000_A6B8F2A767638641889989BC1BA7047936014919LIONALLOTLOCAL_" --_000_A6B8F2A767638641889989BC1BA7047936014919LIONALLOTLOCAL_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Carlos, Thanks, I am fine with such a correction. Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com www.allot.com [291X55_signature (2)] From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] Sent: Wednesday, August 27, 2014 2:08 AM To: Alla Goldner Cc: Hongyu Li (Julio); Reinaldo Penno (repenno); sfc@ietf.org Subject: Re: [sfc] New Version Notification for draft-merged-sfc-architec= ture-02.txt Alla, That's a good callout. How about adding the following following the sente= nce you quoted? "Additionally, the SFF may preserve the handling of packets based on othe= r properties on top of a flow, such as a subscriber, session, or applicat= ion instance identification." Thanks, Carlos. On Aug 26, 2014, at 7:12 AM, Alla Goldner > wrote: Dear all, I have the following comment: " If there are multiple choices, the SFF needs to preserve the property =20 that all packets of a given flow are handled the same way, since the= =20 SF may well be stateful. " A service may need additional levels of "persistency" on top of a flow (e= .g. - all flows related to the same subscriber /session due to e.g. secur= ity reasons, all flows related to the same application instance). I believe it should also be reflected. Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com www.allot.com From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Hongyu Li (Julio) Sent: Tuesday, August 26, 2014 3:58 AM To: Carlos Pignataro (cpignata); Reinaldo Penno (repenno) Cc: sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-arc= hitecture-02.txt Hi Carlos, For the new definition, not sure "delivering traffic to a classifier" is = the best way to say. In case the classifier is inside the current SFF, it= =20is better to say the SFF re-/classify the traffic than deliver it to a= =20classifier. In case the classifier is in the next SFF, the current SFF= =20would only forward the traffic to the next SFF, without knowing or car= ing about if there is a classifier there. Cheers, Hongyu From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro (cp= ignata) Sent: Tuesday, August 26, 2014 3:15 AM To: Reinaldo Penno (repenno) Cc: sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-arc= hitecture-02.txt Reinaldo, Thanks for the comment, good set of points. It does seem that the definit= ion itself might be unnecessarily overly restrictive. We could say "zero or more" or we could say "typically one or more", but = I think it is better to spell out the function. Here's one more comprehen= sive proposal: Old: =20 Service Function Forwarder (SFF): A service function forwarder is =20 responsible for delivering traffic received from the network to= =20 one or more connected service functions according to informatio= n =20 carried in the SFC encapsulation. New: =20 Service Function Forwarder (SFF): A service function forwarder is =20 responsible for delivering traffic received from the network to= =20 one or more connected service functions according to informatio= n =20 carried in the SFC encapsulation, as well as for delivering tra= ffic to =20 a classifier or mapping out traffic to another SFF (in the same= =20or =20 different type of overlay). WG, Reinaldo, Thoughts? Thanks, Carlos. On Aug 25, 2014, at 1:06 PM, Reinaldo Penno > wrote: A couple of points about SFF definition. You mention "one or more connect= ed service functions" But in our implementation we have two types of SFFs that do not have SFs:= - A SFF that maps from one overlay to another, say, VXLAN to GRE - A SFF that only has a classifier (no SFs in itself) Where would they fit or how to to make sure the architecture can predict = their usage? thanks, On 8/23/14 1:47 PM, Carlos Pignataro (cpignata) wrote: SFC, Please find below the email notice of a new revision of draft-merged-sfc-= architecture. Full set of diffs from -00 (IETF90) to -02 (now) can be seen here: http:/= /www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-02&url1=3Ddraf= t-merged-sfc-architecture-00 We still expect further changes to the document; but we also believe that= =20this revision captures the key points and addresses the key open items= , as planned in Toronto. The key objective being to create a single document basis for the SFC arc= hitecture. SFC Chairs, We believe that this revision fulfills the next steps agreed in Toronto (= http://tools.ietf.org/agenda/90/slides/slides-90-sfc-3.pdf). This revision, while we expect changes, is now close enough that we think= =20it makes sense for the WG to take it as the basis for the WG document = to address the deliverable. draft-merged-sfc-architecture-02 addressed the key points -- and we belie= ve is ready to start a poll for adoption. Can you please initiate that WG= =20adoption call for draft-merged-sfc-architecture-02? Thanks, Carlos & Joel. Begin forwarded message: From: > Subject: New Version Notification for draft-merged-sfc-architecture-02.tx= t Date: August 22, 2014 at 12:59:13 PM EDT To: Joel Halpern >, Carlo= s Pignataro >, "Joel M. Hal= pern" >, Carlos Pignataro= =20> A new version of I-D, draft-merged-sfc-architecture-02.txt has been successfully submitted by Carlos Pignataro and posted to the IETF repository. Name: draft-merged-sfc-architecture Revision: 02 Title: Service Function Chaining (SFC) Architecture Document date: 2014-08-22 Group: Individual Submission Pages: 26 URL: http://www.ietf.org/internet-drafts/draft-merged-sfc-arch= itecture-02.txt Status: https://datatracker.ietf.org/doc/draft-merged-sfc-archite= cture/ Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-= 02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-archi= tecture-02 Abstract: =20 This document describes an architecture for the specification, =20 creation, and ongoing maintenance of Service Function Chains (SFC) in= =20 a network. It includes architectural concepts, principles, and =20 components used in the construction of composite services through =20 deployment of SFCs. This document does not propose solutions, =20 protocols, or extensions to existing protocols. 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. The IETF Secretariat _______________________________________________ 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 ________________________________ This message is intended only for the designated recipient(s). It may con= tain confidential or proprietary information. If you are not the designat= ed recipient, you may not review, copy or distribute this message. If you= =20have mistakenly received this message, please notify the sender by a r= eply e-mail and delete this message. Thank you. #########################################################################= ##################### This message is intended only for the designated recipient(s).It may cont= ain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or dist= ribute this message. If you have mistakenly received this message, please notify the sender by= =20a reply e-mail and delete this message.=20 Thank you. #########################################################################= ##################### --_000_A6B8F2A767638641889989BC1BA7047936014919LIONALLOTLOCAL_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =

Dear Carlos,

 

Thanks, I am fine wit= h such a correction.

 

Best regards,

 

 

= Alla Goldner

= Director of Mobile Technologies and Standards

All= ot Communications

Tel= =20+972 9 7619251<= /span>

Cel= l +972 54 2493985<= o:p>

Fax= =20+972 9 7443626<= /span>

= agoldner@allot.com

www.allot= .com

 

= 3D"291X55_signature=

=

 

 

From: Ca= rlos Pignataro (cpignata) [mailto:cpignata@cisco.com]
Sent: Wednesday, August 27, 2014 2:08 AM
To: Alla Goldner
Cc: Hongyu Li (Julio); Reinaldo Penno (repenno); sfc@ietf.org
Subject: Re: [sfc] New Version Notification for draft-merged-sfc-a= rchitecture-02.txt

 

Alla,

 

That's a good callout. How about adding the follow= ing following the sentence you quoted?

 

"Additionally, the SFF may preserve the handl= ing of packets based on other properties on top of a flow, such as a subs= criber, session, or application instance identification."=

 

Thanks,

 

Carlos.

 

On Aug 26, 2014, at 7:12 AM, Alla Goldner <agoldner@allot.com> wrote:<= /o:p>



Dear all,=

 

I have the following = comment:

“

If there are multiple choices, the SFF needs to preser= ve the property

   that all packets of a given flow are hand= led the same way, since the

   SF may well be stateful.

“

 

A service may need ad= ditional levels of “persistency” on top of a flow (e.g. ̵= 1; all flows related to the same subscriber /session due to e.g. security= =20reasons, =20all flows related to the same application instance).=

 

I believe it should a= lso be reflected.

 

Best regards,<= o:p>

 

 

 <= o:p>

= Alla Goldner

= Director of Mobile Technologies and Standards

All= ot Communications

Tel=  +972 9 7619251

Cel= l +972 54 2493985

Fax=  +972 9 7443626

 

= <image001.jpg>

 <= o:p>

= <= /span> 

From: sfc =20[= mailto:sfc-bounces@ietf.org] On Behalf Of&nb= sp;Hongyu Li (Julio)
Sent: Tuesday, A= ugust 26, 2014 3:58 AM
To: Carlos Pigna= taro (cpignata); Reinaldo Penno (repenno)
Cc: sfc@ietf.org<= br> Subject: Re: [sf= c] Fwd: New Version Notification for draft-merged-sfc-architecture-02.txt=

 

Hi Carlos,

 

For the new definitio= n, not sure “delivering traffic to a classifier” is the best = way to say. In case the classifier is inside the current SFF, it is bette= r =20to say the SFF re-/classify the traffic than deliver it to a classifie= r. In case the classifier is in the next SFF, the current SFF would only = forward the traffic to the next SFF, without knowing or caring about if t= here is a classifier there.

 

Cheers,

Hongyu

 

From: sfc =20[= mailto:sfc-bounces@ietf.org] On Behalf Of&nb= sp;Carlos Pignataro (cpignata)
Sent: Tuesday, A= ugust 26, 2014 3:15 AM
To: Reinaldo Pen= no (repenno)
Cc: sfc@ietf.org<= br> Subject: Re: [sf= c] Fwd: New Version Notification for draft-merged-sfc-architecture-02.txt=

 

Reinaldo,

 

Thanks for the comment, good set of points. It doe= s seem that the definition itself might be unnecessarily overly restricti= ve.

 

We could say "zero or more" or we could = say "typically one or more", but I think it is better to spell = out the function. Here's one more comprehensive proposal:

 

Old:

   Service Function Forwarder (SFF): &nb= sp;A service function forwarder is

        responsible for delive= ring traffic received from the network to

        one or more connected = service functions according to information

        carried in the SFC enc= apsulation.

 

New:

   Service Function Forwarder (SFF): &nb= sp;A service function forwarder is

        responsible for delive= ring traffic received from the network to

        one or more connected = service functions according to information

        carried in the SFC enc= apsulation, as well as for delivering traffic to

        a classifier or mappin= g out traffic to another SFF (in the same or

        different type of over= lay).

 

WG, Reinaldo,

 

Thoughts?

 

Thanks,

 

Carlos.

 

On Aug 25, 2014, at 1:06 PM, Reinaldo Penno <repenno= @cisco.com> wrote:





A couple of points = about SFF definition. You mention "one or more connected service fun= ctions" 

But in our implementation we have two types of SFFs that do not have SFs:=

- A SFF that maps from one overlay to another, say, VXLAN to GRE
- A SFF that only has a classifier (no SFs in itself)

Where would they fit or how to to make sure the architecture can predict = their usage?

thanks,

On 8/23/14 1:47 PM, Carlos Pignataro (cpignata) wr= ote:

SFC,

 

Please find below the email notice of a new revisi= on of draft-merged-sfc-architecture.

 

 

We still expect further changes to the document; b= ut we also believe that this revision captures the key points and address= es the key open items, as planned in Toronto.

 

The key objective being to create a single documen= t basis for the SFC architecture.

 

SFC Chairs,

 

We believe that this revision fulfills the next st= eps agreed in Toronto (http://tools.ietf.org/a= genda/90/slides/slides-90-sfc-3.pdf). 

 

This revision, while we expect changes, is now&nbs= p;close enough that we think it makes sense for the WG to take it as the = basis for the WG document to address the deliverable.

 

draft-merged-sfc-architecture-02 addressed the key= =20points -- and we believe is ready to start a poll for adoption. Can yo= u please initiate that WG adoption call for draft-merged-sfc-architecture= -02?

 

Thanks,

 

Carlos & Joel.

 

 

Begin forwarded message:





From:&nbs= p;<internet-drafts@ietf.org><= o:p>

Subject: New Version Notification for draft-mer= ged-sfc-architecture-02.txt

Date:&nbs= p;August 22, 2014 at 12:59:13 PM EDT<= /p>

To: = Joel Halpern <jmh@joelhalpern.com>, =20Carlos Pignataro <cpignata@cisco.com>, "Joel M. Halper= n" <jmh@joelhalpern.com>, Carlos Pignataro <cpignata@cisco.c= om>

 


A new version of I-D, draft-merged-sfc-architecture-02.txt
has been successfully submitted by Carlos Pignataro and posted to the
= IETF repository.

Name: draft-merged-sfc-= architecture
Revision: 02
Title: Service Function= =20Chaining (SFC) Architecture
Document date: 2014-08-= 22
Group: Individual Submi= ssion
Pages: 26
URL:            http://www.ietf.org/internet-dra= fts/draft-merged-sfc-architecture-02.txt
Status:         https://datatracker.ietf.org/doc/draft-merged-sfc-architec= ture/
Htmlized:       http://tools.ietf.org/html/draft-merged-sfc-architecture-02 Diff:           = http://www.ietf.org/rfcdiff?url2=3Ddraft-mer= ged-sfc-architecture-02

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, principl= es, and
  components used in the construction of composite services thr= ough
  deployment of SFCs.  This document does not propose solu= tions,
  protocols, or extensions to existing protocols.




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.

The IETF Secretariat

 






_______________________________________________
sfc mailing list
sfc@iet=
f.org
https://www.ietf.org/mailman/listinfo/sfc<=
/o:p>

 

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

 

 

This message is intende= d only for the designated recipient(s). It may contain confidential or pr= oprietary information. If you are not the designated recipient, =20you may not review, copy or distribute this message. If you have mista= kenly received this message, please notify the sender by a reply e-mail a= nd delete this message. Thank you.

 

This message is intended only for the designated recipient(s). It may con= tain=20 confidential or proprietary information. If you are not the designated=20 recipient, you may not review, copy or distribute this message. If you ha= ve=20 mistakenly received this message, please notify the sender by a reply e-m= ail and=20 delete this message. Thank you.

--_000_A6B8F2A767638641889989BC1BA7047936014919LIONALLOTLOCAL_-- --_004_A6B8F2A767638641889989BC1BA7047936014919LIONALLOTLOCAL_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=29141; creation-date="Wed, 27 Aug 2014 03:46:10 GMT"; modification-date="Wed, 27 Aug 2014 03:46:10 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABkAAD/7gAOQWRvYmUA ZMAAAAAB/9sAhAABAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAgIC AgICAgICAgIDAwMDAwMDAwMDAQEBAQEBAQIBAQICAgECAgMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwP/wAARCAA3ASMDAREAAhEBAxEB/8QAyAAAAQQCAwEB AAAAAAAAAAAACAUGBwkECgACAwsBAQABBQADAQEAAAAAAAAAAAAIBAUGBwkAAQMCChAAAAcAAQMD AgMEBAkLBQAAAQIDBAUGBwgAERITFAkhFTEiFkFRMiNhQjUXcWJyMzQ3GDgKUqJzVHQlVTZWVxlj JGRlZhEAAgIBAwMCAwUDCAcFCAMAAQIDBAUREgYAEwchCDEiFEFhMiMVUTMWcaFCUmJyNAmBkUNT JFQXY3ODZDWx0ZKiRHQmNjcYOP/aAAwDAQACEQMRAD8A365KSYQ8e9lZV43j42ObLPHz52qRBs0a t0zKruF1lBAiaSSZREREfw6bsvlsZgcXYzeasRVcRUheWaaVgkcUcalnd2OgVVUEknpRUqWr9qOl SjeW3K4REUEszMdAoA9SSfQdBK63TYdsl38Hx0rreKq8e5OxkNQtaAJMyrkEoKfb0HSLpAFSFOBv blbPHQEMUyhW49yhnbd9yHnz3EZy1xz2oYqKhw2rKYZuQ5JNse8aamBJEkQEAhuyILVnYyPIlYkq CKh8bcC8d0Isl5YttPmZUDpjqx1YqfhvKlTodNN5kij1BCGUevWeXA+SLlIZB9yckkJsf5gM2EQ/ CCBX8fAUyTDMpku4dvo2KHb+r+zpyX2xe7W5H+q5HzFdiz/4uzDWm+k3faugswgrr9orKNP6H2FK fJ/iSF/pa3DoWx3w3vKne0/bqYn9f/EP8vSM70zkfx/USdbBEx2n52VRNN5daqkkhIRBFjEIVR+k VtH+1TSMfx7u0PRVOIF92Tpiu+Xfdt7YJkt+dqNXmfiveFlyuOVUsVQxAUyqI4NgUnb/AMTB25XK oLsZI6cIOH+JPKKmHgU8uG5WQSlSySY5SATohLPuJ01/KfcoBPYbozajbq9eq/HWeryKMpDSaXqN 3CXcpyHKPis2comAFWztsoAkUTOAGIYOwh1oBwXnXFvJPFqnMuGW47mAuJuSRfQgj0aORDo0csba rJGwDKw0I+HQ/Z3BZXjWUlw2ZiaHIQtoyn4EfYykejKw9VYehHTk6l3TR1zrnXOtd35KvnhpfF+0 WHC+McFX9c2euOXMRdLjOruV8vzqcbnOg8rxUIh2ykLxbopYhk3qCDpoxjnHZJVddwm5aIlH4m9t +Q5hTi5Hy+SWjgJQGiiQAWJ0PqH1YFYYmHqhKs7r8wVVKOw1+UfcFR4pbl4/xWOO7nIiVlkckwQu PQpopBlkX4MAyqh9CzMGRdc+wfLd8pGsSzyVj+Q2lIkTcKOAiszqsBXomLTMIHI1BvVKwgso2QIU AKLtVdQS/UxzCIiJT1fCXh3CwrDLi6hJGm6xI7s336ySEan+yAP2AdDPZ8x+WcxM0seStAa67YI0 RV+7SNAdB/aJP7Sep1wD59ufmK2Fu31Weg+QVTbuUkpeqaNXomtWZFskXwcIw90qURESsdJqdg/m ybaXSIICPoCIj3jnJvbT405BVLYaOTGXSDtkgdpIyT8C0UjMrL90bRE/1upBx33EeRMFZC5eSPJU wfmjmRUcD7Qssaqyt97rIB/V63D+EXOzCuemWm0bHJZw3lIRVnHaFnU8Ldvc89nHiKqrZnNM0FVU XcTKlbLHjpNuY7N8RFQpTEcIOW6AK+QvHPI/G2Y/Ss8gMMgLQTpqYp0BAJQkAhl1AeNtGQkEgqyM xqcD8gcf8hYn9TwjkSxkLNC+glhcjUBgPQq2h2OuquAR6MrKpndQLqcdc651zqB9r3quY60YsTM3 Nmu894J1unRYHUkH6iypm7ddyCCThdBqs5KKaQETUWcKFMVMggRQ6Y0e4f3NcU8C0q+NNebMeRsn oKGKratNMXYxo8mxXeOJpAY4wqPLPIGSGNgkzxWZ478Y5bn08lkSJT45W1Ni1JoEQAbmVdSoZguj NqyqikF2BZFeE2dP5g6eBZayX+HxuJeACiFcgmXu5pogcAUSFYzNYqzZYxD9jEVklTkMHYxSj9AH ilwL35eY1Ga5bymhwHC2NGSjSi7lqJD6rvMTB0YqdGSS+7owIZFIK9WJPnvAvDSaOIxc/IL0fo08 z7YWYeh03ghhqPQrXUEHUEj169nWV8tKR3kaXtbHQiNwBY9fuLEzVxJeP4tUnkirNN0/UAR+vrtP +kD8eva34U98PjkHK+P/ACJBykRfMaWUi7bzgf7JZJ2tIpb19e/W/wC8U+vXnDzXwdyP/hOQ8dkx Rf0E9V9yx/2isYiY6f3JP7p+HUg43yLSvM45zu/QDjP9VjAOVzXn5FUGst6SRllFYgXJzqlOLcgr FRE6xVEA9RFZYpVPTtLwF7rovI3IpfFXlDFy8X81VAQ9KYMkVrYu9mq9wlg2wGVYS0geD86CedBI Y4tz/wATycbxycr4xaXKcJm02zoQWi1OgEu0AabiELaKVf5JEjJXcTvRjdU51zrnXOmHo+kVTK6w 7tdufe0YNx9Fs3SAij+TemIdRKPjkDnTKs5UImYwiYxU00ymOoYpCmMFZ+WvLnCvCvDpua85s9nG xnZHGgDT2ZiCUgroSoeRgpPqyoiK0kjpGrMJNxLiOb5rmUwmCi32m9WY6hI01ALyMAdFBIHoCzEh VDMQCJjCy8q94IWYpqcRitAddzxchNNzObBMMj9vTcpILs1pBRNVJQDpLEJHJHDt4GOH5xB7F8u9 6/uXQZ7ga0fHnjCY615rSdy7ahPwkVXieZgykPHKkdKJ102PIPnN42sP4T8Zt9ByAz8i5QnpJHE2 2CJx8VLBggII0ZCZ2H9IKfl6V1cH5LRRCvq/yYeyMqH5jtLFFPjRJj/tKQFZCcTIT/Kan/wdPcvt n93uEjGR4z5gs281pqYr1ab6bd92+e4oX+Wu3SFPJniC6xrZTh8cVL7GglTu6ffokJJ/kkH8vXWu 8iNAzeyR9H5K1hGCGUVFvCaNDFKetyRiAUBO7O3D2hv4gMqZIrdVsUxRUbATyVL3xT3VeUfEnLKv jr3d4ePHC4+ypnqgBoTkaAmXZrHpqQZGjEMkAZDLTWMtKveW8U8X5diJeSeIbjWeyu6ahL6WI9fs UN833KGLrIQdsxbRCa6aiayZFUjkVSVIVRJVMxTpqJnKBiHIcoiU5DlEBAQHsIdaGxSxTxLPAyvC 6hlZSCrKRqCCPQgj1BHoR6jod3Ro2KOCrqdCD6EEfEEfYR1369OvnrGevWkazdyEg6QZMGDZd49e OlSINWjRskZZw5cLqmKmiggiQTHMYQKUoCI/TpHkMhQxNCfK5SaKvjK0LyyyyMEjiijUu8kjsQqI igszMQFAJJ0HXtXrz27CVaqNJZlcIiKCzMzHRVUD1JJIAA9SfToL3m3avssu/guPUG3jq0wWFo/0 uytgTQ9X8vc8c2eJLN0C+BwOVMyDt4ZMxTmRR/DrO3Je5Tzh7guQW+K+03FxV+KVJe1Y5DkE2RK/ pqYUlV0X0IcRGC1aaNkkeCvqR0RNbxrwfx/j4sr5ZtO+VmXfHj651cj+2UIJ9QQW3xRBgVDyfHrN DB+Qjovv33JKYQlh/OLNiyfhEAp+PgAJSDBD0vL/APCAO39Xpevtk921xP1TI+YLcWdPzdmGvP8A S7v2arYgTbr/AOUA0/ofZ14Hyb4jhb6Wtw+J6Pw3vJH3dP2+sbnX/wAb/T0lOdF5C4Oqi41eNZab QBWIk6ttbRRRlooqpiFIZcEm0akAEE/iBXbdMiyggQroBEAFkueYPdZ7YZ47PnulW5f4sMirJlsc qrYrbyAplAjrhdCdoFqBElkKxrdDEArYeHeKfJ8bR8BnlxHKgpK1LJJjl01J26tJrrpr+VIWVQWM JHRg1W0wN1gI2z1mRRlIWVQ9dm7R8g79jCmqiskcCqtnTZYhk1UjgVRNQolMACAh1oDwrmvGfIfG KnMeH247vHr0e+KVNf2kMjqdGSSNgUkjcB43VlYAgjofs1hcnx7JzYfMRNBkIG2sp/1ggj0ZWGhV gSGUggkHpwdSnpr651zrnQiaVyRlv1YrleGVn+8LQkxUSk3g9zVyuCkoCDgz1yVdqgcWaw+Cyqq6 LZBXsn3VUA6RQV8ue7XOnm7+F/bdh/4p8ooWWxMfWhQKnbJ3XDxoxiY7JZJJYq8MpWMtNKJIUvbi HiOj+hrzXyTc/SuKnQxr/t59RquxdGI3j1RVR5HX5tEQq5b7bGOU1oD39x5ChV3KoeqSKp8asdFo ZT8/tlnDNWtt1QRMPj3BM/cA/iH8eopW9vnvR5mgyXPPKn6Lcf5hXxcDlI9fURs0LUEOz8J0STXT 0c/EusvkHwthj9LgOK/Wwj0MlqQAtp6bgriww1+Pqw/kHWE8i+YWREGXZWKH3KuNB8nkIoxOhZva JiBlFmyKgFkXboxREClReuTgP19BT8OkF/C+/PwShzuPy1DyPxOD1lptCUyBjX1Z41IE8jkahVit 2GB0P08vw6UV7vgXnbfQWKljjeWf8EwcNX3H4BiPkVftJeGMfZ3F+PRCY3ttT2iEWkIMVY6YjTAj PVp+cv3KIceRkxEfypi5ZHVIYpFQIQfIolUImoAkAp/AXuJ4R7gePSZLjvcp8gpkLdx85H1FVzqN fgvchZgwSUKp1BWRIpA0Yqvn/jrOePsitXJbZsfMNYbCfu5V+P37XAIJXUjQgqzqQxmTq/eoB0E3 Jd9MaTf8643wD1xHNrScLRe37UwFVb1mOVXVIRMxjgmc6JY9ZUEzgIC6M0MH8IgOd/u8yOd8ueT+ Ke0zjNiWrSzJGRzE0foyUIGdlUEnaSggmlEbghrH0TD1XQkT4frUOI8Xy3lvKRrLNSH09NG+DWJA ASfTXQ70UsD+7E4+30iHadT0XP4YYfIftub5hn98c5AghFx7Z5YH07H1llZFn8gtJsnjGPinSTs3 tgJ5PHi3qOF1DAoUAor3D+Z/LHi7jhwvgw1eJeH+M8lk4yiwQJJenuQUYrzzTPZhliiryiRjAUJt WZBPZsyOZFVJ5484VxPlGQ+v533svzLKYxcoTI7JAkL2HrhEEbq7yKVHc10iiXbFGo2kkXh5CbsJ /U/vYt3fv37AeJAn49+3phFeHb+jt0GX/wDa33J9zufxpmt396DT/wCHsbf9GmnVzf8ASvxrt2/o dDT+SXX/AF9zXopeP266zOKF/X0nHXuiTl4reWvWk1HMGk2hK2+Ofrt3UYqxYN2E3GJIpFLJM3JD KFbn9UhgKVQpzS9rfuS83cjIPlK3W5J44yfI6HHnjtQQR2lsZSGZkeBooY4bVdETS9WnV3ELCWMq olD0t5S8a8Hxq/8A4vDNjOS1sbPkUaKR2hMdWRAyyB3Z4ZCSTBLGQpcbGBJUrImdMz8fOR7/ACRm soTNtVj17PTGSyxzpQcu3I4FWORUWObxIgLFRoUPqqqiqzKYwikHe1fFVKX2u+7S14QpSOPEnNqr 5DFxMxKU7SB9YVZidNvZkrAesksb0BI7NF6xTlk6+U/EsXOp1B5dhJRXtuAAZomK6SEAfFt6yH4K rLYIAD+h39aV9DR1Vx8wnLyc4ccJ7vc6RJKRGoaLLR2Q5rLNznI7gZ+1spR7K2ZkdL86EjXKhCyT pkt/AlIkbibuH5TXF4L4PX535Br0MggfD1UazOp+DpGVCxn9qvK6K4+JQvp+0VN5p5nY4TwSe9QY plrLrXgYfFHkDFnH7Ckauyn7H26/s61Zvhd+MyI516baNQ2pGRX485DIR6E7FoOnzFzqV+kCBJNa T94aHQdM4ONjPF7OLN103wJuWiCIkF2Zw3Mbz75cn8c4iHD8fKjlF5WKMQCK8K/KZdp1Bdm+SEMC mquza7AjCX4N8WQ+QMrLls6GPG6TAOoJBnmPzCLcNCEVfmlIIbRkVdN5Zd0w9nwrjBDwOV0KjsK4 0bNCqQuaZJT45v7NiUoJ+8NDxRY1g3FYqXcTqGBdfxE/5+wm6xj83+63hXjfkkOH5fPmM95BvR91 aNCFr98xan82RWkRY0Oh2h5FZlDFEKqSNQfH/h/J5nENLx6GhjOMV22d2ZlrVw3p8q7VJZvhuIUg Ejc2p6Fnkxw04a/JrntiZ2Cvx0Rp8c0O0iNTiIJvCa1ns4ZFQkYaa+jNxaa8VVESKxr5Vdg4IVUq CiDkhXCNw+2P3jYbk6SZbxdlJbFSlKqX8VaV4ZYCxb5J60mphdtrhLEO5C6MoeTZJH1W/mn28w2I hR5lSjhvTxk1b8G192gGjJKuglQajdDJodrA6IWR+tNPjLrGu/Ev8hnsbsZePHOb2tlm8V+PO5Xi rjl8pIMyy8hHIqCwUkm6sOdrY6+ooCPm4RaHUKCZlEzax8uwuD81+L+5j9G+qrCxTdtA0VhVO1WP rtO7dBMBroC4HqAes4uK5jM+HvJPbv6r9NYNe2g1KyQMRuKj03DbtmhJ01IQn0JHX0YUF0XKKLls sk4buEk10F0FCKorIqkBRJZFVMTEUSUIYBKYBEBAe4dZYMrIxVgQwOhB9CCPsPWmCsrKGUgqRqCP gR+0dYUzKs4GHlZyQP6TCGjX0q9U7gHptI9sq7cn7mEC/lRREfqIB0z8gzdDjOBu8jyrbMZj6k1m Zv6sUEbSyH10Hoik+vS3H0Z8nfgxtUbrViZI0H7Wdgqj/WR0GPFmqr36Ws3JO7pg+s1qmJaNpqTg BVb12vMVjRzlWM9T6EUcKImZJqAHmRm2AAN/OV8s/fZdwuz5PzOX93HkVBZ5fmr9mHFB9Xjo0Ym7 DtX3egZirU43A3pWrkBz9RMCQXmnNRcYo0/EXHD28PSrxSWyvo087juKJNPiFBErD4GWTUj8tNDg 60Z6HHqHdX3XOscYivbJkppZZA60dWIsCPbDJAQO/mkxBQhWjX97hydFuHYfz9/p1Q3mz3JeKfAm MNnnF8HNPGWgx9fSW9PoCdVh3ARRnQ/nTtFD6Eby3ymfcI8a8s59Z7eDrkUVYCSxJqkEev2F9Dub /s4w7n+rp69Dxr1ZmtcxKA3hGEJTNPqUf/eBWCRrhU8s2qKLgZlKDkpEyTczp+SGIV+n4pgRCQL4 pdinUMcV/PXD895w9vOO9yVWgmC8vYKuc1jjXdzYTGJIbUdaedkRpJRVC3o9IlENsGOEKssrSWtw PMY7gvkW140ksnIcNvS/RWDIoETWivaM0cerBUMpMDasS8B1fUqgUo8kvSelZxUrqUEiLTcUmo/T REPSSlGiijGUTSDyMJUQkGqnpgI+XpiHfoyfBnkqLy94lwXkNAiz5GkrTKn4VsxM0NlVGpIQTxyb AfXZt19eqX5zxp+IctvcdbcY605CE/ExsA8ZP37GXdp6a66dSN1bHUT6r5WauuQm/wBtmXUWW1UH B1m0RB1FR6g2jbLbF33pLKu1nnlHqNEF2CzxYDAYrhJuzSMU5O4Gy2sVL3uj9z2d5Dbo/rfjXxpJ HVpYxpkir38i8xR2keUGBo1eGW1Lrqs0dejBIkiMwYpopoPFni+jj4pzR5PyZWlmtBGaSvWCagKE +cMwdIk00KM9hwVbQgm7pdNahqhY5iCyxs+mY6KdOYyPLZySzly7KQASBKKjowi8kZITeYt010lF gIJCGAxgHouvIXkXzvgOB5bPcZ4TBYz9WlI9eH9SFp3kGgUirXrCSxs17hgjmjklCGONw7Keqi45 xvgWR5BTx+UzjxY6adVkk+mMSqpPrrLJIVj1/DvZGVCdzAgHoQIzkzyIzgIew7Rnx3dJsr1Zm0VC FLVZxmuiHkKTZA7tdJNVVLyUQbSJEFHhEzCkt9B6AfD+8z3YeIvoOWe4niUknjfL2Hiif6UY+5E6 aEoiFyFYpvkhgvRxPbWNjDOFVmBB3fC/iLmP1GJ8cZYR8lpRh2HeNqB1P2swRSQDoryVy6xFhvj9 R1Otg2TjRulcDPZq3NBPbVGkfHMJKNlouYjJ92oVGIdMHLuPK1ZTLJ+qX0lAVFMT/kMJkzGKYneQ +4n2fe5fiv8A0szWehabONHBBBPWtQWq9yQ7K0kUkkHaisxSsNj9wxE6o5eF3VqsxvjfzL40yp5X j8fJsoK8kkkckUsUkCjWVXVZNzxOgO4bQ2nzAKygjF4mWqfQjrnjNxcGcWXIZw8Kg4MBuzqvKKLE jjImMJjHboih6iPceybVygmUOxOvH2P8z5NUxXIPb/z2VpeWcEyJqxudfzKLM6wbCdSyIULREnRa 89eJQFj9OeccLjJbeP8AIOAUJiM9WEzL/VnABk1/Yx12t/Wkjkc+rdF/0eHVDdBxybkpi5WXOuP9 edKs1L29LM2t0kQTHRrMeuoKYeInKRw2KZg7dqpiJRMZikUDdjmAc+vefm+Q8/5ZxL2scQnkr2uV WhZyUqDVo8dA7HXTUB0UQWrMiaqS9OFA2kjAkH4XpY7AYrLeU8wiyRYqIx1kJ9GsOAP2EqTviiVv UATOdNVB6Kir1iEpsBGVmusUo6HiWxGrRskAd+xfqouup283DtyqIqLKm7nVUMJjCIiPRtcH4Txn xzxWlwvh9VKfHsfCI4o1+71Z3b4ySyMTJLK2rySMzuSzE9UlnM3k+R5WfNZiVpsjYcs7H+ZVHwVF Gioo9FUBQAB0v9Svpp68HTVs+bOGT1ug8Zu0FWrto6RTcNnTZdMyS7dwgqU6SyCyRhKchgEpiiIC HbpLeo0snSmxuShisY6xE0csUqLJHJG6lXjkRgVdHUlWVgVZSQQQevWCeerOlms7R2Y2DI6kqysp 1VlYaEMCAQQdQfUdBTlzdbDuQE5jiSyxqLoTBa20tuuoop9vkkUF1l2yZziYO/tY1y2UExjKKlaN zGHyEQHOTwfUse2r3TZT27wySN4z5PVbKYdJGZuxKEdniVm1/ClexXYszPIlam7HcxBI7nMsfkvx ZV8iuqjk2MlFW4VAHcUlQHIH7WkjkAACqZJgBoBobvWkvQ2dDxyf0t/mOUyb+DOoSzWJ41qtcOiY SuEZCVIuZV03EpiqJuUWLdUEFA+ibkyQj3D6CKvvI8vZPw/4TuZLjjMnL8tYjxtFkJ3pNZDlpU2k MHjhjk7Tj8E7QsQR6G1fDfEKvMebQ1ckAcPUjazOCNVKREaK32FS7LvU/ijDgft6bVNjM94iY+2k Lg7IhMSajNe0SLVt72btFteIGOSGiUEhMs7bRpAOi0SAxUUUEzrHEvkqoMT4BhvFnsX8EQ5PnU6x Zy40T5CZEEtvIZKVCwqV1U6yJAN8ddAyxRxJJYkKGSeQvHILnKvO3PXq4GMtQhDLXRm2Q16ytp3Z SfRWkOjStoXZ2WNQ21FGbm/LbJ9GkncMVeVqMm3ZO5JFG3N2ce2fsI9Azl+qzkWr58wFZk2IZRRF RRNX0wExQMUphKu8R++bwh5Zys+CWW7gstFBLOiZNIYEmhgQyTNFNHNNFuijDSPG7o+xWdFdVcqn 5d4L5xxKmmQKwX6byLGTVZnZHc7UDRsiPo7EKrKpXcQpIJALYac48Uc2AsSf9UtIdRyDZK4O4UqV fMBjgRN6sn7sZprFqd+4LqNCgUv5jgUvcwRKj/mM+3u7y0cdb9Zgwry9tcnJVVaR1ICyMvdNuOFt fSR6ykfF0RdSHif24eQ4cUby/RSXwm41Vl1n+GpQHb2mkH9RZTqfRST6dNLkBDkxnQabyVpCZEWE jLs4HS42OMQGk+xmAAEJgqZDlbqu5JukKCin1IZyDVwICdMxjQX3Q4FfAPlDj/u58dIExtm9HTz1 evt7d2C16iyFBCNJPGrRu/qhsLTslTKjyM++Lr7eQeLZDxDyMlrUUDTY+STXdA8X4otSNwWNjvUf ERmeIEKwANv9QQ3/AIi2/sf9Qf5wP7G/8R/7N/jdaIfxRx//AJuH/AfW/i/+k/3/AP3f9rodP0vI f7p/8R2Ph/tf93/e+7oQYP0i85bl9z/zx8ta/pv1P+SCNU+4e37/AL+y/ft/jf09Afxrtr/mQ8h/ V9e43DIvoN3w/Bju9s+/0n+H9v7+r4yQc+27Hmn+7Gab6jT9utnZu/8Ak/m6cnIrjkjpUNZJ+nun 8dd3beMerQpJErasXWQrpTEiRnWK6Z0E55tGqKtWb8h0DkA5CLmOiUAJMvdf7UIPMHHcryLg09mp 5BlSCZqqzLHQy09Iba5uROpX6yOuZK9S2skJQOsc7NAPkafE/lmTiGQqYvPJFLxxHkQSmPdYqJP6 y9lwQxhaQLJLCQ4JDNGFkJLVGKQc6lNjWFYKYTtASJIf9MmYLffhl1AKZOLLGgArHeqkOBilDuBi CBwHw/N1hPNxblEHJP4Mmxt9eYfVCt9CYJPq/qGICwiDbvMjagqANGUhgdp16OpcljHx36ylmucN 2jL9RvHZ7Q+Mnc+AQEEE/YflI19OrZuN/HEKBA1uxXhxJu7girITzerKyCS1WpkzNNisFnrFg2TB F5awgkyNHD9VRb0yiok38ExEx9yfaP7UT4r4ti+SeQZrk3Nw81xcc0yNj8XasoIWlihjXbLkPpFS Ce1JJME+eKttjG9wd8t+Wv4oydvFccSFMCypC1kIRZtxRNvCO7HVK3eJlSFVTcQry7mACp3JEUB2 riqVDwGTC+vTqgT/AEgIoJCq+sJ/H8/tvVD9v5e4D/T0x+7k1z7hvCa1dv6wOTzFtPx/Td/G7t2n rs3a/drr9/SvxGJB485s0uv0f6YgGv4e5ss6afZu0/0/Do0OtCOh761j/wDic28ybj/xmdoCp+nk diszeUABH0RmXVKWUghOH4CoDJpI+A/sDy/f0XXtEauOTZdG0+qNCMr+3YJRv/nKfzdCt7qlnPHM U66/TC64b9m4xHZ/MH/n6m//AIfK0Umu/GxZp1A6CKtV2fVZDQTIEAHJ5lrX6hItjKFHsK7paomj E0u38fiUgfUO3VZe9nk9TgfI8hzXk7snH8bgBaJ+J7EAnd1Qfa7SLIqIPVnYKPVh1N/afjTnuG18 JiADk7GXeFh/2snaClj9gEZQlvgFGv2dF7mdqt9sPdNAJcIfJ2UnNqur1qUuxbSr986cgCsFntTb ypgTKxhY5EhjJonBwbun5iYhUUx/Op4X5z5B56/JPLEfIcdwPG3cm0ua5NbhjtTzSyDdSwOLjtHa IKddEZo4WFhtYi5eNa8R1T5pguP4FcbxNsdYz1mCsFpYyJ2ijRV9J79povXfNISAzgxjR9oDGRgk obAtVtpptr/XEBfmSxggbDdIaGcViVn6u8cpMjtbjAKNmKAyVfEhV2q5Cm9ZJFHyWUAoFJHYvcRL wD3Gce8gPyfE8qxLf8HkMxUpyY2zexkjrE0eWotHAhs0NqzVZ1Dd6KKuHsShAsS+Tx4md8b5HAjG W8VaUd+vTmmWzFBZRS4apOGdu3PqUlQkbGeTbGm7VtWv/iCjQo/JJePtQoi+DMsnCyekKQn+9DWS mQ9x6f5vV/TpmHbz/N6fj/V8ev2He2RbA8TVWm17TWrJj/ud0g6fd3A/w9Ndft16/P8Ae47sf9T7 Ai07n0tff/e2emv37Nnx+zT7Ot33jEZ6bjXx6NI+f3A2HZMZ/wCp3FT3o0KAF16gm/N5+v5d+/17 9Z58v7Y5ZlBF+6/UbOn8nefT+bo8uKbzxfGmX979BX1/l7Ka/wA/StvSThbGNNI2Kc6v6NmziVMB E3opNDquR7B9fEGxDiP9Hfoafc3Dase3zmMdMMZv4fuHQfHYsRaT/QIwxP3a9Wz4yeKPyDh2mICf qEI9f2lgF/8AmI0+/pu8Xl2avH7LjtTJ+kjWU0FxKIACbxq7doSJVP2FUI9SU8+/18u/fqM+zi3j rHth4dNj2T6ZMTsYjQASxyypOD+wiVX3a/bqT06+ZorCeUs0s4O9rhYfejKpj0+4oV0+7oe7hyk0 Gbu8s7xCpnu+ZZaU394j1s19f9TA7OZFc0G9S7vGyMQkgqq2ValWOv4HWOmZsBDHFznnvL8o8h8h Xb3t2wb8j8Q8OB/W5o0DC+JG2Oaso/NRK6pI9eWuJDJtksyRyVEUtaeB8L8Wx3HIIPI14Y3mOa/w KM2n0+0ajvIfkYykqsiyFQmqxq4mLBRSgMMvOxTLHQYeszaGc6BoaUeMhNzDmwWVtWVnIKSE1JPX Y+/lYVNuis1I8FQfFYSlKApFBUQn457bPJnnrklfyliMRkIPFnI+UJB3bdqS3kY6JkUS2p5XXuz1 0jSSL6pn17o2alQJWu7J+SeN8Bx8nFr9ys3LMXii+yGJYK7WAuiQxovyRylikhi2+q6k6OSguKsY RkXT54HJEUIeOrcoC6QgBUEYxpFr+qQQH6Aim1TEP8kOt5+WDD4bgWTFtY4sBUxFjevwRK8Vd9w0 +G1Y1I/kHQDYn6y7nq3aLNfluR7T9pkaQaH+Usf9fQ18IkXCWBQZliKESXmZxVl5gIALUF00B9Pv /UK6RVKPb+sA9CL/AJdUFyH2x4+S0G7UuRuNET8DH3FQlfu7iSD0/pBvt6t73GSRP5PsrGQXWvCH 0/rbSfX79pU/yEdFx0dHVFdABxesjqpZxrU41rchaXkZqNofWOPh1macyhHMa9HPActWrxVAZRyc qBiJNkzAqocexe4j26y59mvMMhwPxFznk1LD283ep8zyM16Cq8K20rw0oJe5FHMyfUudjpHXRhI7 khNSdOij8x4aDP8ALsFi57kNGCfC1kryShzC0jzum1mQHtKNwZpGG1R8dB69TBmHLHMNCavSyrsc /mo9vJSLqHti6bUpYWOMiJpUsuJE4rsZJwUTIGUK5IIG/IYpfMb58M++Xwv5Xgs18vY/hjkdRJ5p KuScRr9NDsJnW2VSsdQ/rCzrOpSQiN41ErQjm3gbm3Ep4zQj/VsbK8cazVVLEzSa/ldrUy/FSA4U xsCvzBjtEk6eNWtFEeRMjFM7xDWOKCR+yR79uMpL11AzNy/nakBAVNJycK1dJPGoICU6igJlTOU5 yCNs+aX4TzTxhYweVo1+S8fy9IWPo4J4zZtUEMUk93FgB/qbFSKWO3WWEhpXESRSLJJGTDuE/rmE 5THfpzyYzI05+33pEbtRWG3qkFrXTtxzMrQylwQqly6lVbSp6wYBosXcmsNnzBxobF4wZXOk2eIW YotpOvA8RVjH0m4cumjeNfNnZU0lwESgYwgoQPE3YuF3Kfan5Ww3kivgfEkEvKMTaqw5bE5Gq0Qj noGVTBNM8kkSQSo+2OUMy6to6fKyno8cT5X4he47JkeWSpiLUcr07laUOWjn2ESJGqq7SIybmQgH Qaq3qNSbOXKrOOYmxuEGxWaSmfVs0+0SUKsk1sh2FLM4bGWT7pLLoD6hROAiBvEwh+PWlfhea1b9 +/PrcEIrwvxXHm7ErBkjvtDiTJHuX5XdD3FLD0YhyCdT0MHNEjh8CYCKRzI4ytjsORoWrh7YVtD6 hW+U6H1GoB6N7rRrocug0lQFDmxWhfgIg8zNYIQTfgApt7D64JiP7vbuu4B+8es8uQA1v8x3BNlA Stjh8opk/AFYrpfb/ojs6/yn9vRD489324XxV+MeYTvf6Wg01/8Aii/1dSZpOwSme6hmNTdRkYWp X1ZVg5sLxR0RwzlCOCtStkRIcrVMgKPGgiZQBDsqIiIAXv1dfl3z3mvFfmXh3B71OmvBeTu0Ml6V pA8VkSCMRroRGq7pa2rSAjSRiSoUnqE8R4FS5Tw3M5yCaY53GKHWBApV4yu7cdRuJ0SXQL9qgepO nU/9FF1V3UAm2GRecgUMehIyOfxEfWVZm2y4quQkIh57ZZdBsiQhvanSEXccU3kHkAuTfUBL26F9 /PeWv+6SLwJxynUtYKrh2t5O0Wk79WXtu6RoAe2V1loq24ag2GGoKgG0BwKpB4tbnuRmlivS3BFW i0XZKu4KWJPzA/LORodNIx6aHXqMth7rcoOPjdl9JBNGUcOPEweX24BkDqAIfj4C3bOQ/cP16pLz 7rY97Xiqrjv/AFRK1qSTQ+v0+6YnX7tkdj+X1/YepvwHSPwlyuWx/hWliVf+80T+fVo/5ujL60N6 HjoKuWoty2vjgeT/ALBLqjL7qKn+j/WTrntvW7/l/Yft3/q+X7O/WeXvk7C838SyZbX+GhzSL6nX 8GnfobN/2aaCT4/0d/2a9EP4MEpwnLVp/wDqZwr9vT8X7ufdp/N/p06bXPesTcjUqNa2TZZzCVGZ ly2EyJROWNSnmjNowlnJCgJiNEXTYUDqj+VL3ICbsAiIRT/M04XyXNcH47zLFRyy8fwl60LuwaiJ bkcMcE8gHwjWSIxM59FaZAfxah39sWYx1TO5LCWXVMjerxGDX07hhZ2eJT9rFW3hfi3bOnqAOqvz FKcAAwAYvcDAAh3DuH1KYOsYmRJF0cAr6H/3HoywSp1Hoeu5Wzp+qjHsWa8lISaycfHxrVI7h3JP nhvRbMGyCYGUXXcqnAoFAB/HuP0AR6U1qF7LWosTi4JLOUtyLDDDGrPJNLKdkcSIoLMzsQoVQSde vgzQ1ka1ZkWGrCpd5GIVY0X1Z2Y+gCga6n/29W2bpBr1Xhw4rdicpuZmDqFAhzrLHTUOedYyldbA RsoAmBRRJdIxSGKIiYhe/wC/rcv3KcbscL9gUvEeVyrNn8bgcLVZmIYm5DYoR6RtqdxV1ZUYEkqu uvqegZ8bZKPNefly+JQpQs37soABAELxztqw+wEEEg/AnTpv+El+5b/cU8PwP/aX7v8Apv8AndRb ZmP2Sf8A+atPt/xH7P738/Tpup/2f/5K1+z93/7v5ulXkzGTWe3bPeR9aYuJEKcoWu3iObD/ADXl WfqrpgJQEhkk/UCRXR9Q34OTNf2AIg/e8DEZ/wAWeReLe7TiVeW0mBYUcvBHrukx8zOqkDTYu7vz QmR9ds709AQCVReHrmO5TxzK+JMxIsJyA79ORvgtlAD+3U6dtG2j4xif7SASHe6czd5420HPoOV0 9vKINlISJqyjAjx+o5MJBI6Wk3TRvFlYKAYrv1R9VuYhiimZQPDorbnl/HZLxhB5N8Y0LfLal2NG qV6BjEkrPqNJWlZRXELArZ7gMkDKyGIyDZ1VVfhtiDlT8W5TZgw0sLMJpbIcogX11URqzSFxoYtv yyAghwp3dAgu55ILbk33AOObor5tXjVklcGYizInZmBUv3I8wC4KhNFSWFIFAb+AIh4fh1mtYue7 Kf3Gxe4ceKZBkIsZ9AKX1MBUx6OvfNrdu+p2v29/Y07QCaaenRLxw+JI/G7+OP4sQ1ntfUGftSah /T8sRaadrUbiN+u/5vj1YFTrm8nqkay22rSuaOWYOxmYm1uosPtibFMFnD8JRm7VYLw/oiJyuDCl +UpvMhBAQ61B4Pz27yHhbcs5riLfFLNcSG1XyEkIEAiQPJMLCP2nrBSSJ2EX4X3Im3oXM/x+vjM4 MPg7sGYik29qWssn5hc6KnbdQ6y6+hQBvUjaza9CbmLpbkFyHktmQbqlzjM49eqUVy4ROmE1JrJr gvIkSVTKIlXJIqu+xvFVBP2XkUBOPiDnh+3Y90Xurt+fa8Ug8T8OqvjcQ7qVFqywcNMEYDXcs8tr 5tssKHHhlDMdt48xhj8W+KYfH0jKeW5iUWbiqQe1GCukeoJ/D21i9NVdvqNDoo1O7rSroaOq6PlR 4fO+a/DXRMrrbduvpVeWY6ZkxXAokK4vtPRfChCFXcKIotVbdX5CQhiLKKJpIKSBVVB8CGAbT8Nc 5Tx/zyrmbZIxMoNezpr6QykavoNSe06pKQASQhUepHVZ+XOFvzrhFnEVQDlIiJ6+unrLGDoup0A7 iF4wSQAXBPoD1pP8Duc9w4VT+k5HeWc4ljerSsHG6zXTMHf6mo9opL6QSj7FHQbw6CiDli7cmbzr Eqabx0g2RDuZRomka3f8xr2o8u94ftru8K8TZKjR8jQyQ26gsMqVMtBFLFZfFy2xr9KbDwQy1LTb oEmQxTbIbEkyDr7SfPGO8AeUEyHMq00vFpiYpwobu05tGjFlYj+PYrPHPH6OUO9Q8kKRPug8MI7F ttoda0dtqWb7BX2aBl6fWKraYefgquaQBN5IPLXDNnB1G9ydqCQHLN+iRdmCRSLk9QhCN8Rfb17C ud8Dx1C37r8LPDmsXv8A0zAWkDU6PdYPPcsxrurW7lpwvzq08IijiLPIywpU1Q5x7iONcqeb/pFe jejcCm1ejcCebaNI4UOolghiUn5SI33M3ypq5ljD5LeXfB/jpmsqvdrVVZLbGDJRTP8ANs3cw8ho MxLAgc8bH2ZnFHOFapjs6Piu/lPRTQTAwtAWcgVuqWXkb/LoxPu+wH6FiqFXjWYjGkGdFMIldRoG jkSMRG7GyaqkAYmNysgMahy1Hw+62t4Mme3kLzZFJAQ2OE3ckkJBIZdd4rtr695wFI1BWQ6L1qF8 XMi2n5Xee8aW/vpKxv75Z2V73e4olVTbVTKqsWIjJFJu5BFwDBNnW2LKuwRVAMAulWaZx8fM5dns zZ437e/DVTA4WWeWnh8bFQotaZXtW7CoQJ7JUKrzzy9y5aKBVBaXYNAo6zNw9PN+cfKs2Qvoqvfu NZtdsFYoK4YapGDuKIibYIFYtoe2pY+rdfRzbt27Rug1aoItmrZFJu2bN0iIt27dEhU0UEEUylTS RSTKBSlKAFKUAAA7dZdszOxdyS5OpJ9SSfiSftJ60mVVRQiABANAB6AAfAAfs66PWbaQZu2DxIq7 R82XZukT9/FZs5SOiukbt2HxUSOID/QPSHIUKmVoT4u+gko2YXikQ/Bo5FKOp+5lJB/l6UV7EtWw lquxWeN1dSPiGUgg/wCggHqt2oshoyuh8QtFskvT4a5LP3uYX1i5KxFy2m1hMMSo5V8WopTKyAmF uIlTcLHeMhOBjJeWS3AaQ8bWOUexXy1lr2DwGdllm4/mIpBCJYrT6/StIdqbLZQ7oCVSaVr9AzB5 IdS4ztj+JExXnfidSC/kMeqJkaTrv2tCP3oUatrEDpvALIogsBdA+h3ZnnFZymnRVLqrUEI+OT83 Dk5S+9l5NUpPfTEkqUA9d8+UIAmH+EhAKmQCpkIUulPiHxPxHwpwKl4/4ZD28ZVXWSRgO7asMB3b U7D8U0pA1/oogSKMLFHGijRzDluY5vn5+Q5t91qU6Ko/BFGNdkUY+xEB9PtJJdiXZiX0mkmimRJF MiSSZSkTSTIUiaZCh2KQhCgBSlKAdgAA7B1ZEUMVeJYIFVIUACqoAVQPQAAegA+wD06jTu8jF5CW cnUknUk/tJPx6DXlDpi8qghx9zo33nRNDOhEzKLBQDhW626H1H4STggmIzdy7NM5BIf6oMBWcKeB ATMcAveV5fs5mrF7XfFB/UPKnKnStaSFgRQoyfNMLDjVY5LMQZXRx+TSNizN2k7LOQHhnh8VKRvK XLB9PxTFAyRFxp9RYX0TtqfV1icggj8c3biTcxcKTmf09ln9KrVNjz+q3r8U3Yiv4+AunQAKr56J O4+mL18qoqJQ+hRP2D8OjD8W8Bx3i7x3h/H+LbfUxVJId+mnck9Wml0/o92ZpJCvwXfoPQdU5ynP 2OUciucgtDSW1Oz7fjtX4Imv27ECrr9umvTx6n3TB0BKUqnxr5HWEZ4SsMr3NVOSbzRyelHQNsTc KHEXi3iCLVoR5ILIrj+UiSDlqocwEIfxzKgzMXtF92WVPJj9N4X8kOtiO2Rtgp5IOzHuv+CKNZZ5 YpdAqRw2ak0jrHE+hOPSfy94lqjGfm8142pjMQ9ZJqxUD5R8WYqiunxLPHMigsy6q+08OIrRJuSu dMsYQVhn5E0pNs5xNSXrsgsdoggRwxBuKbyJXEyHmYxRcJnE4iBC9g7uHuO/y+MF5e5Ha8h8Ay/6 byvJWGntRW1+oozs0aqHiMYE1diylnOs6vvIVY1UA+fjf3EXuI4yHjnI6f1WIqw9uF4CIrEYDMxV 92qSr82gB7bLoNWOvoq55j2x1qrVeqPpeCBxUn5nkVaX8q+mVq89M9WHvUI5BhHuXdSVrDk8W4ip B039Q4+omZIhSlM+eJ/b/wCf+G8NwfCMnfxn1GBtiWtkZrU9p6MveYE4uBIIZJMZJjXfHWMbesQ7 5GM0LQRIqMh5d5C8eZrOXs7Vr2uzfi2S1kiSEWE2D/FyM8ipaFlRZS1BHJtA2OrsSRK8ovn/AB1o 8/cphUh3ax1ncpImSbJTdvsT9dy8QiYtoiVNu3F9IOFPbsm5CNWpDHUEClKqr1euVk8Xe0/xxk+e 511fISF5bNgrGlzKXppJZ1rV40Cxx92eSQwVIFStWRpJWCos03UAqjlXlrklXj9BSK6ALFGCxhq1 0VUMsjtqzbI1XuTSFpJCFUEkonUb8TahPhEW/YLmgKNr1+bPPgibyD2tf81VowqRTgUybdcXJgRD t2OzRbnD+LqqfZDwXk36JnfPPP4zHzPneQNxUOv5dHV3r7QfVEkMjdoeoNaOs6nRtBK/OGexZvUO B8fbdhMDWEOv9afQCTUj4sNoLfsleVT8Oi76OrqiehK5QVGebFqG1UtuK9myx8L2SappqHPIVYyp XLv1wREF1WsYoQ/rJl8f/s3Tk4mDwDoEfepwDlMEOB9xHjiLuc34Ra78sYDEz4/cJJQ+w72ihIcS ou3/AIWzbdmAQA3v4V5Binkv+O+SPtwmci7aMSPy7Gm1SuvoGfVdjHX82KJQPm6dkixzfldlaXou xKmqKbls4QFI83TbImgIGRdNxEAMdMFTEVTN2SdtzeaZgAyapZ1fqeIPfL4RRqs5WNyroy7TcxGQ VNDHLGSPmXcUkjbSOzAwkicBoZlYoJeX+DebsJU1YAqQdezbrk+jI37DoCrD5opBtcah0MWN6HzI hGhanFaTTZGGTIDRlaJMgqTbViUoJEBY7qBePTugS/rHF0oA/gt9AEKbqeM/f/xyiOEYTl3H7fH0 URQ5GwN1uOEDaN5kpSymTb/SY2XB+E/oCJjLybwBkZznLuIyEWQJ3PXjOkLP8ToFmRAuv2Dtgj4x /EdSfm2a1PjzWLHbbdZwkp+V/wC87reJk5wUcKeZ1isWBVTuHhyKO1zCBe6jp85OAiAj6SSdxeJv EnA/adwvL8959mha5JcH1GXzFskFzqWEMIYySsGlckKDJZu2GUkM3Zhih/LOW57yxmqeAwFIxY2H 8upThA0UaAb30CoNFA1OixwxggEDe7RthjaV2DVrLyGmWSzCvNG7ip5wydFAFRapAdq8fkHuYOyD c6xFDEMdIzt44IU3ZEQ6pr2x0c75883Zr3Z8kqyVOMRxPjMBBKBvECaxyTD4/hRpRIVLRtZtWo0f SAjqZ+T56HAeEUvEuNlWbJsws5B1PoZG0ZU/0kIVBAYRRRMw/M16NbrRvoceh+5NZm91HKZWKhin NZYJ03tFbKl/nlZSKIuBmyHYBEzlyxcLFQL3AoufT8hAAEQFz3g+H8h5l8KXcNgFZuW4yePI0Av4 nsVg4MSaepeWGSVYl1AM/a3EKCRaXh7mFfhnNoLuQIGIso1exr8BHIR8zf2VdVLn4iPfp6+nXthG uQu20BM74rQ1mjmhIO/Vt0RJQyT8W4t3DhRisQAWhJ9MDKoiJBTMUx0h7nTUAFHtq858d9xHjBXy Agbl1SAU81QlCkrNsKPI0LDRql1Q0keqmMhpICS8UgHn5M4LkPHfKCKxkGHmczUrC6jVN25VDg+k 0J0VwDuBCuPldSRk2rhMR05LPYn7ONUdvm6clSpV2ZvCNk3jgiS8tAvjgqtHIsPUFdZiPmmdIpwb +BwIkcP/AHDf5dsGRuDk3t9MFKaewosYqxIVqIJXAaxUlOrQrESZZarb1aPf9NsdY4JLi8ee4loY jjPIncmWONjHbjXdMxVSVimQaCQvpsSYaMGKmXcu51IbEeM9IxxNCXEv6mvh2xknlskUSgZp65fF w1rrDuojCMjlESCYomcqlEQUVMUfECo9uvtB8deA4Y82F/V/JDQ7ZclOoHb3DR0ow6slWMglSylp 5FZhJMUbYtVeRfMHI+fM1AH6PjIfVa0Z/Fp+Fp39DM/2gHSNTptQEamHd7nR3XS6px1pzj3kVETT ex6nNMjAq2i0osQ7RBXJCKJlexqa4qKh3EhXyjVAwgcVCloT3Nckb3I+XcJ7U+AymfDUsgl7kVuE 7o66Vzoa/cAZe7Ars0gOqfWSVKzssolVZ94xxv8A004fe8r59O3dnrtXx0T+jSGT/a7SQdkhUKv2 mFZpQCu0k3vssT/1Bt/Zf2X/ADYf2T/1D/s3+L1or/D2D/5WH/BfSfh/+m/3H/d/2ehz/Ub3+9f9 93vj/tf6/wDe+/rKfMWcmzdx0i1bvmD9sszesnaRF2rtq4TMku3cIKlMmsiskcSmKYBAQHsPSzJY 7H5jHz4nKwxWcZZieKaKVQ8cscilXjdGBVkdSVZSCCCQR14VrNinYS3Udo7UThkdSVZWU6qykeoI IBBHqD0E0hx+1XIpyQsfG21NyQsm4F3J5paFhcRSy5uwGFmq7VI3VU7ABSqmWZuiplADrr9Z3ZT2 u+a/BHIrXK/aPmohx25L3bGAyL767Ppp+U8rBGPwAkaWrZWNQr2Z+iKq+UuE87xsWJ8uUmOQhTbH kKw2ygf2goLAfaVCSxliSscfWT/fVyrakGPe8cGjiX/gB8ynXX2cVPwA4gkm/RKn3+vb3gh/jft6 VJ7iPerVT9Kv+JYpc5+EzRWpBV3ft0AmTbr/AOb00/penXifHfhOZvqq/LXSh8djwr3dP2epQ6/+ ED93SWvkPIXd3CBNysUdRaERdFyvQKeoideR9MxVSpvlknMmiuAD28TOnTkiZygINe/5gaLHgr3U e5W1EnuOytXjPjVZUkfDYplMk+07gsrrJOjD4aNZsWFjdQy1N3zBbFzzxX4ziZvG9SXJcmKlRdtA gR6+hKArGV+8RxxlgdO9p6dGdV6tA0uBjq1WY1CKhYtH0WjNuBhAO5hOqssqcTLOXThUwnVVUMZR RQwmMIiIj1oHwzhfGPHvGanEOH1IqPHqUeyKJNfTUkszMSWkkdiXkkcs8jks7FiT0PmazWT5Dk5c xmJmnyEzaszf6gAB6KqjQKqgKqgAAAdODqUdNfXOudc6o1+SX4Sck5qzUrsWVzrLE+Qj9MFJuTGN M7z3SnSSfgk5u0THlLIRViOBSENNMQVVOmA+5auz+B0yJ8Ue4PN8ArpgszG2Q4wp+Rd2k8A/ZEzf KyfE9p9AD+B0GoNB+T/BGG51O+bxEi0OSMPmbbrDOf2yqPVX+A7qakj8SOdCNaC/fBj8mNAl12cf hjO/MU3CzZtZM70ahP4x+Qg9iuW7ObsNctDZquX6lF1HtzdvoYpR+nRa433FeJMnAJJci1aQgExz wTKw+4lEeMkf2Xb7iehayPgLynjpikdBbEYJAeGaEqfvAZ0kAP8AaRfvHUy4F/w8/O3T5tiGts6X x3qBjN1ZGXs9mg7vZhZqKlKsEJUqDLTKDqSSSETAjISMUmPbsKoD9OmHkvug8cYiu36I1jKXvUKs cbwx6/ZvkmVSFP7USQ/d0+cd9t3kDKzr+srBjaXoWaR1lfT7dscLMC33O8Y+/rb24R8EsJ4F5cfO sciHDiUnFGUhoOiz/t3N00KbZIqpNnc08QSSRaRMWVyqWOjGxU2bEiyhilO4XcuFwd8heR+R+Scx +qZ5wIYwVhgTURQITqQgJJLNoC8jas5ABIVUVTN4H4/4/wCPcT+m4RCZpCDNM+hlmYDQFiPQKup2 IuipqToWZmYzuoD1OOudc651GGqZFS9hr4wNvj/VFH1FIuWa+mlLQ66gEBRVi4UTVIKS3pl9VFQp 0VfEomL5EIYtOeavBPj3z1xf+Gud1S7RlmrWotq2artpq0MhVhtfavcidXik2qWTekbpMuFc75Dw LKfqeBl2htBJE2pilUa6B1BB1Gp2spDLqQDozAjU0znltlhAj6DoNd0isNv5UdF3VI4yrVsQABFI rl4sg5TSRIPiUoyaxQAodilDsACHT8Ue+bwwn6X4y5TieXcQi+WCvllP1EaD8K75WR1VR8qqMhIo CjRFGg6t+flvgvmjfVcnxVvEZh/WSSoR22Y/E7UBUkn1J+nU6n1JPqfVevc1b6UY6Zs9Jy2KUD03 bmuEKrMqJHECnFm6QWnl0lSlERD012hu4fRQB+vXrY4t/mG+TUOK5BmOO8Lw7ekslABrTKfQ9qRG uOrgEkFJ6x1H7wH16848r7eOMH6vH08jmro9VWwdIgR8N6kQqQft3JKP7J6mvHMApmOIOXUcLiet kp6gzVwmP5sq9MucqrhNDzUXMybOFygdQPUUWWMACqqp4k8SI8B+2DgHgSvNfxZlyfObu428pa+a zKXYO6xgl+zG7je43vLIwUzTS7I9ld8/8ocg59IkFvZWwcOnaqxekaaDRS2gG9lHovoqqNdiJubW dOiS6rbrnXOudMq/59VtNrL2qW6PK/i3fZQhiiCbxg8TIciEhHOBKf27xAFDAA9jEOQxiKFOmc5D V55Q8W8L8w8QscJ51VFnDT/MpB2ywSqCEngk0PblQMwB0ZWVmjkR4ndGkPF+U5rh2YjzeClMV2P0 P2q6EglJF1G5G0HpqCCAylXVWAiMKLylwgv2vOJSG12gNu4RlfsqoNpiIaFH8rRqu5fs3LdJIg+K aaTl2j+XuRBIB8OgVxnjf3oe2tRhvE9zH868Yw+lelfYR2qsQP7uNpJoXQKpCokVixF8pKV4tdnV 72uS+FvJZ+t5bDYwXJ3/AHk9cbopW/rMFR1Yk+pZo4m9dGkf8XSsfZOV8wUI+E47sIeSP/LPIzk0 4UjUjCAAKxCOfsKJwII9wAXIh/h6eZPP/vczy/pXHPFVahlz8vfuWnNdSfQuBIaaaD4gfUMD8PX7 UK8A8IUD9VkeVy2Kg9RHDCokP3Er3iNfh+7/ANXXtV+N1xvNlY37klaUrfIR4irDUWNH06vEiYxT gk4RSIizMn+UAVRSIcXHiALOFk/JMVPDfaVz/wAk8ureTfdxmkzuSqndVw1c6Y6tqQ22RVCRFfQC WKJG7+xfqLU8e6JvPNeXMBxvDycY8RUmoVZfSW5J62Jfs1UkltftVmI2antxRto4NIpSkKUhClIQ hQKQhQApSlKHYpSlDsBSlAOwAH4daEoiRoI4wFjUAAAaAAegAA+AH2DoeiSxLMSWJ9T126+uuuuC ACAgIdwH6CA/UBAfxAQ66IBGh9QeufD1Hx6ES18ZZCJsLm64RcVcznnZvN7BdlTVR8YxhOYCoIpu fZNxOYT+3O3dtQN29NNIADoCueezPJYjlk3kj2zcgl4Zy2c6zVV3fps5JJI7arII49SW7EkFmuG0 7UUIA6vvA+Zq9vEpxvybj1zWIj/BKdPqU+z8RKlm0AG9ZIpCPxs5PSWD/m00D7f9kzeTEvZL7767 JP1P2e5FL7nH9h/b29kX/J/Z0xi//mRUdMT9Hw67t+X609pS32dzYLUA+/T6Rf7n2dLux7bp/wDi +9mYdfXs/MQP7OvakP3fvT/e6/WPHG/aFKsprkJoR7KyYrlctaTWzrM4QDiAiJXDhJvFpoB4mFNT 2zYq6hPp7kOu8V7QPJvlTO1uS+6/lj5unVkEkWIoloqSt6/iZI66J6ExuYIBM6en1Y66teYOM8Vo y4zxRiVoyyrte3OA85H3AtIW+G5Q8mxT/sujCjo5hEMGcXFs20fGx7dJoxYs0U27Vo1QICaLdugk UqaSSRCgAFAAAA60BxWKxmCxsGGwteGriasSxQwxIsccUaAKqIigKqqAAAAAOh/tW7N6zJcuyPLb lcs7uSzMzHUsxPqST8Seszpw6T9c651zoTNR42O5G0jqGNWY2caV3VUeqI+ScHYDrGBRx9wRTQdJ oneHDycAdu5buDh5mSKqYywg75m9o9/K80PmX2/5c8T8ufO0xXUU7zOQXM6KsgRpWAacNDPBYcB5 IBKzztePDPLsFTC/wZ5ApjLcQ9AgPrNAB6LsJKkhB6IQ8bxj5VcoFjDVQ1Pl3VShH2jDoa5qpgCa c1WpQzMrzt9PXXbsFJ5FIT/iIeLf/IDqFQ+avfXwlP0zmPjejyCdPRbWPsGMSj+u6QtcVSftASD+ 4vw6e5OFeCc2fqsNySxj0J1MViMNt+4M4hJ0/lf+8esR6nzE2AgxLplAYdVnnkm+fMngurKqzN9F EkXKbpzJt1jlN9PSRjzD27esX8RQ5BPft55jOEt1sZ454VYBWaaOUvkGiI0ZVdZZLCOdfl7cdInT QzqCdfeu3gPgTfXQyWuSZqP1RHTbXDfYSpVY2A/tPOB8e2eiMyDF6fjECeJrSCjh++FNWcsD4CHk 5hymBhAVTlAQbs0lFDikgURKQTmMYTqGOocsfBHt84H7f+NNhOJRvNlLO1rl6bQ2LUig6biPwRIS xihUlU3MzNJK8kr1NzzyFn/IOTF7LsErR6iGBNe3Ep/YP6TEABnPqdAAFRVVZc6vTqC9axnMflzy lrvM/mzlWOb3vTPUMwHia44g8d80x6C0yhaJK3umVyW1yE0xcuazbqIhwTMLxFy/n4f0QcuVETOC olQIXfA+EcOtcB4/ms9jca2HufqQyd6xaevNAsMrrWeuO+gZv6JVIZddqBgu7cRP5xzTl1XnWew+ DyORXLVP0442lBWSeGZpokayk57DlV/pBnmj03MVLbdosYcfJg+aADEcWRezZfknY/HEKKOgC2Yq 2d3nRLeOlgsenuFG8WnPm+3mjOyhytwFyDsxg9AasXxJG/5n6gVr/wAJnOamHUiMT9rsad0ats+f uegLfJsA+bqzm8qyJ+X9AGsfxUMJoJtB3DD3O/r2zou/5Nnqdvz7z+HpB4F8peV2hcPuSWybBSob R9Eyy/8AItHO67XLfEA9vq+aydnM2y0qsHRYhhBEjJaJTg4yUO3fLySChHiyZTD4HU+SeHcLxnOs TgcFYkqYu5Womd3ibSETrHrY0eZi+5WM0ke5BGQY1JHqE/jrl3MclwnKZzNwR2snTs3RCiSLrMYG k0r/ACRKE2soijk0cuCHYD4Fml+YJhY2NJSzvHoazWTSapwmhKjGuNRWRiEORnNpOyy9cyK0TkbQ ZQIaBzOoUuVkpqaBBVyqdBNsWPROqByrz4MkqSWGyl6SGpUmyzysK4LGjie2r2Y0aZd72JZY44ot QoBLmVgNCh/62x2o64xlFJbVqHFrGpsEKLuU3slaR1hbakEcUjyy6FjoFEak6h70H5Sl7ZeMIzCX xBOIveh3fnHlWptGGjJy0RmOkcIaswslhYQUiaoMjXyv3wko3Bo7EkYoxIsAmSX8R6bsn4cWljsl mIMiXxtWviLFcmDa1iDLSNGhde6ey8O1ty6yByPQrr0vxvl1rmQx2Jnx4TI2bGVr2AJ9ywT4qMO4 Ru2O8k25draRlAfUNp16cfvko1HklqGF59nnFP1IfScHyvkRpd4ebNDoRuQ0XQ5+81122+0vKfHy V4mWT+poFZJM/RO8ByqdUjYjbur1ybxPh+J4fI5PKZrSepkrFGCEVWLWZoEhcHcJWWFSsh3ltQu1 QC5f5frjflPL8py+PxuMw+sFrHV7s8psqFrRTPKhG0xhpWBjG0LoW3EkKF9RZ5n81eSWGc8Nno8P f3sJx8DiZ+m49daKglonLOQ+oUDXZ3E76aQWhHDtFWZu+WpwxBfLLRvuJJMiiJhOQSTLgPj/AIny LxvQyM9ZZOT/AK33GAZw1ilXmrJbh2hwDthsGU7AJNsZIb0OsQ51zzlPH/Il/HwWWj41+jbFJVCt e7PDZerNuKEjdLXEQ3kpucAr6jTJyL5kk4VpxzzO6xNdvM+lkvCJHdLpP6IyqmrWrQOUue16eeWL JMiYUx0x0KvZupMtHlucEkoozMsiBWzY4IiJ/jOeBzYfK5fHvLWrG7ljTiSAyVo4cfO6BLNlpQYH n2stZTHJu2fO43en1hfOIgTF4q+kViyKWKFuV5hHYkmvwo5etWEREyQblay2+Pbv+VDt9cnjl8mf IWkvbqly5otdkalJc0uYuLIaDAX2PVa5GOE57ZdGZZcnGx+ZV5O3RDReprRMTMu120jJoqndLplM gCSvxyvxHxfIR124RYlS8mAxdowPCwNn6yeOA2NzWH7TESCSWJQyRkBFOjbl++L+VuS0JJ15pXia k+dydUTJMNK30kLzivtECdxQYzHHKxV3BLsNV0LshPm9qL3HUdYm8LlYRzCcb7/u2kUlK7qSc5Sr JGchonjbk+UuDkpLQxZbV7jNt5D3ztBn9rh/Nf2rrt26RWPb1ejzpwtfIpIkmWhpwS9raksbUmvW bI/NPy1okZNilu5Lou9Ollfz7SkwYzNjHvG8eLmtzxd3c8TrdWjXrn8ofNYlcPvYL249W2P0+bp8 pWt56EhmctxVgbZymg+Umf8AF+Sx6l7qgSqSUrsONyevZZc4HTLLnEQ1CGlUGHsJFB8xaHjTFUXM qYABIW7H+HMJlNuXgzMkHDZMNNkFtS0z3FWraWtYievHOx3KW3oUdg/ooA+PThf8u5nGbsVNh45u Xx5eGg1aK2O2zWazWa8qTyQKNrAbHDopT1Yk/Dpl8YPkD1uw8stn4oy7NXWNje8qbQm6p0jMxVXq 3GfjVU8/oMhcp1K0saudfQzxeh2FzBwUeVAruWVSM5XdNUOwmcOYeMcJV4VQ5pAwpYFcNHpKqtJJ fvyTTLEnbMmkG6BFmmfdtjBCKjt8EPEvJOas8yvcOnU3M42Yk1iZljjo0Y4YTK/cEes22Z2iiTTd IQXZ0X4ldz8542XhQ0j55PMKDO0xCmTl1mLXpm6QGTEtL+Dk2LIuO41WUa9d7louxS0e6UkSomjm MMzZIlFZ6KivgnC/Gnjep5BdqxuWY75sJEsdem9ntq6k/VWpC8MUFVWATXe8rOTtj0GpmHkfyJb4 Ei2BUrSURA8rST20r9wowH01ZAkss1llJfTYkSoPmk1OgYnE7k/yJ2Pn3zDzmyx0J/s80vN+OV0z dgpYIgtgo6Om06QsMEr9raVBlLzz3SY8q7yYTdSSyNcdR6LZsZyR0KvTjzXiHFsD40wWVqNJ/FFi 3einbY2yY15VR/mMpVBA2ixFYwZ1dncIU06b+G8t5PnPI2bxdpY/4agq0pYBvXfEJ4mdPlEYZzOu rShnIgZFRSwfXqv6+84eezS7bVDkdwsc6pvym8ZcEzunwNtp6qNgq96ZOTy+CyVld5ogaEq9wjTM 3y1ndpOH7J44VbFJ4ICJrNxnjzxs+Px85WR0n4bfuTyvFKCkkJG24sYnO+SJtyCupVHVVcnVvSt8 jz/yKl+/AGjR4OX0acMSSRkPHKDuqM5gGyORdrmdgzqzFANF9Z5ufzRzFKqkRHz2E55Vdpb6dyuz e71W+8hmlUzONkeJRohGxx9S0s2dSD21WbS5aeaxNaZHhmZFpL1fXWTQIRRWN0PAUGQuvLWyVqbA Gnjp4pIaRksMuS3FGkg76iOOBUaSdxKxEe3apYkLIr3naehTSKzjq0OeFvIQSxzXRHArY7bvEc/Z YySTs6xwL2lBfXcwUAmfuZPMm5veBOI7bx6lpbL7Hyuu3HOiVmyysPFydmy+O2+YjhnHZomSQfwr iywUUV0wAwlVRTcH9ZEwiVJTqM8D4HQj8lZDj3KES5Uwte9NJGrMsdhqitsG5SHEbttf7CVG1h6k dSPnPOb0njqhn+NO9S1mbFKKN2VWkrraZd52sCpkRdyfaA3zKfQHqN7nyI2z42Y1/SNk2ymcko7X t5hKPxdte9abH57MZ1Tz01efvz/lFrELmCEOyjK67aJnjRZQ8hIPRegQBKmJE2ztQ4vx/wAsSrkM Dj7GJlo415shHTrtOs8vdCQrj6z2CxZwSJN8qIuzX1Opdrvcmz3iyJqGcvwZWK7kVioSW51haGPt F5jfsLAFCoQCm2N3bdp6DQLHhvmvtllpkTaMw4kjOro8MLLzLvrG6bWyo4U2tZvslwx3SKyxMGeT p7WunJ1VN1BOkganlW0giY7ZuJTk6dB7fqVS+9PL5vtqc/Hi4TFUM3dknqxWoJD+enbG2QrMp3CN kYB31B6bD55uWqKW8The4wwT5OYS2hF2kgsy1p4x+S/cO6MNEw2mRXUlF0I6TXfyhbZmGqc+9Svd MjbRxzyfKuHdqxqimutcrs1A2TkixaNs/Zy0opTEVkY/QBl15O0O3j18FUShwTZIPwXEevVPD/H8 xhuM4bG2Hh5Vdu5SO1N2ndHjokmYqvdILQ7RHXVUT6gy6yNFt68n8t57E5jkeXyECTcYp08bJWi7 qIyPeAEIZu0CFm3GSdmZ/pxFpGsm7p9Rny96NcIrOIHJOLlU2rXb5yB2XjqhCULkbBJ5lMz2X0Cu 6PE6Fn2oTtDj2lrze11efO5Mu7aRTpl7Bwl6aynpAo3TeDsVQmt2c3mJsfg62Mq3i81F/qESxM8D QT10mYxzxyIF0VpFbep1UbtHCLzXlLsNWthcRDfzVjJWaQWG6nYZ68KTrNDYeFRJBJG5bVljZdjD Rjt1MDmJzVvXHW0ZZmGY4tFa5q2iZ9sesP4iwaQTOarWqLhdUZ2e3iaxEqtteSljnF3ycfENiMk2 5lxMq5XQSJ3NBuCeP8dymnczGXyD0cLVtVawZIO/JJNckMcXydyILGgBeVi5bTQIrMfSbc355kOM W6eJxNBLuYtVrNgq8/YjSGpGJJPn7chZ3JCRqFA11Lsqj1ErCOVG+coPkhyZ9COJup8U5ngpSOSF YzxtfoRoMghp55+C/VOl1xGkSTyw2WLuorwacQ2mm7NknFtZYjlQVlWSs25Jw3jXD/FN2OwI5+aR 8jmoyTmFztNfY/bgcyqEjaLSYytEzOZHgKDasghvHuX8j5b5RpSVzJDw+Tj0V2OETINRPvTuToIm LususQjWUKgjSYOdxjIscqudXOqkaT8ptbgJNlXarx40HgzE5X+np+mupyjRmtWSutft8KEzmyCd kcbvVHjiRlRl3ahKk8ArJsZ0kYXJJjwzxz45yGJ4bbso0tzKVcu1jekoSZq0bnc+yc9sU5AqR9pQ bK6yOEb5DD+YeQvIVDKcvq1nWKnjLOJWvseIvEth0G1d0A3m3GS8ncYiu35alx84LSb+XaVrETKV S95HlOTbtG8or1xweQ+m8i0obC4FvRMyj9Vf3qy7YjmR1GTZ9HSraIaMSQhlXMuumHqJlOJCwqv4 PhuTpdxt67d44+HhvBq9EvbczWGriGOobHqQytKz93RYgfQkamZ2PNM1SF6eRpU6XIVy8tIrPd21 EEUC2DK9rsegKssap2tWkI9QDoHdyf5wW67fD9dObmCr2LG7rNUGp2Kug+bRklO0qaDXK5SLXF/9 8xCsbKoJLpSDRF0oyIDpqcq5E0hOUCIeH+PKOP8AOdfx7yQRX8fHZkR9CypKn00ksbfK25SRsYqH O1gVJOh1W8t5/dv+E5+fcdMtG/JWjdNQrPE31KRSL8ylWGu9QxUblIYAajQMN35RbrxgrnNzLLzv 287DU6Jxv4sciM/vcZL5dmvIGmutM2Ws0C3VaN0iHyuRqDiJeuXQLid3WXK5I8yzVISqH9yM+45w 7jnMLfHszjsZjaF2zlcjRmhZbE9KUV6sk0UjQNYWUMANPlsKC+121A2dQXkPLuQ8Sq5/EZDJZG9S r4vH3YZlavBciM9mOGSNZ1rtGVJOvzQMdm5F0J3dGnHfKLapbkI0zWE47ISOKv8AmxK8EmOzPdaa x1nHVKbVk7BdJhxlwUd0detpqGOSPXSlwByRuYy3t1FE0eoBL4epQcYbLWMoU5AvH1zBqisWj+nl k2RKLHdGknwLgx/KWAXcAW6ncXlu5NyVcVXxgbAtnmxIsmwFk+oij3ysa/aOqD1CESfMAS20kL0H nD7nNyqvGhcII+sRV2v2IaVhXK+8WGF03V6Bdd30SUy3YrHXpF+8m2eW57ErWOqPGKEXWY1BaJjp Fi8D3rlIWh1xnXOvHXDMdi+Qy23r1uQ1MjjoUevWmipwLYqo6qENidgkgJksSESOjr+Wh3heoRwn yDzDIZPAR1EsWcBax+QldJ7EMtuZq9l0YlxXhUvGQI4EBjR0b8xhsLdK28fKbsF443cqWlFToGNb VhjXirc/1JiuxVrkNF16J2jeKzn1ly22zilEiqrHavSkFlmc2gxCYjQOuYEHXkmAm8eN+G8FjuV4 Z8ibN/j+RbIxdu3VkpM7Vack0diNO80jVpSA0RftPoBuTQ9e3IvL2byHFswmPFajnseMfLvq2Uuq i2raQvXkftLGtiIErKE7iak7X1HrYdzI2XUM55W/G/Q6RcH1ep+zbJp9a0+Cas4lw2t8JCZ4nNxL B6u/j3b5mmykiioUzRVucwmEDCYOwBV3A8Dh8rwvleSyMCy3qFCvJXclgYnefYxAVgDqvp8wYfs6 sznGcy+L5jxbHY+doqV69Ok6AKRIiQ71BJUkaN6/KQf29Bb8i/L3ZMWsfPGPxKxaBF3nLuK+HXGO dy93rKmZUyLvmkvKrO3Kj0RxnjqUR0lq3MRH1XUw4bOirAomk3O2L60/8WcHwOfq8bl5DFVfHXMz biYLFJ9RK0MAkSKaYThTAT66LErLpoSwc7YJ5O5rnMDa5FFgJbKZCph6kqlpY+xEs05jeWKIwlhO B6atKVbXUBSg3LlU+UKUxHWcq4i6JT0brZqlcOP/ABz1+yTW9Q103x7rev09nNubxWKPFZxWkNOy mky8tHx07YRNAOTO3w+1jVAQ8Vk13w/DyHCXecYuc16k8F29VjSm0VMVq0pQQyTNPIa9mVVd4YPz l2p88o3fKop+WpsBmafC8nALFuGenSsu1tZbhs2Yw5ljiWCMT14mZElm/Jbc/wAkR2/My7F8qu+7 VxJ5a6ji+R0fM5fNMluNvrk+pvFJsOl47J1fQ5WiyVc3TFp6mJWKkauaAh1rHCx3sJeAkkPFmrJo uQ8DOFXwzxrj/NsJh8/esW4Ld6KKRPo5UgtLJAsyyU7SSmOatvYQSvvimjOrrCyeoQ2fMHI89wzM 5fBUq9SapSlkR/q4nnrNHM0TJbqvFvisbFM8SbJIXHyGVX9DLtD+UzRYeQisd2HAo1htwaVwVyaK cwmphM1LQ0uY9fmJdHTY+QRzeIdNI6is6pIqyrVuxXbi6IKCbkhCiqDHkvDmLnifO4LJu3HvpMvZ YPX2SQfpbqprspnYFpjIgjYuDtO4oSdOnrHeXcnDImDzeOVc/wDVYmupWxujm/U0Zu+pECkLEI3M iqhG4bQwA16HOj/LZeMO4950vozyobZp9td8x9IXntT0WOxRCUzPAtptNIrmfUs0Hntnb2rZL0jF gyrsKm0QIudEBXc9zAPUqyPhLHci5PaXFLPj8PAuLgCV4GtlZ7lWOaSaXfPGY6sJbfPKWJAPyp6d RfH+Zshx/jVVso0F/LTNk5y9iZaoaCnakiSGLZDIJLMu3bDEFAJHzN69Wkf/ACD5T/6J1X/cM/8A kH/8rof6qf8A0T/aX+tX/wDV/wAH/wBbqnf+mGa/5il/+yfov7w/4n/e/h/w/wD2nx/s9W7/ANSs P/y9z/8AXf1n92P8P/uvxf4j/s/h/a6ceM41llQ5jc0NhqWyMLfpuvsOOrXXsfZzFZdvcgLQs9kY HPHM1ERTxWxxB73Ancv2gyqKIuEwUM2E6QD2SZ/PZm9wTAYK7QaDEUWvGtaKyAWe9OrzhGYBG7L7 Ubtk7ToH0bpTgsHiKXOM7m6V5Z8tdWkLNYNGTW7MLJCWVTvXvJude4BqNSmo6Bd7wnxBfdnehhz4 immcD8ldZ5BReEkXxM8e15vsocidkyeQu7lytc5O82KtppJNKomdrIRrHzUBo4WOVySxo/IPIV44 uL/hp2yv8JSUmuaW9xxJb8uysIAiWFJNS1khkkfQb1UbDXz8CwDchbJjkaLi/wCKo7i1Nau0ZUL8 9cyk91pXTQLXBV0TU7GY7wX3EPHa1x6zXe3OD7AvycpVh1HWdDo9HjpvNVGlUvj6Zn5e35ZGX6EO iyWkXtyW9m4UmnIDGOCdlQRAFe8G5xnbfKMtjU5JRGIyEVOtBNMyT6yQhUWKw0L6kKIhuURL+Yp9 N3y9TbhWEq8axWRbjt45ahLbsTRRK8GkcxZ2krrMugLGU7SZW/LYeu35uqguF/D/AI3TXE2Siz8j cFxDX7T8g9b5BYO6zvccX3dbDdcixkW/GXDZyRhbOaj7JaEKsymVE4NuqmaXQfuBQIBkT+F5c+5z yuvzVJhislkcHDxiSlcE9S1TFus2037aK8feqxmQxAzMD2ii7jow1pTgnCeLWOGvCcpjsfm5uSpc qGG3VtmpZXcKNR2WTtWZBGJSIlI7gdto1U6E2HBbBXr7BmdD+QuKrvJCh7LzTsdr0OvOcIl7br2m bLEQhOY8OxzZ6u+g6naqRXW7NJVs0avVKayVIo7bnVFJckQ/6jckjjyUmS4u8vFLNDFJHA4uLFWr 1Wf9LYzgB5I5XLEMzILTAhGA3KZX/wBPeOySY5MdyZIuU172UeSZDUaSzPZVP1NRASUjkiQKCqqx rKQXUnawJzhDxp48YveKvN5ByWgNnlozh5kuSR0HEWOgTJ5LKqtd7pNVTWU0arIPXqsTZZaXeMkH afeOWM0OVNVRQpvGI+Q+W8oz+Omr5zEy0IHztmyzsky7bMkUSSVtZFADRqquVPzjcCQARrLOAcV4 zgshDYwmVjvzJhK9dUV4W3V45ZWjsaRsTtdmZAw+Q7ToSQdGhy/4q8TtUmuZcluXKGrZux2DDMFo OpQs/dM7rTTH2VP0N/PY7o8otPyjFzFKWC7mO2j/ALkZBpIqlVbomUMYSlXcG5nzXDV8DFx3DzW5 KORuTV3SKeQ2jLAqWoFCKQ2yLRn7erICGYDTUoubcP4bmJ85LyDLw1Y7uPqQ2FeWFBWEUxetOxdg V3y6qm/RXOqqTroGDiXB/Ho7TYSb41c8zJV6FpHDdpyYoOXzGZWGe1wuB0CLZ4bNzNzhZh7P5JVd cpTJsvMMY5AqNrijD6C5EFTGM5ch8h52XESV+W8b1tSWMoaE1hbCJW+smY20WJ1CWZK0pYRO51ry fiUsAA3YDgGEiy0c/FeRaVY6+MF6Gu0DvZ+jhUVGaVGL1o7MQUyIg0sR/hYKTqwdu4J8P7pifJKn 3bnpX6pjms83bDsbGVkLhiEXFYjyRXC+PdXzKCtyzmM9ewykHMu2zqEkXIyMUwjR7JAIvTrOfHvI 3OaHIMTex/G5Zs7S48lUqsVtmt0R2RWsPEA2iK6qyyouyR5Pxfuwrbn/AB7wm/gcpSv8iihwdzPv ZDGSqq1bx7xsQJISursjMrRO2+NE+H7wsoW3hj8b0+7+R5xNcscujGfJRlmBNbZsNZyiGLxpc1e5 x7yqvfWJOF/T6Nh2H7UuCEwVBF0+RRZEAwqiBvKjz7yvWTii18Lcd8S1j6YmtZf68SRMJBps+cpV 7g1i1KoWkP4fT0u8F8XWX5Q0+ZqImVWD6kCxXX6ExygxnXf8gez2zpJoGcLGPj6vyL4f4ix0atSW z836ffOU0VzfxXdNGsByZFndjuupVXH3tRxTCS5hHTbkaehJZcC75iwS9xNSxDLvUzHT8RSbZudc hkxU0OA49PW4c/HrdOBP+JnSKvJaEtu59QyDulbGiO50ijO2MgHXc5Q8JwEeUilzufgscuTP1bc7 /wDDQvLYjrGOrU7Cse2Gg1dEGssg3SAkabekXxK4fr8qJiw5/wAu85i+YxuZFm5GItK5YcfkNsYN V6J9g1HjTL1lCTPcJbM5GnN1nD5msgm9ju6joBIJljKdzc25yvDY6uTwdp+CfoMdEl0tLUYibfXv rIV7S2FlIVGBKP6J66KB1FwzhLcvezjc1VTm/wCuSXQEes1oAw7LFFow3caBogS6kBk9X9NWJXee HErD9v3KZuNm5n1fjhc5jh9eMl1qmzamRS0vKcZ3dmk5yTu8M30SRbSmaRDCyOXDaYsbdFRuuyJ7 UFmipTLim8b825Dx7jsdCpgJsrQjzsNmtKn1Kqt8RqiwsYFKzsYwrRQMQyud+1wQvSjyJwzj+f5A 963nYcXefCS17MT/AEzM1EyM7SqJmDQKHLLJOAQVGzchBbqcuO3HXMqDym0vWMu5MpXWcncJ4/0P acYjX2dziAjS6YjEYnp8qWI9e2Uwk9T2cgvHt/JNhKFeOF0zKpppAlHeU8py+T4bUwuYxBr148ld mq2mE6H82Utbrru0jl2SlA59Xj2qpCknWQcZ4xicdy+1mcRlRPYkx1OG1VUwuPyottWdtuskW+MO UHokm5mBYAaD/aeHfGeR26+3x5zKiYxCwc9uNu2P8teWfJzNq5yozgCKV3LSvlnLayJWjUIcySKE Auf7l6JSHbIqj9Rk1PnXLYuPVsamBd2i41fqCwI7OsmOn/HY0AMfbrtqTMB29dQ7DqN3OEcUlz9n IvnERZeR0bRrmSvomQg/BX1JD9yddAIT8+mhVT0ypPg7jM1pclJYX8gcTnfIWV5H81r0wdQKmN3q xxTfc5Copch8iiKY6lkpdGzZNNxDNRCWKqEpWn7wfeIH80U03GLyJnq+JSHkfGHtcXTFYqFg/wBV CjGosppWWlClTHZRmDR6dudF/LYaMSgl4Bgp8q8vHuSJV5M+UykoKfTSuotmP62ssRbcJK7KpEgP cgdvnU6qAanJ7jviF24kVLAtY3aYoUJCvMkhc13m8aBXQ0EuuUl/Fnze0L2u4C3irjoNknYsPdIC Qq8ud04IiCSihDp1/wAQ5TyHH83n5LhcbHZsSLZeenDC/Z+mlDd+MRxatFDGjfKddIgqltwBBnnL eM4C/wAMh45mci9avG1ZYLcsyd76mIr2JDJJosszuvzDTWQswXaSCAeNwhyFq9kWst8htVfc9F+V EDrrjaJiMwr74nsDHJ31VjMwcccfuqEMWJfZM8WefZSKpSpwKR8muVBIqfVhjyFnHjR4OLzL42GG esKqtc2fSmyJGsC9tL7hZAXu6GMesZUsdeq//gHCJIyTcmhbyKcwlk2mWpv+pFcxrAaW4LtNclu1 qJD6SBgo06ctq4K8c4qWv8XqHOOTkdBf/G3e+POkyur6FQX1/Rx+0bZMaFbeSVkVsMshKx9YibpK LQrVVyUsHGNEUWXuBURARSUvI3Kpoa02H46iYteWQ3YFrQTCE2o6iwR0E2KVaRolErBfzpGLSbNG 6V3PHvGIZrMOX5A7ZJuLS0p2sTQmYVpLTTSXnLsGWNZWMSlvyo1Cx7tV6R7/AMIOKlhT3gXPOqNq 9fu+I8OKJpTAlsxEWlVv+UlrX+x9s0nIyYHdwZrUEKr9uhVVG8dayybj26hxBsKCjGeQ+Z1TjdvH Hms18hlJoG7dvWSGz3P1Oqqr6P2943ygM9btruA+fd4ZLgHD7IyO/kKw1rGPxkM47lXSOavs/TbT M3qnc2HZESqWO420n5ds4wfECr1bWOJtt3LmxM6XuVK2fb9RqDS5uaBVk9WtGgZdB1GcomU56D5V 3UqLntPhU5BCDg1XwN1Hbl0uYQWKZOO2Oc3LmFzdLjvH46nHbFCpXlMQmk+mjhsPKk1mfTSSaeVy hmmCbgqIo+Ugv8HCalTM4a7yDPSWuQQX7ViMSmGP6iSaBI3hrw66xxQxKHEURfQs7sfmGjt5y8ba JumhZRMs+VcZxi3Kp51uUDDrrpZ7ZHtww6912MitrKFGu0jGulUa5EtUF055qp6MEoqKrlNYpiAR D465ZkuOYy7Xkwr5jjs9qo7AGeMRW4XZqn50SsNXYkGFhrMBtQqQdVvkDi2O5Dkqc6ZhMTyCGrbR Sey5lqTIq2vypWU6IoBEynSInVg2o09eMXHfjTnG459d8V5AQV6Xr/A3LcKoecx1uoVodSmDVS8v 5Ws7aLyvLhLTzKz2UztsMs3QThnLo6pEh8ilTT65fynluV47ax/IMZJWWXkli5NO0U0YW5JCqyVN HG1DHHtbtsTKqhS3oST9cT4zxXF8grZDA5KOw0XHa9SGBZIZC1SOUtHa1Q7nEkm5e4AImYsB6gAD tya4XcaNL1jmXcZ3m/FZK31tfiUXk5nTixYyo0oV6zKTqbnjvMz72zKJWPP3txhoQzSLj3qqCM0a TVWTK5ErYiUo4jz7luJwuBoVuPPdaiMl9BOEtazQ2FkF5UEeqTCJ33SOgJi7aqSnzloxyvgnFMrm c7esZ9KS3Tjvr4S9XSGWBozSZzJ88JlVNsaMQJe4WAf5QvrbeHuFSmu2yx5Nzio+c8qJfmBpWwUO Rco41o81SdFsWLNKTq+NnymfmUQtqjbLzIyKjVcqMtEdkXw9iAIqdUudcjhwcFXN8dsWuGpgoKsy g2oElgS2Za1r6lEPb1saoGGscvzR/H4d3eE8emzU1rDcgr1eYPm57MLEVp3imeqIrFb6d2Hc0g0c qdJI/lk+HxJvkJxkyyZ+PO0cZNk5Jz9dzT9H1WCunJXV7lXHVgOpFXuv2A9itduuTlnXQcT9jZkZ fz1UyJFclQRMByp9RHi/LszX8oQ8uwOJily3fkeKhWicJ80LpsjiiBfRIyX9AddpZhoT1LOS8TxE /jSbimcyskWK7EaS3rEqF/lmR98kkpCau4C+pGm4KvqB0IOn8F+OT7JOWFJ5L8+0bBqew5xgjDVN n0Gw4hQ3+WYnQNJh5fKWzGixwV2r1Go221svYjJPQ8JZ8uHoqe57+c5w/kXlUebwuQ4lxkxYajbu NXqwJbmWxbmgZbJMzb5JZYozv7aesaD5hs+EJy3j7i8mFzNDlXIxJl71WmLFqZ6sJr1YZ1auBEuy OOOSQbN7ekjn5Tu+I3tsMkJrnTWbBSJGLz3IYf5Rbtp08d9yx43XzCLTrbbNhaWeIpdFhvtfIaF5 UXxdADv6VJIuWdYSBcUDqoLionK35FFX8czVcij2s5Jw+KummNvQ3I6xn1jaWZt1J8dCDoluMq1g 7dwDLoYuvH5Z/IUVmg6VsKnLpZ31yNGapJZEGkixRLturkJiNXquGWAbtpKtqJ1o3BDhzH5Rx5qt Y54Rbym51gvMilytkr19xY6Wz8c9bvNmmN6fDKgtKsa/EZtYZRZo/sUQIEiVW3g5OioUQCN5HyRz uXNZS7b42637WSxcqxvDa/4W9WhjWmNuil2nRQyQS+sgbVAwPUhx/jzg8eHxlOpyJGo1cdk4mdJq v/FUrEsjXDu1YIsDsVeaP0jK6MVI6akXwL40/wBxOlVC/wDyNUGzV22ceuJ9DLeokMCodfoeMZTu bG2YHZYttFTjmHVi75ZWIwyMvJOXSc9KOFjoqqKmTbJLpvJPLf4jqXsZxWzDagymSm7LfWTPNas1 DHcjYsgbdDGe6Yo1UwxqoZQoLlHD464r/D1ulkuUVpas2Mx0PdX6OFIate2JKbqFcrtmcdoSOzCa RmKknRBYJzf45VfetA4sSQcqFuMWx5vdb5L4a5jCZ1JWO7WaaqrVhYGNdq+geqSzvIattlVFUGrd yKbdc6ipOwEMWsfHnKrnGsZmYv0YZjBW68K2w3fVIo0kJQvJDp2w8hADMV1YAA/EGyef8XqciyWH l/WDic5VnmaoV7LPLI0YDhI5te4VQEkKG0BJI+BAt7Vwnwqxx/JaL5Cc82f94V94u5PmO63G3yOL UqdrFMq+uKXCq6nZ6+RWGiqqys0kdOCRVXQaMFik/lKHcj5BMeP+QeR1ZcTNxjjbfpdbMWbFOKJb UqSSyVu1JXjf52kMa6zEAs419QE9OojnuBcetRZWHkvIl/U7OIrwW5ZGqxPHFHZ7sdiRPlWMSNpE CQqH7CX9epmacQa1YeVV/wBLzjmnY4Cuu9Ty7QOROAZo/orScldnz+jwMLWo2zX6AekvtJp1xr7K MezdRcoqJy4GA6aqCKxSgwvzm3V4ZWxOV4/FLaWnYho3Z1mKLVmmd5GjhcdmWWJzIkVlSDF8CGZS en1OFVbPMLOVxeeljqtcrzXacBiDtahiRY1kmQ96KKVBG0tZgRJ8QVVgOhrjOC/G+AunKaI3X5BI TR9JnOIug4landpk8JpezZpx7ss5CS85pW9TrZcbNpVirzxvEtU7XY0WDJszAiR0vUWIqErm8i8r s0MNPxzjElTEx5yC3GI1uS1Z7saOqQU0I7cCODIxrQF3ZtWDaKV6isXj7i9a9l4eQ8kjtZSTCzVZ DI1SKzBTd0Z57bg9yd0IjUWJwiqugI1YN01K5gMW3+T3iHK6bp+dyjPjfxsjKrQNCvGxYiy0HlvN T8PeEMkkKrx/qUq1sEU3z1jbbORpMqsjBKLQ6ijXz9M65ltrk0zeIM5DiKdpJMtlmkmghq2zDjUR oTZWS7KpRjOY65aIP+WJQH01ChHV45CvlnCzZa3VdMXiljhmls1RNkWdZRWMdONg6iESThZSv5hj JTXQsXdXeCeJLwmMVfjf8hkPUdNgavygrLC81FfHL1cL9jGubE9s2vMqrHITibis2jONFUUYs7dC HK5gX/mi4TOoBUiIrXkfkK2L9zlfF5J8RLNj5GhlFqGKG1WqiOsZGKaSRzwaO1aYbZk0ZSBqStq+ PcA1ehU4tyZIMtHDfjEsZrSyzVbNkyWRGofWOSCbVFsxHdC+qsCdALSv9n6rf+7e0/7tn+z9/rbl v/K3/u3+P+un/wDrv9L6pz+J7n/I4/8A9W+t/wAMv7z/AJb/AO0/8t+Hq3f4bqf87f8A/Svo/wDE t+7/AOY/+6/8z+Lr/9k= --_004_A6B8F2A767638641889989BC1BA7047936014919LIONALLOTLOCAL_-- From nobody Wed Aug 27 09:35: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 1C26D1A0B17 for ; Wed, 27 Aug 2014 09:35:15 -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 ayXkfEIiDUez for ; Wed, 27 Aug 2014 09:35:13 -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 0D3051A0B78 for ; Wed, 27 Aug 2014 09:35:13 -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 s7RG1KRH026556; Wed, 27 Aug 2014 09:35:10 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1p1a34a8h9-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Aug 2014 09:35:08 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 27 Aug 2014 09:33:08 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::90ed:fc42:a7bb:9406]) by HQ1WP-EXHUB01.corp.brocade.com ([fe80::55ee:533:4b9d:a097%12]) with mapi; Wed, 27 Aug 2014 09:33:07 -0700 From: ramki Krishnan To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Date: Wed, 27 Aug 2014 09:33:06 -0700 Thread-Topic: Call for WG adoption of draft-merged-sfc-architecture-02 Thread-Index: AQHPwSKarKFwlbPq2EakRGFWvH7bz5vkpsdw 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_C7634EB63EFD984A978DFB46EA5174F2C1512CD399HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-08-27_05:2014-08-27,2014-08-27,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-1408270184 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/h_OpaKNJ9uye_HAPKYmsIj2YaoU Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-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, 27 Aug 2014 16:35:15 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2C1512CD399HQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Thanks, Ramki From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Tuesday, August 26, 2014 4:41 AM To: sfc@ietf.org Subject: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 Greetings WG: This message begins a two week call for WG adoption of draft-merged-sfc-arc= hitecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-architecture= /] ending September 9th 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. 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_C7634EB63EFD984A978DFB46EA5174F2C1512CD399HQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.<= o:p>

 

Thanks,

Ramki

&nb= sp;

From: sfc [mailto:sfc-= bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, August 26, 2014 4:41 AM
To: sfc@ietf.org
Subjec= t: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02<= /o:p>

 

=

Greetings WG:

 

This message begins a two week call for WG adoption of dr= aft-merged-sfc-architecture-02 [http://datatracker.ietf.org/doc/draft-merge= d-sfc-architecture/] ending September 9th 2014.<= /p>

 

<= div>

Please respond to the SFC mailing list with a= ny statements of approval or disapproval.

<= p class=3DMsoNormal> 

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&= #8217;s content until there is WG consensus that the content is solid. Ther= efore, please don’t oppose adoption just because you want to see chan= ges to its content.
  2. If you have objections to adoption of the document, please state your r= easons why, and explain what it would take to address your concerns.
  3. If you have issues wit= h the content, by all means raise those issues and we can begin a dialog ab= out how best to address them.
= --_000_C7634EB63EFD984A978DFB46EA5174F2C1512CD399HQ1EXCH01corp_-- From nobody Wed Aug 27 10:17: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 B95D61A00D0 for ; Wed, 27 Aug 2014 10:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=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 GD_DWXp82PZ7 for ; Wed, 27 Aug 2014 10:17:52 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id A1A241A0061 for ; Wed, 27 Aug 2014 10:17:52 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.188.19; From: "Susan Hares" To: "'ramki Krishnan'" , "'Jim Guichard \(jguichar\)'" , References: In-Reply-To: Date: Wed, 27 Aug 2014 13:17:47 -0400 Message-ID: <008701cfc21a$d2be5160$783af420$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0088_01CFC1F9.4BAF2260" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJFhqpw5mXGm8a9/7d4z6EhoE3HPQKwQPLimuOlUMA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/xlA4r8hS9AxE4f-NLbZxLIKQeko Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-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, 27 Aug 2014 17:17:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0088_01CFC1F9.4BAF2260 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The doodle pool had last week. Are these ET or PT? Can you check your availability for 5pm PT on Thursday (8/28)? I'll send a proposed draft for Informational model. Sue From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of ramki Krishnan Sent: Wednesday, August 27, 2014 12:33 PM To: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 Support. Thanks, Ramki From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Tuesday, August 26, 2014 4:41 AM To: sfc@ietf.org Subject: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 Greetings WG: This message begins a two week call for WG adoption of draft-merged-sfc-architecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-architecture/] ending September 9th 2014. 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 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. ------=_NextPart_000_0088_01CFC1F9.4BAF2260 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The doodle pool had last week.  Are these ET or PT? =

 

Can you check your availability for 5pm PT on Thursday (8/28)? =  I’ll send a proposed draft for Informational model. =

 

Sue

 

 

From:= = sfc [mailto:sfc-bounces@ietf.org] On Behalf Of ramki = Krishnan
Sent: Wednesday, August 27, 2014 12:33 = PM
To: Jim Guichard (jguichar); = sfc@ietf.org
Subject: Re: [sfc] Call for WG adoption of = draft-merged-sfc-architecture-02

 

Support.

 

Thanks,

Ramki

 

From:= = sfc [mailto:sfc-bounces@ietf.org] = On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, = August 26, 2014 4:41 AM
To: sfc@ietf.org
Subject: [sfc] = Call for WG adoption of = draft-merged-sfc-architecture-02

 

Greetings WG:

 

This message begins a two week call for WG adoption of = draft-merged-sfc-architecture-02 [h= ttp://datatracker.ietf.org/doc/draft-merged-sfc-architecture/] e= nding September 9th 2014.

 

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 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.
------=_NextPart_000_0088_01CFC1F9.4BAF2260-- From nobody Wed Aug 27 10:19:38 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 EDB6F1A0024 for ; Wed, 27 Aug 2014 10:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=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 IMid6r6HjMmi for ; Wed, 27 Aug 2014 10:19:21 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6992A1A0ADD for ; Wed, 27 Aug 2014 10:19:21 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.188.19; From: "Susan Hares" To: References: <008701cfc21a$d2be5160$783af420$@ndzh.com> In-Reply-To: <008701cfc21a$d2be5160$783af420$@ndzh.com> Date: Wed, 27 Aug 2014 13:19:16 -0400 Message-ID: <00b001cfc21b$0812a960$1837fc20$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B1_01CFC1F9.810268F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJFhqpw5mXGm8a9/7d4z6EhoE3HPQKwQPLiAmAc4qWa0KWpAA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/O8xGYBE4JEbasUBOD1ez02DYwqc Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-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, 27 Aug 2014 17:19:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B1_01CFC1F9.810268F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Please ignore this email. I apologize for sending spam. Sue From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Susan Hares Sent: Wednesday, August 27, 2014 1:18 PM To: 'ramki Krishnan'; 'Jim Guichard (jguichar)'; sfc@ietf.org Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 The doodle pool had last week. Are these ET or PT? Can you check your availability for 5pm PT on Thursday (8/28)? I'll send a proposed draft for Informational model. Sue From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of ramki Krishnan Sent: Wednesday, August 27, 2014 12:33 PM To: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 Support. Thanks, Ramki From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Tuesday, August 26, 2014 4:41 AM To: sfc@ietf.org Subject: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 Greetings WG: This message begins a two week call for WG adoption of draft-merged-sfc-architecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-architecture/] ending September 9th 2014. 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 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. ------=_NextPart_000_00B1_01CFC1F9.810268F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please ignore this email. I apologize for sending spam. =  

 

Sue

 

From:= = sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Wednesday, August 27, 2014 1:18 PM
To: = 'ramki Krishnan'; 'Jim Guichard (jguichar)'; = sfc@ietf.org
Subject: Re: [sfc] Call for WG adoption of = draft-merged-sfc-architecture-02

 

The doodle pool had last week.  Are these ET or PT? =

 

Can you check your availability for 5pm PT on Thursday (8/28)? =  I’ll send a proposed draft for Informational model. =

 

Sue

 

 

From:= = sfc [mailto:sfc-bounces@ietf.org] = On Behalf Of ramki Krishnan
Sent: Wednesday, August 27, = 2014 12:33 PM
To: Jim Guichard (jguichar); sfc@ietf.org
Subject: Re: = [sfc] Call for WG adoption of = draft-merged-sfc-architecture-02

 

Support.

 

Thanks,

Ramki

 

From:= = sfc [mailto:sfc-bounces@ietf.org] = On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, = August 26, 2014 4:41 AM
To: sfc@ietf.org
Subject: [sfc] = Call for WG adoption of = draft-merged-sfc-architecture-02

 

Greetings WG:

 

This message begins a two week call for WG adoption of = draft-merged-sfc-architecture-02 [h= ttp://datatracker.ietf.org/doc/draft-merged-sfc-architecture/] e= nding September 9th 2014.

 

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 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.
------=_NextPart_000_00B1_01CFC1F9.810268F0-- From nobody Wed Aug 27 11:06:29 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 4E6EA1A00FA for ; Wed, 27 Aug 2014 11:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 AkFlzJ7E6xJy for ; Wed, 27 Aug 2014 11:06: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 605341A1F20 for ; Wed, 27 Aug 2014 11:06:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIU49589; Wed, 27 Aug 2014 18:06:22 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Aug 2014 19:06:21 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.137]) by SJCEML703-CHM.china.huawei.com ([169.254.5.229]) with mapi id 14.03.0158.001; Wed, 27 Aug 2014 11:06:16 -0700 From: Cathy Zhang To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: Call for WG adoption of draft-merged-sfc-architecture-02 Thread-Index: AQHPwSKarKFwlbPq2EakRGFWvH7bz5vkwL/A Date: Wed, 27 Aug 2014 18:06:16 +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: [10.212.145.75] Content-Type: multipart/alternative; boundary="_000_A2C96F6779E6A041BC7023CC207FC99418F7BB46SJCEML702CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Mfh3y6y0XkqQIkXvtzOtD7QNDiw Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-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, 27 Aug 2014 18:06:28 -0000 --_000_A2C96F6779E6A041BC7023CC207FC99418F7BB46SJCEML702CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Cathy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Tuesday, August 26, 2014 4:41 AM To: sfc@ietf.org Subject: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 Greetings WG: This message begins a two week call for WG adoption of draft-merged-sfc-arc= hitecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-architecture= /] ending September 9th 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. 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_A2C96F6779E6A041BC7023CC207FC99418F7BB46SJCEML702CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 <= /p>

Cathy

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, August 26, 2014 4:41 AM
To: sfc@ietf.org
Subject: [sfc] Call for WG adoption of draft-merged-sfc-architecture= -02

 

Greetings WG:

 

This message begins a two w= eek call for WG adoption of draft-merged-sfc-architecture-02 [http://datatr= acker.ietf.org/doc/draft-merged-sfc-architecture/] ending September 9th 2014.

 

Please respond to the SFC m= ailing 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_A2C96F6779E6A041BC7023CC207FC99418F7BB46SJCEML702CHMchi_-- From nobody Wed Aug 27 12:33: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 639AE1A017F for ; Wed, 27 Aug 2014 12:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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.668, 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 6RaW5hzTqx_r for ; Wed, 27 Aug 2014 12:33:52 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02C201A0147 for ; Wed, 27 Aug 2014 12:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21952; q=dns/txt; s=iport; t=1409168032; x=1410377632; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=p2/Eplj1ru1UbUysO5WozX0zRb/w1ZrEgickHUgmTuc=; b=EhLqGuEYsjMAUpVcirrtX0QOXL3aOHst/mLOM8m0st+yKBEQXy6hWaoR k6msX0PjlE7kTqVol3xvPfV4bsXuMJfFUdh3wkvJBW5e/CX6Z+kfKT8L8 sdlZ8Lbf3Qx9rllaHHaf7Xi2cdO0JiKZBc8nykbiBPvyPIc+eL6WA1RFG I=; X-IronPort-AV: E=Sophos; i="5.04,413,1406592000"; d="scan'208,217"; a="72925668" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-7.cisco.com with ESMTP; 27 Aug 2014 19:33:51 +0000 Received: from [10.154.165.19] ([10.154.165.19]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s7RJXnbt022801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Aug 2014 19:33:50 GMT Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_32CE2AE6-D746-4104-BD4B-731CCCCD1BAB" From: Naiming Shen In-Reply-To: <4B25B0E0-F6D5-49A6-BA1C-17B8195038CD@cisco.com> Date: Wed, 27 Aug 2014 12:33:49 -0700 Message-Id: <5645E0FB-0FF2-4EE7-96C3-A413DF18B999@cisco.com> References: <20140822165913.29275.92328.idtracker@ietfa.amsl.com> <53FB6D2E.3010202@cisco.com> <5DE5431F-8519-4E8C-8A0B-49465A4A7857@cisco.com> <4B25B0E0-F6D5-49A6-BA1C-17B8195038CD@cisco.com> To: Carlos Pignataro (cpignata) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/-aVXUtc2k23gdutcQCzkj94W7nI Cc: "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-merged-sfc-architecture-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: Wed, 27 Aug 2014 19:33:54 -0000 --Apple-Mail=_32CE2AE6-D746-4104-BD4B-731CCCCD1BAB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Carlos, On Aug 26, 2014, at 3:47 PM, Carlos Pignataro (cpignata) = wrote: > Naiming, >=20 > You are right -- this is covered in Section 4.3, under "Terminating = SFPs", we can massage the definition some more. That would be good. Although looking at the Section 4.3 the "Terminating = SFPs" paragraph, it's more about the last SFF will strip the NSH transport/header then forwarding; I'm = thinking more in the area with the last SFF can be optionally inserted just for preventing the service looping in the = network and there is no SF associated with it. thanks. - Naiming >=20 > THanks, >=20 > Carlos. >=20 > On Aug 25, 2014, at 4:47 PM, Naiming Shen wrote: >=20 >>=20 >> On Aug 25, 2014, at 1:36 PM, Naiming Shen wrote: >>=20 >>>=20 >>> Carlos, >>>=20 >>> One of the function of SFF could be to "de-encapsulate" the SFC, it = can be the case of the last >>> hop on the SFC list, there may not be any SF associated with the = SFF, but only to remove the service >>> transport and NSH header and to forward the packet normally. >>>=20 >>> Otherwise, after the last SF/SFF service function, service header = and transport is removed, >>> the packet could route through the original "classifier" device = again and it has no information >>> that packet has already gone through the SFC defined. This can cause = looping. This of course >>> depends on where the location of the last SFF in the topology. One = way to solve this can >>> be to define the SFC last item being the SFF which is the next-hop = of the classifier device in >>> normal routing/forwarding to make sure the classifier device will to = see this packet in original >>=20 >> typo, "=85 will not see this =85" >>=20 >>> format(without NSH and transport) twice. >>>=20 >>> thanks. >>> - Naiming >>>=20 >>> On Aug 25, 2014, at 12:14 PM, "Carlos Pignataro (cpignata)" = wrote: >>>=20 >>>> Reinaldo, >>>>=20 >>>> Thanks for the comment, good set of points. It does seem that the = definition itself might be unnecessarily overly restrictive. >>>>=20 >>>> We could say "zero or more" or we could say "typically one or = more", but I think it is better to spell out the function. Here's one = more comprehensive proposal: >>>>=20 >>>> Old: >>>> Service Function Forwarder (SFF): A service function forwarder = is >>>> responsible for delivering traffic received from the = network to >>>> one or more connected service functions according to = information >>>> carried in the SFC encapsulation. >>>>=20 >>>> New: >>>> Service Function Forwarder (SFF): A service function forwarder = is >>>> responsible for delivering traffic received from the = network to >>>> one or more connected service functions according to = information >>>> carried in the SFC encapsulation, as well as for delivering = traffic to >>>> a classifier or mapping out traffic to another SFF (in the = same or >>>> different type of overlay). >>>>=20 >>>> WG, Reinaldo, >>>>=20 >>>> Thoughts? >>>>=20 >>>> Thanks, >>>>=20 >>>> Carlos. >>>>=20 >>>> On Aug 25, 2014, at 1:06 PM, Reinaldo Penno = wrote: >>>>=20 >>>>> A couple of points about SFF definition. You mention "one or more = connected service functions"=20 >>>>>=20 >>>>> But in our implementation we have two types of SFFs that do not = have SFs: >>>>>=20 >>>>> - A SFF that maps from one overlay to another, say, VXLAN to GRE >>>>> - A SFF that only has a classifier (no SFs in itself) >>>>>=20 >>>>> Where would they fit or how to to make sure the architecture can = predict their usage? >>>>>=20 >>>>> thanks, >>>>>=20 >>>>> On 8/23/14 1:47 PM, Carlos Pignataro (cpignata) wrote: >>>>>> SFC, >>>>>>=20 >>>>>> Please find below the email notice of a new revision of = draft-merged-sfc-architecture. >>>>>>=20 >>>>>> Full set of diffs from -00 (IETF90) to -02 (now) can be seen = here: = http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-02&url1=3D= draft-merged-sfc-architecture-00 >>>>>>=20 >>>>>> We still expect further changes to the document; but we also = believe that this revision captures the key points and addresses the key = open items, as planned in Toronto. >>>>>>=20 >>>>>> The key objective being to create a single document basis for the = SFC architecture. >>>>>>=20 >>>>>> SFC Chairs, >>>>>>=20 >>>>>> We believe that this revision fulfills the next steps agreed in = Toronto (http://tools.ietf.org/agenda/90/slides/slides-90-sfc-3.pdf).=20 >>>>>>=20 >>>>>> This revision, while we expect changes, is now close enough that = we think it makes sense for the WG to take it as the basis for the WG = document to address the deliverable. >>>>>>=20 >>>>>> draft-merged-sfc-architecture-02 addressed the key points -- and = we believe is ready to start a poll for adoption. Can you please = initiate that WG adoption call for draft-merged-sfc-architecture-02? >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> Carlos & Joel. >>>>>>=20 >>>>>>=20 >>>>>> Begin forwarded message: >>>>>>=20 >>>>>>> From: >>>>>>> Subject: New Version Notification for = draft-merged-sfc-architecture-02.txt >>>>>>> Date: August 22, 2014 at 12:59:13 PM EDT >>>>>>> To: Joel Halpern , Carlos Pignataro = , "Joel M. Halpern" , Carlos = Pignataro >>>>>>>=20 >>>>>>>=20 >>>>>>> A new version of I-D, draft-merged-sfc-architecture-02.txt >>>>>>> has been successfully submitted by Carlos Pignataro and posted = to the >>>>>>> IETF repository. >>>>>>>=20 >>>>>>> Name: draft-merged-sfc-architecture >>>>>>> Revision: 02 >>>>>>> Title: Service Function Chaining (SFC) Architecture >>>>>>> Document date: 2014-08-22 >>>>>>> Group: Individual Submission >>>>>>> Pages: 26 >>>>>>> URL: = http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-02.txt >>>>>>> Status: = https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ >>>>>>> Htmlized: = http://tools.ietf.org/html/draft-merged-sfc-architecture-02 >>>>>>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-02 >>>>>>>=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 submission >>>>>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>>>>=20 >>>>>>> The IETF Secretariat >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=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 >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>=20 >>=20 >=20 --Apple-Mail=_32CE2AE6-D746-4104-BD4B-731CCCCD1BAB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 cpignata@cisco.com> = wrote:

Naiming,

You are right -- this is covered in Section 4.3, under "Terminating = SFPs", we can massage the definition some = more.

That would be good. = Although looking at the Section 4.3 the "Terminating SFPs" paragraph, = it's more about the
last SFF will strip the NSH = transport/header then forwarding; I'm thinking more in the area with the = last SFF can be
optionally inserted just for preventing the = service looping in the network and there is no SF associated with = it.

thanks.
- = Naiming


THanks,

Carlos.

On Aug 25, 2014, at 4:47 PM, Naiming Shen <naiming@cisco.com> wrote:


On Aug 25, 2014, at 1:36 PM, Naiming Shen <naiming@cisco.com> wrote:


Carlos,

One of the function of SFF could be to "de-encapsulate" the SFC, it = can be the case of the last
hop on the SFC list, there may not be any SF associated with the = SFF, but only to remove the service
transport and NSH header and to forward the packet normally.

Otherwise, after the last SF/SFF service function, service header = and transport is removed,
the packet could route through the original "classifier" device = again and it has no information
that packet has already gone through the SFC defined. This can = cause looping. This of course
depends on where the location of the last SFF in the topology. One = way to solve this can
be to define the SFC last item being the SFF which is the next-hop = of the classifier device in
normal routing/forwarding to make sure the classifier device will = to see this packet in original

typo, "=85 will not see this =85"

format(without NSH and transport) twice.

thanks.
- Naiming

On Aug 25, 2014, at 12:14 PM, "Carlos Pignataro (cpignata)" <cpignata@cisco.com> = wrote:

Reinaldo,

Thanks for the comment, good set of points. It does seem that the = definition itself might be unnecessarily overly restrictive.

We could say "zero or more" or we could say "typically one or = more", but I think it is better to spell out the function. Here's one = more comprehensive proposal:

Old:
   Service Function Forwarder (SFF):  A service = function forwarder is
        responsible for delivering traffic = received from the network to
        one or more connected service functions = according to information
        carried in the SFC encapsulation.

New:
   Service Function Forwarder (SFF):  A service = function forwarder is
        responsible for delivering traffic = received from the network to
        one or more connected service functions = according to information
        carried in the SFC encapsulation, as = well as for delivering traffic to
        a classifier or mapping out traffic to = another SFF (in the same or
        different type of overlay).

WG, Reinaldo,

Thoughts?

Thanks,

Carlos.

On Aug 25, 2014, at 1:06 PM, Reinaldo Penno <repenno@cisco.com> wrote:

A couple of points about SFF = definition. You mention "one or more connected service functions"

But in our implementation we have two types of SFFs that do not have = SFs:

- A SFF that maps from one overlay to another, say, VXLAN to GRE
- A SFF that only has a classifier (no SFs in itself)

Where would they fit or how to to make sure the architecture can predict = their usage?

thanks,

On 8/23/14 1:47 PM, Carlos Pignataro = (cpignata) wrote:
SFC,

Please find below the email notice of a new revision = of draft-merged-sfc-architecture.


We still expect further changes to the document; but we also = believe that this revision captures the key points and addresses the key = open items, as planned in Toronto.

The key objective being to create a single document basis for the = SFC architecture.

SFC Chairs,

We believe that this revision fulfills the next steps agreed in = Toronto (http:/= /tools.ietf.org/agenda/90/slides/slides-90-sfc-3.pdf). 

This revision, while we expect changes, is now close enough = that we think it makes sense for the WG to take it as the basis for the = WG document to address the deliverable.

draft-merged-sfc-architecture-02 addressed the key points -- and we = believe is ready to start a poll for adoption. Can you please initiate = that WG adoption call for draft-merged-sfc-architecture-02?

Thanks,

Carlos & Joel.


Begin forwarded message:

From: <internet-drafts@ietf.org><= br>
Subject: New Version Notification for = draft-merged-sfc-architecture-02.txt
Date: August 22, 2014 at 12:59:13 PM = EDT
To: Joel Halpern <jmh@joelhalpern.com>, Carlos = Pignataro <cpignata@cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Carlos = Pignataro <cpignata@cisco.com>


A new version of I-D, draft-merged-sfc-architecture-02.txt
has been successfully submitted by Carlos Pignataro and posted to = the
IETF repository.

Name: = draft-merged-sfc-architecture
Revision: = 02
Title: = Service Function Chaining (SFC) = Architecture
Document date: = 2014-08-22
Group: = Individual Submission
Pages: = 26
URL: =            http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-= 02.txt
Status:         h= ttps://datatracker.ietf.org/doc/draft-merged-sfc-architecture/
Htmlized:       http:= //tools.ietf.org/html/draft-merged-sfc-architecture-02
Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-merged-sfc-architecture-02=

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.ietf.org.

The IETF Secretariat




_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/sfc

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/ma= ilman/listinfo/sfc

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/ma= ilman/listinfo/sfc




= --Apple-Mail=_32CE2AE6-D746-4104-BD4B-731CCCCD1BAB-- From nobody Wed Aug 27 12:51: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 57A381A01A8 for ; Wed, 27 Aug 2014 12:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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.668, 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 nxq6CsFws56h for ; Wed, 27 Aug 2014 12:50:51 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91AA91A014E for ; Wed, 27 Aug 2014 12:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3794; q=dns/txt; s=iport; t=1409169051; x=1410378651; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=1y5K1B5L6IjL4ydHSX2nx5L9dC7PMNpuqefQhuryifo=; b=VKOheyb7LQ99N0hOxGaGJGtkGB1vGI56E66OEL3xAqZcxDdaKAm5k6d3 KDdw2dg1qHmfwKKZxpHvBs6q+h39hpaHwqw33uHPdaZ5FJ3j339v2Zppm sqK9b4x9uCOEe6Nbz4ozezh9ZeP7kIoej6j/eb68TWdrJBj5LywozhPb5 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAJM1/lOtJA2B/2dsb2JhbABbgkdGU1cEshyYI4FbAQmHTwGBEhZ3hAQBAQQBAQEaURsCAQgEDi0HJwsUAw4CBBOIQg2/SxePU4MvgR0FjxuCFIQthnyBW5M/g15sgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,413,1406592000"; d="scan'208,217";a="350771203" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-5.cisco.com with ESMTP; 27 Aug 2014 19:50:50 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s7RJonwT003816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 27 Aug 2014 19:50:49 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.10]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Wed, 27 Aug 2014 14:50:49 -0500 From: "Guy Meador III (meadorg)" To: "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 Thread-Index: AQHPwjAzrKFwlbPq2EakRGFWvH7bzw== Date: Wed, 27 Aug 2014 19:50:49 +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: [10.117.94.199] Content-Type: multipart/alternative; boundary="_000_A4D52CE0956D418BBBADBBAF92805605ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Okvs0Y2ecS0_zVetP59Xq0ADB8E Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-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, 27 Aug 2014 19:50:55 -0000 --_000_A4D52CE0956D418BBBADBBAF92805605ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Support. On Aug 26, 2014, at 7:40 AM, Jim Guichard (jguichar) > wrote: Greetings WG: This message begins a two week call for WG adoption of draft-merged-sfc-arc= hitecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-architecture= /] ending September 9th 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. 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_A4D52CE0956D418BBBADBBAF92805605ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5F09ABC505CADF478E8086A11643F966@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Support.

On Aug 26, 2014, at 7:40 AM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:

Greetings WG:

This message begins a two week call for WG adoption of draft-merged-sf= c-architecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-archite= cture/] ending September 9th 2014.

Please respond to the SFC mailing list with any statements of approval= or disapproval.

As always, please note:
  1. This is not WG Last C= all. The document is not final, and the WG is expected to modify the docume= nt=92s content until there is WG consensus that the content is solid. There= fore, 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 conten= t, 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_A4D52CE0956D418BBBADBBAF92805605ciscocom_-- From nobody Wed Aug 27 14:23:02 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 357EA1A02A6 for ; Wed, 27 Aug 2014 14:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.568 X-Spam-Level: X-Spam-Status: No, score=-7.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 zlfPmtLMEBph for ; Wed, 27 Aug 2014 14:22:54 -0700 (PDT) Received: from mxe01.gs.com (mxe01.gs.com [204.4.178.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C26591A0141 for ; Wed, 27 Aug 2014 14:22:53 -0700 (PDT) Received: from pps.filterd (gsppacdp01sd.idz.gs.com [127.0.0.1]) by gsppacdp01sd.idz.gs.com (8.14.5/8.14.5) with SMTP id s7RLL6Cs015059 for ; Wed, 27 Aug 2014 17:22:52 -0400 Received: from mxpcd02-public.ny.fw.gs.com ([148.86.97.79]) by gsppacdp01sd.idz.gs.com with ESMTP id 1p1kk0tr8t-1 for ; Wed, 27 Aug 2014 17:22:52 -0400 From: "Zarny, Myo" X-sendergroup: RELAYLIST Received: from gshccdp15ex.firmwide.corp.gs.com ([10.135.172.93]) by cd02-mxp-vip-prod.ny.fw.gs.com with ESMTP; 27 Aug 2014 17:22:52 -0400 Received: from GSCMAMP19EX.firmwide.corp.gs.com ([139.172.38.36]) by gshccdp15ex.firmwide.corp.gs.com ([10.135.172.93]) with mapi; Wed, 27 Aug 2014 17:22:52 -0400 To: "'Jim Guichard (jguichar)'" , "'sfc@ietf.org'" Date: Wed, 27 Aug 2014 17:22:51 -0400 Thread-Topic: Call for WG adoption of draft-merged-sfc-architecture-02 Thread-Index: AQHPwSKarKFwlbPq2EakRGFWvH7bz5vk96SQ 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 x-retentionstamp: Firmwide Content-Type: multipart/alternative; boundary="_000_A3233753A4B65F43BCA1B64DA99A9C23070DD0CDF9GSCMAMP19EXfi_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-08-27_06:2014-08-27,2014-08-27,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/T0gJByTif_kzLFDTUgM96eQuCz8 Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-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, 27 Aug 2014 21:23:01 -0000 --_000_A3233753A4B65F43BCA1B64DA99A9C23070DD0CDF9GSCMAMP19EXfi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: 26 August 2014 7:41 AM To: sfc@ietf.org Subject: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 Greetings WG: This message begins a two week call for WG adoption of draft-merged-sfc-arc= hitecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-architecture= /] ending September 9th 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. 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'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 y= our 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 issu= es and we can begin a dialog about how best to address them. --_000_A3233753A4B65F43BCA1B64DA99A9C23070DD0CDF9GSCMAMP19EXfi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support

 

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: 26 August 2014 7:41 AM
To: sfc@ietf.org
Subject:= [sfc] Call for WG adoption of draft-merged-sfc-architecture-02

<= o:p> 

Greetings WG:

 

This message begins a two = week call for WG adoption of draft-merged-sfc-architecture-02 [http://datat= racker.ietf.org/doc/draft-merged-sfc-architecture/] ending Septemb= er 9th 2014.

 

Please respond to the SFC mailing l= ist with any statements of approval or disapproval.

 

<= span style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif";color:bla= ck'>As always, please note:

<= span style=3D'mso-list:Ignore'>1.This is not WG Last Call. The document is not final, and the WG is expecte= d to modify the document’s content until there is WG consensus that t= he content is solid. Therefore, please don’t oppose adoption just bec= ause 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.    &nbs= p;  If you have issues with the co= ntent, by all means raise those issues and we can begin a dialog about how = best to address them.

= --_000_A3233753A4B65F43BCA1B64DA99A9C23070DD0CDF9GSCMAMP19EXfi_-- From nobody Wed Aug 27 16:14: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 CEF661A028E for ; Wed, 27 Aug 2014 16:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 8y_pKN4_NjXU for ; Wed, 27 Aug 2014 16:14:55 -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 F2E1C1A011B for ; Wed, 27 Aug 2014 16:14:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLV75856; Wed, 27 Aug 2014 23:14:53 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 28 Aug 2014 00:14:52 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Wed, 27 Aug 2014 16:14:45 -0700 From: Linda Dunbar To: Xuxiaohu , "Andrew G. Malis" , "Jim Guichard (jguichar)" Thread-Topic: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 Thread-Index: AQHPwSKarKFwlbPq2EakRGFWvH7bz5vjk4KAgACZw4CAAOnC8A== Date: Wed, 27 Aug 2014 23:14:44 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645DDAFC7@dfweml701-chm> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082AB308@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082AB308@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.151.193] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645DDAFC7dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ng4R-95j8Ai_n9CI81-7osAtdaQ Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-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, 27 Aug 2014 23:14:58 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645DDAFC7dfweml701chm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCB0aGUgYWRvcHRpb24gYW5kIGFncmVlIHdpdGggQW5keeKAmXMgcG9pbnQuDQoNCkxp bmRhDQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgQW5kcmV3IEcuIE1hbGlzDQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAyNywgMjAxNCAxOjA3 IEFNDQpUbzogSmltIEd1aWNoYXJkIChqZ3VpY2hhcikNCkNjOiBzZmNAaWV0Zi5vcmc8bWFpbHRv OnNmY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2ZjXSBDYWxsIGZvciBXRyBhZG9wdGlvbiBv ZiBkcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZS0wMg0KDQpKaW0sDQoNCkkgc3VwcG9ydCB0 aGUgYWRvcHRpb24gb2YgdGhpcyBkcmFmdCBieSB0aGUgV0cuDQoNCkR1cmluZyB0aGUgZGlzY3Vz c2lvbiBvZiByZXZpc2lvbiAtMDEsIGFsdGhvdWdoIGEgbnVtYmVyIG9mIFdHIHBhcnRpY2lwYW50 cyByZXF1ZXN0ZWQgYSBtb3JlIGZsZXhpYmxlIHdvcmRpbmcgb2YgdGhlIFNGQyBlbmNhcHN1bGF0 aW9uIGRlZmluaXRpb24sIGl0IHdhcyB1bmNoYW5nZWQgZnJvbSAtMDEgdG8gLTAyLiBUaGlzIGlz IHdpdGhpbiB0aGUgcmlnaHRzIG9mIGluZGl2aWR1YWwgYXV0aG9ycywgb2YgY291cnNlLiBIb3dl dmVyLCBvbmNlIHRoaXMgYmVjb21lcyBhIFdHIGRyYWZ0LCBJIGhvcGUgd2UgY2FuIHJldmlzaXQg dGhhdCBkaXNjdXNzaW9uLg0KDQpUaGFua3MsDQpBbmR5DQoNCg0KT24gVHVlLCBBdWcgMjYsIDIw MTQgYXQgNzo0MCBBTSwgSmltIEd1aWNoYXJkIChqZ3VpY2hhcikgPGpndWljaGFyQGNpc2NvLmNv bTxtYWlsdG86amd1aWNoYXJAY2lzY28uY29tPj4gd3JvdGU6DQpHcmVldGluZ3MgV0c6DQoNClRo aXMgbWVzc2FnZSBiZWdpbnMgYSB0d28gd2VlayBjYWxsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFm dC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZS0wMiBbaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZS9dIGVuZGluZyBTZXB0ZW1iZXIgOXRo IDIwMTQuDQoNClBsZWFzZSByZXNwb25kIHRvIHRoZSBTRkMgbWFpbGluZyBsaXN0IHdpdGggYW55 IHN0YXRlbWVudHMgb2YgYXBwcm92YWwgb3IgZGlzYXBwcm92YWwuDQoNCkFzIGFsd2F5cywgcGxl YXNlIG5vdGU6DQoNCiAgMS4gIFRoaXMgaXMgbm90IFdHIExhc3QgQ2FsbC4gVGhlIGRvY3VtZW50 IGlzIG5vdCBmaW5hbCwgYW5kIHRoZSBXRyBpcyBleHBlY3RlZCB0byBtb2RpZnkgdGhlIGRvY3Vt ZW504oCZcyBjb250ZW50IHVudGlsIHRoZXJlIGlzIFdHIGNvbnNlbnN1cyB0aGF0IHRoZSBjb250 ZW50IGlzIHNvbGlkLiBUaGVyZWZvcmUsIHBsZWFzZSBkb27igJl0IG9wcG9zZSBhZG9wdGlvbiBq dXN0IGJlY2F1c2UgeW91IHdhbnQgdG8gc2VlIGNoYW5nZXMgdG8gaXRzIGNvbnRlbnQuDQogIDIu ICBJZiB5b3UgaGF2ZSBvYmplY3Rpb25zIHRvIGFkb3B0aW9uIG9mIHRoZSBkb2N1bWVudCwgcGxl YXNlIHN0YXRlIHlvdXIgcmVhc29ucyB3aHksIGFuZCBleHBsYWluIHdoYXQgaXQgd291bGQgdGFr ZSB0byBhZGRyZXNzIHlvdXIgY29uY2VybnMuDQogIDMuICBJZiB5b3UgaGF2ZSBpc3N1ZXMgd2l0 aCB0aGUgY29udGVudCwgYnkgYWxsIG1lYW5zIHJhaXNlIHRob3NlIGlzc3VlcyBhbmQgd2UgY2Fu IGJlZ2luIGEgZGlhbG9nIGFib3V0IGhvdyBiZXN0IHRvIGFkZHJlc3MgdGhlbS4NCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxp c3QNCnNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0K --_000_4A95BA014132FF49AE685FAB4B9F17F645DDAFC7dfweml701chm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OuWui+S9kzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1z b0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWls U3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMjVp biAxLjBpbiAxLjI1aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDozMTA1MjM4 NDQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEwMTAzNDEyNzY7fQ0KQGxpc3QgbDA6bGV2ZWwx DQoJe21zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZl bC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVs Ng0KCXttc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxl dmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC10YWItc3Rv cDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA bGlzdCBsMQ0KCXttc28tbGlzdC1pZDo1MTc4MTQ0NTU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz Oi0zOTY3MjE1NjY7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TdXBwb3J0 IHRoZSBhZG9wdGlvbiBhbmQgYWdyZWUgd2l0aCBBbmR54oCZcyBwb2ludC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE2 LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxp bmRhPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IHNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWls dG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbmRyZXcg Ry4gTWFsaXM8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBdWd1c3QgMjcsIDIwMTQgMTow NyBBTTxicj4NCjxiPlRvOjwvYj4gSmltIEd1aWNoYXJkIChqZ3VpY2hhcik8YnI+DQo8Yj5DYzo8 L2I+IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtzZmNdIENhbGwgZm9yIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LW1l cmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5KaW0sPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQgYnkgdGhlIFdHLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EdXJp bmcgdGhlIGRpc2N1c3Npb24gb2YgcmV2aXNpb24gLTAxLCBhbHRob3VnaCBhIG51bWJlciBvZiBX RyBwYXJ0aWNpcGFudHMgcmVxdWVzdGVkIGEgbW9yZSBmbGV4aWJsZSB3b3JkaW5nIG9mIHRoZSBT RkMgZW5jYXBzdWxhdGlvbiBkZWZpbml0aW9uLCBpdCB3YXMgdW5jaGFuZ2VkIGZyb20gLTAxIHRv IC0wMi4gVGhpcyBpcyB3aXRoaW4gdGhlIHJpZ2h0cyBvZiBpbmRpdmlkdWFsIGF1dGhvcnMsIG9m IGNvdXJzZS4NCiBIb3dldmVyLCBvbmNlIHRoaXMgYmVjb21lcyBhIFdHIGRyYWZ0LCBJIGhvcGUg d2UgY2FuIHJldmlzaXQgdGhhdCBkaXNjdXNzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBUdWUsIEF1ZyAyNiwgMjAxNCBhdCA3OjQwIEFNLCBKaW0gR3VpY2hhcmQgKGpn dWljaGFyKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmpndWljaGFyQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPkdyZWV0aW5ncyBXRzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPlRoaXMgbWVzc2FnZSBiZWdpbnMgYSB0d28gd2VlayBjYWxsIGZv ciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZS0wMiBbPGEgaHJl Zj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tZXJnZWQtc2ZjLWFyY2hp dGVjdHVyZS8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLzwvYT5dJm5ic3A7ZW5kaW5nDQogU2VwdGVt YmVyIDl0aCAyMDE0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5QbGVhc2Ug cmVzcG9uZCB0byB0aGUgU0ZDIG1haWxpbmcgbGlzdCB3aXRoIGFueSBzdGF0ZW1lbnRzIG9mIGFw cHJvdmFsIG9yIGRpc2FwcHJvdmFsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5BcyBhbHdheXMsIHBsZWFzZSBub3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29s b3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5UaGlzIGlzIG5vdCBXRyBMYXN0IENhbGwuIFRoZSBkb2N1bWVudCBpcyBub3QgZmluYWwsIGFu ZCB0aGUgV0cgaXMgZXhwZWN0ZWQgdG8gbW9kaWZ5IHRoZSBkb2N1bWVudOKAmXMgY29udGVudCB1 bnRpbCB0aGVyZSBpcyBXRyBjb25zZW5zdXMgdGhhdCB0aGUgY29udGVudCBpcyBzb2xpZC4gVGhl cmVmb3JlLCBwbGVhc2UgZG9u4oCZdCBvcHBvc2UNCiBhZG9wdGlvbiBqdXN0IGJlY2F1c2UgeW91 IHdhbnQgdG8gc2VlIGNoYW5nZXMgdG8gaXRzIGNvbnRlbnQuPG86cD48L286cD48L3NwYW4+PC9s aT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBs Zm8zIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91IGhhdmUgb2JqZWN0aW9u cyB0byBhZG9wdGlvbiBvZiB0aGUgZG9jdW1lbnQsIHBsZWFzZSBzdGF0ZSB5b3VyIHJlYXNvbnMg d2h5LCBhbmQgZXhwbGFpbiB3aGF0IGl0IHdvdWxkIHRha2UgdG8gYWRkcmVzcyB5b3VyIGNvbmNl cm5zLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJj b2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPklmIHlvdSBoYXZlIGlzc3VlcyB3aXRoIHRoZSBjb250ZW50LCBieSBhbGwgbWVhbnMgcmFp c2UgdGhvc2UgaXNzdWVzIGFuZCB3ZSBjYW4gYmVnaW4gYSBkaWFsb2cgYWJvdXQgaG93IGJlc3Qg dG8gYWRkcmVzcyB0aGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC9vbD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K c2ZjIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0Bp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_4A95BA014132FF49AE685FAB4B9F17F645DDAFC7dfweml701chm_-- From nobody Wed Aug 27 16:36: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 5BFEC1A02BB for ; Wed, 27 Aug 2014 16:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 Wv4IAO7H3h9a for ; Wed, 27 Aug 2014 16:36:05 -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 D88BA1A02A3 for ; Wed, 27 Aug 2014 16:36:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLV76736; Wed, 27 Aug 2014 23:36:03 +0000 (GMT) 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, 28 Aug 2014 00:36:02 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml703-chm.china.huawei.com ([169.254.5.198]) with mapi id 14.03.0158.001; Wed, 27 Aug 2014 16:35:52 -0700 From: Linda Dunbar To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Proposed SFC Architecture - SFC Proxy Thread-Index: AQHPt+TQGNF8Tnpu+0eNJbFzo+jn8ZvlLu4w Date: Wed, 27 Aug 2014 23:35:52 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645DDB054@dfweml701-chm> References: <53ECEDFE.8080007@joelhalpern.com> In-Reply-To: <53ECEDFE.8080007@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.151.193] 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/6YJCgUFQe0OSPvbG2OdgI9qqB10 Subject: Re: [sfc] Proposed SFC Architecture - SFC Proxy 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, 27 Aug 2014 23:36:07 -0000 Joel,=20 Agree with your description of SFC Proxy.=20 Does the term "we" in your sentence below means this architecture draft? Or= SFC as a whole?=20 " Just as we do not specify the delivery mechanism between the SFF and the= SF, we will not specify the delivery mechanism between the SFF and the SFC= Proxy or between the SFC Proxy and the SF." Linda=20 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Thursday, August 14, 2014 12:13 PM To: sfc@ietf.org Subject: [sfc] Proposed SFC Architecture - SFC Proxy In the recent discussion on the SFC Proxy, Carlos and I understood that the= current text is unclear. We need to fix it. It turned out that even he and I had different perspectives on what it mean= t. He has persuaded me that the cleanest approach is not the one I suggest= ed earlier on the list. So I am writing a bit of text to fix the proxy description (and then we wil= l fix any other dangling references.) Since the group is considering adopt= ion of the document, we wanted to make sure that the proposal is one other = folks can live with. The approach is to treat the SFC Proxy as a logical element between the SFF= and the SF. When the SFF wants to send a packet to an SF which requires p= roxy support, the packet goes instead to the proxy. The proxy does what is= necessary, works with the SF however it needs to, and when the packet come= s back puts things back together and hands them back to the SFF. Just as we do not specify the delivery mechanism between the SFF and the SF= , we will not specify the delivery mechanism between the SFF and the SFC Pr= oxy or between the SFC Proxy and the SF. I hope this is understandable and acceptable to folks. Thank you, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Aug 27 17:17: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 18CCB1A0314 for ; Wed, 27 Aug 2014 17:17: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 hmkiQo1mfSs4 for ; Wed, 27 Aug 2014 17:17:03 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AB3C1A0305 for ; Wed, 27 Aug 2014 17:17:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id E43821BC3F0B; Wed, 27 Aug 2014 17:17:02 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [12.177.115.196]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 923CB1BC3F08; Wed, 27 Aug 2014 17:17:02 -0700 (PDT) Message-ID: <53FE74FF.5020408@joelhalpern.com> Date: Wed, 27 Aug 2014 20:17:03 -0400 From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Linda Dunbar , "sfc@ietf.org" References: <53ECEDFE.8080007@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645DDB054@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645DDB054@dfweml701-chm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/cU5S1-fIyA94H6ofO2Jdb9ClO4Y Subject: Re: [sfc] Proposed SFC Architecture - SFC Proxy 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, 28 Aug 2014 00:17:05 -0000 "We" means "this document", and I should probably have written it that way. While I have opinions on what the work group can add value by doing later, it is not the job of this document to be prescriptive around that. Yours, Joel On 8/27/14, 7:35 PM, Linda Dunbar wrote: > Joel, > > Agree with your description of SFC Proxy. > > Does the term "we" in your sentence below means this architecture draft? Or SFC as a whole? > > " Just as we do not specify the delivery mechanism between the SFF and the SF, we will not specify the delivery mechanism between the SFF and the SFC Proxy or between the SFC Proxy and the SF." > > > Linda > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Thursday, August 14, 2014 12:13 PM > To: sfc@ietf.org > Subject: [sfc] Proposed SFC Architecture - SFC Proxy > > In the recent discussion on the SFC Proxy, Carlos and I understood that the current text is unclear. We need to fix it. > > It turned out that even he and I had different perspectives on what it meant. He has persuaded me that the cleanest approach is not the one I suggested earlier on the list. > So I am writing a bit of text to fix the proxy description (and then we will fix any other dangling references.) Since the group is considering adoption of the document, we wanted to make sure that the proposal is one other folks can live with. > > The approach is to treat the SFC Proxy as a logical element between the SFF and the SF. When the SFF wants to send a packet to an SF which requires proxy support, the packet goes instead to the proxy. The proxy does what is necessary, works with the SF however it needs to, and when the packet comes back puts things back together and hands them back to the SFF. > > Just as we do not specify the delivery mechanism between the SFF and the SF, we will not specify the delivery mechanism between the SFF and the SFC Proxy or between the SFC Proxy and the SF. > > I hope this is understandable and acceptable to folks. > Thank you, > Joel > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Wed Aug 27 17:49: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 390031A036B for ; Wed, 27 Aug 2014 17:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgfazuLKCSxu for ; Wed, 27 Aug 2014 17:49:38 -0700 (PDT) Received: from smtp89.iad3a.emailsrvr.com (smtp89.iad3a.emailsrvr.com [173.203.187.89]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80AFC1A02BC for ; Wed, 27 Aug 2014 17:49:38 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp20.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 7BCDC180252; Wed, 27 Aug 2014 20:49:37 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp20.relay.iad3a.emailsrvr.com (Authenticated sender: bgreene-AT-senki.org) with ESMTPSA id BF510180257; Wed, 27 Aug 2014 20:49:35 -0400 (EDT) X-Sender-Id: bgreene@senki.org Received: from [10.0.1.14] ([UNAVAILABLE]. [139.228.10.11]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:587 (trex/5.2.10); Thu, 28 Aug 2014 00:49:37 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_31F0100E-A1FA-4FA7-A261-FA1C80E8AEE6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Barry Greene In-Reply-To: Date: Thu, 28 Aug 2014 07:49:23 +0700 Message-Id: <8F451428-8508-40B9-B610-541556B3BAA7@senki.org> References: To: Jim Guichard X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/sboNFGDJOMfyUTjr-c0ECgX3QUE Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-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, 28 Aug 2014 00:49:40 -0000 --Apple-Mail=_31F0100E-A1FA-4FA7-A261-FA1C80E8AEE6 Content-Type: multipart/alternative; boundary="Apple-Mail=_2F5424EE-719D-44A5-A416-40174591A1DD" --Apple-Mail=_2F5424EE-719D-44A5-A416-40174591A1DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 +1 Support On Aug 26, 2014, at 6:40 PM, Jim Guichard (jguichar) = wrote: > Greetings WG: >=20 > This message begins a two week call for WG adoption of = draft-merged-sfc-architecture-02 = [http://datatracker.ietf.org/doc/draft-merged-sfc-architecture/] ending = September 9th 2014. >=20 > Please respond to the SFC mailing list with any statements of approval = or disapproval. >=20 > 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. > If you have objections to adoption of the document, please state your = reasons why, and explain what it would take to address your concerns. > 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 --Apple-Mail=_2F5424EE-719D-44A5-A416-40174591A1DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

+1 Support

On = Aug 26, 2014, at 6:40 PM, Jim Guichard (jguichar) <jguichar@cisco.com> = wrote:

Greetings WG:

This message begins a two week call for WG adoption of = draft-merged-sfc-architecture-02 [ht= tp://datatracker.ietf.org/doc/draft-merged-sfc-architecture/] end= ing September 9th 2014.

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 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.
  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/mail= man/listinfo/sfc

= --Apple-Mail=_2F5424EE-719D-44A5-A416-40174591A1DD-- --Apple-Mail=_31F0100E-A1FA-4FA7-A261-FA1C80E8AEE6 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 iQEcBAEBCgAGBQJT/nyaAAoJEFVuk3AWv0XznVsIAJUGHtA64FozDqeS90zFKBSs q6cTpSW8B2o/yFGLGwJi0ujuzQEWeDrdss01iqjfCCs/HGAYwVJU93tLmGx1IHpT nG5dfohzeu2J5qU5pIMoqXoXLt3MVAxd3wYncdVeSUvfN2AxytF7LcKl4pQ0Wojl u11PW7buWqcO8/gT0Fx/Sf1DqIK5wM83ZXFkXS5Qr9bO41koSqggISthhQa0k9UD vdmrKL5gl3L3Z8PJ3f88dDqPO9grDHIYBg2Ri4y7mckK+qf0WUj8ea9snLUqg2jY b+jZnjkiGG7K5LyrZ8q+Xm7itePABliN2HU/77nA/d16w3mXDrBs2oxp78wBX4o= =DY1T -----END PGP SIGNATURE----- --Apple-Mail=_31F0100E-A1FA-4FA7-A261-FA1C80E8AEE6-- From nobody Sat Aug 30 00:29: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 E2F061A885D for ; Sat, 30 Aug 2014 00:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 Ii_f3shytlt1 for ; Sat, 30 Aug 2014 00:29: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 96C321A885C for ; Sat, 30 Aug 2014 00:29:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIW70813; Sat, 30 Aug 2014 07:29:32 +0000 (GMT) Received: from SZXEMA404-HUB.china.huawei.com (10.82.72.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 30 Aug 2014 08:29:31 +0100 Received: from SZXEMA509-MBX.china.huawei.com ([169.254.1.59]) by SZXEMA404-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0158.001; Sat, 30 Aug 2014 15:29:24 +0800 From: "Hongyu Li (Julio)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: Call for WG adoption of draft-merged-sfc-architecture-02 Thread-Index: AQHPwSKarKFwlbPq2EakRGFWvH7bz5voxe5g Date: Sat, 30 Aug 2014 07:29:24 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97EA5AF68@SZXEMA509-MBX.china.huawei.com> 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.66.114.234] Content-Type: multipart/alternative; boundary="_000_6EB34CB5D82C4645B826C56144826EA97EA5AF68SZXEMA509MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/XD0RvQ897Gdjca18Yr7aSQeLFbA Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-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: Sat, 30 Aug 2014 07:29:36 -0000 --_000_6EB34CB5D82C4645B826C56144826EA97EA5AF68SZXEMA509MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydA0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEppbSBHdWljaGFyZCAoamd1aWNoYXIpDQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMjYs IDIwMTQgNzo0MSBQTQ0KVG86IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogW3NmY10gQ2FsbCBmb3Ig V0cgYWRvcHRpb24gb2YgZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUtMDINCg0KR3JlZXRp bmdzIFdHOg0KDQpUaGlzIG1lc3NhZ2UgYmVnaW5zIGEgdHdvIHdlZWsgY2FsbCBmb3IgV0cgYWRv cHRpb24gb2YgZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUtMDIgW2h0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUvXSBlbmRpbmcg U2VwdGVtYmVyIDl0aCAyMDE0Lg0KDQpQbGVhc2UgcmVzcG9uZCB0byB0aGUgU0ZDIG1haWxpbmcg bGlzdCB3aXRoIGFueSBzdGF0ZW1lbnRzIG9mIGFwcHJvdmFsIG9yIGRpc2FwcHJvdmFsLg0KDQpB cyBhbHdheXMsIHBsZWFzZSBub3RlOg0KDQogIDEuICBUaGlzIGlzIG5vdCBXRyBMYXN0IENhbGwu IFRoZSBkb2N1bWVudCBpcyBub3QgZmluYWwsIGFuZCB0aGUgV0cgaXMgZXhwZWN0ZWQgdG8gbW9k aWZ5IHRoZSBkb2N1bWVudOKAmXMgY29udGVudCB1bnRpbCB0aGVyZSBpcyBXRyBjb25zZW5zdXMg dGhhdCB0aGUgY29udGVudCBpcyBzb2xpZC4gVGhlcmVmb3JlLCBwbGVhc2UgZG9u4oCZdCBvcHBv c2UgYWRvcHRpb24ganVzdCBiZWNhdXNlIHlvdSB3YW50IHRvIHNlZSBjaGFuZ2VzIHRvIGl0cyBj b250ZW50Lg0KICAyLiAgSWYgeW91IGhhdmUgb2JqZWN0aW9ucyB0byBhZG9wdGlvbiBvZiB0aGUg ZG9jdW1lbnQsIHBsZWFzZSBzdGF0ZSB5b3VyIHJlYXNvbnMgd2h5LCBhbmQgZXhwbGFpbiB3aGF0 IGl0IHdvdWxkIHRha2UgdG8gYWRkcmVzcyB5b3VyIGNvbmNlcm5zLg0KICAzLiAgSWYgeW91IGhh dmUgaXNzdWVzIHdpdGggdGhlIGNvbnRlbnQsIGJ5IGFsbCBtZWFucyByYWlzZSB0aG9zZSBpc3N1 ZXMgYW5kIHdlIGNhbiBiZWdpbiBhIGRpYWxvZyBhYm91dCBob3cgYmVzdCB0byBhZGRyZXNzIHRo ZW0uDQo= --_000_6EB34CB5D82C4645B826C56144826EA97EA5AF68SZXEMA509MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0K CXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDEx IDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglw YW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpw Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGww DQoJe21zby1saXN0LWlkOjE1MjExMTY2MzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTc5Mzg4 MDk5MDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBj bTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5T dXBwb3J0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkppbSBHdWljaGFyZCAoamd1aWNoYXIpPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXks IEF1Z3VzdCAyNiwgMjAxNCA3OjQxIFBNPGJyPg0KPGI+VG86PC9iPiBzZmNAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gW3NmY10gQ2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtbWVy Z2VkLXNmYy1hcmNoaXRlY3R1cmUtMDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5HcmVldGluZ3MgV0c6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPlRoaXMgbWVzc2FnZSBiZWdpbnMgYSB0d28gd2VlayBjYWxsIGZvciBXRyBh ZG9wdGlvbiBvZiBkcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZS0wMiBbPGEgaHJlZj0iaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVy ZS8iPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWVyZ2VkLXNmYy1hcmNo aXRlY3R1cmUvPC9hPl0mbmJzcDtlbmRpbmcNCiBTZXB0ZW1iZXIgOXRoIDIwMTQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UGxl YXNlIHJlc3BvbmQgdG8gdGhlIFNGQyBtYWlsaW5nIGxpc3Qgd2l0aCBhbnkgc3RhdGVtZW50cyBv ZiBhcHByb3ZhbCBvciBkaXNhcHByb3ZhbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5BcyBhbHdheXMsIHBsZWFzZSBub3RlOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEi Pg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhpcyBpcyBub3Qg V0cgTGFzdCBDYWxsLiBUaGUgZG9jdW1lbnQgaXMgbm90IGZpbmFsLCBhbmQgdGhlIFdHIGlzIGV4 cGVjdGVkIHRvIG1vZGlmeSB0aGUgZG9jdW1lbnTigJlzIGNvbnRlbnQgdW50aWwgdGhlcmUgaXMg V0cgY29uc2Vuc3VzIHRoYXQgdGhlIGNvbnRlbnQgaXMgc29saWQuIFRoZXJlZm9yZSwgcGxlYXNl DQogZG9u4oCZdCBvcHBvc2UgYWRvcHRpb24ganVzdCBiZWNhdXNlIHlvdSB3YW50IHRvIHNlZSBj aGFuZ2VzIHRvIGl0cyBjb250ZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JZiB5b3UgaGF2ZSBvYmplY3Rpb25z IHRvIGFkb3B0aW9uIG9mIHRoZSBkb2N1bWVudCwgcGxlYXNlIHN0YXRlIHlvdXIgcmVhc29ucyB3 aHksIGFuZCBleHBsYWluIHdoYXQgaXQgd291bGQgdGFrZSB0byBhZGRyZXNzIHlvdXIgY29uY2Vy bnMuPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNv bG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPklmIHlvdSBoYXZlIGlzc3VlcyB3aXRoIHRoZSBjb250ZW50LCBieSBh bGwgbWVhbnMgcmFpc2UgdGhvc2UgaXNzdWVzIGFuZCB3ZSBjYW4gYmVnaW4gYSBkaWFsb2cgYWJv dXQgaG93IGJlc3QgdG8gYWRkcmVzcyB0aGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC9vbD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6EB34CB5D82C4645B826C56144826EA97EA5AF68SZXEMA509MBXchi_--