From nobody Sun May 1 23:35:32 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A342712B062 for ; Sun, 1 May 2016 23:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 PYBTgrn5KYKG for ; Sun, 1 May 2016 23:35:28 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52D8212B043 for ; Sun, 1 May 2016 23:35:28 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 727B64089C; Mon, 2 May 2016 08:35:26 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 472AD2006D; Mon, 2 May 2016 08:35:26 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0279.002; Mon, 2 May 2016 08:35:26 +0200 From: To: Dave Dolson Thread-Topic: draft-ietf-sfc-control-plane -- C3 interface Thread-Index: AdGiKlPyCGamlj3aSpeV/2k+/ATTtwAI7KCAAHuhleA= Date: Mon, 2 May 2016 06:35:25 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D62720@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D6201C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008D62720OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] draft-ietf-sfc-control-plane -- C3 interface X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 06:35:30 -0000 --_000_787AE7BB302AE849A7480A190F8B933008D62720OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dave, Works for me. I fixed this one as you suggested. Cheers, Med De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : vendredi 29 avril 2016 23:34 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : RE: draft-ietf-sfc-control-plane -- C3 interface Med, Please see inline [DD2] [Med] FWIW, context information is mentioned in the WG charter "communicate= s context information between nodes that implement". What about this change= to avoid confusion: OLD: This interface is also used to instruct an SFC-aware SF about any context information it needs to supply in the context of a given SFC. NEW: This interface is also used to instruct an SFC-aware SF about any context information (a.k.a., metadata) it needs to supply for a given SFC. [DD] Again, is this intended to mean adding information to a packet? Or is = "supply" intentionally vague about the delivery mechanism? [Med] "Supply" is intentional here as this covers both cases: (1) add a new= information to a packer (e.g., a new TLV), (2) update the context of an ex= isting TLV. [DD2] I think we agree on the purpose. But if it is configuration about how= to modify packets, I think you should say so; otherwise one might think it= is about supplying information out-of-band in the control-plane. Would you= change "... it needs to supply for a given SFC." to "... it needs to attac= h to packets for a given SFC." ? --_000_787AE7BB302AE849A7480A190F8B933008D62720OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Dave,

 

Works for me. I fixed this one = as you suggested.

 

Cheers,

Med

 

De : Dave= Dolson [mailto:ddolson@sandvine.com]
Envoy=E9 : vendredi 29 avril 2016 23:34
=C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
Objet : RE: draft-ietf-sfc-control-plane -- C3 interface

 

Med,

Please = see inline [DD2]

&n= bsp;

 

[Med] FWIW, context information= is mentioned in the WG charter “communicates context information bet= ween nodes that implement”. What about this change to avoid confusion:

 

OLD:

   This interface is also used to instruct an SFC-= aware SF about any

   context information it needs to supply in the c= ontext of a given SFC.

 

NEW:

   This interface is also used to instruct an SFC-= aware SF about any

   context information (a.k.a., metadata) it needs= to supply

   for a given SFC.

[DD] Ag= ain, is this intended to mean adding information to a packet? Or is “= supply” intentionally vague about the delivery mechanism?<= /span>

[Med] “Supply” is int= entional here as this covers both cases: (1) add a new information to a pac= ker (e.g., a new TLV), (2) update the context of an existing TLV.

[DD2] I= think we agree on the purpose. But if it is configuration about how to mod= ify packets, I think you should say so; otherwise one might think it is abo= ut supplying information out-of-band in the control-plane. Would you change “… it needs to supply for = a given SFC.” to “… it needs to attach to packets for a g= iven SFC.” ?

&n= bsp;

 

--_000_787AE7BB302AE849A7480A190F8B933008D62720OPEXCLILMA3corp_-- From nobody Sun May 1 23:58:44 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA62E12D099 for ; Sun, 1 May 2016 23:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 17oUrR3EHBVe for ; Sun, 1 May 2016 23:58:38 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEB3D12B040 for ; Sun, 1 May 2016 23:58:37 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id B4D7222D0BB; Mon, 2 May 2016 08:58:35 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.18]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 8B6AC35C07D; Mon, 2 May 2016 08:58:35 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0279.002; Mon, 2 May 2016 08:58:35 +0200 From: To: Dave Dolson Thread-Topic: draft-ietf-sfc-control-plane -- C3 interface Thread-Index: AdGiKlPyCGamlj3aSpeV/2k+/ATTtwAI7KCAAHw7rFA= Date: Mon, 2 May 2016 06:58:34 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D6273E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D6201C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008D6273EOPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.25.91516 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] draft-ietf-sfc-control-plane -- C3 interface X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 06:58:40 -0000 --_000_787AE7BB302AE849A7480A190F8B933008D6273EOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, The text we are discussing is NOT about sending traffic between SFs, but fr= om an SFF to a SF. It assumes that once an SF is consumed it sends back the= packet to the SFF that may undertake another hook to another SF in that no= de, and so on. The packet is not handed directly from an SF to another SF w= ithout soliciting the external SFF. What about making this change to make it clear? OLD: Multiple SFs may be located within the same physical node, and no SFF is enabled in that same node, means to unambiguously forward the traffic to the appropriate SF must be supported. Concretely, each SF must have a unique locator for unambiguous forwarding. NEW: Multiple SFs may be located within the same physical node, and no SFF is enabled in that same node, means to unambiguously forward the traffic from the SFF to the appropriate SF must be supported. Concretel= y, each SF ^^^^^^^^^^^^ must have a unique locator for unambiguous forwarding. This locator may = be ^^^^^^^^^^^^^^^^^= ^^ configured using this interface. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Cheers, Med De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : vendredi 29 avril 2016 23:34 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : RE: draft-ietf-sfc-control-plane -- C3 interface Med, Please see inline [DD2] Regarding this paragraph, I think it would be cleaner if this behavior actu= ally requires the C2 interface into the SF. [Med] I do think the current wording is correct. Having an SFF co-located w= ith a set of SFs is deployment-specific according to the SFC architecture R= FC. [DD] I agree with that statement. However, I think the case being described= is when there *is* a co-located SFF, but the text is pretending there isn'= t. If the following text remains, C3 will need to include all the functiona= lity of C2. [Med] I re-confirm that the initial case we wanted to cover by this text is= an SFF servicing a group of SFs that are embedded in a distinct physical n= ode. This scenario suppose that once an SF is consumed it sends back the pa= cket to the SFF that may undertake another hook to another SF in that node = and so on. The packet is not handed from an SF to another one without solic= iting the external SFF. That's sub-optimal, I agree. The text is currently = silent whether the distinct locators are configured using the C2 interface = (assuming that a distinct management interface is used between the control = element and an SFC-aware SF). [DD2] If you wish the text to be silent on which interface, then you should= move it out of section "3.3.3 C3: Interface between SFC Control Plane & SF= C-aware SFs". [DD2] But again, I think you should avoid discussing how an SF can be confi= gured to send traffic directly to another SF, which I don't think is archit= ecturally correct. There needs to be a (co-located) SFF to connect them. --_000_787AE7BB302AE849A7480A190F8B933008D6273EOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

The text we are discussing is N= OT about sending traffic between SFs, but from an SFF to a SF. It assumes that once an SF is consumed it sends back the pa= cket to the SFF that may undertake another hook to another SF in that node,= and so on. The packet is not handed directly from an SF to another SF without soliciting the external SFF.

 

What about making this change t= o make it clear?

 

OLD:

   Multiple SFs may be located wi= thin the same physical node, and no SFF

   is enabled in that same node, = means to unambiguously forward the

   traffic to the appropriate SF = must be supported.  Concretely, each SF

   must have a unique locator for= unambiguous forwarding.

 

NEW:

   Multiple SFs may be located wi= thin the same physical node, and no SFF

   is enabled in that same node, = means to unambiguously forward the

   traffic from the SFF to the ap= propriate SF must be supported.  Concretely, each SF=

       &= nbsp;   ^^^^^^^^^^^^

   must have a unique locator for= unambiguous forwarding. This locator may be

       &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;^^^^^^^^^^^^^^^^^^^

   configured using this interfac= e.

   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^

 

Cheers,

Med

 

De : Dave= Dolson [mailto:ddolson@sandvine.com]
Envoy=E9 : vendredi 29 avril 2016 23:34
=C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
Objet : RE: draft-ietf-sfc-control-plane -- C3 interface

 

Med,

Please = see inline [DD2]

&n= bsp;

&n= bsp;

 

Regarding this paragraph, I thi= nk it would be cleaner if this behavior actually requires the C2 interface = into the SF.

 

[Med] I do think the current wo= rding is correct. Having an SFF co-located with a set of SFs is deployment-= specific according to the SFC architecture RFC.

[DD] I = agree with that statement. However, I think the case being described is whe= n there *is* a co-located SFF, but the text is pretending there isn&= #8217;t. If the following text remains, C3 will need to include all the functionality of C2.

[Med] I re-confirm that the initi= al case we wanted to cover by this text is an SFF servicing a group of SFs = that are embedded in a distinct physical node. This scenario suppose that once an SF is consumed it sends back the packet to t= he SFF that may undertake another hook to another SF in that node and so on= . The packet is not handed from an SF to another one without soliciting the= external SFF. That’s sub-optimal, I agree. The text is currently silent whether the distinct locators are co= nfigured using the C2 interface (assuming that a distinct management interf= ace is used between the control element and an SFC-aware SF).

[DD2] I= f you wish the text to be silent on which interface, then you should move i= t out of section “3.3.3 C3: Interface between SFC Control Plane &= SFC-aware SFs”.

[DD2] B= ut again, I think you should avoid discussing how an SF can be configured t= o send traffic directly to another SF, which I don’t think is archite= cturally correct. There needs to be a (co-located) SFF to connect them.   

 

--_000_787AE7BB302AE849A7480A190F8B933008D6273EOPEXCLILMA3corp_-- From nobody Mon May 2 02:04:45 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45ACB12D1CC for ; Mon, 2 May 2016 02:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 Th5zTh20vz6r for ; Mon, 2 May 2016 02:04:40 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FD2012D1CB for ; Mon, 2 May 2016 02:04:40 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 0720B20537; Mon, 2 May 2016 11:04:39 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id CC0661A0062; Mon, 2 May 2016 11:04:38 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0279.002; Mon, 2 May 2016 11:04:38 +0200 From: To: Dave Dolson Thread-Topic: draft-ietf-sfc-control-plane -- C3 interface Thread-Index: AdGiKlPyCGamlj3aSpeV/2k+/ATTtwAI7KCAAHuzN2A= Date: Mon, 2 May 2016 09:04:38 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D627D6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D6201C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008D627D6OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] draft-ietf-sfc-control-plane -- C3 interface X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 09:04:43 -0000 --_000_787AE7BB302AE849A7480A190F8B933008D627D6OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Ok, I understand better your case. Please find below a text proposal: NEW: The controller may use the C3 interface to specify how the reverse path of flows, that are processed for a given direction, is selected by the SF. This feature is useful, for example, for packets generated by an SFC-aware SF to ensure these packets are forwarded to the corresponding source node with the same set of SFs, involved in the forward path, are invoked in the reverse order when forwarding back these packets. Special care should be considered to avoid that instructions provided to distinct SFs lead to loops. Does it solve your concern? I don't know whether there should be a default behavior when no instruction= is provided to the SF (e.g., assume that the same SFF should be used for b= oth directions?). Cheers, Med De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : vendredi 29 avril 2016 23:34 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : RE: draft-ietf-sfc-control-plane -- C3 interface Med, Please see inline [DD2] De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : vendredi 29 avril 2016 16:24 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : RE: draft-ietf-sfc-control-plane -- C3 interface [..] E.g., as in section 5.1 of https://www.ietf.org/archive/id/draft-penno-sfc-= packet-02.txt Maybe add this paragraph: "This interface informs the SFC-aware SF about the method for handling bidi= rectional paths, either by conveying the algorithmic method to use, or by providing forward/= reverse path mapping." [Med] I'm hesitating to add text about the "algorithmic method" as I don't = have a document to cite. Note that some stateful SFs (e.g., NAT) will natur= ally add a reverse mapping to handle incoming packets without requiring inp= uts from the CP. What do you mean by "providing forward/reverse path mappin= g"? Is it SF-specific mapping? [DD] I agree there is a lack of material to cite... [DD] What I mean is informing the SF that "path X is the complementary path= of path Y". E.g., "Paths 100 (upstream) and 101 (downstream) are pairs. Re= spond to a path-100 packet on path 101." [Med] Thank you for the clarification. What would be the added value of pro= viding that information (X complementary of Y) if we assume that two classi= fication rules are installed to handle both directions? [DD2] Please see the new https://tools.ietf.org/html/draft-penno-sfc-packet= -03, which discusses the need for symmetric path information. Section 5.1 = talks about using the control plane to provide this information. If this ap= proach is taken, the C3 interface would provide the information. What about adding this NEW text at the end of Section 4.2? NEW: Typically, C2 interface is used to ensure that the same SF instance is involved in both directions of a flow (including, to ensure full chain symmetry). [DD] I disagree that C2 has anything to do with this. Instead, C1 must be u= sed to provide consistent classification. [Med] The example I have in mind is an a statefull NAT that is attached to = a given SFF while the Classifier hasn't the visibility on the full forwardi= ng path. The classifier in such case has no means to force that the same SF= instance will be invoked for both direction. Wouldn't C2 be involved in su= ch case? [DD2] OK, I see your point, but this is different than my concern, which is= that if the SF needs to know about related forward/reverse paths, then the= C3 interface has this responsibility. [DD] How about adding the generic statement to section 3.3.3, "Some SFs may= need to be configured regarding the rules for packet reversal on a path. T= he controller may use the C3 interface to specify how packets on a path may= be placed on the reverse path." [Med] What is specific in this case compared to configuring two classificat= ion rules; one for each direction? Is there something the classifier is sup= posed to do? [DD2] I hope https://tools.ietf.org/html/draft-penno-sfc-packet-03 explains= why SFs need to know this. --_000_787AE7BB302AE849A7480A190F8B933008D627D6OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Ok, I understand better your ca= se. Please find below a text proposal:

 

NEW:

 

   The controller may use the C3 = interface to specify how the reverse

   path of flows, that are proces= sed for a given direction, is selected

   by the SF.  This feature = is useful, for example, for packets

   generated by an SFC-aware SF t= o ensure these packets are forwarded to

   the corresponding source node = with the same set of SFs, involved in

   the forward path, are invoked = in the reverse order when forwarding

   back these packets.  Spec= ial care should be considered to avoid that

   instructions provided to disti= nct SFs lead to loops.

 

Does it solve your concern?

 

I don’t know whether ther= e should be a default behavior when no instruction is provided to the SF (e= .g., assume that the same SFF should be used for both directions?).   

 

Cheers,

Med

 

De : Dave= Dolson [mailto:ddolson@sandvine.com]
Envoy=E9 : vendredi 29 avril 2016 23:34
=C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
Objet : RE: draft-ietf-sfc-control-plane -- C3 interface

 

Med,

Please = see inline [DD2]

&n= bsp;

 

 

De : Dave= Dolson [mailto:ddolson@sandvine.co= m]
Envoy=E9 : vendredi 29 avril 2016 16:24
=C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
Objet : RE: draft-ietf-sfc-control-plane -- C3 interface

 

[..]

 

E.g., as in section 5.1 of https://www.ietf.org/archive/id/draft-penno-sfc-pack= et-02.txt

Maybe add this paragraph:<= /o:p>

“This interface informs t= he SFC-aware SF about the method for handling bidirectional paths,

either by conveying the algorit= hmic method to use, or by providing forward/reverse path

mapping.”

 

[Med] I’m hesitating to a= dd text about the “algorithmic method” as I don’t have a = document to cite. Note that some stateful SFs (e.g., NAT) will naturally add a reverse mapping to handle incoming packets without requiring inputs = from the CP. What do you mean by “providing forward/reverse path mapp= ing”? Is it SF-specific mapping?

&n= bsp;

[DD] I = agree there is a lack of material to cite…

[DD] Wh= at I mean is informing the SF that “path X is the complementary path = of path Y”. E.g., “Paths 100 (upstream) and 101 (downstream) ar= e pairs. Respond to a path-100 packet on path 101.”=

[Med] Thank you for the clarifica= tion. What would be the added value of providing that information (X comple= mentary of Y) if we assume that two classification rules are installed to handle both directions?  

[DD2] P= lease see the new https://t= ools.ietf.org/html/draft-penno-sfc-packet-03, which discusses the nee= d for symmetric path information.  Sectio= n 5.1 talks about using the control plane to provide this information. If this approach is taken, the C3 interface would provid= e the information.

 

What about adding this NEW text= at the end of Section 4.2?

 

NEW:

   Typically, C2 inte= rface is used to ensure that the same SF instance

   is involved i= n both directions of a flow (including, to ensure full

   chain symmetr= y).

[DD] I = disagree that C2 has anything to do with this. Instead, C1 must be used to = provide consistent classification.

[Med] The example I have in mind = is an a statefull NAT that is attached to a given SFF while the Classifier = hasn’t the visibility on the full forwarding path. The classifier in such case has no means to force that the same SF instanc= e will be invoked for both direction. Wouldn’t C2 be involved in such= case?  

[DD2] O= K, I see your point, but this is different than my concern, which is that i= f the SF needs to know about related forward/reverse paths, then the C3 int= erface has this responsibility.

 

[DD] Ho= w about adding the generic statement to section 3.3.3, “Some SFs may = need to be configured regarding the rules for packet reversal on a path. Th= e controller may use the C3 interface to specify how packets on a path may be placed on the reverse path.”=

[Med] What is specific in this ca= se compared to configuring two classification rules; one for each direction= ? Is there something the classifier is supposed to do? 

[DD2] I= hope https://tools.ietf.org/html/draft-penno-sfc-packet-03 explains why SFs = need to know this.

   
--_000_787AE7BB302AE849A7480A190F8B933008D627D6OPEXCLILMA3corp_-- From nobody Mon May 2 03:53:11 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 705F712B056 for ; Mon, 2 May 2016 03:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 ZPXORmOGe1XN for ; Mon, 2 May 2016 03:53:09 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6A312B00A for ; Mon, 2 May 2016 03:53:08 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-2.sandvine.com (192.168.194.177) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 2 May 2016 06:53:07 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Mon, 2 May 2016 06:53:07 -0400 From: Dave Dolson To: "mohamed.boucadair@orange.com" Thread-Topic: draft-ietf-sfc-control-plane -- C3 interface Thread-Index: AdGiKlPylIfr42rfQei+e06aOHat/gALj+BgAII/qAD///55IA== Date: Mon, 2 May 2016 10:53:06 +0000 Message-ID: <20160502105304.5697621.80606.81916@sandvine.com> References: <787AE7BB302AE849A7480A190F8B933008D6201C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> , <787AE7BB302AE849A7480A190F8B933008D6273E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D6273E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] draft-ietf-sfc-control-plane -- C3 interface X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 10:53:10 -0000 Ah, now I get it. Thanks. From: mohamed.boucadair@orange.com Sent: Monday, May 2, 2016 2:58 AM To: Dave Dolson Cc: sfc@ietf.org Subject: RE: draft-ietf-sfc-control-plane -- C3 interface Re-, The text we are discussing is NOT about sending traffic between SFs, but fr= om an SFF to a SF. It assumes that once an SF is consumed it sends back the= packet to the SFF that may undertake another hook to another SF in that no= de, and so on. The packet is not handed directly from an SF to another SF w= ithout soliciting the external SFF. What about making this change to make it clear? OLD: Multiple SFs may be located within the same physical node, and no SFF is enabled in that same node, means to unambiguously forward the traffic to the appropriate SF must be supported. Concretely, each SF must have a unique locator for unambiguous forwarding. NEW: Multiple SFs may be located within the same physical node, and no SFF is enabled in that same node, means to unambiguously forward the traffic from the SFF to the appropriate SF must be supported. Concretel= y, each SF ^^^^^^^^^^^^ must have a unique locator for unambiguous forwarding. This locator may = be ^^^^^^^^^^^^^^^^^= ^^ configured using this interface. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Cheers, Med De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : vendredi 29 avril 2016 23:34 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : RE: draft-ietf-sfc-control-plane -- C3 interface Med, Please see inline [DD2] Regarding this paragraph, I think it would be cleaner if this behavior actu= ally requires the C2 interface into the SF. [Med] I do think the current wording is correct. Having an SFF co-located w= ith a set of SFs is deployment-specific according to the SFC architecture R= FC. [DD] I agree with that statement. However, I think the case being described= is when there *is* a co-located SFF, but the text is pretending there isn= =92t. If the following text remains, C3 will need to include all the functi= onality of C2. [Med] I re-confirm that the initial case we wanted to cover by this text is= an SFF servicing a group of SFs that are embedded in a distinct physical n= ode. This scenario suppose that once an SF is consumed it sends back the pa= cket to the SFF that may undertake another hook to another SF in that node = and so on. The packet is not handed from an SF to another one without solic= iting the external SFF. That=92s sub-optimal, I agree. The text is currentl= y silent whether the distinct locators are configured using the C2 interfac= e (assuming that a distinct management interface is used between the contro= l element and an SFC-aware SF). [DD2] If you wish the text to be silent on which interface, then you should= move it out of section =933.3.3 C3: Interface between SFC Control Plane & = SFC-aware SFs=94. [DD2] But again, I think you should avoid discussing how an SF can be confi= gured to send traffic directly to another SF, which I don=92t think is arch= itecturally correct. There needs to be a (co-located) SFF to connect them. From nobody Mon May 2 03:58:44 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B413112B025 for ; Mon, 2 May 2016 03:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 3uBp-vngkO20 for ; Mon, 2 May 2016 03:58:41 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id CF36212B00A for ; Mon, 2 May 2016 03:58:40 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([::1]) with mapi id 14.03.0195.001; Mon, 2 May 2016 06:58:39 -0400 From: Dave Dolson To: "mohamed.boucadair@orange.com" Thread-Topic: draft-ietf-sfc-control-plane -- C3 interface Thread-Index: AdGiKlPylIfr42rfQei+e06aOHat/gALj+BgAIamyAD//9zNEg== Date: Mon, 2 May 2016 10:58:39 +0000 Message-ID: <20160502105838.5697621.90164.81919@sandvine.com> References: <787AE7BB302AE849A7480A190F8B933008D6201C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> , <787AE7BB302AE849A7480A190F8B933008D627D6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D627D6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] draft-ietf-sfc-control-plane -- C3 interface X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 10:58:42 -0000 That works, thanks. From: mohamed.boucadair@orange.com Sent: Monday, May 2, 2016 5:04 AM To: Dave Dolson Cc: sfc@ietf.org Subject: RE: draft-ietf-sfc-control-plane -- C3 interface Re-, Ok, I understand better your case. Please find below a text proposal: NEW: The controller may use the C3 interface to specify how the reverse path of flows, that are processed for a given direction, is selected by the SF. This feature is useful, for example, for packets generated by an SFC-aware SF to ensure these packets are forwarded to the corresponding source node with the same set of SFs, involved in the forward path, are invoked in the reverse order when forwarding back these packets. Special care should be considered to avoid that instructions provided to distinct SFs lead to loops. Does it solve your concern? I don=92t know whether there should be a default behavior when no instructi= on is provided to the SF (e.g., assume that the same SFF should be used for= both directions?). Cheers, Med De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : vendredi 29 avril 2016 23:34 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : RE: draft-ietf-sfc-control-plane -- C3 interface Med, Please see inline [DD2] De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : vendredi 29 avril 2016 16:24 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : RE: draft-ietf-sfc-control-plane -- C3 interface [..] E.g., as in section 5.1 of https://www.ietf.org/archive/id/draft-penno-sfc-= packet-02.txt Maybe add this paragraph: =93This interface informs the SFC-aware SF about the method for handling bi= directional paths, either by conveying the algorithmic method to use, or by providing forward/= reverse path mapping.=94 [Med] I=92m hesitating to add text about the =93algorithmic method=94 as I = don=92t have a document to cite. Note that some stateful SFs (e.g., NAT) wi= ll naturally add a reverse mapping to handle incoming packets without requi= ring inputs from the CP. What do you mean by =93providing forward/reverse p= ath mapping=94? Is it SF-specific mapping? [DD] I agree there is a lack of material to cite=85 [DD] What I mean is informing the SF that =93path X is the complementary pa= th of path Y=94. E.g., =93Paths 100 (upstream) and 101 (downstream) are pai= rs. Respond to a path-100 packet on path 101.=94 [Med] Thank you for the clarification. What would be the added value of pro= viding that information (X complementary of Y) if we assume that two classi= fication rules are installed to handle both directions? [DD2] Please see the new https://tools.ietf.org/html/draft-penno-sfc-packet= -03, which discusses the need for symmetric path information. Section 5.1 = talks about using the control plane to provide this information. If this ap= proach is taken, the C3 interface would provide the information. What about adding this NEW text at the end of Section 4.2? NEW: Typically, C2 interface is used to ensure that the same SF instance is involved in both directions of a flow (including, to ensure full chain symmetry). [DD] I disagree that C2 has anything to do with this. Instead, C1 must be u= sed to provide consistent classification. [Med] The example I have in mind is an a statefull NAT that is attached to = a given SFF while the Classifier hasn=92t the visibility on the full forwar= ding path. The classifier in such case has no means to force that the same = SF instance will be invoked for both direction. Wouldn=92t C2 be involved i= n such case? [DD2] OK, I see your point, but this is different than my concern, which is= that if the SF needs to know about related forward/reverse paths, then the= C3 interface has this responsibility. [DD] How about adding the generic statement to section 3.3.3, =93Some SFs m= ay need to be configured regarding the rules for packet reversal on a path.= The controller may use the C3 interface to specify how packets on a path m= ay be placed on the reverse path.=94 [Med] What is specific in this case compared to configuring two classificat= ion rules; one for each direction? Is there something the classifier is sup= posed to do? [DD2] I hope https://tools.ietf.org/html/draft-penno-sfc-packet-03 explains= why SFs need to know this. From nobody Mon May 2 04:30:44 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D507A12B04D for ; Mon, 2 May 2016 04:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 8A2de3eRzUDx for ; Mon, 2 May 2016 04:30:39 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B52612B020 for ; Mon, 2 May 2016 04:30:39 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 52EB218088E; Mon, 2 May 2016 13:30:37 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 10A701A0078; Mon, 2 May 2016 13:30:37 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0279.002; Mon, 2 May 2016 13:30:36 +0200 From: To: Sumandra Majee , Dave Dolson , "sfc@ietf.org" Thread-Topic: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Thread-Index: AQHRoD1fSI1yPp+UQ0KhY1xrwASm1p+eIaqAgAGXhUD//+XaAIAF6y3g Date: Mon, 2 May 2016 11:30:36 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D6295C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <65e5a067-8d94-2632-506f-9f2d60dabeaf@gmail.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008D6295COPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Cc: "Jim Guichard \(jguichar\)" Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 11:30:43 -0000 --_000_787AE7BB302AE849A7480A190F8B933008D6295COPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dave, Sumandra, I made the following change in Section 4.10.5., paragraph 7: OLD: The matching criteria for SFF can be more sophisticated. For example, the matching criteria could be any fields in the data packets, such as (non-exhaustive list): NEW: The matching criteria for SFF can be more sophisticated. For example, it could be the SFP-id together with any fields in the data packets, such as (non-exhaustive list): Better? Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Sumandra Majee Envoy=E9 : jeudi 28 avril 2016 21:03 =C0 : Dave Dolson; sfc@ietf.org Cc : Jim Guichard (jguichar) Objet : Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Dave, I would also concur that SFF is a forwarding entity that uses pathID/SI to = find the next-hop/next-sf/next-sff. This is how our SFF works. It is absolutely possible that co resident classifier to further classify b= ased on l3/l4/l7/python_code and change the path. But logically that is an= other classification and list below is certainly not exhaustive. From: sfc > on behalf of = Dave Dolson > Date: Thursday, April 28, 2016 at 11:43 AM To: "sfc@ietf.org" > Cc: "Jim Guichard (jguichar)" > Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Further to Jim's points about section 4.10.5, do I read it correctly that t= he SFF can be configured to steer traffic on the basis of these? o Destination MAC address o Source MAC address o VLAN-ID, o Destination IP address o Source IP address o Source port number o Destination port number o DSCP o Packet size, etc., or any combination thereof. This comes totally unexpected to me, thinking that the SFF steers traffic b= ased exclusively on Service Path Identifier and Service Index (SPI/SI), whi= ch oddly aren't in the above list. I can guess that maybe this is about reclassification, but "classification"= isn't mentioned in 4.10.5. Can someone explain? -Dave From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Wednesday, April 27, 2016 10:18 AM To: Martin Stiemerling; sfc@ietf.org Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Hi Martin & WG: A few comments that I would like to see addressed in the document before it= can move forward to the next step. * Section 2.2 SFC Control Plane Bootstrapping. This section is too wishy washy. It makes the statement "this document assu= mes the SFC control plane is provided with a set of information that is req= uired for proper SFC operation" but then goes on to list bullets that are l= ikely to be provided or may be provided. It does not actually provide any i= nformation on what is required for proper SFC operation. In the list of lik= ely information there is no indication of whether this information must exi= st in the network prior to bootstrapping the SFC control plane element; thi= s is true also for the list of may information. Surely we should provide gu= idelines on what must be available before the SFC control plane element can= actually function although it is reasonable to assume that it can bootstra= p without any information (albeit it can't actually do anything). On this p= oint I would argue that several of the may elements are actually required s= uch as SFF, SF, SFC-proxy locators and may exist prior to bootstrapping the= SFC control plane element, or may be added later through some control inte= rface. Minor point -> typo in bullet point 6 - SFP proxy should read SFC proxy * Section 2.3 Coherent Setup of an SFC-enabled Domain What does the sentence "various transport encapsulation schemes and/or vari= ations of SFC header implementations may be supported" actually mean ? Are = we referring to the fact that the SFC header may carry type-1 or type-2 met= adata or something else ? Note that there is only one SFC header implementa= tion based on the WG charter so if we are referring to different SFC format= s (meaning metadata) then please make this clear in the text, and if not, p= lease remove this sentence. * Section 3.1 Reference Architecture Second bullet point "mapping between service function chains and SFPs" - th= is is a general comment for the entire document but applies here also. Ther= e is no mention of mapping SFPs -> RSPs - in fact RSP is mentioned only onc= e in the entire document. The architecture is explicit in that the SFP when= rendered into the network is an RSP and therefore the SFC control plane el= ement needs to have information on currently deployed RSPs. Additionally there is no interface specified for communication between the = SFC Control Plane Element and SF management systems. This is an important a= spect as many SF's may require that SFC information be communicated to thei= r management systems that will be responsible for communicating directly wi= th their respective SF's. * Section 3.1.1. C1: Interface between SFC Control Plane & SFC Classifi= er The sentence "The control plane may instruct the classifier about the initi= al values of the Service Index (SI)" should be changed to say MUST as other= wise if a classifier chooses whatever value it wants then that may not alig= n with what is programmed into the SFFs by the SFC Control Plane element. * Section 4.10.4. Encoding the Exact SFF/SF Sequence in Data Packets This section does not actually provide any meaning or indication of relatio= nship with the SFC Control Plane element. Furthermore, there has been no W= G consensus to carry source routes within the SFC encapsulation. Therefore = this entire section should be removed from the document. * Section 4.10.5. Fully Controlled SFF/SF Sequence for a SFP Figure 2 lists 3 different SFP-id's whereas the text mentions only SFP-id #= 1. Is this simply a typo or are you trying to convey something else ? Further you state that "the steering policies to a SFF node for service fun= ction chain depends on if the packet comes from previous SFF or comes from = a specific SF i.e., the SFP Forwarding Table entries have to be ingress por= t specific" - this is an inaccurate statement as the combination of the SF= P-id and service-index determines the forwarding behavior (as specified in = section 3.3 & section 7 of draft-ietf-sfc-nsh-04). This sentence should be= removed from the text. Jim On 4/27/16, 12:29 AM, "sfc on behalf of Martin Stiemerling" on behalf of mls.ietf@gmail.com> wrote: Dear all, This is the start of the Working Group Last Call (WGLC) for draft-ietf-sfc-control-plane-04.txt The WGLC lasts for 2 weeks and will end May 11th at 10 pm PDT. Please send your comments and reviews to the sfc@ietf.org list. Regards, Martin (SFC co-chair) _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_787AE7BB302AE849A7480A190F8B933008D6295COPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dave, Sumandra,

 

I made the following change in Section 4.10.5., paragraph 7:

 

OLD:

 

    The matching criteria fo= r SFF can be more sophisticated.  For

    example, the matching cr= iteria could be any fields in the data

    packets, such as (non-ex= haustive list):

 

NEW:

 

    The matching criteria fo= r SFF can be more sophisticated.  For

    example, it could be the= SFP-id together with any fields in the data

    packets, such as (non-ex= haustive list):

 

Better?

 

Cheers,

Med

 

De : sfc = [mailto:sfc-bounces@ietf.org] De la part de Sumandra Majee
Envoy=E9 : jeudi 28 avril 2016 21:03
=C0 : Dave Dolson; sfc@ietf.org
Cc : Jim Guichard (jguichar)
Objet : Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt<= o:p>

 

Dave,

I would also concur that SF= F is a forwarding entity that uses pathID/SI to find the next-hop/next-sf/n= ext-sff. This is how our SFF works.

 

It is absolutely possible t= hat co resident classifier to further classify based on  l3/l4/l7/pyth= on_code and change the path. But logically that is another classification and list below is certainly not exhaustive.  

 

From: sfc <sfc-bounces@ietf.org> on behalf of Dave Dolson <ddolson@sandvine.com>
Date: Thursday, April 28, 2016 at 11:43 AM
To: "sfc@ietf.org" <= ;sfc@ietf.org>
Cc: "Jim Guichard (jguichar)" <jguichar@cisco.com>
Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt=

 

Further to= Jim’s points about section 4.10.5, do I read it correctly that the S= FF can be configured to steer traffic on the basis of these?

 &nbs= p; o  Destination MAC address

 &nbs= p; o  Source MAC address

 &nbs= p; o  VLAN-ID,<= /o:p>

 &nbs= p; o  Destination IP address

 &nbs= p; o  Source IP address

 &nbs= p; o  Source port number

 &nbs= p; o  Destination port number

 &nbs= p; o  DSCP

 &nbs= p; o  Packet size, etc., or any combination thereof.

 

This comes= totally unexpected to me, thinking that the SFF steers traffic based exclu= sively on Service Path Identifier and Service Index (SPI/SI), which oddly aren’t in the above list.

 

I can gues= s that maybe this is about reclassification, but “classification̶= 1; isn’t mentioned in 4.10.5.

Can someon= e explain?

 

-Dave

 

 

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, April 27, 2016 10:18 AM
To: Martin Stiemerling; sfc@ietf.org=
Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt

 

Hi Martin &a= mp; WG:=

 

A few commen= ts that I would like to see addressed in the document before it can move fo= rward to the next step.

  • Section 2.2 SFC Control Plane Bootstrapping.

This section= is too wishy washy. It makes the statement “this document assumes th= e SFC control plane is provided with a set of information that is required for proper SFC operation” but then goes on to list bu= llets that are likely to be provided or may be provided. It does n= ot actually provide any information on what is required for proper SFC operation. In the list of likely&n= bsp;information there is no indication of whether this information must exi= st in the network prior to bootstrapping the SFC control plane element; thi= s is true also for the list of may information. Surely we should provide guidelines on what must be available before the SFC control plane element can actual= ly function although it is reasonable to assume that it can bootstrap witho= ut any information (albeit it can’t actually do anything). On this point I would argue that several of the may&n= bsp;elements are actually required such as SFF, SF, SFC-proxy locators and = may exist prior to bootstrapping the SFC control plane element, or may be a= dded later through some control interface. 

 

Minor point = -> typo in bullet point 6 – SFP proxy should read SFC proxy

  • Section 2.3 Coherent Setup of an SFC-enabled Do= main

What does th= e sentence “various transport encapsulation schemes and/or variations= of SFC header implementations may be supported” actually mean ? Are we referring to the fact that the SFC header may carry type-1 or type-= 2 metadata or something else ? Note that there is only one SFC header implementation based on the WG charter so if we are r= eferring to different SFC formats (meaning metadata) then please make this = clear in the text, and if not, please remove this sentence. 

  • Section 3.1 Reference Architecture

Second bulle= t point “mapping between service function chains and SFPs” - th= is is a general comment for the entire document but applies here also. There is no mention of mapping SFPs -> RSPs – in fact RSP is ment= ioned only once in the entire document. The architecture is explicit in tha= t the SFP when rendered into the network is an RSP and therefore the SFC co= ntrol plane element needs to have information on currently deployed RSPs.

 

Additionally= there is no interface specified for communication between the SFC Control = Plane Element and SF management systems. This is an important aspect as many SF’s may require that SFC information be communicated= to their management systems that will be responsible for communicating dir= ectly with their respective SF’s. 

  • Section 3.1.1. C1: Interface between SFC Contro= l Plane & SFC Classifier<= /li>

The sentence= “The control plane may instruct the classifier about the initial val= ues of the Service Index (SI)” should be changed to say MUST as otherwise if a classifier chooses whatever value it wan= ts then that may not align with what is programmed into the SFFs by the SFC= Control Plane element. = ;

  • Section 4.10.4. Encoding the Exact SFF/SF Seque= nce in Data Packets

This section= does not actually provide any meaning or indication of relationship with t= he SFC Control Plane element. Furthermore,  there has been no WG consensus to carry source routes within the SFC encapsulation. There= fore this entire section should be removed from the document.

  • Section 4.10.5. Fully Controlled SFF/SF Sequenc= e for a SFP

Figure 2 lis= ts 3 different SFP-id’s whereas the text mentions only SFP-id #1. Is = this simply a typo or are you trying to convey something else ?

 

Further you = state that “the steering policies to a SFF node for service function = chain depends on if the packet comes from previous SFF or comes from a specific SF i.e., the SFP Forwarding Table entries have to be ingre= ss port specific” -  this is an inaccurate statement as the comb= ination of the SFP-id and service-index determines the forwarding behavior = (as specified in section 3.3 & section 7 of draft-ietf-sfc-nsh-04).  This sentence should be removed from the tex= t.

 

Jim

 

 

 

On 4/27/16, = 12:29 AM, "sfc on behalf of Martin Stiemerling" <sfc-bounces@ietf.org on behalf of mls.ietf@gmail.com> wrote:

 

Dear all,

 

This is the = start of the Working Group Last Call (WGLC) for

 

draft-ietf-s= fc-control-plane-04.txt

 

The WGLC las= ts for 2 weeks and will end May 11th at 10 pm PDT.

 

Please send = your comments and reviews to the sfc@ietf.org list.

 

Regards,

 

  = Martin (SFC co-chair)

 

____________= ___________________________________

sfc mailing = list

 

--_000_787AE7BB302AE849A7480A190F8B933008D6295COPEXCLILMA3corp_-- From nobody Mon May 2 04:58:55 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FF212D1D6 for ; Mon, 2 May 2016 04:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 jNRrFQGtDH2q for ; Mon, 2 May 2016 04:58:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 008B812D13F for ; Mon, 2 May 2016 04:58:50 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id F125D2DC435; Mon, 2 May 2016 13:58:48 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.75]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id C4665238056; Mon, 2 May 2016 13:58:48 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%19]) with mapi id 14.03.0279.002; Mon, 2 May 2016 13:58:48 +0200 From: To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: Call for WG adoption of draft-penno-sfc-appid-03 Thread-Index: AQHRZQHOvGZf31kz6UifjJTvmDJQAZ+hr9aAgARTiaA= Date: Mon, 2 May 2016 11:58:47 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D62994@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008D62994OPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.25.91516 Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-appid-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 11:58:54 -0000 --_000_787AE7BB302AE849A7480A190F8B933008D62994OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jim, all, I interpret this proposal as if it wants to inherit the IPFIX Application i= nformation to be conveyed in an nsh header. I have some issues with the rat= ionale of this draft, not its goal per se. I do not support this draft. I do think there are other design choices that= can be investigated by the WG to inherit existing IPFIX IEs without writin= g a new RFC for it for EACH IE to be conveyed in an NSH header. For example, there is a more general proposal that aims to import ANY IPFIX= Information Element (that will cover the particular case in this document)= : http://www.ietf.org/mail-archive/web/sfc/current/msg04492.html without co= nsuming the WG effort to edit/review/publish RFCs for each promising IPFIX = IEs. Further, I have the following questions for the draft: =B7 Why reserving this proposal for MD#1? =B7 What means the following headers? 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | 0 | 161 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Shared Context | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Platform Context | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Shared Context | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Example of Metadata Including the SNMP Application Identification Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard (jguichar= ) Envoy=E9 : vendredi 29 avril 2016 18:31 =C0 : sfc@ietf.org Objet : [sfc] Call for WG adoption of draft-penno-sfc-appid-03 Dear WG: We did not receive many responses for this call for adoption and therefore = would like to re-invite people to post their thoughts on adopting this docu= ment into the SFC WG. The call for adoption will run for a further 2 weeks = ending 6/13/2016. Thanks! SFC Chairs From: Jim Guichard > Date: Thursday, February 11, 2016 at 3:24 PM To: "sfc@ietf.org" > Subject: Call for WG adoption of draft-penno-sfc-appid-03 Dear WG: This email serves as a call for WG adoption of draft-penno-sfc-appid-03 as = a WG document. The call for adoption will run for 2 weeks ending 2/25/2016. Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that docume= nt for resolving open issues and documenting the WG's decisions. Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goi= ng forward, rather than a pre-condition for adoption. Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l= isted as a document author please respond to this email (to the chairs) whe= ther or not you are aware of any relevant IPR. Thanks! SFC Chairs --_000_787AE7BB302AE849A7480A190F8B933008D62994OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jim, all,

 

I interpret this proposal as if= it wants to inherit the IPFIX Application information to be conveyed in an= nsh header. I have some issues with the rationale of this draft, not its goal per se.

 

I do not support this draft. I = do think there are other design choices that can be investigated by the WG = to inherit existing IPFIX IEs without writing a new RFC for it for EACH IE to be conveyed in an NSH header.

 

For example, there is a more ge= neral proposal that aims to import ANY IPFIX Information Element (that will= cover the particular case in this document): = http://www.ietf.org/mail-archive/web/sfc/current/msg04492.html without = consuming the WG effort to edit/review/publish RFCs for each promising IPFI= X IEs.

 

Further, I have the following q= uestions for the draft:

 

=B7    &n= bsp;    Why reserving this prop= osal for MD#1?

=B7    &n= bsp;    What means the followin= g headers?

      = 0            &n= bsp;      1      &nb= sp;            2&nbs= p;            &= nbsp;     3

      = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1<= /span>

     +-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+

     | = ;      3       |&nbs= p;       0      |&nb= sp;            = 161            = ;  |

     +-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+

     | = ;             &= nbsp;   Network Shared Context     =             &nb= sp;     |

     +-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+

     | = ;            &n= bsp;    Service Platform Context    &nbs= p;            &= nbsp;   |

     +-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+

     | = ;            &n= bsp;    Service Shared Context     =             &nb= sp;     |

     +-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+

 

     &= nbsp; Figure 2: Example of Metadata Including the SNMP Application

     &= nbsp;           &nbs= p;            Identi= fication

 

Cheers,

Med

 

De : sfc = [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard (jguichar)
Envoy=E9 : vendredi 29 avril 2016 18:31
=C0 : sfc@ietf.org
Objet : [sfc] Call for WG adoption of draft-penno-sfc-appid-03<= o:p>

 

Dear WG:<= /p>

 

We did not receive many res= ponses for this call for adoption and therefore would like to re-invite peo= ple to post their thoughts on adopting this document into the SFC WG. The call for adoption will run for a further 2 weeks ending 6/= 13/2016. 

 

Thanks!

 

SFC Chairs

 

From: Jim Guichard <jguichar@cisco.com>
Date: Thursday, February 11, 2016 at 3:24 PM
To: "sfc@ietf.org" <= ;sfc@ietf.org>
Subject: Call for WG adoption of draft-penno-sfc-appid-03=

 

Dear WG:

&n= bsp;

This email serves as a call for WG adoption of draft-penno-sfc= -appid-03 as a WG document. The call for adoption will run for 2 weeks endi= ng 2/25/2016.

 <= /span>

Please note that this is a call for adoption, and not a last c= all for content of the document. Adopting a WG document simply means that t= he WG will focus its efforts on that particular draft going forward, and use that document for resolving open i= ssues and documenting the WG’s decisions.

 <= /span>

Please indicate whether you support adoption for not, and if n= ot why. Issues you have with the current document itself can also be raised= , but they should be raised in the context of what should be changed in the document going forward, rather than a pre= -condition for adoption. 

 <= /span>

Finally, now is also a good time to poll for knowledge of any = IPR that applies to this draft, in line with the IPR disclosure obligations= for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document aut= hor please respond to this email (to the chairs) whether or not you are awa= re of any relevant IPR.=

&n= bsp;

Thanks!

&n= bsp;

SFC Chairs=

--_000_787AE7BB302AE849A7480A190F8B933008D62994OPEXCLILMA3corp_-- From nobody Mon May 2 06:44:09 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D007012D09D for ; Mon, 2 May 2016 06:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 PfIYaSa3jAln for ; Mon, 2 May 2016 06:44:06 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF7312B022 for ; Mon, 2 May 2016 06:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10121; q=dns/txt; s=iport; t=1462196645; x=1463406245; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kyvi85y72BbfkRZ0BI2Aw+SwYE0AwxIVmfBaoMhO0J4=; b=SASkqWAF0V/kcS4jlAJUyFXvkX4Pvo9e40DI0JlJa45kp4fNFqaWSP2t MlnnZCA83pZUgg8TdR9TU1LxwshzzECrd9jcF0TvH6N4A5JNFl1HVaVvQ iMi4HLFsJ7Cm4YNiN6He+iSTU9O7zmlyKjDQ17FU1dKegh1BhEentzpIs U=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmAwBMWCdX/4sNJK1cgmxMU30GtHuCZ?= =?us-ascii?q?IIPDoF2IoVuAoEnOBQBAQEBAQEBZRwLhEEBAQEDASNWBQsCARoGKgICMhcOAgQ?= =?us-ascii?q?OBQkFiBQIDqh5kEEBAQEBAQEBAQEBAQEBAQEBAQEBAQENCIYhgXaCVoQOEgEBg?= =?us-ascii?q?xsrgisFmBQBgS2BeoFniQmPEY8wAR4BQ4IFG4FLbAGHUTZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,567,1454976000"; d="asc'?scan'208,217";a="267901999" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 May 2016 13:44:04 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u42Di4b5015743 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 May 2016 13:44:04 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 May 2016 09:44:03 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Mon, 2 May 2016 09:44:03 -0400 From: "Carlos Pignataro (cpignata)" To: "mohamed.boucadair@orange.com" Thread-Topic: Reuse the IPFIX registry in NSH Thread-Index: AQHRpHiwIVL3ANO/xESPP/MD2IMNPw== Date: Mon, 2 May 2016 13:44:03 +0000 Message-ID: <2D398770-C83E-48FE-BBE9-574A58871700@cisco.com> References: <787AE7BB302AE849A7480A190F8B933008D62994@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D62994@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.245.225] Content-Type: multipart/signed; boundary="Apple-Mail=_7CB76D42-C05B-47F6-AA85-F88B752F7D53"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: [sfc] Reuse the IPFIX registry in NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 13:44:07 -0000 --Apple-Mail=_7CB76D42-C05B-47F6-AA85-F88B752F7D53 Content-Type: multipart/alternative; boundary="Apple-Mail=_346F0F67-91C5-41A6-B5EF-165C4556F66C" --Apple-Mail=_346F0F67-91C5-41A6-B5EF-165C4556F66C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Med, Since you are making a generic comment outside the scope of = draft-penno-sfc-appid-03, I thought it appropriate to extract that = comment, and reply to it under separate cover (updating also the Subject = line) > On May 2, 2016, at 7:58 AM, mohamed.boucadair@orange.com wrote: >=20 > For example, there is a more general proposal that aims to import ANY = IPFIX Information Element (that will cover the particular case in this = document):http://www.ietf.org/mail-archive/web/sfc/current/msg04492.html = without = consuming the WG effort to edit/review/publish RFCs for each promising = IPFIX IEs. >=20 There have been a number of responses on the list highlighting the = significant drawbacks of this proposal. However, although I agree with = those, I think I have not yet replied enlist. Here=E2=80=99s my view. The IPFIX Information Elements registry contains over 450 entries. It = also has data types, semantics, and units associated with them. These = are in support of a protocol for transmitting Traffic Flow Information. = Looking at the SFC Architecture at RFC 7665, the Metadata is used for a = completely different purpose. Yes, there is intersection with some IPFIX = fields. But there=E2=80=99s also intersection with the IF-MIB. First, IPFIX is not a superset of all the information needed. Looking at = the WG doc on mobility and DC, and the various allocation drafts, not = every fields is in IPFIX. Second, not every IPFIX field is needed in SFC (certainly not the 450+). The corollary of this is that there are a number of associated problems = with the proposal: 1. Does an SFC implementation need to support all (ever growing) IPFIX = IEs? 2. Do you propose to specify profiles of IPFIX, which include a subset = to be used? That seems in practice more difficult than the direct = alternative. 3. Regarding fields not defined in IPFIX, does SFC need to specify a new = IPFIX IE, and specify how it would be used with IPFIX? 4. What about newly defined IPFIX fields after the publishing of the NSH = documents? How are those vetted for applicability to SFC? 5. What is SFC needs a different data type for a field? In my opinion, all of this result in a lot more work and uncertainty = than actually defining what=E2=80=99s needed. I expect some SFC/NSH use cases to use an ifIndex for example. This does = not imply that SFC need to import somehow the full IF-MIB. Similarly, I expect SFC/NSH can use specific fields or values from = various places, when it makes sense. I do not expect NSH needing to = import all of those. In summary, I believe this proposal is harmful to NSH on the above = technical grounds. As a general proposal, it seems to me like a cannon = to kill a fly. I expect SFC might need to define things like flow specifications, it = does not mean it ought to reuse the BGP Flow Spec registries, semantics, = and syntax. That said, as SFC defines things from a flow, I expect it will not = re-invent the wheel and re-use surgically. Best, =E2=80=94 Carlos. --Apple-Mail=_346F0F67-91C5-41A6-B5EF-165C4556F66C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear Med,

Since you are making a generic comment outside the scope = of draft-penno-sfc-appid-03, I thought it appropriate to extract = that comment, and reply to it under separate cover (updating also the = Subject line)

On May 2, 2016, at 7:58 AM, mohamed.boucadair@orange.com wrote:

For example, there is a more general proposal that aims to = import ANY IPFIX Information Element (that will cover the particular = case in this document):http://www.ietf.org/mail-archive/web/sfc/current/msg04492.html<= /a> without consuming = the WG effort to edit/review/publish RFCs for each promising IPFIX = IEs.


There have been a number of responses = on the list highlighting the significant drawbacks of this proposal. = However, although I agree with those, I think I have not yet replied = enlist.

Here=E2=80= =99s my view.

The IPFIX Information Elements registry contains over = 450 entries. It also has data types, semantics, and units associated = with them. These are in support of a protocol for transmitting Traffic = Flow Information. Looking at the SFC Architecture at RFC 7665, the = Metadata is used for a completely different purpose. Yes, there is = intersection with some IPFIX fields. But there=E2=80=99s also = intersection with the IF-MIB.

First, IPFIX is not a superset of all = the information needed. Looking at the WG doc on mobility and DC, and = the various allocation drafts, not every fields is in IPFIX.
Second, not every IPFIX field is needed in SFC (certainly not = the 450+).

The = corollary of this is that there are a number of associated problems with = the proposal:
1. Does an SFC implementation need to = support all (ever growing) IPFIX IEs?
2. Do you = propose to specify profiles of IPFIX, which include a subset to be used? = That seems in practice more difficult than the direct = alternative.
3. Regarding fields not defined in = IPFIX, does SFC need to specify a new IPFIX IE, and specify how it would = be used with IPFIX?
4. What about newly defined = IPFIX fields after the publishing of the NSH documents? How are those = vetted for applicability to SFC?
5. What is SFC = needs a different data type for a field? 

In my opinion, all of this result in a = lot more work and uncertainty than actually defining what=E2=80=99s = needed.

I = expect some SFC/NSH use cases to use an ifIndex for example. This does = not imply that SFC need to import somehow the full IF-MIB.

Similarly, I expect = SFC/NSH can use specific fields or values from various places, when it = makes sense. I do not expect NSH needing to import all of = those.

In = summary, I believe this proposal is harmful to NSH on the above = technical grounds. As a general proposal, it seems to me like a cannon = to kill a fly.

I= expect SFC might need to define things like flow specifications, it = does not mean it ought to reuse the BGP Flow Spec registries, semantics, = and syntax.

That= said, as SFC defines things from a flow, I expect it will not re-invent = the wheel and re-use surgically.

Best,

=E2=80=94 = Carlos. 
= --Apple-Mail=_346F0F67-91C5-41A6-B5EF-165C4556F66C-- --Apple-Mail=_7CB76D42-C05B-47F6-AA85-F88B752F7D53 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 - http://gpgtools.org iQIcBAEBCAAGBQJXJ1miAAoJEIXgpQGOZny90coQALMXMFZyqEccz2pmaXO9NUxL k1TdDxzMKWTFx4tHJEdqj4OIjWMQudJ15YA5kWrFsml2lPfuQaN2e/1yYKdihISu 6sBFdaDYdm26Ie0JM0uzBQ39ENUOHUBfIwbn/MOD+7cTVQL7T9U1KA17WwBUSgtN gnd4jSNDjlGz5leF1rPQw5ZkdpDAAM+N2TkFcZdaPibyHuAvRUo8tPju1mGY0Eyg 0avXTapoRyVSQEKfCKi+eU4/tV66nUA/2Srh1SfgafreuRJHGgzN+n/VoZsV5aRJ g8Zg+28l71TtGVOH/BFkVPArS+2hcTZJpBFFqZ6KudwF8AZbNmaRwMMzIcXvGM9a 0srbGhKukdAwgL+z36Coyq+kiSPgLkKSk3bX7U5hbnTDI/Poi8V/6et/5uZBa8du BZuQ8uVj4ASy35XUNZPeVYT/REmox73IS/Hx35gVn1qImtfjNmEUydN5uYvZe+75 VScRPdN72UwyNinhAvy/k63zf7oBJHVyuzZvZViP8oqE4Ek4kvhXG71gpfFOEbBR b0dFR9oNNSA+8Wpnxz21OIHtBAKAIzMiqlzSwObs8pqNGPlYdpoJ3aVNS2MBgEZb C9iPgRmrMVE7wqEJi8yVsGT/wjbYo/N6bzktaepcC0uh4D2hKUk26im+kATrOC6k uNgF8z8HsD+L5kslwdgA =4sNp -----END PGP SIGNATURE----- --Apple-Mail=_7CB76D42-C05B-47F6-AA85-F88B752F7D53-- From nobody Mon May 2 06:52:43 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90821200A0; Mon, 2 May 2016 06:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 Fked_bUJA5q0; Mon, 2 May 2016 06:52:38 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04FFF12D0A9; Mon, 2 May 2016 06:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36940; q=dns/txt; s=iport; t=1462197158; x=1463406758; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2VhphJQQJN/rcWmEiUAtmDFFTeVm8ql3tNaxPF28O28=; b=aEKv3A35MRvZTwACbB0sqipcd99iE/+uQNOpkZix9KeY2FFOo6A/f2YU s4U4HT2fM/3SQgYNNmX2sxBBIxDeVffVkr5rB5R/C3sBCJJI0pM7W0o5H Y/eV92k5dtuA3BCUPAUw40GvSJHLcdeEwoK9PcI/z8BjwZ+gq7zWmK8p1 w=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAwCgWidX/4ENJK1dgmxMU30GuW4Og?= =?us-ascii?q?XIEFwEKhW4CgSk4FAEBAQEBAQFlHAuEQQEBAQMBAQEBGgZLCwULAgEIEQMBAgE?= =?us-ascii?q?gAQYDAgInCxQJCAIEDgUJBQ2IBwgOqQCQRAEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?Q0IhiGBdoJWhA8QAgE7FoJKK4IrBZMjhHEBgyeBZ22IHIFnhE2IXY8wAR4BQ4I?= =?us-ascii?q?FG4FLbAGIB38BAQE?= X-IronPort-AV: E=Sophos;i="5.24,567,1454976000"; d="asc'?scan'208,217";a="268719849" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 May 2016 13:52:36 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u42DqaKc011997 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 May 2016 13:52:36 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 May 2016 09:52:35 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Mon, 2 May 2016 09:52:35 -0400 From: "Carlos Pignataro (cpignata)" To: "mohamed.boucadair@orange.com" Thread-Topic: [sfc] Call for WG adoption of draft-penno-sfc-appid-03 Thread-Index: AQHRZQHOvGZf31kz6UifjJTvmDJQAZ+hr9aAgARTiaCAAGltAA== Date: Mon, 2 May 2016 13:52:35 +0000 Message-ID: <3501127B-E55B-4FA1-9A63-47D046371132@cisco.com> References: <787AE7BB302AE849A7480A190F8B933008D62994@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D62994@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.245.225] Content-Type: multipart/signed; boundary="Apple-Mail=_5569C10C-046A-4FE6-9C3E-92633F2BFF2B"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "draft-penno-sfc-appid@ietf.org" , "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-appid-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 13:52:41 -0000 --Apple-Mail=_5569C10C-046A-4FE6-9C3E-92633F2BFF2B Content-Type: multipart/alternative; boundary="Apple-Mail=_157EF706-FF09-49F7-94FE-0DFACF383818" --Apple-Mail=_157EF706-FF09-49F7-94FE-0DFACF383818 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Med, Thanks for taking the time to review and comment. Please find some = comments inline. > On May 2, 2016, at 7:58 AM, mohamed.boucadair@orange.com wrote: >=20 > Hi Jim, all, >=20 > I interpret this proposal as if it wants to inherit the IPFIX = Application information to be conveyed in an nsh header. I have some = issues with the rationale of this draft, not its goal per se. >=20 > I do not support this draft. I do think there are other design choices = that can be investigated by the WG to inherit existing IPFIX IEs without = writing a new RFC for it for EACH IE to be conveyed in an NSH header. I believe you are misunderstanding what draft-penno-sfc-appid-03 is = about. The goal is to convey application information in SFC Metadata. It = is not to inherit existing IPFIX IEs. Given this goal of conveying application information, we found one = specific syntax leveraging the Application Information structure from = IPFIX. I wanted to clarify the difference, as it is significance. If there are other design choices *to convey application identification* = (not to inherit existing fields from anywhere as a goal), we=E2=80=99d = love to hear them. This specific proposal compiles and runs. >=20 > For example, there is a more general proposal that aims to import ANY = IPFIX Information Element (that will cover the particular case in this = document):http://www.ietf.org/mail-archive/web/sfc/current/msg04492.html = without = consuming the WG effort to edit/review/publish RFCs for each promising = IPFIX IEs. >=20 I believe this will cause more headaches than solutions =E2=80=94 I = replied in a separate note. > Further, I have the following questions for the draft: >=20 > =C2=B7 Why reserving this proposal for MD#1? Because that is the minimal one to use. However, this is also defined = for MD-Type 2 at = https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01#page-7 (see =E2=80=9C= 5. Application ID=E2=80=9D) Do you suggest we should define MD-Type 2 in this draft as well? Happy = to do so if that=E2=80=99s useful. > =C2=B7 What means the following headers? > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 3 | 0 | 161 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Network Shared Context | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Service Platform Context | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Service Shared Context | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Figure 2: Example of Metadata Including the SNMP Application > Identification >=20 It is an example of metadata including the SNMP application = identification. Best, =E2=80=94 Carlos. > Cheers, > Med >=20 > De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard = (jguichar) > Envoy=C3=A9 : vendredi 29 avril 2016 18:31 > =C3=80 : sfc@ietf.org > Objet : [sfc] Call for WG adoption of draft-penno-sfc-appid-03 >=20 > Dear WG: >=20 > We did not receive many responses for this call for adoption and = therefore would like to re-invite people to post their thoughts on = adopting this document into the SFC WG. The call for adoption will run = for a further 2 weeks ending 6/13/2016. >=20 > Thanks! >=20 > SFC Chairs >=20 > From: Jim Guichard > > Date: Thursday, February 11, 2016 at 3:24 PM > To: "sfc@ietf.org " > > Subject: Call for WG adoption of draft-penno-sfc-appid-03 >=20 > Dear WG: >=20 > This email serves as a call for WG adoption of = draft-penno-sfc-appid-03 as a WG document. The call for adoption will = run for 2 weeks ending 2/25/2016. >=20 > Please note that this is a call for adoption, and not a last call for = content of the document. Adopting a WG document simply means that the WG = will focus its efforts on that particular draft going forward, and use = that document for resolving open issues and documenting the WG=E2=80=99s = decisions. >=20 > Please indicate whether you support adoption for not, and if not why. = Issues you have with the current document itself can also be raised, but = they should be raised in the context of what should be changed in the = document going forward, rather than a pre-condition for adoption. >=20 > Finally, now is also a good time to poll for knowledge of any IPR that = applies to this draft, in line with the IPR disclosure obligations for = WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). = If you are listed as a document author please respond to this email (to = the chairs) whether or not you are aware of any relevant IPR. >=20 > Thanks! >=20 > SFC Chairs > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail=_157EF706-FF09-49F7-94FE-0DFACF383818 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear Med,

Thanks for taking the time to review and comment. Please find = some comments inline.

On May 2, 2016, at 7:58 AM, mohamed.boucadair@orange.com wrote:

Hi = Jim, all,
 
I interpret this proposal = as if it wants to inherit the IPFIX Application information to be = conveyed in an nsh header. I have some issues with the rationale of this = draft, not its goal per se.
 
I do not support this draft. I do think there = are other design choices that can be investigated by the WG to inherit = existing IPFIX IEs without writing a new RFC for it for EACH IE to be = conveyed in an NSH header. 

I believe you are = misunderstanding what draft-penno-sfc-appid-03 is about. The goal is to = convey application information in SFC Metadata. It is not to inherit = existing IPFIX IEs.

Given this goal of conveying application information, we = found one specific syntax leveraging the Application Information = structure from IPFIX.

I wanted to clarify the difference, as it is = significance.

If= there are other design choices *to convey application identification* = (not to inherit existing fields from anywhere as a goal), we=E2=80=99d = love to hear them. 

This specific proposal compiles and runs.

 
For example, there is a more = general proposal that aims to import ANY IPFIX Information Element (that = will cover the particular case in this document):http://www.ietf.org/mail-archive/web/sfc/current/msg04492.html<= /a> without consuming = the WG effort to edit/review/publish RFCs for each promising IPFIX = IEs.


Further,= I have the following questions for the draft:
 
=C2=B7         Why reserving this proposal for = MD#1?



=C2=B7         What means the following headers?
      = 0            &= nbsp;      = 1            &= nbsp;      = 2            &= nbsp;      3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 = 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     = |       = 3       = |        = 0      = |            &= nbsp; = 161            = ;  |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     = |            =       Network Shared = Context           &= nbsp;           |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     = |            &= nbsp;     Service Platform = Context           &= nbsp;         |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     = |            &= nbsp;     Service Shared = Context           &= nbsp;           |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
       Figure 2: Example of = Metadata Including the SNMP Application
          &nb= sp;            = ;       Identification
 


It is an example of = metadata including the SNMP application identification.

Best,

=E2=80=94 = Carlos.

Cheers,
Med
 
De : sfc [mailto:sfc-bounces@ietf.org] De la part = de Jim Guichard = (jguichar)
Envoy=C3=A9 : vendredi 29 avril 2016 = 18:31
=C3=80 : sfc@ietf.org
Objet : [sfc] Call for WG adoption = of draft-penno-sfc-appid-03
 
Dear WG:
 
We did not receive many = responses for this call for adoption and therefore would like to = re-invite people to post their thoughts on adopting this document into = the SFC WG. The call for adoption will run for a further 2 weeks ending = 6/13/2016. 
 
Thanks!
 
SFC Chairs
 
From: Jim Guichard <jguichar@cisco.com>
Date: Thursday, February 11, = 2016 at 3:24 PM
To: "sfc@ietf.org" <sfc@ietf.org>
Subject: Call for WG adoption of = draft-penno-sfc-appid-03
 
Dear WG:
 
This email serves as a call for WG adoption of = draft-penno-sfc-appid-03 as a WG document. The call for adoption will = run for 2 weeks ending 2/25/2016.
 
Please note = that this is a call for adoption, and not a last call for content of the = document. Adopting a WG document simply means that the WG will focus its = efforts on that particular draft going forward, and use that document = for resolving open issues and documenting the WG=E2=80=99s = decisions.
 
Please = indicate whether you support adoption for not, and if not why. Issues = you have with the current document itself can also be raised, but they = should be raised in the context of what should be changed in the = document going forward, rather than a pre-condition for = adoption. 
 
Finally, now = is also a good time to poll for knowledge of any IPR that applies to = this draft, in line with the IPR disclosure obligations for WG = participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If = you are listed as a document author please respond to this email (to the = chairs) whether or not you are aware of any relevant IPR.
 
Thanks!
 
SFC Chairs
_______________________________________________
sfc mailing = list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

= --Apple-Mail=_157EF706-FF09-49F7-94FE-0DFACF383818-- --Apple-Mail=_5569C10C-046A-4FE6-9C3E-92633F2BFF2B 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 - http://gpgtools.org iQIcBAEBCAAGBQJXJ1uiAAoJEIXgpQGOZny9boEP/i/GeHTyZ3vxeMLYDvOJXhVw GtI7y+BNv3xsTc5fabjbv5ucny6+o3cgMKi6DkfVw24xVvKp7yae9TvH6sRKY+2C 8oknvIrkXyYAPD66PFIrTu25PjySvFs+dy8M1WkrpZy+a/TB0XSoJTF38eikMmNt dB8+Ke5T8w81UJ59TK+QUshN8g+oqHI0ssNVmDdf5iR4aPKs5FQg4dqsDayscZBW RJqJ4eZwfK2vsZnBY8Sq4PQ1GbeOwsZk3qdSsMkJ2vHfy4wq5xPsXc+HrUououdd R8dbfJMwimNbHUSlrV0CwzbLBdCcE/r+Cvb7lkVXHtT5K1smXL33T4hPhD7DPOOr gemeIoNkn0JtHi7pAJRHSJN2XnoFPyuo6pUqvGiHKnP4eUyVQqCbshmFbYtXFRoS BytHfBEf7CnYEzqZMjysmhA3mc+2tuzrLzyXOZdjCiCbaoQ33KdZT73KqJPVbdxF 7c4xznUFZEqzeqfSKSp3BhPbceQAwu0yyEV3dCGebBg+J3Nq8LskBXLo3IvtaJet RsvhjEliI7RZcfPbILGV7IpU5MeJJT9BEpeTxwX8eMXtDOudhu20BmRZa5DAFCNn j1SAJFccFx+P478kxHwhQhmDUkrdxGxib3+m72VgGC/ucdecbAtZN3qFTl+iH/6i Q/EU5059+RGmf0ILbiWT =BpS7 -----END PGP SIGNATURE----- --Apple-Mail=_5569C10C-046A-4FE6-9C3E-92633F2BFF2B-- From nobody Mon May 2 07:24:38 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A286E12D0AD for ; Mon, 2 May 2016 07:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 XgOzrc7lbvWE for ; Mon, 2 May 2016 07:24:34 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8772A12B049 for ; Mon, 2 May 2016 07:24:33 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 45E91C07B9; Mon, 2 May 2016 16:24:32 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 11DFC1A005B; Mon, 2 May 2016 16:24:32 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0279.002; Mon, 2 May 2016 16:24:31 +0200 From: To: "Carlos Pignataro (cpignata)" Thread-Topic: Reuse the IPFIX registry in NSH Thread-Index: AQHRpHiwIVL3ANO/xESPP/MD2IMNP5+lqezA Date: Mon, 2 May 2016 14:24:31 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D62BEB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D62994@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2D398770-C83E-48FE-BBE9-574A58871700@cisco.com> In-Reply-To: <2D398770-C83E-48FE-BBE9-574A58871700@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008D62BEBOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] Reuse the IPFIX registry in NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 14:24:36 -0000 --_000_787AE7BB302AE849A7480A190F8B933008D62BEBOPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2FybG9zLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDog Q2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIFttYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tXQ0K RW52b3nDqSA6IGx1bmRpIDIgbWFpIDIwMTYgMTU6NDQNCsOAIDogQk9VQ0FEQUlSIE1vaGFtZWQg SU1UL09MTg0KQ2MgOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgc2ZjQGlldGYub3JnDQpPYmpl dCA6IFJldXNlIHRoZSBJUEZJWCByZWdpc3RyeSBpbiBOU0gNCg0KRGVhciBNZWQsDQoNClNpbmNl IHlvdSBhcmUgbWFraW5nIGEgZ2VuZXJpYyBjb21tZW50IG91dHNpZGUgdGhlIHNjb3BlIG9mIGRy YWZ0LXBlbm5vLXNmYy1hcHBpZC0wMywNCltNZWRdIFBlcmhhcHMgSSBtaXN1bmRlcnN0b29kIHRo ZSBwcm9wb3NhbCwgYnV0IFJlaW5hbGRv4oCZcyBkcmFmdCBzYXlzIHRoZSBmb2xsb3dpbmc6DQoN CiAgIFRoaXMgZG9jdW1lbnQgcHVycG9zZXMgdGhlIHVzZSBvZiBJUEZJWCBbUkZDNzAxMTxodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzAxMT5dIGFwcGxpY2F0aW9uDQogICBpbmZvcm1h dGlvbiB0byBiZSBjYXJyaWVkIGluIHRoZSBOU0ggY29udGV4dCBtZXRhZGF0YSBvZiBhIE1EVHlw ZS0xDQogICBwYWNrZXQuDQoNClNvLCBJIGRvbuKAmXQgdGhpbmsgaXQgaXMgb3V0c2lkZSB0aGUg c2NvcGUgb2YgdGhhdCBkaXNjdXNzaW9uLiBNeSBwb3NpdGlvbiBpcyBzaW1wbGU6IGluc3RlYWQg b2YgbG9va2luZyBhdCBhbiBpbmRpdmlkdWFsIHByb3Bvc2FsICh0aGF0IG1heSBoYXZlIGl0cyBt ZXJpdCksIHdoYXQgaWYgd2UgY29uc2lkZXIgYW4gYXBwcm9hY2ggdGhhdCBkb2VzIG5vdCByZXF1 aXJlIHRoZSBpbnZvbHZlbWVudCBvZiB0aGUgV0cgdG8gcmV1c2VkIGFub3RoZXIgSVBGSVggSUUu DQoNCkkgdGhvdWdodCBpdCBhcHByb3ByaWF0ZSB0byBleHRyYWN0IHRoYXQgY29tbWVudCwgYW5k IHJlcGx5IHRvIGl0IHVuZGVyIHNlcGFyYXRlIGNvdmVyICh1cGRhdGluZyBhbHNvIHRoZSBTdWJq ZWN0IGxpbmUpDQpbTWVkXSBJIGRpc2FncmVlIHRoaXMgaXMgb3V0IG9mIHNjb3BlIG9mIHRoYXQg ZGlzY3Vzc2lvbiwgYnV0IEnigJltIG9wZW4gdG8gZGlzY3VzcyB3aGF0ZXZlciB0aGUgdGl0bGUg b2YgdGhyZWFkIGlzLg0KDQpPbiBNYXkgMiwgMjAxNiwgYXQgNzo1OCBBTSwgbW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4gd3Jv dGU6DQoNCkZvciBleGFtcGxlLCB0aGVyZSBpcyBhIG1vcmUgZ2VuZXJhbCBwcm9wb3NhbCB0aGF0 IGFpbXMgdG8gaW1wb3J0IEFOWSBJUEZJWCBJbmZvcm1hdGlvbiBFbGVtZW50ICh0aGF0IHdpbGwg Y292ZXIgdGhlIHBhcnRpY3VsYXIgY2FzZSBpbiB0aGlzIGRvY3VtZW50KTpodHRwOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2ZjL2N1cnJlbnQvbXNnMDQ0OTIuaHRtbCB3aXRob3V0 IGNvbnN1bWluZyB0aGUgV0cgZWZmb3J0IHRvIGVkaXQvcmV2aWV3L3B1Ymxpc2ggUkZDcyBmb3Ig ZWFjaCBwcm9taXNpbmcgSVBGSVggSUVzLg0KDQoNClRoZXJlIGhhdmUgYmVlbiBhIG51bWJlciBv ZiByZXNwb25zZXMgb24gdGhlIGxpc3QgaGlnaGxpZ2h0aW5nIHRoZSBzaWduaWZpY2FudCBkcmF3 YmFja3Mgb2YgdGhpcyBwcm9wb3NhbC4gSG93ZXZlciwgYWx0aG91Z2ggSSBhZ3JlZSB3aXRoIHRo b3NlLCBJIHRoaW5rIEkgaGF2ZSBub3QgeWV0IHJlcGxpZWQgZW5saXN0Lg0KDQpIZXJl4oCZcyBt eSB2aWV3Lg0KDQpUaGUgSVBGSVggSW5mb3JtYXRpb24gRWxlbWVudHMgcmVnaXN0cnkgY29udGFp bnMgb3ZlciA0NTAgZW50cmllcy4NCltNZWRdIFRoaXMgaXMgYW4gYXJndW1lbnQgdGhhdCBhIHBp ZWNlIG9mIGluZm9ybWF0aW9uIHRoYXQgaXMgbmVlZGVkIGluIHRoZSBjb250ZXh0IG9mIFNGQyBp cyBsaWtlbHkgdG8gYmUgZGVmaW5lZCBpbiB0aGF0IHJpY2ggbGlzdC4NCg0KSXQgYWxzbyBoYXMg ZGF0YSB0eXBlcywgc2VtYW50aWNzLCBhbmQgdW5pdHMgYXNzb2NpYXRlZCB3aXRoIHRoZW0uDQpb TWVkXSBJIGRvbuKAmXQgc2VlIGFueSBpc3N1ZSB0aGVyZS4NCg0KVGhlc2UgYXJlIGluIHN1cHBv cnQgb2YgYSBwcm90b2NvbCBmb3IgdHJhbnNtaXR0aW5nIFRyYWZmaWMgRmxvdyBJbmZvcm1hdGlv bi4NCltNZWRdIEkgZG9u4oCZdCBzZWUgdGhlIGxpbmsgd2l0aCB0aGUgcHJvcG9zYWwgb24gdGhl IHRhYmxlLiBUaGlzIHBhcnQgaXMgbm90IG5lZWRlZCBhdCBhbGwhDQoNCkxvb2tpbmcgYXQgdGhl IFNGQyBBcmNoaXRlY3R1cmUgYXQgUkZDIDc2NjUsIHRoZSBNZXRhZGF0YSBpcyB1c2VkIGZvciBh IGNvbXBsZXRlbHkgZGlmZmVyZW50IHB1cnBvc2UuDQpbTWVkXSBUaGUgSVBGSVggcHJvcG9zYWwg aXMgYWJvdXQgaWRlbnRpZnlpbmcgYSBwaWVjZSBvZiBpbmZvcm1hdGlvbiBOT1QgYWJvdXQgaG93 IHRvIHVzZSBpdC4NCg0KWWVzLCB0aGVyZSBpcyBpbnRlcnNlY3Rpb24gd2l0aCBzb21lIElQRklY IGZpZWxkcy4gQnV0IHRoZXJl4oCZcyBhbHNvIGludGVyc2VjdGlvbiB3aXRoIHRoZSBJRi1NSUIu DQpbTWVkXSBJIHdvbuKAmXQgY29tbWVudCB0aGlzIHBhcnQgYmVjYXVzZSBpdCB0cmllcyB0byBt aXggdGhpbmdzLg0KDQpGaXJzdCwgSVBGSVggaXMgbm90IGEgc3VwZXJzZXQgb2YgYWxsIHRoZSBp bmZvcm1hdGlvbiBuZWVkZWQuDQpbTWVkXSBBZ3JlZS4gSSBuZXZlciBjbGFpbWVkIHRoYXQhDQoN Ckxvb2tpbmcgYXQgdGhlIFdHIGRvYyBvbiBtb2JpbGl0eSBhbmQgREMsIGFuZCB0aGUgdmFyaW91 cyBhbGxvY2F0aW9uIGRyYWZ0cywgbm90IGV2ZXJ5IGZpZWxkcyBpcyBpbiBJUEZJWC4NCltNZWRd IFRoZSBwcm9wb3NhbCBpcyBub3QgYWJvdXQgcmV1c2luZyBhbGwgdGhlIGZpZWxkcyBpbiBJUEZJ WCwgYnV0IHRvIHJldXNlIHRoZSAqKiBJUEZJWCBJRXMgKiogcmVnaXN0cnkuDQoNClNlY29uZCwg bm90IGV2ZXJ5IElQRklYIGZpZWxkIGlzIG5lZWRlZCBpbiBTRkMgKGNlcnRhaW5seSBub3QgdGhl IDQ1MCspLg0KW01lZF0gSSBuZXZlciBjbGFpbWVkIHRoYXQsIHRvbyENCg0KVGhlIGNvcm9sbGFy eSBvZiB0aGlzIGlzIHRoYXQgdGhlcmUgYXJlIGEgbnVtYmVyIG9mIGFzc29jaWF0ZWQgcHJvYmxl bXMgd2l0aCB0aGUgcHJvcG9zYWw6DQoxLiBEb2VzIGFuIFNGQyBpbXBsZW1lbnRhdGlvbiBuZWVk IHRvIHN1cHBvcnQgYWxsIChldmVyIGdyb3dpbmcpIElQRklYIElFcz8NCk1lZDogIFRoZXJlIGlz IG5vIG1hbmRhdG9yeS10by1zdXBwb3J0IG1ldGFkYXRhIGFzIGZhciBhcyBJIGtub3cuIFRoaXMg c2hvdWxkIGJlIHBhcnQgb2YgYW4gUkZQIGFuZCBkZXBsb3ltZW50IGRlY2lzaW9uLiAgVGhlIHF1 ZXN0aW9uIHlvdSByYWlzZWQgYXBwbGllcyBmb3IgYWxsIFRMVnMuDQoNCjIuIERvIHlvdSBwcm9w b3NlIHRvIHNwZWNpZnkgcHJvZmlsZXMgb2YgSVBGSVgsIHdoaWNoIGluY2x1ZGUgYSBzdWJzZXQg dG8gYmUgdXNlZD8gVGhhdCBzZWVtcyBpbiBwcmFjdGljZSBtb3JlIGRpZmZpY3VsdCB0aGFuIHRo ZSBkaXJlY3QgYWx0ZXJuYXRpdmUuDQpbTWVkXSBOby4gSeKAmW0gcmVwcm9kdWNpbmcgaGVyZSB3 aGF0IEkgYW5zd2VyZWQgaW4gYW5vdGhlciB0aHJlYWQ6IFRoZSBwcm9wb3NhbCBpcyBub3QgYWJv dXQgcmV1c2luZyB0aGUgSVBGSVggZm9ybWF0LCBidXQgSVBGSVggcmVnaXN0cnkuIFRoZSBUTFYg Zm9ybWF0IGFzIGRlc2NyaWJlZCBpbiB0aGUgbnNoIGRyYWZ0IHdpbGwgYmUgdXNlZC4gV2l0aCB0 aGUgYXBwcm9hY2ggSeKAmW0gcHJvcG9zaW5nIGhlcmU6DQrigKIgICBpZiB5b3UgbmVlZCB0byBp bmNsdWRlIGEgRmxvd0lELCB5b3UganVzdCBuZWVkIHRvIHNldCB0aGUgcmVnaXN0cnkgSUQgdG8g MSwgYW5kIHRoZSB0eXBlIHRvIDE0Lg0K4oCiICAgSWYgeW91IG5lZWQgdG8gaW5jbHVkZSBhIHZs YW5kSUQsIHlvdSBqdXN0IG5lZWQgdG8gc2V0IHRoZSByZWdpc3RyeSBJRCB0byAxLCBhbmQgdGhl IHR5cGUgdG8gNTguDQrigKIgICAuLg0KVGhpcyBpcyBhbG1vc3QgY2xvc2UgdG8gd2hhdCBSZWlu YWxkb+KAmXMgZHJhZnQgaXMgZG9pbmcgZXhjZXB0IHRoZSBhdXRob3JzIHVzZSBhIG1hbmRhdG9y eSBmaWVsZC4NCg0KDQozLiBSZWdhcmRpbmcgZmllbGRzIG5vdCBkZWZpbmVkIGluIElQRklYLCBk b2VzIFNGQyBuZWVkIHRvIHNwZWNpZnkgYSBuZXcgSVBGSVggSUUsIGFuZCBzcGVjaWZ5IGhvdyBp dCB3b3VsZCBiZSB1c2VkIHdpdGggSVBGSVg/DQpbTWVkXSBOby4NCg0KNC4gV2hhdCBhYm91dCBu ZXdseSBkZWZpbmVkIElQRklYIGZpZWxkcyBhZnRlciB0aGUgcHVibGlzaGluZyBvZiB0aGUgTlNI IGRvY3VtZW50cz8NCltNZWRdIEkgZG9u4oCZdCBzZWUgYW55IGlzc3VlIHRoZXJlIGF0IGFsbCEg V2UgZG9u4oCZdCBjYXJlIGFib3V0IElQRklYIEZJRUxEUywgYnV0IGFib3V0IHRoZSBpbmZvcm1h dGlvbiBlbGVtZW50cyBhbmQgdGhlaXIgY29kZSBwb2ludHMuIEhlcmUgaXMgdGhlIHByb3Bvc2Fs IEkgc2hhcmVkIG9uIHRoZSBsaXN0LCBmd2l3Og0KDQoNCj09UFJPUE9TQUw9PT09DQoNCg0KDQpC YXNlIHZlcnNpb24NCg0KICAgICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAg ICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQoNCiAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCg0KICAgICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsNCg0KICAgICAgfENsYXNzICB8ICAgICAgICAgICAgVHlwZSAgICAgICAgICAgICAgIHwg RkxBR1MgfCAgICAgTGVuZ3RoICAgIHwNCg0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KICAgICAgLy8gICAg ICAgICAgICAgICAgICAgICAgICAgICBEYXRhIChWYXJpYWJsZSkgICAgICAgICAgICAgICAgICAg IC8vDQoNCiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rDQoNCg0KDQogICAgICBUaGUgZGVzY3JpcHRpb24gb2YgdGhl IGZpZWxkcyBpcyBhcyBmb2xsb3dzOg0KDQoNCg0KICAgICAgQ2xhc3M6ICBJbiBvcmRlciB0byBm b3N0ZXIgc2VydmljZSBpbm5vdmF0aW9uLCB0aGlzIGZpZWxkDQoNCiAgICAgICAgIGFsbG93cyB0 byBpbmhlcml0IGZyb20gZXhpc3RpbmcgY29kZSBwb2ludCByZWdpc3RyaWVzIHRoYXQgYXJlDQoN CiAgICAgICAgIGxpa2VseSB0byBiZSB1c2VmdWwgaW4gYSBTRkMgY29udGV4dC4gIFRoZSBmb2xs b3dpbmcgdmFsdWVzIGFyZQ0KDQogICAgICAgICByZXNlcnZlZCBieSB0aGlzIHNwZWNpZmljYXRp b246DQoNCiAgICAgICAgIDA6ICBTZWUgSUFOQSBzZWN0aW9uLg0KDQogICAgICAgICAxOiAgSVBG SVggW0lQRklYXS4NCg0KDQoNCiAgICAgIFR5cGU6ICBJbmRpY2F0ZXMgdGhlIGNvZGUgcG9pbnQg b2YgdGhlIGNvbnRleHQgZWxlbWVudC4gIElmDQoNCiAgICAgICAgICJDbGFzcyIgZmllbGQgaXMg bm9uLW51bGwsIHRoZSBpbnRlcnByZXRhdGlvbiBvZiB0aGlzIGZpZWxkIE1VU1QNCg0KICAgICAg ICAgY29uZm9ybSB0byB0aGUgb25lIGRlZmluZWQgZm9yIHRoYXQgc3BlY2lmaWMgY2xhc3MgcmVn aXN0cnkuIFNlZSBJQU5BIHNlY3Rpb24uDQo9PT0NCg0KSG93IGFyZSB0aG9zZSB2ZXR0ZWQgZm9y IGFwcGxpY2FiaWxpdHkgdG8gU0ZDPw0KW01lZF0gSSBkb27igJl0IHVuZGVyc3RhbmQgdGhlIHBv aW50IGhlcmUuIENhbiB5b3UgcGxlYXNlIGV4cGxpY2l0IHlvdXIgcG9pbnQ/IFRoYW5rcy4NCg0K NS4gV2hhdCBpcyBTRkMgbmVlZHMgYSBkaWZmZXJlbnQgZGF0YSB0eXBlIGZvciBhIGZpZWxkPw0K W01lZF0gVGhpcyBjYW4gYmUgZGVmaW5lZCBpbiBhIGRlZGljYXRlZCBUTFYgZG9jdW1lbnQuDQoN Cg0KSW4gbXkgb3BpbmlvbiwgYWxsIG9mIHRoaXMgcmVzdWx0IGluIGEgbG90IG1vcmUgd29yayBh bmQgdW5jZXJ0YWludHkgdGhhbiBhY3R1YWxseSBkZWZpbmluZyB3aGF04oCZcyBuZWVkZWQuDQpb TWVkXSBJ4oCZbSBhZnJhaWQgdGhpcyBpcyBwdXJlIHNwZWN1bGF0aW9uLiBJIHByb3ZpZGVkIHRo ZSBleGFtcGxlIG9mIHZsYW5pZCwgZmxvd2lkLiBJIGNhbiBwcm92aWRlIGV4YW1wbGUgYWJvdXQg dGhlIHNvdXJjZSBJUCBhZGRyZXNzLCBzb3VyY2UgcG9ydCwgcHJvdG9jb2wsIGV0Yy4NCg0KSSBl eHBlY3Qgc29tZSBTRkMvTlNIIHVzZSBjYXNlcyB0byB1c2UgYW4gaWZJbmRleCBmb3IgZXhhbXBs ZS4gVGhpcyBkb2VzIG5vdCBpbXBseSB0aGF0IFNGQyBuZWVkIHRvIGltcG9ydCBzb21laG93IHRo ZSBmdWxsIElGLU1JQi4NCltNZWRdIEkgZG9u4oCZdCBzZWUgdGhlIHBhcmFsbGVsIGhlcmUuDQoN ClNpbWlsYXJseSwgSSBleHBlY3QgU0ZDL05TSCBjYW4gdXNlIHNwZWNpZmljIGZpZWxkcyBvciB2 YWx1ZXMgZnJvbSB2YXJpb3VzIHBsYWNlcywgd2hlbiBpdCBtYWtlcyBzZW5zZS4NCltNZWRdIFRo aXMgaXMgbm90IHBhcnQgb2YgdGhlIHByb3Bvc2FsIQ0KDQpJIGRvIG5vdCBleHBlY3QgTlNIIG5l ZWRpbmcgdG8gaW1wb3J0IGFsbCBvZiB0aG9zZS4NCg0KSW4gc3VtbWFyeSwgSSBiZWxpZXZlIHRo aXMgcHJvcG9zYWwgaXMgaGFybWZ1bCB0byBOU0ggb24gdGhlIGFib3ZlIHRlY2huaWNhbCBncm91 bmRzLg0KW01lZF0gTXkgaW5pdGlhbCBvYmplY3RpdmUgaXMgdG8gZm9zdGVyIHNlcnZpY2UgaW5u b3ZhdGlvbiB3aXRob3V0IHdhaXRpbmcgbG9uZyBjeWNsZXMgdG8gc3RhbmRhcmRpemUgYSBzaW5n bGUgY29kZSBwb2ludC4NCg0KQXMgYSBnZW5lcmFsIHByb3Bvc2FsLCBpdCBzZWVtcyB0byBtZSBs aWtlIGEgY2Fubm9uIHRvIGtpbGwgYSBmbHkuDQpbTWVkXSBJIGhvcGUgdGhpbmdzIGFyZSBtb3Jl IGNsZWFyIG5vdyBhZnRlciBteSByZXNwb25zZXMuDQoNCkkgZXhwZWN0IFNGQyBtaWdodCBuZWVk IHRvIGRlZmluZSB0aGluZ3MgbGlrZSBmbG93IHNwZWNpZmljYXRpb25zLCBpdCBkb2VzIG5vdCBt ZWFuIGl0IG91Z2h0IHRvIHJldXNlIHRoZSBCR1AgRmxvdyBTcGVjIHJlZ2lzdHJpZXMsIHNlbWFu dGljcywgYW5kIHN5bnRheC4NCg0KVGhhdCBzYWlkLCBhcyBTRkMgZGVmaW5lcyB0aGluZ3MgZnJv bSBhIGZsb3csIEkgZXhwZWN0IGl0IHdpbGwgbm90IHJlLWludmVudCB0aGUgd2hlZWwgYW5kIHJl LXVzZSBzdXJnaWNhbGx5Lg0KDQpCZXN0LA0KDQrigJQgQ2FybG9zLg0K --_000_787AE7BB302AE849A7480A190F8B933008D62BEBOPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1Bs YWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IlRleHRlIGJydXQgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTQuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7DQoJY29sb3I6YmxhY2s7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KcHJlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhU TUwgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdy YXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCglt YXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsInNlcmlmIjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFt ZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xv cjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bh bi5QcmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0 w6kgSFRNTCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLlRleHRlYnJ1dENh cg0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUgYnJ1dCBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgYnJ1dCI7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SGkgQ2FybG9zLA0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj5QbGVhc2Ugc2VlIGlubGluZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+TWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBD YXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgW21haWx0bzpjcGlnbmF0YUBjaXNjby5jb21dDQo8 YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbHVuZGkgMiBtYWkgMjAxNiAxNTo0NDxicj4NCjxi PsOAJm5ic3A7OjwvYj4gQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjxicj4NCjxiPkNjJm5ic3A7 OjwvYj4gSmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IHNmY0BpZXRmLm9yZzxicj4NCjxiPk9iamV0 Jm5ic3A7OjwvYj4gUmV1c2UgdGhlIElQRklYIHJlZ2lzdHJ5IGluIE5TSDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgTWVkLDxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2luY2UgeW91IGFyZSBtYWtpbmcgYSBn ZW5lcmljIGNvbW1lbnQgb3V0c2lkZSB0aGUgc2NvcGUgb2YmbmJzcDtkcmFmdC1wZW5uby1zZmMt YXBwaWQtMDMsPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PltNZWRdIFBlcmhhcHMgSSBtaXN1bmRlcnN0b29kIHRoZSBwcm9wb3NhbCwgYnV0IFJlaW5hbGRv 4oCZcyBkcmFmdCBzYXlzIHRoZSBmb2xsb3dpbmc6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IHB1cnBvc2VzIHRoZSB1c2Ug b2YgSVBGSVggWzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzcwMTEiIHRpdGxlPSImcXVvdDtTcGVjaWZpY2F0aW9uIG9mIHRoZSBJUCBGbG93 IEluZm9ybWF0aW9uIEV4cG9ydCAoSVBGSVgpIFByb3RvY29sIGZvciB0aGUgRXhjaGFuZ2Ugb2Yg RmxvdyBJbmZvcm1hdGlvbiZxdW90OyI+PHNwYW4gbGFuZz0iRU4tVVMiPlJGQzcwMTE8L3NwYW4+ PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPl0NCiBhcHBsaWNhdGlvbjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7IGluZm9ybWF0aW9uIHRvIGJlIGNhcnJpZWQgaW4gdGhlIE5TSCBjb250 ZXh0IG1ldGFkYXRhIG9mIGEgTURUeXBlLTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBwYWNrZXQu DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+U28s IEkgZG9u4oCZdCB0aGluayBpdCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGF0IGRpc2N1c3Np b24uIE15IHBvc2l0aW9uIGlzIHNpbXBsZTogaW5zdGVhZCBvZiBsb29raW5nIGF0IGFuIGluZGl2 aWR1YWwgcHJvcG9zYWwgKHRoYXQgbWF5IGhhdmUgaXRzIG1lcml0KSwNCiB3aGF0IGlmIHdlIGNv bnNpZGVyIGFuIGFwcHJvYWNoIHRoYXQgZG9lcyBub3QgcmVxdWlyZSB0aGUgaW52b2x2ZW1lbnQg b2YgdGhlIFdHIHRvIHJldXNlZCBhbm90aGVyIElQRklYIElFLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPkkgdGhvdWdodCBpdCBhcHByb3ByaWF0ZSB0byBleHRyYWN0IHRoYXQg Y29tbWVudCwgYW5kIHJlcGx5IHRvIGl0IHVuZGVyIHNlcGFyYXRlIGNvdmVyICh1cGRhdGluZyBh bHNvIHRoZSBTdWJqZWN0IGxpbmUpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBJIGRpc2Fn cmVlIHRoaXMgaXMgb3V0IG9mIHNjb3BlIG9mIHRoYXQgZGlzY3Vzc2lvbiwgYnV0IEnigJltIG9w ZW4gdG8gZGlzY3VzcyB3aGF0ZXZlciB0aGUgdGl0bGUgb2YgdGhyZWFkIGlzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTWF5IDIsIDIwMTYsIGF0IDc6NTggQU0sIDxhIGhyZWY9 Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj4NCm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb208L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Gb3IgZXhhbXBsZSwgdGhlcmUgaXMg YSBtb3JlIGdlbmVyYWwgcHJvcG9zYWwgdGhhdCBhaW1zIHRvIGltcG9ydCBBTlkgSVBGSVggSW5m b3JtYXRpb24gRWxlbWVudCAodGhhdCB3aWxsIGNvdmVyIHRoZSBwYXJ0aWN1bGFyIGNhc2UgaW4g dGhpcyBkb2N1bWVudCk6PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL3NmYy9jdXJyZW50L21zZzA0NDkyLmh0bWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zZmMvY3VycmVudC9tc2cwNDQ5 Mi5odG1sPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+d2l0aG91dA0KIGNvbnN1bWluZyB0aGUgV0cgZWZmb3J0IHRvIGVkaXQvcmV2aWV3 L3B1Ymxpc2ggUkZDcyBmb3IgZWFjaCBwcm9taXNpbmcgSVBGSVggSUVzLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGVyZSBoYXZlIGJlZW4gYSBudW1iZXIgb2YgcmVzcG9uc2VzIG9uIHRoZSBsaXN0IGhpZ2hs aWdodGluZyB0aGUgc2lnbmlmaWNhbnQgZHJhd2JhY2tzIG9mIHRoaXMgcHJvcG9zYWwuIEhvd2V2 ZXIsIGFsdGhvdWdoIEkgYWdyZWUgd2l0aCB0aG9zZSwgSSB0aGluayBJIGhhdmUgbm90IHlldCBy ZXBsaWVkIGVubGlzdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SGVyZeKAmXMgbXkgdmlldy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSZuYnNwO0lQ RklYIEluZm9ybWF0aW9uIEVsZW1lbnRzIHJlZ2lzdHJ5IGNvbnRhaW5zIG92ZXIgNDUwIGVudHJp ZXMuPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij5bTWVkXSBUaGlzIGlzIGFuIGFyZ3VtZW50IHRoYXQgYSBwaWVjZSBvZiBpbmZvcm1hdGlvbiB0 aGF0IGlzIG5lZWRlZCBpbiB0aGUgY29udGV4dCBvZiBTRkMgaXMgbGlrZWx5IHRvIGJlIGRlZmlu ZWQgaW4gdGhhdCByaWNoIGxpc3QuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5JdCBhbHNvIGhhcyBkYXRhIHR5cGVzLCBzZW1hbnRpY3MsIGFuZCB1bml0cyBhc3NvY2lhdGVk IHdpdGggdGhlbS48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPltNZWRdIEkgZG9u4oCZdCBzZWUgYW55IGlzc3VlIHRoZXJlLg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlc2UgYXJlIGluIHN1cHBvcnQgb2YgYSBwcm90 b2NvbCBmb3IgdHJhbnNtaXR0aW5nIFRyYWZmaWMgRmxvdyBJbmZvcm1hdGlvbi48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIEkgZG9u 4oCZdCBzZWUgdGhlIGxpbmsgd2l0aCB0aGUgcHJvcG9zYWwgb24gdGhlIHRhYmxlLiBUaGlzIHBh cnQgaXMgbm90IG5lZWRlZCBhdCBhbGwhDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5Mb29raW5nIGF0IHRoZSBTRkMgQXJjaGl0ZWN0dXJlIGF0IFJGQyA3NjY1LCB0aGUgTWV0 YWRhdGEgaXMgdXNlZCBmb3IgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCBwdXJwb3NlLjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gVGhl IElQRklYIHByb3Bvc2FsIGlzIGFib3V0IGlkZW50aWZ5aW5nIGEgcGllY2Ugb2YgaW5mb3JtYXRp b24gTk9UIGFib3V0IGhvdyB0byB1c2UgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+WWVzLCB0aGVyZSBpcyBpbnRlcnNlY3Rpb24gd2l0aCBzb21lIElQRklYIGZpZWxkcy4N Cjwvc3Bhbj5CdXQgdGhlcmXigJlzIGFsc28gaW50ZXJzZWN0aW9uIHdpdGggdGhlIElGLU1JQi48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+W01lZF0gSSB3b27igJl0IGNvbW1lbnQgdGhpcyBwYXJ0IGJlY2F1c2Ug aXQgdHJpZXMgdG8gbWl4IHRoaW5ncy4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5GaXJzdCwgSVBGSVggaXMgbm90IGEgc3VwZXJzZXQgb2Yg YWxsIHRoZSBpbmZvcm1hdGlvbiBuZWVkZWQuPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBBZ3JlZS4gSSBuZXZlciBjbGFpbWVkIHRo YXQhDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Mb29raW5nIGF0IHRoZSBX RyBkb2Mgb24gbW9iaWxpdHkgYW5kIERDLCBhbmQgdGhlIHZhcmlvdXMgYWxsb2NhdGlvbiBkcmFm dHMsIG5vdCBldmVyeSBmaWVsZHMgaXMgaW4gSVBGSVguPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5b TWVkXSBUaGUgcHJvcG9zYWwgaXMgbm90IGFib3V0IHJldXNpbmcgYWxsIHRoZSBmaWVsZHMgaW4g SVBGSVgsIGJ1dCB0byByZXVzZSB0aGUgKiogSVBGSVggSUVzICoqIHJlZ2lzdHJ5LiAmbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U2Vj b25kLCBub3QgZXZlcnkgSVBGSVggZmllbGQgaXMgbmVlZGVkIGluIFNGQyAoY2VydGFpbmx5IG5v dCB0aGUgNDUwJiM0MzspLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gSSBuZXZlciBjbGFp bWVkIHRoYXQsIHRvbyENCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgY29yb2xs YXJ5IG9mIHRoaXMgaXMgdGhhdCB0aGVyZSBhcmUgYSBudW1iZXIgb2YgYXNzb2NpYXRlZCBwcm9i bGVtcyB3aXRoIHRoZSBwcm9wb3NhbDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4xLiBEb2VzIGFuIFNGQyBpbXBs ZW1lbnRhdGlvbiBuZWVkIHRvIHN1cHBvcnQgYWxsIChldmVyIGdyb3dpbmcpIElQRklYIElFcz88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPk1lZDogJm5ic3A7VGhlcmUgaXMgbm8gbWFuZGF0b3J5LXRv LXN1cHBvcnQgbWV0YWRhdGEgYXMgZmFyIGFzIEkga25vdy4gVGhpcyBzaG91bGQgYmUgcGFydCBv ZiBhbiBSRlAgYW5kIGRlcGxveW1lbnQgZGVjaXNpb24uICZuYnNwO1RoZSBxdWVzdGlvbiB5b3Ug cmFpc2VkIGFwcGxpZXMNCiBmb3IgYWxsIFRMVnMuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4yLiBEbyB5b3UgcHJvcG9zZSB0byBzcGVjaWZ5 IHByb2ZpbGVzIG9mIElQRklYLCB3aGljaCBpbmNsdWRlIGEgc3Vic2V0IHRvIGJlIHVzZWQ/DQo8 L3NwYW4+VGhhdCBzZWVtcyBpbiBwcmFjdGljZSBtb3JlIGRpZmZpY3VsdCB0aGFuIHRoZSBkaXJl Y3QgYWx0ZXJuYXRpdmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIE5vLiBJ4oCZbSByZXByb2R1Y2lu ZyBoZXJlIHdoYXQgSSBhbnN3ZXJlZCBpbiBhbm90aGVyIHRocmVhZDogVGhlIHByb3Bvc2FsIGlz IG5vdCBhYm91dCByZXVzaW5nIHRoZSBJUEZJWCBmb3JtYXQsIGJ1dCBJUEZJWCByZWdpc3RyeS4g VGhlIFRMViBmb3JtYXQgYXMNCiBkZXNjcmliZWQgaW4gdGhlIG5zaCBkcmFmdCB3aWxsIGJlIHVz ZWQuIFdpdGggdGhlIGFwcHJvYWNoIEnigJltIHByb3Bvc2luZyBoZXJlOiA8bzpwPg0KPC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjI1 cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+4oCiJm5ic3A7Jm5ic3A7IGlm IHlvdSBuZWVkIHRvIGluY2x1ZGUgYSBGbG93SUQsIHlvdSBqdXN0IG5lZWQgdG8gc2V0IHRoZSBy ZWdpc3RyeSBJRCB0byAxLCBhbmQgdGhlIHR5cGUgdG8gMTQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuMjVwdCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj7igKImbmJzcDsmbmJzcDsgSWYgeW91IG5lZWQg dG8gaW5jbHVkZSBhIHZsYW5kSUQsIHlvdSBqdXN0IG5lZWQgdG8gc2V0IHRoZSByZWdpc3RyeSBJ RCB0byAxLCBhbmQgdGhlIHR5cGUgdG8gNTguPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuMjVwdCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj7igKImbmJzcDsmbmJzcDsgLi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS4yNXB0Ij48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRoaXMgaXMgYWxtb3N0IGNsb3NlIHRvIHdo YXQgUmVpbmFsZG/igJlzIGRyYWZ0IGlzIGRvaW5nIGV4Y2VwdCB0aGUgYXV0aG9ycyB1c2UgYSBt YW5kYXRvcnkgZmllbGQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjMuIFJlZ2FyZGluZyBmaWVsZHMgbm90IGRlZmluZWQgaW4gSVBG SVgsIGRvZXMgU0ZDIG5lZWQgdG8gc3BlY2lmeSBhIG5ldyBJUEZJWCBJRSwgYW5kIHNwZWNpZnkg aG93IGl0IHdvdWxkIGJlIHVzZWQgd2l0aCBJUEZJWD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBOby4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+NC4gV2hhdCBhYm91dCBuZXdseSBkZWZpbmVkIElQ RklYIGZpZWxkcyBhZnRlciB0aGUgcHVibGlzaGluZyBvZiB0aGUgTlNIIGRvY3VtZW50cz88c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRd IEkgZG9u4oCZdCBzZWUgYW55IGlzc3VlIHRoZXJlIGF0IGFsbCEgV2UgZG9u4oCZdCBjYXJlIGFi b3V0IElQRklYIEZJRUxEUywgYnV0IGFib3V0IHRoZSBpbmZvcm1hdGlvbiBlbGVtZW50cyBhbmQg dGhlaXIgY29kZSBwb2ludHMuIEhlcmUgaXMgdGhlIHByb3Bvc2FsDQogSSBzaGFyZWQgb24gdGhl IGxpc3QsIGZ3aXc6IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPj09UFJP UE9TQUw9PT09Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+QmFzZSB2ZXJzaW9uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMg NCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Q2xhc3MmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUeXBl Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgRkxBR1MgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBMZW5ndGgmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8vJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IERhdGEgKFZhcmlhYmxlKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvLzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgZGVzY3JpcHRpb24g b2YgdGhlIGZpZWxkcyBpcyBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENsYXNzOiZuYnNwOyBJbiBvcmRlciB0byBmb3N0 ZXIgc2VydmljZSBpbm5vdmF0aW9uLCB0aGlzIGZpZWxkPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhbGxvd3MgdG8gaW5oZXJpdCBmcm9t IGV4aXN0aW5nIGNvZGUgcG9pbnQgcmVnaXN0cmllcyB0aGF0IGFyZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGlrZWx5IHRvIGJlIHVz ZWZ1bCBpbiBhIFNGQyBjb250ZXh0LiZuYnNwOyBUaGUgZm9sbG93aW5nIHZhbHVlcyBhcmU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJl c2VydmVkIGJ5IHRoaXMgc3BlY2lmaWNhdGlvbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDA6Jm5ic3A7IFNlZSBJQU5BIHNlY3Rpb24u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAxOiZuYnNwOyBJUEZJWCBbSVBGSVhdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFR5cGU6Jm5ic3A7IEluZGljYXRlcyB0aGUgY29kZSBw b2ludCBvZiB0aGUgY29udGV4dCBlbGVtZW50LiZuYnNwOyBJZjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7Q2xhc3MmcXVvdDsg ZmllbGQgaXMgbm9uLW51bGwsIHRoZSBpbnRlcnByZXRhdGlvbiBvZiB0aGlzIGZpZWxkIE1VU1Q8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGNvbmZvcm0gdG8gdGhlIG9uZSBkZWZpbmVkIGZvciB0aGF0IHNwZWNpZmljIGNsYXNzIHJlZ2lz dHJ5Lg0KPC9zcGFuPlNlZSBJQU5BIHNlY3Rpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPj09PTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhvdyBhcmUgdGhvc2UgdmV0dGVkIGZvciBhcHBs aWNhYmlsaXR5IHRvIFNGQz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIEkgZG9u4oCZdCB1 bmRlcnN0YW5kIHRoZSBwb2ludCBoZXJlLiBDYW4geW91IHBsZWFzZSBleHBsaWNpdCB5b3VyIHBv aW50PyBUaGFua3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj41LiBXaGF0IGlzIFNG QyBuZWVkcyBhIGRpZmZlcmVudCBkYXRhIHR5cGUgZm9yIGEgZmllbGQ/PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIFRoaXMgY2FuIGJlIGRlZmlu ZWQgaW4gYSBkZWRpY2F0ZWQgVExWIGRvY3VtZW50Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBteSBvcGluaW9uLCBhbGwgb2YgdGhpcyByZXN1bHQgaW4g YSBsb3QgbW9yZSB3b3JrIGFuZCB1bmNlcnRhaW50eSB0aGFuIGFjdHVhbGx5IGRlZmluaW5nIHdo YXTigJlzIG5lZWRlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gSeKAmW0gYWZyYWlkIHRoaXMgaXMg cHVyZSBzcGVjdWxhdGlvbi4gSSBwcm92aWRlZCB0aGUgZXhhbXBsZSBvZiB2bGFuaWQsIGZsb3dp ZC4gSSBjYW4gcHJvdmlkZSBleGFtcGxlIGFib3V0IHRoZSBzb3VyY2UgSVAgYWRkcmVzcywgc291 cmNlIHBvcnQsIHByb3RvY29sLA0KIGV0Yy4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5JIGV4cGVjdCBzb21lIFNGQy9OU0ggdXNlIGNhc2VzIHRvIHVz ZSBhbiBpZkluZGV4IGZvciBleGFtcGxlLg0KPC9zcGFuPlRoaXMgZG9lcyBub3QgaW1wbHkgdGhh dCBTRkMgbmVlZCB0byBpbXBvcnQgc29tZWhvdyB0aGUgZnVsbCBJRi1NSUIuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPltNZWRdIEkgZG9u4oCZdCBzZWUgdGhlIHBhcmFsbGVsIGhlcmUuDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+U2ltaWxhcmx5LCBJIGV4cGVjdCBTRkMvTlNIIGNhbiB1c2Ugc3Bl Y2lmaWMgZmllbGRzIG9yIHZhbHVlcyBmcm9tIHZhcmlvdXMgcGxhY2VzLCB3aGVuIGl0IG1ha2Vz IHNlbnNlLjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5b TWVkXSBUaGlzIGlzIG5vdCBwYXJ0IG9mIHRoZSBwcm9wb3NhbCE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5JIGRvIG5vdCBleHBlY3QgTlNIIG5lZWRpbmcgdG8gaW1wb3J0IGFs bCBvZiB0aG9zZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gc3VtbWFyeSwgSSBi ZWxpZXZlIHRoaXMgcHJvcG9zYWwgaXMgaGFybWZ1bCB0byBOU0ggb24gdGhlIGFib3ZlIHRlY2hu aWNhbCBncm91bmRzLjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj5bTWVkXSBNeSBpbml0aWFsIG9iamVjdGl2ZSBpcyB0byBmb3N0ZXIgc2VydmljZSBpbm5v dmF0aW9uIHdpdGhvdXQgd2FpdGluZyBsb25nIGN5Y2xlcyB0byBzdGFuZGFyZGl6ZSBhIHNpbmds ZSBjb2RlIHBvaW50Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QXMgYSBn ZW5lcmFsIHByb3Bvc2FsLCBpdCBzZWVtcyB0byBtZSBsaWtlIGEgY2Fubm9uIHRvIGtpbGwgYSBm bHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBJIGhvcGUgdGhpbmdzIGFyZSBtb3JlIGNs ZWFyIG5vdyBhZnRlciBteSByZXNwb25zZXMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBleHBlY3QgU0ZDIG1pZ2h0IG5lZWQgdG8gZGVm aW5lIHRoaW5ncyBsaWtlIGZsb3cgc3BlY2lmaWNhdGlvbnMsIGl0IGRvZXMgbm90IG1lYW4gaXQg b3VnaHQgdG8gcmV1c2UgdGhlIEJHUCBGbG93IFNwZWMgcmVnaXN0cmllcywgc2VtYW50aWNzLCBh bmQgc3ludGF4LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+VGhhdCBzYWlkLCBhcyBTRkMgZGVmaW5lcyB0aGluZ3MgZnJvbSBhIGZsb3csIEkgZXhwZWN0 IGl0IHdpbGwgbm90IHJlLWludmVudCB0aGUgd2hlZWwgYW5kIHJlLXVzZSBzdXJnaWNhbGx5Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJQgQ2FybG9zLiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B933008D62BEBOPEXCLILMA3corp_-- From nobody Mon May 2 07:32:40 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B356112D0C3; Mon, 2 May 2016 07:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 3zlcBMYFJGHc; Mon, 2 May 2016 07:32:36 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C49A812D0C0; Mon, 2 May 2016 07:32:32 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 0175C40697; Mon, 2 May 2016 16:32:31 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id C56071A0054; Mon, 2 May 2016 16:32:30 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0279.002; Mon, 2 May 2016 16:32:30 +0200 From: To: "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] Call for WG adoption of draft-penno-sfc-appid-03 Thread-Index: AQHRZQHOvGZf31kz6UifjJTvmDJQAZ+hr9aAgARTiaCAAGltAP//xfBA Date: Mon, 2 May 2016 14:32:30 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D62C02@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D62994@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <3501127B-E55B-4FA1-9A63-47D046371132@cisco.com> In-Reply-To: <3501127B-E55B-4FA1-9A63-47D046371132@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008D62C02OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Cc: "draft-penno-sfc-appid@ietf.org" , "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-appid-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 14:32:38 -0000 --_000_787AE7BB302AE849A7480A190F8B933008D62C02OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogQ2FybG9z IFBpZ25hdGFybyAoY3BpZ25hdGEpIFttYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tXQ0KRW52b3nD qSA6IGx1bmRpIDIgbWFpIDIwMTYgMTU6NTMNCsOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09M Tg0KQ2MgOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgc2ZjQGlldGYub3JnOyBkcmFmdC1wZW5u by1zZmMtYXBwaWRAaWV0Zi5vcmcNCk9iamV0IDogUmU6IFtzZmNdIENhbGwgZm9yIFdHIGFkb3B0 aW9uIG9mIGRyYWZ0LXBlbm5vLXNmYy1hcHBpZC0wMw0KDQpEZWFyIE1lZCwNCg0KVGhhbmtzIGZv ciB0YWtpbmcgdGhlIHRpbWUgdG8gcmV2aWV3IGFuZCBjb21tZW50LiBQbGVhc2UgZmluZCBzb21l IGNvbW1lbnRzIGlubGluZS4NCg0KT24gTWF5IDIsIDIwMTYsIGF0IDc6NTggQU0sIG1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+ IHdyb3RlOg0KDQpIaSBKaW0sIGFsbCwNCg0KSSBpbnRlcnByZXQgdGhpcyBwcm9wb3NhbCBhcyBp ZiBpdCB3YW50cyB0byBpbmhlcml0IHRoZSBJUEZJWCBBcHBsaWNhdGlvbiBpbmZvcm1hdGlvbiB0 byBiZSBjb252ZXllZCBpbiBhbiBuc2ggaGVhZGVyLiBJIGhhdmUgc29tZSBpc3N1ZXMgd2l0aCB0 aGUgcmF0aW9uYWxlIG9mIHRoaXMgZHJhZnQsIG5vdCBpdHMgZ29hbCBwZXIgc2UuDQoNCkkgZG8g bm90IHN1cHBvcnQgdGhpcyBkcmFmdC4gSSBkbyB0aGluayB0aGVyZSBhcmUgb3RoZXIgZGVzaWdu IGNob2ljZXMgdGhhdCBjYW4gYmUgaW52ZXN0aWdhdGVkIGJ5IHRoZSBXRyB0byBpbmhlcml0IGV4 aXN0aW5nIElQRklYIElFcyB3aXRob3V0IHdyaXRpbmcgYSBuZXcgUkZDIGZvciBpdCBmb3IgRUFD SCBJRSB0byBiZSBjb252ZXllZCBpbiBhbiBOU0ggaGVhZGVyLg0KDQpJIGJlbGlldmUgeW91IGFy ZSBtaXN1bmRlcnN0YW5kaW5nIHdoYXQgZHJhZnQtcGVubm8tc2ZjLWFwcGlkLTAzIGlzIGFib3V0 LiBUaGUgZ29hbCBpcyB0byBjb252ZXkgYXBwbGljYXRpb24gaW5mb3JtYXRpb24gaW4gU0ZDIE1l dGFkYXRhLiBJdCBpcyBub3QgdG8gaW5oZXJpdCBleGlzdGluZyBJUEZJWCBJRXMuDQpbTWVkXSBZ b3UgbWF5IGJlIHJpZ2h0IGJ1dCB0aGUgZG9jdW1lbnQgZXhwbGljaXRseSBzYXlzOg0KDQogICBU aGlzIGRvY3VtZW50IHB1cnBvc2VzIHRoZSB1c2Ugb2YgSVBGSVggW1JGQzcwMTE8aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzcwMTE+XSBhcHBsaWNhdGlvbg0KICAgICAgICAgICAgICAg ICAgICAgICAgICBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXg0KICAgaW5m b3JtYXRpb24gdG8gYmUgY2FycmllZCBpbiB0aGUgTlNIIGNvbnRleHQgbWV0YWRhdGEgb2YgYSBN RFR5cGUtMQ0KICAgXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXg0K ICAgcGFja2V0Lg0KDQoNCkdpdmVuIHRoaXMgZ29hbCBvZiBjb252ZXlpbmcgYXBwbGljYXRpb24g aW5mb3JtYXRpb24sIHdlIGZvdW5kIG9uZSBzcGVjaWZpYyBzeW50YXggbGV2ZXJhZ2luZyB0aGUg QXBwbGljYXRpb24gSW5mb3JtYXRpb24gc3RydWN0dXJlIGZyb20gSVBGSVguDQpbTWVkXSBXaGlj aCBtYWtlcyBzZW5zZS4gSSBmdWxseSBhZ3JlZSB3aXRoIHRoYXQuDQoNCkkgd2FudGVkIHRvIGNs YXJpZnkgdGhlIGRpZmZlcmVuY2UsIGFzIGl0IGlzIHNpZ25pZmljYW5jZS4NCg0KSWYgdGhlcmUg YXJlIG90aGVyIGRlc2lnbiBjaG9pY2VzICp0byBjb252ZXkgYXBwbGljYXRpb24gaWRlbnRpZmlj YXRpb24qIChub3QgdG8gaW5oZXJpdCBleGlzdGluZyBmaWVsZHMgZnJvbSBhbnl3aGVyZSBhcyBh IGdvYWwpLCB3ZeKAmWQgbG92ZSB0byBoZWFyIHRoZW0uDQpbTWVkXSBXaG8gaXMgYXNraW5nIHRv IOKAnGluaGVyaXQgZXhpc3RpbmcgZmllbGRz4oCdPw0KDQpUaGlzIHNwZWNpZmljIHByb3Bvc2Fs IGNvbXBpbGVzIGFuZCBydW5zLg0KDQoNCg0KRm9yIGV4YW1wbGUsIHRoZXJlIGlzIGEgbW9yZSBn ZW5lcmFsIHByb3Bvc2FsIHRoYXQgYWltcyB0byBpbXBvcnQgQU5ZIElQRklYIEluZm9ybWF0aW9u IEVsZW1lbnQgKHRoYXQgd2lsbCBjb3ZlciB0aGUgcGFydGljdWxhciBjYXNlIGluIHRoaXMgZG9j dW1lbnQpOmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zZmMvY3VycmVudC9t c2cwNDQ5Mi5odG1sIHdpdGhvdXQgY29uc3VtaW5nIHRoZSBXRyBlZmZvcnQgdG8gZWRpdC9yZXZp ZXcvcHVibGlzaCBSRkNzIGZvciBlYWNoIHByb21pc2luZyBJUEZJWCBJRXMuDQoNCg0KSSBiZWxp ZXZlIHRoaXMgd2lsbCBjYXVzZSBtb3JlIGhlYWRhY2hlcyB0aGFuIHNvbHV0aW9ucyDigJQgSSBy ZXBsaWVkIGluIGEgc2VwYXJhdGUgbm90ZS4NCg0KDQpGdXJ0aGVyLCBJIGhhdmUgdGhlIGZvbGxv d2luZyBxdWVzdGlvbnMgZm9yIHRoZSBkcmFmdDoNCg0K4oCiICAgICAgICAgV2h5IHJlc2Vydmlu ZyB0aGlzIHByb3Bvc2FsIGZvciBNRCMxPw0KDQpCZWNhdXNlIHRoYXQgaXMgdGhlIG1pbmltYWwg b25lIHRvIHVzZS4NCltNZWRdIEkgZG9u4oCZdCBwYXJzZSB0aGlzLCBzb3JyeS4NCg0KSG93ZXZl ciwgdGhpcyBpcyBhbHNvIGRlZmluZWQgZm9yIE1ELVR5cGUgMiBhdCBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtcXVpbm4tc2ZjLW5zaC10bHYtMDEjcGFnZS03IChzZWUg4oCcNS4g ICBBcHBsaWNhdGlvbiBJROKAnSkNCltNZWRdIEkgZG9u4oCZdCB0aGluayBpdCBpcyBhIGdvb2Qg aWRlYSB0byBoYXZlIGEgbG90IG9mIGRvY3VtZW50cyB0byBkZWZpbmUgdGhlIHNhbWUgc2V0IG9m IGluZm9ybWF0aW9uLg0KDQpEbyB5b3Ugc3VnZ2VzdCB3ZSBzaG91bGQgZGVmaW5lIE1ELVR5cGUg MiBpbiB0aGlzIGRyYWZ0IGFzIHdlbGw/IEhhcHB5IHRvIGRvIHNvIGlmIHRoYXTigJlzIHVzZWZ1 bC4NCltNZWRdIE5vLCBJ4oCZbSBub3QgcHJvcG9zaW5nIHRoYXQuIEnigJltIHRyeWluZyB0byB1 bmRlcnN0YW5kIHRoZSB0ZWNobmljYWwgcmF0aW9uYWxlIGZvciB0aGF0IGNob2ljZS4NCg0KDQri gKIgICAgICAgICBXaGF0IG1lYW5zIHRoZSBmb2xsb3dpbmcgaGVhZGVycz8NCiAgICAgIDAgICAg ICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMN CiAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQg NSA2IDcgOCA5IDAgMQ0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgIDMgICAgICAgfCAgICAg ICAgMCAgICAgIHwgICAgICAgICAgICAgIDE2MSAgICAgICAgICAgICAgfA0KICAgICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KICAgICB8ICAgICAgICAgICAgICAgICAgTmV0d29yayBTaGFyZWQgQ29udGV4dCAgICAgICAg ICAgICAgICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICAgICAgICAgICAg U2VydmljZSBQbGF0Zm9ybSBDb250ZXh0ICAgICAgICAgICAgICAgICAgICAgfA0KICAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0KICAgICB8ICAgICAgICAgICAgICAgICAgU2VydmljZSBTaGFyZWQgQ29udGV4dCAgICAg ICAgICAgICAgICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQogICAgICAgRmlndXJlIDI6IEV4 YW1wbGUgb2YgTWV0YWRhdGEgSW5jbHVkaW5nIHRoZSBTTk1QIEFwcGxpY2F0aW9uDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBJZGVudGlmaWNhdGlvbg0KDQoNCg0KSXQgaXMgYW4gZXhh bXBsZSBvZiBtZXRhZGF0YSBpbmNsdWRpbmcgdGhlIFNOTVAgYXBwbGljYXRpb24gaWRlbnRpZmlj YXRpb24uDQpbTWVkXSBNeSBxdWVzdGlvbiB3YXMgbWF5YmUgbm90IGNsZWFyOiB3aGF0IGEgTmV0 d29yayBTaGFyZWQgQ29udGV4dD8gV2hhdCBpcyBhIFNlcnZpY2UgUGxhdGZvcm0gQ29udGV4dD8g V2hhdCBpcyBTZXJ2aWNlIFNoYXJlZCBDb250ZXh0Pw0KDQpCZXN0LA0KDQrigJQgQ2FybG9zLg0K DQoNCkNoZWVycywNCk1lZA0KDQpEZSA6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn XSBEZSBsYSBwYXJ0IGRlIEppbSBHdWljaGFyZCAoamd1aWNoYXIpDQpFbnZvecOpIDogdmVuZHJl ZGkgMjkgYXZyaWwgMjAxNiAxODozMQ0Kw4AgOiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRm Lm9yZz4NCk9iamV0IDogW3NmY10gQ2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtcGVubm8t c2ZjLWFwcGlkLTAzDQoNCkRlYXIgV0c6DQoNCldlIGRpZCBub3QgcmVjZWl2ZSBtYW55IHJlc3Bv bnNlcyBmb3IgdGhpcyBjYWxsIGZvciBhZG9wdGlvbiBhbmQgdGhlcmVmb3JlIHdvdWxkIGxpa2Ug dG8gcmUtaW52aXRlIHBlb3BsZSB0byBwb3N0IHRoZWlyIHRob3VnaHRzIG9uIGFkb3B0aW5nIHRo aXMgZG9jdW1lbnQgaW50byB0aGUgU0ZDIFdHLiBUaGUgY2FsbCBmb3IgYWRvcHRpb24gd2lsbCBy dW4gZm9yIGEgZnVydGhlciAyIHdlZWtzIGVuZGluZyA2LzEzLzIwMTYuDQoNClRoYW5rcyENCg0K U0ZDIENoYWlycw0KDQpGcm9tOiBKaW0gR3VpY2hhcmQgPGpndWljaGFyQGNpc2NvLmNvbTxtYWls dG86amd1aWNoYXJAY2lzY28uY29tPj4NCkRhdGU6IFRodXJzZGF5LCBGZWJydWFyeSAxMSwgMjAx NiBhdCAzOjI0IFBNDQpUbzogInNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiIgPHNm Y0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPj4NClN1YmplY3Q6IENhbGwgZm9yIFdHIGFk b3B0aW9uIG9mIGRyYWZ0LXBlbm5vLXNmYy1hcHBpZC0wMw0KDQpEZWFyIFdHOg0KDQpUaGlzIGVt YWlsIHNlcnZlcyBhcyBhIGNhbGwgZm9yIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LXBlbm5vLXNmYy1h cHBpZC0wMyBhcyBhIFdHIGRvY3VtZW50LiBUaGUgY2FsbCBmb3IgYWRvcHRpb24gd2lsbCBydW4g Zm9yIDIgd2Vla3MgZW5kaW5nIDIvMjUvMjAxNi4NCg0KUGxlYXNlIG5vdGUgdGhhdCB0aGlzIGlz IGEgY2FsbCBmb3IgYWRvcHRpb24sIGFuZCBub3QgYSBsYXN0IGNhbGwgZm9yIGNvbnRlbnQgb2Yg dGhlIGRvY3VtZW50LiBBZG9wdGluZyBhIFdHIGRvY3VtZW50IHNpbXBseSBtZWFucyB0aGF0IHRo ZSBXRyB3aWxsIGZvY3VzIGl0cyBlZmZvcnRzIG9uIHRoYXQgcGFydGljdWxhciBkcmFmdCBnb2lu ZyBmb3J3YXJkLCBhbmQgdXNlIHRoYXQgZG9jdW1lbnQgZm9yIHJlc29sdmluZyBvcGVuIGlzc3Vl cyBhbmQgZG9jdW1lbnRpbmcgdGhlIFdH4oCZcyBkZWNpc2lvbnMuDQoNClBsZWFzZSBpbmRpY2F0 ZSB3aGV0aGVyIHlvdSBzdXBwb3J0IGFkb3B0aW9uIGZvciBub3QsIGFuZCBpZiBub3Qgd2h5LiBJ c3N1ZXMgeW91IGhhdmUgd2l0aCB0aGUgY3VycmVudCBkb2N1bWVudCBpdHNlbGYgY2FuIGFsc28g YmUgcmFpc2VkLCBidXQgdGhleSBzaG91bGQgYmUgcmFpc2VkIGluIHRoZSBjb250ZXh0IG9mIHdo YXQgc2hvdWxkIGJlIGNoYW5nZWQgaW4gdGhlIGRvY3VtZW50IGdvaW5nIGZvcndhcmQsIHJhdGhl ciB0aGFuIGEgcHJlLWNvbmRpdGlvbiBmb3IgYWRvcHRpb24uDQoNCkZpbmFsbHksIG5vdyBpcyBh bHNvIGEgZ29vZCB0aW1lIHRvIHBvbGwgZm9yIGtub3dsZWRnZSBvZiBhbnkgSVBSIHRoYXQgYXBw bGllcyB0byB0aGlzIGRyYWZ0LCBpbiBsaW5lIHdpdGggdGhlIElQUiBkaXNjbG9zdXJlIG9ibGln YXRpb25zIGZvciBXRyBwYXJ0aWNpcGFudHMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5k IDUzNzggZm9yIG1vcmUgZGV0YWlscykuIElmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQg YXV0aG9yIHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgKHRvIHRoZSBjaGFpcnMpIHdoZXRo ZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4NCg0KVGhhbmtzIQ0K DQpTRkMgQ2hhaXJzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQo= --_000_787AE7BB302AE849A7480A190F8B933008D62C02OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNv bnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVz IENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLmFwcGxl LWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7 fQ0Kc3Bhbi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxs ZXMgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRl IGRlIGJ1bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4u RW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0K CWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4uUHJmb3JtYXRIVE1MQ2FyDQoJe21zby1zdHlsZS1u YW1lOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlJlLSw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPlBsZWFzZSBzZWUgaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSBbbWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbV0N Cjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBsdW5kaSAyIG1haSAyMDE2IDE1OjUzPGJyPg0K PGI+w4AmbmJzcDs6PC9iPiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOPGJyPg0KPGI+Q2MmbmJz cDs6PC9iPiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgc2ZjQGlldGYub3JnOyBkcmFmdC1wZW5u by1zZmMtYXBwaWRAaWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbc2ZjXSBD YWxsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1wZW5uby1zZmMtYXBwaWQtMDM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIE1lZCw8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgdGFraW5nIHRo ZSB0aW1lIHRvIHJldmlldyBhbmQgY29tbWVudC4gUGxlYXNlIGZpbmQgc29tZSBjb21tZW50cyBp bmxpbmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBNYXkgMiwgMjAxNiwgYXQgNzo1OCBBTSwgPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20iPg0KbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4g d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPkhpIEppbSwgYWxsLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JIGludGVycHJldCB0aGlzIHByb3Bvc2Fs IGFzIGlmIGl0IHdhbnRzIHRvIGluaGVyaXQgdGhlIElQRklYIEFwcGxpY2F0aW9uIGluZm9ybWF0 aW9uIHRvIGJlIGNvbnZleWVkIGluIGFuIG5zaCBoZWFkZXIuIEkgaGF2ZSBzb21lIGlzc3VlcyB3 aXRoIHRoZSByYXRpb25hbGUgb2YgdGhpcyBkcmFmdCwNCiBub3QgaXRzIGdvYWwgcGVyIHNlLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5J IGRvIG5vdCBzdXBwb3J0IHRoaXMgZHJhZnQuIEkgZG8gdGhpbmsgdGhlcmUgYXJlIG90aGVyIGRl c2lnbiBjaG9pY2VzIHRoYXQgY2FuIGJlIGludmVzdGlnYXRlZCBieSB0aGUgV0cgdG8gaW5oZXJp dCBleGlzdGluZyBJUEZJWCBJRXMgd2l0aG91dCB3cml0aW5nIGEgbmV3IFJGQyBmb3INCiBpdCBm b3IgRUFDSCBJRSB0byBiZSBjb252ZXllZCBpbiBhbiBOU0ggaGVhZGVyLjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSBiZWxpZXZlIHlvdSBhcmUgbWlzdW5kZXJzdGFuZGluZyB3aGF0IGRyYWZ0LXBlbm5v LXNmYy1hcHBpZC0wMyBpcyBhYm91dC4gVGhlIGdvYWwgaXMgdG8gY29udmV5IGFwcGxpY2F0aW9u IGluZm9ybWF0aW9uIGluIFNGQyBNZXRhZGF0YS4gSXQgaXMgbm90IHRvIGluaGVyaXQgZXhpc3Rp bmcgSVBGSVggSUVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBZb3UgbWF5IGJlIHJpZ2h0IGJ1dCB0 aGUgZG9jdW1lbnQgZXhwbGljaXRseSBzYXlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgVGhpcyBkb2N1bWVudCBwdXJwb3NlcyB0aGUgdXNlIG9m IElQRklYIFs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM3MDExIiB0aXRsZT0iJnF1b3Q7U3BlY2lmaWNhdGlvbiBvZiB0aGUgSVAgRmxvdyBJ bmZvcm1hdGlvbiBFeHBvcnQgKElQRklYKSBQcm90b2NvbCBmb3IgdGhlIEV4Y2hhbmdlIG9mIEZs b3cgSW5mb3JtYXRpb24mcXVvdDsiPjxzcGFuIGxhbmc9IkVOLVVTIj5SRkM3MDExPC9zcGFuPjwv YT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5dDQogYXBwbGljYXRpb248bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBeXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGluZm9ybWF0aW9uIHRv IGJlIGNhcnJpZWQgaW4gdGhlIE5TSCBjb250ZXh0IG1ldGFkYXRhIG9mIGEgTURUeXBlLTE8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5ePG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+cGFja2V0Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkdpdmVuIHRoaXMgZ29hbCBvZiBjb252ZXlpbmcgYXBwbGljYXRpb24gaW5mb3JtYXRpb24sIHdl IGZvdW5kIG9uZSBzcGVjaWZpYyBzeW50YXggbGV2ZXJhZ2luZyB0aGUgQXBwbGljYXRpb24gSW5m b3JtYXRpb24gc3RydWN0dXJlIGZyb20gSVBGSVguPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIFdoaWNo IG1ha2VzIHNlbnNlLiBJIGZ1bGx5IGFncmVlIHdpdGggdGhhdC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgd2FudGVkIHRvIGNsYXJpZnkgdGhlIGRp ZmZlcmVuY2UsIGFzIGl0IGlzIHNpZ25pZmljYW5jZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPklmIHRoZXJlIGFyZSBvdGhlciBkZXNpZ24gY2hvaWNl cyAqdG8gYzwvc3Bhbj5vbnZleSBhcHBsaWNhdGlvbiBpZGVudGlmaWNhdGlvbiogKG5vdCB0byBp bmhlcml0IGV4aXN0aW5nIGZpZWxkcyBmcm9tIGFueXdoZXJlIGFzIGEgZ29hbCksIHdl4oCZZCBs b3ZlIHRvIGhlYXIgdGhlbS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gV2hvIGlzIGFza2lu ZyB0byDigJxpbmhlcml0IGV4aXN0aW5nIGZpZWxkc+KAnT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhpcyBzcGVjaWZpYyBwcm9wb3NhbCBjb21waWxlcyBhbmQgcnVucy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Gb3IgZXhhbXBsZSwg dGhlcmUgaXMgYSBtb3JlIGdlbmVyYWwgcHJvcG9zYWwgdGhhdCBhaW1zIHRvIGltcG9ydCBBTlkg SVBGSVggSW5mb3JtYXRpb24gRWxlbWVudCAodGhhdCB3aWxsIGNvdmVyIHRoZSBwYXJ0aWN1bGFy IGNhc2UgaW4gdGhpcyBkb2N1bWVudCk6PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL3NmYy9jdXJyZW50L21zZzA0NDkyLmh0bWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zZmMvY3VycmVu dC9tc2cwNDQ5Mi5odG1sPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+d2l0aG91dA0KIGNvbnN1bWluZyB0aGUgV0cgZWZmb3J0IHRvIGVk aXQvcmV2aWV3L3B1Ymxpc2ggUkZDcyBmb3IgZWFjaCBwcm9taXNpbmcgSVBGSVggSUVzLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYmVsaWV2ZSB0aGlzIHdp bGwgY2F1c2UgbW9yZSBoZWFkYWNoZXMgdGhhbiBzb2x1dGlvbnMg4oCUIEkgcmVwbGllZCBpbiBh IHNlcGFyYXRlIG5vdGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkZ1cnRoZXIsIEkgaGF2ZSB0aGUgZm9s bG93aW5nIHF1ZXN0aW9ucyBmb3IgdGhlIGRyYWZ0Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0x OC4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpTeW1ib2wiPsK3PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+V2h5DQogcmVzZXJ2aW5nIHRoaXMgcHJvcG9zYWwgZm9yIE1E IzE/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkJlY2F1c2UgdGhhdCBpcyB0aGUgbWluaW1hbCBvbmUgdG8gdXNlLiA8 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBJ IGRvbuKAmXQgcGFyc2UgdGhpcywgc29ycnkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+SG93ZXZlciwgdGhpcyBpcyBhbHNvIGRlZmluZWQgZm9yIE1ELVR5cGUgMiBhdCZuYnNw Ozwvc3Bhbj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcXVpbm4t c2ZjLW5zaC10bHYtMDEjcGFnZS03Ij48c3BhbiBsYW5nPSJFTi1VUyI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXNmYy1uc2gtdGx2LTAxI3BhZ2UtNzwvc3Bhbj48L2E+ PHNwYW4gbGFuZz0iRU4tVVMiPg0KIChzZWUg4oCcNS4gJm5ic3A7IDwvc3Bhbj5BcHBsaWNhdGlv biBJROKAnSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gSSBkb27igJl0IHRoaW5rIGl0IGlzIGEgZ29v ZCBpZGVhIHRvIGhhdmUgYSBsb3Qgb2YgZG9jdW1lbnRzIHRvIGRlZmluZSB0aGUgc2FtZSBzZXQg b2YgaW5mb3JtYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvIHlvdSBzdWdn ZXN0IHdlIHNob3VsZCBkZWZpbmUgTUQtVHlwZSAyIGluIHRoaXMgZHJhZnQgYXMgd2VsbD8gSGFw cHkgdG8gZG8gc28gaWYgdGhhdOKAmXMgdXNlZnVsLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBObywg SeKAmW0gbm90IHByb3Bvc2luZyB0aGF0LiBJ4oCZbSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB0aGUg dGVjaG5pY2FsIHJhdGlvbmFsZSBmb3IgdGhhdCBjaG9pY2UuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0K PGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4 LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij5XaGF0DQogbWVhbnMgdGhlIGZvbGxvd2luZyBoZWFkZXJzPzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMSZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDM8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAxNjEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtOZXR3b3JrIFNoYXJlZCBD b250ZXh0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2VydmljZSBQbGF0Zm9ybSBDb250ZXh0Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgU2VydmljZSBTaGFyZWQgQ29udGV4dCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0Mzs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZpZ3Vy ZSAyOiBFeGFtcGxlIG9mIE1ldGFkYXRhIEluY2x1ZGluZyB0aGUgU05NUCBBcHBsaWNhdGlvbjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElkZW50aWZpY2F0aW9uPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBpcyBhbiBleGFtcGxlIG9mIG1ldGFk YXRhIGluY2x1ZGluZyB0aGUgU05NUCBhcHBsaWNhdGlvbiBpZGVudGlmaWNhdGlvbi48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+W01lZF0gTXkgcXVlc3Rpb24gd2FzIG1heWJlIG5vdCBjbGVhcjogd2hhdCBhDQo8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5OZXR3b3JrIFNoYXJlZCBDb250ZXh0PyBXaGF0 IGlzIGEgU2VydmljZSBQbGF0Zm9ybSBDb250ZXh0PyBXaGF0IGlzIFNlcnZpY2UgU2hhcmVkIENv bnRleHQ/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAlCBDYXJsb3MuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkNo ZWVycyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk1lZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9z cGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+c2ZjDQogWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRv OnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGI+RGUgbGEgcGFydCBkZTwvYj48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+SmltIEd1aWNoYXJkIChqZ3VpY2hhcik8YnI+ DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+dmVuZHJlZGkgMjkgYXZyaWwgMjAxNiAxODozMTxicj4NCjxiPsOAJm5i c3A7OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxiPk9i amV0Jm5ic3A7OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+W3NmY10gQ2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtcGVubm8tc2ZjLWFwcGlk LTAzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RGVhciBXRzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+V2Ug ZGlkIG5vdCByZWNlaXZlIG1hbnkgcmVzcG9uc2VzIGZvciB0aGlzIGNhbGwgZm9yIGFkb3B0aW9u IGFuZCB0aGVyZWZvcmUgd291bGQgbGlrZSB0byByZS1pbnZpdGUgcGVvcGxlIHRvIHBvc3QgdGhl aXIgdGhvdWdodHMgb24gYWRvcHRpbmcgdGhpcyBkb2N1bWVudCBpbnRvIHRoZSBTRkMgV0cuDQog VGhlIGNhbGwgZm9yIGFkb3B0aW9uIHdpbGwgcnVuIGZvciBhIGZ1cnRoZXIgMiB3ZWVrcyBlbmRp bmcgNi8xMy8yMDE2LiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5UaGFua3MhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNG QyBDaGFpcnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Smlt IEd1aWNoYXJkICZsdDs8YSBocmVmPSJtYWlsdG86amd1aWNoYXJAY2lzY28uY29tIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5qZ3VpY2hhckBjaXNjby5jb208L3NwYW4+PC9hPiZndDs8YnI+ DQo8Yj5EYXRlOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48L2I+VGh1cnNkYXksIEZlYnJ1YXJ5IDExLCAyMDE2IGF0IDM6MjQgUE08YnI+DQo8Yj5Ubzo8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPiZxdW90 OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi PnNmY0BpZXRmLm9yZzwvc3Bhbj48L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGll dGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5zZmNAaWV0Zi5vcmc8L3NwYW4+PC9h PiZndDs8YnI+DQo8Yj5TdWJqZWN0OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L2I+Q2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtcGVubm8tc2Zj LWFwcGlkLTAzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPkRlYXIgV0c6PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXMiPlRoaXMgZW1haWwgc2VydmVzIGFzIGEgY2FsbCBmb3IgV0cgYWRv cHRpb24gb2YgZHJhZnQtcGVubm8tc2ZjLWFwcGlkLTAzIGFzIGEgV0cgZG9jdW1lbnQuIFRoZSBj YWxsIGZvciBhZG9wdGlvbiB3aWxsIHJ1biBmb3IgMiB3ZWVrcyBlbmRpbmcgMi8yNS8yMDE2Ljwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj5QbGVhc2Ugbm90ZSB0aGF0IHRoaXMg aXMgYSBjYWxsIGZvciBhZG9wdGlvbiwgYW5kIG5vdCBhIGxhc3QgY2FsbCBmb3IgY29udGVudCBv ZiB0aGUgZG9jdW1lbnQuIEFkb3B0aW5nIGEgV0cgZG9jdW1lbnQgc2ltcGx5IG1lYW5zIHRoYXQg dGhlIFdHIHdpbGwgZm9jdXMgaXRzIGVmZm9ydHMgb24gdGhhdCBwYXJ0aWN1bGFyDQogZHJhZnQg Z29pbmcgZm9yd2FyZCwgYW5kIHVzZSB0aGF0IGRvY3VtZW50IGZvciByZXNvbHZpbmcgb3BlbiBp c3N1ZXMgYW5kIGRvY3VtZW50aW5nIHRoZSBXR+KAmXMgZGVjaXNpb25zLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTMuNXB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj5QbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5b3Ugc3VwcG9y dCBhZG9wdGlvbiBmb3Igbm90LCBhbmQgaWYgbm90IHdoeS4gSXNzdWVzIHlvdSBoYXZlIHdpdGgg dGhlIGN1cnJlbnQgZG9jdW1lbnQgaXRzZWxmIGNhbiBhbHNvIGJlIHJhaXNlZCwgYnV0IHRoZXkg c2hvdWxkIGJlIHJhaXNlZCBpbiB0aGUgY29udGV4dCBvZiB3aGF0DQogc2hvdWxkIGJlIGNoYW5n ZWQgaW4gdGhlIGRvY3VtZW50IGdvaW5nIGZvcndhcmQsIHJhdGhlciB0aGFuIGEgcHJlLWNvbmRp dGlvbiBmb3IgYWRvcHRpb24uJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29s YXMiPkZpbmFsbHksIG5vdyBpcyBhbHNvIGEgZ29vZCB0aW1lIHRvIHBvbGwgZm9yIGtub3dsZWRn ZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0LCBpbiBsaW5lIHdpdGggdGhl IElQUiBkaXNjbG9zdXJlIG9ibGlnYXRpb25zIGZvciBXRyBwYXJ0aWNpcGFudHMgKHNlZSBSRkNz IDM5NzksIDQ4NzksIDM2NjkNCiBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4gSWYgeW91IGFy ZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3IgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFp bCAodG8gdGhlIGNoYWlycykgd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVs ZXZhbnQgSVBSLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj5UaGFua3MhPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPlNGQyBDaGFpcnM8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzZmMgbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B933008D62C02OPEXCLILMA3corp_-- From nobody Mon May 2 07:34:18 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55EF212D0D8 for ; Mon, 2 May 2016 07:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 FOdRFJW5avBd for ; Mon, 2 May 2016 07:34:15 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D1AA12D0C3 for ; Mon, 2 May 2016 07:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3820; q=dns/txt; s=iport; t=1462199655; x=1463409255; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1Ng7TxpB6j7fjjB9Kk5fUUBMImMttWFLYqNsIxrVxZQ=; b=ObM+/W2zQGosLaENfM0wkbgXsKJet75IZ1+RbR3ccUlyIl2yz97mf9Mt N2VWheiROhxp48X3hK1evwTfqiNSnMIE67HGKYkKXyC+TJG2MWfG41uUZ PDY3kUrOro4X6cu7FabMoGdDOSn0lfE4xmSIlVnyhoDxW+Nm41zVXb5cS c=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AkAwC6ZCdX/4MNJK1dgmxMgVAGtH2CZ?= =?us-ascii?q?IIPDoF2hhACgSs4FAEBAQEBAQFlHAuEQQEBAQMBI0gOBQsCAQgEARMqAgIyJQI?= =?us-ascii?q?EDgUOiBQIqS6QSgEBAQEBAQEBAQEBAQEBAQEBAQEBAQ0IhiGBdoJWhz0rgisFm?= =?us-ascii?q?BQBgyeBZ4kJjxGPMAEeAUODa2yICH8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,567,1454976000"; d="asc'?scan'208,217";a="268683563" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 May 2016 14:34:14 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u42EYEqj028525 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 May 2016 14:34:14 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 May 2016 10:34:13 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Mon, 2 May 2016 10:34:13 -0400 From: "Carlos Pignataro (cpignata)" To: "mohamed.boucadair@orange.com" Thread-Topic: Reuse the IPFIX registry in NSH Thread-Index: AQHRpHiwfFVWYWvPeEiiAjrA4JW4V5+l9suAgAACtoA= Date: Mon, 2 May 2016 14:34:13 +0000 Message-ID: <05CF8496-033A-4B1F-AA5D-E16A8B6ED09E@cisco.com> References: <787AE7BB302AE849A7480A190F8B933008D62994@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2D398770-C83E-48FE-BBE9-574A58871700@cisco.com> <787AE7BB302AE849A7480A190F8B933008D62BEB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D62BEB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.245.225] Content-Type: multipart/signed; boundary="Apple-Mail=_DE47CAA9-DF8F-4709-B9E5-3B1F4A512EC8"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] Reuse the IPFIX registry in NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 14:34:17 -0000 --Apple-Mail=_DE47CAA9-DF8F-4709-B9E5-3B1F4A512EC8 Content-Type: multipart/alternative; boundary="Apple-Mail=_0CB61D2F-CA3C-4ECF-9B65-F8B12903D95C" --Apple-Mail=_0CB61D2F-CA3C-4ECF-9B65-F8B12903D95C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Med, > On May 2, 2016, at 10:24 AM, mohamed.boucadair@orange.com wrote: >=20 > [Med] My initial objective is to foster service innovation without = waiting long cycles to standardize a single code point. >=20 If this is your objective, I=E2=80=99d suggest that setting appropriate = IANA Policies and ranges (including FCFS, Expert Review in particular, = and Specification Required) will achieve it without overcomplicating = things. Best, =E2=80=94 Carlos. --Apple-Mail=_0CB61D2F-CA3C-4ECF-9B65-F8B12903D95C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear Med,

On May 2, 2016, at 10:24 AM, mohamed.boucadair@orange.com wrote:

[Med] My initial objective is to foster service innovation = without waiting long cycles to standardize a single code point.


If this is your objective, I=E2=80=99d = suggest that setting appropriate IANA Policies and ranges (including = FCFS, Expert Review in particular, and Specification Required) will = achieve it without overcomplicating things.

Best,

=E2=80=94 Carlos.
= --Apple-Mail=_0CB61D2F-CA3C-4ECF-9B65-F8B12903D95C-- --Apple-Mail=_DE47CAA9-DF8F-4709-B9E5-3B1F4A512EC8 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 - http://gpgtools.org iQIcBAEBCAAGBQJXJ2VlAAoJEIXgpQGOZny94uoP/1m6ny11z+jqPTFKT9z9uH3y TcuJblUiMorz8mtPwAzCWlbTZPxmVbgavq7het2C2aIHmUyp4ndnWsS8PHgRvoyO HOQ40yevby0cXdvzYzbebTc4FimB2zeVcU5nTChOO5ya3sDPH1Ux++COyzgD1vDz TbzoIqWYyOxw8PlniRwQaZP/qwfbM1EcheQvCoeOlKa2jIe6VfV1NkQa7Oe98YZY M3RXeZxKaGk41wLAvJXMoqlKcmGCbkfVcGECrdkO6M/Nn3+pczLiTrrNai9UxWV0 nCcUquPsf+Om7iu+mdc1aLSlvFf7SQ6Ug6lQ1nCKMmZMuy8AbwQN/5MilkFR1grU 9IIoQd6k+WaN6XLVrlgTe2914aloN6MBYLW6mGUdABlYPim10jrq3mwpkv1+cJHO Ur26mq5NeOHzQApwCniegUy1FNvH086YzGv9gRgtoWduy8iIqIy/qjirtMfwQGrT PnhjEAEG0HQuKh03jRqkhI0jP2W38zu0fNFnCappg8kKRtM7M9rCQxJOQ0r8Q98Z CooLhODUAWfvZwc9qHGVCSafVNx8uaS/BhEms6YzH3jcD4bo+jkpD/X3jBjqb8NZ YqwrGOmdkXQavuw+Au6xI+0Cp7gd2BtcRnYr2ikLw/L0xLStiimHv3jdFvbqiB3J ktj+zsr49LKTJOPO14B3 =6vq3 -----END PGP SIGNATURE----- --Apple-Mail=_DE47CAA9-DF8F-4709-B9E5-3B1F4A512EC8-- From nobody Mon May 2 07:42:26 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7923E12D0EA for ; Mon, 2 May 2016 07:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 BwU5TenQk4Fn for ; Mon, 2 May 2016 07:42:18 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9E1D12D0C0 for ; Mon, 2 May 2016 07:42:17 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id E64F6324A64; Mon, 2 May 2016 16:42:15 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.75]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id C252A27C053; Mon, 2 May 2016 16:42:15 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%19]) with mapi id 14.03.0279.002; Mon, 2 May 2016 16:42:15 +0200 From: To: "Carlos Pignataro (cpignata)" Thread-Topic: Reuse the IPFIX registry in NSH Thread-Index: AQHRpHiwfFVWYWvPeEiiAjrA4JW4V5+l9suAgAACtoD//70OoA== Date: Mon, 2 May 2016 14:42:14 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D62C31@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D62994@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2D398770-C83E-48FE-BBE9-574A58871700@cisco.com> <787AE7BB302AE849A7480A190F8B933008D62BEB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <05CF8496-033A-4B1F-AA5D-E16A8B6ED09E@cisco.com> In-Reply-To: <05CF8496-033A-4B1F-AA5D-E16A8B6ED09E@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008D62C31OPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.5.2.142417 Archived-At: Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] Reuse the IPFIX registry in NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 14:42:24 -0000 --_000_787AE7BB302AE849A7480A190F8B933008D62C31OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpJ4oCZbSBhZnJhaWQgdGhlIOKAnEZDRlMgKyBTcGVjaWZpY2F0aW9uIFJlcXVpcmVk 4oCdIGRvZXMgbm90IGFjaGlldmUgZ29hbC4gSeKAmW0gc3VyZSB5b3UgYXJlIGF3YXJlIHRoYXQg 4oCccGVybWFuZW50IGFuZCByZWFkaWx5IGF2YWlsYWJsZeKAnSBpcyBuZWVkZWQgZm9yIOKAnFNw ZWNpZmljYXRpb24gUmVxdWlyZWTigJ0uIFRoZSBleHBlcnQgcmV2aWV3IHdpbGwgcmVqZWN0IHRo ZSByZXF1ZXN0IGlmIHRoZSBkb2N1bWVudCBpcyBub3QgdG8gYmUgcHVibGlzaGVkIGFzIGFuIFJG QzoNCg0KICAgICAgU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCAtIFZhbHVlcyBhbmQgdGhlaXIgbWVh bmluZ3MgbXVzdCBiZQ0KICAgICAgICAgICAgZG9jdW1lbnRlZCBpbiBhIHBlcm1hbmVudCBhbmQg cmVhZGlseSBhdmFpbGFibGUgcHVibGljDQogICAgICAgICAgICBzcGVjaWZpY2F0aW9uLCBpbiBz dWZmaWNpZW50IGRldGFpbCBzbyB0aGF0IGludGVyb3BlcmFiaWxpdHkNCiAgICAgICAgICAgIGJl dHdlZW4gaW5kZXBlbmRlbnQgaW1wbGVtZW50YXRpb25zIGlzIHBvc3NpYmxlLiAgV2hlbiB1c2Vk LA0KICAgICAgICAgICAgU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCBhbHNvIGltcGxpZXMgdXNlIG9m IGEgRGVzaWduYXRlZA0KICAgICAgICAgICAgRXhwZXJ0LCB3aG8gd2lsbCByZXZpZXcgdGhlIHB1 YmxpYyBzcGVjaWZpY2F0aW9uIGFuZA0KICAgICAgICAgICAgZXZhbHVhdGUgd2hldGhlciBpdCBp cyBzdWZmaWNpZW50bHkgY2xlYXIgdG8gYWxsb3cNCiAgICAgICAgICAgIGludGVyb3BlcmFibGUg aW1wbGVtZW50YXRpb25zLiAgVGhlIGludGVudGlvbiBiZWhpbmQNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgXl5eXl5eXl5eXl5eXl5eXl5eXl4NCiAgICAgICAg ICAgICJwZXJtYW5lbnQgYW5kIHJlYWRpbHkgYXZhaWxhYmxlIiBpcyB0aGF0IGEgZG9jdW1lbnQg Y2FuDQogICAgICAgICAgICBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXg0KICAgICAgICAgICAgcmVhc29uYWJseSBiZSBleHBlY3RlZCB0byBi ZSBmaW5kYWJsZSBhbmQgcmV0cmlldmFibGUgbG9uZw0KICAgICAgICAgICAgYWZ0ZXIgSUFOQSBh c3NpZ25tZW50IG9mIHRoZSByZXF1ZXN0ZWQgdmFsdWUuICBQdWJsaWNhdGlvbg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeXl5eXl5e Xl4NCiAgICAgICAgICAgIG9mIGFuIFJGQyBpcyBhbiBpZGVhbCBtZWFucyBvZiBhY2hpZXZpbmcg dGhpcyByZXF1aXJlbWVudCwNCiAgICAgICAgICAgIF5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eDQogICAgICAgICAgICBidXQgU3BlY2lmaWNh dGlvbiBSZXF1aXJlZCBpcyBpbnRlbmRlZCB0byBhbHNvIGNvdmVyIHRoZQ0KICAgICAgICAgICAg Y2FzZSBvZiBhIGRvY3VtZW50IHB1Ymxpc2hlZCBvdXRzaWRlIG9mIHRoZSBSRkMgcGF0aC4gIEZv cg0KICAgICAgICAgICAgUkZDIHB1YmxpY2F0aW9uLCB0aGUgbm9ybWFsIFJGQyByZXZpZXcgcHJv Y2VzcyBpcyBleHBlY3RlZA0KICAgICAgICAgICAgdG8gcHJvdmlkZSB0aGUgbmVjZXNzYXJ5IHJl dmlldyBmb3IgaW50ZXJvcGVyYWJpbGl0eSwgdGhvdWdoDQogICAgICAgICAgICB0aGUgRGVzaWdu YXRlZCBFeHBlcnQgbWF5IGJlIGEgcGFydGljdWxhcmx5IHdlbGwtcXVhbGlmaWVkDQogICAgICAg ICAgICBwZXJzb24gdG8gcGVyZm9ybSBzdWNoIGEgcmV2aWV3Lg0KDQpJIHN0aWxsIGRvbuKAmXQg c2VlIHRoZSDigJxvdmVyY29tcGxpY2F0aW5n4oCdIHRoaW5nIHlvdSBhcmUgdGFsa2luZyBhYm91 dC4gSXQgaXMgbGlrZSBpbml0aWF0aW5nIHRoZSByZWdpc3RyeSBhdXRvbWF0aWNhbGx5IHdpdGgg dmFsdWVzIGZvciBhIHJpY2ggcmVnaXN0cnkuDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6IENhcmxv cyBQaWduYXRhcm8gKGNwaWduYXRhKSBbbWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbV0NCkVudm95 w6kgOiBsdW5kaSAyIG1haSAyMDE2IDE2OjM0DQrDgCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9P TE4NCkNjIDogSmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IHNmY0BpZXRmLm9yZw0KT2JqZXQgOiBS ZTogUmV1c2UgdGhlIElQRklYIHJlZ2lzdHJ5IGluIE5TSA0KDQpEZWFyIE1lZCwNCg0KT24gTWF5 IDIsIDIwMTYsIGF0IDEwOjI0IEFNLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0 bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCg0KW01lZF0gTXkgaW5pdGlh bCBvYmplY3RpdmUgaXMgdG8gZm9zdGVyIHNlcnZpY2UgaW5ub3ZhdGlvbiB3aXRob3V0IHdhaXRp bmcgbG9uZyBjeWNsZXMgdG8gc3RhbmRhcmRpemUgYSBzaW5nbGUgY29kZSBwb2ludC4NCg0KDQpJ ZiB0aGlzIGlzIHlvdXIgb2JqZWN0aXZlLCBJ4oCZZCBzdWdnZXN0IHRoYXQgc2V0dGluZyBhcHBy b3ByaWF0ZSBJQU5BIFBvbGljaWVzIGFuZCByYW5nZXMgKGluY2x1ZGluZyBGQ0ZTLCBFeHBlcnQg UmV2aWV3IGluIHBhcnRpY3VsYXIsIGFuZCBTcGVjaWZpY2F0aW9uIFJlcXVpcmVkKSB3aWxsIGFj aGlldmUgaXQgd2l0aG91dCBvdmVyY29tcGxpY2F0aW5nIHRoaW5ncy4NCg0KQmVzdCwNCg0K4oCU IENhcmxvcy4NCg== --_000_787AE7BB302AE849A7480A190F8B933008D62C31OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpi bGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5Q cmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kg SFRNTCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44 NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlJlLSw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SeKAmW0gYWZyYWlkIHRoZSDigJxGQ0ZT ICYjNDM7IFNwZWNpZmljYXRpb24gUmVxdWlyZWTigJ0gZG9lcyBub3QgYWNoaWV2ZSBnb2FsLiBJ 4oCZbSBzdXJlIHlvdSBhcmUgYXdhcmUgdGhhdCDigJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij5wZXJtYW5lbnQNCiBhbmQgcmVhZGlseSBhdmFpbGFibGXigJ0gaXMgbmVlZGVkIGZvciDi gJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5TcGVjaWZpY2F0aW9u IFJlcXVpcmVk4oCdLiBUaGUgZXhwZXJ0IHJldmlldyB3aWxsIHJlamVjdCB0aGUgcmVxdWVzdCBp ZiB0aGUgZG9jdW1lbnQgaXMgbm90IHRvIGJlIHB1Ymxpc2hlZCBhcyBhbiBSRkM6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBTcGVjaWZpY2F0aW9uIFJlcXVpcmVkIC0gVmFsdWVzIGFuZCB0aGVpciBtZWFuaW5ncyBt dXN0IGJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZG9jdW1lbnRlZCBpbiBhIHBlcm1hbmVudCBhbmQg cmVhZGlseSBhdmFpbGFibGUgcHVibGljPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3BlY2lmaWNhdGlv biwgaW4gc3VmZmljaWVudCBkZXRhaWwgc28gdGhhdCBpbnRlcm9wZXJhYmlsaXR5PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgYmV0d2VlbiBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbnMgaXMgcG9zc2li bGUuJm5ic3A7IFdoZW4gdXNlZCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTcGVjaWZpY2F0aW9uIFJl cXVpcmVkIGFsc28gaW1wbGllcyB1c2Ugb2YgYSBEZXNpZ25hdGVkPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgRXhwZXJ0LCB3aG8gd2lsbCByZXZpZXcgdGhlIHB1YmxpYyBzcGVjaWZpY2F0aW9uIGFuZDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGV2YWx1YXRlIHdoZXRoZXIgaXQgaXMgc3VmZmljaWVudGx5IGNs ZWFyIHRvIGFsbG93PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRh dGlvbnMuJm5ic3A7IFRoZSBpbnRlbnRpb24gYmVoaW5kPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgXl5eXl5eXl5eXl5eXl5eXl5eXl48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmcXVvdDtwZXJtYW5lbnQgYW5kIHJlYWRpbHkgYXZhaWxhYmxlJnF1b3Q7IGlzIHRoYXQgYSBk b2N1bWVudCBjYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlYXNv bmFibHkgYmUgZXhwZWN0ZWQgdG8gYmUgZmluZGFibGUgYW5kIHJldHJpZXZhYmxlIGxvbmc8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBhZnRlciBJQU5BIGFzc2lnbm1lbnQgb2YgdGhlIHJlcXVlc3RlZCB2 YWx1ZS4mbmJzcDsgUHVibGljYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBeXl5eXl5eXl48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBvZiBhbiBSRkMgaXMgYW4gaWRlYWwgbWVhbnMgb2YgYWNoaWV2aW5nIHRo aXMgcmVxdWlyZW1lbnQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBi dXQgU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCBpcyBpbnRlbmRlZCB0byBhbHNvIGNvdmVyIHRoZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNhc2Ugb2YgYSBkb2N1bWVudCBwdWJsaXNoZWQgb3V0c2lkZSBv ZiB0aGUgUkZDIHBhdGguJm5ic3A7IEZvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJGQyBwdWJsaWNh dGlvbiwgdGhlIG5vcm1hbCBSRkMgcmV2aWV3IHByb2Nlc3MgaXMgZXhwZWN0ZWQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB0byBwcm92aWRlIHRoZSBuZWNlc3NhcnkgcmV2aWV3IGZvciBpbnRlcm9wZXJh YmlsaXR5LCB0aG91Z2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgRGVzaWduYXRlZCBFeHBlcnQg bWF5IGJlIGEgcGFydGljdWxhcmx5IHdlbGwtcXVhbGlmaWVkPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg cGVyc29uIHRvIHBlcmZvcm0gc3VjaCBhIHJldmlldy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SSBzdGlsbCBkb27igJl0IHNlZSB0aGUg4oCcb3Zl cmNvbXBsaWNhdGluZ+KAnSB0aGluZyB5b3UgYXJlIHRhbGtpbmcgYWJvdXQuIEl0IGlzIGxpa2Ug aW5pdGlhdGluZyB0aGUgcmVnaXN0cnkgYXV0b21hdGljYWxseSB3aXRoIHZhbHVlcyBmb3IgYSBy aWNoIHJlZ2lzdHJ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IENhcmxv cyBQaWduYXRhcm8gKGNwaWduYXRhKSBbbWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbV0NCjxicj4N CjxiPkVudm95w6kmbmJzcDs6PC9iPiBsdW5kaSAyIG1haSAyMDE2IDE2OjM0PGJyPg0KPGI+w4Am bmJzcDs6PC9iPiA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkJPVUNBREFJUiBN b2hhbWVkIElNVC9PTE48YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IEppbSBHdWljaGFyZCAoamd1aWNo YXIpOyBzZmNAaWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBSZXVzZSB0aGUg SVBGSVggcmVnaXN0cnkgaW4gTlNIPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RGVhciBNZWQsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gTWF5IDIsIDIwMTYsIGF0IDEwOjI0IEFNLCA8YSBocmVmPSJtYWlsdG86 bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+DQptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+W01lZF0gTXkgaW5pdGlhbCBvYmplY3RpdmUgaXMg dG8gZm9zdGVyIHNlcnZpY2UgaW5ub3ZhdGlvbiB3aXRob3V0IHdhaXRpbmcgbG9uZyBjeWNsZXMg dG8gc3RhbmRhcmRpemUgYSBzaW5nbGUgY29kZSBwb2ludC48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhp cyBpcyB5b3VyIG9iamVjdGl2ZSwgSeKAmWQgc3VnZ2VzdCB0aGF0IHNldHRpbmcgYXBwcm9wcmlh dGUgSUFOQSBQb2xpY2llcyBhbmQgcmFuZ2VzIChpbmNsdWRpbmcgRkNGUywgRXhwZXJ0IFJldmll dyBpbiBwYXJ0aWN1bGFyLCBhbmQgU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCkgd2lsbCBhY2hpZXZl IGl0IHdpdGhvdXQgb3ZlcmNvbXBsaWNhdGluZyB0aGluZ3MuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAlCBDYXJsb3MuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B933008D62C31OPEXCLILMA3corp_-- From nobody Mon May 2 07:44:15 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611EA12D1DA; Mon, 2 May 2016 07:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 E30z9mGl4Zh8; Mon, 2 May 2016 07:44:11 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41CD212D1AC; Mon, 2 May 2016 07:44:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=57422; q=dns/txt; s=iport; t=1462200251; x=1463409851; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fdBl/mZUHo3DbmxBfaXlW829HOzcgHCGV0eVNchfUA0=; b=D7w9cg2tOcFLZhmYK8ZqYHoqAaAIXRgTQ04rCLDFnOWUojyraj+2toGS 2IdFgHPN+IsutKcEF6+nnUIpK7CesVo7C/IFR9zkbQFLC+PK4B/rSD7R7 Stkf4Ob08umVbzfa8znMOZdUd2oV4fHxnpftlSmj4LIddaqIzkqzkxnEs 8=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAwAPZydX/4ENJK1dgmxMU30GuXAOg?= =?us-ascii?q?XIEFwEKhW4CgSw4FAEBAQEBAQFlHAuEQQEBAQMBAQEBGgZEBwsFCwIBCBEDAQI?= =?us-ascii?q?BIAEGAwICJwsUCQgCBA4FCQUNiAcIDqknkEkBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QENCIYhgXYIgk6EDxACATsWgkorgisFh3CLM4RxAYMngWdtiByBZ4RNiF2GPYh?= =?us-ascii?q?zAR4BQ4IFG4FLbAGIB38BAQE?= X-IronPort-AV: E=Sophos;i="5.24,567,1454976000"; d="asc'?scan'208,217";a="266788456" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 May 2016 14:44:09 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u42Ei9uO023225 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 May 2016 14:44:09 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 May 2016 10:44:08 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Mon, 2 May 2016 10:44:08 -0400 From: "Carlos Pignataro (cpignata)" To: "mohamed.boucadair@orange.com" Thread-Topic: [sfc] Call for WG adoption of draft-penno-sfc-appid-03 Thread-Index: AQHRZQHOvGZf31kz6UifjJTvmDJQAZ+hr9aAgARTiaCAAGltAP//xfBAgABId4A= Date: Mon, 2 May 2016 14:44:08 +0000 Message-ID: <30650369-47D3-4387-B535-C2B7756B246A@cisco.com> References: <787AE7BB302AE849A7480A190F8B933008D62994@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <3501127B-E55B-4FA1-9A63-47D046371132@cisco.com> <787AE7BB302AE849A7480A190F8B933008D62C02@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D62C02@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.245.225] Content-Type: multipart/signed; boundary="Apple-Mail=_F70D6DB0-5661-46DA-8404-C7747E82F1D2"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "draft-penno-sfc-appid@ietf.org" , "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-appid-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 14:44:14 -0000 --Apple-Mail=_F70D6DB0-5661-46DA-8404-C7747E82F1D2 Content-Type: multipart/alternative; boundary="Apple-Mail=_DB8194D5-2E47-44A8-A8CB-9A681B4764AC" --Apple-Mail=_DB8194D5-2E47-44A8-A8CB-9A681B4764AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Med, Trying to extract the key statements from the line-by-line reply, you = said: > Given this goal of conveying application information, we found one = specific syntax leveraging the Application Information structure from = IPFIX. > [Med] Which makes sense. I fully agree with that. Apologies in advance for asking again, but, what exactly is your concern = with this document (beyond your proposal to use IPFIX IEs for = everything)? Some additional follow-ups for closure inline. > On May 2, 2016, at 10:32 AM, mohamed.boucadair@orange.com wrote: >=20 > Re-, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > De : Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com = ] > Envoy=C3=A9 : lundi 2 mai 2016 15:53 > =C3=80 : BOUCADAIR Mohamed IMT/OLN > Cc : Jim Guichard (jguichar); sfc@ietf.org ; = draft-penno-sfc-appid@ietf.org > Objet : Re: [sfc] Call for WG adoption of draft-penno-sfc-appid-03 >=20 > Dear Med, >=20 > Thanks for taking the time to review and comment. Please find some = comments inline. >=20 > On May 2, 2016, at 7:58 AM, mohamed.boucadair@orange.com = wrote: >=20 > Hi Jim, all, >=20 > I interpret this proposal as if it wants to inherit the IPFIX = Application information to be conveyed in an nsh header. I have some = issues with the rationale of this draft, not its goal per se. >=20 > I do not support this draft. I do think there are other design choices = that can be investigated by the WG to inherit existing IPFIX IEs without = writing a new RFC for it for EACH IE to be conveyed in an NSH header. >=20 > I believe you are misunderstanding what draft-penno-sfc-appid-03 is = about. The goal is to convey application information in SFC Metadata. It = is not to inherit existing IPFIX IEs. > [Med] You may be right but the document explicitly says: >=20 > This document purposes the use of IPFIX [RFC7011 = ] application > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > information to be carried in the NSH context metadata of a MDType-1 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > packet. >=20 >=20 Abstract This document proposes to use the structured application information in the service function chaining metadata, and specifies a YANG model for the configuration of the application registry. > Given this goal of conveying application information, we found one = specific syntax leveraging the Application Information structure from = IPFIX. > [Med] Which makes sense. I fully agree with that. >=20 > I wanted to clarify the difference, as it is significance. >=20 > If there are other design choices *to convey application = identification* (not to inherit existing fields from anywhere as a = goal), we=E2=80=99d love to hear them. > [Med] Who is asking to =E2=80=9Cinherit existing fields=E2=80=9D? >=20 > This specific proposal compiles and runs. >=20 >=20 >=20 > For example, there is a more general proposal that aims to import ANY = IPFIX Information Element (that will cover the particular case in this = document):http://www.ietf.org/mail-archive/web/sfc/current/msg04492.html = without = consuming the WG effort to edit/review/publish RFCs for each promising = IPFIX IEs. >=20 >=20 > I believe this will cause more headaches than solutions =E2=80=94 I = replied in a separate note. >=20 >=20 > Further, I have the following questions for the draft: >=20 > =C2=B7 Why reserving this proposal for MD#1? >=20 > Because that is the minimal one to use. > [Med] I don=E2=80=99t parse this, sorry. >=20 > However, this is also defined for MD-Type 2 at = https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01#page-7 = (see = =E2=80=9C5. Application ID=E2=80=9D) > [Med] I don=E2=80=99t think it is a good idea to have a lot of = documents to define the same set of information. >=20 Noted. Thank you. > Do you suggest we should define MD-Type 2 in this draft as well? Happy = to do so if that=E2=80=99s useful. > [Med] No, I=E2=80=99m not proposing that. I=E2=80=99m trying to = understand the technical rationale for that choice. >=20 This doc defines MD-Type 1, and the TLV doc defines MD-Type 2 for a = bunch of things. If you have an editorial or information arrangement proposal, please do = share. Happy to accommodate to make things easier to parse. >=20 > =C2=B7 What means the following headers? > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 3 | 0 | 161 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Network Shared Context | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Service Platform Context | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Service Shared Context | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Figure 2: Example of Metadata Including the SNMP Application > Identification >=20 >=20 >=20 > It is an example of metadata including the SNMP application = identification. > [Med] My question was maybe not clear: what a Network Shared Context? = What is a Service Platform Context? What is Service Shared Context? >=20 Ah, thanks for the clarification. These are remainders from earlier = versions of draft-ietf-sfc-nsh, which we have to fix. This is a good = adoption comment and a good catch. Best, =E2=80=94 Carlos. > Best, >=20 > =E2=80=94 Carlos. >=20 >=20 > Cheers, > Med >=20 > De : sfc [mailto:sfc-bounces@ietf.org ] = De la part de Jim Guichard (jguichar) > Envoy=C3=A9 : vendredi 29 avril 2016 18:31 > =C3=80 : sfc@ietf.org > Objet : [sfc] Call for WG adoption of draft-penno-sfc-appid-03 >=20 > Dear WG: >=20 > We did not receive many responses for this call for adoption and = therefore would like to re-invite people to post their thoughts on = adopting this document into the SFC WG. The call for adoption will run = for a further 2 weeks ending 6/13/2016. >=20 > Thanks! >=20 > SFC Chairs >=20 > From: Jim Guichard > > Date: Thursday, February 11, 2016 at 3:24 PM > To: "sfc@ietf.org " > > Subject: Call for WG adoption of draft-penno-sfc-appid-03 >=20 > Dear WG: >=20 > This email serves as a call for WG adoption of = draft-penno-sfc-appid-03 as a WG document. The call for adoption will = run for 2 weeks ending 2/25/2016. >=20 > Please note that this is a call for adoption, and not a last call for = content of the document. Adopting a WG document simply means that the WG = will focus its efforts on that particular draft going forward, and use = that document for resolving open issues and documenting the WG=E2=80=99s = decisions. >=20 > Please indicate whether you support adoption for not, and if not why. = Issues you have with the current document itself can also be raised, but = they should be raised in the context of what should be changed in the = document going forward, rather than a pre-condition for adoption. >=20 > Finally, now is also a good time to poll for knowledge of any IPR that = applies to this draft, in line with the IPR disclosure obligations for = WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). = If you are listed as a document author please respond to this email (to = the chairs) whether or not you are aware of any relevant IPR. >=20 > Thanks! >=20 > SFC Chairs > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc = >=20 --Apple-Mail=_DB8194D5-2E47-44A8-A8CB-9A681B4764AC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear Med,

Trying to extract the key statements from the line-by-line = reply, you said:

Given this goal of conveying application = information, we found one specific syntax leveraging the Application = Information structure from IPFIX.
[Med] Which makes sense. I = fully agree with that.

Apologies in advance for asking again, = but, what exactly is your concern with this document (beyond your = proposal to use IPFIX IEs for everything)?


Some= additional follow-ups for closure inline.

On = May 2, 2016, at 10:32 AM, mohamed.boucadair@orange.com wrote:

Re-,
 
Please see inline.
 
Cheers,
Med
 
De : Carlos Pignataro (cpignata) = [mailto:cpignata@cisco.com] 
Envoy=C3=A9 : lundi 2 mai 2016 15:53
=C3=80 : BOUCADAIR Mohamed = IMT/OLN
Cc : Jim Guichard = (jguichar); sfc@ietf.org; draft-penno-sfc-appid@ietf.org
Objet : Re: [sfc] Call for WG = adoption of draft-penno-sfc-appid-03
 
Dear Med,
 
Thanks for taking the time to review and comment. = Please find some comments inline.
 
On May 2, 2016, at = 7:58 AM, mohamed.boucadair@orange.com wrote:
 
Hi Jim, all,
 
I interpret this proposal as if it wants to = inherit the IPFIX Application information to be conveyed in an nsh = header. I have some issues with the rationale of this draft, not its = goal per se.
 
I do not support this draft. I do think there = are other design choices that can be investigated by the WG to inherit = existing IPFIX IEs without writing a new RFC for it for EACH IE to be = conveyed in an NSH header. 
 
I believe you are misunderstanding what = draft-penno-sfc-appid-03 is about. The goal is to convey application = information in SFC Metadata. It is not to inherit existing IPFIX = IEs.
[Med] You may be right but the document explicitly says:
 
   This document = purposes the use of IPFIX [RFC7011] = application
          &nb= sp;            = ;   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   information to be carried in the NSH context = metadata of a MDType-1
   = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   packet.
 
 


Abstract

   This document proposes to use the structured = application information
   in the service = function chaining metadata, and specifies a YANG model
   for the configuration of the application = registry.



Given this goal of = conveying application information, we found one specific syntax = leveraging the Application Information structure from IPFIX.
[Med] Which makes sense. I fully agree with that.
 
I wanted = to clarify the difference, as it is significance.
 
If there = are other design choices *to convey application identification* = (not to inherit existing fields from anywhere as a goal), we=E2=80=99d = love to hear them. 
[Med] Who is asking to = =E2=80=9Cinherit existing fields=E2=80=9D?
 
This specific proposal compiles and = runs.


 
For = example, there is a more general proposal that aims to import ANY IPFIX = Information Element (that will cover the particular case in this = document):http://www.ietf.org/mail-archive/web/sfc/current/msg04492.html<= /span> without = consuming the WG effort to edit/review/publish RFCs for each promising = IPFIX IEs.
 
 
I believe this will = cause more headaches than solutions =E2=80=94 I replied in a separate = note.


Further, I have the following questions for the = draft:
 
=C2=B7         Why = reserving this proposal for MD#1?
 
Because that is the = minimal one to use. 
[Med] I don=E2=80=99t parse this, sorry.
 
However, this is also = defined for MD-Type 2 at https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01#page-7 (see =E2=80=9C5. =   Application = ID=E2=80=9D)
[Med] I don=E2=80=99t think it is a good idea = to have a lot of documents to define the same set of information.
 

Noted. Thank = you.


Do you suggest we should define MD-Type 2 in this draft as = well? Happy to do so if that=E2=80=99s useful.
[Med] No, I=E2=80=99m not proposing that. I=E2=80=99m trying = to understand the technical rationale for that choice.


This doc defines = MD-Type 1, and the TLV doc defines MD-Type 2 for a bunch of = things.

If you have an editorial or = information arrangement proposal, please do share. Happy to accommodate = to make things easier to parse.



=C2=B7         What = means the following headers?
      = 0            &= nbsp;      = 1            &= nbsp;      = 2            &= nbsp;      3
      0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     = |       = 3       = |        = 0      = |            &= nbsp; = 161            = ;  |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     = |            =       Network Shared = Context           &= nbsp;           = |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     = |            &= nbsp;     Service Platform = Context           &= nbsp;         |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     = |            &= nbsp;     Service Shared = Context           &= nbsp;           = |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
       Figure = 2: Example of Metadata Including the SNMP Application
          &nb= sp;            = ;       Identification
 
 
 
It is an example of metadata including the SNMP = application identification.
[Med] My question was = maybe not clear: what a Network = Shared Context? What is a Service Platform Context? What is Service = Shared Context?
 

Ah, thanks for the = clarification. These are remainders from earlier versions of = draft-ietf-sfc-nsh, which we have to fix. This is a good adoption = comment and a good catch.

Best,

=E2=80=94 = Carlos.

Best,
 
=E2=80=94 Carlos.


Cheers,
Med
 
De : sfc= [mailto:sfc-bounces@ietf.org] De la part = de Jim Guichard = (jguichar)
Envoy=C3=A9 : vendredi 29 avril 2016 = 18:31
=C3=80 : sfc@ietf.org
Objet : [sfc] Call for WG adoption = of draft-penno-sfc-appid-03
 
Dear WG:
 
We did not receive many = responses for this call for adoption and therefore would like to = re-invite people to post their thoughts on adopting this document into = the SFC WG. The call for adoption will run for a further 2 weeks ending = 6/13/2016. 
 
Thanks!
 
SFC Chairs
 
From: Jim Guichard <jguichar@cisco.com>
Date: Thursday, February 11, = 2016 at 3:24 PM
To: "sfc@ietf.org" <sfc@ietf.org>
Subject: Call for WG adoption of = draft-penno-sfc-appid-03
 
Dear = WG:
 
This email = serves as a call for WG adoption of draft-penno-sfc-appid-03 as a WG = document. The call for adoption will run for 2 weeks ending = 2/25/2016.
 
Please note = that this is a call for adoption, and not a last call for content of the = document. Adopting a WG document simply means that the WG will focus its = efforts on that particular draft going forward, and use that document = for resolving open issues and documenting the WG=E2=80=99s = decisions.
 
Please = indicate whether you support adoption for not, and if not why. Issues = you have with the current document itself can also be raised, but they = should be raised in the context of what should be changed in the = document going forward, rather than a pre-condition for = adoption. 
 
Finally, now is also a good time to poll for knowledge of any = IPR that applies to this draft, in line with the IPR disclosure = obligations for WG participants (see RFCs 3979, 4879, 3669 and 5378 for = more details). If you are listed as a document author please respond to = this email (to the chairs) whether or not you are aware of any relevant = IPR.
 
Thanks!
 
SFC Chairs
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
 
= --Apple-Mail=_DB8194D5-2E47-44A8-A8CB-9A681B4764AC-- --Apple-Mail=_F70D6DB0-5661-46DA-8404-C7747E82F1D2 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 - http://gpgtools.org iQIcBAEBCAAGBQJXJ2e3AAoJEIXgpQGOZny9Zh8QAKyhBVsvnF7hlAITRjpycxWm eTY+Rs5NAnGSfWD+A04xPkx2IAg5sz16EsaTjxPLa2BRvWw1H6apBepYwAdqpPIs X/8C8NTJO68JdjgMCpLPLw+sn/2HiBZrgwX/3h7ECZ+2SoP3nFmR1d1UjO0wiLJq bAUbg2do6hoFdSEQ2BvzwYKko9G+sJquFi554IOjMunlxMC/tDEF4RvNx16YpzoM XQsrgLiLM2/4d3qVacTBtPLmbNl+UxBFTrKuA4vsFcrnn6aYRCgNRh8oOd7SIpp5 0BFA4ZJ3AjTz6CePfRkBqU8D1ZWwsdLPIVYbB1ZqXGZqqXnarM9ennXqi9iN/CRh tLYje1aWkWFr2h2DHcQqoZl6RmZJJSpaMWwQ2xYnOuoFJDbtxzWk9Mjy/yhPXIbE JTz4yOMNQV0Y5T8bDNKvHKI3PB0cz/f6dqR5DxWlLzh7fBqgi0/FZR/BP9OSjbvd w9MEWba+nGECmN7H73vCjiYVWAhGS2/8GKPGUZpSYtgnGBu5PAfcxH61HOzXub7X ga/t+CQy1vsqzj9KaRzgd2dY5kJGvR1X4JVEHTja72KVhohAh6H23625/gJQ7cKK lEFawXJclihoqRLxmhLRTeexkTeESoRpgZ2syoq2y70UHmvp76ar5eRdc9kRUBqG HU/IHc1aOlpNnqLTqRVN =Febm -----END PGP SIGNATURE----- --Apple-Mail=_F70D6DB0-5661-46DA-8404-C7747E82F1D2-- From nobody Mon May 2 07:51:50 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6062812B02D for ; Mon, 2 May 2016 07:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 VHofFypvxLzw for ; Mon, 2 May 2016 07:51:47 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6696512D0E5 for ; Mon, 2 May 2016 07:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24931; q=dns/txt; s=iport; t=1462200706; x=1463410306; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/HnOzs4PfaFDaF8A346Fz58XxxQGv7RPBnQqa5iLgZ0=; b=m5bfRZbwVb1eGTXJLxvSXwWUwJHeKkAC/hoQl4Q/wlqcBk3CAh7VKpa/ IH+vqKfUMPnl7EY746ZhIz37NogHo2PYhrVfyhv8OSDassgtjlS2fwmJe Br4d910AuRxA82azvwUpoT+1mlMa2QH2o5drRQ35mrC7opMNfuQ+eyGUz M=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAwC0aCdX/4UNJK1egmxMgVAGt2GCD?= =?us-ascii?q?w6BdoYQAoEtOBQBAQEBAQEBZRwLhEEBAQEDASNIDgULAgEIGCAHAwICMhQRAgQ?= =?us-ascii?q?OBQ6IFAipQJBMAQEBAQEBAQEBAQEBAQEBAQEBAQEBDQiGIYF2glaEc4JKK4IrB?= =?us-ascii?q?ZgUAYMngWeJCYFnhE2IXY8wAR4BQ4IFG4FLbIgIfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,567,1454976000"; d="asc'?scan'208,217";a="98201356" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 May 2016 14:51:45 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u42EpiCm023487 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 May 2016 14:51:45 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 May 2016 10:51:44 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Mon, 2 May 2016 10:51:44 -0400 From: "Carlos Pignataro (cpignata)" To: "mohamed.boucadair@orange.com" Thread-Topic: Reuse the IPFIX registry in NSH Thread-Index: AQHRpHiwfFVWYWvPeEiiAjrA4JW4V5+l9suAgAACtoD//70OoIAAR9aA Date: Mon, 2 May 2016 14:51:43 +0000 Message-ID: <21509E9B-797F-4B3E-8C0B-99657EEF005D@cisco.com> References: <787AE7BB302AE849A7480A190F8B933008D62994@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2D398770-C83E-48FE-BBE9-574A58871700@cisco.com> <787AE7BB302AE849A7480A190F8B933008D62BEB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <05CF8496-033A-4B1F-AA5D-E16A8B6ED09E@cisco.com> <787AE7BB302AE849A7480A190F8B933008D62C31@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D62C31@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.245.225] Content-Type: multipart/signed; boundary="Apple-Mail=_0665B213-EF1F-4050-854D-06AFCD246A29"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] Reuse the IPFIX registry in NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 14:51:49 -0000 --Apple-Mail=_0665B213-EF1F-4050-854D-06AFCD246A29 Content-Type: multipart/alternative; boundary="Apple-Mail=_C75CE9C9-B591-4130-A1CF-C970A7FED516" --Apple-Mail=_C75CE9C9-B591-4130-A1CF-C970A7FED516 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Med, Your response is somehow truncating what I said, which changes the = meaning. You are quoting me here as saying: > I=E2=80=99m afraid the =E2=80=9CFCFS + Specification Required=E2=80=9D = does not achieve goal. But what I wrote is: > =E2=80=9C(including FCFS, Expert Review in particular, and = Specification Required)" Let me please highlight the =E2=80=9CExpert Review in particular=E2=80=9D = portion. The =E2=80=9Cin particular=E2=80=9D text was meant as an = emphasizer. The IPFIX IE registry uses Expert Review, with a group of = IPFIX (not SFC necessarily) experts. And yes, Spec Required is useful = for interacting with other SDOs. Please note, I do not want to hog the SFC list; this response summarizes = my position well enough. Best, =E2=80=94 Carlos. > On May 2, 2016, at 10:42 AM, mohamed.boucadair@orange.com wrote: >=20 > Re-, >=20 > I=E2=80=99m afraid the =E2=80=9CFCFS + Specification Required=E2=80=9D = does not achieve goal. I=E2=80=99m sure you are aware that =E2=80=9Cperman= ent and readily available=E2=80=9D is needed for =E2=80=9CSpecification = Required=E2=80=9D. The expert review will reject the request if the = document is not to be published as an RFC: >=20 > Specification Required - Values and their meanings must be > documented in a permanent and readily available public > specification, in sufficient detail so that = interoperability > between independent implementations is possible. When = used, > Specification Required also implies use of a Designated > Expert, who will review the public specification and > evaluate whether it is sufficiently clear to allow > interoperable implementations. The intention behind > ^^^^^^^^^^^^^^^^^^^^ > "permanent and readily available" is that a document can > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > reasonably be expected to be findable and retrievable long > after IANA assignment of the requested value. Publication > ^^^^^^^^^ > of an RFC is an ideal means of achieving this requirement, > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > but Specification Required is intended to also cover the > case of a document published outside of the RFC path. For > RFC publication, the normal RFC review process is expected > to provide the necessary review for interoperability, = though > the Designated Expert may be a particularly well-qualified > person to perform such a review. >=20 > I still don=E2=80=99t see the =E2=80=9Covercomplicating=E2=80=9D thing = you are talking about. It is like initiating the registry automatically = with values for a rich registry. >=20 > Cheers, > Med >=20 > De : Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com = ] > Envoy=C3=A9 : lundi 2 mai 2016 16:34 > =C3=80 : BOUCADAIR Mohamed IMT/OLN > Cc : Jim Guichard (jguichar); sfc@ietf.org > Objet : Re: Reuse the IPFIX registry in NSH >=20 > Dear Med, >=20 > On May 2, 2016, at 10:24 AM, mohamed.boucadair@orange.com = wrote: >=20 > [Med] My initial objective is to foster service innovation without = waiting long cycles to standardize a single code point. >=20 >=20 > If this is your objective, I=E2=80=99d suggest that setting = appropriate IANA Policies and ranges (including FCFS, Expert Review in = particular, and Specification Required) will achieve it without = overcomplicating things. >=20 > Best, >=20 > =E2=80=94 Carlos. --Apple-Mail=_C75CE9C9-B591-4130-A1CF-C970A7FED516 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear Med,

Your response is somehow truncating what I said, which = changes the meaning. You are quoting me here as saying:
I=E2=80=99m afraid the =E2=80=9CFCFS = + Specification Required=E2=80=9D does not achieve = goal.

But what I wrote is:
=E2=80=9C(including FCFS, Expert = Review in particular, and Specification = Required)"

Let me please highlight the =E2=80=9CExpert Review in particular=E2=80=9D portion. The = =E2=80=9Cin particular=E2=80=9D text was meant as an emphasizer. The = IPFIX IE registry uses Expert Review, with a group of IPFIX (not SFC = necessarily) experts. And yes, Spec Required is useful for interacting = with other SDOs.

Please note, I do not want to hog the SFC list; this response = summarizes my position well enough.

Best,

=E2=80=94 Carlos.

On May 2, 2016, at 10:42 AM, mohamed.boucadair@orange.com wrote:

Re-,
 
I=E2=80=99m afraid the =E2=80=9CFC= FS + Specification Required=E2=80=9D does not achieve goal. I=E2=80=99m = sure you are aware that =E2=80=9Cpermanent and readily available=E2=80=9D is needed for = =E2=80=9CSpecification Required=E2=80=9D. = The expert review will reject the request if the document is not to be = published as an RFC:
 
      Specification = Required - Values and their meanings must be
          &nb= sp; documented in a permanent and readily available public
          &nb= sp; specification, in sufficient detail so that interoperability
          &nb= sp; between independent implementations is possible.  When = used,
          &nb= sp; Specification Required also implies use of a Designated
          &nb= sp; Expert, who will review the public specification and
          &nb= sp; evaluate whether it is sufficiently clear to allow
          &nb= sp; interoperable implementations.  The intention behind
          &nb= sp;            = ;            &= nbsp;        ^^^^^^^^^^^^^^^^^^^^
          &nb= sp; "permanent and readily available" is that a document can
          &nb= sp; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          &nb= sp; reasonably be expected to be findable and retrievable long
          &nb= sp; after IANA assignment of the requested value.  Publication
          &nb= sp;            = ;            &= nbsp;           &nb= sp;           = ^^^^^^^^^
          &nb= sp; of an RFC is an ideal means of achieving this requirement,
          &nb= sp; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          &nb= sp; but Specification Required is intended to also cover the
          &nb= sp; case of a document published outside of the RFC path.  For
          &nb= sp; RFC publication, the normal RFC review process is expected
          &nb= sp; to provide the necessary review for interoperability, though
          &nb= sp; the Designated Expert may be a particularly well-qualified
          &nb= sp; person to perform such a review.
 
I still don=E2=80=99t see the = =E2=80=9Covercomplicating=E2=80=9D thing you are talking about. It is = like initiating the registry automatically with values for a rich = registry.
 
Cheers,
Med
 
De : Carlos Pignataro (cpignata) = [mailto:cpignata@cisco.com] 
Envoy=C3=A9 : lundi 2 mai 2016 16:34
=C3=80 : BOUCADAIR Mohamed IMT/OLN
Cc : Jim Guichard = (jguichar); sfc@ietf.org
Objet : Re: Reuse the IPFIX = registry in NSH
 
Dear Med,
 
On May 2, 2016, at = 10:24 AM, mohamed.boucadair@orange.com wrote:
 
[Med] My initial objective = is to foster service innovation without waiting long cycles to = standardize a single code point.
 
 
If this is your objective, I=E2=80=99d suggest that = setting appropriate IANA Policies and ranges (including FCFS, Expert = Review in particular, and Specification Required) will achieve it = without overcomplicating things.
 
Best,
 
=E2=80=94 = Carlos.

= --Apple-Mail=_C75CE9C9-B591-4130-A1CF-C970A7FED516-- --Apple-Mail=_0665B213-EF1F-4050-854D-06AFCD246A29 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 - http://gpgtools.org iQIcBAEBCAAGBQJXJ2l/AAoJEIXgpQGOZny9neIQAIRBgM/heI7kexQ7BtD8MAW8 uHfGVGOR31S5Q3N8owSk1S5XS40P+wWu9x2HP7mof5zc2FrZuGnnVJcaKj/H4Im9 N3G70729u4ufmGt9eBa/XzEPkcI6oJIJX0G1Wd6q+BvunxHRjC9hHZ+AfxS7S6cS VWw3H//YLUcjMBZ+qoO6hUzZOG7JZuvdq9QfnEoo2w4uvQzbpN+TN0vIr7aUC9KZ DNd3R3e+54Om2/iFH5FJTzX5A5TXKfGfXTe8NKD0bm0WfHWqltpe8HmV/s8cRXsP ZrDggh9AXDdQnNxcuQVtnBlbfGnqxRSDng442SViSAGH+x5JIsu9eA7UuPfzNdPN C5uUW/v4S4IkUQOGo+d8bicVrYULv9rxko7bWEbdUq1V1mqkczbdZPsqag1WWX2i xD+bleiHpZhG65ghWABF+dTQAJS8d5Df6P9OOkCxD+cZUKU86RuCAlWdxpQRawBf wVWAdGqkFUEeaXkqGmWlYkoFQgTGjp6wfYr/QLKL/b24uyS517Zu66gmrv29k0GE E3n74XqLEdjn6TsuDnxAgjHB0Blxgednfez/+dBhtcskZC44N2kqa5xMNdmt2r0N rkBnY3uIqM88Uf0/cCzDDgra8uue8omhcnoUac1uBQnPg19Dr4JsoE7Nil0svd/t V6R/+wXJphSTDWaiEVQb =LWw1 -----END PGP SIGNATURE----- --Apple-Mail=_0665B213-EF1F-4050-854D-06AFCD246A29-- From nobody Mon May 2 07:56:58 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBC712B01D for ; Mon, 2 May 2016 07:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 RMqkTGfCMC2O for ; Mon, 2 May 2016 07:56:53 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 D8D1F12B013 for ; Mon, 2 May 2016 07:56:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id BFCEE26464D; Mon, 2 May 2016 07:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1462201013; bh=xX/xljxkS5VRnGliMdE4ML54pRDZd3TmRlNyGeX4EZI=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=N1djfm+zGED4QCZIXdVDcvfIKDBbnLDX82yA2zmNbndGnETdw9KdO7uGAsdzsG55T yetx2KgT2wCGEmM98AXjl7pYr3QbsJmWaa2QHRM37eucuLJ1EJapSx/vTgDlDn64k7 YSy6G2fMpLIiCHngWu1F7onG3byCyccE3tMOj2wM= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id CF60526451C; Mon, 2 May 2016 07:56:52 -0700 (PDT) To: mohamed.boucadair@orange.com, "Carlos Pignataro (cpignata)" References: <787AE7BB302AE849A7480A190F8B933008D62994@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2D398770-C83E-48FE-BBE9-574A58871700@cisco.com> <787AE7BB302AE849A7480A190F8B933008D62BEB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: "Joel M. Halpern" Message-ID: <179bc64c-be11-ef2d-81d1-75ef25fa3f99@joelhalpern.com> Date: Mon, 2 May 2016 10:56:28 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D62BEB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] Reuse the IPFIX registry in NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 14:56:56 -0000 I rather like the idea of being able to use any IPFIX ID that is useful for metadata. Unfortunately, it doesn't work. The IPFIX Identifiers are associated with a type, and a fixed length encoding. That will not work directly for SFC MD-2 carriage. So we would have to define how to carry each thing, and watch out for new data types being added which we had not described. Put simply Med, while I wish the IPFIX IE registry was just a list of IDs and description, that is not what it is. It also has associated syntax and semantics (identifier, counter, ...) which make application to SFC more complex. Yours, Joel On 5/2/16 10:24 AM, mohamed.boucadair@orange.com wrote: > Hi Carlos, > > > > Please see inline. > > > > Cheers, > > Med > > > > *De :*Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] > *Envoyé :* lundi 2 mai 2016 15:44 > *À :* BOUCADAIR Mohamed IMT/OLN > *Cc :* Jim Guichard (jguichar); sfc@ietf.org > *Objet :* Reuse the IPFIX registry in NSH > > > > Dear Med, > > > > Since you are making a generic comment outside the scope > of draft-penno-sfc-appid-03, > > [Med] Perhaps I misunderstood the proposal, but Reinaldo’s draft says > the following: > > > > This document purposes the use of IPFIX [RFC7011 > ] application > > information to be carried in the NSH context metadata of a MDType-1 > > packet. > > > > So, I don’t think it is outside the scope of that discussion. My > position is simple: instead of looking at an individual proposal (that > may have its merit), what if we consider an approach that does not > require the involvement of the WG to reused another IPFIX IE. > > > > I thought it appropriate to extract that comment, and reply to it under > separate cover (updating also the Subject line) > > [Med] I disagree this is out of scope of that discussion, but I’m open > to discuss whatever the title of thread is. > > > > On May 2, 2016, at 7:58 AM, mohamed.boucadair@orange.com > wrote: > > > > For example, there is a more general proposal that aims to import > ANY IPFIX Information Element (that will cover the particular case > in this > document):http://www.ietf.org/mail-archive/web/sfc/current/msg04492.html without > consuming the WG effort to edit/review/publish RFCs for each > promising IPFIX IEs. > > > > > > There have been a number of responses on the list highlighting the > significant drawbacks of this proposal. However, although I agree with > those, I think I have not yet replied enlist. > > > > Here’s my view. > > > > The IPFIX Information Elements registry contains over 450 entries. > > [Med] This is an argument that a piece of information that is needed in > the context of SFC is likely to be defined in that rich list. > > > > It also has data types, semantics, and units associated with them. > > [Med] I don’t see any issue there. > > > > These are in support of a protocol for transmitting Traffic Flow > Information. > > [Med] I don’t see the link with the proposal on the table. This part is > not needed at all! > > > > Looking at the SFC Architecture at RFC 7665, the Metadata is used for a > completely different purpose. > > [Med] The IPFIX proposal is about identifying a piece of information NOT > about how to use it. > > > > Yes, there is intersection with some IPFIX fields. But there’s also > intersection with the IF-MIB. > > [Med] I won’t comment this part because it tries to mix things. > > > > First, IPFIX is not a superset of all the information needed. > > [Med] Agree. I never claimed that! > > > > Looking at the WG doc on mobility and DC, and the various allocation > drafts, not every fields is in IPFIX. > > [Med] The proposal is not about reusing all the fields in IPFIX, but to > reuse the ** IPFIX IEs ** registry. > > > > Second, not every IPFIX field is needed in SFC (certainly not the 450+). > > [Med] I never claimed that, too! > > > > The corollary of this is that there are a number of associated problems > with the proposal: > > 1. Does an SFC implementation need to support all (ever growing) IPFIX IEs? > > Med: There is no mandatory-to-support metadata as far as I know. This > should be part of an RFP and deployment decision. The question you > raised applies for all TLVs. > > > > 2. Do you propose to specify profiles of IPFIX, which include a subset > to be used? That seems in practice more difficult than the direct > alternative. > > [Med] No. I’m reproducing here what I answered in another thread: The > proposal is not about reusing the IPFIX format, but IPFIX registry. The > TLV format as described in the nsh draft will be used. With the approach > I’m proposing here: > > • if you need to include a FlowID, you just need to set the registry > ID to 1, and the type to 14. > > • If you need to include a vlandID, you just need to set the registry > ID to 1, and the type to 58. > > • .. > > This is almost close to what Reinaldo’s draft is doing except the > authors use a mandatory field. > > > > > > 3. Regarding fields not defined in IPFIX, does SFC need to specify a new > IPFIX IE, and specify how it would be used with IPFIX? > > [Med] No. > > > > 4. What about newly defined IPFIX fields after the publishing of the NSH > documents? > > [Med] I don’t see any issue there at all! We don’t care about IPFIX > FIELDS, but about the information elements and their code points. Here > is the proposal I shared on the list, fwiw: > > > > ==PROPOSAL==== > > > > Base version > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |Class | Type | FLAGS | Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > // Data (Variable) // > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > The description of the fields is as follows: > > > > Class: In order to foster service innovation, this field > > allows to inherit from existing code point registries that are > > likely to be useful in a SFC context. The following values are > > reserved by this specification: > > 0: See IANA section. > > 1: IPFIX [IPFIX]. > > > > Type: Indicates the code point of the context element. If > > "Class" field is non-null, the interpretation of this field MUST > > conform to the one defined for that specific class registry. > See IANA section. > > === > > > > How are those vetted for applicability to SFC? > > [Med] I don’t understand the point here. Can you please explicit your > point? Thanks. > > > > 5. What is SFC needs a different data type for a field? > > [Med] This can be defined in a dedicated TLV document. > > > > > > In my opinion, all of this result in a lot more work and uncertainty > than actually defining what’s needed. > > [Med] I’m afraid this is pure speculation. I provided the example of > vlanid, flowid. I can provide example about the source IP address, > source port, protocol, etc. > > > > I expect some SFC/NSH use cases to use an ifIndex for example. This does > not imply that SFC need to import somehow the full IF-MIB. > > [Med] I don’t see the parallel here. > > > > Similarly, I expect SFC/NSH can use specific fields or values from > various places, when it makes sense. > > [Med] This is not part of the proposal! > > > > I do not expect NSH needing to import all of those. > > > > In summary, I believe this proposal is harmful to NSH on the above > technical grounds. > > [Med] My initial objective is to foster service innovation without > waiting long cycles to standardize a single code point. > > > > As a general proposal, it seems to me like a cannon to kill a fly. > > [Med] I hope things are more clear now after my responses. > > > > I expect SFC might need to define things like flow specifications, it > does not mean it ought to reuse the BGP Flow Spec registries, semantics, > and syntax. > > > > That said, as SFC defines things from a flow, I expect it will not > re-invent the wheel and re-use surgically. > > > > Best, > > > > — Carlos. > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon May 2 23:18:03 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F5212D0EF; Mon, 2 May 2016 23:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 vzpEnzKzkgzP; Mon, 2 May 2016 23:17:58 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98AB112B00E; Mon, 2 May 2016 23:17:57 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 28823A077A; Tue, 3 May 2016 08:17:56 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id DB46C1C005D; Tue, 3 May 2016 08:17:55 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0279.002; Tue, 3 May 2016 08:17:55 +0200 From: To: "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] Call for WG adoption of draft-penno-sfc-appid-03 Thread-Index: AQHRZQHOvGZf31kz6UifjJTvmDJQAZ+hr9aAgARTiaCAAGltAP//xfBAgABId4CAALvlkA== Date: Tue, 3 May 2016 06:17:54 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D6310A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D62994@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <3501127B-E55B-4FA1-9A63-47D046371132@cisco.com> <787AE7BB302AE849A7480A190F8B933008D62C02@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <30650369-47D3-4387-B535-C2B7756B246A@cisco.com> In-Reply-To: <30650369-47D3-4387-B535-C2B7756B246A@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008D6310AOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Cc: "draft-penno-sfc-appid@ietf.org" , "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-appid-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 06:18:01 -0000 --_000_787AE7BB302AE849A7480A190F8B933008D6310AOPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2FybG9zLA0KDQpJIGFscmVhZHkgZXhwbGFpbmVkIHdoeSBJ4oCZbSBvYmplY3RpbmcgdG8gYWRv cHQgdGhpcyBkb2N1bWVudCBhdCB0aGlzIHN0YWdlLiBJbiBhZGRpdGlvbiB0byB0aGF0LCBJIGhh dmUgc29tZSBjb25jZXJucyB0aGF0IEnigJltIGxpc3RpbmcgYmVsb3c6DQoNCsK3ICAgICAgICAg SSBkb27igJl0IHRoaW5rIGl0IGlzIGEgZ29vZCBpZGVhIHRvIGhhdmUgYSBsb3Qgb2YgZG9jdW1l bnRzIHRvIGRlZmluZSBwaWVjZXMgb2YgaW5mb3JtYXRpb24gdGhhdCBjYW4gYmUgc3VwcGxpZWQg dXNpbmcgbnNoLg0KDQrCtyAgICAgICAgIE5vbmUgb2YgdGhlIFdHIGFkb3B0ZWQgdXNlIGNhc2Ug ZG9jdW1lbnRzIGNhbGwgZm9yIHRoZSBhcHBpZCBhcyBhIG1hbmRhdG9yeS10by1zdXBwb3J0IGlu Zm9ybWF0aW9uLg0KDQrCtyAgICAgICAgIFRoZSBhcHBpZCBkcmFmdCAodGFyZ2V0aW5nIOKAnFN0 YW5kYXJkcyBUcmFja+KAnSBzdGF0dXMpIHJlbGllcyBvbiBhICoqIFZFTkRPUiAqKiBJUEZJWCBl eHRlbnNpb24gKGFuIGluZm9ybWF0aW9uIFJGQykuIElzIHRoZXJlIGFueSByZWFzb24gd2h5IHRo YXQgaW5mb3JtYXRpb24gd2FzIG5vdCBwYXJ0IG9mIHRoZSBub3JtYWwgSVBGSVggYXNzaWdubWVu dCBwcm9jZXNzPw0KDQrCtyAgICAgICAgIFRoZXJlIGlzIGFuIElQUiBmb3IgdGhlIGFwcGlkIGRy YWZ0LiBCZWZvcmUgZW5kb3JzaW5nIHRoZSBkcmFmdCwgaXQgd291bGQgYmUgYXBwcm9wcmlhdGUg Zm9yIHRoZSBXRyB0byB1bmRlcnN0YW5kIGZpcnN0IHRoZSBwcm9ibGVtIHRvIHNvbHZlLCBhZ3Jl ZSBpdCBpcyB3b3J0aCB0byBiZSBzb2x2ZWQsIGFuZCB0aGVuIHRoZSBXRyBjYW4gc2VlIHdoZXRo ZXIgdGhlcmUgYXJlIG90aGVyIHNvbHV0aW9uIGRlc2lnbnMgd2l0aG91dCBoYXZpbmcgYW5vdGhl ciB5ZXQgU0ZDIGRvY3VtZW50IHdpdGggYW4gSVBSIG9uIGl0IQ0KDQpDaGVlcnMsDQpNZWQNCg0K RGUgOiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgW21haWx0bzpjcGlnbmF0YUBjaXNjby5j b21dDQpFbnZvecOpIDogbHVuZGkgMiBtYWkgMjAxNiAxNjo0NA0Kw4AgOiBCT1VDQURBSVIgTW9o YW1lZCBJTVQvT0xODQpDYyA6IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBzZmNAaWV0Zi5vcmc7 IGRyYWZ0LXBlbm5vLXNmYy1hcHBpZEBpZXRmLm9yZw0KT2JqZXQgOiBSZTogW3NmY10gQ2FsbCBm b3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtcGVubm8tc2ZjLWFwcGlkLTAzDQoNCkRlYXIgTWVkLA0K DQpUcnlpbmcgdG8gZXh0cmFjdCB0aGUga2V5IHN0YXRlbWVudHMgZnJvbSB0aGUgbGluZS1ieS1s aW5lIHJlcGx5LCB5b3Ugc2FpZDoNCg0KR2l2ZW4gdGhpcyBnb2FsIG9mIGNvbnZleWluZyBhcHBs aWNhdGlvbiBpbmZvcm1hdGlvbiwgd2UgZm91bmQgb25lIHNwZWNpZmljIHN5bnRheCBsZXZlcmFn aW5nIHRoZSBBcHBsaWNhdGlvbiBJbmZvcm1hdGlvbiBzdHJ1Y3R1cmUgZnJvbSBJUEZJWC4NCltN ZWRdIFdoaWNoIG1ha2VzIHNlbnNlLiBJIGZ1bGx5IGFncmVlIHdpdGggdGhhdC4NCg0KQXBvbG9n aWVzIGluIGFkdmFuY2UgZm9yIGFza2luZyBhZ2FpbiwgYnV0LCB3aGF0IGV4YWN0bHkgaXMgeW91 ciBjb25jZXJuIHdpdGggdGhpcyBkb2N1bWVudCAoYmV5b25kIHlvdXIgcHJvcG9zYWwgdG8gdXNl IElQRklYIElFcyBmb3IgZXZlcnl0aGluZyk/DQoNCg0KU29tZSBhZGRpdGlvbmFsIGZvbGxvdy11 cHMgZm9yIGNsb3N1cmUgaW5saW5lLg0KDQpPbiBNYXkgMiwgMjAxNiwgYXQgMTA6MzIgQU0sIG1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20+IHdyb3RlOg0KDQpSZS0sDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQpDaGVlcnMsDQpN ZWQNCg0KRGUgOiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgW21haWx0bzpjcGlnbmF0YUBj aXNjby5jb21dDQpFbnZvecOpIDogbHVuZGkgMiBtYWkgMjAxNiAxNTo1Mw0Kw4AgOiBCT1VDQURB SVIgTW9oYW1lZCBJTVQvT0xODQpDYyA6IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBzZmNAaWV0 Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz47IGRyYWZ0LXBlbm5vLXNmYy1hcHBpZEBpZXRmLm9y ZzxtYWlsdG86ZHJhZnQtcGVubm8tc2ZjLWFwcGlkQGlldGYub3JnPg0KT2JqZXQgOiBSZTogW3Nm Y10gQ2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtcGVubm8tc2ZjLWFwcGlkLTAzDQoNCkRl YXIgTWVkLA0KDQpUaGFua3MgZm9yIHRha2luZyB0aGUgdGltZSB0byByZXZpZXcgYW5kIGNvbW1l bnQuIFBsZWFzZSBmaW5kIHNvbWUgY29tbWVudHMgaW5saW5lLg0KDQpPbiBNYXkgMiwgMjAxNiwg YXQgNzo1OCBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbT4gd3JvdGU6DQoNCkhpIEppbSwgYWxsLA0KDQpJIGludGVycHJl dCB0aGlzIHByb3Bvc2FsIGFzIGlmIGl0IHdhbnRzIHRvIGluaGVyaXQgdGhlIElQRklYIEFwcGxp Y2F0aW9uIGluZm9ybWF0aW9uIHRvIGJlIGNvbnZleWVkIGluIGFuIG5zaCBoZWFkZXIuIEkgaGF2 ZSBzb21lIGlzc3VlcyB3aXRoIHRoZSByYXRpb25hbGUgb2YgdGhpcyBkcmFmdCwgbm90IGl0cyBn b2FsIHBlciBzZS4NCg0KSSBkbyBub3Qgc3VwcG9ydCB0aGlzIGRyYWZ0LiBJIGRvIHRoaW5rIHRo ZXJlIGFyZSBvdGhlciBkZXNpZ24gY2hvaWNlcyB0aGF0IGNhbiBiZSBpbnZlc3RpZ2F0ZWQgYnkg dGhlIFdHIHRvIGluaGVyaXQgZXhpc3RpbmcgSVBGSVggSUVzIHdpdGhvdXQgd3JpdGluZyBhIG5l dyBSRkMgZm9yIGl0IGZvciBFQUNIIElFIHRvIGJlIGNvbnZleWVkIGluIGFuIE5TSCBoZWFkZXIu DQoNCkkgYmVsaWV2ZSB5b3UgYXJlIG1pc3VuZGVyc3RhbmRpbmcgd2hhdCBkcmFmdC1wZW5uby1z ZmMtYXBwaWQtMDMgaXMgYWJvdXQuIFRoZSBnb2FsIGlzIHRvIGNvbnZleSBhcHBsaWNhdGlvbiBp bmZvcm1hdGlvbiBpbiBTRkMgTWV0YWRhdGEuIEl0IGlzIG5vdCB0byBpbmhlcml0IGV4aXN0aW5n IElQRklYIElFcy4NCltNZWRdIFlvdSBtYXkgYmUgcmlnaHQgYnV0IHRoZSBkb2N1bWVudCBleHBs aWNpdGx5IHNheXM6DQoNCiAgIFRoaXMgZG9jdW1lbnQgcHVycG9zZXMgdGhlIHVzZSBvZiBJUEZJ WCBbUkZDNzAxMTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzAxMT5dIGFwcGxpY2F0 aW9uDQogICAgICAgICAgICAgICAgICAgICAgICAgIF5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eDQogICBpbmZvcm1hdGlvbiB0byBiZSBjYXJyaWVkIGluIHRoZSBOU0ggY29u dGV4dCBtZXRhZGF0YSBvZiBhIE1EVHlwZS0xDQogICBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eDQogICBwYWNrZXQuDQoNCg0KDQoNCkFic3RyYWN0DQoNCiAgIFRo aXMgZG9jdW1lbnQgcHJvcG9zZXMgdG8gdXNlIHRoZSBzdHJ1Y3R1cmVkIGFwcGxpY2F0aW9uIGlu Zm9ybWF0aW9uDQogICBpbiB0aGUgc2VydmljZSBmdW5jdGlvbiBjaGFpbmluZyBtZXRhZGF0YSwg YW5kIHNwZWNpZmllcyBhIFlBTkcgbW9kZWwNCiAgIGZvciB0aGUgY29uZmlndXJhdGlvbiBvZiB0 aGUgYXBwbGljYXRpb24gcmVnaXN0cnkuDQoNCg0KDQoNCkdpdmVuIHRoaXMgZ29hbCBvZiBjb252 ZXlpbmcgYXBwbGljYXRpb24gaW5mb3JtYXRpb24sIHdlIGZvdW5kIG9uZSBzcGVjaWZpYyBzeW50 YXggbGV2ZXJhZ2luZyB0aGUgQXBwbGljYXRpb24gSW5mb3JtYXRpb24gc3RydWN0dXJlIGZyb20g SVBGSVguDQpbTWVkXSBXaGljaCBtYWtlcyBzZW5zZS4gSSBmdWxseSBhZ3JlZSB3aXRoIHRoYXQu DQoNCkkgd2FudGVkIHRvIGNsYXJpZnkgdGhlIGRpZmZlcmVuY2UsIGFzIGl0IGlzIHNpZ25pZmlj YW5jZS4NCg0KSWYgdGhlcmUgYXJlIG90aGVyIGRlc2lnbiBjaG9pY2VzICp0byBjb252ZXkgYXBw bGljYXRpb24gaWRlbnRpZmljYXRpb24qIChub3QgdG8gaW5oZXJpdCBleGlzdGluZyBmaWVsZHMg ZnJvbSBhbnl3aGVyZSBhcyBhIGdvYWwpLCB3ZeKAmWQgbG92ZSB0byBoZWFyIHRoZW0uDQpbTWVk XSBXaG8gaXMgYXNraW5nIHRvIOKAnGluaGVyaXQgZXhpc3RpbmcgZmllbGRz4oCdPw0KDQpUaGlz IHNwZWNpZmljIHByb3Bvc2FsIGNvbXBpbGVzIGFuZCBydW5zLg0KDQoNCg0KDQpGb3IgZXhhbXBs ZSwgdGhlcmUgaXMgYSBtb3JlIGdlbmVyYWwgcHJvcG9zYWwgdGhhdCBhaW1zIHRvIGltcG9ydCBB TlkgSVBGSVggSW5mb3JtYXRpb24gRWxlbWVudCAodGhhdCB3aWxsIGNvdmVyIHRoZSBwYXJ0aWN1 bGFyIGNhc2UgaW4gdGhpcyBkb2N1bWVudCk6aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL3NmYy9jdXJyZW50L21zZzA0NDkyLmh0bWwgd2l0aG91dCBjb25zdW1pbmcgdGhlIFdH IGVmZm9ydCB0byBlZGl0L3Jldmlldy9wdWJsaXNoIFJGQ3MgZm9yIGVhY2ggcHJvbWlzaW5nIElQ RklYIElFcy4NCg0KDQpJIGJlbGlldmUgdGhpcyB3aWxsIGNhdXNlIG1vcmUgaGVhZGFjaGVzIHRo YW4gc29sdXRpb25zIOKAlCBJIHJlcGxpZWQgaW4gYSBzZXBhcmF0ZSBub3RlLg0KDQoNCg0KRnVy dGhlciwgSSBoYXZlIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25zIGZvciB0aGUgZHJhZnQ6DQoNCuKA oiAgICAgICAgIFdoeSByZXNlcnZpbmcgdGhpcyBwcm9wb3NhbCBmb3IgTUQjMT8NCg0KQmVjYXVz ZSB0aGF0IGlzIHRoZSBtaW5pbWFsIG9uZSB0byB1c2UuDQpbTWVkXSBJIGRvbuKAmXQgcGFyc2Ug dGhpcywgc29ycnkuDQoNCkhvd2V2ZXIsIHRoaXMgaXMgYWxzbyBkZWZpbmVkIGZvciBNRC1UeXBl IDIgYXQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXNmYy1uc2gtdGx2 LTAxI3BhZ2UtNyAoc2VlIOKAnDUuICAgQXBwbGljYXRpb24gSUTigJ0pDQpbTWVkXSBJIGRvbuKA mXQgdGhpbmsgaXQgaXMgYSBnb29kIGlkZWEgdG8gaGF2ZSBhIGxvdCBvZiBkb2N1bWVudHMgdG8g ZGVmaW5lIHRoZSBzYW1lIHNldCBvZiBpbmZvcm1hdGlvbi4NCg0KDQpOb3RlZC4gVGhhbmsgeW91 Lg0KDQoNCg0KRG8geW91IHN1Z2dlc3Qgd2Ugc2hvdWxkIGRlZmluZSBNRC1UeXBlIDIgaW4gdGhp cyBkcmFmdCBhcyB3ZWxsPyBIYXBweSB0byBkbyBzbyBpZiB0aGF04oCZcyB1c2VmdWwuDQpbTWVk XSBObywgSeKAmW0gbm90IHByb3Bvc2luZyB0aGF0LiBJ4oCZbSB0cnlpbmcgdG8gdW5kZXJzdGFu ZCB0aGUgdGVjaG5pY2FsIHJhdGlvbmFsZSBmb3IgdGhhdCBjaG9pY2UuDQoNCg0KDQpUaGlzIGRv YyBkZWZpbmVzIE1ELVR5cGUgMSwgYW5kIHRoZSBUTFYgZG9jIGRlZmluZXMgTUQtVHlwZSAyIGZv ciBhIGJ1bmNoIG9mIHRoaW5ncy4NCg0KSWYgeW91IGhhdmUgYW4gZWRpdG9yaWFsIG9yIGluZm9y bWF0aW9uIGFycmFuZ2VtZW50IHByb3Bvc2FsLCBwbGVhc2UgZG8gc2hhcmUuIEhhcHB5IHRvIGFj Y29tbW9kYXRlIHRvIG1ha2UgdGhpbmdzIGVhc2llciB0byBwYXJzZS4NCg0KDQoNCg0KDQrigKIg ICAgICAgICBXaGF0IG1lYW5zIHRoZSBmb2xsb3dpbmcgaGVhZGVycz8NCiAgICAgIDAgICAgICAg ICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAg ICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMQ0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgIDMgICAgICAgfCAgICAgICAg MCAgICAgIHwgICAgICAgICAgICAgIDE2MSAgICAgICAgICAgICAgfA0KICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K ICAgICB8ICAgICAgICAgICAgICAgICAgTmV0d29yayBTaGFyZWQgQ29udGV4dCAgICAgICAgICAg ICAgICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICAgICAgICAgICAgU2Vy dmljZSBQbGF0Zm9ybSBDb250ZXh0ICAgICAgICAgICAgICAgICAgICAgfA0KICAgICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KICAgICB8ICAgICAgICAgICAgICAgICAgU2VydmljZSBTaGFyZWQgQ29udGV4dCAgICAgICAg ICAgICAgICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQogICAgICAgRmlndXJlIDI6IEV4YW1w bGUgb2YgTWV0YWRhdGEgSW5jbHVkaW5nIHRoZSBTTk1QIEFwcGxpY2F0aW9uDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBJZGVudGlmaWNhdGlvbg0KDQoNCg0KSXQgaXMgYW4gZXhhbXBs ZSBvZiBtZXRhZGF0YSBpbmNsdWRpbmcgdGhlIFNOTVAgYXBwbGljYXRpb24gaWRlbnRpZmljYXRp b24uDQpbTWVkXSBNeSBxdWVzdGlvbiB3YXMgbWF5YmUgbm90IGNsZWFyOiB3aGF0IGEgTmV0d29y ayBTaGFyZWQgQ29udGV4dD8gV2hhdCBpcyBhIFNlcnZpY2UgUGxhdGZvcm0gQ29udGV4dD8gV2hh dCBpcyBTZXJ2aWNlIFNoYXJlZCBDb250ZXh0Pw0KDQoNCkFoLCB0aGFua3MgZm9yIHRoZSBjbGFy aWZpY2F0aW9uLiBUaGVzZSBhcmUgcmVtYWluZGVycyBmcm9tIGVhcmxpZXIgdmVyc2lvbnMgb2Yg ZHJhZnQtaWV0Zi1zZmMtbnNoLCB3aGljaCB3ZSBoYXZlIHRvIGZpeC4gVGhpcyBpcyBhIGdvb2Qg YWRvcHRpb24gY29tbWVudCBhbmQgYSBnb29kIGNhdGNoLg0KDQpCZXN0LA0KDQrigJQgQ2FybG9z Lg0KDQoNCkJlc3QsDQoNCuKAlCBDYXJsb3MuDQoNCg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBz ZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBKaW0gR3VpY2hh cmQgKGpndWljaGFyKQ0KRW52b3nDqSA6IHZlbmRyZWRpIDI5IGF2cmlsIDIwMTYgMTg6MzENCsOA IDogc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpPYmpldCA6IFtzZmNdIENhbGwg Zm9yIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LXBlbm5vLXNmYy1hcHBpZC0wMw0KDQpEZWFyIFdHOg0K DQpXZSBkaWQgbm90IHJlY2VpdmUgbWFueSByZXNwb25zZXMgZm9yIHRoaXMgY2FsbCBmb3IgYWRv cHRpb24gYW5kIHRoZXJlZm9yZSB3b3VsZCBsaWtlIHRvIHJlLWludml0ZSBwZW9wbGUgdG8gcG9z dCB0aGVpciB0aG91Z2h0cyBvbiBhZG9wdGluZyB0aGlzIGRvY3VtZW50IGludG8gdGhlIFNGQyBX Ry4gVGhlIGNhbGwgZm9yIGFkb3B0aW9uIHdpbGwgcnVuIGZvciBhIGZ1cnRoZXIgMiB3ZWVrcyBl bmRpbmcgNi8xMy8yMDE2Lg0KDQpUaGFua3MhDQoNClNGQyBDaGFpcnMNCg0KRnJvbTogSmltIEd1 aWNoYXJkIDxqZ3VpY2hhckBjaXNjby5jb208bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbT4+DQpE YXRlOiBUaHVyc2RheSwgRmVicnVhcnkgMTEsIDIwMTYgYXQgMzoyNCBQTQ0KVG86ICJzZmNAaWV0 Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRm Lm9yZz4+DQpTdWJqZWN0OiBDYWxsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1wZW5uby1zZmMt YXBwaWQtMDMNCg0KRGVhciBXRzoNCg0KVGhpcyBlbWFpbCBzZXJ2ZXMgYXMgYSBjYWxsIGZvciBX RyBhZG9wdGlvbiBvZiBkcmFmdC1wZW5uby1zZmMtYXBwaWQtMDMgYXMgYSBXRyBkb2N1bWVudC4g VGhlIGNhbGwgZm9yIGFkb3B0aW9uIHdpbGwgcnVuIGZvciAyIHdlZWtzIGVuZGluZyAyLzI1LzIw MTYuDQoNClBsZWFzZSBub3RlIHRoYXQgdGhpcyBpcyBhIGNhbGwgZm9yIGFkb3B0aW9uLCBhbmQg bm90IGEgbGFzdCBjYWxsIGZvciBjb250ZW50IG9mIHRoZSBkb2N1bWVudC4gQWRvcHRpbmcgYSBX RyBkb2N1bWVudCBzaW1wbHkgbWVhbnMgdGhhdCB0aGUgV0cgd2lsbCBmb2N1cyBpdHMgZWZmb3J0 cyBvbiB0aGF0IHBhcnRpY3VsYXIgZHJhZnQgZ29pbmcgZm9yd2FyZCwgYW5kIHVzZSB0aGF0IGRv Y3VtZW50IGZvciByZXNvbHZpbmcgb3BlbiBpc3N1ZXMgYW5kIGRvY3VtZW50aW5nIHRoZSBXR+KA mXMgZGVjaXNpb25zLg0KDQpQbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5b3Ugc3VwcG9ydCBhZG9w dGlvbiBmb3Igbm90LCBhbmQgaWYgbm90IHdoeS4gSXNzdWVzIHlvdSBoYXZlIHdpdGggdGhlIGN1 cnJlbnQgZG9jdW1lbnQgaXRzZWxmIGNhbiBhbHNvIGJlIHJhaXNlZCwgYnV0IHRoZXkgc2hvdWxk IGJlIHJhaXNlZCBpbiB0aGUgY29udGV4dCBvZiB3aGF0IHNob3VsZCBiZSBjaGFuZ2VkIGluIHRo ZSBkb2N1bWVudCBnb2luZyBmb3J3YXJkLCByYXRoZXIgdGhhbiBhIHByZS1jb25kaXRpb24gZm9y IGFkb3B0aW9uLg0KDQpGaW5hbGx5LCBub3cgaXMgYWxzbyBhIGdvb2QgdGltZSB0byBwb2xsIGZv ciBrbm93bGVkZ2Ugb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCwgaW4gbGlu ZSB3aXRoIHRoZSBJUFIgZGlzY2xvc3VyZSBvYmxpZ2F0aW9ucyBmb3IgV0cgcGFydGljaXBhbnRz IChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLiBJ ZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBwbGVhc2UgcmVzcG9uZCB0byB0 aGlzIGVtYWlsICh0byB0aGUgY2hhaXJzKSB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9m IGFueSByZWxldmFudCBJUFIuDQoNClRoYW5rcyENCg0KU0ZDIENoYWlycw0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNm Y0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMNCg0KDQo= --_000_787AE7BB302AE849A7480A190F8B933008D6310AOPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAg MCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpU YWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYu TXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDow Y207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVm dDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLmFwcGxlLWNvbnZl cnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bh bi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMgQ2Fy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1 bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxT dHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQt c3R5bGU6bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0 aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTUxMzgzNzM3MzsNCgltc28tbGlzdC10 eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTI0OTc5NTU1NiAtNzYwMjg1MjYy IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3IDY3 ODk1Mjk5IDY3ODk1MzAxO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6 MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDsNCgltc28t ZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs MDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Q2FybG9zLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JIGFscmVhZHkgZXhwbGFpbmVkIHdoeSBJ 4oCZbSBvYmplY3RpbmcgdG8gYWRvcHQgdGhpcyBkb2N1bWVudCBhdCB0aGlzIHN0YWdlLiBJbiBh ZGRpdGlvbiB0byB0aGF0LCBJIGhhdmUgc29tZSBjb25jZXJucyB0aGF0IEnigJltIGxpc3Rpbmcg YmVsb3c6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlz dDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPkkgZG9u4oCZdCB0aGluayBpdCBpcyBhIGdvb2QgaWRlYSB0byBoYXZlIGEgbG90 IG9mIGRvY3VtZW50cyB0byBkZWZpbmUgcGllY2VzIG9mIGluZm9ybWF0aW9uIHRoYXQgY2FuIGJl IHN1cHBsaWVkIHVzaW5nIG5zaC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjpibGFjayI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Tm9uZSBvZiB0aGUgV0cgYWRvcHRlZCB1c2UgY2FzZSBk b2N1bWVudHMgY2FsbCBmb3IgdGhlIGFwcGlkIGFzIGEgbWFuZGF0b3J5LXRvLXN1cHBvcnQgaW5m b3JtYXRpb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEi PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPlRoZSBhcHBpZCBkcmFmdCAodGFyZ2V0aW5nIOKAnFN0YW5kYXJkcyBUcmFj a+KAnSBzdGF0dXMpIHJlbGllcyBvbiBhICoqIFZFTkRPUiAqKiBJUEZJWCBleHRlbnNpb24gKGFu IGluZm9ybWF0aW9uIFJGQykuIElzIHRoZXJlIGFueSByZWFzb24gd2h5IHRoYXQNCiBpbmZvcm1h dGlvbiB3YXMgbm90IHBhcnQgb2YgdGhlIG5vcm1hbCBJUEZJWCBhc3NpZ25tZW50IHByb2Nlc3M/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6U3ltYm9sO2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij5UaGVyZSBpcyBhbiBJUFIgZm9yIHRoZSBhcHBpZCBkcmFmdC4gQmVmb3JlIGVuZG9yc2luZyB0 aGUgZHJhZnQsIGl0IHdvdWxkIGJlIGFwcHJvcHJpYXRlIGZvciB0aGUgV0cgdG8gdW5kZXJzdGFu ZCBmaXJzdCB0aGUgcHJvYmxlbSB0byBzb2x2ZSwgYWdyZWUNCiBpdCBpcyB3b3J0aCB0byBiZSBz b2x2ZWQsIGFuZCB0aGVuIHRoZSBXRyBjYW4gc2VlIHdoZXRoZXIgdGhlcmUgYXJlIG90aGVyIHNv bHV0aW9uIGRlc2lnbnMgd2l0aG91dCBoYXZpbmcgYW5vdGhlciB5ZXQgU0ZDIGRvY3VtZW50IHdp dGggYW4gSVBSIG9uIGl0ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNw Ozo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IENh cmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSBbbWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbV0NCjxi cj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBsdW5kaSAyIG1haSAyMDE2IDE2OjQ0PGJyPg0KPGI+ w4AmbmJzcDs6PC9iPiBCT1VDQURBSVIgTW9oYW08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPmVkIElNVC9PTE48YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IEppbSBHdWljaGFyZCAoamd1 aWNoYXIpOyBzZmNAaWV0Zi5vcmc7IGRyYWZ0LXBlbm5vLXNmYy1hcHBpZEBpZXRmLm9yZzxicj4N CjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFtzZmNdIENhbGwgZm9yIFdHIGFkb3B0aW9uIG9mIGRy YWZ0LXBlbm5vLXNmYy1hcHBpZC0wMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkRlYXIgTWVkLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VHJ5aW5nIHRvIGV4dHJhY3QgdGhlIGtleSBzdGF0ZW1lbnRzIGZyb20gdGhl IGxpbmUtYnktbGluZSByZXBseSwgeW91IHNhaWQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HaXZlbiB0aGlzIGdv YWwgb2YgY29udmV5aW5nIGFwcGxpY2F0aW9uIGluZm9ybWF0aW9uLCB3ZSBmb3VuZCBvbmUgc3Bl Y2lmaWMgc3ludGF4IGxldmVyYWdpbmcgdGhlIEFwcGxpY2F0aW9uIEluZm9ybWF0aW9uIHN0cnVj dHVyZSBmcm9tIElQRklYLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5bTWVkXSBXaGljaCBtYWtlcyBzZW5z ZS4gSSBmdWxseSBhZ3JlZSB3aXRoIHRoYXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QXBvbG9naWVzIGluIGFkdmFuY2UgZm9yIGFza2luZyBhZ2FpbiwgYnV0LCB3aGF0IGV4 YWN0bHkgaXMgeW91ciBjb25jZXJuIHdpdGggdGhpcyBkb2N1bWVudCAoYmV5b25kIHlvdXIgcHJv cG9zYWwgdG8gdXNlIElQRklYIElFcyBmb3IgZXZlcnl0aGluZyk/PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U29tZSBhZGRpdGlvbmFsIGZv bGxvdy11cHMgZm9yIGNsb3N1cmUgaW5saW5lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTWF5IDIsIDIwMTYsIGF0IDEwOjMyIEFNLCA8 YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+DQptb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5SZS0sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij5QbGVhc2Ugc2VlIGlubGluZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PkNoZWVycyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+TWVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNhcmxvcw0KIFBpZ25hdGFy byAoY3BpZ25hdGEpIFs8YSBocmVmPSJtYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tPC9zcGFuPjwvYT5d PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxi PkVudm95w6kmbmJzcDs6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5sdW5kaSAyIG1haSAyMDE2IDE1OjUzPGJyPg0KPGI+w4AmbmJzcDs6PC9iPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5CT1VDQURBSVIg TW9oYW1lZCBJTVQvT0xOPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5KaW0gR3VpY2hhcmQgKGpndWljaGFyKTs8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOnNmY0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+c2ZjQGlldGYub3Jn PC9zcGFuPjwvYT47PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxhIGhyZWY9Im1haWx0bzpkcmFmdC1wZW5uby1zZmMtYXBwaWRAaWV0Zi5vcmciPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPmRyYWZ0LXBlbm5vLXNmYy1hcHBpZEBpZXRmLm9yZzwvc3Bh bj48L2E+PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW3NmY10gQ2FsbCBmb3IgV0cgYWRvcHRpb24gb2Yg ZHJhZnQtcGVubm8tc2ZjLWFwcGlkLTAzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBNZWQsPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHRha2luZyB0aGUgdGltZSB0byByZXZpZXcgYW5k IGNvbW1lbnQuIFBsZWFzZSBmaW5kIHNvbWUgY29tbWVudHMgaW5saW5lLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gTWF5IDIsIDIwMTYsIGF0IDc6NTggQU0sPHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPkhpIEppbSwgYWxsLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5JIGludGVycHJldCB0aGlzIHByb3Bvc2FsIGFzIGlmIGl0IHdhbnRzIHRvIGluaGVyaXQgdGhl IElQRklYIEFwcGxpY2F0aW9uIGluZm9ybWF0aW9uIHRvIGJlIGNvbnZleWVkIGluIGFuIG5zaCBo ZWFkZXIuIEkgaGF2ZSBzb21lIGlzc3VlcyB3aXRoIHRoZSByYXRpb25hbGUgb2YgdGhpcyBkcmFm dCwNCiBub3QgaXRzIGdvYWwgcGVyIHNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5J IGRvIG5vdCBzdXBwb3J0IHRoaXMgZHJhZnQuIEkgZG8gdGhpbmsgdGhlcmUgYXJlIG90aGVyIGRl c2lnbiBjaG9pY2VzIHRoYXQgY2FuIGJlIGludmVzdGlnYXRlZCBieSB0aGUgV0cgdG8gaW5oZXJp dCBleGlzdGluZyBJUEZJWCBJRXMgd2l0aG91dCB3cml0aW5nIGEgbmV3IFJGQyBmb3INCiBpdCBm b3IgRUFDSCBJRSB0byBiZSBjb252ZXllZCBpbiBhbiBOU0ggaGVhZGVyLjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBiZWxpZXZlIHlvdSBhcmUgbWlz dW5kZXJzdGFuZGluZyB3aGF0IGRyYWZ0LXBlbm5vLXNmYy1hcHBpZC0wMyBpcyBhYm91dC4gVGhl IGdvYWwgaXMgdG8gY29udmV5IGFwcGxpY2F0aW9uIGluZm9ybWF0aW9uIGluIFNGQyBNZXRhZGF0 YS4gSXQgaXMgbm90IHRvIGluaGVyaXQgZXhpc3RpbmcgSVBGSVggSUVzLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij5bTWVkXSBZb3UgbWF5IGJlIHJpZ2h0IGJ1dCB0aGUgZG9jdW1lbnQgZXhwbGljaXRseSBz YXlzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsgVGhpcyBkb2N1bWVudCBwdXJwb3NlcyB0aGUgdXNlIG9mIElQRklY IFs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM3MDExIiB0aXRsZT0iJnF1b3Q7U3BlY2lmaWNhdGlvbiBvZiB0aGUgSVAgRmxvdyBJbmZvcm1h dGlvbiBFeHBvcnQgKElQRklYKSBQcm90b2NvbCBmb3IgdGhlIEV4Y2hhbmdlIG9mIEZsb3cgSW5m b3JtYXRpb24mcXVvdDsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6cHVycGxlIj5S RkM3MDExPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5dDQogYXBwbGlj YXRpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGluZm9ybWF0aW9uIHRvIGJlIGNhcnJpZWQg aW4gdGhlIE5TSCBjb250ZXh0IG1ldGFkYXRhIG9mIGEgTURUeXBlLTE8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5ePC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDs8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5w YWNrZXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWJzdHJhY3Q8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO1Ro aXMgZG9jdW1lbnQgcHJvcG9zZXMgdG8gdXNlIHRoZSBzdHJ1Y3R1cmVkIGFwcGxpY2F0aW9uIGlu Zm9ybWF0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7aW4gdGhlIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcgbWV0YWRh dGEsIGFuZCBzcGVjaWZpZXMgYSBZQU5HIG1vZGVsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7Zm9yIHRoZSBjb25maWd1cmF0 aW9uIG9mIHRoZSBhcHBsaWNhdGlvbiByZWdpc3RyeS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HaXZlbiB0aGlzIGdvYWwgb2YgY29udmV5aW5n IGFwcGxpY2F0aW9uIGluZm9ybWF0aW9uLCB3ZSBmb3VuZCBvbmUgc3BlY2lmaWMgc3ludGF4IGxl dmVyYWdpbmcgdGhlIEFwcGxpY2F0aW9uIEluZm9ybWF0aW9uIHN0cnVjdHVyZSBmcm9tIElQRklY LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij5bTWVkXSBXaGljaCBtYWtlcyBzZW5zZS4gSSBmdWxseSBhZ3Jl ZSB3aXRoIHRoYXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHdhbnRlZCB0byBjbGFyaWZ5IHRo ZSBkaWZmZXJlbmNlLCBhcyBpdCBpcyBzaWduaWZpY2FuY2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5JZiB0aGVyZSBhcmUgb3RoZXIgZGVzaWduIGNob2ljZXMgKnRvIGM8L3NwYW4+b252ZXkgYXBw bGljYXRpb24gaWRlbnRpZmljYXRpb24qIChub3QgdG8gaW5oZXJpdCBleGlzdGluZyBmaWVsZHMg ZnJvbSBhbnl3aGVyZSBhcyBhIGdvYWwpLCB3ZeKAmWQgbG92ZSB0byBoZWFyIHRoZW0uJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPltNZWRdIFdobyBpcyBhc2tpbmcgdG8g4oCcaW5oZXJpdCBleGlz dGluZyBmaWVsZHPigJ0/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgc3BlY2lmaWMgcHJvcG9zYWwgY29tcGlsZXMgYW5kIHJ1 bnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Rm9yIGV4YW1w bGUsIHRoZXJlIGlzIGEgbW9yZSBnZW5lcmFsIHByb3Bvc2FsIHRoYXQgYWltcyB0byBpbXBvcnQg QU5ZIElQRklYIEluZm9ybWF0aW9uIEVsZW1lbnQgKHRoYXQgd2lsbCBjb3ZlciB0aGUgcGFydGlj dWxhciBjYXNlIGluIHRoaXMgZG9jdW1lbnQpOjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9zZmMvY3VycmVudC9tc2cwNDQ5Mi5odG1sIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2ZjL2N1 cnJlbnQvbXNnMDQ0OTIuaHRtbDwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPndpdGhvdXQNCiBjb25zdW1pbmcgdGhlIFdHIGVmZm9ydCB0 byBlZGl0L3Jldmlldy9wdWJsaXNoIFJGQ3MgZm9yIGVhY2ggcHJvbWlzaW5nIElQRklYIElFcy48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGJlbGlldmUgdGhpcyB3aWxsIGNhdXNl IG1vcmUgaGVhZGFjaGVzIHRoYW4gc29sdXRpb25zIOKAlCBJIHJlcGxpZWQgaW4gYSBzZXBhcmF0 ZSBub3RlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij5GdXJ0aGVyLCBJIGhhdmUgdGhlIGZvbGxvd2luZyBxdWVzdGlvbnMgZm9yIHRoZSBkcmFm dDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDot MTguMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPldoeQ0KIHJlc2VydmluZyB0aGlzIHByb3Bvc2FsIGZvciBN RCMxPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZWNhdXNlIHRo YXQgaXMgdGhlIG1pbmltYWwgb25lIHRvIHVzZS48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPltNZWRdIEkgZG9u4oCZdCBw YXJzZSB0aGlzLCBzb3JyeS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5Ib3dldmVyLCB0aGlzIGlzIGFsc28gZGVmaW5lZCBmb3IgTUQtVHlwZSAy IGF0Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1xdWlubi1zZmMtbnNoLXRsdi0wMSNwYWdlLTciPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6cHVycGxlIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcXVpbm4tc2Zj LW5zaC10bHYtMDEjcGFnZS03PC9zcGFuPjwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+KHNlZQ0KIOKAnDUuICZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+QXBwbGljYXRpb24gSUTigJ0pPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPltNZWRdIEkgZG9u4oCZdCB0aGluayBpdCBpcyBhIGdvb2QgaWRlYSB0byBoYXZlIGEg bG90IG9mIGRvY3VtZW50cyB0byBkZWZpbmUgdGhlIHNhbWUgc2V0IG9mIGluZm9ybWF0aW9uLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3RlZC4gVGhhbmsgeW91LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG8geW91IHN1Z2dlc3Qgd2Ugc2hvdWxk IGRlZmluZSBNRC1UeXBlIDIgaW4gdGhpcyBkcmFmdCBhcyB3ZWxsPyBIYXBweSB0byBkbyBzbyBp ZiB0aGF04oCZcyB1c2VmdWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPltNZWRdIE5vLCBJ4oCZbSBub3Qg cHJvcG9zaW5nIHRoYXQuIEnigJltIHRyeWluZyB0byB1bmRlcnN0YW5kIHRoZSB0ZWNobmljYWwg cmF0aW9uYWxlIGZvciB0aGF0IGNob2ljZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgZG9jIGRlZmluZXMgTUQtVHlwZSAxLCBhbmQg dGhlIFRMViBkb2MgZGVmaW5lcyBNRC1UeXBlIDIgZm9yIGEgYnVuY2ggb2YgdGhpbmdzLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB5b3Ug aGF2ZSBhbiBlZGl0b3JpYWwgb3IgaW5mb3JtYXRpb24gYXJyYW5nZW1lbnQgcHJvcG9zYWwsIHBs ZWFzZSBkbyBzaGFyZS4gSGFwcHkgdG8gYWNjb21tb2RhdGUgdG8gbWFrZSB0aGluZ3MgZWFzaWVy IHRvIHBhcnNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PldoYXQNCiBtZWFucyB0aGUgZm9sbG93aW5nIGhlYWRlcnM/PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDImbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDE2MSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO05l dHdvcmsgU2hhcmVkIENvbnRleHQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBTZXJ2aWNlIFBsYXRmb3JtIENvbnRleHQmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTZXJ2aWNlIFNoYXJlZCBDb250ZXh0Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg RmlndXJlIDI6IEV4YW1wbGUgb2YgTWV0YWRhdGEgSW5jbHVkaW5nIHRoZSBTTk1QIEFwcGxpY2F0 aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSWRlbnRpZmlj YXRpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0 IGlzIGFuIGV4YW1wbGUgb2YgbWV0YWRhdGEgaW5jbHVkaW5nIHRoZSBTTk1QIGFwcGxpY2F0aW9u IGlkZW50aWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5bTWVkXSBNeSBxdWVzdGlvbiB3YXMg bWF5YmUgbm90IGNsZWFyOiB3aGF0IGE8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+TmV0d29yayBTaGFyZWQgQ29udGV4dD8gV2hhdCBpcyBhIFNlcnZpY2Ug UGxhdGZvcm0gQ29udGV4dD8gV2hhdCBpcyBTZXJ2aWNlIFNoYXJlZA0KIENvbnRleHQ/PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFoLCB0aGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9u LiBUaGVzZSBhcmUgcmVtYWluZGVycyBmcm9tIGVhcmxpZXIgdmVyc2lvbnMgb2YgZHJhZnQtaWV0 Zi1zZmMtbnNoLCB3aGljaCB3ZSBoYXZlIHRvIGZpeC4gVGhpcyBpcyBhIGdvb2QgYWRvcHRpb24g Y29tbWVudCBhbmQgYSBnb29kIGNhdGNoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJQgQ2FybG9zLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKA lCBDYXJsb3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPkNoZWVycyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk1l ZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFu PjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+c2ZjDQogWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5d PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPkRlIGxh IHBhcnQgZGU8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPkppbSBHdWljaGFyZCAoamd1aWNoYXIpPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPnZlbmRyZWRpIDI5 IGF2cmlsIDIwMTYgMTg6MzE8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5v cmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnNmY0BpZXRmLm9yZzwvc3Bhbj48L2E+PGJy Pg0KPGI+T2JqZXQmbmJzcDs6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj5bc2ZjXSBDYWxsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1wZW5uby1z ZmMtYXBwaWQtMDM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZWFyIFdHOjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5XZSBkaWQgbm90IHJlY2VpdmUgbWFueSByZXNwb25zZXMgZm9yIHRoaXMgY2FsbCBm b3IgYWRvcHRpb24gYW5kIHRoZXJlZm9yZSB3b3VsZCBsaWtlIHRvIHJlLWludml0ZSBwZW9wbGUg dG8gcG9zdCB0aGVpciB0aG91Z2h0cyBvbiBhZG9wdGluZyB0aGlzIGRvY3VtZW50IGludG8gdGhl IFNGQyBXRy4NCiBUaGUgY2FsbCBmb3IgYWRvcHRpb24gd2lsbCBydW4gZm9yIGEgZnVydGhlciAy IHdlZWtzIGVuZGluZyA2LzEzLzIwMTYuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoYW5rcyE8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+U0ZDIENoYWlyczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5KaW0gR3VpY2hhcmQgJmx0 OzxhIGhyZWY9Im1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPmpndWljaGFyQGNpc2NvLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkRhdGU6PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5UaHVyc2Rh eSwgRmVicnVhcnkgMTEsIDIwMTYgYXQgMzoyNCBQTTxicj4NCjxiPlRvOjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+JnF1b3Q7PGEgaHJlZj0ibWFp bHRvOnNmY0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+c2ZjQGlldGYub3Jn PC9zcGFuPjwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPnNmY0BpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxi PlN1YmplY3Q6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjwvYj5DYWxsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1wZW5uby1zZmMtYXBwaWQtMDM8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+RGVhciBXRzo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpD b25zb2xhcyI+VGhpcyBlbWFpbCBzZXJ2ZXMgYXMgYSBjYWxsIGZvciBXRyBhZG9wdGlvbiBvZiBk cmFmdC1wZW5uby1zZmMtYXBwaWQtMDMgYXMgYSBXRyBkb2N1bWVudC4gVGhlIGNhbGwgZm9yIGFk b3B0aW9uIHdpbGwgcnVuIGZvciAyIHdlZWtzIGVuZGluZyAyLzI1LzIwMTYuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPlBs ZWFzZSBub3RlIHRoYXQgdGhpcyBpcyBhIGNhbGwgZm9yIGFkb3B0aW9uLCBhbmQgbm90IGEgbGFz dCBjYWxsIGZvciBjb250ZW50IG9mIHRoZSBkb2N1bWVudC4gQWRvcHRpbmcgYSBXRyBkb2N1bWVu dCBzaW1wbHkgbWVhbnMgdGhhdCB0aGUgV0cgd2lsbCBmb2N1cyBpdHMgZWZmb3J0cyBvbiB0aGF0 IHBhcnRpY3VsYXINCiBkcmFmdCBnb2luZyBmb3J3YXJkLCBhbmQgdXNlIHRoYXQgZG9jdW1lbnQg Zm9yIHJlc29sdmluZyBvcGVuIGlzc3VlcyBhbmQgZG9jdW1lbnRpbmcgdGhlIFdH4oCZcyBkZWNp c2lvbnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6Q29uc29sYXMiPlBsZWFzZSBpbmRpY2F0ZSB3aGV0aGVyIHlvdSBzdXBwb3J0IGFkb3B0 aW9uIGZvciBub3QsIGFuZCBpZiBub3Qgd2h5LiBJc3N1ZXMgeW91IGhhdmUgd2l0aCB0aGUgY3Vy cmVudCBkb2N1bWVudCBpdHNlbGYgY2FuIGFsc28gYmUgcmFpc2VkLCBidXQgdGhleSBzaG91bGQg YmUgcmFpc2VkIGluIHRoZSBjb250ZXh0IG9mIHdoYXQNCiBzaG91bGQgYmUgY2hhbmdlZCBpbiB0 aGUgZG9jdW1lbnQgZ29pbmcgZm9yd2FyZCwgcmF0aGVyIHRoYW4gYSBwcmUtY29uZGl0aW9uIGZv ciBhZG9wdGlvbi4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEzLjVwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+RmluYWxseSwgbm93IGlzIGFsc28gYSBnb29kIHRp bWUgdG8gcG9sbCBmb3Iga25vd2xlZGdlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMg ZHJhZnQsIGluIGxpbmUgd2l0aCB0aGUgSVBSIGRpc2Nsb3N1cmUgb2JsaWdhdGlvbnMgZm9yIFdH IHBhcnRpY2lwYW50cyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OQ0KIGFuZCA1Mzc4IGZvciBt b3JlIGRldGFpbHMpLiBJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBwbGVh c2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsICh0byB0aGUgY2hhaXJzKSB3aGV0aGVyIG9yIG5vdCB5 b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPlRoYW5rcyE8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xh cyI+U0ZDIENoYWlyczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCnNmYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5zZmNAaWV0Zi5v cmc8L3NwYW4+PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B933008D6310AOPEXCLILMA3corp_-- From nobody Tue May 3 04:45:24 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DECC312D763 for ; Tue, 3 May 2016 04:45:23 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ytR4S_loAw5t for ; Tue, 3 May 2016 04:45:22 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20D6A12D1CD for ; Tue, 3 May 2016 04:45:22 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id g17so33999555wme.1 for ; Tue, 03 May 2016 04:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=G05R2NPFazpjtATWiK0MuesKGBcEKDfLymv/V7aC3Yo=; b=eUz14TiqunZnRzCuNSf2W9oT/x5hlXopTBgojBNNH1YeArhX0IXI2qLFQX1k4WG0w2 wJs9dM7eSnaPOFNWTt49YuFD437b/PI7DezNRbFVZ8qWPFoCWCetNdQs6PTi5Qh3jaI+ IneQzYVhaJ9HKCJqRSBcRPz8JknEgyyJvbPV+XdIu2Dvf5Dc1S6Jl6cIec6H58rPYddC MSMlzY56I6SfL1RAzZWZdAmOWLxT3EujbqOysvCTvtiAGFzy59arPzqgHdtXoao/3l1n KeIRBPBdnIiLvQH73OyJyrAVHIiQN/p6FMXqV0Mv/uRgBQvC9rFOm4qBk0K+5zyNHe1K ljPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=G05R2NPFazpjtATWiK0MuesKGBcEKDfLymv/V7aC3Yo=; b=I/Bx60CJBa1giNXbM8qC25YNHgOr+aFKHHqOq4tLkKhkXjmRu5zbxMbK7JwRgveEDK u0Qeny/hryM45Kk05kGwXIOXaZy6UZQkxJBHH5uKW3dxRVpcopLnIf0mPn8B8/gqJsGS TZZtlvniIW7oyABWwgTMY6MPhQECVALjHszicXDClPBxP1KCNwx1zi+7nS7L/GL9FqMw ovHcCOa+s+D8W/xT7Qmwk1jknv7HOQI+vs8BeQnXFhBIrBJDY51B97YHEXsCIDsE7Cfm CPjuLJqGCAoMNMhQmjovX39/QN2v+x8VZt/lLvYVDTRUlfPFpYIXRYcjDms8yj0c45Wr uymw== X-Gm-Message-State: AOPr4FW4uONTfT88EjOANs6ZtHQ/Obki854OKhgeHk/4JdgY2XKh+mOc778++R6b7wXtnQ== X-Received: by 10.28.137.14 with SMTP id l14mr2845787wmd.64.1462275920749; Tue, 03 May 2016 04:45:20 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id u6sm3465652wjh.2.2016.05.03.04.45.19 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 May 2016 04:45:19 -0700 (PDT) To: "Joel M. Halpern" , mohamed.boucadair@orange.com, "Carlos Pignataro (cpignata)" References: <787AE7BB302AE849A7480A190F8B933008D62994@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2D398770-C83E-48FE-BBE9-574A58871700@cisco.com> <787AE7BB302AE849A7480A190F8B933008D62BEB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <179bc64c-be11-ef2d-81d1-75ef25fa3f99@joelhalpern.com> From: Stewart Bryant Message-ID: <57288F4E.50005@gmail.com> Date: Tue, 3 May 2016 12:45:18 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <179bc64c-be11-ef2d-81d1-75ef25fa3f99@joelhalpern.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] Reuse the IPFIX registry in NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 11:45:24 -0000 On 02/05/2016 15:56, Joel M. Halpern wrote: > The IPFIX Identifiers are associated with a type, and a fixed length > encoding. Joel Maybe I misunderstand you point, but IPFIX has the ability to carry variable length objects - RFC7011 Section 7 Stewart From nobody Tue May 3 07:16:10 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A033112D0A9; Tue, 3 May 2016 07:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 8CZ4CTope7j2; Tue, 3 May 2016 07:16:06 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05ED812D50F; Tue, 3 May 2016 07:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=81856; q=dns/txt; s=iport; t=1462284966; x=1463494566; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=de5lVCbOvz7RKmkQwF6W5XC+bhVk3pO3uFwq7asCi/Y=; b=bJfBs7eCUQtustLsfPhB2PhzAyh+kgdRkZuyF17dO70vUg0Ys2tml5UC 2ZURbUPAwTFFZFvWN6g3iQWvfQxa21ISJvc3hmkjTxXzkF7CeKzqakFPl INY5rhmofFCFt3g6HNAZllxZvJEi8oAGX2uNBN2hTabxLUQETacCfQ5p/ 4=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DFAgD7sShX/4oNJK1fgmxMU30GugwOg?= =?us-ascii?q?XEEFwEKhW4CgT04FAEBAQEBAQFlHAuEQQEBAQIBAQEBARoGRAcGBQULAgEIEQM?= =?us-ascii?q?BAgEgAQYDAgInCxQJCAIEDgUJBQ2IBwgOqm+RHQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQ0IhiCBdgiBTIEDhBEQAgE7FoJKK4IuBYdxizOEcgGDJ4FnbYgcgWiETYh?= =?us-ascii?q?dhj2IdAEeAUOCBRuBS2wBhzx/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,572,1454976000"; d="asc'?scan'208,217";a="267222678" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 May 2016 14:16:04 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u43EG31T025989 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 May 2016 14:16:04 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 May 2016 10:16:02 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Tue, 3 May 2016 10:16:02 -0400 From: "Carlos Pignataro (cpignata)" To: "mohamed.boucadair@orange.com" Thread-Topic: [sfc] Call for WG adoption of draft-penno-sfc-appid-03 Thread-Index: AQHRZQHOvGZf31kz6UifjJTvmDJQAZ+hr9aAgARTiaCAAGltAP//xfBAgABId4CAALvlkIAAzpcA Date: Tue, 3 May 2016 14:16:02 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B933008D62994@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <3501127B-E55B-4FA1-9A63-47D046371132@cisco.com> <787AE7BB302AE849A7480A190F8B933008D62C02@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <30650369-47D3-4387-B535-C2B7756B246A@cisco.com> <787AE7BB302AE849A7480A190F8B933008D6310A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D6310A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.48.199] Content-Type: multipart/signed; boundary="Apple-Mail=_F2C9285D-F51A-45DF-9A50-45FFA8D27C16"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "draft-penno-sfc-appid@ietf.org" , "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-appid-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 14:16:08 -0000 --Apple-Mail=_F2C9285D-F51A-45DF-9A50-45FFA8D27C16 Content-Type: multipart/alternative; boundary="Apple-Mail=_76A576C9-428A-4DDC-BEF6-5066A4A1F55C" --Apple-Mail=_76A576C9-428A-4DDC-BEF6-5066A4A1F55C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Med, I am trying to understand your objection. Do you believe that (1) conveying application information in the service = function chaining metadata is not a problem the WG should try to solve, = that (2) it is a problem for the WG to solve but this document is not a = good basis for it and there are other proposals the WG can use which are = better (and why), or that (3) something else? What you explained before says: > I do not support this draft. I do think there are other design choices = that can be investigated by the WG to inherit existing IPFIX IEs without = writing a new RFC for it for EACH IE to be conveyed in an NSH header. And my response to that has been that the goal is not to inherit = existing IPFIX IEs, and less so in a sweeping broadmost fashion. More inline... > On May 3, 2016, at 2:17 AM, mohamed.boucadair@orange.com wrote: >=20 > Carlos, >=20 > I already explained why I=E2=80=99m objecting to adopt this document = at this stage. In addition to that, I have some concerns that I=E2=80=99m = listing below: > =C2=B7 I don=E2=80=99t think it is a good idea to have a lot = of documents to define pieces of information that can be supplied using = nsh. Are you advocating a single uber meta-document for all-things NSH? > =C2=B7 None of the WG adopted use case documents call for the = appid as a mandatory-to-support information. I do not believe anyone is saying this is mandatory-to-support, nor that = this document is the result of a requirement from some other document. > =C2=B7 The appid draft (targeting =E2=80=9CStandards Track=E2=80= =9D status) relies on a ** VENDOR ** IPFIX extension (an information = RFC). This draft relies on registered IPFIX IEs. What is exactly the issue = with these registrations being performed via an Informational RFC? > Is there any reason why that information was not part of the normal = IPFIX assignment process? That=E2=80=99s a historical question for the authors of that RFC. > =C2=B7 There is an IPR for the appid draft. Before endorsing = the draft, it would be appropriate for the WG to understand first the = problem to solve, agree it is worth to be solved, and then the WG can = see whether there are other solution designs without having another yet = SFC document with an IPR on it! >=20 That=E2=80=99s exactly what a call-for-adoption is for. The question of does the WG-at-large believe this is a worthy problem, = and does this document propose a good starting point. For completeness, this is from IETF 93: = https://www.ietf.org/proceedings/93/slides/slides-93-sfc-5.pdf = Best, =E2=80=94 Carlos. > Cheers, > Med >=20 > De : Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com = ] > Envoy=C3=A9 : lundi 2 mai 2016 16:44 > =C3=80 : BOUCADAIR Mohamed IMT/OLN > Cc : Jim Guichard (jguichar); sfc@ietf.org ; = draft-penno-sfc-appid@ietf.org > Objet : Re: [sfc] Call for WG adoption of draft-penno-sfc-appid-03 >=20 > Dear Med, >=20 > Trying to extract the key statements from the line-by-line reply, you = said: >=20 > Given this goal of conveying application information, we found one = specific syntax leveraging the Application Information structure from = IPFIX. > [Med] Which makes sense. I fully agree with that. >=20 > Apologies in advance for asking again, but, what exactly is your = concern with this document (beyond your proposal to use IPFIX IEs for = everything)? >=20 >=20 > Some additional follow-ups for closure inline. >=20 > On May 2, 2016, at 10:32 AM, mohamed.boucadair@orange.com = wrote: >=20 > Re-, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > De : Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com = ] > Envoy=C3=A9 : lundi 2 mai 2016 15:53 > =C3=80 : BOUCADAIR Mohamed IMT/OLN > Cc : Jim Guichard (jguichar); sfc@ietf.org ; = draft-penno-sfc-appid@ietf.org > Objet : Re: [sfc] Call for WG adoption of draft-penno-sfc-appid-03 >=20 > Dear Med, >=20 > Thanks for taking the time to review and comment. Please find some = comments inline. >=20 > On May 2, 2016, at 7:58 AM, mohamed.boucadair@orange.com = wrote: >=20 > Hi Jim, all, >=20 > I interpret this proposal as if it wants to inherit the IPFIX = Application information to be conveyed in an nsh header. I have some = issues with the rationale of this draft, not its goal per se. >=20 > I do not support this draft. I do think there are other design choices = that can be investigated by the WG to inherit existing IPFIX IEs without = writing a new RFC for it for EACH IE to be conveyed in an NSH header. >=20 > I believe you are misunderstanding what draft-penno-sfc-appid-03 is = about. The goal is to convey application information in SFC Metadata. It = is not to inherit existing IPFIX IEs. > [Med] You may be right but the document explicitly says: >=20 > This document purposes the use of IPFIX [RFC7011 = ] application > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > information to be carried in the NSH context metadata of a MDType-1 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > packet. >=20 >=20 >=20 >=20 > Abstract >=20 > This document proposes to use the structured application = information > in the service function chaining metadata, and specifies a YANG = model > for the configuration of the application registry. >=20 >=20 >=20 >=20 > Given this goal of conveying application information, we found one = specific syntax leveraging the Application Information structure from = IPFIX. > [Med] Which makes sense. I fully agree with that. >=20 > I wanted to clarify the difference, as it is significance. >=20 > If there are other design choices *to convey application = identification* (not to inherit existing fields from anywhere as a = goal), we=E2=80=99d love to hear them. > [Med] Who is asking to =E2=80=9Cinherit existing fields=E2=80=9D? >=20 > This specific proposal compiles and runs. >=20 >=20 >=20 >=20 > For example, there is a more general proposal that aims to import ANY = IPFIX Information Element (that will cover the particular case in this = document):http://www.ietf.org/mail-archive/web/sfc/current/msg04492.html = without = consuming the WG effort to edit/review/publish RFCs for each promising = IPFIX IEs. >=20 >=20 > I believe this will cause more headaches than solutions =E2=80=94 I = replied in a separate note. >=20 >=20 >=20 > Further, I have the following questions for the draft: >=20 > =C2=B7 Why reserving this proposal for MD#1? >=20 > Because that is the minimal one to use. > [Med] I don=E2=80=99t parse this, sorry. >=20 > However, this is also defined for MD-Type 2 at = https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01#page-7 = (see = =E2=80=9C5. Application ID=E2=80=9D) > [Med] I don=E2=80=99t think it is a good idea to have a lot of = documents to define the same set of information. >=20 >=20 > Noted. Thank you. >=20 >=20 >=20 > Do you suggest we should define MD-Type 2 in this draft as well? Happy = to do so if that=E2=80=99s useful. > [Med] No, I=E2=80=99m not proposing that. I=E2=80=99m trying to = understand the technical rationale for that choice. >=20 >=20 >=20 > This doc defines MD-Type 1, and the TLV doc defines MD-Type 2 for a = bunch of things. >=20 > If you have an editorial or information arrangement proposal, please = do share. Happy to accommodate to make things easier to parse. >=20 >=20 >=20 >=20 >=20 > =C2=B7 What means the following headers? > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 3 | 0 | 161 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Network Shared Context | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Service Platform Context | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Service Shared Context | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Figure 2: Example of Metadata Including the SNMP Application > Identification >=20 >=20 >=20 > It is an example of metadata including the SNMP application = identification. > [Med] My question was maybe not clear: what a Network Shared Context? = What is a Service Platform Context? What is Service Shared Context? >=20 >=20 > Ah, thanks for the clarification. These are remainders from earlier = versions of draft-ietf-sfc-nsh, which we have to fix. This is a good = adoption comment and a good catch. >=20 > Best, >=20 > =E2=80=94 Carlos. >=20 >=20 > Best, >=20 > =E2=80=94 Carlos. >=20 >=20 >=20 > Cheers, > Med >=20 > De : sfc [mailto:sfc-bounces@ietf.org ] = De la part de Jim Guichard (jguichar) > Envoy=C3=A9 : vendredi 29 avril 2016 18:31 > =C3=80 : sfc@ietf.org > Objet : [sfc] Call for WG adoption of draft-penno-sfc-appid-03 >=20 > Dear WG: >=20 > We did not receive many responses for this call for adoption and = therefore would like to re-invite people to post their thoughts on = adopting this document into the SFC WG. The call for adoption will run = for a further 2 weeks ending 6/13/2016. >=20 > Thanks! >=20 > SFC Chairs >=20 > From: Jim Guichard > > Date: Thursday, February 11, 2016 at 3:24 PM > To: "sfc@ietf.org " > > Subject: Call for WG adoption of draft-penno-sfc-appid-03 >=20 > Dear WG: >=20 > This email serves as a call for WG adoption of = draft-penno-sfc-appid-03 as a WG document. The call for adoption will = run for 2 weeks ending 2/25/2016. >=20 > Please note that this is a call for adoption, and not a last call for = content of the document. Adopting a WG document simply means that the WG = will focus its efforts on that particular draft going forward, and use = that document for resolving open issues and documenting the WG=E2=80=99s = decisions. >=20 > Please indicate whether you support adoption for not, and if not why. = Issues you have with the current document itself can also be raised, but = they should be raised in the context of what should be changed in the = document going forward, rather than a pre-condition for adoption. >=20 > Finally, now is also a good time to poll for knowledge of any IPR that = applies to this draft, in line with the IPR disclosure obligations for = WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). = If you are listed as a document author please respond to this email (to = the chairs) whether or not you are aware of any relevant IPR. >=20 > Thanks! >=20 > SFC Chairs > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc = --Apple-Mail=_76A576C9-428A-4DDC-BEF6-5066A4A1F55C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear Med,

I= am trying to understand your objection.

Do you believe that (1) conveying = application information in the service function chaining metadata is not = a problem the WG should try to solve, that (2) it is a problem for the = WG to solve but this document is not a good basis for it and there are = other proposals the WG can use which are better (and why), or that (3) = something else?

What you explained before says:
I do not support this draft. I = do think there are other design choices that can be investigated by the = WG to inherit existing IPFIX IEs without writing a new RFC for it for = EACH IE to be conveyed in an NSH = header. 

And my response to that has been that = the goal is not to inherit existing IPFIX IEs, and less so in a sweeping = broadmost fashion.

More inline...

On = May 3, 2016, at 2:17 AM, mohamed.boucadair@orange.com wrote:

Carlos,
 
I already explained why I=E2=80=99m objecting = to adopt this document at this stage. In addition to that, I have some = concerns that I=E2=80=99m listing below:
=C2=B7         I don=E2=80=99t think it is a good idea to have a lot of = documents to define pieces of information that can be supplied using = nsh.

Are you advocating a single uber meta-document for = all-things NSH?

=C2=B7         None of the WG adopted use case documents call for the appid = as a mandatory-to-support = information.

I do not believe anyone is saying this is = mandatory-to-support, nor that this document is the result of a = requirement from some other document.

=C2=B7         The appid draft (targeting =E2=80=9CStandards Track=E2=80=9D = status) relies on a ** VENDOR ** IPFIX extension (an information = RFC).

This = draft relies on registered IPFIX IEs. What is exactly the issue with = these registrations being performed via an Informational RFC?

 Is there any reason = why that information was not part of the normal IPFIX assignment = process?

That=E2=80=99s a historical question for the = authors of that RFC.

=C2=B7         There is an IPR for the appid draft. Before endorsing the = draft, it would be appropriate for the WG to understand first the = problem to solve, agree it is worth to be solved, and then the WG can = see whether there are other solution designs without having another yet = SFC document with an IPR on it!
 

That=E2=80=99s exactly = what a call-for-adoption is for.

The question of does the WG-at-large = believe this is a worthy problem, and does this document propose a good = starting point.

For completeness, this is from IETF 93: https://www.ietf.org/proceedings/93/slides/slides-93-sfc-5.pdf<= /a>

Best,

=E2=80=94 Carlos.

Cheers,
Med
 
De : Carlos = Pignataro (cpignata) [mailto:cpignata@cisco.com] 
Envoy=C3=A9 : lundi 2 mai 2016 16:44
=C3=80 : BOUCADAIR Mohamed = IMT/OLN
Cc : Jim Guichard = (jguichar); sfc@ietf.org; draft-penno-sfc-appid@ietf.org
Objet : Re: [sfc] Call for WG = adoption of draft-penno-sfc-appid-03
 
Dear Med,
 
Trying to extract the key statements from the = line-by-line reply, you said:
 
Given = this goal of conveying application information, we found one specific = syntax leveraging the Application Information structure from IPFIX.
[Med] Which makes sense. I fully agree with = that.
 
Apologies in advance for asking again, but, what = exactly is your concern with this document (beyond your proposal to use = IPFIX IEs for everything)?
 
 
Some additional = follow-ups for closure inline.
 
On May 2, 2016, at = 10:32 AM, mohamed.boucadair@orange.com wrote:
 
Re-,
 
Please = see inline.
 
Cheers,
Med
 
De : Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] 
Envoy=C3=A9 : lundi 2 mai 2016 15:53
=C3=80 : BOUCADAIR Mohamed = IMT/OLN
Cc : Jim Guichard = (jguichar); sfc@ietf.org; draft-penno-sfc-appid@ietf.org
Objet : Re: [sfc] Call for WG = adoption of draft-penno-sfc-appid-03
 
Dear Med,
 
Thanks for taking the time to review and = comment. Please find some comments inline.
 
On = May 2, 2016, at 7:58 AM, mohamed.boucadair@orange.com wrote:
 
Hi Jim, all,
 
I interpret this proposal = as if it wants to inherit the IPFIX Application information to be = conveyed in an nsh header. I have some issues with the rationale of this = draft, not its goal per se.
 
I do not support this = draft. I do think there are other design choices that can be = investigated by the WG to inherit existing IPFIX IEs without writing a = new RFC for it for EACH IE to be conveyed in an NSH header. 
 
I believe you are misunderstanding what = draft-penno-sfc-appid-03 is about. The goal is to convey application = information in SFC Metadata. It is not to inherit existing IPFIX = IEs.
[Med] You may be right but = the document explicitly says:
 
   This document purposes the use of IPFIX = [RFC7011] application
          &nb= sp;            = ;   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   information to be carried in the = NSH context metadata of a MDType-1
   = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   packet.
 
 
 
 
Abstract
 
   This document proposes to use the = structured application information
   in the = service function chaining metadata, and specifies a YANG model
   for the configuration of the application = registry.
 
 


Given = this goal of conveying application information, we found one specific = syntax leveraging the Application Information structure from IPFIX.
[Med] Which makes sense. I fully agree with = that.
 
I wanted to clarify the difference, as it is = significance.
 
If there = are other design choices *to convey application identification* = (not to inherit existing fields from anywhere as a goal), we=E2=80=99d = love to hear them. 
[Med] = Who is asking to =E2=80=9Cinherit existing fields=E2=80=9D?
 
This = specific proposal compiles and runs.



 
For example, there is a more general proposal that aims to = import ANY IPFIX Information Element (that will cover the particular = case in this document):http://www.ietf.org/mail-archive/web/sfc/current/msg04492.html<= /span> without = consuming the WG effort to edit/review/publish RFCs for each promising = IPFIX IEs.
 
 
I = believe this will cause more headaches than solutions =E2=80=94 I = replied in a separate note.



Further, I have the following questions for = the draft:
 
=C2=B7         Why = reserving this proposal for MD#1?
 
Because that is the minimal one to = use. 
[Med] I don=E2=80=99t parse this, = sorry.
 
However, this is also defined = for MD-Type 2 at https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01#page-7 (see = =E2=80=9C5.   Application = ID=E2=80=9D)
[Med] I don=E2=80=99t = think it is a good idea to have a lot of documents to define the same = set of information.
 
 
Noted. Thank you.
 


Do you suggest we = should define MD-Type 2 in this draft as well? Happy to do so if = that=E2=80=99s useful.
[Med] = No, I=E2=80=99m not proposing that. I=E2=80=99m trying to understand the = technical rationale for that choice.
 
 
 
This = doc defines MD-Type 1, and the TLV doc defines MD-Type 2 for a bunch of = things.
 
If you have an editorial or information arrangement = proposal, please do share. Happy to accommodate to make things easier to = parse.
 




=C2=B7         What = means the following headers?
      = 0            &= nbsp;      = 1            &= nbsp;      = 2            &= nbsp;      3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 = 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     = |       = 3       = |        = 0      = |            &= nbsp; = 161            = ;  |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     = |            =       Network Shared = Context           &= nbsp;           = |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     = |            &= nbsp;     Service Platform = Context           &= nbsp;         |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     = |            &= nbsp;     Service Shared = Context           &= nbsp;           = |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
       Figure 2: Example of = Metadata Including the SNMP Application
          &nb= sp;            = ;       Identification
 
 
 
It is an example of metadata including = the SNMP application identification.
[Med] = My question was maybe not clear: what a Network Shared Context? = What is a Service Platform Context? What is Service Shared = Context?
 
 
Ah, thanks for the clarification. These are = remainders from earlier versions of draft-ietf-sfc-nsh, which we have to = fix. This is a good adoption comment and a good catch.
 
Best,
 
=E2=80=94 Carlos.


Best,
 
=E2=80= =94 Carlos.



Cheers,
Med
 
De : sfc [mailto:sfc-bounces@ietf.org] De la part = de Jim Guichard = (jguichar)
Envoy=C3=A9 : vendredi 29 avril 2016 = 18:31
=C3=80 : sfc@ietf.org
Objet : [sfc] Call for WG adoption = of draft-penno-sfc-appid-03
 
Dear WG:
 
We did not receive many responses for this call = for adoption and therefore would like to re-invite people to post their = thoughts on adopting this document into the SFC WG. The call for = adoption will run for a further 2 weeks ending = 6/13/2016. 
 
Thanks!
 
SFC Chairs
 
From: Jim Guichard <jguichar@cisco.com>
Date: Thursday, February 11, = 2016 at 3:24 PM
To: "sfc@ietf.org" <sfc@ietf.org>
Subject: Call for WG adoption of = draft-penno-sfc-appid-03
 
Dear = WG:
 
This email serves as a call for WG = adoption of draft-penno-sfc-appid-03 as a WG document. The call for = adoption will run for 2 weeks ending 2/25/2016.
 
Please note = that this is a call for adoption, and not a last call for content of the = document. Adopting a WG document simply means that the WG will focus its = efforts on that particular draft going forward, and use that document = for resolving open issues and documenting the WG=E2=80=99s = decisions.
 
Please indicate whether you support = adoption for not, and if not why. Issues you have with the current = document itself can also be raised, but they should be raised in the = context of what should be changed in the document going forward, rather = than a pre-condition for adoption. 
 
Finally, now = is also a good time to poll for knowledge of any IPR that applies to = this draft, in line with the IPR disclosure obligations for WG = participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If = you are listed as a document author please respond to this email (to the = chairs) whether or not you are aware of any relevant IPR.
 
Thanks!
 
SFC Chairs
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

= --Apple-Mail=_76A576C9-428A-4DDC-BEF6-5066A4A1F55C-- --Apple-Mail=_F2C9285D-F51A-45DF-9A50-45FFA8D27C16 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 - http://gpgtools.org iQIcBAEBCAAGBQJXKLKiAAoJEIXgpQGOZny9Vx8QAI4wGcWrRQ7FqKDClmJVCLr8 z49/mvoUTn4jo9CmaQOUn3M6YYrY3pJYmVSm0vnl1Mk7aK6fXnvtWBCqJFewVL46 g1UIFyNxEVapq/eM7y5acnT0/dvEb0UV+OkqZvP1X7DQeljo16frtFwt3Vvg8++z CXbBzkstBOVg1D5C98/bVvN/Kv1ikdh95QFL3vkdlZXN4GGayRulOO9E8TqtmQJl KRfI2dNfJBY1yKyr1W2UFEnQrinIXZAVKIN6cyDmGQBxV5zkUZbgoTSgTqmb6oZB N9vVGS9HKOCszTIyVxpJLT5EN1tM3zTsP/PnV1yEkx8yiTM9DdspnCsp8abDZAxJ oELJhdnDfz3OzYVrj0tTuEqWPX/7nQ4yXEj7Bj6D8LpAk0psYPtPgLYCkuTBsveU wul/MH943sQljgyeJb99saLHoh123zXUjSG1cktUoRNXxBNjc5Q8QyIXABHEwsdo wByQBsQ+lxJqaBENxXr6ytL+UhCT1QM1saYfL6oyd6fGtCoaHxNNpzDXXsn2qmqP AqCim6nSQskhftB5eba3apR17zgT5s8uNtoaxARMpJwlxd2S8WSgawh/ZamXUykE xFkvGwoKJBfgN3R1vHx2n3SYaqXrYQZcVgBPoZkG5ZaxxVIgkqJ4Lxa2mjj9yeXv O70uH2x14pvH81zzBZlI =kAU3 -----END PGP SIGNATURE----- --Apple-Mail=_F2C9285D-F51A-45DF-9A50-45FFA8D27C16-- From nobody Tue May 3 08:35:10 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3084612D950 for ; Tue, 3 May 2016 08:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 n9m2Cq00msWi for ; Tue, 3 May 2016 08:35:06 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 2804B12D8D3 for ; Tue, 3 May 2016 08:35:06 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([::1]) with mapi id 14.03.0195.001; Tue, 3 May 2016 11:35:05 -0400 From: Dave Dolson To: "sfc@ietf.org" Thread-Topic: Does NSH OAM bit change the meaning of Next-Header field? Thread-Index: AdGlUV25l2a2MKjYRAGRL6A+jIxF1g== Date: Tue, 3 May 2016 15:35:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830F4E720wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: [sfc] Does NSH OAM bit change the meaning of Next-Header field? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 15:35:08 -0000 --_000_E8355113905631478EFF04F5AA706E9830F4E720wtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd like to understand whether setting the OAM bit is intended to change th= e meaning of the NSH Next-Header field. I.e., is OAM-Protocol in a different number space from Next-Header? This is hinted at in https://tools.ietf.org/html/draft-yang-sfc-trace-issue= -analysis-01, for example, where the field does not have "Next Header" name, rather "OAM Protocol" as below. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ |Ver|1|C|R|R|R|R|R|R| Length | MD-type=3D0x2 | OAM Protocol | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Service Path ID | Service Index | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Mandatory Context Header | |S +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F | Mandatory Context Header | |C +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Mandatory Context Header | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Mandatory Context Header | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ < If it is a distinct number space, is there any standard-track draft that de= fines how values are to be allocated? David Dolson Senior Software Architect, Sandvine Inc. --_000_E8355113905631478EFF04F5AA706E9830F4E720wtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’d like to understand whether setting the OAM= bit is intended to change the meaning of the NSH Next-Header field.

I.e., is OAM-Protocol in a different number space fr= om Next-Header?

 

This is hinted at in https://tools.ietf.org/html/draft-yang-sfc-trace-issue-analysis-01, for= example, where the field

does not have “Next Header” name, rather= “OAM Protocol” as below.

 

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 = 9 0 1

+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+-+-+\

|Ver|1|C|R|R|R|R|R|R|   Length  |  MD-= type=3D0x2  |  OAM Protocol | |

+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+-+-+ |

|          Se= rvice Path ID          &n= bsp;           | Service = Index | |

+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+-+-+ |

|         &nb= sp;      Mandatory Context Header   = ;            &n= bsp;       | |S

+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+-+-+ |F

|         &nb= sp;      Mandatory Context Header   = ;            &n= bsp;       | |C

+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+-+-+ |

|         &nb= sp;      Mandatory Context Header   = ;            &n= bsp;       | |

+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+-+-+ |

|         &nb= sp;      Mandatory Context Header   = ;            &n= bsp;       | |

+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+-+ <<= /span>

 

If it is a distinct number space, is there any stand= ard-track draft that defines how values are to be allocated?

 

 

David Dolson

Senior Software Architect, Sandvine Inc.<= /p>

 

--_000_E8355113905631478EFF04F5AA706E9830F4E720wtlexchp2sandvi_-- From nobody Tue May 3 10:05:42 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA2112DBAF; Tue, 3 May 2016 10:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.681 X-Spam-Level: X-Spam-Status: No, score=-1.681 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 ueS7D9iSbSlD; Tue, 3 May 2016 10:05:40 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 328F412DC38; Tue, 3 May 2016 10:00:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 1E8F026377C; Tue, 3 May 2016 10:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1462294826; bh=QUz3rd031eD0TeuGqPn+A3SphfMTDO9gQ1uyQcqfgoc=; h=Subject:References:Cc:From:Date:In-Reply-To:From; b=DRO/jS18cGztXWmM0ICLoI2HZ3rSCyClOBmgfawJkoMnIlt9zoVslPophEklf94V8 5+IDaoG2wD/Is33JrUUJXbhrjEhrlowlIySu7jPEOdqfmQlnN+nxdmqxsHqwMQbwT0 rZXpdWmEVzGZQho+HXMz3tj6ajokvDzkPmof4aUw= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 94F6B251F41; Tue, 3 May 2016 10:00:25 -0700 (PDT) References: <787AE7BB302AE849A7480A190F8B933008D62994@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <3501127B-E55B-4FA1-9A63-47D046371132@cisco.com> <787AE7BB302AE849A7480A190F8B933008D62C02@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <30650369-47D3-4387-B535-C2B7756B246A@cisco.com> <787AE7BB302AE849A7480A190F8B933008D6310A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: "Joel M. Halpern" Message-ID: <738e733a-8962-cc66-e7e7-1863dd4f6627@joelhalpern.com> Date: Tue, 3 May 2016 12:59:59 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-penno-sfc-appid@ietf.org" , "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-appid-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 17:05:41 -0000 I read this document. The problem / task is clearly useful, so I support having the WG adopt a document to address it. The proposed information structure seems a good start, so I support adoption of this document. I think it would be helped by a little bit of text explaining how this would appear, with what length, in an MD-2 TLV, and what happens if the inner implicit length and the outer explicit length don't match. What is unclear to me is: what is the purpose of the YANG model? I have no problem with having separate documents defining additional TLVs. We are clearly going to need them. But defining a YANG model for each TLV seems really strange. Yours, Joel From nobody Tue May 3 10:08:23 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7609F12DC54 for ; Tue, 3 May 2016 10:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 Tfyu4MopNKcj for ; Tue, 3 May 2016 10:08:20 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 3597812DAEC for ; Tue, 3 May 2016 10:03:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 2356B251F41; Tue, 3 May 2016 10:03:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1462295020; bh=wapXBuhAFx9sVp539GIj21gOTJIE4fCNkTnR9UTa6AY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=mFK0cMdhYurs0gdXX+o2yX7bzgidxZGgfq8ew2m8uZg7O84zYM6YmcZN0c5EPOU8E RUfZcTCK0Iey3WIMPjgUWZSYK9qPZC+7i1vFjletDvEkcop9T0tuOfp6JqeqcqoPrU 88sp4G3y6SOguobJ/RrX6j8+Is1mesLt4uD1Rs3g= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id B2B54251F34; Tue, 3 May 2016 10:03:39 -0700 (PDT) To: Dave Dolson , "sfc@ietf.org" References: From: "Joel M. Halpern" Message-ID: <652d807d-651e-b631-b308-5596676d7147@joelhalpern.com> Date: Tue, 3 May 2016 13:03:14 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Does NSH OAM bit change the meaning of Next-Header field? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 17:08:22 -0000 Good question. I would tend to prefer that we use a single number space for that, so as to reduce implementation complexity and usage errors. Yours, Joel On 5/3/16 11:35 AM, Dave Dolson wrote: > I’d like to understand whether setting the OAM bit is intended to change > the meaning of the NSH Next-Header field. > > I.e., is OAM-Protocol in a different number space from Next-Header? > > > > This is hinted at in > https://tools.ietf.org/html/draft-yang-sfc-trace-issue-analysis-01, for > example, where the field > > does not have “Next Header” name, rather “OAM Protocol” as below. > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ > > |Ver|1|C|R|R|R|R|R|R| Length | MD-type=0x2 | OAM Protocol | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > > | Service Path ID | Service Index | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > > | Mandatory Context Header | |S > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F > > | Mandatory Context Header | |C > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > > | Mandatory Context Header | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > > | Mandatory Context Header | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ < > > > > If it is a distinct number space, is there any standard-track draft that > defines how values are to be allocated? > > > > > > David Dolson > > Senior Software Architect, Sandvine Inc. > > > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Tue May 3 10:39:14 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0E412DBA4 for ; Tue, 3 May 2016 10:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 1JL3u4qrEOph for ; Tue, 3 May 2016 10:39:11 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB7812D0AE for ; Tue, 3 May 2016 10:39:08 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-2.sandvine.com (192.168.194.177) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 3 May 2016 13:39:07 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Tue, 3 May 2016 13:39:06 -0400 From: Dave Dolson To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Does NSH OAM bit change the meaning of Next-Header field? Thread-Index: AdGlUV25l2a2MKjYRAGRL6A+jIxF1gALddUAAAdNbAA= Date: Tue, 3 May 2016 17:39:05 +0000 Message-ID: References: <652d807d-651e-b631-b308-5596676d7147@joelhalpern.com> In-Reply-To: <652d807d-651e-b631-b308-5596676d7147@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Does NSH OAM bit change the meaning of Next-Header field? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 17:39:14 -0000 One thing we could do assume a single number space, but also specify which = values are valid per OAM setting. E.g., Next-Header value of 1 means IPv4, and must only be used with OAM=3D0= . Does it make sense to start assigning OAM protocols from 128 ?=20 Also, am I right in asking draft-ietf-sfc-nsh to address this? (Nothing is said about how Next-Header values from 4 to 0xFD are to be assi= gned) -Dave -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Tuesday, May 03, 2016 1:03 PM To: Dave Dolson; sfc@ietf.org Subject: Re: [sfc] Does NSH OAM bit change the meaning of Next-Header field= ? Good question. I would tend to prefer that we use a single number space for that, so as=20 to reduce implementation complexity and usage errors. Yours, Joel On 5/3/16 11:35 AM, Dave Dolson wrote: > I'd like to understand whether setting the OAM bit is intended to change > the meaning of the NSH Next-Header field. > > I.e., is OAM-Protocol in a different number space from Next-Header? > > > > This is hinted at in > https://tools.ietf.org/html/draft-yang-sfc-trace-issue-analysis-01, for > example, where the field > > does not have "Next Header" name, rather "OAM Protocol" as below. > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ > > |Ver|1|C|R|R|R|R|R|R| Length | MD-type=3D0x2 | OAM Protocol | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > > | Service Path ID | Service Index | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > > | Mandatory Context Header | |S > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F > > | Mandatory Context Header | |C > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > > | Mandatory Context Header | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > > | Mandatory Context Header | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ < > > > > If it is a distinct number space, is there any standard-track draft that > defines how values are to be allocated? > > > > > > David Dolson > > Senior Software Architect, Sandvine Inc. > > > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Tue May 3 11:19:25 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C8B12D0B7 for ; Tue, 3 May 2016 11:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 SOyOx4cFhXIT for ; Tue, 3 May 2016 11:19:20 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 A5CE712B016 for ; Tue, 3 May 2016 11:19:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 850C9259F5F; Tue, 3 May 2016 11:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1462299560; bh=z3nGX9LFgLsT3ErXT5YNIEGkn2lhmKhwN86zU1WMK7s=; h=Subject:To:References:From:Date:In-Reply-To:From; b=J+WrvF3HkVpdQuOdx/zN4EYDoYg9j80Ghay4v7RbWbQXfHlBeyZS6QX5LzjGIf5NN Vhio89R75TrmsOWhjrCGjGXUmpFvfJ0gmTT71DquR0uS6VyhoADOs0n24iZSq0LCtf FMe3L5/tkjNHg3tLS0lhJRiNlpCNTRohiA0tUlOw= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 138CF2535B1; Tue, 3 May 2016 11:19:20 -0700 (PDT) To: Dave Dolson , "sfc@ietf.org" References: <652d807d-651e-b631-b308-5596676d7147@joelhalpern.com> From: "Joel M. Halpern" Message-ID: Date: Tue, 3 May 2016 14:18:53 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] Does NSH OAM bit change the meaning of Next-Header field? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 18:19:22 -0000 Given that the NSH draft defines the OAM bit, it seems sensible to note that the setting of this bit does not change the meaning of the next-protocol field. I would prefer not to try to split the field protocol types between OAM and non-OAM. I don't think there is any need to do so. Yours, Joel On 5/3/16 1:39 PM, Dave Dolson wrote: > One thing we could do assume a single number space, but also specify which values are valid per OAM setting. > E.g., Next-Header value of 1 means IPv4, and must only be used with OAM=0. > > Does it make sense to start assigning OAM protocols from 128 ? > > Also, am I right in asking draft-ietf-sfc-nsh to address this? > (Nothing is said about how Next-Header values from 4 to 0xFD are to be assigned) > > > -Dave > > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Tuesday, May 03, 2016 1:03 PM > To: Dave Dolson; sfc@ietf.org > Subject: Re: [sfc] Does NSH OAM bit change the meaning of Next-Header field? > > Good question. > I would tend to prefer that we use a single number space for that, so as > to reduce implementation complexity and usage errors. > > Yours, > Joel > > On 5/3/16 11:35 AM, Dave Dolson wrote: >> I'd like to understand whether setting the OAM bit is intended to change >> the meaning of the NSH Next-Header field. >> >> I.e., is OAM-Protocol in a different number space from Next-Header? >> >> >> >> This is hinted at in >> https://tools.ietf.org/html/draft-yang-sfc-trace-issue-analysis-01, for >> example, where the field >> >> does not have "Next Header" name, rather "OAM Protocol" as below. >> >> >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ >> >> |Ver|1|C|R|R|R|R|R|R| Length | MD-type=0x2 | OAM Protocol | | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> >> | Service Path ID | Service Index | | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> >> | Mandatory Context Header | |S >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F >> >> | Mandatory Context Header | |C >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> >> | Mandatory Context Header | | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> >> | Mandatory Context Header | | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ < >> >> >> >> If it is a distinct number space, is there any standard-track draft that >> defines how values are to be allocated? >> >> >> >> >> >> David Dolson >> >> Senior Software Architect, Sandvine Inc. >> >> >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > From nobody Tue May 3 11:34:09 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B3D12D852 for ; Tue, 3 May 2016 11:34:07 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 6aSAS5PHfg5v for ; Tue, 3 May 2016 11:34:05 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 678DC12D854 for ; Tue, 3 May 2016 11:34:05 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-62-5728eeee9907 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 30.79.03614.EEEE8275; Tue, 3 May 2016 20:33:18 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0248.002; Tue, 3 May 2016 14:34:04 -0400 From: Gregory Mirsky To: "Joel M. Halpern" , Dave Dolson , "sfc@ietf.org" Thread-Topic: [sfc] Does NSH OAM bit change the meaning of Next-Header field? Thread-Index: AdGlUV25l2a2MKjYRAGRL6A+jIxF1gALddUAAAdNbAD//9q3gIAAQHtw Date: Tue, 3 May 2016 18:34:03 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A66D59@eusaamb103.ericsson.se> References: <652d807d-651e-b631-b308-5596676d7147@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyuXRPlO67dxrhBh936FlsXfaQ3eLjqTdM Fk8ebGV3YPZYsuQnk8e5Kd8ZPb5u3s4awBzFZZOSmpNZllqkb5fAlbHwwV6WguvyFf0XdrE0 MK6W6GLk4JAQMJFoOKfUxcgJZIpJXLi3nq2LkYtDSOAoo8Sqc/ehnGWMEnu3b2MGqWITMJJ4 sbGHHcQWESiQ+DWnFcwWFvCR2Ht6CgtE3Ffi6KT7jBC2m8TNG8vAbBYBFYkFk76D2bxANf/X XmSGWNDOJNHR8JEVJMEp4Cyx7NZBsEGMQCd9P7WGCcRmFhCXuPVkPhPEqQISS/acZ4awRSVe Pv7HCmErSUxaeo4Vol5HYsHuT2wQtrbEsoWvmSEWC0qcnPmEZQKj6CwkY2chaZmFpGUWkpYF jCyrGDlKiwtyctONDDcxAmPkmASb4w7Gvb2ehxgFOBiVeHgV2DTChVgTy4orcw8xSnAwK4nw Kj4HCvGmJFZWpRblxxeV5qQWH2KU5mBREufVf6kYLiSQnliSmp2aWpBaBJNl4uCUamC05BPa 9rRok0n5/KTu3PlcWVs49Pxbv1xdfO7I94PT/qx+y2X/55jFhIDsuplLrwTf5DJa8bGMxTR+ w70bd29oSUjfbxMVD/qatNto1fxbt5MPbp/PEu/am+a+T9PyhbzxX7PuJ3NPqCgKihukcu5U +FTQxx3emnD24auPl5kDtqsvq7QMfayrxFKckWioxVxUnAgAjUd4do0CAAA= Archived-At: Subject: Re: [sfc] Does NSH OAM bit change the meaning of Next-Header field? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 18:34:08 -0000 Hi Joel, how to interpret the situation when the OAM bit is set and the value in the= Next-protocol field is not any OAM protocol? Similar discussion we had in = NVO3. This situation, in my view, requires clarification of the priority be= tween OAM bit and the Next-protocol value to specify who gets to process th= e packet - OAM or the native processor of that protocol. Of course, we can = state that if the OAM bit is set the Next-protocol MUST be OAM and anything= else SHOULD be treated as error. Regards, Greg -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Tuesday, May 03, 2016 11:19 AM To: Dave Dolson; sfc@ietf.org Subject: Re: [sfc] Does NSH OAM bit change the meaning of Next-Header field= ? Given that the NSH draft defines the OAM bit, it seems sensible to note tha= t the setting of this bit does not change the meaning of the next-protocol = field. I would prefer not to try to split the field protocol types between OAM and= non-OAM. I don't think there is any need to do so. Yours, Joel On 5/3/16 1:39 PM, Dave Dolson wrote: > One thing we could do assume a single number space, but also specify whic= h values are valid per OAM setting. > E.g., Next-Header value of 1 means IPv4, and must only be used with OAM= =3D0. > > Does it make sense to start assigning OAM protocols from 128 ? > > Also, am I right in asking draft-ietf-sfc-nsh to address this? > (Nothing is said about how Next-Header values from 4 to 0xFD are to be=20 > assigned) > > > -Dave > > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Tuesday, May 03, 2016 1:03 PM > To: Dave Dolson; sfc@ietf.org > Subject: Re: [sfc] Does NSH OAM bit change the meaning of Next-Header fie= ld? > > Good question. > I would tend to prefer that we use a single number space for that, so=20 > as to reduce implementation complexity and usage errors. > > Yours, > Joel > > On 5/3/16 11:35 AM, Dave Dolson wrote: >> I'd like to understand whether setting the OAM bit is intended to=20 >> change the meaning of the NSH Next-Header field. >> >> I.e., is OAM-Protocol in a different number space from Next-Header? >> >> >> >> This is hinted at in >> https://tools.ietf.org/html/draft-yang-sfc-trace-issue-analysis-01,=20 >> for example, where the field >> >> does not have "Next Header" name, rather "OAM Protocol" as below. >> >> >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ >> >> |Ver|1|C|R|R|R|R|R|R| Length | MD-type=3D0x2 | OAM Protocol | | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> >> | Service Path ID | Service Index | | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> >> | Mandatory Context Header | |S >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F >> >> | Mandatory Context Header | |C >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> >> | Mandatory Context Header | | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> >> | Mandatory Context Header | | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ < >> >> >> >> If it is a distinct number space, is there any standard-track draft=20 >> that defines how values are to be allocated? >> >> >> >> >> >> David Dolson >> >> Senior Software Architect, Sandvine Inc. >> >> >> >> >> >> _______________________________________________ >> 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 Tue May 3 12:00:15 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D101312D8BF for ; Tue, 3 May 2016 12:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 Il0YMOUvKxMv for ; Tue, 3 May 2016 12:00:04 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 454C112D89B for ; Tue, 3 May 2016 12:00:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 30CDD2642DD; Tue, 3 May 2016 12:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1462302004; bh=c8UC/llyOom/6Ea8NTCY5IbkUubBuRF8AZpXel9QsUo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=MYcdzsjYpjnj2Bn6doAdlqk8tjdLKYJafqfwg//+i+kMTzdv4uXFlg38P4X+wd1a3 73aDzGCbJx23uRjzcxovZBUimQbkNe9GoWI8+GW4OmYkqvAcl/uLigHoe0S3/nW0d6 oceSxc8t/zAJMxaPY869ttIIF8ZI4y75Gu8SlTFM= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 986FF259F5F; Tue, 3 May 2016 12:00:03 -0700 (PDT) To: Gregory Mirsky , Dave Dolson , "sfc@ietf.org" References: <652d807d-651e-b631-b308-5596676d7147@joelhalpern.com> <7347100B5761DC41A166AC17F22DF11221A66D59@eusaamb103.ericsson.se> From: "Joel M. Halpern" Message-ID: Date: Tue, 3 May 2016 14:59:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A66D59@eusaamb103.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] Does NSH OAM bit change the meaning of Next-Header field? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 19:00:14 -0000 It seems to me that the SFC OAM document needs to (and I expect will) describe the handling of packets with the OAM bit set. That descriptionnecessarily includes what to do when the processing depends upon the next protocol field (frequent), and what happens when that field is needed and is not an OAM type. Trying to write all of that in the NSH document would, it seems to me, end up folding the whole OAM document into the NSH document. Which I consider undesirable. Yours, Joel On 5/3/16 2:34 PM, Gregory Mirsky wrote: > Hi Joel, > how to interpret the situation when the OAM bit is set and the value in the Next-protocol field is not any OAM protocol? Similar discussion we had in NVO3. This situation, in my view, requires clarification of the priority between OAM bit and the Next-protocol value to specify who gets to process the packet - OAM or the native processor of that protocol. Of course, we can state that if the OAM bit is set the Next-protocol MUST be OAM and anything else SHOULD be treated as error. > > Regards, > Greg > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Tuesday, May 03, 2016 11:19 AM > To: Dave Dolson; sfc@ietf.org > Subject: Re: [sfc] Does NSH OAM bit change the meaning of Next-Header field? > > Given that the NSH draft defines the OAM bit, it seems sensible to note that the setting of this bit does not change the meaning of the next-protocol field. > > I would prefer not to try to split the field protocol types between OAM and non-OAM. I don't think there is any need to do so. > > Yours, > Joel > > On 5/3/16 1:39 PM, Dave Dolson wrote: >> One thing we could do assume a single number space, but also specify which values are valid per OAM setting. >> E.g., Next-Header value of 1 means IPv4, and must only be used with OAM=0. >> >> Does it make sense to start assigning OAM protocols from 128 ? >> >> Also, am I right in asking draft-ietf-sfc-nsh to address this? >> (Nothing is said about how Next-Header values from 4 to 0xFD are to be >> assigned) >> >> >> -Dave >> >> >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Tuesday, May 03, 2016 1:03 PM >> To: Dave Dolson; sfc@ietf.org >> Subject: Re: [sfc] Does NSH OAM bit change the meaning of Next-Header field? >> >> Good question. >> I would tend to prefer that we use a single number space for that, so >> as to reduce implementation complexity and usage errors. >> >> Yours, >> Joel >> >> On 5/3/16 11:35 AM, Dave Dolson wrote: >>> I'd like to understand whether setting the OAM bit is intended to >>> change the meaning of the NSH Next-Header field. >>> >>> I.e., is OAM-Protocol in a different number space from Next-Header? >>> >>> >>> >>> This is hinted at in >>> https://tools.ietf.org/html/draft-yang-sfc-trace-issue-analysis-01, >>> for example, where the field >>> >>> does not have "Next Header" name, rather "OAM Protocol" as below. >>> >>> >>> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ >>> >>> |Ver|1|C|R|R|R|R|R|R| Length | MD-type=0x2 | OAM Protocol | | >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >>> >>> | Service Path ID | Service Index | | >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >>> >>> | Mandatory Context Header | |S >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F >>> >>> | Mandatory Context Header | |C >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >>> >>> | Mandatory Context Header | | >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >>> >>> | Mandatory Context Header | | >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ < >>> >>> >>> >>> If it is a distinct number space, is there any standard-track draft >>> that defines how values are to be allocated? >>> >>> >>> >>> >>> >>> David Dolson >>> >>> Senior Software Architect, Sandvine Inc. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 Tue May 3 12:02:06 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF05412D89B for ; Tue, 3 May 2016 12:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 pZF9Sh73SvDO for ; Tue, 3 May 2016 12:02:02 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.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 6416812D0C2 for ; Tue, 3 May 2016 12:01:46 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-a9-5728ee1306a6 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id B8.6A.09012.31EE8275; Tue, 3 May 2016 20:29:39 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Tue, 3 May 2016 15:01:45 -0400 From: Gregory Mirsky To: "Joel M. Halpern" , Dave Dolson , "sfc@ietf.org" Thread-Topic: [sfc] Does NSH OAM bit change the meaning of Next-Header field? Thread-Index: AdGlUV25l2a2MKjYRAGRL6A+jIxF1gALddUAAAdNbAD//9q3gIAAQHtw///K54CAAEKskA== Date: Tue, 3 May 2016 19:01:44 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A66DF8@eusaamb103.ericsson.se> References: <652d807d-651e-b631-b308-5596676d7147@joelhalpern.com> <7347100B5761DC41A166AC17F22DF11221A66D59@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXRPuK7wO41wg+X3ZCy2LnvIbvHx1Bsm iycPtrI7MHssWfKTyePclO+MHl83b2cNYI7isklJzcksSy3St0vgynj9voGp4LV6xfVPP5ka GD/JdTFyckgImEg8uHCPEcIWk7hwbz1bFyMXh5DAUUaJqRMnsEM4yxglHlz/xQZSxSZgJPFi Yw87iC0iUCDxa04rmC0s4COx9/QUFoi4r8TRSfcZIewwiZ/3NoD1sgioSCycehzM5gWqOfC8 G2pbC7PE2XmrwBo4BZwlzrxdAlbECHTS91NrmEBsZgFxiVtP5jNBnCogsWTPeWYIW1Ti5eN/ rBC2ksSkpedYIep1JBbs/sQGYWtLLFv4mhlisaDEyZlPWCYwis5CMnYWkpZZSFpmIWlZwMiy ipGjtLggJzfdyGATIzBKjkmw6e5gvD/d8xCjAAejEg+vAptGuBBrYllxZe4hRgkOZiURXsXn QCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8Yo8Uw4UE0hNLUrNTUwtSi2CyTBycUg2MocoyxX+3 b7/Su0j6Z8fJq7Nlfrc0HjYwa11asyphTb7ZtpsOM38Y1ljNsa134VS4+Mboq/yD2ebnjzFF p9drTKlMijkizljHxjONMZ09f7/E7RO7v315Pn22VD3HsW/V61+uPbZ6o/iuv/5KN3mLfXbM OB4ufuezSLiNECtncem3h4uC678yKbEUZyQaajEXFScCAMGCJBmOAgAA Archived-At: Subject: Re: [sfc] Does NSH OAM bit change the meaning of Next-Header field? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 19:02:05 -0000 Hi Joel, wholeheartedly agree and am looking forward to more discussions. Regards, Greg -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Tuesday, May 03, 2016 12:00 PM To: Gregory Mirsky; Dave Dolson; sfc@ietf.org Subject: Re: [sfc] Does NSH OAM bit change the meaning of Next-Header field= ? It seems to me that the SFC OAM document needs to (and I expect will) descr= ibe the handling of packets with the OAM bit set. That descriptionnecessar= ily includes what to do when the processing depends upon the next protocol = field (frequent), and what happens when that field is needed and is not an = OAM type. Trying to write all of that in the NSH document would, it seems = to me, end up folding the whole OAM document into the NSH document. Which = I consider undesirable. Yours, Joel On 5/3/16 2:34 PM, Gregory Mirsky wrote: > Hi Joel, > how to interpret the situation when the OAM bit is set and the value in t= he Next-protocol field is not any OAM protocol? Similar discussion we had i= n NVO3. This situation, in my view, requires clarification of the priority = between OAM bit and the Next-protocol value to specify who gets to process = the packet - OAM or the native processor of that protocol. Of course, we ca= n state that if the OAM bit is set the Next-protocol MUST be OAM and anythi= ng else SHOULD be treated as error. > > Regards, > Greg > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Tuesday, May 03, 2016 11:19 AM > To: Dave Dolson; sfc@ietf.org > Subject: Re: [sfc] Does NSH OAM bit change the meaning of Next-Header fie= ld? > > Given that the NSH draft defines the OAM bit, it seems sensible to note t= hat the setting of this bit does not change the meaning of the next-protoco= l field. > > I would prefer not to try to split the field protocol types between OAM a= nd non-OAM. I don't think there is any need to do so. > > Yours, > Joel > > On 5/3/16 1:39 PM, Dave Dolson wrote: >> One thing we could do assume a single number space, but also specify whi= ch values are valid per OAM setting. >> E.g., Next-Header value of 1 means IPv4, and must only be used with OAM= =3D0. >> >> Does it make sense to start assigning OAM protocols from 128 ? >> >> Also, am I right in asking draft-ietf-sfc-nsh to address this? >> (Nothing is said about how Next-Header values from 4 to 0xFD are to=20 >> be >> assigned) >> >> >> -Dave >> >> >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Tuesday, May 03, 2016 1:03 PM >> To: Dave Dolson; sfc@ietf.org >> Subject: Re: [sfc] Does NSH OAM bit change the meaning of Next-Header fi= eld? >> >> Good question. >> I would tend to prefer that we use a single number space for that, so=20 >> as to reduce implementation complexity and usage errors. >> >> Yours, >> Joel >> >> On 5/3/16 11:35 AM, Dave Dolson wrote: >>> I'd like to understand whether setting the OAM bit is intended to=20 >>> change the meaning of the NSH Next-Header field. >>> >>> I.e., is OAM-Protocol in a different number space from Next-Header? >>> >>> >>> >>> This is hinted at in >>> https://tools.ietf.org/html/draft-yang-sfc-trace-issue-analysis-01, >>> for example, where the field >>> >>> does not have "Next Header" name, rather "OAM Protocol" as below. >>> >>> >>> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ >>> >>> |Ver|1|C|R|R|R|R|R|R| Length | MD-type=3D0x2 | OAM Protocol | | >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >>> >>> | Service Path ID | Service Index | | >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >>> >>> | Mandatory Context Header | |S >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F >>> >>> | Mandatory Context Header | |C >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >>> >>> | Mandatory Context Header | | >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >>> >>> | Mandatory Context Header | | >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ < >>> >>> >>> >>> If it is a distinct number space, is there any standard-track draft=20 >>> that defines how values are to be allocated? >>> >>> >>> >>> >>> >>> David Dolson >>> >>> Senior Software Architect, Sandvine Inc. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 May 4 09:05:37 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BBF12D1B2 for ; Wed, 4 May 2016 09:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 AOD530JLmK1b for ; Wed, 4 May 2016 09:05:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43EF412D8A1 for ; Wed, 4 May 2016 08:57:54 -0700 (PDT) Received: from localhost ([::1]:34353 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1axzBR-0007XQ-U6; Wed, 04 May 2016 08:57:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: sunilvk@f5.com X-Trac-Project: sfc Date: Wed, 04 May 2016 15:57:53 -0000 X-URL: https://tools.ietf.org/sfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/sfc/trac/ticket/20 Message-ID: <053.44d8a5076d07c61144f6efc088bdec60@tools.ietf.org> X-Trac-Ticket-ID: 20 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: sunilvk@f5.com, sfc@ietf.org X-SA-Exim-Mail-From: trac+sfc@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: sfc@ietf.org Subject: [sfc] #20 (architecture): Word size limitation with MDType 1 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 16:05:34 -0000 #20: Word size limitation with MDType 1 Two points are being raised wrt MDType1 in NSH (document: draft-ietf-sfc- nsh-04.txt): (a) The fixed size and length of MDType1 issue was raised in email group by few folks which is yet to be addressed. The issue of MDType1 size arbitrarily being fixed 4 words is questionable as in many use cases and implementations. Also it is inefficient in the cases where less than 4 words suffices. Rather having one MDType (type 2) would suffice and address most if not all cases. The argument of MDTyp1 and being fixed 4 words for hardware efficiency need to be thought through. In above cases since it actually hinders overall system to process (reads/writes) the words (zeros in Context header) not in use for each packet for ingress and egress. For cases requiring more than 4 words, MDType2 would be the solution anyway but in this case each packet is mandated to still have MDType1 and of fixed 4 words of zeros for ingress and egress. (b) There is open ticket request to allocate flags in header for MDType to specify: append only, rw, mimic flags for nodes in transit to modify/update/preserve Metadata along the path. -- -----------------------------+------------------------ Reporter: sunilvk@f5.com | Owner: Paul Quinn Type: defect | Status: new Priority: major | Milestone: milestone1 Component: architecture | Version: 2.0 Severity: In WG Last Call | Keywords: NSH -----------------------------+------------------------ Ticket URL: sfc From nobody Wed May 4 09:11:09 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE69012DD48 for ; Wed, 4 May 2016 09:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 pgR9SsagrCOE for ; Wed, 4 May 2016 09:11:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C42D12DBB7 for ; Wed, 4 May 2016 09:02:28 -0700 (PDT) Received: from localhost ([::1]:34761 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1axzFs-0003IA-AN; Wed, 04 May 2016 09:02:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: sunilvk@f5.com X-Trac-Project: sfc Date: Wed, 04 May 2016 16:02:28 -0000 X-URL: https://tools.ietf.org/sfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/sfc/trac/ticket/20#comment:1 Message-ID: <068.1e903090b2d4c24aae5d925d26ed7db0@tools.ietf.org> References: <053.44d8a5076d07c61144f6efc088bdec60@tools.ietf.org> X-Trac-Ticket-ID: 20 In-Reply-To: <053.44d8a5076d07c61144f6efc088bdec60@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: sunilvk@f5.com, sfc@ietf.org X-SA-Exim-Mail-From: trac+sfc@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] #20 (architecture): Context Header size limit with MDType 1 (was: Word size limitation with MDType 1) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 16:11:08 -0000 #20: Context Header size limit with MDType 1 -- -----------------------------+------------------------- Reporter: sunilvk@f5.com | Owner: Paul Quinn Type: defect | Status: new Priority: major | Milestone: milestone1 Component: architecture | Version: 2.0 Severity: In WG Last Call | Resolution: Keywords: NSH | -----------------------------+------------------------- Ticket URL: sfc From prvs=92724792f=C.Koenning@f5.com Fri May 6 06:30:28 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D9112D5CF for ; Fri, 6 May 2016 06:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.017 X-Spam-Level: X-Spam-Status: No, score=-8.017 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=f5.com 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 YLlI91SvVmmS for ; Fri, 6 May 2016 06:30:25 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA8FF12D5B9 for ; Fri, 6 May 2016 06:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1462541426; x=1494077426; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=bdCA3ooMH7g/ferFM6OEdHL1bGiO135bwydI08lzDQw=; b=y+jbn0xBN8yNE1SQwaFV0CwJ8yavimAh0XDU3Tj8boc4xzYeCGjoAEXs fZEsF9b3a0IvI0vu3H62awkBDIB3SYpXX7RzhYQWbfLbKksMzxUNZ0qku 9wGw7RGZtnlOxu79ZFFiKC2XETVyZ5tFrf8zv6FHQivf28jlihc/I6LTD g=; X-IronPort-AV: E=Sophos;i="5.24,587,1454976000"; d="scan'208";a="217592744" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 06 May 2016 13:30:25 +0000 Received: from SEAEXCHMBX01.olympus.F5Net.com (192.168.15.223) by seaexchmbx01.olympus.F5Net.com (192.168.15.223) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Fri, 6 May 2016 06:30:25 -0700 Received: from SEAEXCHMBX01.olympus.F5Net.com ([fe80::143c:7597:6ad7:ce75]) by seaexchmbx01.olympus.F5Net.com ([fe80::143c:7597:6ad7:ce75%13]) with mapi id 15.00.1156.000; Fri, 6 May 2016 06:30:25 -0700 From: Christian Koenning To: "sfc@ietf.org" Thread-Topic: draft-ietf-sfc-nsh-04 NSH-MD-type 1 use-cases Thread-Index: AQHRp5ty47UgELVI6kCbX7BiL7kBmQ== Date: Fri, 6 May 2016 13:30:24 +0000 Message-ID: <09EB144B-2DC1-48FF-B438-4F26C4C70FA8@f5.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="utf-8" Content-ID: <47DDE66CA2146447AFB3B7C8681B1677@F5.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 06 May 2016 06:59:20 -0700 Subject: [sfc] draft-ietf-sfc-nsh-04 NSH-MD-type 1 use-cases X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 13:40:31 -0000 RGVhciBXRzoNCg0KV2UgYXJlIGN1cnJlbnRseSBsb29raW5nIGludG8gU0ZDIHVzZS1jYXNlcyBm b3IgbW9iaWxlIG5ldHdvcmtzIGFuZCBhcmUgdGhpbmtpbmcgb2YgdXNpbmcgdGhlIE5TSCBNZXRh ZGF0YSB0byBjYXJyeSBzdWJzY3JpYmVyIGlkZW50aXR5Lg0KDQpUaGUgaXAtYWRkcmVzcyB0byBz dWJzY3JpYmVyIG1hcHBpbmcgaW4gdG9kYXlzIG5ldHdvcmsgaXMgdXN1YWxseSBwcm9wYWdhdGVk IHZpYSBleHRlcm5hbCBjb250cm9sLXBsYW5lcywgZS5nLiBSQURJVVMgYWNjb3VudGluZy4gDQoN Ckxvb2tpbmcgYXQgdGhlIHBvc3NpYmlsaXRpZXMgIG9mIE5TSCwgdGhlIHN1YnNjcmliZXIgaWRl bnRpdHkgY291bGQgZWFzaWx5IGJlIGNhcnJpZWQgYXMgbWV0YWRhdGEgcGVyIHBhY2tldC4gDQoN Ckhvd2V2ZXIsIHRoZSAyIG1vc3QgY29tbW9uIGlkZW50aWZpZXJzIGluIG1vYmlsZSBuZXR3b3Jr cyBhcmUNCg0KLSBNb2JpbGUgU3RhdGlvbiBJbnRlcm5hdGlvbmFsIFN1YnNjcmliZXIgRGlyZWN0 b3J5IE51bWJlciAoTVNJU0ROKSANCiAgRS4xNjQgZGVmaW5lcyB0aGlzIHRvIGEgbWF4aW11bSBv ZiAxNSBkaWdpdHMNCiAgDQotIEludGVybmF0aW9uYWwgTW9iaWxlIFN1YnNjcmliZXIgSWRlbnRp dHkgKElNU0kpLCBhbHNvIGRlZmluZWQgYXMgYSAxNSBkaWdpdCBudW1iZXINCg0KTm93IGxvb2tp bmcgYXQgZHJhZnQtaWV0Zi1zZmMtbnNoLTA0LnR4dCBwLjEyIDMuNCBOU0gtTUQtdHlwZSAxIGVh Y2ggTWFuZGF0b3J5IENvbnRleHQgSGVhZGVyIGlzIGRlZmluZWQgYXMgNCBCeXRlcy4NCg0KICAg ICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDENCiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgIHxWZXJ8T3xDfFJ8UnxSfFJ8UnxSfCAgIExlbmd0 aCAgfCAgTUQtdHlwZT0weDEgIHwgTmV4dCBQcm90b2NvbCB8DQogICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICB8 ICAgICAgICAgIFNlcnZpY2UgUGF0aCBJRCAgICAgICAgICAgICAgICAgICAgICB8IFNlcnZpY2Ug SW5kZXggfA0KICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rDQogICAgfCAgICAgICAgICAgICAgICBNYW5kYXRvcnkgQ29u dGV4dCBIZWFkZXIgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgIHwg ICAgICAgICAgICAgICAgTWFuZGF0b3J5IENvbnRleHQgSGVhZGVyICAgICAgICAgICAgICAgICAg ICAgICB8DQogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCiAgICB8ICAgICAgICAgICAgICAgIE1hbmRhdG9yeSBDb250 ZXh0IEhlYWRlciAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgfCAg ICAgICAgICAgICAgICBNYW5kYXRvcnkgQ29udGV4dCBIZWFkZXIgICAgICAgICAgICAgICAgICAg ICAgIHwNCiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KICAgIA0KDQpBcyB5b3UgY2FuIHNlZSwgYSAxNSBkaWdpdCBu dW1iZXIgY2Fubm90IGJlIHJlcHJlc2VudGVkIHdpdGggNCBieXRlcy4gDQpEb2luZyB0aGUgbWF0 aCBpdCBzaG93cyB0aGF0ICBjZWlsaW5nIFsgbG9nMiAoICggMTBeMTYgKSAtMSApIF0gID0gNTQg Yml0cyB3b3VsZCBiZSBuZWVkZWQNCmZvciBzaW1wbGUgYmluYXJ5IHJlcHJlc2VudGF0aW9uLg0K DQpRdWVzdGlvbjogQXJlIHRoZXJlIGFueSBwbGFucyB0byBhZGRyZXNzIHRoaXMgaW4gdGhlIE1E IHR5cGUgMSwgZm9yIGV4YW1wbGUgYnkgZGVmaW5pbmcNCmNvbmNhdGVuYXRpb24gb2YgdHdvIE1h bmRhdG9yeSBDb250ZXh0IEhlYWRlcnMsIHdoaWNoIHRoZW4gd2l0aCA2NCBiaXRzIG9yIDggYnl0 ZSB3b3VsZCBmaXQgdGhlIHN1YnNjcmliZXIgaWRlbnRpdHkgPw0KDQoNCk1hbnkgVGhhbmtzDQoN CkNocmlzdGlhbiBLb2VubmluZw0KDQoNCg0K From nobody Fri May 6 07:48:15 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E77D12D643 for ; Fri, 6 May 2016 07:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 w-c2vXJui4WO for ; Fri, 6 May 2016 07:48:11 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id BD26412D640 for ; Fri, 6 May 2016 07:48:10 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Fri, 6 May 2016 10:48:10 -0400 From: Dave Dolson To: Christian Koenning , "sfc@ietf.org" Thread-Topic: draft-ietf-sfc-nsh-04 NSH-MD-type 1 use-cases Thread-Index: AQHRp5ty47UgELVI6kCbX7BiL7kBmZ+r/LKw Date: Fri, 6 May 2016 14:48:09 +0000 Message-ID: References: <09EB144B-2DC1-48FF-B438-4F26C4C70FA8@f5.com> In-Reply-To: <09EB144B-2DC1-48FF-B438-4F26C4C70FA8@f5.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] draft-ietf-sfc-nsh-04 NSH-MD-type 1 use-cases X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 14:48:13 -0000 This expired draft proposed using CH2 and CH3 for sub/endpoint ID. https://tools.ietf.org/html/draft-napper-sfc-nsh-mobility-allocation-02 I think it is worth reviving it. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Christian Koenning Sent: Friday, May 06, 2016 9:30 AM To: sfc@ietf.org Subject: [sfc] draft-ietf-sfc-nsh-04 NSH-MD-type 1 use-cases Dear WG: We are currently looking into SFC use-cases for mobile networks and are thi= nking of using the NSH Metadata to carry subscriber identity. The ip-address to subscriber mapping in todays network is usually propagate= d via external control-planes, e.g. RADIUS accounting.=20 Looking at the possibilities of NSH, the subscriber identity could easily = be carried as metadata per packet.=20 However, the 2 most common identifiers in mobile networks are - Mobile Station International Subscriber Directory Number (MSISDN)=20 E.164 defines this to a maximum of 15 digits =20 - International Mobile Subscriber Identity (IMSI), also defined as a 15 dig= it number Now looking at draft-ietf-sfc-nsh-04.txt p.12 3.4 NSH-MD-type 1 each Mandat= ory Context Header is defined as 4 Bytes. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|O|C|R|R|R|R|R|R| Length | MD-type=3D0x1 | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Path ID | Service Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 As you can see, a 15 digit number cannot be represented with 4 bytes.=20 Doing the math it shows that ceiling [ log2 ( ( 10^16 ) -1 ) ] =3D 54 bit= s would be needed for simple binary representation. Question: Are there any plans to address this in the MD type 1, for example= by defining concatenation of two Mandatory Context Headers, which then with 64 bits or = 8 byte would fit the subscriber identity ? Many Thanks Christian Koenning _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Fri May 6 07:56:49 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F9312B054 for ; Fri, 6 May 2016 07:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.017 X-Spam-Level: X-Spam-Status: No, score=-8.017 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=f5.com 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 rRYOO4FF-4MH for ; Fri, 6 May 2016 07:56:46 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D7D612B046 for ; Fri, 6 May 2016 07:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1462546606; x=1494082606; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=3R2vlZ9glhLfRfUdxitD7culALnmrDasX2LAW4SNb5E=; b=GTfz8/qn/bjx+g7+wP8tEhnxyk0VGFqkL4yjQet3xckAjmieezw9GhcO v48SWShoDHYHcoKQCAZx3feCLastCabbXhneeqDhgzTfq0PNoaucLnPLh s2v5zhiYIPCEG3N2Yd9ChEVUNi2cZUxc2AzaGtt2SMHsV8QRUSfX2E+E+ E=; X-IronPort-AV: E=Sophos;i="5.24,587,1454976000"; d="scan'208";a="217607341" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 06 May 2016 14:56:46 +0000 Received: from SEAEXCHMBX01.olympus.F5Net.com (192.168.15.223) by seaexchmbx02.olympus.F5Net.com (192.168.15.224) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Fri, 6 May 2016 07:56:45 -0700 Received: from SEAEXCHMBX01.olympus.F5Net.com ([fe80::143c:7597:6ad7:ce75]) by seaexchmbx01.olympus.F5Net.com ([fe80::143c:7597:6ad7:ce75%13]) with mapi id 15.00.1156.000; Fri, 6 May 2016 07:56:45 -0700 From: Christian Koenning To: Dave Dolson , "sfc@ietf.org" Thread-Topic: draft-ietf-sfc-nsh-04 NSH-MD-type 1 use-cases Thread-Index: AQHRp5ty47UgELVI6kCbX7BiL7kBmZ+r/LKwgACJN4A= Date: Fri, 6 May 2016 14:56:44 +0000 Message-ID: References: <09EB144B-2DC1-48FF-B438-4F26C4C70FA8@f5.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] draft-ietf-sfc-nsh-04 NSH-MD-type 1 use-cases X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 14:56:48 -0000 RXhjZWxsZW50LiBJIHNoYWxsIHJlYWNoIG91dCB0byB0aGUgYXV0aG9ycy4NCg0KDQoNCk1hbnkg VGhhbmtzDQpDaHJpc3RpYW4NCg0KDQpPbiAwNi8wNS8yMDE2LCAxNTo0OCwgIkRhdmUgRG9sc29u IiA8ZGRvbHNvbkBzYW5kdmluZS5jb20+IHdyb3RlOg0KDQo+VGhpcyBleHBpcmVkIGRyYWZ0IHBy b3Bvc2VkIHVzaW5nIENIMiBhbmQgQ0gzIGZvciBzdWIvZW5kcG9pbnQgSUQuDQo+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW5hcHBlci1zZmMtbnNoLW1vYmlsaXR5LWFsbG9jYXRp b24tMDINCj4NCj4NCj5JIHRoaW5rIGl0IGlzIHdvcnRoIHJldml2aW5nIGl0Lg0KPg0KPg0KPg0K Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJpc3RpYW4gS29lbm5pbmcNCj5TZW50OiBGcmlk YXksIE1heSAwNiwgMjAxNiA5OjMwIEFNDQo+VG86IHNmY0BpZXRmLm9yZw0KPlN1YmplY3Q6IFtz ZmNdIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNCBOU0gtTUQtdHlwZSAxIHVzZS1jYXNlcw0KPg0KPkRl YXIgV0c6DQo+DQo+V2UgYXJlIGN1cnJlbnRseSBsb29raW5nIGludG8gU0ZDIHVzZS1jYXNlcyBm b3IgbW9iaWxlIG5ldHdvcmtzIGFuZCBhcmUgdGhpbmtpbmcgb2YgdXNpbmcgdGhlIE5TSCBNZXRh ZGF0YSB0byBjYXJyeSBzdWJzY3JpYmVyIGlkZW50aXR5Lg0KPg0KPlRoZSBpcC1hZGRyZXNzIHRv IHN1YnNjcmliZXIgbWFwcGluZyBpbiB0b2RheXMgbmV0d29yayBpcyB1c3VhbGx5IHByb3BhZ2F0 ZWQgdmlhIGV4dGVybmFsIGNvbnRyb2wtcGxhbmVzLCBlLmcuIFJBRElVUyBhY2NvdW50aW5nLiAN Cj4NCj5Mb29raW5nIGF0IHRoZSBwb3NzaWJpbGl0aWVzICBvZiBOU0gsIHRoZSBzdWJzY3JpYmVy IGlkZW50aXR5IGNvdWxkIGVhc2lseSBiZSBjYXJyaWVkIGFzIG1ldGFkYXRhIHBlciBwYWNrZXQu IA0KPg0KPkhvd2V2ZXIsIHRoZSAyIG1vc3QgY29tbW9uIGlkZW50aWZpZXJzIGluIG1vYmlsZSBu ZXR3b3JrcyBhcmUNCj4NCj4tIE1vYmlsZSBTdGF0aW9uIEludGVybmF0aW9uYWwgU3Vic2NyaWJl ciBEaXJlY3RvcnkgTnVtYmVyIChNU0lTRE4pIA0KPiAgRS4xNjQgZGVmaW5lcyB0aGlzIHRvIGEg bWF4aW11bSBvZiAxNSBkaWdpdHMNCj4gIA0KPi0gSW50ZXJuYXRpb25hbCBNb2JpbGUgU3Vic2Ny aWJlciBJZGVudGl0eSAoSU1TSSksIGFsc28gZGVmaW5lZCBhcyBhIDE1IGRpZ2l0IG51bWJlcg0K Pg0KPk5vdyBsb29raW5nIGF0IGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQgcC4xMiAzLjQgTlNI LU1ELXR5cGUgMSBlYWNoIE1hbmRhdG9yeSBDb250ZXh0IEhlYWRlciBpcyBkZWZpbmVkIGFzIDQg Qnl0ZXMuDQo+DQo+ICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAgfFZlcnxPfEN8UnxS fFJ8UnxSfFJ8ICAgTGVuZ3RoICB8ICBNRC10eXBlPTB4MSAgfCBOZXh0IFByb3RvY29sIHwNCj4g ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCj4gICAgfCAgICAgICAgICBTZXJ2aWNlIFBhdGggSUQgICAgICAgICAgICAg ICAgICAgICAgfCBTZXJ2aWNlIEluZGV4IHwNCj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAgfCAgICAgICAg ICAgICAgICBNYW5kYXRvcnkgQ29udGV4dCBIZWFkZXIgICAgICAgICAgICAgICAgICAgICAgIHwN Cj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCj4gICAgfCAgICAgICAgICAgICAgICBNYW5kYXRvcnkgQ29udGV4dCBI ZWFkZXIgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAgfCAgICAg ICAgICAgICAgICBNYW5kYXRvcnkgQ29udGV4dCBIZWFkZXIgICAgICAgICAgICAgICAgICAgICAg IHwNCj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCj4gICAgfCAgICAgICAgICAgICAgICBNYW5kYXRvcnkgQ29udGV4 dCBIZWFkZXIgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAgDQo+ DQo+QXMgeW91IGNhbiBzZWUsIGEgMTUgZGlnaXQgbnVtYmVyIGNhbm5vdCBiZSByZXByZXNlbnRl ZCB3aXRoIDQgYnl0ZXMuIA0KPkRvaW5nIHRoZSBtYXRoIGl0IHNob3dzIHRoYXQgIGNlaWxpbmcg WyBsb2cyICggKCAxMF4xNiApIC0xICkgXSAgPSA1NCBiaXRzIHdvdWxkIGJlIG5lZWRlZA0KPmZv ciBzaW1wbGUgYmluYXJ5IHJlcHJlc2VudGF0aW9uLg0KPg0KPlF1ZXN0aW9uOiBBcmUgdGhlcmUg YW55IHBsYW5zIHRvIGFkZHJlc3MgdGhpcyBpbiB0aGUgTUQgdHlwZSAxLCBmb3IgZXhhbXBsZSBi eSBkZWZpbmluZw0KPmNvbmNhdGVuYXRpb24gb2YgdHdvIE1hbmRhdG9yeSBDb250ZXh0IEhlYWRl cnMsIHdoaWNoIHRoZW4gd2l0aCA2NCBiaXRzIG9yIDggYnl0ZSB3b3VsZCBmaXQgdGhlIHN1YnNj cmliZXIgaWRlbnRpdHkgPw0KPg0KPg0KPk1hbnkgVGhhbmtzDQo+DQo+Q2hyaXN0aWFuIEtvZW5u aW5nDQo+DQo+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj5zZmMgbWFpbGluZyBsaXN0DQo+c2ZjQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg== From nobody Fri May 6 08:19:41 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A0D12D8FF for ; Fri, 6 May 2016 08:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 FfRjB7xR-h6s for ; Fri, 6 May 2016 08:19:37 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E17F12D8FD for ; Fri, 6 May 2016 08:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11210; q=dns/txt; s=iport; t=1462547977; x=1463757577; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=szl/YyV9fX0cep9UtCDxfErYOjbBfwZXe0nMTMcjPaM=; b=hIgmk2W4Cy1vmjwTXPwU6J0vF3gP3fOx03AWqdUp90op8TJJBQJ69G0K jFjDFNjiuQiD8dw7SVND2wBY2lSfbxHOHPgzDLuJwXhPSMyxu2JO/M492 G0Y1p7B0lgdjLi6S6qBNaSxalaJ5tgfB3o0pyI03iJR4mH/kgWhroWXaM 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAgCCtSxX/5ldJa1VCYM4VX20B4R0A?= =?us-ascii?q?Q2BdhcBDIIWAYNVAoEzOBQBAQEBAQEBZSeEQQEBAQQBAQFkBwsMBAIBCA4DBAE?= =?us-ascii?q?BKAcnCxQJCAIEDgWIKw69SgEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhiCBdoJWh?= =?us-ascii?q?BiDUoIuBYd3hxeJEQGFfIgejxaPNQEeAQFCggIegUtuiC0BAQE?= X-IronPort-AV: E=Sophos;i="5.24,587,1454976000"; d="scan'208,217";a="270567829" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 May 2016 15:19:36 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u46FJaR1014607 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 May 2016 15:19:36 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 6 May 2016 10:19:36 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1104.009; Fri, 6 May 2016 10:19:35 -0500 From: "Jim Guichard (jguichar)" To: Dave Dolson Thread-Topic: [sfc] draft-ietf-sfc-nsh-04 NSH-MD-type 1 use-cases Thread-Index: AQHRp6qy9DhGPrR1akyo7hldWz99sA== Date: Fri, 6 May 2016 15:19:35 +0000 Message-ID: <4673AD5D-DFE9-478F-8A9D-6C1B8597892D@cisco.com> References: <09EB144B-2DC1-48FF-B438-4F26C4C70FA8@f5.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_4673AD5DDFE9478F8A9D6C1B8597892Dciscocom_" MIME-Version: 1.0 Archived-At: Cc: Christian Koenning , "sfc@ietf.org" Subject: Re: [sfc] draft-ietf-sfc-nsh-04 NSH-MD-type 1 use-cases X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 15:19:40 -0000 --_000_4673AD5DDFE9478F8A9D6C1B8597892Dciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Actually I think the draft you are looking for is: https://datatracker.ietf.org/doc/draft-napper-sfc-nsh-broadband-allocation<= https://datatracker.ietf.org/doc/draft-napper-sfc-nsh-broadband-allocation/= > Jim Sent from my iPhone On May 6, 2016, at 10:48 AM, Dave Dolson > wrote: This expired draft proposed using CH2 and CH3 for sub/endpoint ID. https://tools.ietf.org/html/draft-napper-sfc-nsh-mobility-allocation-02 I think it is worth reviving it. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Christian Koenning Sent: Friday, May 06, 2016 9:30 AM To: sfc@ietf.org Subject: [sfc] draft-ietf-sfc-nsh-04 NSH-MD-type 1 use-cases Dear WG: We are currently looking into SFC use-cases for mobile networks and are thi= nking of using the NSH Metadata to carry subscriber identity. The ip-address to subscriber mapping in todays network is usually propagate= d via external control-planes, e.g. RADIUS accounting. Looking at the possibilities of NSH, the subscriber identity could easily = be carried as metadata per packet. However, the 2 most common identifiers in mobile networks are - Mobile Station International Subscriber Directory Number (MSISDN) E.164 defines this to a maximum of 15 digits - International Mobile Subscriber Identity (IMSI), also defined as a 15 dig= it number Now looking at draft-ietf-sfc-nsh-04.txt p.12 3.4 NSH-MD-type 1 each Mandat= ory Context Header is defined as 4 Bytes. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|O|C|R|R|R|R|R|R| Length | MD-type=3D0x1 | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Path ID | Service Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ As you can see, a 15 digit number cannot be represented with 4 bytes. Doing the math it shows that ceiling [ log2 ( ( 10^16 ) -1 ) ] =3D 54 bit= s would be needed for simple binary representation. Question: Are there any plans to address this in the MD type 1, for example= by defining concatenation of two Mandatory Context Headers, which then with 64 bits or = 8 byte would fit the subscriber identity ? Many Thanks Christian Koenning _______________________________________________ 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_4673AD5DDFE9478F8A9D6C1B8597892Dciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Actually I think the draft you are looking for is:


Jim

Sent from my iPhone

On May 6, 2016, at 10:48 AM, Dave Dolson <ddolson@sandvine.com> wrote:

This expired draft proposed using CH2 and CH3 for sub/endpoint I= D.
https://tools.ietf.org/html/draft-napper-sfc-nsh-mobility-al= location-02


I think it is worth reviving it.



-----Original Message-----
From: sfc [mailto:sfc-bounces= @ietf.org] On Behalf Of Christian Koenning
Sent: Friday, May 06, 2016 9:30 AM
To: sfc@ietf.org
Subject: [sfc] draft-ietf-sfc-nsh-04 NSH-MD-type 1 use-cases
Dear WG:

We are currently looking into SFC use-cases for mobile networks and a= re thinking of using the NSH Metadata to carry subscriber identity.<= br>
The ip-address to subscriber mapping in todays network is usually pro= pagated via external control-planes, e.g. RADIUS accounting.

Looking at the possibilities  of NSH, the subscriber identity co= uld easily be carried as metadata per packet.

However, the 2 most common identifiers in mobile networks are<= br>
- Mobile Station International Subscriber Directory Number (MSISDN) <= /span>
 E.164 defines this to a maximum of 15 digits

- International Mobile Subscriber Identity (IMSI), also defined as a = 15 digit number

Now looking at draft-ietf-sfc-nsh-04.txt p.12 3.4 NSH-MD-type 1 each = Mandatory Context Header is defined as 4 Bytes.

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2= 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+
   |Ver|O|C|R|R|R|R|R|R|   Length  | &n= bsp;MD-type=3D0x1  | Next Protocol |
   +-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+
   |         &= nbsp;Service Path ID          =             | S= ervice Index |
   +-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+
   |         &= nbsp;      Mandatory Context Header  &nb= sp;            =         |
   +-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+
   |         &= nbsp;      Mandatory Context Header  &nb= sp;            =         |
   +-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+
   |         &= nbsp;      Mandatory Context Header  &nb= sp;            =         |
   +-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+
   |         &= nbsp;      Mandatory Context Header  &nb= sp;            =         |
   +-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+


As you can see, a 15 digit number cannot be represented with 4 bytes.=
Doing the math it shows that  ceiling [ log2 ( ( 10^16 ) -1 ) ] =  =3D 54 bits would be needed
for simple binary representation.

Question: Are there any plans to address this in the MD type 1, for e= xample by defining
concatenation of two Mandatory Context Headers, which then with 64 bi= ts or 8 byte would fit the subscriber identity ?


Many Thanks

Christian Koenning



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

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.iet= f.org/mailman/listinfo/sfc
--_000_4673AD5DDFE9478F8A9D6C1B8597892Dciscocom_-- From nobody Fri May 6 09:18:28 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E6512D097 for ; Fri, 6 May 2016 09:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 6laW2I5f_-k6 for ; Fri, 6 May 2016 09:18:23 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 D9ACE12B032 for ; Fri, 6 May 2016 09:18:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 8351224FD3E; Fri, 6 May 2016 09:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1462551503; bh=wvdoQtuWOJdmG8aN7yY2/WlfydfCb6wi2mfnmFwiS9s=; h=Subject:To:References:From:Date:In-Reply-To:From; b=H5Y7JzrMvuOGH3EC0Bp9XFPyOsmVg5Je/Tkkhtjxwq5JvoCGhHg7YMUTM/9+hm9N2 RkyIHU7GNQgNWXWjcE9o9u00B3oqwrFNqJK/KisF3RTf4SPHbHE2BZylXE6DWLuiL5 kPaszEwJW5q0lAxPB7+5WVl3wqRfyQgvb30gblhY= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 1EA31245C19; Fri, 6 May 2016 09:18:23 -0700 (PDT) To: Christian Koenning , "sfc@ietf.org" References: <09EB144B-2DC1-48FF-B438-4F26C4C70FA8@f5.com> From: "Joel M. Halpern" Message-ID: <24ad5610-9cf2-5f18-946d-5f17b58f3586@joelhalpern.com> Date: Fri, 6 May 2016 12:18:16 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <09EB144B-2DC1-48FF-B438-4F26C4C70FA8@f5.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] draft-ietf-sfc-nsh-04 NSH-MD-type 1 use-cases X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 16:18:25 -0000 There are privacy considerations that complicate this while pointing a way to addressing it. In order to reduce privacy risks, the SFC Architecture points out the fields revealing subscriber specific information should be represented indirectly. Thus, instead of putting the IMSI or MSISDN into the metadata, the recommended approach is to put a local-environment-assigned 32-bit subscriber ID in as one of the pieces of metadata. The service functions which need subscriber identity can then either be provisioned with the mapping information, or fetch the mapping when new packets arrive (SFC does not care which). For some logging purposes, the 32 bit id can even be logged without translation( with a time stamp, so the IDs can be reused). The drawback is that this does require coordination between the classifier and the service functions, usually by way of the control system. Yours, Joel On 5/6/16 9:30 AM, Christian Koenning wrote: > Dear WG: > > We are currently looking into SFC use-cases for mobile networks and are thinking of using the NSH Metadata to carry subscriber identity. > > The ip-address to subscriber mapping in todays network is usually propagated via external control-planes, e.g. RADIUS accounting. > > Looking at the possibilities of NSH, the subscriber identity could easily be carried as metadata per packet. > > However, the 2 most common identifiers in mobile networks are > > - Mobile Station International Subscriber Directory Number (MSISDN) > E.164 defines this to a maximum of 15 digits > > - International Mobile Subscriber Identity (IMSI), also defined as a 15 digit number > > Now looking at draft-ietf-sfc-nsh-04.txt p.12 3.4 NSH-MD-type 1 each Mandatory Context Header is defined as 4 Bytes. > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x1 | Next Protocol | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Service Path ID | Service Index | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Mandatory Context Header | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Mandatory Context Header | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Mandatory Context Header | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Mandatory Context Header | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > As you can see, a 15 digit number cannot be represented with 4 bytes. > Doing the math it shows that ceiling [ log2 ( ( 10^16 ) -1 ) ] = 54 bits would be needed > for simple binary representation. > > Question: Are there any plans to address this in the MD type 1, for example by defining > concatenation of two Mandatory Context Headers, which then with 64 bits or 8 byte would fit the subscriber identity ? > > > Many Thanks > > Christian Koenning > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon May 9 13:43:56 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361C712D5DA; Mon, 9 May 2016 13:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 KNXLUzPRzMbD; Mon, 9 May 2016 13:43: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 D480D12B00A; Mon, 9 May 2016 13:43:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJN89304; Mon, 09 May 2016 20:43:47 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 9 May 2016 21:43:46 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Mon, 9 May 2016 13:43:43 -0700 From: Linda Dunbar To: "mohamed.boucadair@orange.com" , "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] Call for WG adoption of draft-penno-sfc-appid-03 Thread-Index: AQHRZQHOvGZf31kz6UifjJTvmDJQAZ+hr9aAgARTiaCAAGltAP//xfBAgABId4CAALvlkIAKZcmQ Date: Mon, 9 May 2016 20:43:42 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657E82B12@dfweml501-mbb> References: <787AE7BB302AE849A7480A190F8B933008D62994@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <3501127B-E55B-4FA1-9A63-47D046371132@cisco.com> <787AE7BB302AE849A7480A190F8B933008D62C02@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <30650369-47D3-4387-B535-C2B7756B246A@cisco.com> <787AE7BB302AE849A7480A190F8B933008D6310A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D6310A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.128] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657E82B12dfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5730F684.002E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6755a14ce1a2df7dea48d95b5e07c18e Archived-At: Cc: "draft-penno-sfc-appid@ietf.org" , "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-appid-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 20:43:55 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657E82B12dfweml501mbb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWUgd2l0aCBNZWQuDQoNCkxpbmRhDQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KU2Vu dDogVHVlc2RheSwgTWF5IDAzLCAyMDE2IDE6MTggQU0NClRvOiBDYXJsb3MgUGlnbmF0YXJvIChj cGlnbmF0YSkNCkNjOiBkcmFmdC1wZW5uby1zZmMtYXBwaWRAaWV0Zi5vcmc7IEppbSBHdWljaGFy ZCAoamd1aWNoYXIpOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBDYWxsIGZvciBX RyBhZG9wdGlvbiBvZiBkcmFmdC1wZW5uby1zZmMtYXBwaWQtMDMNCg0KQ2FybG9zLA0KDQpJIGFs cmVhZHkgZXhwbGFpbmVkIHdoeSBJ4oCZbSBvYmplY3RpbmcgdG8gYWRvcHQgdGhpcyBkb2N1bWVu dCBhdCB0aGlzIHN0YWdlLiBJbiBhZGRpdGlvbiB0byB0aGF0LCBJIGhhdmUgc29tZSBjb25jZXJu cyB0aGF0IEnigJltIGxpc3RpbmcgYmVsb3c6DQoNCsK3ICAgICAgICBJIGRvbuKAmXQgdGhpbmsg aXQgaXMgYSBnb29kIGlkZWEgdG8gaGF2ZSBhIGxvdCBvZiBkb2N1bWVudHMgdG8gZGVmaW5lIHBp ZWNlcyBvZiBpbmZvcm1hdGlvbiB0aGF0IGNhbiBiZSBzdXBwbGllZCB1c2luZyBuc2guDQoNCsK3 ICAgICAgICBOb25lIG9mIHRoZSBXRyBhZG9wdGVkIHVzZSBjYXNlIGRvY3VtZW50cyBjYWxsIGZv ciB0aGUgYXBwaWQgYXMgYSBtYW5kYXRvcnktdG8tc3VwcG9ydCBpbmZvcm1hdGlvbi4NCg0Kwrcg ICAgICAgIFRoZSBhcHBpZCBkcmFmdCAodGFyZ2V0aW5nIOKAnFN0YW5kYXJkcyBUcmFja+KAnSBz dGF0dXMpIHJlbGllcyBvbiBhICoqIFZFTkRPUiAqKiBJUEZJWCBleHRlbnNpb24gKGFuIGluZm9y bWF0aW9uIFJGQykuIElzIHRoZXJlIGFueSByZWFzb24gd2h5IHRoYXQgaW5mb3JtYXRpb24gd2Fz IG5vdCBwYXJ0IG9mIHRoZSBub3JtYWwgSVBGSVggYXNzaWdubWVudCBwcm9jZXNzPw0KDQrCtyAg ICAgICAgVGhlcmUgaXMgYW4gSVBSIGZvciB0aGUgYXBwaWQgZHJhZnQuIEJlZm9yZSBlbmRvcnNp bmcgdGhlIGRyYWZ0LCBpdCB3b3VsZCBiZSBhcHByb3ByaWF0ZSBmb3IgdGhlIFdHIHRvIHVuZGVy c3RhbmQgZmlyc3QgdGhlIHByb2JsZW0gdG8gc29sdmUsIGFncmVlIGl0IGlzIHdvcnRoIHRvIGJl IHNvbHZlZCwgYW5kIHRoZW4gdGhlIFdHIGNhbiBzZWUgd2hldGhlciB0aGVyZSBhcmUgb3RoZXIg c29sdXRpb24gZGVzaWducyB3aXRob3V0IGhhdmluZyBhbm90aGVyIHlldCBTRkMgZG9jdW1lbnQg d2l0aCBhbiBJUFIgb24gaXQhDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6IENhcmxvcyBQaWduYXRh cm8gKGNwaWduYXRhKSBbbWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbV0NCkVudm95w6kgOiBsdW5k aSAyIG1haSAyMDE2IDE2OjQ0DQrDgCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE4NCkNjIDog SmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3Jn PjsgZHJhZnQtcGVubm8tc2ZjLWFwcGlkQGlldGYub3JnPG1haWx0bzpkcmFmdC1wZW5uby1zZmMt YXBwaWRAaWV0Zi5vcmc+DQpPYmpldCA6IFJlOiBbc2ZjXSBDYWxsIGZvciBXRyBhZG9wdGlvbiBv ZiBkcmFmdC1wZW5uby1zZmMtYXBwaWQtMDMNCg0KRGVhciBNZWQsDQoNClRyeWluZyB0byBleHRy YWN0IHRoZSBrZXkgc3RhdGVtZW50cyBmcm9tIHRoZSBsaW5lLWJ5LWxpbmUgcmVwbHksIHlvdSBz YWlkOg0KDQpHaXZlbiB0aGlzIGdvYWwgb2YgY29udmV5aW5nIGFwcGxpY2F0aW9uIGluZm9ybWF0 aW9uLCB3ZSBmb3VuZCBvbmUgc3BlY2lmaWMgc3ludGF4IGxldmVyYWdpbmcgdGhlIEFwcGxpY2F0 aW9uIEluZm9ybWF0aW9uIHN0cnVjdHVyZSBmcm9tIElQRklYLg0KW01lZF0gV2hpY2ggbWFrZXMg c2Vuc2UuIEkgZnVsbHkgYWdyZWUgd2l0aCB0aGF0Lg0KDQpBcG9sb2dpZXMgaW4gYWR2YW5jZSBm b3IgYXNraW5nIGFnYWluLCBidXQsIHdoYXQgZXhhY3RseSBpcyB5b3VyIGNvbmNlcm4gd2l0aCB0 aGlzIGRvY3VtZW50IChiZXlvbmQgeW91ciBwcm9wb3NhbCB0byB1c2UgSVBGSVggSUVzIGZvciBl dmVyeXRoaW5nKT8NCg0KDQpTb21lIGFkZGl0aW9uYWwgZm9sbG93LXVwcyBmb3IgY2xvc3VyZSBp bmxpbmUuDQoNCk9uIE1heSAyLCAyMDE2LCBhdCAxMDozMiBBTSwgbW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4gd3JvdGU6DQoN ClJlLSwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6IENhcmxv cyBQaWduYXRhcm8gKGNwaWduYXRhKSBbbWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbV0NCkVudm95 w6kgOiBsdW5kaSAyIG1haSAyMDE2IDE1OjUzDQrDgCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9P TE4NCkNjIDogSmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IHNmY0BpZXRmLm9yZzxtYWlsdG86c2Zj QGlldGYub3JnPjsgZHJhZnQtcGVubm8tc2ZjLWFwcGlkQGlldGYub3JnPG1haWx0bzpkcmFmdC1w ZW5uby1zZmMtYXBwaWRAaWV0Zi5vcmc+DQpPYmpldCA6IFJlOiBbc2ZjXSBDYWxsIGZvciBXRyBh ZG9wdGlvbiBvZiBkcmFmdC1wZW5uby1zZmMtYXBwaWQtMDMNCg0KRGVhciBNZWQsDQoNClRoYW5r cyBmb3IgdGFraW5nIHRoZSB0aW1lIHRvIHJldmlldyBhbmQgY29tbWVudC4gUGxlYXNlIGZpbmQg c29tZSBjb21tZW50cyBpbmxpbmUuDQoNCk9uIE1heSAyLCAyMDE2LCBhdCA3OjU4IEFNLCBtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPiB3cm90ZToNCg0KSGkgSmltLCBhbGwsDQoNCkkgaW50ZXJwcmV0IHRoaXMgcHJvcG9zYWwg YXMgaWYgaXQgd2FudHMgdG8gaW5oZXJpdCB0aGUgSVBGSVggQXBwbGljYXRpb24gaW5mb3JtYXRp b24gdG8gYmUgY29udmV5ZWQgaW4gYW4gbnNoIGhlYWRlci4gSSBoYXZlIHNvbWUgaXNzdWVzIHdp dGggdGhlIHJhdGlvbmFsZSBvZiB0aGlzIGRyYWZ0LCBub3QgaXRzIGdvYWwgcGVyIHNlLg0KDQpJ IGRvIG5vdCBzdXBwb3J0IHRoaXMgZHJhZnQuIEkgZG8gdGhpbmsgdGhlcmUgYXJlIG90aGVyIGRl c2lnbiBjaG9pY2VzIHRoYXQgY2FuIGJlIGludmVzdGlnYXRlZCBieSB0aGUgV0cgdG8gaW5oZXJp dCBleGlzdGluZyBJUEZJWCBJRXMgd2l0aG91dCB3cml0aW5nIGEgbmV3IFJGQyBmb3IgaXQgZm9y IEVBQ0ggSUUgdG8gYmUgY29udmV5ZWQgaW4gYW4gTlNIIGhlYWRlci4NCg0KSSBiZWxpZXZlIHlv dSBhcmUgbWlzdW5kZXJzdGFuZGluZyB3aGF0IGRyYWZ0LXBlbm5vLXNmYy1hcHBpZC0wMyBpcyBh Ym91dC4gVGhlIGdvYWwgaXMgdG8gY29udmV5IGFwcGxpY2F0aW9uIGluZm9ybWF0aW9uIGluIFNG QyBNZXRhZGF0YS4gSXQgaXMgbm90IHRvIGluaGVyaXQgZXhpc3RpbmcgSVBGSVggSUVzLg0KW01l ZF0gWW91IG1heSBiZSByaWdodCBidXQgdGhlIGRvY3VtZW50IGV4cGxpY2l0bHkgc2F5czoNCg0K ICAgVGhpcyBkb2N1bWVudCBwdXJwb3NlcyB0aGUgdXNlIG9mIElQRklYIFtSRkM3MDExPGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MDExPl0gYXBwbGljYXRpb24NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl4NCiAg IGluZm9ybWF0aW9uIHRvIGJlIGNhcnJpZWQgaW4gdGhlIE5TSCBjb250ZXh0IG1ldGFkYXRhIG9m IGEgTURUeXBlLTENCiAgIF5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl4NCiAgIHBhY2tldC4NCg0KDQoNCg0KQWJzdHJhY3QNCg0KICAgVGhpcyBkb2N1bWVudCBwcm9w b3NlcyB0byB1c2UgdGhlIHN0cnVjdHVyZWQgYXBwbGljYXRpb24gaW5mb3JtYXRpb24NCiAgIGlu IHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nIG1ldGFkYXRhLCBhbmQgc3BlY2lmaWVzIGEg WUFORyBtb2RlbA0KICAgZm9yIHRoZSBjb25maWd1cmF0aW9uIG9mIHRoZSBhcHBsaWNhdGlvbiBy ZWdpc3RyeS4NCg0KDQoNCkdpdmVuIHRoaXMgZ29hbCBvZiBjb252ZXlpbmcgYXBwbGljYXRpb24g aW5mb3JtYXRpb24sIHdlIGZvdW5kIG9uZSBzcGVjaWZpYyBzeW50YXggbGV2ZXJhZ2luZyB0aGUg QXBwbGljYXRpb24gSW5mb3JtYXRpb24gc3RydWN0dXJlIGZyb20gSVBGSVguDQpbTWVkXSBXaGlj aCBtYWtlcyBzZW5zZS4gSSBmdWxseSBhZ3JlZSB3aXRoIHRoYXQuDQoNCkkgd2FudGVkIHRvIGNs YXJpZnkgdGhlIGRpZmZlcmVuY2UsIGFzIGl0IGlzIHNpZ25pZmljYW5jZS4NCg0KSWYgdGhlcmUg YXJlIG90aGVyIGRlc2lnbiBjaG9pY2VzICp0byBjb252ZXkgYXBwbGljYXRpb24gaWRlbnRpZmlj YXRpb24qIChub3QgdG8gaW5oZXJpdCBleGlzdGluZyBmaWVsZHMgZnJvbSBhbnl3aGVyZSBhcyBh IGdvYWwpLCB3ZeKAmWQgbG92ZSB0byBoZWFyIHRoZW0uDQpbTWVkXSBXaG8gaXMgYXNraW5nIHRv IOKAnGluaGVyaXQgZXhpc3RpbmcgZmllbGRz4oCdPw0KDQpUaGlzIHNwZWNpZmljIHByb3Bvc2Fs IGNvbXBpbGVzIGFuZCBydW5zLg0KDQoNCg0KRm9yIGV4YW1wbGUsIHRoZXJlIGlzIGEgbW9yZSBn ZW5lcmFsIHByb3Bvc2FsIHRoYXQgYWltcyB0byBpbXBvcnQgQU5ZIElQRklYIEluZm9ybWF0aW9u IEVsZW1lbnQgKHRoYXQgd2lsbCBjb3ZlciB0aGUgcGFydGljdWxhciBjYXNlIGluIHRoaXMgZG9j dW1lbnQpOmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zZmMvY3VycmVudC9t c2cwNDQ5Mi5odG1sIHdpdGhvdXQgY29uc3VtaW5nIHRoZSBXRyBlZmZvcnQgdG8gZWRpdC9yZXZp ZXcvcHVibGlzaCBSRkNzIGZvciBlYWNoIHByb21pc2luZyBJUEZJWCBJRXMuDQoNCg0KSSBiZWxp ZXZlIHRoaXMgd2lsbCBjYXVzZSBtb3JlIGhlYWRhY2hlcyB0aGFuIHNvbHV0aW9ucyDigJQgSSBy ZXBsaWVkIGluIGEgc2VwYXJhdGUgbm90ZS4NCg0KDQpGdXJ0aGVyLCBJIGhhdmUgdGhlIGZvbGxv d2luZyBxdWVzdGlvbnMgZm9yIHRoZSBkcmFmdDoNCg0K4oCiICAgICAgICAgV2h5IHJlc2Vydmlu ZyB0aGlzIHByb3Bvc2FsIGZvciBNRCMxPw0KDQpCZWNhdXNlIHRoYXQgaXMgdGhlIG1pbmltYWwg b25lIHRvIHVzZS4NCltNZWRdIEkgZG9u4oCZdCBwYXJzZSB0aGlzLCBzb3JyeS4NCg0KSG93ZXZl ciwgdGhpcyBpcyBhbHNvIGRlZmluZWQgZm9yIE1ELVR5cGUgMiBhdCBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtcXVpbm4tc2ZjLW5zaC10bHYtMDEjcGFnZS03IChzZWUg4oCcNS4g ICBBcHBsaWNhdGlvbiBJROKAnSkNCltNZWRdIEkgZG9u4oCZdCB0aGluayBpdCBpcyBhIGdvb2Qg aWRlYSB0byBoYXZlIGEgbG90IG9mIGRvY3VtZW50cyB0byBkZWZpbmUgdGhlIHNhbWUgc2V0IG9m IGluZm9ybWF0aW9uLg0KDQoNCk5vdGVkLiBUaGFuayB5b3UuDQoNCg0KRG8geW91IHN1Z2dlc3Qg d2Ugc2hvdWxkIGRlZmluZSBNRC1UeXBlIDIgaW4gdGhpcyBkcmFmdCBhcyB3ZWxsPyBIYXBweSB0 byBkbyBzbyBpZiB0aGF04oCZcyB1c2VmdWwuDQpbTWVkXSBObywgSeKAmW0gbm90IHByb3Bvc2lu ZyB0aGF0LiBJ4oCZbSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB0aGUgdGVjaG5pY2FsIHJhdGlvbmFs ZSBmb3IgdGhhdCBjaG9pY2UuDQoNCg0KDQpUaGlzIGRvYyBkZWZpbmVzIE1ELVR5cGUgMSwgYW5k IHRoZSBUTFYgZG9jIGRlZmluZXMgTUQtVHlwZSAyIGZvciBhIGJ1bmNoIG9mIHRoaW5ncy4NCg0K SWYgeW91IGhhdmUgYW4gZWRpdG9yaWFsIG9yIGluZm9ybWF0aW9uIGFycmFuZ2VtZW50IHByb3Bv c2FsLCBwbGVhc2UgZG8gc2hhcmUuIEhhcHB5IHRvIGFjY29tbW9kYXRlIHRvIG1ha2UgdGhpbmdz IGVhc2llciB0byBwYXJzZS4NCg0KDQoNCuKAoiAgICAgICAgIFdoYXQgbWVhbnMgdGhlIGZvbGxv d2luZyBoZWFkZXJzPw0KICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAg ICAgIDIgICAgICAgICAgICAgICAgICAgMw0KICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQog ICAgIHwgICAgICAgMyAgICAgICB8ICAgICAgICAwICAgICAgfCAgICAgICAgICAgICAgMTYxICAg ICAgICAgICAgICB8DQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgIHwgICAgICAgICAgICAgICAgICBOZXR3 b3JrIFNoYXJlZCBDb250ZXh0ICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r DQogICAgIHwgICAgICAgICAgICAgICAgICBTZXJ2aWNlIFBsYXRmb3JtIENvbnRleHQgICAgICAg ICAgICAgICAgICAgICB8DQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgIHwgICAgICAgICAgICAgICAgICBT ZXJ2aWNlIFNoYXJlZCBDb250ZXh0ICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rDQoNCiAgICAgICBGaWd1cmUgMjogRXhhbXBsZSBvZiBNZXRhZGF0YSBJbmNsdWRpbmcgdGhl IFNOTVAgQXBwbGljYXRpb24NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElkZW50aWZp Y2F0aW9uDQoNCg0KDQpJdCBpcyBhbiBleGFtcGxlIG9mIG1ldGFkYXRhIGluY2x1ZGluZyB0aGUg U05NUCBhcHBsaWNhdGlvbiBpZGVudGlmaWNhdGlvbi4NCltNZWRdIE15IHF1ZXN0aW9uIHdhcyBt YXliZSBub3QgY2xlYXI6IHdoYXQgYSBOZXR3b3JrIFNoYXJlZCBDb250ZXh0PyBXaGF0IGlzIGEg U2VydmljZSBQbGF0Zm9ybSBDb250ZXh0PyBXaGF0IGlzIFNlcnZpY2UgU2hhcmVkIENvbnRleHQ/ DQoNCg0KQWgsIHRoYW5rcyBmb3IgdGhlIGNsYXJpZmljYXRpb24uIFRoZXNlIGFyZSByZW1haW5k ZXJzIGZyb20gZWFybGllciB2ZXJzaW9ucyBvZiBkcmFmdC1pZXRmLXNmYy1uc2gsIHdoaWNoIHdl IGhhdmUgdG8gZml4LiBUaGlzIGlzIGEgZ29vZCBhZG9wdGlvbiBjb21tZW50IGFuZCBhIGdvb2Qg Y2F0Y2guDQoNCkJlc3QsDQoNCuKAlCBDYXJsb3MuDQoNCkJlc3QsDQoNCuKAlCBDYXJsb3MuDQoN Cg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmdd IERlIGxhIHBhcnQgZGUgSmltIEd1aWNoYXJkIChqZ3VpY2hhcikNCkVudm95w6kgOiB2ZW5kcmVk aSAyOSBhdnJpbCAyMDE2IDE4OjMxDQrDgCA6IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYu b3JnPg0KT2JqZXQgOiBbc2ZjXSBDYWxsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1wZW5uby1z ZmMtYXBwaWQtMDMNCg0KRGVhciBXRzoNCg0KV2UgZGlkIG5vdCByZWNlaXZlIG1hbnkgcmVzcG9u c2VzIGZvciB0aGlzIGNhbGwgZm9yIGFkb3B0aW9uIGFuZCB0aGVyZWZvcmUgd291bGQgbGlrZSB0 byByZS1pbnZpdGUgcGVvcGxlIHRvIHBvc3QgdGhlaXIgdGhvdWdodHMgb24gYWRvcHRpbmcgdGhp cyBkb2N1bWVudCBpbnRvIHRoZSBTRkMgV0cuIFRoZSBjYWxsIGZvciBhZG9wdGlvbiB3aWxsIHJ1 biBmb3IgYSBmdXJ0aGVyIDIgd2Vla3MgZW5kaW5nIDYvMTMvMjAxNi4NCg0KVGhhbmtzIQ0KDQpT RkMgQ2hhaXJzDQoNCkZyb206IEppbSBHdWljaGFyZCA8amd1aWNoYXJAY2lzY28uY29tPG1haWx0 bzpqZ3VpY2hhckBjaXNjby5jb20+Pg0KRGF0ZTogVGh1cnNkYXksIEZlYnJ1YXJ5IDExLCAyMDE2 IGF0IDM6MjQgUE0NClRvOiAic2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IiA8c2Zj QGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogQ2FsbCBmb3IgV0cgYWRv cHRpb24gb2YgZHJhZnQtcGVubm8tc2ZjLWFwcGlkLTAzDQoNCkRlYXIgV0c6DQoNClRoaXMgZW1h aWwgc2VydmVzIGFzIGEgY2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtcGVubm8tc2ZjLWFw cGlkLTAzIGFzIGEgV0cgZG9jdW1lbnQuIFRoZSBjYWxsIGZvciBhZG9wdGlvbiB3aWxsIHJ1biBm b3IgMiB3ZWVrcyBlbmRpbmcgMi8yNS8yMDE2Lg0KDQpQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgaXMg YSBjYWxsIGZvciBhZG9wdGlvbiwgYW5kIG5vdCBhIGxhc3QgY2FsbCBmb3IgY29udGVudCBvZiB0 aGUgZG9jdW1lbnQuIEFkb3B0aW5nIGEgV0cgZG9jdW1lbnQgc2ltcGx5IG1lYW5zIHRoYXQgdGhl IFdHIHdpbGwgZm9jdXMgaXRzIGVmZm9ydHMgb24gdGhhdCBwYXJ0aWN1bGFyIGRyYWZ0IGdvaW5n IGZvcndhcmQsIGFuZCB1c2UgdGhhdCBkb2N1bWVudCBmb3IgcmVzb2x2aW5nIG9wZW4gaXNzdWVz IGFuZCBkb2N1bWVudGluZyB0aGUgV0figJlzIGRlY2lzaW9ucy4NCg0KUGxlYXNlIGluZGljYXRl IHdoZXRoZXIgeW91IHN1cHBvcnQgYWRvcHRpb24gZm9yIG5vdCwgYW5kIGlmIG5vdCB3aHkuIElz c3VlcyB5b3UgaGF2ZSB3aXRoIHRoZSBjdXJyZW50IGRvY3VtZW50IGl0c2VsZiBjYW4gYWxzbyBi ZSByYWlzZWQsIGJ1dCB0aGV5IHNob3VsZCBiZSByYWlzZWQgaW4gdGhlIGNvbnRleHQgb2Ygd2hh dCBzaG91bGQgYmUgY2hhbmdlZCBpbiB0aGUgZG9jdW1lbnQgZ29pbmcgZm9yd2FyZCwgcmF0aGVy IHRoYW4gYSBwcmUtY29uZGl0aW9uIGZvciBhZG9wdGlvbi4NCg0KRmluYWxseSwgbm93IGlzIGFs c28gYSBnb29kIHRpbWUgdG8gcG9sbCBmb3Iga25vd2xlZGdlIG9mIGFueSBJUFIgdGhhdCBhcHBs aWVzIHRvIHRoaXMgZHJhZnQsIGluIGxpbmUgd2l0aCB0aGUgSVBSIGRpc2Nsb3N1cmUgb2JsaWdh dGlvbnMgZm9yIFdHIHBhcnRpY2lwYW50cyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQg NTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4gSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBh dXRob3IgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCAodG8gdGhlIGNoYWlycykgd2hldGhl ciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLg0KDQpUaGFua3MhDQoN ClNGQyBDaGFpcnMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCg0K --_000_4A95BA014132FF49AE685FAB4B9F17F657E82B12dfweml501mbb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAz IDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0K CXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBh bm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7 DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3Jh cGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHls ZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1h cmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVk LXNwYWNlO30NCnAuVGV4dGVkZWJ1bGxlcywgbGkuVGV4dGVkZWJ1bGxlcywgZGl2LlRleHRlZGVi dWxsZXMNCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyI7DQoJbXNvLXN0eWxlLWxp bms6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsInNlcmlmIjt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRl eHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3Jt YWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZp bml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTUxMzgzNzM3MzsNCgltc28tbGlz dC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTI0OTc5NTU1NiAtNzYwMjg1 MjYyIDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3 IDY3ODk1Mjk5IDY3ODk1MzAxO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQt YXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sOw0KCW1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BZ3JlZSB3aXRoIE1lZC4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+TGluZGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0Bp ZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBNYXkgMDMsIDIwMTYgMToxOCBBTTxicj4NCjxi PlRvOjwvYj4gQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpPGJyPg0KPGI+Q2M6PC9iPiBkcmFm dC1wZW5uby1zZmMtYXBwaWRAaWV0Zi5vcmc7IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBzZmNA aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzZmNdIENhbGwgZm9yIFdHIGFkb3B0 aW9uIG9mIGRyYWZ0LXBlbm5vLXNmYy1hcHBpZC0wMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5DYXJsb3MsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj5JIGFscmVhZHkgZXhwbGFpbmVkIHdoeSBJ4oCZbSBvYmplY3Rp bmcgdG8gYWRvcHQgdGhpcyBkb2N1bWVudCBhdCB0aGlzIHN0YWdlLiBJbiBhZGRpdGlvbiB0byB0 aGF0LCBJIGhhdmUgc29tZSBjb25jZXJucyB0aGF0IEnigJltIGxpc3RpbmcgYmVsb3c6DQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRl eHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2Nv bG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPkkgZG9u4oCZdCB0aGluayBpdCBpcyBhIGdvb2QgaWRlYSB0 byBoYXZlIGEgbG90IG9mIGRvY3VtZW50cyB0byBkZWZpbmUgcGllY2VzIG9mIGluZm9ybWF0aW9u IHRoYXQgY2FuIGJlIHN1cHBsaWVkIHVzaW5nIG5zaC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21z by1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6YmxhY2siPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+Tm9uZSBvZiB0aGUgV0cgYWRvcHRlZCB1c2UgY2FzZSBkb2N1bWVudHMgY2FsbCBmb3IgdGhl IGFwcGlkIGFzIGEgbWFuZGF0b3J5LXRvLXN1cHBvcnQgaW5mb3JtYXRpb24uDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5k ZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOmJs YWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPlRoZSBhcHBpZCBkcmFmdCAodGFyZ2V0aW5nIOKAnFN0YW5kYXJkcyBU cmFja+KAnSBzdGF0dXMpIHJlbGllcyBvbiBhICoqIFZFTkRPUiAqKiBJUEZJWCBleHRlbnNpb24g KGFuIGluZm9ybWF0aW9uIFJGQykuIElzIHRoZXJlIGFueSByZWFzb24gd2h5IHRoYXQgaW5mb3Jt YXRpb24NCiB3YXMgbm90IHBhcnQgb2YgdGhlIG5vcm1hbCBJUEZJWCBhc3NpZ25tZW50IHByb2Nl c3M/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5 bWJvbDtjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFb ZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGVyZSBpcyBhbiBJUFIgZm9yIHRoZSBhcHBp ZCBkcmFmdC4gQmVmb3JlIGVuZG9yc2luZyB0aGUgZHJhZnQsIGl0IHdvdWxkIGJlIGFwcHJvcHJp YXRlIGZvciB0aGUgV0cgdG8gdW5kZXJzdGFuZCBmaXJzdCB0aGUgcHJvYmxlbSB0byBzb2x2ZSwg YWdyZWUgaXQgaXMgd29ydGgNCiB0byBiZSBzb2x2ZWQsIGFuZCB0aGVuIHRoZSBXRyBjYW4gc2Vl IHdoZXRoZXIgdGhlcmUgYXJlIG90aGVyIHNvbHV0aW9uIGRlc2lnbnMgd2l0aG91dCBoYXZpbmcg YW5vdGhlciB5ZXQgU0ZDIGRvY3VtZW50IHdpdGggYW4gSVBSIG9uIGl0ITxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSBbPGEgaHJlZj0ibWFpbHRvOmNwaWduYXRh QGNpc2NvLmNvbSI+bWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbTwvYT5dDQo8YnI+DQo8Yj5FbnZv ecOpJm5ic3A7OjwvYj4gbHVuZGkgMiBtYWkgMjAxNiAxNjo0NDxicj4NCjxiPsOAJm5ic3A7Ojwv Yj4gQk9VQ0FEQUlSIE1vaGFtPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+ZWQgSU1UL09MTjxicj4NCjxiPkNjJm5ic3A7OjwvYj4gSmltIEd1aWNoYXJkIChqZ3Vp Y2hhcik7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT47DQo8 YSBocmVmPSJtYWlsdG86ZHJhZnQtcGVubm8tc2ZjLWFwcGlkQGlldGYub3JnIj5kcmFmdC1wZW5u by1zZmMtYXBwaWRAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW3Nm Y10gQ2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtcGVubm8tc2ZjLWFwcGlkLTAzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+RGVhciBNZWQsPG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJGUiI+VHJ5aW5nIHRvIGV4dHJhY3QgdGhlIGtleSBzdGF0ZW1lbnRzIGZyb20gdGhl IGxpbmUtYnktbGluZSByZXBseSwgeW91IHNhaWQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+R2l2ZW4gdGhpcyBnb2FsIG9mIGNvbnZl eWluZyBhcHBsaWNhdGlvbiBpbmZvcm1hdGlvbiwgd2UgZm91bmQgb25lIHNwZWNpZmljIHN5bnRh eCBsZXZlcmFnaW5nIHRoZSBBcHBsaWNhdGlvbiBJbmZvcm1hdGlvbiBzdHJ1Y3R1cmUgZnJvbSBJ UEZJWC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+W01lZF0gV2hpY2ggbWFrZXMgc2Vuc2UuIEkgZnVsbHkgYWdyZWUg d2l0aCB0aGF0Ljwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+QXBvbG9n aWVzIGluIGFkdmFuY2UgZm9yIGFza2luZyBhZ2FpbiwgYnV0LCB3aGF0IGV4YWN0bHkgaXMgeW91 ciBjb25jZXJuIHdpdGggdGhpcyBkb2N1bWVudCAoYmV5b25kIHlvdXIgcHJvcG9zYWwgdG8gdXNl IElQRklYIElFcyBmb3IgZXZlcnl0aGluZyk/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+U29tZSBhZGRpdGlvbmFsIGZv bGxvdy11cHMgZm9yIGNsb3N1cmUgaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRlIiPk9uIE1heSAyLCAyMDE2LCBhdCAxMDozMiBBTSwgPGEgaHJlZj0ibWFp bHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPg0KbW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbTwvYT4gd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PlJlLSw8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlBsZWFzZSBzZWUg aW5saW5lLjwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Q2hlZXJzLDwv c3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5NZWQ8L3NwYW4+PHNw YW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUm bmJzcDs6PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3Bh biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5DYXJsb3MNCiBQaWduYXRhcm8gKGNw aWduYXRhKSBbPGEgaHJlZj0ibWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+bWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbTwvc3Bhbj48L2E+XTxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5FbnZv ecOpJm5ic3A7OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+bHVuZGkgMiBtYWkgMjAxNiAxNTo1Mzxicj4NCjxiPsOAJm5ic3A7OjwvYj48c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Qk9VQ0FEQUlSIE1vaGFt ZWQgSU1UL09MTjxicj4NCjxiPkNjJm5ic3A7OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+SmltIEd1aWNoYXJkIChqZ3VpY2hhcik7PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpz ZmNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnNmY0BpZXRmLm9yZzwvc3Bh bj48L2E+OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YSBocmVmPSJtYWlsdG86ZHJhZnQtcGVubm8tc2ZjLWFwcGlkQGlldGYub3JnIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5kcmFmdC1wZW5uby1zZmMtYXBwaWRAaWV0Zi5vcmc8L3NwYW4+PC9h Pjxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtzZmNdIENhbGwgZm9yIFdHIGFkb3B0aW9uIG9mIGRyYWZ0 LXBlbm5vLXNmYy1hcHBpZC0wMzwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+RGVhciBNZWQsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJGUiI+VGhhbmtzIGZvciB0YWtpbmcgdGhlIHRpbWUgdG8gcmV2aWV3IGFuZCBjb21tZW50LiBQ bGVhc2UgZmluZCBzb21lIGNvbW1lbnRzIGlubGluZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj5PbiBNYXkg MiwgMjAxNiwgYXQgNzo1OCBBTSw8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20i PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208 L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj53cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5IaSBKaW0sIGFsbCw8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij5JIGludGVycHJldCB0aGlzIHByb3Bvc2FsIGFzIGlmIGl0IHdhbnRz IHRvIGluaGVyaXQgdGhlIElQRklYIEFwcGxpY2F0aW9uIGluZm9ybWF0aW9uIHRvIGJlIGNvbnZl eWVkIGluIGFuIG5zaCBoZWFkZXIuIEkgaGF2ZSBzb21lIGlzc3VlcyB3aXRoIHRoZSByYXRpb25h bGUgb2YgdGhpcyBkcmFmdCwgbm90IGl0cw0KIGdvYWwgcGVyIHNlLjwvc3Bhbj48c3BhbiBsYW5n PSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkgZG8gbm90IHN1cHBvcnQgdGhpcyBk cmFmdC4gSSBkbyB0aGluayB0aGVyZSBhcmUgb3RoZXIgZGVzaWduIGNob2ljZXMgdGhhdCBjYW4g YmUgaW52ZXN0aWdhdGVkIGJ5IHRoZSBXRyB0byBpbmhlcml0IGV4aXN0aW5nIElQRklYIElFcyB3 aXRob3V0IHdyaXRpbmcgYSBuZXcgUkZDIGZvciBpdCBmb3IgRUFDSCBJRQ0KIHRvIGJlIGNvbnZl eWVkIGluIGFuIE5TSCBoZWFkZXIuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRlIiPkkgYmVsaWV2ZSB5b3UgYXJlIG1pc3VuZGVyc3RhbmRpbmcgd2hh dCBkcmFmdC1wZW5uby1zZmMtYXBwaWQtMDMgaXMgYWJvdXQuIFRoZSBnb2FsIGlzIHRvIGNvbnZl eSBhcHBsaWNhdGlvbiBpbmZvcm1hdGlvbiBpbiBTRkMgTWV0YWRhdGEuIEl0IGlzIG5vdCB0byBp bmhlcml0IGV4aXN0aW5nIElQRklYIElFcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+W01lZF0gWW91IG1heSBiZSBy aWdodCBidXQgdGhlIGRvY3VtZW50IGV4cGxpY2l0bHkgc2F5czo8L3NwYW4+PHNwYW4gbGFuZz0i RlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgVGhpcyBkb2N1bWVudCBwdXJwb3NlcyB0aGUgdXNlIG9mIElQRklYIFs8 L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNzAxMSIgdGl0bGU9IiZxdW90O1NwZWNpZmljYXRpb24gb2YgdGhlIElQIEZsb3cg SW5mb3JtYXRpb24gRXhwb3J0IChJUEZJWCkgUHJvdG9jb2wgZm9yIHRoZSBFeGNoYW5nZSBvZiBG bG93IEluZm9ybWF0aW9uJnF1b3Q7Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOnB1 cnBsZSI+UkZDNzAxMTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5dDQogYXBwbGljYXRpb248 L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl48L3Nw YW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgaW5mb3JtYXRpb24g dG8gYmUgY2FycmllZCBpbiB0aGUgTlNIIGNvbnRleHQgbWV0YWRhdGEgb2YgYSBNRFR5cGUtMTwv c3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBeXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5ePC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnBhY2tldC48L3NwYW4+ PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIi PkFic3RyYWN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj4mbmJz cDsgJm5ic3A7VGhpcyBkb2N1bWVudCBwcm9wb3NlcyB0byB1c2UgdGhlIHN0cnVjdHVyZWQgYXBw bGljYXRpb24gaW5mb3JtYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7ICZuYnNwO2luIHRo ZSBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nIG1ldGFkYXRhLCBhbmQgc3BlY2lmaWVzIGEgWUFO RyBtb2RlbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsgJm5ic3A7Zm9yIHRoZSBjb25maWd1cmF0 aW9uIG9mIHRoZSBhcHBsaWNhdGlvbiByZWdpc3RyeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+R2l2ZW4gdGhpcyBnb2FsIG9mIGNvbnZleWlu ZyBhcHBsaWNhdGlvbiBpbmZvcm1hdGlvbiwgd2UgZm91bmQgb25lIHNwZWNpZmljIHN5bnRheCBs ZXZlcmFnaW5nIHRoZSBBcHBsaWNhdGlvbiBJbmZvcm1hdGlvbiBzdHJ1Y3R1cmUgZnJvbSBJUEZJ WC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+W01lZF0gV2hpY2ggbWFrZXMgc2Vuc2UuIEkgZnVsbHkgYWdyZWUgd2l0 aCB0aGF0Ljwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHNw YW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd2FudGVkIHRvIGNsYXJpZnkgdGhlIGRp ZmZlcmVuY2UsIGFzIGl0IGlzIHNpZ25pZmljYW5jZS48c3BhbiBsYW5nPSJGUiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZXJl IGFyZSBvdGhlciBkZXNpZ24gY2hvaWNlcyAqdG8gYzxzcGFuIGxhbmc9IkZSIj5vbnZleSBhcHBs aWNhdGlvbiBpZGVudGlmaWNhdGlvbiogKG5vdCB0byBpbmhlcml0IGV4aXN0aW5nIGZpZWxkcyBm cm9tIGFueXdoZXJlIGFzIGEgZ29hbCksIHdl4oCZZCBsb3ZlIHRvIGhlYXIgdGhlbS4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+W01lZF0gV2hvIGlzIGFza2luZyB0byDigJxpbmhlcml0IGV4aXN0aW5nIGZp ZWxkc+KAnT88L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxz cGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+VGhpcyBzcGVj aWZpYyBwcm9wb3NhbCBjb21waWxlcyBhbmQgcnVucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRlIiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPkZvciBleGFtcGxlLCB0aGVyZSBpcyBhIG1vcmUgZ2VuZXJhbCBwcm9wb3Nh bCB0aGF0IGFpbXMgdG8gaW1wb3J0IEFOWSBJUEZJWCBJbmZvcm1hdGlvbiBFbGVtZW50ICh0aGF0 IHdpbGwgY292ZXIgdGhlIHBhcnRpY3VsYXIgY2FzZSBpbiB0aGlzIGRvY3VtZW50KTo8YSBocmVm PSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2ZjL2N1cnJlbnQvbXNnMDQ0 OTIuaHRtbCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cDovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL3NmYy9jdXJyZW50L21zZzA0NDkyLmh0bWw8L3NwYW4+PC9hPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj53aXRob3V0DQogY29u c3VtaW5nIHRoZSBXRyBlZmZvcnQgdG8gZWRpdC9yZXZpZXcvcHVibGlzaCBSRkNzIGZvciBlYWNo IHByb21pc2luZyBJUEZJWCBJRXMuPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJGUiI+SSBiZWxpZXZlIHRoaXMgd2lsbCBjYXVzZSBtb3JlIGhlYWRhY2hlcyB0aGFu IHNvbHV0aW9ucyDigJQgSSByZXBsaWVkIGluIGEgc2VwYXJhdGUgbm90ZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRlIiPjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkZ1cnRoZXIsIEkgaGF2ZSB0aGUgZm9sbG93aW5nIHF1 ZXN0aW9ucyBmb3IgdGhlIGRyYWZ0Ojwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+V2h5IHJlc2VydmluZw0KIHRoaXMgcHJv cG9zYWwgZm9yIE1EIzE/PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJGUiI+QmVjYXVzZSB0aGF0IGlzIHRoZSBtaW5pbWFsIG9uZSB0byB1c2UuPHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5bTWVkXSBJ IGRvbuKAmXQgcGFyc2UgdGhpcywgc29ycnkuPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3dldmVyLCB0aGlzIGlzIGFs c28gZGVmaW5lZCBmb3IgTUQtVHlwZSAyIGF0Jm5ic3A7PHNwYW4gbGFuZz0iRlIiPjxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1xdWlubi1zZmMtbnNoLXRsdi0wMSNw YWdlLTciPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcXVpbm4tc2ZjLW5zaC10bHYtMDEjcGFnZS03PC9zcGFu PjwvYT48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPihzZWUNCiDigJw1LiAmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPkFwcGxpY2F0aW9uIElE4oCdKTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij5bTWVkXSBJIGRvbuKAmXQgdGhpbmsgaXQgaXMgYSBnb29kIGlkZWEgdG8gaGF2ZSBhIGxv dCBvZiBkb2N1bWVudHMgdG8gZGVmaW5lIHRoZSBzYW1lIHNldCBvZiBpbmZvcm1hdGlvbi48L3Nw YW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxzcGFuIGxhbmc9IkZS Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj5Ob3RlZC4gVGhhbmsgeW91LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRlIiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkZSIj5EbyB5b3Ugc3VnZ2VzdCB3ZSBzaG91bGQgZGVmaW5lIE1ELVR5cGUgMiBpbiB0 aGlzIGRyYWZ0IGFzIHdlbGw/IEhhcHB5IHRvIGRvIHNvIGlmIHRoYXTigJlzIHVzZWZ1bC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+W01lZF0gTm8sIEnigJltIG5vdCBwcm9wb3NpbmcgdGhhdC4gSeKAmW0gdHJ5aW5n IHRvIHVuZGVyc3RhbmQgdGhlIHRlY2huaWNhbCByYXRpb25hbGUgZm9yIHRoYXQgY2hvaWNlLjwv c3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+VGhpcyBkb2Mg ZGVmaW5lcyBNRC1UeXBlIDEsIGFuZCB0aGUgVExWIGRvYyBkZWZpbmVzIE1ELVR5cGUgMiBmb3Ig YSBidW5jaCBvZiB0aGluZ3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkZSIj5JZiB5b3UgaGF2ZSBhbiBlZGl0b3JpYWwgb3IgaW5mb3JtYXRpb24gYXJyYW5nZW1lbnQg cHJvcG9zYWwsIHBsZWFzZSBkbyBzaGFyZS4gSGFwcHkgdG8gYWNjb21tb2RhdGUgdG8gbWFrZSB0 aGluZ3MgZWFzaWVyIHRvIHBhcnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPldoYXQNCiBtZWFucyB0aGUgZm9sbG93aW5nIGhlYWRlcnM/PC9zcGFuPjxzcGFu IGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDM8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQg NSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxNjEmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfDwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Ozwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO05ldHdvcmsgU2hhcmVkIENvbnRleHQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvc3Bh bj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzwvc3Bhbj48c3BhbiBsYW5n PSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlcnZpY2Ug UGxhdGZvcm0gQ29udGV4dCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgU2VydmljZSBTaGFyZWQgQ29udGV4dCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PC9zcGFu PjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZpZ3VyZSAyOiBFeGFtcGxlIG9mIE1ldGFkYXRhIElu Y2x1ZGluZyB0aGUgU05NUCBBcHBsaWNhdGlvbjwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJZGVudGlmaWNhdGlvbjwvc3Bhbj48c3BhbiBsYW5n PSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkZSIj5JdCBpcyBhbiBleGFtcGxlIG9mIG1ldGFkYXRhIGluY2x1ZGluZyB0aGUg U05NUCBhcHBsaWNhdGlvbiBpZGVudGlmaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+W01lZF0gTXkgcXVl c3Rpb24gd2FzIG1heWJlIG5vdCBjbGVhcjogd2hhdCBhPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk5ldHdvcmsgU2hhcmVkIENvbnRleHQ/IFdoYXQgaXMg YSBTZXJ2aWNlIFBsYXRmb3JtIENvbnRleHQ/IFdoYXQgaXMgU2VydmljZSBTaGFyZWQgQ29udGV4 dD88L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxzcGFuIGxh bmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj5BaCwgdGhhbmtzIGZvciB0aGUgY2xh cmlmaWNhdGlvbi4gVGhlc2UgYXJlIHJlbWFpbmRlcnMgZnJvbSBlYXJsaWVyIHZlcnNpb25zIG9m IGRyYWZ0LWlldGYtc2ZjLW5zaCwgd2hpY2ggd2UgaGF2ZSB0byBmaXguIFRoaXMgaXMgYSBnb29k IGFkb3B0aW9uIGNvbW1lbnQgYW5kIGEgZ29vZCBjYXRjaC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRlIiPkJlc3QsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkZSIj7igJQgQ2FybG9zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBs YW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRlIiPkJlc3QsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj7igJQgQ2FybG9zLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJGUiI+PGJy Pg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Q2hlZXJzLDwvc3Bhbj48c3BhbiBs YW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk1lZDwvc3Bhbj48c3BhbiBsYW5n PSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3Nw YW4+PC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+c2ZjDQogWzxh IGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPkRlIGxhIHBhcnQgZGU8L2I+ PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkppbSBHdWlj aGFyZCAoamd1aWNoYXIpPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPnZlbmRyZWRpIDI5IGF2cmlsIDIwMTYg MTg6MzE8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPnNmY0BpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGI+T2JqZXQm bmJzcDs6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5bc2ZjXSBDYWxsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1wZW5uby1zZmMtYXBwaWQtMDM8 L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlYXIgV0c6PC9zcGFuPjxzcGFuIGxhbmc9IkZS Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPldlIGRpZCBub3QgcmVjZWl2ZSBtYW55IHJlc3BvbnNlcyBmb3IgdGhpcyBjYWxsIGZvciBh ZG9wdGlvbiBhbmQgdGhlcmVmb3JlIHdvdWxkIGxpa2UgdG8gcmUtaW52aXRlIHBlb3BsZSB0byBw b3N0IHRoZWlyIHRob3VnaHRzIG9uIGFkb3B0aW5nIHRoaXMgZG9jdW1lbnQgaW50bw0KIHRoZSBT RkMgV0cuIFRoZSBjYWxsIGZvciBhZG9wdGlvbiB3aWxsIHJ1biBmb3IgYSBmdXJ0aGVyIDIgd2Vl a3MgZW5kaW5nIDYvMTMvMjAxNi4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhhbmtz ITwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJG UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TRkMgQ2hhaXJzPC9zcGFuPjxzcGFuIGxhbmc9IkZS Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0i RlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5KaW0gR3VpY2hhcmQgJmx0OzxhIGhyZWY9Im1haWx0bzpqZ3VpY2hh ckBjaXNjby5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmpndWljaGFyQGNpc2NvLmNv bTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkRhdGU6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5UaHVyc2RheSwgRmVicnVhcnkgMTEsIDIwMTYgYXQg MzoyNCBQTTxicj4NCjxiPlRvOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+c2ZjQGlldGYub3JnPC9zcGFuPjwvYT4mcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnNm Y0BpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5DYWxsIGZvciBXRyBhZG9wdGlv biBvZiBkcmFmdC1wZW5uby1zZmMtYXBwaWQtMDM8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+RGVhciBXRzo8L3NwYW4+PHNwYW4gbGFu Zz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xh cyI+VGhpcyBlbWFpbCBzZXJ2ZXMgYXMgYSBjYWxsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1w ZW5uby1zZmMtYXBwaWQtMDMgYXMgYSBXRyBkb2N1bWVudC4gVGhlIGNhbGwgZm9yIGFkb3B0aW9u IHdpbGwgcnVuIGZvciAyIHdlZWtzIGVuZGluZyAyLzI1LzIwMTYuPC9zcGFuPjxzcGFuIGxhbmc9 IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox My41cHQiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMi PlBsZWFzZSBub3RlIHRoYXQgdGhpcyBpcyBhIGNhbGwgZm9yIGFkb3B0aW9uLCBhbmQgbm90IGEg bGFzdCBjYWxsIGZvciBjb250ZW50IG9mIHRoZSBkb2N1bWVudC4gQWRvcHRpbmcgYSBXRyBkb2N1 bWVudCBzaW1wbHkgbWVhbnMgdGhhdCB0aGUgV0cgd2lsbCBmb2N1cyBpdHMgZWZmb3J0cyBvbiB0 aGF0IHBhcnRpY3VsYXINCiBkcmFmdCBnb2luZyBmb3J3YXJkLCBhbmQgdXNlIHRoYXQgZG9jdW1l bnQgZm9yIHJlc29sdmluZyBvcGVuIGlzc3VlcyBhbmQgZG9jdW1lbnRpbmcgdGhlIFdH4oCZcyBk ZWNpc2lvbnMuPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPlBsZWFzZSBpbmRpY2F0ZSB3aGV0aGVyIHlvdSBz dXBwb3J0IGFkb3B0aW9uIGZvciBub3QsIGFuZCBpZiBub3Qgd2h5LiBJc3N1ZXMgeW91IGhhdmUg d2l0aCB0aGUgY3VycmVudCBkb2N1bWVudCBpdHNlbGYgY2FuIGFsc28gYmUgcmFpc2VkLCBidXQg dGhleSBzaG91bGQgYmUgcmFpc2VkIGluIHRoZSBjb250ZXh0DQogb2Ygd2hhdCBzaG91bGQgYmUg Y2hhbmdlZCBpbiB0aGUgZG9jdW1lbnQgZ29pbmcgZm9yd2FyZCwgcmF0aGVyIHRoYW4gYSBwcmUt Y29uZGl0aW9uIGZvciBhZG9wdGlvbi4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdCI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJG UiIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+RmluYWxseSwg bm93IGlzIGFsc28gYSBnb29kIHRpbWUgdG8gcG9sbCBmb3Iga25vd2xlZGdlIG9mIGFueSBJUFIg dGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQsIGluIGxpbmUgd2l0aCB0aGUgSVBSIGRpc2Nsb3N1 cmUgb2JsaWdhdGlvbnMgZm9yIFdHIHBhcnRpY2lwYW50cyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwN CiAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLiBJZiB5b3UgYXJlIGxpc3RlZCBhcyBh IGRvY3VtZW50IGF1dGhvciBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsICh0byB0aGUgY2hh aXJzKSB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuPC9z cGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6Q29uc29sYXMiPlRoYW5rcyE8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+U0ZDIENoYWlyczwvc3Bh bj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNmYyBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5zZmNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvc3Bhbj48L2E+PC9zcGFu PjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_4A95BA014132FF49AE685FAB4B9F17F657E82B12dfweml501mbb_-- From nobody Tue May 10 08:35:01 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E905012D1C2 for ; Tue, 10 May 2016 08:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=unavailable autolearn_force=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 h59aYUPfKiyU for ; Tue, 10 May 2016 08:34:58 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E85F712D6D4 for ; Tue, 10 May 2016 08:26:55 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Tue, 10 May 2016 11:26:54 -0400 From: Dave Dolson To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-penno-sfc-packet-03.txt Thread-Index: AQHRoi6oDJmE1p92I0K/S46gKGKcvJ+yWd1g Date: Tue, 10 May 2016 15:26:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [sfc] FW: New Version Notification for draft-penno-sfc-packet-03.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 15:35:00 -0000 VGhpcyB3YXMgc3VibWl0dGVkIGEgY291cGxlIG9mIHdlZWtzIGFnby4NCg0KRmVhdHVyZXM6DQpT ZWN0aW9uIDUuMy4yIC0gYSBuZXcgb3B0aW1pemVkIG1ldGhvZCBvZiBlbmNvZGluZyByZXZlcnNl LXBhdGggaW5mb3JtYXRpb24gaW4gbWV0YWRhdGEgdGhhdCByZXF1aXJlcyBvbmx5IDMyIGJpdHMu DQoNCkknbSBpbnRlcmVzdGVkIHRvIGtub3cgd2hpY2ggYXBwcm9hY2hlcyBwZW9wbGUgZXhwZWN0 IHRvIHVzZS4gDQooV2UgZXhwZWN0IHRvIHByb3ZpZGUgYXQgbGVhc3QgdGhlIGFwcHJvYWNoIG9m IHNlY3Rpb24gNS40LjEgYXMgYSBtb2RlIG9mIG9wZXJhdGlvbi4pDQoNCg0KU2VjdGlvbiA3IC0g c29tZSBmbGVzaGluZyBvdXQgb2YgdGhlIHNlY3Rpb24gb24gaW5qZWN0aW5nIG1ldGFkYXRhLCBk ZWZpbmluZyBzZXZlcmFsIHR5cGVzIG9mIG1ldGFkYXRhOg0KICAgLSBTZXJ2aWNlLVBhdGgtSW52 YXJpYW50IE1ldGFkYXRhDQogICAtIFNlcnZpY2UtUGF0aC1EZWZhdWx0IE1ldGFkYXRhDQogICAt IEJpZGlyZWN0aW9uYWwgQ2xvbmFibGUgTWV0YWRhdGENCiAgIC0gVW5pZGlyZWN0aW9uYWwgQ2xv bmFibGUgTWV0YWRhdGENCiAgIC0gU2VydmljZS1GdW5jdGlvbi1NYXN0ZXJlZCBNZXRhZGF0YQ0K ICAgLSBNZXRhZGF0YSBmcm9tIFJlY2xhc3NpZmljYXRpb24NCg0KSSdkIGxpa2UgdG8ga25vdyBp ZiB0aGlzIHRheG9ub215IG9mIG1ldGFkYXRhIG1ha2VzIHNlbnNlIHRvIHBlb3BsZS4NCg0KDQot RGF2ZQ0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBG cmlkYXksIEFwcmlsIDI5LCAyMDE2IDExOjQ5IEFNDQpUbzogRXJpYyBXYW5nOyBSZWluYWxkbyBQ ZW5ubzsgQ2h1aS1UaW4gWWVuOyBEYXZlIERvbHNvbjsgQ2FybG9zIFBpZ25hdGFybzsgS2VudCBM ZXVuZw0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1wZW5uby1z ZmMtcGFja2V0LTAzLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1wZW5uby1z ZmMtcGFja2V0LTAzLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBSZWlu YWxkbyBQZW5ubyBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJ ZHJhZnQtcGVubm8tc2ZjLXBhY2tldA0KUmV2aXNpb246CTAzDQpUaXRsZToJCVBhY2tldCBHZW5l cmF0aW9uIGluIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5zDQpEb2N1bWVudCBkYXRlOgkyMDE2LTA0 LTI5DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkyNg0KVVJMOiAgICAg ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1wZW5uby1z ZmMtcGFja2V0LTAzLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LXBlbm5vLXNmYy1wYWNrZXQvDQpIdG1saXplZDogICAgICAgaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBlbm5vLXNmYy1wYWNrZXQtMDMNCkRpZmY6ICAg ICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtcGVubm8tc2Zj LXBhY2tldC0wMw0KDQpBYnN0cmFjdDoNCiAgIFNlcnZpY2UgRnVuY3Rpb25zIChlLmcuLCBGaXJl d2FsbCwgTkFULCBQcm94aWVzIGFuZCBJbnRydXNpb24NCiAgIFByZXZlbnRpb24gU3lzdGVtcykg Z2VuZXJhdGUgcGFja2V0cyBpbiB0aGUgcmV2ZXJzZSBmbG93IGRpcmVjdGlvbiB0bw0KICAgdGhl IHNvdXJjZSBvZiB0aGUgY3VycmVudCBpbi1wcm9jZXNzIHBhY2tldC9mbG93LiAgSW4gdGhpcyBk b2N1bWVudA0KICAgd2UgZGlzY3VzcyBhbmQgcHJvcG9zZSBob3cgdG8gc3VwcG9ydCB0aGlzIHJl cXVpcmVkIGZ1bmN0aW9uYWxpdHkNCiAgIHdpdGhpbiB0aGUgU0ZDIGZyYW1ld29yay4NCg0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Tue May 10 17:36:39 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654D412D0B6 for ; Tue, 10 May 2016 17:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 CjHeFijNAtgo for ; Tue, 10 May 2016 17:36:36 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.161]) (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 E4D9612D0E6 for ; Tue, 10 May 2016 17:36:35 -0700 (PDT) Received: from [195.245.230.51] by server-1.bemta-3.messagelabs.com id F0/13-07924-19E72375; Wed, 11 May 2016 00:36:33 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileJIrShJLcpLzFFi42I5/OJLu+7EOqN wg3dXlC22LnvIbvHkwVZ2ByaPJUt+Mnl83bydNYApijUzLym/IoE14+mEy2wF96Qqpr6PamB8 KdrFyMUhJLCXUeLvil42CGclo8SK96eYIJzlTBJL+j9BZY4wSjzf2scK4WxmlPh3tJmxi5GTg 03ARWLKhH1gtoiAq0Tn9QWsILawgLvE97PnmSDiHhJ/Xm1nhrCtJM4uPQcWZxFQldg55S5YL6 9AqMS++bfB4kIC/hJzl80Bm8MpECBx/e06MJtRQFZiw4bzYHOYBcQlNj37DhaXEBCQWLIHIi4 hICrx8vE/VogaPYkbU6ewQdjaEssWvmaG2CUocXLmE5YJjKKzkIyahaRlFpKWWUhaFjCyrGJU L04tKkst0rXUSyrKTM8oyU3MzNE1NDDWy00tLk5MT81JTCrWS87P3cQIjKN6BgbGHYyvfzodY pTkYFIS5d2SbxQuxJeUn1KZkVicEV9UmpNafIhRhoNDSYKXqRYoJ1iUmp5akZaZA4xomLQEB4 +SCK8FSJq3uCAxtzgzHSJ1ilFRSpz3Yw1QQgAkkVGaB9cGSyKXGGWlhHkZGRgYhHgKUotyM0t Q5V8xinMwKgnzuoOM58nMK4Gb/gpoMRPQYjk2fZDFJYkIKakGRvbdN4La8xTC5lxPETI6yxXi IivOw9rtOen1D38brh1nvJbnqyUd+y8luZhjm/eig/1TRfMY5SSe2bGELLmXpK3B6nNtanfjH Ovc8lSPW/6i2tfOT3wfz1i6Z5/oIu/zIdveJ9oK1j4Rvl17iKvfZJ5JYJDQaSbvtZ43WHQdv8 65eJD/8+FMJZbijERDLeai4kQAoD20vx0DAAA= X-Env-Sender: walter.haeffner@vodafone.com X-Msg-Ref: server-7.tower-33.messagelabs.com!1462926993!32164682!1 X-Originating-IP: [195.232.244.135] X-StarScan-Received: X-StarScan-Version: 8.34; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23971 invoked from network); 11 May 2016 00:36:33 -0000 Received: from mailout03.vodafone.com (HELO mailout03.vodafone.com) (195.232.244.135) by server-7.tower-33.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2016 00:36:33 -0000 Received: from mailint02.vodafone.com (mailint02.vodafone.com [195.232.244.199]) by mailout03.vodafone.com (Postfix) with ESMTP id 3r4HHP12RZz17HLs; Wed, 11 May 2016 02:36:32 +0200 (CEST) Received: from mailint02.vodafone.com (localhost [127.0.0.1]) by mailint02.vodafone.com (Postfix) with ESMTP id 3r4HHN5wHxzQngS; Wed, 11 May 2016 02:36:32 +0200 (CEST) Received: from VOEXC06W.internal.vodafone.com (voexc06w.dc-ratingen.de [145.230.101.26]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailint02.vodafone.com (Postfix) with ESMTPS id 3r4HHN5XnQzQn5S; Wed, 11 May 2016 02:36:32 +0200 (CEST) Received: from AVOEXH04W.internal.vodafone.com (145.230.15.136) by VOEXC06W.internal.vodafone.com (145.230.101.26) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 11 May 2016 02:36:32 +0200 Received: from VOEXM20W.internal.vodafone.com ([169.254.4.78]) by AVOEXH04W.internal.vodafone.com ([145.230.15.136]) with mapi id 14.03.0224.002; Wed, 11 May 2016 02:36:31 +0200 From: "Haeffner, Walter, Vodafone DE" To: Dave Dolson , "sfc@ietf.org" Thread-Topic: New Version Notification for draft-penno-sfc-packet-03.txt Thread-Index: AQHRoi6oDJmE1p92I0K/S46gKGKcvJ+yWd1ggACRU9A= Date: Wed, 11 May 2016 00:36:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] New Version Notification for draft-penno-sfc-packet-03.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 00:36:38 -0000 Section 7: >From a user point of view the md classification sounds very technical and m= ost definitions may not be obvious for people who simply deploy an sfc. Fo= r a specific service these folks expect to have a certain set of static me= tadata and a set of dynamic metadata. Static md may be related to a user, a= service profile etc. That is, md you know in advance. Dynamic md may be re= lated to user location, network conditions, user-selected value added servi= ce identifier etc. These are md which can even change on the fly. Because = of dynamic md a user-related service maps rather onto a sf-graph than a sf-= chain. I can e.g. think about dynamic md which enforce reclassification. Well, i= f I would use a md2-slot from nsh to signal reclassification, I could also = understand "md from reclassification ".=20 BR, Walter -----Urspr=FCngliche Nachricht----- Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson Gesendet: Dienstag, 10. Mai 2016 17:27 An: sfc@ietf.org Betreff: [sfc] FW: New Version Notification for draft-penno-sfc-packet-03.t= xt This was submitted a couple of weeks ago. Features: Section 5.3.2 - a new optimized method of encoding reverse-path information= in metadata that requires only 32 bits. I'm interested to know which approaches people expect to use.=20 (We expect to provide at least the approach of section 5.4.1 as a mode of o= peration.) Section 7 - some fleshing out of the section on injecting metadata, definin= g several types of metadata: - Service-Path-Invariant Metadata - Service-Path-Default Metadata - Bidirectional Clonable Metadata - Unidirectional Clonable Metadata - Service-Function-Mastered Metadata - Metadata from Reclassification I'd like to know if this taxonomy of metadata makes sense to people. -Dave -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Friday, April 29, 2016 11:49 AM To: Eric Wang; Reinaldo Penno; Chui-Tin Yen; Dave Dolson; Carlos Pignataro;= Kent Leung Subject: New Version Notification for draft-penno-sfc-packet-03.txt A new version of I-D, draft-penno-sfc-packet-03.txt has been successfully submitted by Reinaldo Penno and posted to the IETF repository. Name: draft-penno-sfc-packet Revision: 03 Title: Packet Generation in Service Function Chains Document date: 2016-04-29 Group: Individual Submission Pages: 26 URL: https://www.ietf.org/internet-drafts/draft-penno-sfc-packet= -03.txt Status: https://datatracker.ietf.org/doc/draft-penno-sfc-packet/ Htmlized: https://tools.ietf.org/html/draft-penno-sfc-packet-03 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-penno-sfc-packet-= 03 Abstract: Service Functions (e.g., Firewall, NAT, Proxies and Intrusion Prevention Systems) generate packets in the reverse flow direction to the source of the current in-process packet/flow. In this document we discuss and propose how to support this required functionality within the SFC framework. = =20 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 From nobody Wed May 11 23:44:59 2016 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E92C12D737; Wed, 11 May 2016 23:44:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160512064455.15167.2456.idtracker@ietfa.amsl.com> Date: Wed, 11 May 2016 23:44:55 -0700 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 06:44:55 -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 of the IETF. Title : Service Function Chaining (SFC) Control Plane Components & Requirements Author : Mohamed Boucadair Filename : draft-ietf-sfc-control-plane-05.txt Pages : 27 Date : 2016-05-11 Abstract: This document describes requirements for conveying information between Service Function Chaining (SFC) control elements and SFC data plane functional elements. Also, this document identifies a set of control interfaces to interact with SFC-aware elements to establish, maintain or recover service function chains. This document does not specify protocols nor extensions to existing protocols. This document exclusively focuses on SFC deployments that are under the responsibility of a single administrative entity. Inter-domain considerations are out of scope. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-control-plane-05 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 Wed May 11 23:48:00 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE4512D875 for ; Wed, 11 May 2016 23:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 fGJSmqO7Ke4D for ; Wed, 11 May 2016 23:47:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C428912D782 for ; Wed, 11 May 2016 23:47:55 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 0BBCF18C4CA for ; Thu, 12 May 2016 08:47:54 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.27]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id E3E1027C059 for ; Thu, 12 May 2016 08:47:53 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0294.000; Thu, 12 May 2016 08:47:53 +0200 From: To: "sfc@ietf.org" Thread-Topic: I-D Action: draft-ietf-sfc-control-plane-05.txt Thread-Index: AQHRrBnbQzMkk7mdhUSlgBRvYxskxJ+025cA Date: Thu, 12 May 2016 06:47:53 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D73BEA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <20160512064455.15167.2456.idtracker@ietfa.amsl.com> In-Reply-To: <20160512064455.15167.2456.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.5.12.54517 Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 06:47:58 -0000 Dear all,=20 This version addresses the comments received during the WGLC. You can check= the diff to track the changes.=20 Thank you. Cheers, Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > internet-drafts@ietf.org > Envoy=E9=A0: jeudi 12 mai 2016 08:45 > =C0=A0: i-d-announce@ietf.org > Cc=A0: sfc@ietf.org > Objet=A0: I-D Action: draft-ietf-sfc-control-plane-05.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Service Function Chaining of the IETF. >=20 > Title : Service Function Chaining (SFC) Control Plane > Components & Requirements > Author : Mohamed Boucadair > Filename : draft-ietf-sfc-control-plane-05.txt > Pages : 27 > Date : 2016-05-11 >=20 > Abstract: > This document describes requirements for conveying information > between Service Function Chaining (SFC) control elements and SFC data > plane functional elements. Also, this document identifies a set of > control interfaces to interact with SFC-aware elements to establish, > maintain or recover service function chains. This document does not > specify protocols nor extensions to existing protocols. >=20 > This document exclusively focuses on SFC deployments that are under > the responsibility of a single administrative entity. Inter-domain > considerations are out of scope. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-control-plane-05 >=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 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri May 13 02:39:35 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A712C12B032 for ; Fri, 13 May 2016 02:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 pplpS3dg0aue for ; Fri, 13 May 2016 02:39:32 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DED5912B044 for ; Fri, 13 May 2016 02:39:31 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id n129so15175517wmn.1 for ; Fri, 13 May 2016 02:39:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=0AGd5KGqzRNfdERUFKSJEpm0FHJAlR9KgdHkDrR2YEk=; b=OaqJiuiAJ+sx7sdk87FQqaG2WCJ0zA3tmLhMqt8JkSkfzH6RujSvtEjsspUHOge0be kyp+KR6uG5a89lV/jRwJ+dijbdPv2B0KhWCQUcXx2RvmKfBW/1YtVjzmkdevD7W44SjT 1Ej4mwDN1LsG+pgzbwla4HnP+feksD+s9NbhnvgHwHg7vyVFdnu7Cqh5/f/hx28qO5+l nhHlVEa04DogrP+Qi9Pr7Vv2sjjBx8JzIPcuxeQKYQqOf7PNojvI2UitQwIiWFJacPFZ V/pcm6GcQ+28oIqtXfz4mXXCbqK2oKsMkKFr4mH5TMMDDSLjvrSCJUJ8jjLW9FK+RhFu F94w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=0AGd5KGqzRNfdERUFKSJEpm0FHJAlR9KgdHkDrR2YEk=; b=RZCJR+FLFgnE++TV0vW+z4o5AbayTEy7lXznjLLfdn7XMSDUfuQNJhnZn9to6OiEtQ ZruHMjNqcMJ3D+YSAXVJNLVdNpGlTTjChA8xht9BoEmLjGzFU5155q2mPCAdz6K5E/Gb 3n8HDtqXnW8/RKzYO8b6QQ6eDIT6V6aPj7fqbZSq0oy0PV53Gp5qVqTseSj4+KUskb/X s5v7aLzU5+fGFyWpwLvdgqUoa6NrxqqGi9uOtGL8+9Clf0IC93lw7RnNTFb0SxP4CsPt 4cneF95HDjVdHdl72/EB2gOkcUKLGwBpnub1BQtL0c8fAsZGtJiVHE+lnf5M2zpEuws2 M7CQ== X-Gm-Message-State: AOPr4FU6vg0/6ogCPXcKl/z5H9rKoe+FPc3wlS+/exbDxqFaklO/9I/3Xr4CBFxJFU7efg== X-Received: by 10.28.212.8 with SMTP id l8mr2476887wmg.11.1463132370493; Fri, 13 May 2016 02:39:30 -0700 (PDT) Received: from ?IPv6:2003:74:cf72:2203:297e:cc95:a846:c019? (p200300061177DF03297ECC95A846C019.dip0.t-ipconnect.de. [2003:6:1177:df03:297e:cc95:a846:c019]) by smtp.googlemail.com with ESMTPSA id x124sm2327412wmg.24.2016.05.13.02.39.28 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 May 2016 02:39:29 -0700 (PDT) To: sfc@ietf.org References: <65e5a067-8d94-2632-506f-9f2d60dabeaf@gmail.com> From: Martin Stiemerling Message-ID: Date: Fri, 13 May 2016 11:39:31 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <65e5a067-8d94-2632-506f-9f2d60dabeaf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 09:39:33 -0000 Dear all, The WGLC for draft-ietf-sfc-control-plane-04.txt is concluded. Thanks to all reviewers! Martin Am 27.04.16 um 06:29 schrieb Martin Stiemerling: > Dear all, > > This is the start of the Working Group Last Call (WGLC) for > > draft-ietf-sfc-control-plane-04.txt > > The WGLC lasts for 2 weeks and will end May 11th at 10 pm PDT. > > Please send your comments and reviews to the sfc@ietf.org list. > > Regards, > > Martin (SFC co-chair) From nobody Fri May 13 06:33:44 2016 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD5B12B03B; Fri, 13 May 2016 06:33:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160513133342.10521.24355.idtracker@ietfa.amsl.com> Date: Fri, 13 May 2016 06:33:42 -0700 Archived-At: Cc: mls.ietf@gmail.com, sfc-chairs@ietf.org, sfc@ietf.org, akatlas@gmail.com Subject: [sfc] sfc - New Meeting Session Request for IETF 96 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 13:33:42 -0000 A new meeting session request has just been submitted by Martin Stiemerling, a Chair of the sfc working group. --------------------------------------------------------- Working Group Name: Service Function Chaining Area Name: Routing Area Session Requester: Martin Stiemerling Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 200 Conflicts to Avoid: First Priority: spring sdnrg rtgwg nvo3 mpls lisp idr i2rs bess tsvarea tsvwg rmcat Special Requests: Please add the quic bof (if approved to the 1st priority conflict list) --------------------------------------------------------- From nobody Sat May 14 02:29:38 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F8712D0C2 for ; Sat, 14 May 2016 02:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 fzc7LPJxlFyk for ; Sat, 14 May 2016 02:29:34 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E87412D0BF for ; Sat, 14 May 2016 02:29:34 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id n129so47802620wmn.1 for ; Sat, 14 May 2016 02:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=58H8C/RJUyvNci59FZMX01YQD4pJL91rzgrJpfiXMnk=; b=Lg1qjWlEjoeUl5lJ7DuHiVzZZI/JGG7GqhrYky574zm7JS6fEr9Uv2v509wyLmuIbj Ax9XltYG7wbFDh5e7iLTyETy+Ce2GdmmCdO89rJJEs1RxoMyf44eAPhIlcGpv9advjD6 kMBlzn7LMdolq78hiegmheXzPhYSdn0+UmNxEaNrgL5Xto1q696Zl7lNPFmdqdNfOGMN gWVHp9HKprNqEUfovhuTKi30jvfqzWvbPwPt/cBESIy4QC9OBROC6scuZ3jYccS2WDzV mS40qm6Rwxiy56VDa66Xz7ypwIud/yxlMkJ0AYfAMUGHC6tg+V7cZyBx7KGYMNZFJUI3 yPvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=58H8C/RJUyvNci59FZMX01YQD4pJL91rzgrJpfiXMnk=; b=MJsDtp3IgsNS4pVz+8VvQOJvCq/hOQw4q+xkDJJ1x5Dmm78NOPePuA0vIMmgMPdnQ5 KS7zv0rj/wN2UujZ9VQ/0qPtVzUzwafXYyEyved8tiIaXYKOXkDGs3+NAVMviivYPbOj jbrUUkHrDnKYLt8eFrOAaW/CHSKjGMjgTiAIrb4rRfAknENgmTsr/iZZHQvJ2Xu98kQw w7LiUC4Fx+0pdO8FflfyHrAZd/zBO6UBJ/IBnj6LyQ7RHaN7BVfA14RPrEX9DvbJr5mr NpKY+Dc3SqeyuN2mOolC8TJM0fbPmMYqVnyfpG8SBrAWC1uZToS2lMyEtBpyKxUQ+Y0i 41xA== X-Gm-Message-State: AOPr4FVe3OUU0cT3SfUKmFSN01ItYRT0Fgp0bHZ4FVvnJ8u7acOKqREDSowAXd6reEOCWw== X-Received: by 10.194.152.202 with SMTP id va10mr19627609wjb.76.1463218173164; Sat, 14 May 2016 02:29:33 -0700 (PDT) Received: from mn-mn0F.local (tmo-098-135.customers.d1-online.com. [80.187.98.135]) by smtp.googlemail.com with ESMTPSA id p129sm7375205wmd.13.2016.05.14.02.29.29 for (version=TLSv1/SSLv3 cipher=OTHER); Sat, 14 May 2016 02:29:32 -0700 (PDT) References: <20160512064455.15167.2456.idtracker@ietfa.amsl.com> To: sfc@ietf.org From: Martin Stiemerling Message-ID: <6a339336-a3df-6044-4c66-7a48b869670f@gmail.com> Date: Sat, 14 May 2016 11:28:48 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160512064455.15167.2456.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2016 09:29:36 -0000 Dear all, The authors have posted an updated version addressing the reviews out of the WGLC. Please check until May 20th 5pm CEST if your comments have been addressed. Thanks, Martin Am 12.05.16 um 08:44 schrieb internet-drafts@ietf.org: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Service Function Chaining of the IETF. > > Title : Service Function Chaining (SFC) Control Plane Components & Requirements > Author : Mohamed Boucadair > Filename : draft-ietf-sfc-control-plane-05.txt > Pages : 27 > Date : 2016-05-11 > > Abstract: > This document describes requirements for conveying information > between Service Function Chaining (SFC) control elements and SFC data > plane functional elements. Also, this document identifies a set of > control interfaces to interact with SFC-aware elements to establish, > maintain or recover service function chains. This document does not > specify protocols nor extensions to existing protocols. > > This document exclusively focuses on SFC deployments that are under > the responsibility of a single administrative entity. Inter-domain > considerations are out of scope. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-control-plane-05 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Sat May 14 10:47:50 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79D512D1AC for ; Sat, 14 May 2016 10:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.047 X-Spam-Level: X-Spam-Status: No, score=-14.047 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 45vn2Yk4tw5T for ; Sat, 14 May 2016 10:47:47 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83F6B12D09F for ; Sat, 14 May 2016 10:47:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3429; q=dns/txt; s=iport; t=1463248067; x=1464457667; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=trhaF4Ar8tHBh0q/a6B/QiI0QjSrCp1Ue+dh+mT1wK4=; b=IAkzJ4R6JjqIuYI2fzK5wCGmrlC8J+PwdYLwozry3oBj3XaDT7m1wvTs ig+W83GASNA8EBbQBXydHXeFg7ULXAgDVNqoidvuijgggo3og3/feoPoi sX81APLBP0Zv5u9TENQ/jJqCZnwo8H84hdA1QpSs5ooYsBOfN3H/R/UFH 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B9AgC3YzdX/49dJa1dgzdVfgateYtlA?= =?us-ascii?q?Q2BdhcLhW8CgSI4FAEBAQEBAQFlJ4RDAQEEAQEBNzQbAgEIDigQIQYLJQIEARI?= =?us-ascii?q?JiAwDFw6/Eg2EJwEBAQEBAQEBAQEBAQEBAQEBAQEehiWETYJDgi6FJwWTG4RbM?= =?us-ascii?q?QGFfYYngXmBaU6EAYQlgyGBG4dcFIdQAR4BAUKDbG4BhwZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,619,1454976000"; d="scan'208";a="104347996" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 May 2016 17:47:46 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u4EHlkOm030696 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 14 May 2016 17:47:46 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 14 May 2016 12:47:45 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1104.009; Sat, 14 May 2016 12:47:45 -0500 From: "Jim Guichard (jguichar)" To: Martin Stiemerling , "sfc@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt Thread-Index: AQHRrBnorsE3n3ea8ESTJLAGtYIQrp+4gacAgABIV4A= Date: Sat, 14 May 2016 17:47:45 +0000 Message-ID: References: <20160512064455.15167.2456.idtracker@ietfa.amsl.com> <6a339336-a3df-6044-4c66-7a48b869670f@gmail.com> In-Reply-To: <6a339336-a3df-6044-4c66-7a48b869670f@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.43.179] Content-Type: text/plain; charset="us-ascii" Content-ID: <8EA7341F783E3745A8DFCBEE740932DF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2016 17:47:49 -0000 I would like to see my comments addressed for section 4.10.4. Our charter calls for a single SFC encapsulation and that is being documented in draft-ietf-sfc-nsh. The text within this section suggests that forwarding can be enabled using an SFP-id and some other condition such as input port etc. This is inaccurate based upon the SFC encapsulation as well as our WG charter. There is no mention of the SFC encapsulation or the fact that the NSH base header is the method used for forwarding; note that the most common forwarding method (and the one implemented in several places) is SFP-id + index - this is not even mentioned!. In addition, this is a control plane document; there is no need to talk about forwarding other than point to the SFC encapsulation document. For these reasons I would like to see this section removed from the document. Jim On 5/14/16, 5:28 AM, "sfc on behalf of Martin Stiemerling" wrote: >Dear all, > >The authors have posted an updated version addressing the reviews out of >the WGLC. > >Please check until May 20th 5pm CEST if your comments have been addressed. > >Thanks, > > Martin > >Am 12.05.16 um 08:44 schrieb internet-drafts@ietf.org: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> This draft is a work item of the Service Function Chaining of the IETF. >> >> Title : Service Function Chaining (SFC) Control Plane >>Components & Requirements >> Author : Mohamed Boucadair >> Filename : draft-ietf-sfc-control-plane-05.txt >> Pages : 27 >> Date : 2016-05-11 >> >> Abstract: >> This document describes requirements for conveying information >> between Service Function Chaining (SFC) control elements and SFC data >> plane functional elements. Also, this document identifies a set of >> control interfaces to interact with SFC-aware elements to establish, >> maintain or recover service function chains. This document does not >> specify protocols nor extensions to existing protocols. >> >> This document exclusively focuses on SFC deployments that are under >> the responsibility of a single administrative entity. Inter-domain >> considerations are out of scope. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-control-plane-05 >> >> >> 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/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Mon May 16 22:42:36 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC5812D565 for ; Mon, 16 May 2016 22:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 cW-8WCcGGIZ6 for ; Mon, 16 May 2016 22:42:32 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E77912D52A for ; Mon, 16 May 2016 22:42:27 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 8FB8722CBC4; Tue, 17 May 2016 07:42:25 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.17]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 7072123805C; Tue, 17 May 2016 07:42:25 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%19]) with mapi id 14.03.0294.000; Tue, 17 May 2016 07:42:25 +0200 From: To: "Jim Guichard (jguichar)" , Martin Stiemerling , "sfc@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt Thread-Index: AQHRrcMmGfBNCeIeLEaKxI2MksHJmp+4lGOAgAQGazA= Date: Tue, 17 May 2016 05:42:24 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D7585A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <20160512064455.15167.2456.idtracker@ietfa.amsl.com> <6a339336-a3df-6044-4c66-7a48b869670f@gmail.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.25.91516 Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 05:42:35 -0000 Hi Jim, I believe all your comments for section 4.10.5 (-04) (section 4.10.4 in -05= ) have been addressed.=20 For the record, Andy shared a proposal here (http://www.ietf.org/mail-archi= ve/web/sfc/current/msg04616.html) while I send a text proposal here (http:/= /www.ietf.org/mail-archive/web/sfc/current/msg04651.html). These changes we= re implemented in -05 given that no objections were raised against them. Also, the old section 4.10.4 was removed as per one of your comments. Applying policies on the full aggregate (sfp-id) is the default mode. But f= or the particular case of this section (that is about "Fully Controlled SFF= /SF Sequence for a SFP"), there might be deployments where it is appropriat= e to allow for local enforcement of polices that are more fine-grained (TE,= for example). This section does not specify a new sfc encapsulation or ca= lls for recommendation how forwarding must be achieved. It does discuss som= e information that can be passed via the C2 interface if additional informa= tion is required to achieve some TE goals.=20 Cheers, Med > -----Message d'origine----- > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard > (jguichar) > Envoy=E9=A0: samedi 14 mai 2016 19:48 > =C0=A0: Martin Stiemerling; sfc@ietf.org > Objet=A0: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt >=20 > I would like to see my comments addressed for section 4.10.4. >=20 > Our charter calls for a single SFC encapsulation and that is being > documented in draft-ietf-sfc-nsh. The text within this section suggests > that forwarding can be enabled using an SFP-id and some other condition > such as input port etc. This is inaccurate based upon the SFC > encapsulation as well as our WG charter. There is no mention of the SFC > encapsulation or the fact that the NSH base header is the method used for > forwarding; note that the most common forwarding method (and the one > implemented in several places) is SFP-id + index - this is not even > mentioned!. In addition, this is a control plane document; there is no > need to talk about forwarding other than point to the SFC encapsulation > document. >=20 > For these reasons I would like to see this section removed from the > document. >=20 > Jim >=20 >=20 > On 5/14/16, 5:28 AM, "sfc on behalf of Martin Stiemerling" > wrote: >=20 > >Dear all, > > > >The authors have posted an updated version addressing the reviews out of > >the WGLC. > > > >Please check until May 20th 5pm CEST if your comments have been > addressed. > > > >Thanks, > > > > Martin > > > >Am 12.05.16 um 08:44 schrieb internet-drafts@ietf.org: > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >>directories. > >> This draft is a work item of the Service Function Chaining of the IETF= . > >> > >> Title : Service Function Chaining (SFC) Control Plan= e > >>Components & Requirements > >> Author : Mohamed Boucadair > >> Filename : draft-ietf-sfc-control-plane-05.txt > >> Pages : 27 > >> Date : 2016-05-11 > >> > >> Abstract: > >> This document describes requirements for conveying information > >> between Service Function Chaining (SFC) control elements and SFC > data > >> plane functional elements. Also, this document identifies a set of > >> control interfaces to interact with SFC-aware elements to establish= , > >> maintain or recover service function chains. This document does no= t > >> specify protocols nor extensions to existing protocols. > >> > >> This document exclusively focuses on SFC deployments that are under > >> the responsibility of a single administrative entity. Inter-domain > >> considerations are out of scope. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ > >> > >> There's also a htmlized version available at: > >> https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05 > >> > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-control-plane-05 > >> > >> > >> 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/ > >> > >> _______________________________________________ > >> I-D-Announce mailing list > >> I-D-Announce@ietf.org > >> https://www.ietf.org/mailman/listinfo/i-d-announce > >> Internet-Draft directories: http://www.ietf.org/shadow.html > >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > > > >_______________________________________________ > >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 May 17 08:45:07 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E6812D6E7 for ; Tue, 17 May 2016 08:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 j_DrYEzyHCU6 for ; Tue, 17 May 2016 08:45:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1312512D1AE for ; Tue, 17 May 2016 08:45:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id COW45996; Tue, 17 May 2016 15:45:00 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 17 May 2016 16:44:57 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Tue, 17 May 2016 08:44:52 -0700 From: Linda Dunbar To: "Jim Guichard (jguichar)" , Martin Stiemerling , "sfc@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt Thread-Index: AQHRrBn8beGDF0FHckW6ZK+h6OJtL5+4oy4AgACLZ4CABBbJAA== Date: Tue, 17 May 2016 15:44:51 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657E9BC5D@dfweml501-mbb> References: <20160512064455.15167.2456.idtracker@ietfa.amsl.com> <6a339336-a3df-6044-4c66-7a48b869670f@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.573B3C7D.00EE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6330e38328d98f5c5ece8bb648b0eb3b Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 15:45:06 -0000 Jim,=20 Why "calling for a single SFC encapsulation" conflicts with SFC control pla= ne sending request (via out of bound) to steer NSH encapsulated packets bas= ed on some criteria (e.g. port, or time stamp, or others)?=20 For example, when detecting a port status problem (from scheduling or monit= oring), can SFC control plane be allowed to ask the forwarding devices to = steer traffic to different port (based on its specific criteria)? Just curious,=20 Linda=20 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Saturday, May 14, 2016 12:48 PM To: Martin Stiemerling; sfc@ietf.org Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt I would like to see my comments addressed for section 4.10.4. Our charter calls for a single SFC encapsulation and that is being document= ed in draft-ietf-sfc-nsh. The text within this section suggests that forwar= ding can be enabled using an SFP-id and some other condition such as input = port etc. This is inaccurate based upon the SFC encapsulation as well as ou= r WG charter. There is no mention of the SFC encapsulation or the fact that= the NSH base header is the method used for forwarding; note that the most = common forwarding method (and the one implemented in several places) is SFP= -id + index - this is not even mentioned!. In addition, this is a control p= lane document; there is no need to talk about forwarding other than point t= o the SFC encapsulation document. For these reasons I would like to see this section removed from the documen= t. Jim On 5/14/16, 5:28 AM, "sfc on behalf of Martin Stiemerling" wrote: >Dear all, > >The authors have posted an updated version addressing the reviews out=20 >of the WGLC. > >Please check until May 20th 5pm CEST if your comments have been addressed. > >Thanks, > > Martin > >Am 12.05.16 um 08:44 schrieb internet-drafts@ietf.org: >> >> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>directories. >> This draft is a work item of the Service Function Chaining of the IETF. >> >> Title : Service Function Chaining (SFC) Control Plane >>Components & Requirements >> Author : Mohamed Boucadair >> Filename : draft-ietf-sfc-control-plane-05.txt >> Pages : 27 >> Date : 2016-05-11 >> >> Abstract: >> This document describes requirements for conveying information >> between Service Function Chaining (SFC) control elements and SFC data >> plane functional elements. Also, this document identifies a set of >> control interfaces to interact with SFC-aware elements to establish, >> maintain or recover service function chains. This document does not >> specify protocols nor extensions to existing protocols. >> >> This document exclusively focuses on SFC deployments that are under >> the responsibility of a single administrative entity. Inter-domain >> considerations are out of scope. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-control-plane-05 >> >> >> 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. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > >_______________________________________________ >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 Tue May 17 10:30:59 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B78B12DC30 for ; Tue, 17 May 2016 10:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 kNbUiJV3nq_k for ; Tue, 17 May 2016 10:30:56 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7261F12D777 for ; Tue, 17 May 2016 10:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6034; q=dns/txt; s=iport; t=1463506256; x=1464715856; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=OFcfuvDDAIbA4ChoKCe1JxcOdTbfJdFeQEX9SfydKvs=; b=cAMlZLXvvjyWVzCKtY9QOCluvNmceA7d+PAFL+aKs/s4iIU1g0vbBl5f g8HSbimDbb8GXg8ytR75NlQjiQk+8stoMUzK1tK7yFeR8V54OqwHYV37E anrmquQ5ZhWUbtEm2ugODRk1FhxEWJQAhidOvT7J1VM9jH3SVOH+By1EL c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQDrVDtX/4UNJK1cgzdVfgauC4tmA?= =?us-ascii?q?Q2BdRcLhW8CgTo4FAEBAQEBAQFlJ4RDAQEEAQEBaxsCAQgYJwchBgsUEQIEARI?= =?us-ascii?q?JiAwDFw6/Pw2EHwEBAQEBAQEBAQEBAQEBAQEBAQEehiWETYJDgV8BAU2FJwWOF?= =?us-ascii?q?4UEhF0xAYV+hieBeYFpToQBhCWDIYEbh10Uh1ABHgEBQoNtbgGGUDZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,324,1459814400"; d="scan'208";a="274679266" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 May 2016 17:30:55 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u4HHUtTa030821 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 May 2016 17:30:55 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 17 May 2016 12:30:54 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1104.009; Tue, 17 May 2016 12:30:54 -0500 From: "Jim Guichard (jguichar)" To: "mohamed.boucadair@orange.com" , "Martin Stiemerling" , "sfc@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt Thread-Index: AQHRrBnorsE3n3ea8ESTJLAGtYIQrp+4gacAgABIV4CABC9mAIAAguMA Date: Tue, 17 May 2016 17:30:54 +0000 Message-ID: References: <20160512064455.15167.2456.idtracker@ietfa.amsl.com> <6a339336-a3df-6044-4c66-7a48b869670f@gmail.com> <787AE7BB302AE849A7480A190F8B933008D7585A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D7585A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.124.28] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <88F0A890AEB28D449962E93DA4897489@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 17:30:58 -0000 Hi Med, My concern (as chair) is with Figure 2 (and all of the text surrounding it) which suggests that the forwarding is based on incoming SFP-id *and* ingress port (or any of the other criteria listed). This is misleading based upon RFC7665 which says the SFF forwards packets based upon the information conveyed within the SFC encapsulation (see https://tools.ietf.org/html/rfc7665#section-4.3) and the SFC encapsulation document (see=20 https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-7). I suggest that the text is silent on whether the ingress interface has context to the SFF - its an implementation/deployment decision. Jim On 5/17/16, 1:42 AM, "mohamed.boucadair@orange.com" wrote: >Hi Jim, > >I believe all your comments for section 4.10.5 (-04) (section 4.10.4 in >-05) have been addressed. > >For the record, Andy shared a proposal here >(http://www.ietf.org/mail-archive/web/sfc/current/msg04616.html) while I >send a text proposal here >(http://www.ietf.org/mail-archive/web/sfc/current/msg04651.html). These >changes were implemented in -05 given that no objections were raised >against them. > >Also, the old section 4.10.4 was removed as per one of your comments. > >Applying policies on the full aggregate (sfp-id) is the default mode. But >for the particular case of this section (that is about "Fully Controlled >SFF/SF Sequence for a SFP"), there might be deployments where it is >appropriate to allow for local enforcement of polices that are more >fine-grained (TE, for example). This section does not specify a new sfc >encapsulation or calls for recommendation how forwarding must be >achieved. It does discuss some information that can be passed via the C2 >interface if additional information is required to achieve some TE goals. > >Cheers, >Med > >> -----Message d'origine----- >> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard >> (jguichar) >> Envoy=E9 : samedi 14 mai 2016 19:48 >> =C0 : Martin Stiemerling; sfc@ietf.org >> Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt >>=20 >> I would like to see my comments addressed for section 4.10.4. >>=20 >> Our charter calls for a single SFC encapsulation and that is being >> documented in draft-ietf-sfc-nsh. The text within this section suggests >> that forwarding can be enabled using an SFP-id and some other condition >> such as input port etc. This is inaccurate based upon the SFC >> encapsulation as well as our WG charter. There is no mention of the SFC >> encapsulation or the fact that the NSH base header is the method used >>for >> forwarding; note that the most common forwarding method (and the one >> implemented in several places) is SFP-id + index - this is not even >> mentioned!. In addition, this is a control plane document; there is no >> need to talk about forwarding other than point to the SFC encapsulation >> document. >>=20 >> For these reasons I would like to see this section removed from the >> document. >>=20 >> Jim >>=20 >>=20 >> On 5/14/16, 5:28 AM, "sfc on behalf of Martin Stiemerling" >> wrote: >>=20 >> >Dear all, >> > >> >The authors have posted an updated version addressing the reviews out >>of >> >the WGLC. >> > >> >Please check until May 20th 5pm CEST if your comments have been >> addressed. >> > >> >Thanks, >> > >> > Martin >> > >> >Am 12.05.16 um 08:44 schrieb internet-drafts@ietf.org: >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> >>directories. >> >> This draft is a work item of the Service Function Chaining of the >>IETF. >> >> >> >> Title : Service Function Chaining (SFC) Control >>Plane >> >>Components & Requirements >> >> Author : Mohamed Boucadair >> >> Filename : draft-ietf-sfc-control-plane-05.txt >> >> Pages : 27 >> >> Date : 2016-05-11 >> >> >> >> Abstract: >> >> This document describes requirements for conveying information >> >> between Service Function Chaining (SFC) control elements and SFC >> data >> >> plane functional elements. Also, this document identifies a set >>of >> >> control interfaces to interact with SFC-aware elements to >>establish, >> >> maintain or recover service function chains. This document does >>not >> >> specify protocols nor extensions to existing protocols. >> >> >> >> This document exclusively focuses on SFC deployments that are >>under >> >> the responsibility of a single administrative entity. >>Inter-domain >> >> considerations are out of scope. >> >> >> >> >> >> The IETF datatracker status page for this draft is: >> >> https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ >> >> >> >> There's also a htmlized version available at: >> >> https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05 >> >> >> >> A diff from the previous version is available at: >> >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-control-plane-05 >> >> >> >> >> >> 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/ >> >> >> >> _______________________________________________ >> >> I-D-Announce mailing list >> >> I-D-Announce@ietf.org >> >> https://www.ietf.org/mailman/listinfo/i-d-announce >> >> Internet-Draft directories: http://www.ietf.org/shadow.html >> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> > >> >_______________________________________________ >> >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 May 17 10:32:50 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA1D12DC38 for ; Tue, 17 May 2016 10:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 ARkd7dTqSjCy for ; Tue, 17 May 2016 10:32:47 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90BEF12DC16 for ; Tue, 17 May 2016 10:32:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4713; q=dns/txt; s=iport; t=1463506367; x=1464715967; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=oGYgbcmb8iOouT63y2Ol1oGY+nwpARnyL9XPNh9/b24=; b=OxTp9jaXTT6cujGmCZw52JOyydgqZwoMzgw1WMJ+SZw4ARsGfkELnKe3 HqkEnO8YpozCC7h7/W7TSBhLEG5SqOZTCAfXY/zgySGXBd0cBvq1C5PDQ gWBx1OJ2AzmlkstrE4QnzZJudPMLe8Op8tqo/Bruf/+rdToCHejguZKxO c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQAoVTtX/4ENJK1cgzdVfgauC4tmA?= =?us-ascii?q?Q2BdRcLhW8CgTo4FAEBAQEBAQFlJ4RCAQEBBAEBARodNBcEAgEIEQQBAQEeCQc?= =?us-ascii?q?hBgsUCQgCBAESCYgMAxcOv0ANhB8BAQEBAQEBAQEBAQEBAQEBAQEBAQEchiWET?= =?us-ascii?q?YJDgi6FJwWTG4RdMQGFfoYngXmBaU6EAYQlgyGBG4ddFIdQAR4BAUKDbW4BhwZ?= =?us-ascii?q?/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,324,1459814400"; d="scan'208";a="108131803" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 May 2016 17:32:46 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u4HHWkVH022030 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 May 2016 17:32:46 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 17 May 2016 12:32:46 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1104.009; Tue, 17 May 2016 12:32:45 -0500 From: "Jim Guichard (jguichar)" To: Linda Dunbar , Martin Stiemerling , "sfc@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt Thread-Index: AQHRrBnorsE3n3ea8ESTJLAGtYIQrp+4gacAgABIV4CABNe4gP//2xaA Date: Tue, 17 May 2016 17:32:45 +0000 Message-ID: References: <20160512064455.15167.2456.idtracker@ietfa.amsl.com> <6a339336-a3df-6044-4c66-7a48b869670f@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F657E9BC5D@dfweml501-mbb> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657E9BC5D@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.124.28] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 17:32:49 -0000 Hi Linda, See my response to Med. If you want to use other criteria above and beyond the documented SFC encapsulation then that is an implementation choice not a requirement within the control plane specification. Jim On 5/17/16, 11:44 AM, "Linda Dunbar" wrote: >Jim,=20 > >Why "calling for a single SFC encapsulation" conflicts with SFC control >plane sending request (via out of bound) to steer NSH encapsulated >packets based on some criteria (e.g. port, or time stamp, or others)? > >For example, when detecting a port status problem (from scheduling or >monitoring), can SFC control plane be allowed to ask the forwarding >devices to steer traffic to different port (based on its specific >criteria)? > >Just curious,=20 > >Linda=20 > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard >(jguichar) >Sent: Saturday, May 14, 2016 12:48 PM >To: Martin Stiemerling; sfc@ietf.org >Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt > >I would like to see my comments addressed for section 4.10.4. > >Our charter calls for a single SFC encapsulation and that is being >documented in draft-ietf-sfc-nsh. The text within this section suggests >that forwarding can be enabled using an SFP-id and some other condition >such as input port etc. This is inaccurate based upon the SFC >encapsulation as well as our WG charter. There is no mention of the SFC >encapsulation or the fact that the NSH base header is the method used for >forwarding; note that the most common forwarding method (and the one >implemented in several places) is SFP-id + index - this is not even >mentioned!. In addition, this is a control plane document; there is no >need to talk about forwarding other than point to the SFC encapsulation >document. > >For these reasons I would like to see this section removed from the >document. > >Jim > > >On 5/14/16, 5:28 AM, "sfc on behalf of Martin Stiemerling" > wrote: > >>Dear all, >> >>The authors have posted an updated version addressing the reviews out >>of the WGLC. >> >>Please check until May 20th 5pm CEST if your comments have been >>addressed. >> >>Thanks, >> >> Martin >> >>Am 12.05.16 um 08:44 schrieb internet-drafts@ietf.org: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>>directories. >>> This draft is a work item of the Service Function Chaining of the IETF. >>> >>> Title : Service Function Chaining (SFC) Control Plane >>>Components & Requirements >>> Author : Mohamed Boucadair >>> Filename : draft-ietf-sfc-control-plane-05.txt >>> Pages : 27 >>> Date : 2016-05-11 >>> >>> Abstract: >>> This document describes requirements for conveying information >>> between Service Function Chaining (SFC) control elements and SFC >>>data >>> plane functional elements. Also, this document identifies a set of >>> control interfaces to interact with SFC-aware elements to establish, >>> maintain or recover service function chains. This document does not >>> specify protocols nor extensions to existing protocols. >>> >>> This document exclusively focuses on SFC deployments that are under >>> the responsibility of a single administrative entity. Inter-domain >>> considerations are out of scope. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ >>> >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-control-plane-05 >>> >>> >>> 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/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >> >>_______________________________________________ >>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 Tue May 17 12:35:27 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB48C12D946 for ; Tue, 17 May 2016 12:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.447 X-Spam-Level: X-Spam-Status: No, score=-8.447 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=f5.com 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 zfBmziVFMDXW for ; Tue, 17 May 2016 12:35:24 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E08DD12D919 for ; Tue, 17 May 2016 12:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1463513724; x=1495049724; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=N+CqyyBHvpgoQBjDNZjTtVHPhBchtmEpxYhXgFlJH1I=; b=fyCB2ihOzrUiHoOA4ie/uvlGwwh3Qa6tI3bNTLUhC1DlmWzPWvra0kpj fd9mWH3cRAmB6kUb+mRlAzgRXBmn3yGDm4f1gpQ4xTmzzU9EZAam1zCq8 juV0FL4fnsabPDRDnUa+fLwCULmmVgnvWX33V+TgcG61rlb5B9BaVYtbK k=; X-IronPort-AV: E=Sophos;i="5.26,324,1459814400"; d="scan'208";a="218601113" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP; 17 May 2016 19:35:21 +0000 Received: from SEAEXCHMBX04.olympus.F5Net.com (192.168.15.226) by seaexchmbx03.olympus.F5Net.com (192.168.15.225) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 17 May 2016 12:35:21 -0700 Received: from SEAEXCHMBX04.olympus.F5Net.com ([fe80::856e:99ba:ff8b:b756]) by SEAEXCHMBX04.olympus.F5Net.com ([fe80::856e:99ba:ff8b:b756%21]) with mapi id 15.00.1178.000; Tue, 17 May 2016 12:35:21 -0700 From: Christian Koenning To: "sfc@ietf.org" Thread-Topic: draft-ietf-sfc-nsh-04 with L2 encapsulation Thread-Index: AQHRsHM/L+LySgCie0G1aqv45aN+zA== Date: Tue, 17 May 2016 19:35:20 +0000 Message-ID: <8FB80637-C981-499B-A9C2-FCE119761B55@f5.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [sfc] draft-ietf-sfc-nsh-04 with L2 encapsulation X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 19:35:26 -0000 R29vZCBhZnRlcm5vb24sDQoNCndlIGhhdmUgYmVlbiBkaXNjdXNzaW5nIGludGVybmFsbHkgdGhl IHNlbWFudGljcyBvZiANCk5TSCBMMiBlbmNhcHN1bGF0aW9uIGFzIHBlcjoNCg0KaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2ZjLW5zaC0wNA0KDQoNCg0KOS4xLiAgR1JF ICsgTlNIDQoNCiAgICBMMiBGcmFtZToNCiAgICArLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICB8TDIgaGVhZGVyIHwgTDMgaGVhZGVyLCBw cm90bz00N3xHUkUgaGVhZGVyLFBUPTB4ODk0RnwNCiAgICArLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAtLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tKw0KICAgIE5TSCwgTlA9MHgzICAgIHxvcmlnaW5hbCBmcmFtZSB8DQogICAg LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCiAgICANCjkuMi4gIFZYTEFOLWdwZSAr IE5TSA0KDQogICAgTDIgRnJhbWU6DQogICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICB8TDIgaGVhZGVyIHwgSVAgKyBVRFAg ZHN0IHBvcnQ9NDc5MCB8VlhMQU4tZ3BlIE5QPTB4NChOU0gpfA0KICAgICstLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCiAgICBOU0gsTlA9MHgzICAgICB8b3JpZ2luYWwg ZnJhbWUgfA0KICAgIC0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQoNCg0KOS4zLiAg RXRoZXJuZXQgKyBOU0gNCiAgTDIgRnJhbWU6DQogICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tKw0KICB8T3V0ZXIgRXRoZXJu ZXQsIEVUPTB4ODk0RiAgICAgIHwgTlNILCBOUCA9IDB4MyB8IG9yaWdpbmFsIGZyYW1lIHwNCiAg Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0rDQogIA0KQWxzbywgbGV0IHVzIHJlY2FwIHRoYXQgdGhlIGZvcndhcmRpbmcgYmVo YXZpb3VyIGlzIGRlcml2ZWQgZnJvbSB0aGUNClNQSS9TSSBtYXBwaW5nIGRlZmluZWQgYnkgdGhl IGNvbnRyb2xwbGFuZS4NCg0Kc2VlIHAuMjAgDQoNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfCAgU1BJIHwgIFNJIHwgIE5I ICAgICAgICAgICAgICAgICB8ICAgVHJhbnNwb3J0ICAgICAgICB8DQogICArLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgIDEwICB8 IDI1NSB8ICAxLjEuMS4xICAgICAgICAgICAgfCAgIFZYTEFOLWdwZSAgICAgICAgfA0KICAgfCAg MTAgIHwgMjU0IHwgIDIuMi4yLjIgICAgICAgICAgICB8ICAgbnZHUkUgICAgICAgICAgICB8DQog ICB8ICAxMCAgfCAyNTEgfCAgMTAuMS4yLjMgICAgICAgICAgIHwgICBHUkUgICAgICAgICAgICAg IHwNCiAgIHwgIDQwICB8IDI1MSB8ICAxMC4xLjIuMyAgICAgICAgICAgfCAgIEdSRSAgICAgICAg ICAgICAgfA0KICAgfCAgNTAgIHwgMjAwIHwgIDAxOjIzOjQ1OjY3Ojg5OmFiICB8ICAgRXRoZXJu ZXQgICAgICAgICB8DQogICB8ICAxNSAgfCAyMTIgfCAgTnVsbCAoZW5kIG9mIHBhdGgpIHwgICBO b25lICAgICAgICAgICAgIHwNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDk6IFNG RiBOU0ggTWFwcGluZyBFeGFtcGxlDQogICAgICAgICAgICAgICAgICAgICANCk5vdyBsb29raW5n IGF0IGEgc3BlY2lmaWMgZXhhbXBsZSBmb3IgZm9yd2FyZGluZyB0byBhIFZYTEFOLUdQRQ0KZW5k cG9pbnQsIGlzIHRoZSBuZXh0LWhvcCBkZWZpbmVkIGFzIHRoZSBvdXRlciBsYXllciBkZXN0aW5h dGlvbiwgb3IgaXMNCnRoaXMgdGhlIGlubmVyIGxheWVyIGRlc3RpbmF0aW9uLCBhbmQgc29tZSBm b3JtIG9mIEFSUCBvciBwcmVkZWZpbmVkDQpyZXNvbHV0aW9uIGlzIGFzc3VtZWQgPw0KDQpPciBl dmVuIHRvIGFzayBtb3JlIHNwZWNpZmljYWxseSwgd2hlbiBmb3J3YXJkaW5nIGZyb20gYSBTRkYg dG8gYSBTRg0KdXNpbmcgVlhMQU4tR1BFIE5TSCB3aXRoIEwyIGVuY2Fwc3VsYXRpb24sIGlzIGl0 IGV4cGVjdGVkIHRoYXQgdGhlIGlubmVyDQpMMiBkZXN0aW5hdGlvbiBhZGRyZXNzIGlzIGJlaW5n IGNoYW5nZWQgdG8gdGhlIHJlc29sdmVkIEwyIGFkZHJlc3Mgb2YNCnRoZSBTRiA/DQoNClRoZSBt aXNzaW5nIGNsYXJpdHkgaXMgZGVyaXZlZCBmcm9tIHRoZSBkZWZpbml0aW9uIGFib3ZlLCAib3Jp Z2luYWwNCmZyYW1lLiIgVGhpcyBjYW4gZWl0aGVyIG1lYW4gZW5jYXBzdWxhdGlvbiBoYXBwZW5z IGF0IENsYXNzaWZpZXIgTGV2ZWwsDQphbmQgdGhlbiB0aGUgTDIgSGVhZGVyIHdpbGwgc3RheSB1 bnRvdWNoZWQuIEJ1dCB3aGF0IGlzIHRoZW4gdGhlIHB1cnBvc2UNCm9mIGl0ID8gT3IgZG9lcyB0 aGlzIG1lYW4gdGhlIGlubmVyIEwyIEFkZHJlc3NlcyBuZWVkIHRvIHRvIHJlbmRlcmVkIGhvcA0K YnkgaG9wIGFzIGluIHRyYWRpdGlvbmFsIG5ldHdvcmtzLiBUaGlzIHdvdWxkIG1lYW4gd2UgaGF2 ZSBhIHBvc3NpYmxlDQp1bndhbnRlZCBkZXBlbmRlbmN5Lg0KDQoNCg0KVGhlIHF1ZXN0aW9uIGNh biBiZSB0YWtlbiBvdXQgb2YgdGhlIHRyYW5zcG9ydCBzY29wZSwgYW5kIHNpbXBsZSBiZQ0KZGVm aW5lZCBhcyDigJxEb2VzIE5TSCBMMiBlbmNhcHN1bGF0aW9uIGNhcmUgYWJvdXQgdGhlIGlubmVy IEwyIGhlYWRlcnMgP+KAnQ0KDQpQbGVhc2UgYWxsb3cgdXMgdG8gY2xhcmlmeSB0aGlzLg0KDQpN YW55IFRoYW5rcw0KDQpDaHJpc3RpYW4gS29lbm5pbmcNCi0tDQpGNSBOZXR3b3JrcyBJbmMuDQpj aHJpc3RpYW5AZjUuY29tDQoNCg0K From nobody Tue May 17 12:48:03 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA2212DD5D for ; Tue, 17 May 2016 12:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 kDcFu9STpTJg for ; Tue, 17 May 2016 12:47:58 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 0365012D919 for ; Tue, 17 May 2016 12:47:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 9EE1F2661F0; Tue, 17 May 2016 12:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1463514477; bh=DhQHxvfmeAavzqs51HTtnpHiF2m53gR0OBh0zKt52hA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=erhNgPaW4JkZ0rDxIScimLdPilZ3UEQLBI4BBhFLUcCQ72Uf7PbofG6xke0u4LThK dmyp4y41un7TL+q1iNrTq/1n09k1RvNd6Y9YWYeElpRE0RsTl+4g+UVpOfKGeMy9Oq dPySuaKCUZ7L9AmMS0PwuB0Gv/NgF4N7yZVlbm/I= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 326CE24091B; Tue, 17 May 2016 12:47:57 -0700 (PDT) To: Christian Koenning , "sfc@ietf.org" References: <8FB80637-C981-499B-A9C2-FCE119761B55@f5.com> From: "Joel M. Halpern" Message-ID: <46f91899-618a-7443-1e12-d8bb153cf36e@joelhalpern.com> Date: Tue, 17 May 2016 15:48:06 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <8FB80637-C981-499B-A9C2-FCE119761B55@f5.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] draft-ietf-sfc-nsh-04 with L2 encapsulation X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 19:48:03 -0000 I am having trouble parsing your question. I may be misreading inner and outer. The "inner" packet is whatever NSH is carrying. That is whatever was sent into the system. Individual SF may play with that, but NSH forwarding ignores that. Now, the outer packet depends upon the tunnel type. If the tunnel is a pure Ethernet tunnel, then the NSH table tells you the L2 Address to use for the outer packet. If the tunnel is an L3 encapsulated tunnel (VxLAN, GRE, ...) then the NSH information gives you the L3 next hop. It is the responsibility of the outer IP system, not the NSH system, to resolve that IP address to an actual Interface and if needed (usually) an L2 MAC address. NSH and SFC don't care how the system does that. Most commmonly, it is ARP / IPv6 ND. But it can be static configuration or some other form of magic. Yours, Joel On 5/17/16 3:35 PM, Christian Koenning wrote: > Good afternoon, > > we have been discussing internally the semantics of > NSH L2 encapsulation as per: > > https://tools.ietf.org/html/draft-ietf-sfc-nsh-04 > > > > 9.1. GRE + NSH > > L2 Frame: > +----------+--------------------+--------------------+ > |L2 header | L3 header, proto=47|GRE header,PT=0x894F| > +----------+--------------------+--------------------+ > ---------------+---------------+ > NSH, NP=0x3 |original frame | > ---------------+---------------+ > > 9.2. VXLAN-gpe + NSH > > L2 Frame: > +----------+------------------------+---------------------+ > |L2 header | IP + UDP dst port=4790 |VXLAN-gpe NP=0x4(NSH)| > +----------+------------------------+---------------------+ > ---------------+---------------+ > NSH,NP=0x3 |original frame | > ---------------+---------------+ > > > 9.3. Ethernet + NSH > L2 Frame: > +-------------------------------+---------------+----------------+ > |Outer Ethernet, ET=0x894F | NSH, NP = 0x3 | original frame | > +-------------------------------+---------------+----------------+ > > Also, let us recap that the forwarding behaviour is derived from the > SPI/SI mapping defined by the controlplane. > > see p.20 > > +-------------------------------------------------------+ > | SPI | SI | NH | Transport | > +-------------------------------------------------------+ > | 10 | 255 | 1.1.1.1 | VXLAN-gpe | > | 10 | 254 | 2.2.2.2 | nvGRE | > | 10 | 251 | 10.1.2.3 | GRE | > | 40 | 251 | 10.1.2.3 | GRE | > | 50 | 200 | 01:23:45:67:89:ab | Ethernet | > | 15 | 212 | Null (end of path) | None | > +-------------------------------------------------------+ > Figure 9: SFF NSH Mapping Example > > Now looking at a specific example for forwarding to a VXLAN-GPE > endpoint, is the next-hop defined as the outer layer destination, or is > this the inner layer destination, and some form of ARP or predefined > resolution is assumed ? > > Or even to ask more specifically, when forwarding from a SFF to a SF > using VXLAN-GPE NSH with L2 encapsulation, is it expected that the inner > L2 destination address is being changed to the resolved L2 address of > the SF ? > > The missing clarity is derived from the definition above, "original > frame." This can either mean encapsulation happens at Classifier Level, > and then the L2 Header will stay untouched. But what is then the purpose > of it ? Or does this mean the inner L2 Addresses need to to rendered hop > by hop as in traditional networks. This would mean we have a possible > unwanted dependency. > > > > The question can be taken out of the transport scope, and simple be > defined as “Does NSH L2 encapsulation care about the inner L2 headers ?†> > Please allow us to clarify this. > > Many Thanks > > Christian Koenning > -- > F5 Networks Inc. > christian@f5.com > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Tue May 17 12:49:13 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5C512DD8D for ; Tue, 17 May 2016 12:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.446 X-Spam-Level: X-Spam-Status: No, score=-8.446 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=f5.com 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 ur_cY8RQwuMA for ; Tue, 17 May 2016 12:49:10 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C3612DD89 for ; Tue, 17 May 2016 12:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1463514551; x=1495050551; h=from:to:subject:date:message-id:mime-version; bh=0kXzD2pNL74VwdNdxgPbdLrx4VZQinPfdudcKIIlhHM=; b=vcNSEPX8l2yQ9cSCRLw8ydZbvo03SZkQPZuM0DynfZ7RzTepY2eUhqdb z1zv2sPSafslEPpeR2R8IHjSpOp18wACKsMPbbseEhAwro+9JhtlyRPk1 jd08N37VmNsSq0E1juwd8zarb5hwypx1iL1NlCwU5O4MV4ABiTVxPv3vX 0=; X-IronPort-AV: E=Sophos;i="5.26,325,1459814400"; d="scan'208,217";a="219461073" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 17 May 2016 19:49:10 +0000 Received: from SEAEXCHMBX04.olympus.F5Net.com (192.168.15.226) by SEAEXCHMBX07.olympus.F5Net.com (192.168.15.50) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 17 May 2016 12:49:09 -0700 Received: from SEAEXCHMBX04.olympus.F5Net.com ([fe80::856e:99ba:ff8b:b756]) by SEAEXCHMBX04.olympus.F5Net.com ([fe80::856e:99ba:ff8b:b756%21]) with mapi id 15.00.1178.000; Tue, 17 May 2016 12:49:09 -0700 From: Christian Koenning To: "sfc@ietf.org" Thread-Topic: Service Path Identifier (SPI) and symmetry Thread-Index: AQHRsHUtFvsY0ydaV0iEs6canF5mkg== Date: Tue, 17 May 2016 19:49:08 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: multipart/alternative; boundary="_000_AEB4E375203A4BD79E247D6C65861576f5com_" MIME-Version: 1.0 Archived-At: Subject: [sfc] Service Path Identifier (SPI) and symmetry X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 19:49:12 -0000 --_000_AEB4E375203A4BD79E247D6C65861576f5com_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R29vZCBFdmVuaW5nLA0KDQpsb29raW5nIGF0IFJGQyA3NjY1DQpTZXJ2aWNlIEZ1bmN0aW9uIENo YWluaW5nIChTRkMpIEFyY2hpdGVjdHVyZQ0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm Yzc2NjUNCg0KdGhlcmUgaXMgYSBjbGVhciBkZWZpbml0aW9uIG9mIGNoYWluIHN5bWV0cnkNCg0K Ig0KMi4yLiAgU2VydmljZSBGdW5jdGlvbiBDaGFpbiBTeW1tZXRyeQ0KDQogICBTRkNzIG1heSBi ZSB1bmlkaXJlY3Rpb25hbCBvciBiaWRpcmVjdGlvbmFsLiAgQSB1bmlkaXJlY3Rpb25hbCBTRkMN CiAgIHJlcXVpcmVzIHRoYXQgdHJhZmZpYyBiZSBmb3J3YXJkZWQgdGhyb3VnaCB0aGUgb3JkZXJl ZCBTRnMgaW4gb25lDQogICBkaXJlY3Rpb24gKHNmMSAtPiBzZjIgLT4gc2YzKSwgd2hlcmVhcyBh IGJpZGlyZWN0aW9uYWwgU0ZDIHJlcXVpcmVzIGENCiAgIHN5bW1ldHJpYyBwYXRoIChzZjEgLT4g c2YyIC0+IHNmMyBhbmQgc2YzIC0+IHNmMiAtPiBzZjEpLCBhbmQgaW4NCiAgIHdoaWNoIHRoZSBT RiBpbnN0YW5jZXMgYXJlIHRoZSBzYW1lIGluIG9wcG9zaXRlIGRpcmVjdGlvbnMuICBBIGh5YnJp ZA0KICAgU0ZDIGhhcyBhdHRyaWJ1dGVzIG9mIGJvdGggdW5pZGlyZWN0aW9uYWwgYW5kIGJpZGly ZWN0aW9uYWwgU0ZDczsNCiAgIHRoYXQgaXMgdG8gc2F5IHNvbWUgU0ZzIHJlcXVpcmUgc3ltbWV0 cmljIHRyYWZmaWMsIHdoZXJlYXMgb3RoZXIgU0ZzDQogICBkbyBub3QgcHJvY2VzcyByZXZlcnNl IHRyYWZmaWMgb3IgYXJlIGluZGVwZW5kZW50IG9mIHRoZQ0KICAgY29ycmVzcG9uZGluZyBmb3J3 YXJkIHRyYWZmaWMuDQoNCiAgIC4uLg0KDQogICAgRnVydGhlciwgdGhlcmUgYXJlIHN0YXRlIHRy YWRlLW9mZnMgaW4gc3ltbWV0cnkuICBTeW1tZXRyeSBtYXkgYmUNCiAgIHJlYWxpemVkIGluIHNl dmVyYWwgd2F5cyBkZXBlbmRpbmcgb24gdGhlIFNGRiBhbmQgY2xhc3NpZmllcg0KICAgZnVuY3Rp b25hbGl0eS4gIEluIHNvbWUgY2FzZXMsICJtaXJyb3JlZCIgY2xhc3NpZmljYXRpb24gKGkuZS4s IGZyb20NCiAgIFNvdXJjZSB0byBEZXN0aW5hdGlvbiBhbmQgZnJvbSBEZXN0aW5hdGlvbiB0byBT b3VyY2UpIHBvbGljeSBtYXkgYmUNCiAgIGRlcGxveWVkLCB3aGVyZWFzIGluIG90aGVycyBzaGFy ZWQgc3RhdGUgYmV0d2VlbiBjbGFzc2lmaWVycyBtYXkgYmUNCiAgIHVzZWQgdG8gZW5zdXJlIHRo YXQgc3ltbWV0cmljIGZsb3dzIGFyZSBjb3JyZWN0bHkgaWRlbnRpZmllZCwgdGhlbg0KICAgc3Rl ZXJlZCBhbG9uZyB0aGUgcmVxdWlyZWQgU0ZQLiAgQXQgYSBoaWdoIGxldmVsLCB0aGVyZSBhcmUg dmFyaW91cw0KICAgY29tbW9uIGNhc2VzLiAgSW4gYSBub24tZXhoYXVzdGl2ZSB3YXksIHRoZXJl IGNhbiBiZSBmb3IgZXhhbXBsZToNCg0KICAgbyAgQSBzaW5nbGUgY2xhc3NpZmllciAob3IgYSBz bWFsbCBudW1iZXIgb2YgY2xhc3NpZmllcnMpLCBpbiB3aGljaA0KICAgICAgY2FzZSBib3RoIGlu Y29taW5nIGFuZCBvdXRnb2luZyBmbG93cyBjb3VsZCBiZSByZWNvZ25pemVkIGF0IHRoZQ0KICAg ICAgc2FtZSBjbGFzc2lmaWVyLCBzbyB0aGUgc3luY2hyb25pemF0aW9uIHdvdWxkIGJlIGZlYXNp YmxlIGJ5DQogICAgICBpbnRlcm5hbCBtZWNoYW5pc21zIGludGVybmFsIHRvIHRoZSBjbGFzc2lm aWVyLg0KDQogICBvICBTdGF0ZWZ1bCBjbGFzc2lmaWVycyB3aGVyZSBzZXZlcmFsIGNsYXNzaWZp ZXJzIG1heSBiZSBjbHVzdGVyZWQNCiAgICAgIGFuZCBzaGFyZSBzdGF0ZS4NCg0KICAgbyAgRnVs bHkgZGlzdHJpYnV0ZWQgY2xhc3NpZmllcnMsIHdoZXJlIHN5bmNocm9uaXphdGlvbiBuZWVkcyB0 byBiZQ0KICAgICAgcHJvdmlkZWQgdGhyb3VnaCB1bnNwZWNpZmllZCBtZWFucy4NCg0KICAgbyAg QSBjbGFzc2lmaWVyIHRoYXQgbGVhcm5zIHN0YXRlIGZyb20gdGhlIGVncmVzcyBwYWNrZXRzL2Zs b3dzIHRoYXQNCiAgICAgIGlzIHRoZW4gdXNlZCB0byBwcm92aWRlIHN0YXRlIGZvciB0aGUgcmV0 dXJuIHBhY2tldHMvZmxvdy4NCg0KICAgbyAgU3ltbWV0cnkgbWF5IGFsc28gYmUgcHJvdmlkZWQg Ynkgc3RhdGVmdWwgZm9yd2FyZGluZyBsb2dpYyBpbiB0aGUNCiAgICAgIFNGRiBpbiBzb21lIGlt cGxlbWVudGF0aW9ucy4NCg0KICAgVGhpcyBpcyBhIG5vbi1jb21wcmVoZW5zaXZlIGxpc3Qgb2Yg Y29tbW9uIGNhc2VzLiAiDQoNCg0KSG93ZXZlciwgd2hlbiBsb29raW5nIGF0IHRoaXMgdG9nZXRo ZXIgd2l0aA0KTmV0d29yayBTZXJ2aWNlIEhlYWRlcg0KZHJhZnQtaWV0Zi1zZmMtbnNoLTA0LnR4 dA0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2ZjLW5zaC0wNA0KDQoz LjMuICBTZXJ2aWNlIFBhdGggSGVhZGVyDQoNCiINCiAgIFNlcnZpY2UgUGF0aCBJZGVudGlmaWVy IChTUEkpOiBpZGVudGlmaWVzIGEgc2VydmljZSBwYXRoLg0KICAgUGFydGljaXBhdGluZyBub2Rl cyBNVVNUIHVzZSB0aGlzIGlkZW50aWZpZXIgZm9yIFNlcnZpY2UgRnVuY3Rpb24NCiAgIFBhdGgg c2VsZWN0aW9uLg0KIg0KDQp0aGVyZSBpcyBubyBub3Rpb24gb2Ygc3ltbWV0cnkuDQoNCg0KQ2Fu IHlvdSBwbGVhc2UgY29uZmlybSB0aGF0IGEgYmlkaXJlY3Rpb25hbCBTZXJ2aWNlIEZ1bmN0aW9u IENoYWluDQp3aWxsIGJlIHJlcHJlc2VudGVkIGJ5IG9uZSBzaW5nbGUgU2VydmljZSBQYXRoIElk ZW50aWZpZXIsIGluZ3Jlc3Mgc3ltbWV0cmljIHRvIGVncmVzcyA/DQoNCg0KUGxlYXNlIGFsbG93 IHVzIHRvIGNsYXJpZnkgdGhpcy4NCg0KTWFueSBUaGFua3MNCg0KQ2hyaXN0aWFuIEtvZW5uaW5n DQotLQ0KRjUgTmV0d29ya3MgSW5jLg0KY2hyaXN0aWFuQGY1LmNvbQ0KDQo= --_000_AEB4E375203A4BD79E247D6C65861576f5com_ Content-Type: text/html; charset="utf-8" Content-ID: <1E39F063C9DFB4429EA0266DFB36A0E9@F5.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj5Hb29kIEV2ZW5pbmcsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5s b29raW5nIGF0IFJGQyA3NjY1Jm5ic3A7PC9kaXY+DQo8ZGl2PlNlcnZpY2UgRnVuY3Rpb24gQ2hh aW5pbmcgKFNGQykgQXJjaGl0ZWN0dXJlPC9kaXY+DQo8ZGl2Pmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM3NjY1PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj50aGVyZSBpcyBh IGNsZWFyIGRlZmluaXRpb24gb2YgY2hhaW4gc3ltZXRyeTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+JnF1b3Q7PC9kaXY+DQo8ZGl2PjIuMi4gJm5ic3A7U2VydmljZSBGdW5jdGlvbiBD aGFpbiBTeW1tZXRyeTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNw O1NGQ3MgbWF5IGJlIHVuaWRpcmVjdGlvbmFsIG9yIGJpZGlyZWN0aW9uYWwuICZuYnNwO0EgdW5p ZGlyZWN0aW9uYWwgU0ZDPC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDtyZXF1aXJlcyB0aGF0IHRy YWZmaWMgYmUgZm9yd2FyZGVkIHRocm91Z2ggdGhlIG9yZGVyZWQgU0ZzIGluIG9uZTwvZGl2Pg0K PGRpdj4mbmJzcDsgJm5ic3A7ZGlyZWN0aW9uIChzZjEgLSZndDsgc2YyIC0mZ3Q7IHNmMyksIHdo ZXJlYXMgYSBiaWRpcmVjdGlvbmFsIFNGQyByZXF1aXJlcyBhPC9kaXY+DQo8ZGl2PiZuYnNwOyAm bmJzcDtzeW1tZXRyaWMgcGF0aCAoc2YxIC0mZ3Q7IHNmMiAtJmd0OyBzZjMgYW5kIHNmMyAtJmd0 OyBzZjIgLSZndDsgc2YxKSwgYW5kIGluPC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDt3aGljaCB0 aGUgU0YgaW5zdGFuY2VzIGFyZSB0aGUgc2FtZSBpbiBvcHBvc2l0ZSBkaXJlY3Rpb25zLiAmbmJz cDtBIGh5YnJpZDwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7U0ZDIGhhcyBhdHRyaWJ1dGVzIG9m IGJvdGggdW5pZGlyZWN0aW9uYWwgYW5kIGJpZGlyZWN0aW9uYWwgU0ZDczs8L2Rpdj4NCjxkaXY+ Jm5ic3A7ICZuYnNwO3RoYXQgaXMgdG8gc2F5IHNvbWUgU0ZzIHJlcXVpcmUgc3ltbWV0cmljIHRy YWZmaWMsIHdoZXJlYXMgb3RoZXIgU0ZzPC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDtkbyBub3Qg cHJvY2VzcyByZXZlcnNlIHRyYWZmaWMgb3IgYXJlIGluZGVwZW5kZW50IG9mIHRoZTwvZGl2Pg0K PGRpdj4mbmJzcDsgJm5ic3A7Y29ycmVzcG9uZGluZyBmb3J3YXJkIHRyYWZmaWMuPC9kaXY+DQo8 ZGl2PiZuYnNwOyAmbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwOy4uLjwvZGl2Pg0KPGRp dj4mbmJzcDsgJm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDsgRnVydGhlciwgdGhlcmUg YXJlIHN0YXRlIHRyYWRlLW9mZnMgaW4gc3ltbWV0cnkuICZuYnNwO1N5bW1ldHJ5IG1heSBiZTwv ZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7cmVhbGl6ZWQgaW4gc2V2ZXJhbCB3YXlzIGRlcGVuZGlu ZyBvbiB0aGUgU0ZGIGFuZCBjbGFzc2lmaWVyPC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDtmdW5j dGlvbmFsaXR5LiAmbmJzcDtJbiBzb21lIGNhc2VzLCAmcXVvdDttaXJyb3JlZCZxdW90OyBjbGFz c2lmaWNhdGlvbiAoaS5lLiwgZnJvbTwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7U291cmNlIHRv IERlc3RpbmF0aW9uIGFuZCBmcm9tIERlc3RpbmF0aW9uIHRvIFNvdXJjZSkgcG9saWN5IG1heSBi ZTwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7ZGVwbG95ZWQsIHdoZXJlYXMgaW4gb3RoZXJzIHNo YXJlZCBzdGF0ZSBiZXR3ZWVuIGNsYXNzaWZpZXJzIG1heSBiZTwvZGl2Pg0KPGRpdj4mbmJzcDsg Jm5ic3A7dXNlZCB0byBlbnN1cmUgdGhhdCBzeW1tZXRyaWMgZmxvd3MgYXJlIGNvcnJlY3RseSBp ZGVudGlmaWVkLCB0aGVuPC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDtzdGVlcmVkIGFsb25nIHRo ZSByZXF1aXJlZCBTRlAuICZuYnNwO0F0IGEgaGlnaCBsZXZlbCwgdGhlcmUgYXJlIHZhcmlvdXM8 L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwO2NvbW1vbiBjYXNlcy4gJm5ic3A7SW4gYSBub24tZXho YXVzdGl2ZSB3YXksIHRoZXJlIGNhbiBiZSBmb3IgZXhhbXBsZTo8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDtvICZuYnNwO0Egc2luZ2xlIGNsYXNzaWZpZXIgKG9y IGEgc21hbGwgbnVtYmVyIG9mIGNsYXNzaWZpZXJzKSwgaW4gd2hpY2g8L2Rpdj4NCjxkaXY+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgY2FzZSBib3RoIGluY29taW5nIGFuZCBvdXRnb2luZyBmbG93cyBj b3VsZCBiZSByZWNvZ25pemVkIGF0IHRoZTwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7ICZuYnNw OyBzYW1lIGNsYXNzaWZpZXIsIHNvIHRoZSBzeW5jaHJvbml6YXRpb24gd291bGQgYmUgZmVhc2li bGUgYnk8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgaW50ZXJuYWwgbWVjaGFuaXNt cyBpbnRlcm5hbCB0byB0aGUgY2xhc3NpZmllci48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PiZuYnNwOyAmbmJzcDtvICZuYnNwO1N0YXRlZnVsIGNsYXNzaWZpZXJzIHdoZXJlIHNldmVy YWwgY2xhc3NpZmllcnMgbWF5IGJlIGNsdXN0ZXJlZDwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyBhbmQgc2hhcmUgc3RhdGUuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4m bmJzcDsgJm5ic3A7byAmbmJzcDtGdWxseSBkaXN0cmlidXRlZCBjbGFzc2lmaWVycywgd2hlcmUg c3luY2hyb25pemF0aW9uIG5lZWRzIHRvIGJlPC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDsgJm5i c3A7IHByb3ZpZGVkIHRocm91Z2ggdW5zcGVjaWZpZWQgbWVhbnMuPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7byAmbmJzcDtBIGNsYXNzaWZpZXIgdGhhdCBsZWFy bnMgc3RhdGUgZnJvbSB0aGUgZWdyZXNzIHBhY2tldHMvZmxvd3MgdGhhdDwvZGl2Pg0KPGRpdj4m bmJzcDsgJm5ic3A7ICZuYnNwOyBpcyB0aGVuIHVzZWQgdG8gcHJvdmlkZSBzdGF0ZSBmb3IgdGhl IHJldHVybiBwYWNrZXRzL2Zsb3cuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4mbmJz cDsgJm5ic3A7byAmbmJzcDtTeW1tZXRyeSBtYXkgYWxzbyBiZSBwcm92aWRlZCBieSBzdGF0ZWZ1 bCBmb3J3YXJkaW5nIGxvZ2ljIGluIHRoZTwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7ICZuYnNw OyBTRkYgaW4gc29tZSBpbXBsZW1lbnRhdGlvbnMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj4mbmJzcDsgJm5ic3A7VGhpcyBpcyBhIG5vbi1jb21wcmVoZW5zaXZlIGxpc3Qgb2YgY29t bW9uIGNhc2VzLiAmcXVvdDs8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwOzwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+SG93ZXZlciwgd2hlbiBsb29raW5nIGF0IHRoaXMgdG9nZXRoZXIg d2l0aCZuYnNwOzwvZGl2Pg0KPGRpdj5OZXR3b3JrIFNlcnZpY2UgSGVhZGVyPC9kaXY+DQo8ZGl2 PmRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQ8L2Rpdj4NCjxkaXY+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtc2ZjLW5zaC0wNDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+My4zLiAmbmJzcDtTZXJ2aWNlIFBhdGggSGVhZGVyPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj4mcXVvdDs8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwO1NlcnZpY2UgUGF0aCBJ ZGVudGlmaWVyIChTUEkpOiBpZGVudGlmaWVzIGEgc2VydmljZSBwYXRoLjwvZGl2Pg0KPGRpdj4m bmJzcDsgJm5ic3A7UGFydGljaXBhdGluZyBub2RlcyBNVVNUIHVzZSB0aGlzIGlkZW50aWZpZXIg Zm9yIFNlcnZpY2UgRnVuY3Rpb248L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwO1BhdGggc2VsZWN0 aW9uLjwvZGl2Pg0KPGRpdj4mcXVvdDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PnRo ZXJlIGlzIG5vIG5vdGlvbiBvZiBzeW1tZXRyeS4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5DYW4geW91IHBsZWFzZSBjb25maXJtIHRoYXQg YSBiaWRpcmVjdGlvbmFsIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW4mbmJzcDs8L2Rpdj4NCjxkaXY+ d2lsbCBiZSByZXByZXNlbnRlZCBieSBvbmUgc2luZ2xlIFNlcnZpY2UgUGF0aCBJZGVudGlmaWVy LCBpbmdyZXNzIHN5bW1ldHJpYyB0byBlZ3Jlc3MgPzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlBsZWFzZSBhbGxvdyB1cyB0byBjbGFyaWZ5IHRoaXMu PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5NYW55IFRoYW5rczwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+Q2hyaXN0aWFuIEtvZW5uaW5nPC9kaXY+DQo8ZGl2Pi0tPC9kaXY+ DQo8ZGl2PkY1IE5ldHdvcmtzIEluYy48L2Rpdj4NCjxkaXY+Y2hyaXN0aWFuQGY1LmNvbTwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09L X1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_AEB4E375203A4BD79E247D6C65861576f5com_-- From nobody Tue May 17 12:57:29 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B57112DDA3 for ; Tue, 17 May 2016 12:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 0r7K6dBtC-ED for ; Tue, 17 May 2016 12:57:26 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 A640112DDA0 for ; Tue, 17 May 2016 12:57:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 9381E24091B; Tue, 17 May 2016 12:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1463515046; bh=RqmkkNSbSzPVS4YjPd1Mkba5LOM4ij0bJ/XPdmF8mbQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ZLOkpwWJdKSC9n3kkgxci71vYtOiqaVMwQ1XkQcQNQ/5yEPKr+J/G3uiRr7NfpXWS NICMLD45pLA9qCoQP+By2g6sm5szyotz5EbQH9pKNMy51NlDwoPREgf6R5yk9OJJy7 f+0OYJawwwjFYuNPfc5wPAXTOJOobM0NMv9nPtiU= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 29E6A240779; Tue, 17 May 2016 12:57:26 -0700 (PDT) To: Christian Koenning , "sfc@ietf.org" References: From: "Joel M. Halpern" Message-ID: Date: Tue, 17 May 2016 15:57:35 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] Service Path Identifier (SPI) and symmetry X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 19:57:28 -0000 Most of us have assumed that a bi-directional symmetric path pair is set up by control, and has separate Service Path IDs (and indicies) in each direction. This does lead to a need for service functions which originate reverse direction packets to have a means to get the correct SPI / Index in place for those packets. There are drafts discussing approaches to that question. Yours, Joel On 5/17/16 3:49 PM, Christian Koenning wrote: > Good Evening, > > looking at RFC 7665 > Service Function Chaining (SFC) Architecture > https://tools.ietf.org/html/rfc7665 > > there is a clear definition of chain symetry > > " > 2.2. Service Function Chain Symmetry > > SFCs may be unidirectional or bidirectional. A unidirectional SFC > requires that traffic be forwarded through the ordered SFs in one > direction (sf1 -> sf2 -> sf3), whereas a bidirectional SFC requires a > symmetric path (sf1 -> sf2 -> sf3 and sf3 -> sf2 -> sf1), and in > which the SF instances are the same in opposite directions. A hybrid > SFC has attributes of both unidirectional and bidirectional SFCs; > that is to say some SFs require symmetric traffic, whereas other SFs > do not process reverse traffic or are independent of the > corresponding forward traffic. > > ... > > Further, there are state trade-offs in symmetry. Symmetry may be > realized in several ways depending on the SFF and classifier > functionality. In some cases, "mirrored" classification (i.e., from > Source to Destination and from Destination to Source) policy may be > deployed, whereas in others shared state between classifiers may be > used to ensure that symmetric flows are correctly identified, then > steered along the required SFP. At a high level, there are various > common cases. In a non-exhaustive way, there can be for example: > > o A single classifier (or a small number of classifiers), in which > case both incoming and outgoing flows could be recognized at the > same classifier, so the synchronization would be feasible by > internal mechanisms internal to the classifier. > > o Stateful classifiers where several classifiers may be clustered > and share state. > > o Fully distributed classifiers, where synchronization needs to be > provided through unspecified means. > > o A classifier that learns state from the egress packets/flows that > is then used to provide state for the return packets/flow. > > o Symmetry may also be provided by stateful forwarding logic in the > SFF in some implementations. > > This is a non-comprehensive list of common cases. " > > > However, when looking at this together with > Network Service Header > draft-ietf-sfc-nsh-04.txt > https://tools.ietf.org/html/draft-ietf-sfc-nsh-04 > > 3.3. Service Path Header > > " > Service Path Identifier (SPI): identifies a service path. > Participating nodes MUST use this identifier for Service Function > Path selection. > " > > there is no notion of symmetry. > > > Can you please confirm that a bidirectional Service Function Chain > will be represented by one single Service Path Identifier, ingress > symmetric to egress ? > > > Please allow us to clarify this. > > Many Thanks > > Christian Koenning > -- > F5 Networks Inc. > christian@f5.com > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Tue May 17 12:57:58 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC4D12DDA9 for ; Tue, 17 May 2016 12:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.447 X-Spam-Level: X-Spam-Status: No, score=-8.447 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=f5.com 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 4Lex-cfsD0HF for ; Tue, 17 May 2016 12:57:55 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1944612DD90 for ; Tue, 17 May 2016 12:57:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1463515076; x=1495051076; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ddwQXJmFOeQRdlBvci4TVIppHfq4N2POdfIWSMV01Tc=; b=IpGvTiVEeT9niw4xyTzV+l1LHlfAsUMgVKz4ujdSWb3iTrnTBMZMqAV1 QPoa4xjkRxst3uVuc1p9hFtqPqPnC4oGxqTxA7DaeYIuDZDs4TwnVQ24s jXI9v2dAxeB6pukLKm4NjZJZZXovBRJlsfBqLkeRwER4B98+OJhoiz0ov E=; X-IronPort-AV: E=Sophos;i="5.26,325,1459814400"; d="scan'208";a="219463080" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 17 May 2016 19:57:56 +0000 Received: from SEAEXCHMBX04.olympus.F5Net.com (192.168.15.226) by SEAEXCHMBX04.olympus.F5Net.com (192.168.15.226) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 17 May 2016 12:57:54 -0700 Received: from SEAEXCHMBX04.olympus.F5Net.com ([fe80::856e:99ba:ff8b:b756]) by SEAEXCHMBX04.olympus.F5Net.com ([fe80::856e:99ba:ff8b:b756%21]) with mapi id 15.00.1178.000; Tue, 17 May 2016 12:57:54 -0700 From: Christian Koenning To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] draft-ietf-sfc-nsh-04 with L2 encapsulation Thread-Index: AQHRsHUEuuA61QWLJU2qU3GSbFpt55++EjMA Date: Tue, 17 May 2016 19:57:53 +0000 Message-ID: <5EC3BFCB-31AD-4BA2-A9DD-5B2F1C51831D@f5.com> References: <8FB80637-C981-499B-A9C2-FCE119761B55@f5.com> <46f91899-618a-7443-1e12-d8bb153cf36e@joelhalpern.com> In-Reply-To: <46f91899-618a-7443-1e12-d8bb153cf36e@joelhalpern.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] draft-ietf-sfc-nsh-04 with L2 encapsulation X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 19:57:57 -0000 VGhhbmtzIEpvZWwsDQoNCg0KQWxsb3cgbWUgdG8gY2xhcmlmeToNCg0KV2hlbiBsb29raW5nIGF0 IHRoZSBpbm5lciBMMiBwYXlsb2FkICggb3V0ZXIgKE5TSCkgaW5uZXIgTDIpLCANCmlzIHRoZSBT RkYvU0YgcmVxdWlyZWQgdG8gY2hhbmdlIHRoZSBkZXN0aW5hdGlvbiBtYWMgYWRkcmVzcyB0bw0K d2hhdCB0aGUgbmV4dC1ob3AgbWlnaHQgZXhwZWN0ID8gDQoNCllvdXIgYW5zd2VyDQoiSm9lbCBN LiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6DQoNCj5UaGUgImlubmVyIiBw YWNrZXQgaXMgd2hhdGV2ZXIgTlNIIGlzIGNhcnJ5aW5nLiAgVGhhdCBpcyB3aGF0ZXZlciB3YXMg DQo+c2VudCBpbnRvIHRoZSBzeXN0ZW0uICBJbmRpdmlkdWFsIFNGIG1heSBwbGF5IHdpdGggdGhh dCwgYnV0IE5TSCANCj5mb3J3YXJkaW5nIGlnbm9yZXMgdGhhdC4NCg0KDQpMb29raW5nIGF0IHRo ZSBvdXRlciBwYXlsb2FkLCBmb3IgZS5nLiBhIFZYTEFOLUdQRSBlbmRwb2ludCwgeW91IHNheSAN CnRoYXQgbm9ybWFsIG1lY2hhbmlzbSBkZWZpbmUgdGhlIGZvcndhcmRpbmcuDQoNCkluIHRoZSBz cGVjaWZjIGV4YW1wbGUgb2YgYmVsb3cNCiAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICB8ICBTUEkgfCAgU0kgfCAgTkggICAg ICAgICAgICAgICAgIHwgICBUcmFuc3BvcnQgICAgICAgIHwNCiAgICArLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICB8ICAxMCAgfCAy NTUgfCAgMS4xLjEuMSAgICAgICAgICAgIHwgICBWWExBTi1ncGUgICAgICAgIHwNCg0KSXQgbWVh bnMgdGhhdCB0aGUgVlRFUCBhZGRyZXNzIGlzIDEuMS4xLjEgPyBIb3cgYWJvdXQgdGhlIFZOSSA/ DQoNCkNocmlzdGlhbg0KDQoNCg0KMTcvMDUvMjAxNiwgMjA6NDgsICJKb2VsIE0uIEhhbHBlcm4i IDxqbWhAam9lbGhhbHBlcm4uY29tPiB3cm90ZToNCg0KPkkgYW0gaGF2aW5nIHRyb3VibGUgcGFy c2luZyB5b3VyIHF1ZXN0aW9uLiAgSSBtYXkgYmUgbWlzcmVhZGluZyBpbm5lciANCj5hbmQgb3V0 ZXIuDQo+VGhlICJpbm5lciIgcGFja2V0IGlzIHdoYXRldmVyIE5TSCBpcyBjYXJyeWluZy4gIFRo YXQgaXMgd2hhdGV2ZXIgd2FzIA0KPnNlbnQgaW50byB0aGUgc3lzdGVtLiAgSW5kaXZpZHVhbCBT RiBtYXkgcGxheSB3aXRoIHRoYXQsIGJ1dCBOU0ggDQo+Zm9yd2FyZGluZyBpZ25vcmVzIHRoYXQu DQo+DQo+Tm93LCB0aGUgb3V0ZXIgcGFja2V0IGRlcGVuZHMgdXBvbiB0aGUgdHVubmVsIHR5cGUu ICBJZiB0aGUgdHVubmVsIGlzIGEgDQo+cHVyZSBFdGhlcm5ldCB0dW5uZWwsIHRoZW4gdGhlIE5T SCB0YWJsZSB0ZWxscyB5b3UgdGhlIEwyIEFkZHJlc3MgdG8gdXNlIA0KPmZvciB0aGUgb3V0ZXIg cGFja2V0Lg0KPklmIHRoZSB0dW5uZWwgaXMgYW4gTDMgZW5jYXBzdWxhdGVkIHR1bm5lbCAoVnhM QU4sIEdSRSwgLi4uKSB0aGVuIHRoZSANCj5OU0ggaW5mb3JtYXRpb24gZ2l2ZXMgeW91IHRoZSBM MyBuZXh0IGhvcC4gIEl0IGlzIHRoZSByZXNwb25zaWJpbGl0eSBvZiANCj50aGUgb3V0ZXIgSVAg c3lzdGVtLCBub3QgdGhlIE5TSCBzeXN0ZW0sIHRvIHJlc29sdmUgdGhhdCBJUCBhZGRyZXNzIHRv IA0KPmFuIGFjdHVhbCBJbnRlcmZhY2UgYW5kIGlmIG5lZWRlZCAodXN1YWxseSkgYW4gTDIgTUFD IGFkZHJlc3MuICBOU0ggYW5kIA0KPlNGQyBkb24ndCBjYXJlIGhvdyB0aGUgc3lzdGVtIGRvZXMg dGhhdC4gIE1vc3QgY29tbW1vbmx5LCBpdCBpcyBBUlAgLyANCj5JUHY2IE5ELiAgQnV0IGl0IGNh biBiZSBzdGF0aWMgY29uZmlndXJhdGlvbiBvciBzb21lIG90aGVyIGZvcm0gb2YgbWFnaWMuDQo+ DQo+WW91cnMsDQo+Sm9lbA0KPg0KPk9uIDUvMTcvMTYgMzozNSBQTSwgQ2hyaXN0aWFuIEtvZW5u aW5nIHdyb3RlOg0KPj4gR29vZCBhZnRlcm5vb24sDQo+Pg0KPj4gd2UgaGF2ZSBiZWVuIGRpc2N1 c3NpbmcgaW50ZXJuYWxseSB0aGUgc2VtYW50aWNzIG9mDQo+PiBOU0ggTDIgZW5jYXBzdWxhdGlv biBhcyBwZXI6DQo+Pg0KPj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt c2ZjLW5zaC0wNA0KPj4NCj4+DQo+Pg0KPj4gOS4xLiAgR1JFICsgTlNIDQo+Pg0KPj4gICAgIEwy IEZyYW1lOg0KPj4gICAgICstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0tLS0tKw0KPj4gICAgIHxMMiBoZWFkZXIgfCBMMyBoZWFkZXIsIHByb3RvPTQ3fEdS RSBoZWFkZXIsUFQ9MHg4OTRGfA0KPj4gICAgICstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPj4gICAgIC0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0rDQo+PiAgICAgTlNILCBOUD0weDMgICAgfG9yaWdpbmFsIGZyYW1lIHwNCj4+ICAg ICAtLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KPj4NCj4+IDkuMi4gIFZYTEFOLWdw ZSArIE5TSA0KPj4NCj4+ICAgICBMMiBGcmFtZToNCj4+ICAgICArLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPj4gICAgIHxMMiBoZWFk ZXIgfCBJUCArIFVEUCBkc3QgcG9ydD00NzkwIHxWWExBTi1ncGUgTlA9MHg0KE5TSCl8DQo+PiAg ICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0t LS0tLSsNCj4+ICAgICAtLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KPj4gICAgIE5T SCxOUD0weDMgICAgIHxvcmlnaW5hbCBmcmFtZSB8DQo+PiAgICAgLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLSsNCj4+DQo+Pg0KPj4gOS4zLiAgRXRoZXJuZXQgKyBOU0gNCj4+ICAgTDIg RnJhbWU6DQo+PiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tKw0KPj4gICB8T3V0ZXIgRXRoZXJuZXQsIEVUPTB4ODk0RiAg ICAgIHwgTlNILCBOUCA9IDB4MyB8IG9yaWdpbmFsIGZyYW1lIHwNCj4+ICAgKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rDQo+ Pg0KPj4gQWxzbywgbGV0IHVzIHJlY2FwIHRoYXQgdGhlIGZvcndhcmRpbmcgYmVoYXZpb3VyIGlz IGRlcml2ZWQgZnJvbSB0aGUNCj4+IFNQSS9TSSBtYXBwaW5nIGRlZmluZWQgYnkgdGhlIGNvbnRy b2xwbGFuZS4NCj4+DQo+PiBzZWUgcC4yMA0KPj4NCj4+ICAgICstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPj4gICAgfCAgU1BJIHwgIFNJ IHwgIE5IICAgICAgICAgICAgICAgICB8ICAgVHJhbnNwb3J0ICAgICAgICB8DQo+PiAgICArLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+ ICAgIHwgIDEwICB8IDI1NSB8ICAxLjEuMS4xICAgICAgICAgICAgfCAgIFZYTEFOLWdwZSAgICAg ICAgfA0KPj4gICAgfCAgMTAgIHwgMjU0IHwgIDIuMi4yLjIgICAgICAgICAgICB8ICAgbnZHUkUg ICAgICAgICAgICB8DQo+PiAgICB8ICAxMCAgfCAyNTEgfCAgMTAuMS4yLjMgICAgICAgICAgIHwg ICBHUkUgICAgICAgICAgICAgIHwNCj4+ICAgIHwgIDQwICB8IDI1MSB8ICAxMC4xLjIuMyAgICAg ICAgICAgfCAgIEdSRSAgICAgICAgICAgICAgfA0KPj4gICAgfCAgNTAgIHwgMjAwIHwgIDAxOjIz OjQ1OjY3Ojg5OmFiICB8ICAgRXRoZXJuZXQgICAgICAgICB8DQo+PiAgICB8ICAxNSAgfCAyMTIg fCAgTnVsbCAoZW5kIG9mIHBhdGgpIHwgICBOb25lICAgICAgICAgICAgIHwNCj4+ICAgICstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPj4g ICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDk6IFNGRiBOU0ggTWFwcGluZyBFeGFtcGxlDQo+ Pg0KPj4gTm93IGxvb2tpbmcgYXQgYSBzcGVjaWZpYyBleGFtcGxlIGZvciBmb3J3YXJkaW5nIHRv IGEgVlhMQU4tR1BFDQo+PiBlbmRwb2ludCwgaXMgdGhlIG5leHQtaG9wIGRlZmluZWQgYXMgdGhl IG91dGVyIGxheWVyIGRlc3RpbmF0aW9uLCBvciBpcw0KPj4gdGhpcyB0aGUgaW5uZXIgbGF5ZXIg ZGVzdGluYXRpb24sIGFuZCBzb21lIGZvcm0gb2YgQVJQIG9yIHByZWRlZmluZWQNCj4+IHJlc29s dXRpb24gaXMgYXNzdW1lZCA/DQo+Pg0KPj4gT3IgZXZlbiB0byBhc2sgbW9yZSBzcGVjaWZpY2Fs bHksIHdoZW4gZm9yd2FyZGluZyBmcm9tIGEgU0ZGIHRvIGEgU0YNCj4+IHVzaW5nIFZYTEFOLUdQ RSBOU0ggd2l0aCBMMiBlbmNhcHN1bGF0aW9uLCBpcyBpdCBleHBlY3RlZCB0aGF0IHRoZSBpbm5l cg0KPj4gTDIgZGVzdGluYXRpb24gYWRkcmVzcyBpcyBiZWluZyBjaGFuZ2VkIHRvIHRoZSByZXNv bHZlZCBMMiBhZGRyZXNzIG9mDQo+PiB0aGUgU0YgPw0KPj4NCj4+IFRoZSBtaXNzaW5nIGNsYXJp dHkgaXMgZGVyaXZlZCBmcm9tIHRoZSBkZWZpbml0aW9uIGFib3ZlLCAib3JpZ2luYWwNCj4+IGZy YW1lLiIgVGhpcyBjYW4gZWl0aGVyIG1lYW4gZW5jYXBzdWxhdGlvbiBoYXBwZW5zIGF0IENsYXNz aWZpZXIgTGV2ZWwsDQo+PiBhbmQgdGhlbiB0aGUgTDIgSGVhZGVyIHdpbGwgc3RheSB1bnRvdWNo ZWQuIEJ1dCB3aGF0IGlzIHRoZW4gdGhlIHB1cnBvc2UNCj4+IG9mIGl0ID8gT3IgZG9lcyB0aGlz IG1lYW4gdGhlIGlubmVyIEwyIEFkZHJlc3NlcyBuZWVkIHRvIHRvIHJlbmRlcmVkIGhvcA0KPj4g YnkgaG9wIGFzIGluIHRyYWRpdGlvbmFsIG5ldHdvcmtzLiBUaGlzIHdvdWxkIG1lYW4gd2UgaGF2 ZSBhIHBvc3NpYmxlDQo+PiB1bndhbnRlZCBkZXBlbmRlbmN5Lg0KPj4NCj4+DQo+Pg0KPj4gVGhl IHF1ZXN0aW9uIGNhbiBiZSB0YWtlbiBvdXQgb2YgdGhlIHRyYW5zcG9ydCBzY29wZSwgYW5kIHNp bXBsZSBiZQ0KPj4gZGVmaW5lZCBhcyDigJxEb2VzIE5TSCBMMiBlbmNhcHN1bGF0aW9uIGNhcmUg YWJvdXQgdGhlIGlubmVyIEwyIGhlYWRlcnMgP+KAnQ0KPj4NCj4+IFBsZWFzZSBhbGxvdyB1cyB0 byBjbGFyaWZ5IHRoaXMuDQo+Pg0KPj4gTWFueSBUaGFua3MNCj4+DQo+PiBDaHJpc3RpYW4gS29l bm5pbmcNCj4+IC0tDQo+PiBGNSBOZXR3b3JrcyBJbmMuDQo+PiBjaHJpc3RpYW5AZjUuY29tDQo+ Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+PiBzZmMgbWFpbGluZyBsaXN0DQo+PiBzZmNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Tue May 17 13:02:53 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1EB12DD98 for ; Tue, 17 May 2016 13:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.447 X-Spam-Level: X-Spam-Status: No, score=-8.447 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=f5.com 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 NyHq9wuYIQKn for ; Tue, 17 May 2016 13:02:50 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBD6B12D524 for ; Tue, 17 May 2016 13:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1463515371; x=1495051371; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=cNnrAIrBqBv0w+hKNNDHr42Q+saqpMc36z6t3hU5xL4=; b=RDZ9feSDfl2HAhwRrbPBOhoXGcfsOXpwvq3P26AK0ZKgYwX9KbRBeMbT DNLINLKzCeuCxHNyxT6V7kj5OrGq7z3ycQx6AbqJGcmh9teWQduhEHdzS x16KDaE3QqoffFPhbtLgHwCIWJqgnOtaNtRh75hi3IiUFqlTSrBFdjqpV s=; X-IronPort-AV: E=Sophos;i="5.26,325,1459814400"; d="scan'208";a="218606762" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP; 17 May 2016 20:02:50 +0000 Received: from SEAEXCHMBX04.olympus.F5Net.com (192.168.15.226) by seaexchmbx01.olympus.F5Net.com (192.168.15.223) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 17 May 2016 13:02:50 -0700 Received: from SEAEXCHMBX04.olympus.F5Net.com ([fe80::856e:99ba:ff8b:b756]) by SEAEXCHMBX04.olympus.F5Net.com ([fe80::856e:99ba:ff8b:b756%21]) with mapi id 15.00.1178.000; Tue, 17 May 2016 13:02:50 -0700 From: Christian Koenning To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Service Path Identifier (SPI) and symmetry Thread-Index: AQHRsHUtFvsY0ydaV0iEs6canF5mkp++ASSAgAASbwA= Date: Tue, 17 May 2016 20:02:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Service Path Identifier (SPI) and symmetry X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 20:02:52 -0000 VGhhbmtzIEpvZWwsDQoNCnRoYXQgaXMgd2hlcmUgSSB3YXMgZ2V0dGluZyBjb25mdXNlZC4NCg0K V2hlbiBsb29raW5nIGUuZy4gYXQgYSBzdGF0ZWZ1bCBTZXJ2aWNlIEZ1bmN0aW9uIChTRiksIHRo ZXJlIG5lZWRzIHRvIGJlDQphbiBpbnN0cnVjdGlvbiB3aGljaCB0d28gb2YgdGhlIFNlcnZpY2Ug UGF0aCBJZGVudGlmaWVycyBjby1yZWxlYXRlIGluDQpvcmRlciB0byBlc3RhYmxpc2ggc3RhdGUu DQoNCg0KRnVydGhlciB0byB0aGF0LCBjb3VsZCB5b3UgZGVmaW5lIGlmIFNlcnZpY2UgUGF0aCBJ ZGVudGlmaWVycyBhbGxvd3MgZm9yIA0Kb3ZlcmxvYWRpbmcgb2YgYWRkcmVzcyBuYW1lc3BhY2U/ IA0KDQpQbGVhc2UgYWxsb3cgdXMgdG8gY2xhcmlmeSB0aGlzLg0KDQpNYW55IFRoYW5rcw0KDQpD aHJpc3RpYW4gS29lbm5pbmcNCi0tDQpGNSBOZXR3b3JrcyBJbmMuDQpjaHJpc3RpYW5AZjUuY29t DQoNCg0KDQoNCg0KDQpPbiAxNy8wNS8yMDE2LCAyMDo1NywgIkpvZWwgTS4gSGFscGVybiIgPGpt aEBqb2VsaGFscGVybi5jb20+IHdyb3RlOg0KDQo+TW9zdCBvZiB1cyBoYXZlIGFzc3VtZWQgdGhh dCBhIGJpLWRpcmVjdGlvbmFsIHN5bW1ldHJpYyBwYXRoIHBhaXIgaXMgc2V0IA0KPnVwIGJ5IGNv bnRyb2wsIGFuZCBoYXMgc2VwYXJhdGUgU2VydmljZSBQYXRoIElEcyAoYW5kIGluZGljaWVzKSBp biBlYWNoIA0KPmRpcmVjdGlvbi4gIFRoaXMgZG9lcyBsZWFkIHRvIGEgbmVlZCBmb3Igc2Vydmlj ZSBmdW5jdGlvbnMgd2hpY2ggDQo+b3JpZ2luYXRlIHJldmVyc2UgZGlyZWN0aW9uIHBhY2tldHMg dG8gaGF2ZSBhIG1lYW5zIHRvIGdldCB0aGUgY29ycmVjdCANCj5TUEkgLyBJbmRleCBpbiBwbGFj ZSBmb3IgdGhvc2UgcGFja2V0cy4gIFRoZXJlIGFyZSBkcmFmdHMgZGlzY3Vzc2luZyANCj5hcHBy b2FjaGVzIHRvIHRoYXQgcXVlc3Rpb24uDQo+DQo+WW91cnMsDQo+Sm9lbA0KPg0KPk9uIDUvMTcv MTYgMzo0OSBQTSwgQ2hyaXN0aWFuIEtvZW5uaW5nIHdyb3RlOg0KPj4gR29vZCBFdmVuaW5nLA0K Pj4NCj4+IGxvb2tpbmcgYXQgUkZDIDc2NjUNCj4+IFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcg KFNGQykgQXJjaGl0ZWN0dXJlDQo+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzY2 NQ0KPj4NCj4+IHRoZXJlIGlzIGEgY2xlYXIgZGVmaW5pdGlvbiBvZiBjaGFpbiBzeW1ldHJ5DQo+ Pg0KPj4gIg0KPj4gMi4yLiAgU2VydmljZSBGdW5jdGlvbiBDaGFpbiBTeW1tZXRyeQ0KPj4NCj4+ ICAgIFNGQ3MgbWF5IGJlIHVuaWRpcmVjdGlvbmFsIG9yIGJpZGlyZWN0aW9uYWwuICBBIHVuaWRp cmVjdGlvbmFsIFNGQw0KPj4gICAgcmVxdWlyZXMgdGhhdCB0cmFmZmljIGJlIGZvcndhcmRlZCB0 aHJvdWdoIHRoZSBvcmRlcmVkIFNGcyBpbiBvbmUNCj4+ICAgIGRpcmVjdGlvbiAoc2YxIC0+IHNm MiAtPiBzZjMpLCB3aGVyZWFzIGEgYmlkaXJlY3Rpb25hbCBTRkMgcmVxdWlyZXMgYQ0KPj4gICAg c3ltbWV0cmljIHBhdGggKHNmMSAtPiBzZjIgLT4gc2YzIGFuZCBzZjMgLT4gc2YyIC0+IHNmMSks IGFuZCBpbg0KPj4gICAgd2hpY2ggdGhlIFNGIGluc3RhbmNlcyBhcmUgdGhlIHNhbWUgaW4gb3Bw b3NpdGUgZGlyZWN0aW9ucy4gIEEgaHlicmlkDQo+PiAgICBTRkMgaGFzIGF0dHJpYnV0ZXMgb2Yg Ym90aCB1bmlkaXJlY3Rpb25hbCBhbmQgYmlkaXJlY3Rpb25hbCBTRkNzOw0KPj4gICAgdGhhdCBp cyB0byBzYXkgc29tZSBTRnMgcmVxdWlyZSBzeW1tZXRyaWMgdHJhZmZpYywgd2hlcmVhcyBvdGhl ciBTRnMNCj4+ICAgIGRvIG5vdCBwcm9jZXNzIHJldmVyc2UgdHJhZmZpYyBvciBhcmUgaW5kZXBl bmRlbnQgb2YgdGhlDQo+PiAgICBjb3JyZXNwb25kaW5nIGZvcndhcmQgdHJhZmZpYy4NCj4+DQo+ PiAgICAuLi4NCj4+DQo+PiAgICAgRnVydGhlciwgdGhlcmUgYXJlIHN0YXRlIHRyYWRlLW9mZnMg aW4gc3ltbWV0cnkuICBTeW1tZXRyeSBtYXkgYmUNCj4+ICAgIHJlYWxpemVkIGluIHNldmVyYWwg d2F5cyBkZXBlbmRpbmcgb24gdGhlIFNGRiBhbmQgY2xhc3NpZmllcg0KPj4gICAgZnVuY3Rpb25h bGl0eS4gIEluIHNvbWUgY2FzZXMsICJtaXJyb3JlZCIgY2xhc3NpZmljYXRpb24gKGkuZS4sIGZy b20NCj4+ICAgIFNvdXJjZSB0byBEZXN0aW5hdGlvbiBhbmQgZnJvbSBEZXN0aW5hdGlvbiB0byBT b3VyY2UpIHBvbGljeSBtYXkgYmUNCj4+ICAgIGRlcGxveWVkLCB3aGVyZWFzIGluIG90aGVycyBz aGFyZWQgc3RhdGUgYmV0d2VlbiBjbGFzc2lmaWVycyBtYXkgYmUNCj4+ICAgIHVzZWQgdG8gZW5z dXJlIHRoYXQgc3ltbWV0cmljIGZsb3dzIGFyZSBjb3JyZWN0bHkgaWRlbnRpZmllZCwgdGhlbg0K Pj4gICAgc3RlZXJlZCBhbG9uZyB0aGUgcmVxdWlyZWQgU0ZQLiAgQXQgYSBoaWdoIGxldmVsLCB0 aGVyZSBhcmUgdmFyaW91cw0KPj4gICAgY29tbW9uIGNhc2VzLiAgSW4gYSBub24tZXhoYXVzdGl2 ZSB3YXksIHRoZXJlIGNhbiBiZSBmb3IgZXhhbXBsZToNCj4+DQo+PiAgICBvICBBIHNpbmdsZSBj bGFzc2lmaWVyIChvciBhIHNtYWxsIG51bWJlciBvZiBjbGFzc2lmaWVycyksIGluIHdoaWNoDQo+ PiAgICAgICBjYXNlIGJvdGggaW5jb21pbmcgYW5kIG91dGdvaW5nIGZsb3dzIGNvdWxkIGJlIHJl Y29nbml6ZWQgYXQgdGhlDQo+PiAgICAgICBzYW1lIGNsYXNzaWZpZXIsIHNvIHRoZSBzeW5jaHJv bml6YXRpb24gd291bGQgYmUgZmVhc2libGUgYnkNCj4+ICAgICAgIGludGVybmFsIG1lY2hhbmlz bXMgaW50ZXJuYWwgdG8gdGhlIGNsYXNzaWZpZXIuDQo+Pg0KPj4gICAgbyAgU3RhdGVmdWwgY2xh c3NpZmllcnMgd2hlcmUgc2V2ZXJhbCBjbGFzc2lmaWVycyBtYXkgYmUgY2x1c3RlcmVkDQo+PiAg ICAgICBhbmQgc2hhcmUgc3RhdGUuDQo+Pg0KPj4gICAgbyAgRnVsbHkgZGlzdHJpYnV0ZWQgY2xh c3NpZmllcnMsIHdoZXJlIHN5bmNocm9uaXphdGlvbiBuZWVkcyB0byBiZQ0KPj4gICAgICAgcHJv dmlkZWQgdGhyb3VnaCB1bnNwZWNpZmllZCBtZWFucy4NCj4+DQo+PiAgICBvICBBIGNsYXNzaWZp ZXIgdGhhdCBsZWFybnMgc3RhdGUgZnJvbSB0aGUgZWdyZXNzIHBhY2tldHMvZmxvd3MgdGhhdA0K Pj4gICAgICAgaXMgdGhlbiB1c2VkIHRvIHByb3ZpZGUgc3RhdGUgZm9yIHRoZSByZXR1cm4gcGFj a2V0cy9mbG93Lg0KPj4NCj4+ICAgIG8gIFN5bW1ldHJ5IG1heSBhbHNvIGJlIHByb3ZpZGVkIGJ5 IHN0YXRlZnVsIGZvcndhcmRpbmcgbG9naWMgaW4gdGhlDQo+PiAgICAgICBTRkYgaW4gc29tZSBp bXBsZW1lbnRhdGlvbnMuDQo+Pg0KPj4gICAgVGhpcyBpcyBhIG5vbi1jb21wcmVoZW5zaXZlIGxp c3Qgb2YgY29tbW9uIGNhc2VzLiAiDQo+Pg0KPj4NCj4+IEhvd2V2ZXIsIHdoZW4gbG9va2luZyBh dCB0aGlzIHRvZ2V0aGVyIHdpdGgNCj4+IE5ldHdvcmsgU2VydmljZSBIZWFkZXINCj4+IGRyYWZ0 LWlldGYtc2ZjLW5zaC0wNC50eHQNCj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLXNmYy1uc2gtMDQNCj4+DQo+PiAzLjMuICBTZXJ2aWNlIFBhdGggSGVhZGVyDQo+Pg0K Pj4gIg0KPj4gICAgU2VydmljZSBQYXRoIElkZW50aWZpZXIgKFNQSSk6IGlkZW50aWZpZXMgYSBz ZXJ2aWNlIHBhdGguDQo+PiAgICBQYXJ0aWNpcGF0aW5nIG5vZGVzIE1VU1QgdXNlIHRoaXMgaWRl bnRpZmllciBmb3IgU2VydmljZSBGdW5jdGlvbg0KPj4gICAgUGF0aCBzZWxlY3Rpb24uDQo+PiAi DQo+Pg0KPj4gdGhlcmUgaXMgbm8gbm90aW9uIG9mIHN5bW1ldHJ5Lg0KPj4NCj4+DQo+PiBDYW4g eW91IHBsZWFzZSBjb25maXJtIHRoYXQgYSBiaWRpcmVjdGlvbmFsIFNlcnZpY2UgRnVuY3Rpb24g Q2hhaW4NCj4+IHdpbGwgYmUgcmVwcmVzZW50ZWQgYnkgb25lIHNpbmdsZSBTZXJ2aWNlIFBhdGgg SWRlbnRpZmllciwgaW5ncmVzcw0KPj4gc3ltbWV0cmljIHRvIGVncmVzcyA/DQo+Pg0KPj4NCj4+ IFBsZWFzZSBhbGxvdyB1cyB0byBjbGFyaWZ5IHRoaXMuDQo+Pg0KPj4gTWFueSBUaGFua3MNCj4+ DQo+PiBDaHJpc3RpYW4gS29lbm5pbmcNCj4+IC0tDQo+PiBGNSBOZXR3b3JrcyBJbmMuDQo+PiBj aHJpc3RpYW5AZjUuY29tDQo+Pg0KPj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4gc2ZjQGlldGYu b3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4NCg== From nobody Tue May 17 13:06:58 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E069612DDA3 for ; Tue, 17 May 2016 13:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 SCYtfsu0Ag55 for ; Tue, 17 May 2016 13:06:55 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 8BE2312D985 for ; Tue, 17 May 2016 13:06:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 74802245B40; Tue, 17 May 2016 13:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1463515615; bh=c1PeQfqMHq7MadGldLBNS4pXZLBSfc3uYg7hat2/u+8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=E3skVgA/YeRcwiyCemuxn75T3esO1r99VKTOVEfw/jr8Trr0a5TIfNuKmyK6jFp2l Cov/ywA08ErAPCaIscT+uecBaRN4NUrYnhFzQc+5b97NgUSOYl4BZ6mSlHdMAxdPoN 9i/mOdGQPOQ7WU/8Cw9wdZzdT+akKpObGuR+MOKA= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id CB62E24091B; Tue, 17 May 2016 13:06:54 -0700 (PDT) To: Christian Koenning , "sfc@ietf.org" References: From: "Joel M. Halpern" Message-ID: <708683c2-8c57-41e1-0dc9-153fd09ecdcd@joelhalpern.com> Date: Tue, 17 May 2016 16:07:04 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] Service Path Identifier (SPI) and symmetry X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 20:06:57 -0000 Correlation of packets in two directions for an SF which works seems to require that the SF know how to correlate packets. Id does not need to look at the SPI for that, since SPI are coarser than flow. It may need to look at metadata (such as subscriber identity) if the SF is inside a domain where IP addresses are reused (NAT being a service function itself, so one could be on the reuse side of a NAT.) I am not sure what you are referring to by address namespaces. SPIs do not segregate subscribers, nor are they qualifiers for disambiguating addresses where NAT is in use. Metadata in the packet is used for such disambiguation. So, in the presence of suitable metadata, SFC and NSH support inner (subscriber) address reuse / duplication. NAT is an envisioned service function. Just don't try to use the SPI as the key. It won't tell you what you need. Yours, Joel On 5/17/16 4:02 PM, Christian Koenning wrote: > Thanks Joel, > > that is where I was getting confused. > > When looking e.g. at a stateful Service Function (SF), there needs to be > an instruction which two of the Service Path Identifiers co-releate in > order to establish state. > > > Further to that, could you define if Service Path Identifiers allows for > overloading of address namespace? > > Please allow us to clarify this. > > Many Thanks > > Christian Koenning > -- > F5 Networks Inc. > christian@f5.com > > > > > > > On 17/05/2016, 20:57, "Joel M. Halpern" wrote: > >> Most of us have assumed that a bi-directional symmetric path pair is set >> up by control, and has separate Service Path IDs (and indicies) in each >> direction. This does lead to a need for service functions which >> originate reverse direction packets to have a means to get the correct >> SPI / Index in place for those packets. There are drafts discussing >> approaches to that question. >> >> Yours, >> Joel >> >> On 5/17/16 3:49 PM, Christian Koenning wrote: >>> Good Evening, >>> >>> looking at RFC 7665 >>> Service Function Chaining (SFC) Architecture >>> https://tools.ietf.org/html/rfc7665 >>> >>> there is a clear definition of chain symetry >>> >>> " >>> 2.2. Service Function Chain Symmetry >>> >>> SFCs may be unidirectional or bidirectional. A unidirectional SFC >>> requires that traffic be forwarded through the ordered SFs in one >>> direction (sf1 -> sf2 -> sf3), whereas a bidirectional SFC requires a >>> symmetric path (sf1 -> sf2 -> sf3 and sf3 -> sf2 -> sf1), and in >>> which the SF instances are the same in opposite directions. A hybrid >>> SFC has attributes of both unidirectional and bidirectional SFCs; >>> that is to say some SFs require symmetric traffic, whereas other SFs >>> do not process reverse traffic or are independent of the >>> corresponding forward traffic. >>> >>> ... >>> >>> Further, there are state trade-offs in symmetry. Symmetry may be >>> realized in several ways depending on the SFF and classifier >>> functionality. In some cases, "mirrored" classification (i.e., from >>> Source to Destination and from Destination to Source) policy may be >>> deployed, whereas in others shared state between classifiers may be >>> used to ensure that symmetric flows are correctly identified, then >>> steered along the required SFP. At a high level, there are various >>> common cases. In a non-exhaustive way, there can be for example: >>> >>> o A single classifier (or a small number of classifiers), in which >>> case both incoming and outgoing flows could be recognized at the >>> same classifier, so the synchronization would be feasible by >>> internal mechanisms internal to the classifier. >>> >>> o Stateful classifiers where several classifiers may be clustered >>> and share state. >>> >>> o Fully distributed classifiers, where synchronization needs to be >>> provided through unspecified means. >>> >>> o A classifier that learns state from the egress packets/flows that >>> is then used to provide state for the return packets/flow. >>> >>> o Symmetry may also be provided by stateful forwarding logic in the >>> SFF in some implementations. >>> >>> This is a non-comprehensive list of common cases. " >>> >>> >>> However, when looking at this together with >>> Network Service Header >>> draft-ietf-sfc-nsh-04.txt >>> https://tools.ietf.org/html/draft-ietf-sfc-nsh-04 >>> >>> 3.3. Service Path Header >>> >>> " >>> Service Path Identifier (SPI): identifies a service path. >>> Participating nodes MUST use this identifier for Service Function >>> Path selection. >>> " >>> >>> there is no notion of symmetry. >>> >>> >>> Can you please confirm that a bidirectional Service Function Chain >>> will be represented by one single Service Path Identifier, ingress >>> symmetric to egress ? >>> >>> >>> Please allow us to clarify this. >>> >>> Many Thanks >>> >>> Christian Koenning >>> -- >>> F5 Networks Inc. >>> christian@f5.com >>> >>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> From nobody Tue May 17 13:08:28 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E3912DDA3 for ; Tue, 17 May 2016 13:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 SmWU_scjZs4h for ; Tue, 17 May 2016 13:08:24 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 5859A12D98A for ; Tue, 17 May 2016 13:08:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 43B6F24091B; Tue, 17 May 2016 13:08:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1463515704; bh=Wzu9VUZvh9h6OaX8CqqUuy8Plhj+gKzL4qqCef1gLTM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=j51lBkvhrFiyY/1oCOirbOwZKTiC0rG0u2BtItqUZaABHpYBBWhRJgoCTG8gpu7ZT xCYax9GD6LRoykaAM60YRWKvcfnWJ3vRs8/0wNumW0GaTjLNvPtk5tHxdf4j4L1x9Q ZUneZtAkaCtUUPLDiD4LWJfCA55PWqvg3/8hP0VE= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id A812124059A; Tue, 17 May 2016 13:08:23 -0700 (PDT) To: Christian Koenning , "sfc@ietf.org" References: <8FB80637-C981-499B-A9C2-FCE119761B55@f5.com> <46f91899-618a-7443-1e12-d8bb153cf36e@joelhalpern.com> <5EC3BFCB-31AD-4BA2-A9DD-5B2F1C51831D@f5.com> From: "Joel M. Halpern" Message-ID: Date: Tue, 17 May 2016 16:08:33 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <5EC3BFCB-31AD-4BA2-A9DD-5B2F1C51831D@f5.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] draft-ietf-sfc-nsh-04 with L2 encapsulation X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 20:08:26 -0000 In looking at this question, I sent Christian the following: Looking at pieces of packets on the wire, for a VXLAN packet carry NSH, I will see: Ehternet Header with Ethernet address this device and that of the next IP device towards the IP destination; IP Header with the IP Source equal to this device and IP Dest equal to that of the next SFF, as indicated by the table; UDP header; NSH Header; Original packet, which may be an IP packet or an Ethernet Packet. If the Original packet is an Ethernet packet, NSH will never change teh Ethernet headers in that packet. Conversely, the first listed Ethernet Header is added and subtracted at each hop in accordance with IP forwarding rules. Based on this, he indicated that his question was indeed about the inner packet. That is left unmodified by any SFF. Service functions can of course do what they like. Yours, Joel On 5/17/16 3:57 PM, Christian Koenning wrote: > Thanks Joel, > > > Allow me to clarify: > > When looking at the inner L2 payload ( outer (NSH) inner L2), > is the SFF/SF required to change the destination mac address to > what the next-hop might expect ? > > Your answer > "Joel M. Halpern" wrote: > >> The "inner" packet is whatever NSH is carrying. That is whatever was >> sent into the system. Individual SF may play with that, but NSH >> forwarding ignores that. > > > Looking at the outer payload, for e.g. a VXLAN-GPE endpoint, you say > that normal mechanism define the forwarding. > > In the specifc example of below > +-------------------------------------------------------+ > | SPI | SI | NH | Transport | > +-------------------------------------------------------+ > | 10 | 255 | 1.1.1.1 | VXLAN-gpe | > > It means that the VTEP address is 1.1.1.1 ? How about the VNI ? > > Christian > > > > 17/05/2016, 20:48, "Joel M. Halpern" wrote: > >> I am having trouble parsing your question. I may be misreading inner >> and outer. >> The "inner" packet is whatever NSH is carrying. That is whatever was >> sent into the system. Individual SF may play with that, but NSH >> forwarding ignores that. >> >> Now, the outer packet depends upon the tunnel type. If the tunnel is a >> pure Ethernet tunnel, then the NSH table tells you the L2 Address to use >> for the outer packet. >> If the tunnel is an L3 encapsulated tunnel (VxLAN, GRE, ...) then the >> NSH information gives you the L3 next hop. It is the responsibility of >> the outer IP system, not the NSH system, to resolve that IP address to >> an actual Interface and if needed (usually) an L2 MAC address. NSH and >> SFC don't care how the system does that. Most commmonly, it is ARP / >> IPv6 ND. But it can be static configuration or some other form of magic. >> >> Yours, >> Joel >> >> On 5/17/16 3:35 PM, Christian Koenning wrote: >>> Good afternoon, >>> >>> we have been discussing internally the semantics of >>> NSH L2 encapsulation as per: >>> >>> https://tools.ietf.org/html/draft-ietf-sfc-nsh-04 >>> >>> >>> >>> 9.1. GRE + NSH >>> >>> L2 Frame: >>> +----------+--------------------+--------------------+ >>> |L2 header | L3 header, proto=47|GRE header,PT=0x894F| >>> +----------+--------------------+--------------------+ >>> ---------------+---------------+ >>> NSH, NP=0x3 |original frame | >>> ---------------+---------------+ >>> >>> 9.2. VXLAN-gpe + NSH >>> >>> L2 Frame: >>> +----------+------------------------+---------------------+ >>> |L2 header | IP + UDP dst port=4790 |VXLAN-gpe NP=0x4(NSH)| >>> +----------+------------------------+---------------------+ >>> ---------------+---------------+ >>> NSH,NP=0x3 |original frame | >>> ---------------+---------------+ >>> >>> >>> 9.3. Ethernet + NSH >>> L2 Frame: >>> +-------------------------------+---------------+----------------+ >>> |Outer Ethernet, ET=0x894F | NSH, NP = 0x3 | original frame | >>> +-------------------------------+---------------+----------------+ >>> >>> Also, let us recap that the forwarding behaviour is derived from the >>> SPI/SI mapping defined by the controlplane. >>> >>> see p.20 >>> >>> +-------------------------------------------------------+ >>> | SPI | SI | NH | Transport | >>> +-------------------------------------------------------+ >>> | 10 | 255 | 1.1.1.1 | VXLAN-gpe | >>> | 10 | 254 | 2.2.2.2 | nvGRE | >>> | 10 | 251 | 10.1.2.3 | GRE | >>> | 40 | 251 | 10.1.2.3 | GRE | >>> | 50 | 200 | 01:23:45:67:89:ab | Ethernet | >>> | 15 | 212 | Null (end of path) | None | >>> +-------------------------------------------------------+ >>> Figure 9: SFF NSH Mapping Example >>> >>> Now looking at a specific example for forwarding to a VXLAN-GPE >>> endpoint, is the next-hop defined as the outer layer destination, or is >>> this the inner layer destination, and some form of ARP or predefined >>> resolution is assumed ? >>> >>> Or even to ask more specifically, when forwarding from a SFF to a SF >>> using VXLAN-GPE NSH with L2 encapsulation, is it expected that the inner >>> L2 destination address is being changed to the resolved L2 address of >>> the SF ? >>> >>> The missing clarity is derived from the definition above, "original >>> frame." This can either mean encapsulation happens at Classifier Level, >>> and then the L2 Header will stay untouched. But what is then the purpose >>> of it ? Or does this mean the inner L2 Addresses need to to rendered hop >>> by hop as in traditional networks. This would mean we have a possible >>> unwanted dependency. >>> >>> >>> >>> The question can be taken out of the transport scope, and simple be >>> defined as “Does NSH L2 encapsulation care about the inner L2 headers ?†>>> >>> Please allow us to clarify this. >>> >>> Many Thanks >>> >>> Christian Koenning >>> -- >>> F5 Networks Inc. >>> christian@f5.com >>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc From nobody Tue May 17 13:45:41 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417A312D5D2 for ; Tue, 17 May 2016 13:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.447 X-Spam-Level: X-Spam-Status: No, score=-8.447 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=f5.com 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 RdxCC0CthC-6 for ; Tue, 17 May 2016 13:45:37 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4651612DD66 for ; Tue, 17 May 2016 13:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1463517938; x=1495053938; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=YVboUbQrQh5iJJe+c7OjhG4SfzW0BL68OydETFqXplk=; b=tK55v1cjKmU2TxJi3GRrqq7KJ8A2jS1dhhfI4/tKbXdDuxyv8ADoFNDY S6vtjrpKRPO6nUGjw+PWPub4TsoaWF5CTmYwTMKqJRqbGldEav+69W8FN 8AhofbjwoSr2UmU4X+XcMXvhTt5FVkjPlLioNYvmW9UirofjvaQTEgHHD Y=; X-IronPort-AV: E=Sophos;i="5.26,325,1459814400"; d="scan'208";a="219472760" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 17 May 2016 20:45:37 +0000 Received: from SEAEXCHMBX04.olympus.F5Net.com (192.168.15.226) by seaexchmbx01.olympus.F5Net.com (192.168.15.223) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 17 May 2016 13:45:36 -0700 Received: from SEAEXCHMBX04.olympus.F5Net.com ([fe80::856e:99ba:ff8b:b756]) by SEAEXCHMBX04.olympus.F5Net.com ([fe80::856e:99ba:ff8b:b756%21]) with mapi id 15.00.1178.000; Tue, 17 May 2016 13:45:36 -0700 From: Christian Koenning To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Service Path Identifier (SPI) and symmetry Thread-Index: AQHRsHUtFvsY0ydaV0iEs6canF5mkp++ASSAgAASbwD///A3AIAAG7uA Date: Tue, 17 May 2016 20:45:36 +0000 Message-ID: References: <708683c2-8c57-41e1-0dc9-153fd09ecdcd@joelhalpern.com> In-Reply-To: <708683c2-8c57-41e1-0dc9-153fd09ecdcd@joelhalpern.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Service Path Identifier (SPI) and symmetry X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 20:45:39 -0000 DQpUaGFua3MgSm9lbCwNCg0KdGhhbmtzIGZvciBjb25maXJtaW5nIGZsb3cgY29ycmVsYXRpb24g KEw0KSBpcyBleHBlY3RlZCBhcyB1c3VhbCwgZXZlbg0Kd2l0aCBpbmdyZXNzIGFuZCBlZ3Jlc3Mg b24gdHdvIGRpZmZlcmVudCBTZXJ2aWNlIFBhdGggSURzLiBUaGUgcXVlc3Rpb24NCm9mIG92ZXJs b2FkaW5nIGFkZHJlc3Mgc3BhY2UgdHJpZWQgdG8gY2xhcmlmeSB0aGUgKHJhcmUpIHRoZSBzaXR1 YXRpb24gd2hlcmUNCiAyIGVuZHBvaW50IHBhaXJzIGhhdmUgdGhlIHNhbWUgYWRkcmVzc2VzIGFu ZCBoYXZlIGFncmVlZCBvbiB0aGUgc2FtZQ0Kc3JjL2RzdCBwb3J0L3Byb3RvY29sLCB3aGljaCBs ZWFkcyB0byBmbG93IGNvbGxpc2lvbnMuDQoNCllvdSBtZW50aW9uIHRoYXQgU2VydmljZSBQYXRo IElEIHdpbGwgbm93IGFsbG93IHRvIHJldXNlLSAvZHVwbGljYXRpb24uDQoNCkhvd2V2ZXIsIHlv dSBtZW50aW9uZWQgdGhhdCBtZXRhZGF0YSB3aWxsIHByb3ZpZGUgYWRkcmVzcyByZXVzZS0gLw0K ZHVwbGljYXRpb24uIFRoZXJlZm9yZSB0aGUgZmxvdyBjb3JyZWxhdGlvbiB3b3VsZCBuZWVkIHRv IGhhcHBlbiBvbg0KaW5jbHVkaW5nIHRoZSBtZXRhZGF0YSBhcyBwYXJ0IG9mIHRoZSB0dXBsZSBh cyB3ZWxsLg0KDQpBbHNvLCBhbGxvdyBtZSB0byBhc2sgaWYgd2UgZXhwZWN0IGluZ3Jlc3MgYW5k IGVncmVzcyBTZXJ2aWNlIFBhdGggSURzDQpvbiB0aGUgc2FtZSB0cmFuc3BvcnQvdHVubmVsID8N Cg0KTWFueSBUaGFua3MNCg0KQ2hyaXN0aWFuIEtvZW5uaW5nDQotLQ0KRjUgTmV0d29ya3MgSW5j Lg0KY2hyaXN0aWFuQGY1LmNvbQ0KDQoNCg0KDQoNCg0KT24gMTcvMDUvMjAxNiwgMjE6MDcsICJK b2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPiB3cm90ZToNCg0KPkNvcnJlbGF0 aW9uIG9mIHBhY2tldHMgaW4gdHdvIGRpcmVjdGlvbnMgZm9yIGFuIFNGIHdoaWNoIHdvcmtzIHNl ZW1zIHRvIA0KPnJlcXVpcmUgdGhhdCB0aGUgU0Yga25vdyBob3cgdG8gY29ycmVsYXRlIHBhY2tl dHMuICBJZCBkb2VzIG5vdCBuZWVkIHRvIA0KPmxvb2sgYXQgdGhlIFNQSSBmb3IgdGhhdCwgc2lu Y2UgU1BJIGFyZSBjb2Fyc2VyIHRoYW4gZmxvdy4gIEl0IG1heSBuZWVkIA0KPnRvIGxvb2sgYXQg bWV0YWRhdGEgKHN1Y2ggYXMgc3Vic2NyaWJlciBpZGVudGl0eSkgaWYgdGhlIFNGIGlzIGluc2lk ZSBhIA0KPmRvbWFpbiB3aGVyZSBJUCBhZGRyZXNzZXMgYXJlIHJldXNlZCAoTkFUIGJlaW5nIGEg c2VydmljZSBmdW5jdGlvbiANCj5pdHNlbGYsIHNvIG9uZSBjb3VsZCBiZSBvbiB0aGUgcmV1c2Ug c2lkZSBvZiBhIE5BVC4pDQo+DQo+SSBhbSBub3Qgc3VyZSB3aGF0IHlvdSBhcmUgcmVmZXJyaW5n IHRvIGJ5IGFkZHJlc3MgbmFtZXNwYWNlcy4gIFNQSXMgZG8gDQo+bm90IHNlZ3JlZ2F0ZSBzdWJz Y3JpYmVycywgbm9yIGFyZSB0aGV5IHF1YWxpZmllcnMgZm9yIGRpc2FtYmlndWF0aW5nIA0KPmFk ZHJlc3NlcyB3aGVyZSBOQVQgaXMgaW4gdXNlLiAgTWV0YWRhdGEgaW4gdGhlIHBhY2tldCBpcyB1 c2VkIGZvciBzdWNoIA0KPmRpc2FtYmlndWF0aW9uLiAgU28sIGluIHRoZSBwcmVzZW5jZSBvZiBz dWl0YWJsZSBtZXRhZGF0YSwgU0ZDIGFuZCBOU0ggDQo+c3VwcG9ydCBpbm5lciAoc3Vic2NyaWJl cikgYWRkcmVzcyByZXVzZSAvIGR1cGxpY2F0aW9uLiAgTkFUIGlzIGFuIA0KPmVudmlzaW9uZWQg c2VydmljZSBmdW5jdGlvbi4gIEp1c3QgZG9uJ3QgdHJ5IHRvIHVzZSB0aGUgU1BJIGFzIHRoZSBr ZXkuIA0KPkl0IHdvbid0IHRlbGwgeW91IHdoYXQgeW91IG5lZWQuDQo+DQo+WW91cnMsDQo+Sm9l bA0KPg0KPk9uIDUvMTcvMTYgNDowMiBQTSwgQ2hyaXN0aWFuIEtvZW5uaW5nIHdyb3RlOg0KPj4g VGhhbmtzIEpvZWwsDQo+Pg0KPj4gdGhhdCBpcyB3aGVyZSBJIHdhcyBnZXR0aW5nIGNvbmZ1c2Vk Lg0KPj4NCj4+IFdoZW4gbG9va2luZyBlLmcuIGF0IGEgc3RhdGVmdWwgU2VydmljZSBGdW5jdGlv biAoU0YpLCB0aGVyZSBuZWVkcyB0byBiZQ0KPj4gYW4gaW5zdHJ1Y3Rpb24gd2hpY2ggdHdvIG9m IHRoZSBTZXJ2aWNlIFBhdGggSWRlbnRpZmllcnMgY28tcmVsZWF0ZSBpbg0KPj4gb3JkZXIgdG8g ZXN0YWJsaXNoIHN0YXRlLg0KPj4NCj4+DQo+PiBGdXJ0aGVyIHRvIHRoYXQsIGNvdWxkIHlvdSBk ZWZpbmUgaWYgU2VydmljZSBQYXRoIElkZW50aWZpZXJzIGFsbG93cyBmb3INCj4+IG92ZXJsb2Fk aW5nIG9mIGFkZHJlc3MgbmFtZXNwYWNlPw0KPj4NCj4+IFBsZWFzZSBhbGxvdyB1cyB0byBjbGFy aWZ5IHRoaXMuDQo+Pg0KPj4gTWFueSBUaGFua3MNCj4+DQo+PiBDaHJpc3RpYW4gS29lbm5pbmcN Cj4+IC0tDQo+PiBGNSBOZXR3b3JrcyBJbmMuDQo+PiBjaHJpc3RpYW5AZjUuY29tDQo+Pg0KPj4N Cj4+DQo+Pg0KPj4NCj4+DQo+PiBPbiAxNy8wNS8yMDE2LCAyMDo1NywgIkpvZWwgTS4gSGFscGVy biIgPGptaEBqb2VsaGFscGVybi5jb20+IHdyb3RlOg0KPj4NCj4+PiBNb3N0IG9mIHVzIGhhdmUg YXNzdW1lZCB0aGF0IGEgYmktZGlyZWN0aW9uYWwgc3ltbWV0cmljIHBhdGggcGFpciBpcyBzZXQN Cj4+PiB1cCBieSBjb250cm9sLCBhbmQgaGFzIHNlcGFyYXRlIFNlcnZpY2UgUGF0aCBJRHMgKGFu ZCBpbmRpY2llcykgaW4gZWFjaA0KPj4+IGRpcmVjdGlvbi4gIFRoaXMgZG9lcyBsZWFkIHRvIGEg bmVlZCBmb3Igc2VydmljZSBmdW5jdGlvbnMgd2hpY2gNCj4+PiBvcmlnaW5hdGUgcmV2ZXJzZSBk aXJlY3Rpb24gcGFja2V0cyB0byBoYXZlIGEgbWVhbnMgdG8gZ2V0IHRoZSBjb3JyZWN0DQo+Pj4g U1BJIC8gSW5kZXggaW4gcGxhY2UgZm9yIHRob3NlIHBhY2tldHMuICBUaGVyZSBhcmUgZHJhZnRz IGRpc2N1c3NpbmcNCj4+PiBhcHByb2FjaGVzIHRvIHRoYXQgcXVlc3Rpb24uDQo+Pj4NCj4+PiBZ b3VycywNCj4+PiBKb2VsDQo+Pj4NCj4+PiBPbiA1LzE3LzE2IDM6NDkgUE0sIENocmlzdGlhbiBL b2VubmluZyB3cm90ZToNCj4+Pj4gR29vZCBFdmVuaW5nLA0KPj4+Pg0KPj4+PiBsb29raW5nIGF0 IFJGQyA3NjY1DQo+Pj4+IFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgKFNGQykgQXJjaGl0ZWN0 dXJlDQo+Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NjY1DQo+Pj4+DQo+Pj4+ IHRoZXJlIGlzIGEgY2xlYXIgZGVmaW5pdGlvbiBvZiBjaGFpbiBzeW1ldHJ5DQo+Pj4+DQo+Pj4+ ICINCj4+Pj4gMi4yLiAgU2VydmljZSBGdW5jdGlvbiBDaGFpbiBTeW1tZXRyeQ0KPj4+Pg0KPj4+ PiAgICBTRkNzIG1heSBiZSB1bmlkaXJlY3Rpb25hbCBvciBiaWRpcmVjdGlvbmFsLiAgQSB1bmlk aXJlY3Rpb25hbCBTRkMNCj4+Pj4gICAgcmVxdWlyZXMgdGhhdCB0cmFmZmljIGJlIGZvcndhcmRl ZCB0aHJvdWdoIHRoZSBvcmRlcmVkIFNGcyBpbiBvbmUNCj4+Pj4gICAgZGlyZWN0aW9uIChzZjEg LT4gc2YyIC0+IHNmMyksIHdoZXJlYXMgYSBiaWRpcmVjdGlvbmFsIFNGQyByZXF1aXJlcyBhDQo+ Pj4+ICAgIHN5bW1ldHJpYyBwYXRoIChzZjEgLT4gc2YyIC0+IHNmMyBhbmQgc2YzIC0+IHNmMiAt PiBzZjEpLCBhbmQgaW4NCj4+Pj4gICAgd2hpY2ggdGhlIFNGIGluc3RhbmNlcyBhcmUgdGhlIHNh bWUgaW4gb3Bwb3NpdGUgZGlyZWN0aW9ucy4gIEEgaHlicmlkDQo+Pj4+ICAgIFNGQyBoYXMgYXR0 cmlidXRlcyBvZiBib3RoIHVuaWRpcmVjdGlvbmFsIGFuZCBiaWRpcmVjdGlvbmFsIFNGQ3M7DQo+ Pj4+ICAgIHRoYXQgaXMgdG8gc2F5IHNvbWUgU0ZzIHJlcXVpcmUgc3ltbWV0cmljIHRyYWZmaWMs IHdoZXJlYXMgb3RoZXIgU0ZzDQo+Pj4+ICAgIGRvIG5vdCBwcm9jZXNzIHJldmVyc2UgdHJhZmZp YyBvciBhcmUgaW5kZXBlbmRlbnQgb2YgdGhlDQo+Pj4+ICAgIGNvcnJlc3BvbmRpbmcgZm9yd2Fy ZCB0cmFmZmljLg0KPj4+Pg0KPj4+PiAgICAuLi4NCj4+Pj4NCj4+Pj4gICAgIEZ1cnRoZXIsIHRo ZXJlIGFyZSBzdGF0ZSB0cmFkZS1vZmZzIGluIHN5bW1ldHJ5LiAgU3ltbWV0cnkgbWF5IGJlDQo+ Pj4+ICAgIHJlYWxpemVkIGluIHNldmVyYWwgd2F5cyBkZXBlbmRpbmcgb24gdGhlIFNGRiBhbmQg Y2xhc3NpZmllcg0KPj4+PiAgICBmdW5jdGlvbmFsaXR5LiAgSW4gc29tZSBjYXNlcywgIm1pcnJv cmVkIiBjbGFzc2lmaWNhdGlvbiAoaS5lLiwgZnJvbQ0KPj4+PiAgICBTb3VyY2UgdG8gRGVzdGlu YXRpb24gYW5kIGZyb20gRGVzdGluYXRpb24gdG8gU291cmNlKSBwb2xpY3kgbWF5IGJlDQo+Pj4+ ICAgIGRlcGxveWVkLCB3aGVyZWFzIGluIG90aGVycyBzaGFyZWQgc3RhdGUgYmV0d2VlbiBjbGFz c2lmaWVycyBtYXkgYmUNCj4+Pj4gICAgdXNlZCB0byBlbnN1cmUgdGhhdCBzeW1tZXRyaWMgZmxv d3MgYXJlIGNvcnJlY3RseSBpZGVudGlmaWVkLCB0aGVuDQo+Pj4+ICAgIHN0ZWVyZWQgYWxvbmcg dGhlIHJlcXVpcmVkIFNGUC4gIEF0IGEgaGlnaCBsZXZlbCwgdGhlcmUgYXJlIHZhcmlvdXMNCj4+ Pj4gICAgY29tbW9uIGNhc2VzLiAgSW4gYSBub24tZXhoYXVzdGl2ZSB3YXksIHRoZXJlIGNhbiBi ZSBmb3IgZXhhbXBsZToNCj4+Pj4NCj4+Pj4gICAgbyAgQSBzaW5nbGUgY2xhc3NpZmllciAob3Ig YSBzbWFsbCBudW1iZXIgb2YgY2xhc3NpZmllcnMpLCBpbiB3aGljaA0KPj4+PiAgICAgICBjYXNl IGJvdGggaW5jb21pbmcgYW5kIG91dGdvaW5nIGZsb3dzIGNvdWxkIGJlIHJlY29nbml6ZWQgYXQg dGhlDQo+Pj4+ICAgICAgIHNhbWUgY2xhc3NpZmllciwgc28gdGhlIHN5bmNocm9uaXphdGlvbiB3 b3VsZCBiZSBmZWFzaWJsZSBieQ0KPj4+PiAgICAgICBpbnRlcm5hbCBtZWNoYW5pc21zIGludGVy bmFsIHRvIHRoZSBjbGFzc2lmaWVyLg0KPj4+Pg0KPj4+PiAgICBvICBTdGF0ZWZ1bCBjbGFzc2lm aWVycyB3aGVyZSBzZXZlcmFsIGNsYXNzaWZpZXJzIG1heSBiZSBjbHVzdGVyZWQNCj4+Pj4gICAg ICAgYW5kIHNoYXJlIHN0YXRlLg0KPj4+Pg0KPj4+PiAgICBvICBGdWxseSBkaXN0cmlidXRlZCBj bGFzc2lmaWVycywgd2hlcmUgc3luY2hyb25pemF0aW9uIG5lZWRzIHRvIGJlDQo+Pj4+ICAgICAg IHByb3ZpZGVkIHRocm91Z2ggdW5zcGVjaWZpZWQgbWVhbnMuDQo+Pj4+DQo+Pj4+ICAgIG8gIEEg Y2xhc3NpZmllciB0aGF0IGxlYXJucyBzdGF0ZSBmcm9tIHRoZSBlZ3Jlc3MgcGFja2V0cy9mbG93 cyB0aGF0DQo+Pj4+ICAgICAgIGlzIHRoZW4gdXNlZCB0byBwcm92aWRlIHN0YXRlIGZvciB0aGUg cmV0dXJuIHBhY2tldHMvZmxvdy4NCj4+Pj4NCj4+Pj4gICAgbyAgU3ltbWV0cnkgbWF5IGFsc28g YmUgcHJvdmlkZWQgYnkgc3RhdGVmdWwgZm9yd2FyZGluZyBsb2dpYyBpbiB0aGUNCj4+Pj4gICAg ICAgU0ZGIGluIHNvbWUgaW1wbGVtZW50YXRpb25zLg0KPj4+Pg0KPj4+PiAgICBUaGlzIGlzIGEg bm9uLWNvbXByZWhlbnNpdmUgbGlzdCBvZiBjb21tb24gY2FzZXMuICINCj4+Pj4NCj4+Pj4NCj4+ Pj4gSG93ZXZlciwgd2hlbiBsb29raW5nIGF0IHRoaXMgdG9nZXRoZXIgd2l0aA0KPj4+PiBOZXR3 b3JrIFNlcnZpY2UgSGVhZGVyDQo+Pj4+IGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQNCj4+Pj4g aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2ZjLW5zaC0wNA0KPj4+Pg0K Pj4+PiAzLjMuICBTZXJ2aWNlIFBhdGggSGVhZGVyDQo+Pj4+DQo+Pj4+ICINCj4+Pj4gICAgU2Vy dmljZSBQYXRoIElkZW50aWZpZXIgKFNQSSk6IGlkZW50aWZpZXMgYSBzZXJ2aWNlIHBhdGguDQo+ Pj4+ICAgIFBhcnRpY2lwYXRpbmcgbm9kZXMgTVVTVCB1c2UgdGhpcyBpZGVudGlmaWVyIGZvciBT ZXJ2aWNlIEZ1bmN0aW9uDQo+Pj4+ICAgIFBhdGggc2VsZWN0aW9uLg0KPj4+PiAiDQo+Pj4+DQo+ Pj4+IHRoZXJlIGlzIG5vIG5vdGlvbiBvZiBzeW1tZXRyeS4NCj4+Pj4NCj4+Pj4NCj4+Pj4gQ2Fu IHlvdSBwbGVhc2UgY29uZmlybSB0aGF0IGEgYmlkaXJlY3Rpb25hbCBTZXJ2aWNlIEZ1bmN0aW9u IENoYWluDQo+Pj4+IHdpbGwgYmUgcmVwcmVzZW50ZWQgYnkgb25lIHNpbmdsZSBTZXJ2aWNlIFBh dGggSWRlbnRpZmllciwgaW5ncmVzcw0KPj4+PiBzeW1tZXRyaWMgdG8gZWdyZXNzID8NCj4+Pj4N Cj4+Pj4NCj4+Pj4gUGxlYXNlIGFsbG93IHVzIHRvIGNsYXJpZnkgdGhpcy4NCj4+Pj4NCj4+Pj4g TWFueSBUaGFua3MNCj4+Pj4NCj4+Pj4gQ2hyaXN0aWFuIEtvZW5uaW5nDQo+Pj4+IC0tDQo+Pj4+ IEY1IE5ldHdvcmtzIEluYy4NCj4+Pj4gY2hyaXN0aWFuQGY1LmNvbQ0KPj4+Pg0KPj4+Pg0KPj4+ Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+Pg0K From nobody Tue May 17 13:51:10 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCD412D1B7 for ; Tue, 17 May 2016 13:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 Z_PfTNXooUbE for ; Tue, 17 May 2016 13:51:06 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 BBCC612DA0F for ; Tue, 17 May 2016 13:50:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id A42112663D9; Tue, 17 May 2016 13:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1463518258; bh=wrr/D89hw21fzxvswROTY027ojvww7gnboJuGf5Eflc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=KGVLK+PWyk75xlrl6Ut2VcrV6Cbm3lr9hxZX5CfKDoagoN041eD9y42oYO55zCdD/ nRdpB2IPMhKd0E59jMAopmKu5fMRtwcV6W9bdRl+Z4nq5BHI1dsL5Ev8u/OxIU+KRH 4XR9p2A/EfVjVUXQmSWDxQaecjSHRbT04zEPu4rQ= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 21F262663A5; Tue, 17 May 2016 13:50:58 -0700 (PDT) To: Christian Koenning , "sfc@ietf.org" References: <708683c2-8c57-41e1-0dc9-153fd09ecdcd@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <4ffc7b1e-b9cd-ea61-58b1-55e93e373768@joelhalpern.com> Date: Tue, 17 May 2016 16:51:08 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] Service Path Identifier (SPI) and symmetry X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 20:51:09 -0000 I do not think that the SFC archtiecture or the NSH mechanisms specify anything about the inter-SFF paths used in the two different directions for a pair of symmetrically correlated Service Function Paths. That said, given that the transports are running between the same two end-points, I would expect that operational practices will result in them using the same kind of transport. For most of the transports we are looking at, it is not clear what it means to ask if they are using the same tunnel. For example, if the transport is native Ethernet, then one direction uses a particular src/dest Ethernet address pari, and the other direction will typically (but not always) use the same addresses in the other order. If we are using VxLAN, in each direction the source UDP port will be random, as that is the way VxLAN works. If we are using LISP, the tunnels are considered to be unidirectional. Yours, Joel On 5/17/16 4:45 PM, Christian Koenning wrote: > > Thanks Joel, > > thanks for confirming flow correlation (L4) is expected as usual, even > with ingress and egress on two different Service Path IDs. The question > of overloading address space tried to clarify the (rare) the situation where > 2 endpoint pairs have the same addresses and have agreed on the same > src/dst port/protocol, which leads to flow collisions. > > You mention that Service Path ID will now allow to reuse- /duplication. > > However, you mentioned that metadata will provide address reuse- / > duplication. Therefore the flow correlation would need to happen on > including the metadata as part of the tuple as well. > > Also, allow me to ask if we expect ingress and egress Service Path IDs > on the same transport/tunnel ? > > Many Thanks > > Christian Koenning > -- > F5 Networks Inc. > christian@f5.com > > > > > > > On 17/05/2016, 21:07, "Joel M. Halpern" wrote: > >> Correlation of packets in two directions for an SF which works seems to >> require that the SF know how to correlate packets. Id does not need to >> look at the SPI for that, since SPI are coarser than flow. It may need >> to look at metadata (such as subscriber identity) if the SF is inside a >> domain where IP addresses are reused (NAT being a service function >> itself, so one could be on the reuse side of a NAT.) >> >> I am not sure what you are referring to by address namespaces. SPIs do >> not segregate subscribers, nor are they qualifiers for disambiguating >> addresses where NAT is in use. Metadata in the packet is used for such >> disambiguation. So, in the presence of suitable metadata, SFC and NSH >> support inner (subscriber) address reuse / duplication. NAT is an >> envisioned service function. Just don't try to use the SPI as the key. >> It won't tell you what you need. >> >> Yours, >> Joel >> >> On 5/17/16 4:02 PM, Christian Koenning wrote: >>> Thanks Joel, >>> >>> that is where I was getting confused. >>> >>> When looking e.g. at a stateful Service Function (SF), there needs to be >>> an instruction which two of the Service Path Identifiers co-releate in >>> order to establish state. >>> >>> >>> Further to that, could you define if Service Path Identifiers allows for >>> overloading of address namespace? >>> >>> Please allow us to clarify this. >>> >>> Many Thanks >>> >>> Christian Koenning >>> -- >>> F5 Networks Inc. >>> christian@f5.com >>> >>> >>> >>> >>> >>> >>> On 17/05/2016, 20:57, "Joel M. Halpern" wrote: >>> >>>> Most of us have assumed that a bi-directional symmetric path pair is set >>>> up by control, and has separate Service Path IDs (and indicies) in each >>>> direction. This does lead to a need for service functions which >>>> originate reverse direction packets to have a means to get the correct >>>> SPI / Index in place for those packets. There are drafts discussing >>>> approaches to that question. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 5/17/16 3:49 PM, Christian Koenning wrote: >>>>> Good Evening, >>>>> >>>>> looking at RFC 7665 >>>>> Service Function Chaining (SFC) Architecture >>>>> https://tools.ietf.org/html/rfc7665 >>>>> >>>>> there is a clear definition of chain symetry >>>>> >>>>> " >>>>> 2.2. Service Function Chain Symmetry >>>>> >>>>> SFCs may be unidirectional or bidirectional. A unidirectional SFC >>>>> requires that traffic be forwarded through the ordered SFs in one >>>>> direction (sf1 -> sf2 -> sf3), whereas a bidirectional SFC requires a >>>>> symmetric path (sf1 -> sf2 -> sf3 and sf3 -> sf2 -> sf1), and in >>>>> which the SF instances are the same in opposite directions. A hybrid >>>>> SFC has attributes of both unidirectional and bidirectional SFCs; >>>>> that is to say some SFs require symmetric traffic, whereas other SFs >>>>> do not process reverse traffic or are independent of the >>>>> corresponding forward traffic. >>>>> >>>>> ... >>>>> >>>>> Further, there are state trade-offs in symmetry. Symmetry may be >>>>> realized in several ways depending on the SFF and classifier >>>>> functionality. In some cases, "mirrored" classification (i.e., from >>>>> Source to Destination and from Destination to Source) policy may be >>>>> deployed, whereas in others shared state between classifiers may be >>>>> used to ensure that symmetric flows are correctly identified, then >>>>> steered along the required SFP. At a high level, there are various >>>>> common cases. In a non-exhaustive way, there can be for example: >>>>> >>>>> o A single classifier (or a small number of classifiers), in which >>>>> case both incoming and outgoing flows could be recognized at the >>>>> same classifier, so the synchronization would be feasible by >>>>> internal mechanisms internal to the classifier. >>>>> >>>>> o Stateful classifiers where several classifiers may be clustered >>>>> and share state. >>>>> >>>>> o Fully distributed classifiers, where synchronization needs to be >>>>> provided through unspecified means. >>>>> >>>>> o A classifier that learns state from the egress packets/flows that >>>>> is then used to provide state for the return packets/flow. >>>>> >>>>> o Symmetry may also be provided by stateful forwarding logic in the >>>>> SFF in some implementations. >>>>> >>>>> This is a non-comprehensive list of common cases. " >>>>> >>>>> >>>>> However, when looking at this together with >>>>> Network Service Header >>>>> draft-ietf-sfc-nsh-04.txt >>>>> https://tools.ietf.org/html/draft-ietf-sfc-nsh-04 >>>>> >>>>> 3.3. Service Path Header >>>>> >>>>> " >>>>> Service Path Identifier (SPI): identifies a service path. >>>>> Participating nodes MUST use this identifier for Service Function >>>>> Path selection. >>>>> " >>>>> >>>>> there is no notion of symmetry. >>>>> >>>>> >>>>> Can you please confirm that a bidirectional Service Function Chain >>>>> will be represented by one single Service Path Identifier, ingress >>>>> symmetric to egress ? >>>>> >>>>> >>>>> Please allow us to clarify this. >>>>> >>>>> Many Thanks >>>>> >>>>> Christian Koenning >>>>> -- >>>>> F5 Networks Inc. >>>>> christian@f5.com >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> From nobody Tue May 17 14:02:45 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA69412DA09 for ; Tue, 17 May 2016 14:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.447 X-Spam-Level: X-Spam-Status: No, score=-8.447 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=f5.com 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 DvYXFoQywzyW for ; Tue, 17 May 2016 14:02:41 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDD4212DA07 for ; Tue, 17 May 2016 14:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1463518961; x=1495054961; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QheYdjCGlChA9CspjlGJ6KHtcPC9aZ1WA9aPnLzI+NU=; b=GSzrjNvSXwLtvK4kZtTnhqebqSYvqhd1N6HFqObMbZvCKd3EVIIUsZYo +qTY6UfySvaR2ggTBLpkbUgCXpFog0mCidUPsUOvERGJnl93bbG6d+bP5 pb3gPMnpffPWUfE827HTV8/y2Wk4/PD80/l1V17yy+bGFcjdsmaNgr+yF M=; X-IronPort-AV: E=Sophos;i="5.26,325,1459814400"; d="scan'208";a="219476185" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 17 May 2016 21:02:40 +0000 Received: from SEAEXCHMBX04.olympus.F5Net.com (192.168.15.226) by seaexchmbx03.olympus.F5Net.com (192.168.15.225) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 17 May 2016 14:02:40 -0700 Received: from SEAEXCHMBX04.olympus.F5Net.com ([fe80::856e:99ba:ff8b:b756]) by SEAEXCHMBX04.olympus.F5Net.com ([fe80::856e:99ba:ff8b:b756%21]) with mapi id 15.00.1178.000; Tue, 17 May 2016 14:02:40 -0700 From: Christian Koenning To: "Joel M. Halpern" Thread-Topic: [sfc] Service Path Identifier (SPI) and symmetry Thread-Index: AQHRsHUtFvsY0ydaV0iEs6canF5mkp++ASSAgAASbwD///A3AIAAG7uA///wlQD//43gnQ== Date: Tue, 17 May 2016 21:02:39 +0000 Message-ID: <00D7FD5C-2F8A-4D21-AC12-C560E106704D@F5.com> References: <708683c2-8c57-41e1-0dc9-153fd09ecdcd@joelhalpern.com> , <4ffc7b1e-b9cd-ea61-58b1-55e93e373768@joelhalpern.com> In-Reply-To: <4ffc7b1e-b9cd-ea61-58b1-55e93e373768@joelhalpern.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Service Path Identifier (SPI) and symmetry X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 21:02:43 -0000 Thanks for the quick reply.=20 Specifically for VXLAN-GPE, will the co-relating SPI be using the same VXLA= N Segment ID/VXLAN Network Identifier (VNI)?=20 Sorry for the broad question, i realise that i rather should go into the de= tail directly. Many Thanks, Christian > On 17 May 2016, at 21:51, Joel M. Halpern wrote: >=20 > I do not think that the SFC archtiecture or the NSH mechanisms specify a= nything about the inter-SFF paths used in the two different directions for = a pair of symmetrically correlated Service Function Paths. >=20 > That said, given that the transports are running between the same two end= -points, I would expect that operational practices will result in them usin= g the same kind of transport. >=20 > For most of the transports we are looking at, it is not clear what it mea= ns to ask if they are using the same tunnel. For example, if the transport= is native Ethernet, then one direction uses a particular src/dest Ethernet= address pari, and the other direction will typically (but not always) use = the same addresses in the other order. If we are using VxLAN, in each dire= ction the source UDP port will be random, as that is the way VxLAN works. = If we are using LISP, the tunnels are considered to be unidirectional. >=20 > Yours, > Joel >=20 >> On 5/17/16 4:45 PM, Christian Koenning wrote: >>=20 >> Thanks Joel, >>=20 >> thanks for confirming flow correlation (L4) is expected as usual, even >> with ingress and egress on two different Service Path IDs. The question >> of overloading address space tried to clarify the (rare) the situation w= here >> 2 endpoint pairs have the same addresses and have agreed on the same >> src/dst port/protocol, which leads to flow collisions. >>=20 >> You mention that Service Path ID will now allow to reuse- /duplication. >>=20 >> However, you mentioned that metadata will provide address reuse- / >> duplication. Therefore the flow correlation would need to happen on >> including the metadata as part of the tuple as well. >>=20 >> Also, allow me to ask if we expect ingress and egress Service Path IDs >> on the same transport/tunnel ? >>=20 >> Many Thanks >>=20 >> Christian Koenning >> -- >> F5 Networks Inc. >> christian@f5.com >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>> On 17/05/2016, 21:07, "Joel M. Halpern" wrote: >>>=20 >>> Correlation of packets in two directions for an SF which works seems to >>> require that the SF know how to correlate packets. Id does not need to >>> look at the SPI for that, since SPI are coarser than flow. It may need >>> to look at metadata (such as subscriber identity) if the SF is inside a >>> domain where IP addresses are reused (NAT being a service function >>> itself, so one could be on the reuse side of a NAT.) >>>=20 >>> I am not sure what you are referring to by address namespaces. SPIs do >>> not segregate subscribers, nor are they qualifiers for disambiguating >>> addresses where NAT is in use. Metadata in the packet is used for such >>> disambiguation. So, in the presence of suitable metadata, SFC and NSH >>> support inner (subscriber) address reuse / duplication. NAT is an >>> envisioned service function. Just don't try to use the SPI as the key. >>> It won't tell you what you need. >>>=20 >>> Yours, >>> Joel >>>=20 >>>> On 5/17/16 4:02 PM, Christian Koenning wrote: >>>> Thanks Joel, >>>>=20 >>>> that is where I was getting confused. >>>>=20 >>>> When looking e.g. at a stateful Service Function (SF), there needs to = be >>>> an instruction which two of the Service Path Identifiers co-releate in >>>> order to establish state. >>>>=20 >>>>=20 >>>> Further to that, could you define if Service Path Identifiers allows f= or >>>> overloading of address namespace? >>>>=20 >>>> Please allow us to clarify this. >>>>=20 >>>> Many Thanks >>>>=20 >>>> Christian Koenning >>>> -- >>>> F5 Networks Inc. >>>> christian@f5.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> On 17/05/2016, 20:57, "Joel M. Halpern" wrote: >>>>>=20 >>>>> Most of us have assumed that a bi-directional symmetric path pair is = set >>>>> up by control, and has separate Service Path IDs (and indicies) in ea= ch >>>>> direction. This does lead to a need for service functions which >>>>> originate reverse direction packets to have a means to get the correc= t >>>>> SPI / Index in place for those packets. There are drafts discussing >>>>> approaches to that question. >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>>> On 5/17/16 3:49 PM, Christian Koenning wrote: >>>>>> Good Evening, >>>>>>=20 >>>>>> looking at RFC 7665 >>>>>> Service Function Chaining (SFC) Architecture >>>>>> https://tools.ietf.org/html/rfc7665 >>>>>>=20 >>>>>> there is a clear definition of chain symetry >>>>>>=20 >>>>>> " >>>>>> 2.2. Service Function Chain Symmetry >>>>>>=20 >>>>>> SFCs may be unidirectional or bidirectional. A unidirectional SFC >>>>>> requires that traffic be forwarded through the ordered SFs in one >>>>>> direction (sf1 -> sf2 -> sf3), whereas a bidirectional SFC require= s a >>>>>> symmetric path (sf1 -> sf2 -> sf3 and sf3 -> sf2 -> sf1), and in >>>>>> which the SF instances are the same in opposite directions. A hyb= rid >>>>>> SFC has attributes of both unidirectional and bidirectional SFCs; >>>>>> that is to say some SFs require symmetric traffic, whereas other S= Fs >>>>>> do not process reverse traffic or are independent of the >>>>>> corresponding forward traffic. >>>>>>=20 >>>>>> ... >>>>>>=20 >>>>>> Further, there are state trade-offs in symmetry. Symmetry may be >>>>>> realized in several ways depending on the SFF and classifier >>>>>> functionality. In some cases, "mirrored" classification (i.e., fr= om >>>>>> Source to Destination and from Destination to Source) policy may b= e >>>>>> deployed, whereas in others shared state between classifiers may b= e >>>>>> used to ensure that symmetric flows are correctly identified, then >>>>>> steered along the required SFP. At a high level, there are variou= s >>>>>> common cases. In a non-exhaustive way, there can be for example: >>>>>>=20 >>>>>> o A single classifier (or a small number of classifiers), in whic= h >>>>>> case both incoming and outgoing flows could be recognized at th= e >>>>>> same classifier, so the synchronization would be feasible by >>>>>> internal mechanisms internal to the classifier. >>>>>>=20 >>>>>> o Stateful classifiers where several classifiers may be clustered >>>>>> and share state. >>>>>>=20 >>>>>> o Fully distributed classifiers, where synchronization needs to b= e >>>>>> provided through unspecified means. >>>>>>=20 >>>>>> o A classifier that learns state from the egress packets/flows th= at >>>>>> is then used to provide state for the return packets/flow. >>>>>>=20 >>>>>> o Symmetry may also be provided by stateful forwarding logic in t= he >>>>>> SFF in some implementations. >>>>>>=20 >>>>>> This is a non-comprehensive list of common cases. " >>>>>>=20 >>>>>>=20 >>>>>> However, when looking at this together with >>>>>> Network Service Header >>>>>> draft-ietf-sfc-nsh-04.txt >>>>>> https://tools.ietf.org/html/draft-ietf-sfc-nsh-04 >>>>>>=20 >>>>>> 3.3. Service Path Header >>>>>>=20 >>>>>> " >>>>>> Service Path Identifier (SPI): identifies a service path. >>>>>> Participating nodes MUST use this identifier for Service Function >>>>>> Path selection. >>>>>> " >>>>>>=20 >>>>>> there is no notion of symmetry. >>>>>>=20 >>>>>>=20 >>>>>> Can you please confirm that a bidirectional Service Function Chain >>>>>> will be represented by one single Service Path Identifier, ingress >>>>>> symmetric to egress ? >>>>>>=20 >>>>>>=20 >>>>>> Please allow us to clarify this. >>>>>>=20 >>>>>> Many Thanks >>>>>>=20 >>>>>> Christian Koenning >>>>>> -- >>>>>> F5 Networks Inc. >>>>>> christian@f5.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>=20 From nobody Tue May 17 14:12:12 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B4312D523 for ; Tue, 17 May 2016 14:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 bJ9QChGjbxuX for ; Tue, 17 May 2016 14:12:09 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 6A73C12D1DF for ; Tue, 17 May 2016 14:12:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4BCEC26645C; Tue, 17 May 2016 14:12:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1463519529; bh=YGU4Kxo1ygsu9fHHY00EkICKDt6RZ9LY77gLmOyITWY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Z+YMdjB5paEYB4pup0mHQf9YNgXJIGkTl3bisY2+vIvlnTKfK2EAByxDwWo0Czvyh tM3COTXiJcKb4yLryO5Um6z13zOPUTqzvrMNZ72Hn0URzUdIOBl+RSw9IeC81iTqwx a4PZDnFdCpnbsh/SEz8vQk7PIoxhh53kD211uK0o= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id BC5A3266461; Tue, 17 May 2016 14:12:08 -0700 (PDT) To: Christian Koenning References: <708683c2-8c57-41e1-0dc9-153fd09ecdcd@joelhalpern.com> <4ffc7b1e-b9cd-ea61-58b1-55e93e373768@joelhalpern.com> <00D7FD5C-2F8A-4D21-AC12-C560E106704D@F5.com> From: "Joel M. Halpern" Message-ID: <6737272c-dbbc-f985-1c9a-7dd93b99659a@joelhalpern.com> Date: Tue, 17 May 2016 17:12:18 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <00D7FD5C-2F8A-4D21-AC12-C560E106704D@F5.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Service Path Identifier (SPI) and symmetry X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 21:12:11 -0000 Neither NSH nor SFC Architecture would force the same VNI to be used in each direction for the paired SFPs. I would not assume that in my SFF design. Hwoe3ver, it would seem a very good practice, and something I would expect control to do. This does get back to your earlier, welltaken, question about where teh SFF gets the VNI to put into the VxLAN header. One approach is to declare that all of service chaining is a single VNI, and so it is an SFF-wide configuration parameter. Another approach is that specific portions use specific VNI, which would lead to wanting the VNI configured in the SPI mapping table. It seems to depend upon where the VTEP is understood to be. I think we need to allow both cases. It should be remembered that the table entries in the NSH draft are exemplars, not specification. The NSH draft does not standardize the transport mappings. (And the WG charter makes appears to make it out of scope for the WG.) So I am not sure where the question of interoperable VNI use for VxLAN transport can be answered. (And VLAN use for Ethernet Transport.) Yours, Joel On 5/17/16 5:02 PM, Christian Koenning wrote: > Thanks for the quick reply. > > Specifically for VXLAN-GPE, will the co-relating SPI be using the > same VXLAN Segment ID/VXLAN Network Identifier (VNI)? > > Sorry for the broad question, i realise that i rather should go into > the detail directly. > > > Many Thanks, > > Christian > > > > >> On 17 May 2016, at 21:51, Joel M. Halpern >> wrote: >> >> I do not think that the SFC archtiecture or the NSH mechanisms >> specify anything about the inter-SFF paths used in the two >> different directions for a pair of symmetrically correlated Service >> Function Paths. >> >> That said, given that the transports are running between the same >> two end-points, I would expect that operational practices will >> result in them using the same kind of transport. >> >> For most of the transports we are looking at, it is not clear what >> it means to ask if they are using the same tunnel. For example, if >> the transport is native Ethernet, then one direction uses a >> particular src/dest Ethernet address pari, and the other direction >> will typically (but not always) use the same addresses in the other >> order. If we are using VxLAN, in each direction the source UDP >> port will be random, as that is the way VxLAN works. If we are >> using LISP, the tunnels are considered to be unidirectional. >> >> Yours, Joel >> >>> On 5/17/16 4:45 PM, Christian Koenning wrote: >>> >>> Thanks Joel, >>> >>> thanks for confirming flow correlation (L4) is expected as usual, >>> even with ingress and egress on two different Service Path IDs. >>> The question of overloading address space tried to clarify the >>> (rare) the situation where 2 endpoint pairs have the same >>> addresses and have agreed on the same src/dst port/protocol, >>> which leads to flow collisions. >>> >>> You mention that Service Path ID will now allow to reuse- >>> /duplication. >>> >>> However, you mentioned that metadata will provide address reuse- >>> / duplication. Therefore the flow correlation would need to >>> happen on including the metadata as part of the tuple as well. >>> >>> Also, allow me to ask if we expect ingress and egress Service >>> Path IDs on the same transport/tunnel ? >>> >>> Many Thanks >>> >>> Christian Koenning -- F5 Networks Inc. christian@f5.com >>> >>> >>> >>> >>> >>> >>>> On 17/05/2016, 21:07, "Joel M. Halpern" >>>> wrote: >>>> >>>> Correlation of packets in two directions for an SF which works >>>> seems to require that the SF know how to correlate packets. Id >>>> does not need to look at the SPI for that, since SPI are >>>> coarser than flow. It may need to look at metadata (such as >>>> subscriber identity) if the SF is inside a domain where IP >>>> addresses are reused (NAT being a service function itself, so >>>> one could be on the reuse side of a NAT.) >>>> >>>> I am not sure what you are referring to by address namespaces. >>>> SPIs do not segregate subscribers, nor are they qualifiers for >>>> disambiguating addresses where NAT is in use. Metadata in the >>>> packet is used for such disambiguation. So, in the presence of >>>> suitable metadata, SFC and NSH support inner (subscriber) >>>> address reuse / duplication. NAT is an envisioned service >>>> function. Just don't try to use the SPI as the key. It won't >>>> tell you what you need. >>>> >>>> Yours, Joel >>>> >>>>> On 5/17/16 4:02 PM, Christian Koenning wrote: Thanks Joel, >>>>> >>>>> that is where I was getting confused. >>>>> >>>>> When looking e.g. at a stateful Service Function (SF), there >>>>> needs to be an instruction which two of the Service Path >>>>> Identifiers co-releate in order to establish state. >>>>> >>>>> >>>>> Further to that, could you define if Service Path Identifiers >>>>> allows for overloading of address namespace? >>>>> >>>>> Please allow us to clarify this. >>>>> >>>>> Many Thanks >>>>> >>>>> Christian Koenning -- F5 Networks Inc. christian@f5.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> On 17/05/2016, 20:57, "Joel M. Halpern" >>>>>> wrote: >>>>>> >>>>>> Most of us have assumed that a bi-directional symmetric >>>>>> path pair is set up by control, and has separate Service >>>>>> Path IDs (and indicies) in each direction. This does lead >>>>>> to a need for service functions which originate reverse >>>>>> direction packets to have a means to get the correct SPI / >>>>>> Index in place for those packets. There are drafts >>>>>> discussing approaches to that question. >>>>>> >>>>>> Yours, Joel >>>>>> >>>>>>> On 5/17/16 3:49 PM, Christian Koenning wrote: Good >>>>>>> Evening, >>>>>>> >>>>>>> looking at RFC 7665 Service Function Chaining (SFC) >>>>>>> Architecture https://tools.ietf.org/html/rfc7665 >>>>>>> >>>>>>> there is a clear definition of chain symetry >>>>>>> >>>>>>> " 2.2. Service Function Chain Symmetry >>>>>>> >>>>>>> SFCs may be unidirectional or bidirectional. A >>>>>>> unidirectional SFC requires that traffic be forwarded >>>>>>> through the ordered SFs in one direction (sf1 -> sf2 -> >>>>>>> sf3), whereas a bidirectional SFC requires a symmetric >>>>>>> path (sf1 -> sf2 -> sf3 and sf3 -> sf2 -> sf1), and in >>>>>>> which the SF instances are the same in opposite >>>>>>> directions. A hybrid SFC has attributes of both >>>>>>> unidirectional and bidirectional SFCs; that is to say >>>>>>> some SFs require symmetric traffic, whereas other SFs do >>>>>>> not process reverse traffic or are independent of the >>>>>>> corresponding forward traffic. >>>>>>> >>>>>>> ... >>>>>>> >>>>>>> Further, there are state trade-offs in symmetry. >>>>>>> Symmetry may be realized in several ways depending on the >>>>>>> SFF and classifier functionality. In some cases, >>>>>>> "mirrored" classification (i.e., from Source to >>>>>>> Destination and from Destination to Source) policy may >>>>>>> be deployed, whereas in others shared state between >>>>>>> classifiers may be used to ensure that symmetric flows >>>>>>> are correctly identified, then steered along the required >>>>>>> SFP. At a high level, there are various common cases. >>>>>>> In a non-exhaustive way, there can be for example: >>>>>>> >>>>>>> o A single classifier (or a small number of >>>>>>> classifiers), in which case both incoming and outgoing >>>>>>> flows could be recognized at the same classifier, so the >>>>>>> synchronization would be feasible by internal mechanisms >>>>>>> internal to the classifier. >>>>>>> >>>>>>> o Stateful classifiers where several classifiers may be >>>>>>> clustered and share state. >>>>>>> >>>>>>> o Fully distributed classifiers, where synchronization >>>>>>> needs to be provided through unspecified means. >>>>>>> >>>>>>> o A classifier that learns state from the egress >>>>>>> packets/flows that is then used to provide state for the >>>>>>> return packets/flow. >>>>>>> >>>>>>> o Symmetry may also be provided by stateful forwarding >>>>>>> logic in the SFF in some implementations. >>>>>>> >>>>>>> This is a non-comprehensive list of common cases. " >>>>>>> >>>>>>> >>>>>>> However, when looking at this together with Network >>>>>>> Service Header draft-ietf-sfc-nsh-04.txt >>>>>>> https://tools.ietf.org/html/draft-ietf-sfc-nsh-04 >>>>>>> >>>>>>> 3.3. Service Path Header >>>>>>> >>>>>>> " Service Path Identifier (SPI): identifies a service >>>>>>> path. Participating nodes MUST use this identifier for >>>>>>> Service Function Path selection. " >>>>>>> >>>>>>> there is no notion of symmetry. >>>>>>> >>>>>>> >>>>>>> Can you please confirm that a bidirectional Service >>>>>>> Function Chain will be represented by one single Service >>>>>>> Path Identifier, ingress symmetric to egress ? >>>>>>> >>>>>>> >>>>>>> Please allow us to clarify this. >>>>>>> >>>>>>> Many Thanks >>>>>>> >>>>>>> Christian Koenning -- F5 Networks Inc. christian@f5.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ sfc >>>>>>> mailing list sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> > From nobody Tue May 17 14:25:40 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6852D12D9D1 for ; Tue, 17 May 2016 14:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 oshZqEXMuz5q for ; Tue, 17 May 2016 14:25:36 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D05FC12DA25 for ; Tue, 17 May 2016 14:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=668; q=dns/txt; s=iport; t=1463520332; x=1464729932; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xtNza6hpiJJEsTeEan4jVCw/wKxQ942PApoIuJTGia4=; b=eD5DFvvKEl1hGmwQbrM+vto/0T21TkvbrTAjZtMlT/GGlzv+EWmDLkFS GQ2/hREnbGfQaQ6Ou0sVpUhSCWOIPYver7RhG7eZEB/guGMMxFNvZIVSs V4y5+tT834vAkguBzKX1fiNGjVDPLpGYHAgG+BWHUjuI4debNbXS64oyR 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALBQDJiztX/4gNJK1dgzeBUwa6AoF1h?= =?us-ascii?q?hECgT05EwEBAQEBAQFlJ4RCAQEBAwE6PwULAgEIDgoeEDIlAgQOBYgnCMM+AQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBHIYlgXYIgk+EPziCc4IuAQSYKQGOHoFTjUaPQ?= =?us-ascii?q?QEiAT+DbW6HB38BAQE?= X-IronPort-AV: E=Sophos;i="5.26,325,1459814400"; d="scan'208";a="273217512" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 May 2016 21:25:32 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u4HLPWCq029555 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 May 2016 21:25:32 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 17 May 2016 16:25:31 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1104.009; Tue, 17 May 2016 16:25:31 -0500 From: "Paul Quinn (paulq)" To: Christian Koenning Thread-Topic: [sfc] Service Path Identifier (SPI) and symmetry Thread-Index: AQHRsHUtFvsY0ydaV0iEs6canF5mkp+9352A//+u2ZiAAF6RAIAAAYwAgAADOICAAAZiAA== Date: Tue, 17 May 2016 21:25:31 +0000 Message-ID: <15109594-0FA7-4934-B1BD-208342C040B9@cisco.com> References: <708683c2-8c57-41e1-0dc9-153fd09ecdcd@joelhalpern.com> <4ffc7b1e-b9cd-ea61-58b1-55e93e373768@joelhalpern.com> <00D7FD5C-2F8A-4D21-AC12-C560E106704D@F5.com> In-Reply-To: <00D7FD5C-2F8A-4D21-AC12-C560E106704D@F5.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.242.233] Content-Type: text/plain; charset="us-ascii" Content-ID: <46AD2CDB09ABBB4A80BCAEBC200E7632@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Service Path Identifier (SPI) and symmetry X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 21:25:38 -0000 Hi Christian, > On May 17, 2016, at 5:02 PM, Christian Koenning wrote= : >=20 > Thanks for the quick reply.=20 >=20 > Specifically for VXLAN-GPE, will the co-relating SPI be using the same VX= LAN Segment ID/VXLAN Network Identifier (VNI)?=20 >=20 The GPE VNI is orthogonal to the NSH information. I expect (and have seen)= two cases: a common shared VNI for the service path, or a per-tenant VNI, = imposed at the SFF(s). > Sorry for the broad question, i realise that i rather should go into the = detail directly. >=20 Not at all, let's keep the discussion going! >=20 > Many Thanks, >=20 > Christian >=20 From nobody Tue May 17 15:20:09 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771CC12DA7E for ; Tue, 17 May 2016 15:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 quzRglYln04h for ; Tue, 17 May 2016 15:20:03 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFCA912DA82 for ; Tue, 17 May 2016 15:20:02 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id x201so48479277oif.3 for ; Tue, 17 May 2016 15:20:02 -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; bh=YQJsR9/vmu8tqP0NHx061v0G0t4+j9KL+e/eVVJayrw=; b=iWb92mJyvAyqSJbFDULXBPGyO/auU8wXmGjf9zH10thVia3IHOEIlX7OylLXIq7qAr vGehH6N4ImKAdrMwDep4t5Y1MB+fE7julN/S6IgTaQ654ZtlB2nLF03ICNhK24CU2Grv VC7jZLvYqlaM4xdkGnkIAHzOjsKnrqa6ceRGq81EajiSiS3GPFGGMLeIyyaJ08q3MIoQ 0lNhiFuBSH656hJ4JQpnLIEgMjFhOlkYjIWDoTLaRAQtWdLceq8AoSVrl35sD3XLJ/nD MQgX1sgs/JLqIbbqy+gVfHmePkdHYCsGptJFg5Zh0GleFMIcsNIL8KXOCNpxRNS1YE5q FOgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YQJsR9/vmu8tqP0NHx061v0G0t4+j9KL+e/eVVJayrw=; b=kUACNx0RCjH8jCPRKREe9x9nXvTKKfDIUPHAYGuhAvWWNPnP/kJXXQukLPnhWXCeqt M9tk6dL1AoXYw1Q9UdMKNspPuU8zQwaqyCoAFBp9MknX+htWLqEyA4D/XSfNTz13X6yj nCguqdC3UjqdVSsCRJLy2ai6a3ViLHQWye8HJS6KNxobzNk97UG5NTVSnQimkOw2hRnw rLcZkk9gYrT2PJPcNymb2Q49vRSNignxPQNsMD8hWmqDs7xQsL09ruwmxn5jZfXMVcjm AtYDZZ9roARgjmz8FtrS1vdJv2B1YiArKrTxK4+TKY8M9g5lY/bWKMAEqlWG7JyBo4vJ eBlA== X-Gm-Message-State: AOPr4FXFRxLceeWtCD4/gz/iBMUrv/KX0IulqVAjCjXG/qDhlHrnEORnwtimvInuX0XQLgHQ53KR7WUQgQr8lA== X-Received: by 10.157.33.85 with SMTP id l21mr2128196otd.61.1463523602262; Tue, 17 May 2016 15:20:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.106 with HTTP; Tue, 17 May 2016 15:19:42 -0700 (PDT) In-Reply-To: References: <20160512064455.15167.2456.idtracker@ietfa.amsl.com> <6a339336-a3df-6044-4c66-7a48b869670f@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F657E9BC5D@dfweml501-mbb> From: "Andrew G. Malis" Date: Tue, 17 May 2016 18:19:42 -0400 Message-ID: To: "Jim Guichard (jguichar)" Content-Type: multipart/alternative; boundary=001a11463b926ef01405331124a1 Archived-At: Cc: Martin Stiemerling , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 22:20:06 -0000 --001a11463b926ef01405331124a1 Content-Type: text/plain; charset=UTF-8 Jim, There are no requirements in section 4.10.4, or indeed in section 4.10 at all. There's no use of "required", "requirement", or "MUST" (although there is a "not required" in one place). Cheers, Andy On Tue, May 17, 2016 at 1:32 PM, Jim Guichard (jguichar) wrote: > Hi Linda, > > See my response to Med. If you want to use other criteria above and beyond > the documented SFC encapsulation then that is an implementation choice not > a requirement within the control plane specification. > > Jim > > On 5/17/16, 11:44 AM, "Linda Dunbar" wrote: > > >Jim, > > > >Why "calling for a single SFC encapsulation" conflicts with SFC control > >plane sending request (via out of bound) to steer NSH encapsulated > >packets based on some criteria (e.g. port, or time stamp, or others)? > > > >For example, when detecting a port status problem (from scheduling or > >monitoring), can SFC control plane be allowed to ask the forwarding > >devices to steer traffic to different port (based on its specific > >criteria)? > > > >Just curious, > > > >Linda > > > >-----Original Message----- > >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard > >(jguichar) > >Sent: Saturday, May 14, 2016 12:48 PM > >To: Martin Stiemerling; sfc@ietf.org > >Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt > > > >I would like to see my comments addressed for section 4.10.4. > > > >Our charter calls for a single SFC encapsulation and that is being > >documented in draft-ietf-sfc-nsh. The text within this section suggests > >that forwarding can be enabled using an SFP-id and some other condition > >such as input port etc. This is inaccurate based upon the SFC > >encapsulation as well as our WG charter. There is no mention of the SFC > >encapsulation or the fact that the NSH base header is the method used for > >forwarding; note that the most common forwarding method (and the one > >implemented in several places) is SFP-id + index - this is not even > >mentioned!. In addition, this is a control plane document; there is no > >need to talk about forwarding other than point to the SFC encapsulation > >document. > > > >For these reasons I would like to see this section removed from the > >document. > > > >Jim > > > > > >On 5/14/16, 5:28 AM, "sfc on behalf of Martin Stiemerling" > > wrote: > > > >>Dear all, > >> > >>The authors have posted an updated version addressing the reviews out > >>of the WGLC. > >> > >>Please check until May 20th 5pm CEST if your comments have been > >>addressed. > >> > >>Thanks, > >> > >> Martin > >> > >>Am 12.05.16 um 08:44 schrieb internet-drafts@ietf.org: > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >>>directories. > >>> This draft is a work item of the Service Function Chaining of the IETF. > >>> > >>> Title : Service Function Chaining (SFC) Control Plane > >>>Components & Requirements > >>> Author : Mohamed Boucadair > >>> Filename : draft-ietf-sfc-control-plane-05.txt > >>> Pages : 27 > >>> Date : 2016-05-11 > >>> > >>> Abstract: > >>> This document describes requirements for conveying information > >>> between Service Function Chaining (SFC) control elements and SFC > >>>data > >>> plane functional elements. Also, this document identifies a set of > >>> control interfaces to interact with SFC-aware elements to establish, > >>> maintain or recover service function chains. This document does not > >>> specify protocols nor extensions to existing protocols. > >>> > >>> This document exclusively focuses on SFC deployments that are under > >>> the responsibility of a single administrative entity. Inter-domain > >>> considerations are out of scope. > >>> > >>> > >>> The IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ > >>> > >>> There's also a htmlized version available at: > >>> https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05 > >>> > >>> A diff from the previous version is available at: > >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-control-plane-05 > >>> > >>> > >>> 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/ > >>> > >>> _______________________________________________ > >>> I-D-Announce mailing list > >>> I-D-Announce@ietf.org > >>> https://www.ietf.org/mailman/listinfo/i-d-announce > >>> Internet-Draft directories: http://www.ietf.org/shadow.html or > >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>> > >> > >>_______________________________________________ > >>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 > --001a11463b926ef01405331124a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jim,

There are no requirements in secti= on 4.10.4, or indeed in section 4.10 at all. There's no use of "re= quired", "requirement", or "MUST" (although there = is a "not required" in one place).

Cheer= s,
Andy

On Tue, May 17, 2016 at 1:32 PM, Jim Guichard (jguichar) <jgu= ichar@cisco.com> wrote:
Hi = Linda,

See my response to Med. If you want to use other criteria above and beyond<= br> the documented SFC encapsulation then that is an implementation choice not<= br> a requirement within the control plane specification.

Jim

On 5/17/16, 11:44 AM, "Linda Dunbar" <linda.dunbar@huawei.com> wrote:

>Jim,
>
>Why "calling for a single SFC encapsulation" conflicts with S= FC control
>plane sending request (via out of bound) to steer NSH encapsulated
>packets based on some criteria (e.g. port, or time stamp, or others)? >
>For example, when detecting a port status problem (from scheduling or >monitoring),=C2=A0 can SFC control plane be allowed to ask the forwardi= ng
>devices to steer traffic to different port (based on its specific
>criteria)?
>
>Just curious,
>
>Linda
>
>-----Original Message-----
>From: sfc [mailto:sfc-bounces@i= etf.org] On Behalf Of Jim Guichard
>(jguichar)
>Sent: Saturday, May 14, 2016 12:48 PM
>To: Martin Stiemerling; sfc@ietf.org
>Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt
>
>I would like to see my comments addressed for section 4.10.4.
>
>Our charter calls for a single SFC encapsulation and that is being
>documented in draft-ietf-sfc-nsh. The text within this section suggests=
>that forwarding can be enabled using an SFP-id and some other condition=
>such as input port etc. This is inaccurate based upon the SFC
>encapsulation as well as our WG charter. There is no mention of the SFC=
>encapsulation or the fact that the NSH base header is the method used f= or
>forwarding; note that the most common forwarding method (and the one >implemented in several places) is SFP-id + index - this is not even
>mentioned!. In addition, this is a control plane document; there is no<= br> >need to talk about forwarding other than point to the SFC encapsulation=
>document.
>
>For these reasons I would like to see this section removed from the
>document.
>
>Jim
>
>
>On 5/14/16, 5:28 AM, "sfc on behalf of Martin Stiemerling" ><sfc-bounces@ietf.org on= behalf of mls.ietf@gmail.com>= wrote:
>
>>Dear all,
>>
>>The authors have posted an updated version addressing the reviews o= ut
>>of the WGLC.
>>
>>Please check until May 20th 5pm CEST if your comments have been
>>addressed.
>>
>>Thanks,
>>
>>=C2=A0 =C2=A0 Martin
>>
>>Am 12.05.16 um 08:44 schrieb internet-drafts@ietf.org:
>>>
>>> A New Internet-Draft is available from the on-line Internet-Dr= afts
>>>directories.
>>> This draft is a work item of the Service Function Chaining of = the IETF.
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0: Service Function Chaining (SFC) Control Plane
>>>Components & Requirements
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 : Mohamed Boucadair
>>>=C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft= -ietf-sfc-control-plane-05.txt
>>>=C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 27
>>>=C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2016-05-11
>>>
>>> Abstract:
>>>=C2=A0 =C2=A0 This document describes requirements for conveyin= g information
>>>=C2=A0 =C2=A0 between Service Function Chaining (SFC) control e= lements and SFC
>>>data
>>>=C2=A0 =C2=A0 plane functional elements.=C2=A0 Also, this docum= ent identifies a set of
>>>=C2=A0 =C2=A0 control interfaces to interact with SFC-aware ele= ments to establish,
>>>=C2=A0 =C2=A0 maintain or recover service function chains.=C2= =A0 This document does not
>>>=C2=A0 =C2=A0 specify protocols nor extensions to existing prot= ocols.
>>>
>>>=C2=A0 =C2=A0 This document exclusively focuses on SFC deployme= nts that are under
>>>=C2=A0 =C2=A0 the responsibility of a single administrative ent= ity.=C2=A0 Inter-domain
>>>=C2=A0 =C2=A0 considerations are out of scope.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.= org/doc/draft-ietf-sfc-control-plane/
>>>
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/= draft-ietf-sfc-control-plane-05
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org= /rfcdiff?url2=3Ddraft-ietf-sfc-control-plane-05
>>>
>>>
>>> Please note that it may take a couple of minutes from the time= of
>>>submission=C2=A0 until the htmlized version and diff are availa= ble at
>>>tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> I-D-Announce@ietf.org=
>>> https://www.ietf.org/mailman/listinfo= /i-d-announce
>>> Internet-Draft directories: http://www.ietf.org/shadow.h= tml or
>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt<= br> >>>
>>
>>_______________________________________________
>>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

--001a11463b926ef01405331124a1-- From nobody Tue May 17 15:28:58 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E0812DAB3 for ; Tue, 17 May 2016 15:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.447 X-Spam-Level: X-Spam-Status: No, score=-8.447 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=f5.com 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 2-BD3qaxMAWs for ; Tue, 17 May 2016 15:28:54 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1A2812D882 for ; Tue, 17 May 2016 15:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1463524135; x=1495060135; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zYadn8zCP1kDXrJtoK3A/8ZRi8Hmtg50DHNiLY9ExBk=; b=r5HmrHS+1CqaxA2sF2ctASMVjXkzQSUxu5cGyG/xysV2TChYhLI1qpEP NcXBu7XwBAZs28bnUQeX2ChGHdE7cszWmr0d1yZmkSch4VTMNn8dcCzOH Y7GVuUPrqJbu7K/Q3kWwkKjHPP2WFON9hNmZy4iJ4wh6EwG5XEiP598U6 w=; X-IronPort-AV: E=Sophos;i="5.26,325,1459814400"; d="scan'208";a="219491023" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 17 May 2016 22:28:54 +0000 Received: from SEAEXCHMBX04.olympus.F5Net.com (192.168.15.226) by seaexchmbx02.olympus.F5Net.com (192.168.15.224) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 17 May 2016 15:28:53 -0700 Received: from SEAEXCHMBX04.olympus.F5Net.com ([fe80::856e:99ba:ff8b:b756]) by SEAEXCHMBX04.olympus.F5Net.com ([fe80::856e:99ba:ff8b:b756%21]) with mapi id 15.00.1178.000; Tue, 17 May 2016 15:28:53 -0700 From: Christian Koenning To: "Joel M. Halpern" Thread-Topic: [sfc] Service Path Identifier (SPI) and symmetry Thread-Index: AQHRsHUtFvsY0ydaV0iEs6canF5mkp++ASSAgAASbwD///A3AIAAG7uA///wlQD//43gnQAPAVIAAATLtIA= Date: Tue, 17 May 2016 22:28:52 +0000 Message-ID: References: <708683c2-8c57-41e1-0dc9-153fd09ecdcd@joelhalpern.com> <4ffc7b1e-b9cd-ea61-58b1-55e93e373768@joelhalpern.com> <00D7FD5C-2F8A-4D21-AC12-C560E106704D@F5.com> <6737272c-dbbc-f985-1c9a-7dd93b99659a@joelhalpern.com> In-Reply-To: <6737272c-dbbc-f985-1c9a-7dd93b99659a@joelhalpern.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="utf-8" Content-ID: <0D0F7A8D4C54E94992605C9447B91910@F5.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Service Path Identifier (SPI) and symmetry X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 22:28:56 -0000 VGhhbmtzIEpvZWwsDQoNCldvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIGFkZCBhbGwgdGhpcyBjbGFy aWZpY2F0aW9uIGludG8gdGhlIGRyYWZ0ID8NCkl0IHdpbGwgcmVtb3ZlIHRoZSBhbWJpZ3VpdHku DQoNCg0KTWFueSBUaGFua3MNCkNocmlzdGlhbg0KDQoNCg0KDQoNCk9uIDE3LzA1LzIwMTYsIDIy OjEyLCAic2ZjIG9uIGJlaGFsZiBvZiBKb2VsIE0uIEhhbHBlcm4iIDxzZmMtYm91bmNlc0BpZXRm Lm9yZyBvbiBiZWhhbGYgb2Ygam1oQGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6DQoNCj5OZWl0aGVy IE5TSCBub3IgU0ZDIEFyY2hpdGVjdHVyZSB3b3VsZCBmb3JjZSB0aGUgc2FtZSBWTkkgdG8gYmUg dXNlZCBpbiANCj5lYWNoIGRpcmVjdGlvbiBmb3IgdGhlIHBhaXJlZCBTRlBzLiAgSSB3b3VsZCBu b3QgYXNzdW1lIHRoYXQgaW4gbXkgU0ZGIA0KPmRlc2lnbi4NCj5Id29lM3ZlciwgaXQgd291bGQg c2VlbSBhIHZlcnkgZ29vZCBwcmFjdGljZSwgYW5kIHNvbWV0aGluZyBJIHdvdWxkIA0KPmV4cGVj dCBjb250cm9sIHRvIGRvLg0KPg0KPlRoaXMgZG9lcyBnZXQgYmFjayB0byB5b3VyIGVhcmxpZXIs IHdlbGx0YWtlbiwgcXVlc3Rpb24gYWJvdXQgd2hlcmUgdGVoIA0KPlNGRiBnZXRzIHRoZSBWTkkg dG8gcHV0IGludG8gdGhlIFZ4TEFOIGhlYWRlci4gIE9uZSBhcHByb2FjaCBpcyB0byANCj5kZWNs YXJlIHRoYXQgYWxsIG9mIHNlcnZpY2UgY2hhaW5pbmcgaXMgYSBzaW5nbGUgVk5JLCBhbmQgc28g aXQgaXMgYW4gDQo+U0ZGLXdpZGUgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXIuICBBbm90aGVyIGFw cHJvYWNoIGlzIHRoYXQgc3BlY2lmaWMgDQo+cG9ydGlvbnMgdXNlIHNwZWNpZmljIFZOSSwgd2hp Y2ggd291bGQgbGVhZCB0byB3YW50aW5nIHRoZSBWTkkgDQo+Y29uZmlndXJlZCBpbiB0aGUgU1BJ IG1hcHBpbmcgdGFibGUuICBJdCBzZWVtcyB0byBkZXBlbmQgdXBvbiB3aGVyZSB0aGUgDQo+VlRF UCBpcyB1bmRlcnN0b29kIHRvIGJlLiAgSSB0aGluayB3ZSBuZWVkIHRvIGFsbG93IGJvdGggY2Fz ZXMuDQo+DQo+SXQgc2hvdWxkIGJlIHJlbWVtYmVyZWQgdGhhdCB0aGUgdGFibGUgZW50cmllcyBp biB0aGUgTlNIIGRyYWZ0IGFyZSANCj5leGVtcGxhcnMsIG5vdCBzcGVjaWZpY2F0aW9uLiAgVGhl IE5TSCBkcmFmdCBkb2VzIG5vdCBzdGFuZGFyZGl6ZSB0aGUgDQo+dHJhbnNwb3J0IG1hcHBpbmdz LiAgKEFuZCB0aGUgV0cgY2hhcnRlciBtYWtlcyBhcHBlYXJzIHRvIG1ha2UgaXQgb3V0IG9mIA0K PnNjb3BlIGZvciB0aGUgV0cuKSAgU28gSSBhbSBub3Qgc3VyZSB3aGVyZSB0aGUgcXVlc3Rpb24g b2YgaW50ZXJvcGVyYWJsZSANCj5WTkkgdXNlIGZvciBWeExBTiB0cmFuc3BvcnQgY2FuIGJlIGFu c3dlcmVkLiAgKEFuZCBWTEFOIHVzZSBmb3IgRXRoZXJuZXQgDQo+VHJhbnNwb3J0LikNCj4NCj5Z b3VycywNCj5Kb2VsDQo+DQo+T24gNS8xNy8xNiA1OjAyIFBNLCBDaHJpc3RpYW4gS29lbm5pbmcg d3JvdGU6DQo+PiBUaGFua3MgZm9yIHRoZSBxdWljayByZXBseS4NCj4+DQo+PiBTcGVjaWZpY2Fs bHkgZm9yIFZYTEFOLUdQRSwgd2lsbCB0aGUgY28tcmVsYXRpbmcgU1BJIGJlIHVzaW5nIHRoZQ0K Pj4gc2FtZSBWWExBTiBTZWdtZW50IElEL1ZYTEFOIE5ldHdvcmsgSWRlbnRpZmllciAoVk5JKT8N Cj4+DQo+PiBTb3JyeSBmb3IgdGhlIGJyb2FkIHF1ZXN0aW9uLCBpIHJlYWxpc2UgdGhhdCBpIHJh dGhlciBzaG91bGQgZ28gaW50bw0KPj4gdGhlIGRldGFpbCBkaXJlY3RseS4NCj4+DQo+Pg0KPj4g TWFueSBUaGFua3MsDQo+Pg0KPj4gQ2hyaXN0aWFuDQo+Pg0KPj4NCj4+DQo+Pg0KPj4+IE9uIDE3 IE1heSAyMDE2LCBhdCAyMTo1MSwgSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29t Pg0KPj4+IHdyb3RlOg0KPj4+DQo+Pj4gSSBkbyBub3QgdGhpbmsgdGhhdCB0aGUgU0ZDIGFyY2h0 aWVjdHVyZSBvciB0aGUgTlNIIG1lY2hhbmlzbXMNCj4+PiBzcGVjaWZ5IGFueXRoaW5nIGFib3V0 IHRoZSBpbnRlci1TRkYgcGF0aHMgdXNlZCBpbiB0aGUgdHdvDQo+Pj4gZGlmZmVyZW50IGRpcmVj dGlvbnMgZm9yIGEgcGFpciBvZiBzeW1tZXRyaWNhbGx5IGNvcnJlbGF0ZWQgU2VydmljZQ0KPj4+ IEZ1bmN0aW9uIFBhdGhzLg0KPj4+DQo+Pj4gVGhhdCBzYWlkLCBnaXZlbiB0aGF0IHRoZSB0cmFu c3BvcnRzIGFyZSBydW5uaW5nIGJldHdlZW4gdGhlIHNhbWUNCj4+PiB0d28gZW5kLXBvaW50cywg SSB3b3VsZCBleHBlY3QgdGhhdCBvcGVyYXRpb25hbCBwcmFjdGljZXMgd2lsbA0KPj4+IHJlc3Vs dCBpbiB0aGVtIHVzaW5nIHRoZSBzYW1lIGtpbmQgb2YgdHJhbnNwb3J0Lg0KPj4+DQo+Pj4gRm9y IG1vc3Qgb2YgdGhlIHRyYW5zcG9ydHMgd2UgYXJlIGxvb2tpbmcgYXQsIGl0IGlzIG5vdCBjbGVh ciB3aGF0DQo+Pj4gaXQgbWVhbnMgdG8gYXNrIGlmIHRoZXkgYXJlIHVzaW5nIHRoZSBzYW1lIHR1 bm5lbC4gIEZvciBleGFtcGxlLCBpZg0KPj4+IHRoZSB0cmFuc3BvcnQgaXMgbmF0aXZlIEV0aGVy bmV0LCB0aGVuIG9uZSBkaXJlY3Rpb24gdXNlcyBhDQo+Pj4gcGFydGljdWxhciBzcmMvZGVzdCBF dGhlcm5ldCBhZGRyZXNzIHBhcmksIGFuZCB0aGUgb3RoZXIgZGlyZWN0aW9uDQo+Pj4gd2lsbCB0 eXBpY2FsbHkgKGJ1dCBub3QgYWx3YXlzKSB1c2UgdGhlIHNhbWUgYWRkcmVzc2VzIGluIHRoZSBv dGhlcg0KPj4+IG9yZGVyLiAgSWYgd2UgYXJlIHVzaW5nIFZ4TEFOLCBpbiBlYWNoIGRpcmVjdGlv biB0aGUgc291cmNlIFVEUA0KPj4+IHBvcnQgd2lsbCBiZSByYW5kb20sIGFzIHRoYXQgaXMgdGhl IHdheSBWeExBTiB3b3Jrcy4gIElmIHdlIGFyZQ0KPj4+IHVzaW5nIExJU1AsIHRoZSB0dW5uZWxz IGFyZSBjb25zaWRlcmVkIHRvIGJlIHVuaWRpcmVjdGlvbmFsLg0KPj4+DQo+Pj4gWW91cnMsIEpv ZWwNCj4+Pg0KPj4+PiBPbiA1LzE3LzE2IDQ6NDUgUE0sIENocmlzdGlhbiBLb2VubmluZyB3cm90 ZToNCj4+Pj4NCj4+Pj4gVGhhbmtzIEpvZWwsDQo+Pj4+DQo+Pj4+IHRoYW5rcyBmb3IgY29uZmly bWluZyBmbG93IGNvcnJlbGF0aW9uIChMNCkgaXMgZXhwZWN0ZWQgYXMgdXN1YWwsDQo+Pj4+IGV2 ZW4gd2l0aCBpbmdyZXNzIGFuZCBlZ3Jlc3Mgb24gdHdvIGRpZmZlcmVudCBTZXJ2aWNlIFBhdGgg SURzLg0KPj4+PiBUaGUgcXVlc3Rpb24gb2Ygb3ZlcmxvYWRpbmcgYWRkcmVzcyBzcGFjZSB0cmll ZCB0byBjbGFyaWZ5IHRoZQ0KPj4+PiAocmFyZSkgdGhlIHNpdHVhdGlvbiB3aGVyZSAyIGVuZHBv aW50IHBhaXJzIGhhdmUgdGhlIHNhbWUNCj4+Pj4gYWRkcmVzc2VzIGFuZCBoYXZlIGFncmVlZCBv biB0aGUgc2FtZSBzcmMvZHN0IHBvcnQvcHJvdG9jb2wsDQo+Pj4+IHdoaWNoIGxlYWRzIHRvIGZs b3cgY29sbGlzaW9ucy4NCj4+Pj4NCj4+Pj4gWW91IG1lbnRpb24gdGhhdCBTZXJ2aWNlIFBhdGgg SUQgd2lsbCBub3cgYWxsb3cgdG8gcmV1c2UtDQo+Pj4+IC9kdXBsaWNhdGlvbi4NCj4+Pj4NCj4+ Pj4gSG93ZXZlciwgeW91IG1lbnRpb25lZCB0aGF0IG1ldGFkYXRhIHdpbGwgcHJvdmlkZSBhZGRy ZXNzIHJldXNlLQ0KPj4+PiAvIGR1cGxpY2F0aW9uLiBUaGVyZWZvcmUgdGhlIGZsb3cgY29ycmVs YXRpb24gd291bGQgbmVlZCB0bw0KPj4+PiBoYXBwZW4gb24gaW5jbHVkaW5nIHRoZSBtZXRhZGF0 YSBhcyBwYXJ0IG9mIHRoZSB0dXBsZSBhcyB3ZWxsLg0KPj4+Pg0KPj4+PiBBbHNvLCBhbGxvdyBt ZSB0byBhc2sgaWYgd2UgZXhwZWN0IGluZ3Jlc3MgYW5kIGVncmVzcyBTZXJ2aWNlDQo+Pj4+IFBh dGggSURzIG9uIHRoZSBzYW1lIHRyYW5zcG9ydC90dW5uZWwgPw0KPj4+Pg0KPj4+PiBNYW55IFRo YW5rcw0KPj4+Pg0KPj4+PiBDaHJpc3RpYW4gS29lbm5pbmcgLS0gRjUgTmV0d29ya3MgSW5jLiBj aHJpc3RpYW5AZjUuY29tDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+ PiBPbiAxNy8wNS8yMDE2LCAyMTowNywgIkpvZWwgTS4gSGFscGVybiIgPGptaEBqb2VsaGFscGVy bi5jb20+DQo+Pj4+PiB3cm90ZToNCj4+Pj4+DQo+Pj4+PiBDb3JyZWxhdGlvbiBvZiBwYWNrZXRz IGluIHR3byBkaXJlY3Rpb25zIGZvciBhbiBTRiB3aGljaCB3b3Jrcw0KPj4+Pj4gc2VlbXMgdG8g cmVxdWlyZSB0aGF0IHRoZSBTRiBrbm93IGhvdyB0byBjb3JyZWxhdGUgcGFja2V0cy4gIElkDQo+ Pj4+PiBkb2VzIG5vdCBuZWVkIHRvIGxvb2sgYXQgdGhlIFNQSSBmb3IgdGhhdCwgc2luY2UgU1BJ IGFyZQ0KPj4+Pj4gY29hcnNlciB0aGFuIGZsb3cuICBJdCBtYXkgbmVlZCB0byBsb29rIGF0IG1l dGFkYXRhIChzdWNoIGFzDQo+Pj4+PiBzdWJzY3JpYmVyIGlkZW50aXR5KSBpZiB0aGUgU0YgaXMg aW5zaWRlIGEgZG9tYWluIHdoZXJlIElQDQo+Pj4+PiBhZGRyZXNzZXMgYXJlIHJldXNlZCAoTkFU IGJlaW5nIGEgc2VydmljZSBmdW5jdGlvbiBpdHNlbGYsIHNvDQo+Pj4+PiBvbmUgY291bGQgYmUg b24gdGhlIHJldXNlIHNpZGUgb2YgYSBOQVQuKQ0KPj4+Pj4NCj4+Pj4+IEkgYW0gbm90IHN1cmUg d2hhdCB5b3UgYXJlIHJlZmVycmluZyB0byBieSBhZGRyZXNzIG5hbWVzcGFjZXMuDQo+Pj4+PiBT UElzIGRvIG5vdCBzZWdyZWdhdGUgc3Vic2NyaWJlcnMsIG5vciBhcmUgdGhleSBxdWFsaWZpZXJz IGZvcg0KPj4+Pj4gZGlzYW1iaWd1YXRpbmcgYWRkcmVzc2VzIHdoZXJlIE5BVCBpcyBpbiB1c2Uu ICBNZXRhZGF0YSBpbiB0aGUNCj4+Pj4+IHBhY2tldCBpcyB1c2VkIGZvciBzdWNoIGRpc2FtYmln dWF0aW9uLiAgU28sIGluIHRoZSBwcmVzZW5jZSBvZg0KPj4+Pj4gc3VpdGFibGUgbWV0YWRhdGEs IFNGQyBhbmQgTlNIIHN1cHBvcnQgaW5uZXIgKHN1YnNjcmliZXIpDQo+Pj4+PiBhZGRyZXNzIHJl dXNlIC8gZHVwbGljYXRpb24uICBOQVQgaXMgYW4gZW52aXNpb25lZCBzZXJ2aWNlDQo+Pj4+PiBm dW5jdGlvbi4gIEp1c3QgZG9uJ3QgdHJ5IHRvIHVzZSB0aGUgU1BJIGFzIHRoZSBrZXkuIEl0IHdv bid0DQo+Pj4+PiB0ZWxsIHlvdSB3aGF0IHlvdSBuZWVkLg0KPj4+Pj4NCj4+Pj4+IFlvdXJzLCBK b2VsDQo+Pj4+Pg0KPj4+Pj4+IE9uIDUvMTcvMTYgNDowMiBQTSwgQ2hyaXN0aWFuIEtvZW5uaW5n IHdyb3RlOiBUaGFua3MgSm9lbCwNCj4+Pj4+Pg0KPj4+Pj4+IHRoYXQgaXMgd2hlcmUgSSB3YXMg Z2V0dGluZyBjb25mdXNlZC4NCj4+Pj4+Pg0KPj4+Pj4+IFdoZW4gbG9va2luZyBlLmcuIGF0IGEg c3RhdGVmdWwgU2VydmljZSBGdW5jdGlvbiAoU0YpLCB0aGVyZQ0KPj4+Pj4+IG5lZWRzIHRvIGJl IGFuIGluc3RydWN0aW9uIHdoaWNoIHR3byBvZiB0aGUgU2VydmljZSBQYXRoDQo+Pj4+Pj4gSWRl bnRpZmllcnMgY28tcmVsZWF0ZSBpbiBvcmRlciB0byBlc3RhYmxpc2ggc3RhdGUuDQo+Pj4+Pj4N Cj4+Pj4+Pg0KPj4+Pj4+IEZ1cnRoZXIgdG8gdGhhdCwgY291bGQgeW91IGRlZmluZSBpZiBTZXJ2 aWNlIFBhdGggSWRlbnRpZmllcnMNCj4+Pj4+PiBhbGxvd3MgZm9yIG92ZXJsb2FkaW5nIG9mIGFk ZHJlc3MgbmFtZXNwYWNlPw0KPj4+Pj4+DQo+Pj4+Pj4gUGxlYXNlIGFsbG93IHVzIHRvIGNsYXJp ZnkgdGhpcy4NCj4+Pj4+Pg0KPj4+Pj4+IE1hbnkgVGhhbmtzDQo+Pj4+Pj4NCj4+Pj4+PiBDaHJp c3RpYW4gS29lbm5pbmcgLS0gRjUgTmV0d29ya3MgSW5jLiBjaHJpc3RpYW5AZjUuY29tDQo+Pj4+ Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4+IE9uIDE3 LzA1LzIwMTYsIDIwOjU3LCAiSm9lbCBNLiBIYWxwZXJuIg0KPj4+Pj4+PiA8am1oQGpvZWxoYWxw ZXJuLmNvbT4gd3JvdGU6DQo+Pj4+Pj4+DQo+Pj4+Pj4+IE1vc3Qgb2YgdXMgaGF2ZSBhc3N1bWVk IHRoYXQgYSBiaS1kaXJlY3Rpb25hbCBzeW1tZXRyaWMNCj4+Pj4+Pj4gcGF0aCBwYWlyIGlzIHNl dCB1cCBieSBjb250cm9sLCBhbmQgaGFzIHNlcGFyYXRlIFNlcnZpY2UNCj4+Pj4+Pj4gUGF0aCBJ RHMgKGFuZCBpbmRpY2llcykgaW4gZWFjaCBkaXJlY3Rpb24uICBUaGlzIGRvZXMgbGVhZA0KPj4+ Pj4+PiB0byBhIG5lZWQgZm9yIHNlcnZpY2UgZnVuY3Rpb25zIHdoaWNoIG9yaWdpbmF0ZSByZXZl cnNlDQo+Pj4+Pj4+IGRpcmVjdGlvbiBwYWNrZXRzIHRvIGhhdmUgYSBtZWFucyB0byBnZXQgdGhl IGNvcnJlY3QgU1BJIC8NCj4+Pj4+Pj4gSW5kZXggaW4gcGxhY2UgZm9yIHRob3NlIHBhY2tldHMu ICBUaGVyZSBhcmUgZHJhZnRzDQo+Pj4+Pj4+IGRpc2N1c3NpbmcgYXBwcm9hY2hlcyB0byB0aGF0 IHF1ZXN0aW9uLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBZb3VycywgSm9lbA0KPj4+Pj4+Pg0KPj4+Pj4+ Pj4gT24gNS8xNy8xNiAzOjQ5IFBNLCBDaHJpc3RpYW4gS29lbm5pbmcgd3JvdGU6IEdvb2QNCj4+ Pj4+Pj4+IEV2ZW5pbmcsDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gbG9va2luZyBhdCBSRkMgNzY2NSBT ZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIChTRkMpDQo+Pj4+Pj4+PiBBcmNoaXRlY3R1cmUgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc2NjUNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiB0aGVy ZSBpcyBhIGNsZWFyIGRlZmluaXRpb24gb2YgY2hhaW4gc3ltZXRyeQ0KPj4+Pj4+Pj4NCj4+Pj4+ Pj4+ICIgMi4yLiAgU2VydmljZSBGdW5jdGlvbiBDaGFpbiBTeW1tZXRyeQ0KPj4+Pj4+Pj4NCj4+ Pj4+Pj4+IFNGQ3MgbWF5IGJlIHVuaWRpcmVjdGlvbmFsIG9yIGJpZGlyZWN0aW9uYWwuICBBDQo+ Pj4+Pj4+PiB1bmlkaXJlY3Rpb25hbCBTRkMgcmVxdWlyZXMgdGhhdCB0cmFmZmljIGJlIGZvcndh cmRlZA0KPj4+Pj4+Pj4gdGhyb3VnaCB0aGUgb3JkZXJlZCBTRnMgaW4gb25lIGRpcmVjdGlvbiAo c2YxIC0+IHNmMiAtPg0KPj4+Pj4+Pj4gc2YzKSwgd2hlcmVhcyBhIGJpZGlyZWN0aW9uYWwgU0ZD IHJlcXVpcmVzIGEgc3ltbWV0cmljDQo+Pj4+Pj4+PiBwYXRoIChzZjEgLT4gc2YyIC0+IHNmMyBh bmQgc2YzIC0+IHNmMiAtPiBzZjEpLCBhbmQgaW4NCj4+Pj4+Pj4+IHdoaWNoIHRoZSBTRiBpbnN0 YW5jZXMgYXJlIHRoZSBzYW1lIGluIG9wcG9zaXRlDQo+Pj4+Pj4+PiBkaXJlY3Rpb25zLiAgQSBo eWJyaWQgU0ZDIGhhcyBhdHRyaWJ1dGVzIG9mIGJvdGgNCj4+Pj4+Pj4+IHVuaWRpcmVjdGlvbmFs IGFuZCBiaWRpcmVjdGlvbmFsIFNGQ3M7IHRoYXQgaXMgdG8gc2F5DQo+Pj4+Pj4+PiBzb21lIFNG cyByZXF1aXJlIHN5bW1ldHJpYyB0cmFmZmljLCB3aGVyZWFzIG90aGVyIFNGcyBkbw0KPj4+Pj4+ Pj4gbm90IHByb2Nlc3MgcmV2ZXJzZSB0cmFmZmljIG9yIGFyZSBpbmRlcGVuZGVudCBvZiB0aGUN Cj4+Pj4+Pj4+IGNvcnJlc3BvbmRpbmcgZm9yd2FyZCB0cmFmZmljLg0KPj4+Pj4+Pj4NCj4+Pj4+ Pj4+IC4uLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEZ1cnRoZXIsIHRoZXJlIGFyZSBzdGF0ZSB0cmFk ZS1vZmZzIGluIHN5bW1ldHJ5Lg0KPj4+Pj4+Pj4gU3ltbWV0cnkgbWF5IGJlIHJlYWxpemVkIGlu IHNldmVyYWwgd2F5cyBkZXBlbmRpbmcgb24gdGhlDQo+Pj4+Pj4+PiBTRkYgYW5kIGNsYXNzaWZp ZXIgZnVuY3Rpb25hbGl0eS4gIEluIHNvbWUgY2FzZXMsDQo+Pj4+Pj4+PiAibWlycm9yZWQiIGNs YXNzaWZpY2F0aW9uIChpLmUuLCBmcm9tIFNvdXJjZSB0bw0KPj4+Pj4+Pj4gRGVzdGluYXRpb24g YW5kIGZyb20gRGVzdGluYXRpb24gdG8gU291cmNlKSBwb2xpY3kgbWF5DQo+Pj4+Pj4+PiBiZSBk ZXBsb3llZCwgd2hlcmVhcyBpbiBvdGhlcnMgc2hhcmVkIHN0YXRlIGJldHdlZW4NCj4+Pj4+Pj4+ IGNsYXNzaWZpZXJzIG1heSBiZSB1c2VkIHRvIGVuc3VyZSB0aGF0IHN5bW1ldHJpYyBmbG93cw0K Pj4+Pj4+Pj4gYXJlIGNvcnJlY3RseSBpZGVudGlmaWVkLCB0aGVuIHN0ZWVyZWQgYWxvbmcgdGhl IHJlcXVpcmVkDQo+Pj4+Pj4+PiBTRlAuICBBdCBhIGhpZ2ggbGV2ZWwsIHRoZXJlIGFyZSB2YXJp b3VzIGNvbW1vbiBjYXNlcy4NCj4+Pj4+Pj4+IEluIGEgbm9uLWV4aGF1c3RpdmUgd2F5LCB0aGVy ZSBjYW4gYmUgZm9yIGV4YW1wbGU6DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gbyAgQSBzaW5nbGUgY2xh c3NpZmllciAob3IgYSBzbWFsbCBudW1iZXIgb2YNCj4+Pj4+Pj4+IGNsYXNzaWZpZXJzKSwgaW4g d2hpY2ggY2FzZSBib3RoIGluY29taW5nIGFuZCBvdXRnb2luZw0KPj4+Pj4+Pj4gZmxvd3MgY291 bGQgYmUgcmVjb2duaXplZCBhdCB0aGUgc2FtZSBjbGFzc2lmaWVyLCBzbyB0aGUNCj4+Pj4+Pj4+ IHN5bmNocm9uaXphdGlvbiB3b3VsZCBiZSBmZWFzaWJsZSBieSBpbnRlcm5hbCBtZWNoYW5pc21z DQo+Pj4+Pj4+PiBpbnRlcm5hbCB0byB0aGUgY2xhc3NpZmllci4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+ PiBvICBTdGF0ZWZ1bCBjbGFzc2lmaWVycyB3aGVyZSBzZXZlcmFsIGNsYXNzaWZpZXJzIG1heSBi ZQ0KPj4+Pj4+Pj4gY2x1c3RlcmVkIGFuZCBzaGFyZSBzdGF0ZS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+ PiBvICBGdWxseSBkaXN0cmlidXRlZCBjbGFzc2lmaWVycywgd2hlcmUgc3luY2hyb25pemF0aW9u DQo+Pj4+Pj4+PiBuZWVkcyB0byBiZSBwcm92aWRlZCB0aHJvdWdoIHVuc3BlY2lmaWVkIG1lYW5z Lg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IG8gIEEgY2xhc3NpZmllciB0aGF0IGxlYXJucyBzdGF0ZSBm cm9tIHRoZSBlZ3Jlc3MNCj4+Pj4+Pj4+IHBhY2tldHMvZmxvd3MgdGhhdCBpcyB0aGVuIHVzZWQg dG8gcHJvdmlkZSBzdGF0ZSBmb3IgdGhlDQo+Pj4+Pj4+PiByZXR1cm4gcGFja2V0cy9mbG93Lg0K Pj4+Pj4+Pj4NCj4+Pj4+Pj4+IG8gIFN5bW1ldHJ5IG1heSBhbHNvIGJlIHByb3ZpZGVkIGJ5IHN0 YXRlZnVsIGZvcndhcmRpbmcNCj4+Pj4+Pj4+IGxvZ2ljIGluIHRoZSBTRkYgaW4gc29tZSBpbXBs ZW1lbnRhdGlvbnMuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gVGhpcyBpcyBhIG5vbi1jb21wcmVoZW5z aXZlIGxpc3Qgb2YgY29tbW9uIGNhc2VzLiAiDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ IEhvd2V2ZXIsIHdoZW4gbG9va2luZyBhdCB0aGlzIHRvZ2V0aGVyIHdpdGggTmV0d29yaw0KPj4+ Pj4+Pj4gU2VydmljZSBIZWFkZXIgZHJhZnQtaWV0Zi1zZmMtbnNoLTA0LnR4dA0KPj4+Pj4+Pj4g aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2ZjLW5zaC0wNA0KPj4+Pj4+ Pj4NCj4+Pj4+Pj4+IDMuMy4gIFNlcnZpY2UgUGF0aCBIZWFkZXINCj4+Pj4+Pj4+DQo+Pj4+Pj4+ PiAiIFNlcnZpY2UgUGF0aCBJZGVudGlmaWVyIChTUEkpOiBpZGVudGlmaWVzIGEgc2VydmljZQ0K Pj4+Pj4+Pj4gcGF0aC4gUGFydGljaXBhdGluZyBub2RlcyBNVVNUIHVzZSB0aGlzIGlkZW50aWZp ZXIgZm9yDQo+Pj4+Pj4+PiBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGggc2VsZWN0aW9uLiAiDQo+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4gdGhlcmUgaXMgbm8gbm90aW9uIG9mIHN5bW1ldHJ5Lg0KPj4+Pj4+Pj4N Cj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBDYW4geW91IHBsZWFzZSBjb25maXJtIHRoYXQgYSBiaWRpcmVj dGlvbmFsIFNlcnZpY2UNCj4+Pj4+Pj4+IEZ1bmN0aW9uIENoYWluIHdpbGwgYmUgcmVwcmVzZW50 ZWQgYnkgb25lIHNpbmdsZSBTZXJ2aWNlDQo+Pj4+Pj4+PiBQYXRoIElkZW50aWZpZXIsIGluZ3Jl c3Mgc3ltbWV0cmljIHRvIGVncmVzcyA/DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFBs ZWFzZSBhbGxvdyB1cyB0byBjbGFyaWZ5IHRoaXMuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gTWFueSBU aGFua3MNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBDaHJpc3RpYW4gS29lbm5pbmcgLS0gRjUgTmV0d29y a3MgSW5jLiBjaHJpc3RpYW5AZjUuY29tDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+ Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBz ZmMNCj4+Pj4+Pj4+IG1haWxpbmcgbGlzdCBzZmNAaWV0Zi5vcmcNCj4+Pj4+Pj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4+Pj4+Pg0KPj4NCj4NCj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnNmYyBtYWlsaW5n IGxpc3QNCj5zZmNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0K From nobody Tue May 17 16:04:28 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C881B12DAD9 for ; Tue, 17 May 2016 16:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 OLCqKB59kjY5 for ; Tue, 17 May 2016 16:04:23 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 ADD8912DAB3 for ; Tue, 17 May 2016 16:04:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 96264240783; Tue, 17 May 2016 16:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1463526263; bh=OHsgglq+F+x0xtf/NTGS6TfB/NI6SbWndja4LeQtDRk=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=BKf2+q+iel8C1XmFt7YSBbp0Q7XmHXSLyWCyptKo1HrxCATj5LbJdd83S57c9IdG0 Vxc7tKs2KZRpusl2I6B76wJIDsT45tGJCw+a1rtA1aZ9tMFcsgS3T9zQ1GS7BpEbf5 YoUXjFMVX0+QP1lvDe8G8NuVD0KegH0a1Ms0eeY4= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 03293240779; Tue, 17 May 2016 16:04:22 -0700 (PDT) To: Christian Koenning References: <708683c2-8c57-41e1-0dc9-153fd09ecdcd@joelhalpern.com> <4ffc7b1e-b9cd-ea61-58b1-55e93e373768@joelhalpern.com> <00D7FD5C-2F8A-4D21-AC12-C560E106704D@F5.com> <6737272c-dbbc-f985-1c9a-7dd93b99659a@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <604cceed-4030-79e7-01f9-29a335058bc0@joelhalpern.com> Date: Tue, 17 May 2016 19:04:34 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Service Path Identifier (SPI) and symmetry X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 23:04:26 -0000 I am not sure which aspects can reasonably go in the NSH draft. For example, although the VxLAN example can be enhanced, it is still an example, not anything normative. Basically, additions are up to the WG. Within the scope of the document and WG charter. Yours, Joel On 5/17/16 6:28 PM, Christian Koenning wrote: > Thanks Joel, > > Would it be possible to add all this clarification into the draft ? > It will remove the ambiguity. > > > Many Thanks > Christian > > > > > > On 17/05/2016, 22:12, "sfc on behalf of Joel M. Halpern" wrote: > >> Neither NSH nor SFC Architecture would force the same VNI to be used in >> each direction for the paired SFPs. I would not assume that in my SFF >> design. >> Hwoe3ver, it would seem a very good practice, and something I would >> expect control to do. >> >> This does get back to your earlier, welltaken, question about where teh >> SFF gets the VNI to put into the VxLAN header. One approach is to >> declare that all of service chaining is a single VNI, and so it is an >> SFF-wide configuration parameter. Another approach is that specific >> portions use specific VNI, which would lead to wanting the VNI >> configured in the SPI mapping table. It seems to depend upon where the >> VTEP is understood to be. I think we need to allow both cases. >> >> It should be remembered that the table entries in the NSH draft are >> exemplars, not specification. The NSH draft does not standardize the >> transport mappings. (And the WG charter makes appears to make it out of >> scope for the WG.) So I am not sure where the question of interoperable >> VNI use for VxLAN transport can be answered. (And VLAN use for Ethernet >> Transport.) >> >> Yours, >> Joel >> >> On 5/17/16 5:02 PM, Christian Koenning wrote: >>> Thanks for the quick reply. >>> >>> Specifically for VXLAN-GPE, will the co-relating SPI be using the >>> same VXLAN Segment ID/VXLAN Network Identifier (VNI)? >>> >>> Sorry for the broad question, i realise that i rather should go into >>> the detail directly. >>> >>> >>> Many Thanks, >>> >>> Christian >>> >>> >>> >>> >>>> On 17 May 2016, at 21:51, Joel M. Halpern >>>> wrote: >>>> >>>> I do not think that the SFC archtiecture or the NSH mechanisms >>>> specify anything about the inter-SFF paths used in the two >>>> different directions for a pair of symmetrically correlated Service >>>> Function Paths. >>>> >>>> That said, given that the transports are running between the same >>>> two end-points, I would expect that operational practices will >>>> result in them using the same kind of transport. >>>> >>>> For most of the transports we are looking at, it is not clear what >>>> it means to ask if they are using the same tunnel. For example, if >>>> the transport is native Ethernet, then one direction uses a >>>> particular src/dest Ethernet address pari, and the other direction >>>> will typically (but not always) use the same addresses in the other >>>> order. If we are using VxLAN, in each direction the source UDP >>>> port will be random, as that is the way VxLAN works. If we are >>>> using LISP, the tunnels are considered to be unidirectional. >>>> >>>> Yours, Joel >>>> >>>>> On 5/17/16 4:45 PM, Christian Koenning wrote: >>>>> >>>>> Thanks Joel, >>>>> >>>>> thanks for confirming flow correlation (L4) is expected as usual, >>>>> even with ingress and egress on two different Service Path IDs. >>>>> The question of overloading address space tried to clarify the >>>>> (rare) the situation where 2 endpoint pairs have the same >>>>> addresses and have agreed on the same src/dst port/protocol, >>>>> which leads to flow collisions. >>>>> >>>>> You mention that Service Path ID will now allow to reuse- >>>>> /duplication. >>>>> >>>>> However, you mentioned that metadata will provide address reuse- >>>>> / duplication. Therefore the flow correlation would need to >>>>> happen on including the metadata as part of the tuple as well. >>>>> >>>>> Also, allow me to ask if we expect ingress and egress Service >>>>> Path IDs on the same transport/tunnel ? >>>>> >>>>> Many Thanks >>>>> >>>>> Christian Koenning -- F5 Networks Inc. christian@f5.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> On 17/05/2016, 21:07, "Joel M. Halpern" >>>>>> wrote: >>>>>> >>>>>> Correlation of packets in two directions for an SF which works >>>>>> seems to require that the SF know how to correlate packets. Id >>>>>> does not need to look at the SPI for that, since SPI are >>>>>> coarser than flow. It may need to look at metadata (such as >>>>>> subscriber identity) if the SF is inside a domain where IP >>>>>> addresses are reused (NAT being a service function itself, so >>>>>> one could be on the reuse side of a NAT.) >>>>>> >>>>>> I am not sure what you are referring to by address namespaces. >>>>>> SPIs do not segregate subscribers, nor are they qualifiers for >>>>>> disambiguating addresses where NAT is in use. Metadata in the >>>>>> packet is used for such disambiguation. So, in the presence of >>>>>> suitable metadata, SFC and NSH support inner (subscriber) >>>>>> address reuse / duplication. NAT is an envisioned service >>>>>> function. Just don't try to use the SPI as the key. It won't >>>>>> tell you what you need. >>>>>> >>>>>> Yours, Joel >>>>>> >>>>>>> On 5/17/16 4:02 PM, Christian Koenning wrote: Thanks Joel, >>>>>>> >>>>>>> that is where I was getting confused. >>>>>>> >>>>>>> When looking e.g. at a stateful Service Function (SF), there >>>>>>> needs to be an instruction which two of the Service Path >>>>>>> Identifiers co-releate in order to establish state. >>>>>>> >>>>>>> >>>>>>> Further to that, could you define if Service Path Identifiers >>>>>>> allows for overloading of address namespace? >>>>>>> >>>>>>> Please allow us to clarify this. >>>>>>> >>>>>>> Many Thanks >>>>>>> >>>>>>> Christian Koenning -- F5 Networks Inc. christian@f5.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 17/05/2016, 20:57, "Joel M. Halpern" >>>>>>>> wrote: >>>>>>>> >>>>>>>> Most of us have assumed that a bi-directional symmetric >>>>>>>> path pair is set up by control, and has separate Service >>>>>>>> Path IDs (and indicies) in each direction. This does lead >>>>>>>> to a need for service functions which originate reverse >>>>>>>> direction packets to have a means to get the correct SPI / >>>>>>>> Index in place for those packets. There are drafts >>>>>>>> discussing approaches to that question. >>>>>>>> >>>>>>>> Yours, Joel >>>>>>>> >>>>>>>>> On 5/17/16 3:49 PM, Christian Koenning wrote: Good >>>>>>>>> Evening, >>>>>>>>> >>>>>>>>> looking at RFC 7665 Service Function Chaining (SFC) >>>>>>>>> Architecture https://tools.ietf.org/html/rfc7665 >>>>>>>>> >>>>>>>>> there is a clear definition of chain symetry >>>>>>>>> >>>>>>>>> " 2.2. Service Function Chain Symmetry >>>>>>>>> >>>>>>>>> SFCs may be unidirectional or bidirectional. A >>>>>>>>> unidirectional SFC requires that traffic be forwarded >>>>>>>>> through the ordered SFs in one direction (sf1 -> sf2 -> >>>>>>>>> sf3), whereas a bidirectional SFC requires a symmetric >>>>>>>>> path (sf1 -> sf2 -> sf3 and sf3 -> sf2 -> sf1), and in >>>>>>>>> which the SF instances are the same in opposite >>>>>>>>> directions. A hybrid SFC has attributes of both >>>>>>>>> unidirectional and bidirectional SFCs; that is to say >>>>>>>>> some SFs require symmetric traffic, whereas other SFs do >>>>>>>>> not process reverse traffic or are independent of the >>>>>>>>> corresponding forward traffic. >>>>>>>>> >>>>>>>>> ... >>>>>>>>> >>>>>>>>> Further, there are state trade-offs in symmetry. >>>>>>>>> Symmetry may be realized in several ways depending on the >>>>>>>>> SFF and classifier functionality. In some cases, >>>>>>>>> "mirrored" classification (i.e., from Source to >>>>>>>>> Destination and from Destination to Source) policy may >>>>>>>>> be deployed, whereas in others shared state between >>>>>>>>> classifiers may be used to ensure that symmetric flows >>>>>>>>> are correctly identified, then steered along the required >>>>>>>>> SFP. At a high level, there are various common cases. >>>>>>>>> In a non-exhaustive way, there can be for example: >>>>>>>>> >>>>>>>>> o A single classifier (or a small number of >>>>>>>>> classifiers), in which case both incoming and outgoing >>>>>>>>> flows could be recognized at the same classifier, so the >>>>>>>>> synchronization would be feasible by internal mechanisms >>>>>>>>> internal to the classifier. >>>>>>>>> >>>>>>>>> o Stateful classifiers where several classifiers may be >>>>>>>>> clustered and share state. >>>>>>>>> >>>>>>>>> o Fully distributed classifiers, where synchronization >>>>>>>>> needs to be provided through unspecified means. >>>>>>>>> >>>>>>>>> o A classifier that learns state from the egress >>>>>>>>> packets/flows that is then used to provide state for the >>>>>>>>> return packets/flow. >>>>>>>>> >>>>>>>>> o Symmetry may also be provided by stateful forwarding >>>>>>>>> logic in the SFF in some implementations. >>>>>>>>> >>>>>>>>> This is a non-comprehensive list of common cases. " >>>>>>>>> >>>>>>>>> >>>>>>>>> However, when looking at this together with Network >>>>>>>>> Service Header draft-ietf-sfc-nsh-04.txt >>>>>>>>> https://tools.ietf.org/html/draft-ietf-sfc-nsh-04 >>>>>>>>> >>>>>>>>> 3.3. Service Path Header >>>>>>>>> >>>>>>>>> " Service Path Identifier (SPI): identifies a service >>>>>>>>> path. Participating nodes MUST use this identifier for >>>>>>>>> Service Function Path selection. " >>>>>>>>> >>>>>>>>> there is no notion of symmetry. >>>>>>>>> >>>>>>>>> >>>>>>>>> Can you please confirm that a bidirectional Service >>>>>>>>> Function Chain will be represented by one single Service >>>>>>>>> Path Identifier, ingress symmetric to egress ? >>>>>>>>> >>>>>>>>> >>>>>>>>> Please allow us to clarify this. >>>>>>>>> >>>>>>>>> Many Thanks >>>>>>>>> >>>>>>>>> Christian Koenning -- F5 Networks Inc. christian@f5.com >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ 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 Tue May 17 16:11:14 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A2D12D882 for ; Tue, 17 May 2016 16:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 zpTpNqf4X4Cn for ; Tue, 17 May 2016 16:11:11 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 3377012D545 for ; Tue, 17 May 2016 16:11:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 21768240779; Tue, 17 May 2016 16:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1463526671; bh=5NQ8tbfAO4Ww7rbdJUPFPNZjPK2q9ngcit4OxkVy2m4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=jEiCEsYJ7l3eJtuhtJCKPidqACCWdTRKbyILeJvK1cKUeKHhX8t3gdzXcLtFOJgaL KJqcuvh0NdyIgV04TqJT+sSIWAtLyWT0LiVC5lIuYQfTbX9bVVqaV7IcvaYL6S3vmm p6aJp2GzXsZh1N3tUouQ89wzwITFID7dKyezlroY= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 7E6C8240783; Tue, 17 May 2016 16:11:10 -0700 (PDT) To: Christian Koenning References: <708683c2-8c57-41e1-0dc9-153fd09ecdcd@joelhalpern.com> <4ffc7b1e-b9cd-ea61-58b1-55e93e373768@joelhalpern.com> <00D7FD5C-2F8A-4D21-AC12-C560E106704D@F5.com> <6737272c-dbbc-f985-1c9a-7dd93b99659a@joelhalpern.com> <604cceed-4030-79e7-01f9-29a335058bc0@joelhalpern.com> From: "Joel M. Halpern" Message-ID: Date: Tue, 17 May 2016 19:11:21 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <604cceed-4030-79e7-01f9-29a335058bc0@joelhalpern.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Service Path Identifier (SPI) and symmetry X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 23:11:13 -0000 I realized reading my reply that I left out something important. The fact that you found this confusing is a good indication that we should try to improve the text. Yours, Joel On 5/17/16 7:04 PM, Joel M. Halpern wrote: > I am not sure which aspects can reasonably go in the NSH draft. For > example, although the VxLAN example can be enhanced, it is still an > example, not anything normative. > > Basically, additions are up to the WG. Within the scope of the document > and WG charter. > > Yours, > Joel > > On 5/17/16 6:28 PM, Christian Koenning wrote: >> Thanks Joel, >> >> Would it be possible to add all this clarification into the draft ? >> It will remove the ambiguity. >> >> >> Many Thanks >> Christian >> >> >> >> >> >> On 17/05/2016, 22:12, "sfc on behalf of Joel M. Halpern" >> wrote: >> >>> Neither NSH nor SFC Architecture would force the same VNI to be used in >>> each direction for the paired SFPs. I would not assume that in my SFF >>> design. >>> Hwoe3ver, it would seem a very good practice, and something I would >>> expect control to do. >>> >>> This does get back to your earlier, welltaken, question about where teh >>> SFF gets the VNI to put into the VxLAN header. One approach is to >>> declare that all of service chaining is a single VNI, and so it is an >>> SFF-wide configuration parameter. Another approach is that specific >>> portions use specific VNI, which would lead to wanting the VNI >>> configured in the SPI mapping table. It seems to depend upon where the >>> VTEP is understood to be. I think we need to allow both cases. >>> >>> It should be remembered that the table entries in the NSH draft are >>> exemplars, not specification. The NSH draft does not standardize the >>> transport mappings. (And the WG charter makes appears to make it out of >>> scope for the WG.) So I am not sure where the question of interoperable >>> VNI use for VxLAN transport can be answered. (And VLAN use for Ethernet >>> Transport.) >>> >>> Yours, >>> Joel >>> >>> On 5/17/16 5:02 PM, Christian Koenning wrote: >>>> Thanks for the quick reply. >>>> >>>> Specifically for VXLAN-GPE, will the co-relating SPI be using the >>>> same VXLAN Segment ID/VXLAN Network Identifier (VNI)? >>>> >>>> Sorry for the broad question, i realise that i rather should go into >>>> the detail directly. >>>> >>>> >>>> Many Thanks, >>>> >>>> Christian >>>> >>>> >>>> >>>> >>>>> On 17 May 2016, at 21:51, Joel M. Halpern >>>>> wrote: >>>>> >>>>> I do not think that the SFC archtiecture or the NSH mechanisms >>>>> specify anything about the inter-SFF paths used in the two >>>>> different directions for a pair of symmetrically correlated Service >>>>> Function Paths. >>>>> >>>>> That said, given that the transports are running between the same >>>>> two end-points, I would expect that operational practices will >>>>> result in them using the same kind of transport. >>>>> >>>>> For most of the transports we are looking at, it is not clear what >>>>> it means to ask if they are using the same tunnel. For example, if >>>>> the transport is native Ethernet, then one direction uses a >>>>> particular src/dest Ethernet address pari, and the other direction >>>>> will typically (but not always) use the same addresses in the other >>>>> order. If we are using VxLAN, in each direction the source UDP >>>>> port will be random, as that is the way VxLAN works. If we are >>>>> using LISP, the tunnels are considered to be unidirectional. >>>>> >>>>> Yours, Joel >>>>> >>>>>> On 5/17/16 4:45 PM, Christian Koenning wrote: >>>>>> >>>>>> Thanks Joel, >>>>>> >>>>>> thanks for confirming flow correlation (L4) is expected as usual, >>>>>> even with ingress and egress on two different Service Path IDs. >>>>>> The question of overloading address space tried to clarify the >>>>>> (rare) the situation where 2 endpoint pairs have the same >>>>>> addresses and have agreed on the same src/dst port/protocol, >>>>>> which leads to flow collisions. >>>>>> >>>>>> You mention that Service Path ID will now allow to reuse- >>>>>> /duplication. >>>>>> >>>>>> However, you mentioned that metadata will provide address reuse- >>>>>> / duplication. Therefore the flow correlation would need to >>>>>> happen on including the metadata as part of the tuple as well. >>>>>> >>>>>> Also, allow me to ask if we expect ingress and egress Service >>>>>> Path IDs on the same transport/tunnel ? >>>>>> >>>>>> Many Thanks >>>>>> >>>>>> Christian Koenning -- F5 Networks Inc. christian@f5.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On 17/05/2016, 21:07, "Joel M. Halpern" >>>>>>> wrote: >>>>>>> >>>>>>> Correlation of packets in two directions for an SF which works >>>>>>> seems to require that the SF know how to correlate packets. Id >>>>>>> does not need to look at the SPI for that, since SPI are >>>>>>> coarser than flow. It may need to look at metadata (such as >>>>>>> subscriber identity) if the SF is inside a domain where IP >>>>>>> addresses are reused (NAT being a service function itself, so >>>>>>> one could be on the reuse side of a NAT.) >>>>>>> >>>>>>> I am not sure what you are referring to by address namespaces. >>>>>>> SPIs do not segregate subscribers, nor are they qualifiers for >>>>>>> disambiguating addresses where NAT is in use. Metadata in the >>>>>>> packet is used for such disambiguation. So, in the presence of >>>>>>> suitable metadata, SFC and NSH support inner (subscriber) >>>>>>> address reuse / duplication. NAT is an envisioned service >>>>>>> function. Just don't try to use the SPI as the key. It won't >>>>>>> tell you what you need. >>>>>>> >>>>>>> Yours, Joel >>>>>>> >>>>>>>> On 5/17/16 4:02 PM, Christian Koenning wrote: Thanks Joel, >>>>>>>> >>>>>>>> that is where I was getting confused. >>>>>>>> >>>>>>>> When looking e.g. at a stateful Service Function (SF), there >>>>>>>> needs to be an instruction which two of the Service Path >>>>>>>> Identifiers co-releate in order to establish state. >>>>>>>> >>>>>>>> >>>>>>>> Further to that, could you define if Service Path Identifiers >>>>>>>> allows for overloading of address namespace? >>>>>>>> >>>>>>>> Please allow us to clarify this. >>>>>>>> >>>>>>>> Many Thanks >>>>>>>> >>>>>>>> Christian Koenning -- F5 Networks Inc. christian@f5.com >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 17/05/2016, 20:57, "Joel M. Halpern" >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Most of us have assumed that a bi-directional symmetric >>>>>>>>> path pair is set up by control, and has separate Service >>>>>>>>> Path IDs (and indicies) in each direction. This does lead >>>>>>>>> to a need for service functions which originate reverse >>>>>>>>> direction packets to have a means to get the correct SPI / >>>>>>>>> Index in place for those packets. There are drafts >>>>>>>>> discussing approaches to that question. >>>>>>>>> >>>>>>>>> Yours, Joel >>>>>>>>> >>>>>>>>>> On 5/17/16 3:49 PM, Christian Koenning wrote: Good >>>>>>>>>> Evening, >>>>>>>>>> >>>>>>>>>> looking at RFC 7665 Service Function Chaining (SFC) >>>>>>>>>> Architecture https://tools.ietf.org/html/rfc7665 >>>>>>>>>> >>>>>>>>>> there is a clear definition of chain symetry >>>>>>>>>> >>>>>>>>>> " 2.2. Service Function Chain Symmetry >>>>>>>>>> >>>>>>>>>> SFCs may be unidirectional or bidirectional. A >>>>>>>>>> unidirectional SFC requires that traffic be forwarded >>>>>>>>>> through the ordered SFs in one direction (sf1 -> sf2 -> >>>>>>>>>> sf3), whereas a bidirectional SFC requires a symmetric >>>>>>>>>> path (sf1 -> sf2 -> sf3 and sf3 -> sf2 -> sf1), and in >>>>>>>>>> which the SF instances are the same in opposite >>>>>>>>>> directions. A hybrid SFC has attributes of both >>>>>>>>>> unidirectional and bidirectional SFCs; that is to say >>>>>>>>>> some SFs require symmetric traffic, whereas other SFs do >>>>>>>>>> not process reverse traffic or are independent of the >>>>>>>>>> corresponding forward traffic. >>>>>>>>>> >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> Further, there are state trade-offs in symmetry. >>>>>>>>>> Symmetry may be realized in several ways depending on the >>>>>>>>>> SFF and classifier functionality. In some cases, >>>>>>>>>> "mirrored" classification (i.e., from Source to >>>>>>>>>> Destination and from Destination to Source) policy may >>>>>>>>>> be deployed, whereas in others shared state between >>>>>>>>>> classifiers may be used to ensure that symmetric flows >>>>>>>>>> are correctly identified, then steered along the required >>>>>>>>>> SFP. At a high level, there are various common cases. >>>>>>>>>> In a non-exhaustive way, there can be for example: >>>>>>>>>> >>>>>>>>>> o A single classifier (or a small number of >>>>>>>>>> classifiers), in which case both incoming and outgoing >>>>>>>>>> flows could be recognized at the same classifier, so the >>>>>>>>>> synchronization would be feasible by internal mechanisms >>>>>>>>>> internal to the classifier. >>>>>>>>>> >>>>>>>>>> o Stateful classifiers where several classifiers may be >>>>>>>>>> clustered and share state. >>>>>>>>>> >>>>>>>>>> o Fully distributed classifiers, where synchronization >>>>>>>>>> needs to be provided through unspecified means. >>>>>>>>>> >>>>>>>>>> o A classifier that learns state from the egress >>>>>>>>>> packets/flows that is then used to provide state for the >>>>>>>>>> return packets/flow. >>>>>>>>>> >>>>>>>>>> o Symmetry may also be provided by stateful forwarding >>>>>>>>>> logic in the SFF in some implementations. >>>>>>>>>> >>>>>>>>>> This is a non-comprehensive list of common cases. " >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> However, when looking at this together with Network >>>>>>>>>> Service Header draft-ietf-sfc-nsh-04.txt >>>>>>>>>> https://tools.ietf.org/html/draft-ietf-sfc-nsh-04 >>>>>>>>>> >>>>>>>>>> 3.3. Service Path Header >>>>>>>>>> >>>>>>>>>> " Service Path Identifier (SPI): identifies a service >>>>>>>>>> path. Participating nodes MUST use this identifier for >>>>>>>>>> Service Function Path selection. " >>>>>>>>>> >>>>>>>>>> there is no notion of symmetry. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Can you please confirm that a bidirectional Service >>>>>>>>>> Function Chain will be represented by one single Service >>>>>>>>>> Path Identifier, ingress symmetric to egress ? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Please allow us to clarify this. >>>>>>>>>> >>>>>>>>>> Many Thanks >>>>>>>>>> >>>>>>>>>> Christian Koenning -- F5 Networks Inc. christian@f5.com >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ sfc >>>>>>>>>> mailing list sfc@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>> >>>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Tue May 17 23:10:43 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E4712D0B1 for ; Tue, 17 May 2016 23:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 5WPviaDEsuPO for ; Tue, 17 May 2016 23:10:41 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC6612B047 for ; Tue, 17 May 2016 23:10:33 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 632CE402C0; Wed, 18 May 2016 08:10:32 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 3B71B1A0062; Wed, 18 May 2016 08:10:32 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0294.000; Wed, 18 May 2016 08:10:31 +0200 From: To: "Jim Guichard (jguichar)" , Martin Stiemerling , "sfc@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt Thread-Index: AQHRrBnorsE3n3ea8ESTJLAGtYIQrp+4gacAgABIV4CABC9mAIAAguMAgAC2wvA= Date: Wed, 18 May 2016 06:10:30 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D763CC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <20160512064455.15167.2456.idtracker@ietfa.amsl.com> <6a339336-a3df-6044-4c66-7a48b869670f@gmail.com> <787AE7BB302AE849A7480A190F8B933008D7585A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 06:10:43 -0000 Hi Jim, Thank you for clarifying your concern.=20 RFC7665 does not exclude that additional information may be used with the S= FP-id to make SFF forwarding decisions. Also, RFC7665 acknowledges that mul= tiple choices may be allowed in an SFF. See this excerpt, for example: =20 SFFs maintain the requisite SFP forwarding information. SFP forwarding information is associated with a service path identifier ^^^^^^^^^^^^^ that is used to uniquely identify an SFP. The service forwarding state enables an SFF to identify which SFs of a given SFP should be applied, and in what order, as traffic flows through the associated SFP. While there may appear to the SFF to be only one available way to deliver the given SF, there may also be multiple choices allowed ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = =20 by the constraints of the SFP. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Section 4.10.4 does not violate RFC7665 because it assumes that the forward= ing information is associated with SFP-id. It does not say that additional = information MUST be supported other than SFP-id, or other information MUST = be supported in addition to the SFP-id, but that some additional informatio= n MIGHT be needed to constrain the SFP (that is still uniquely identified b= y an SFP-id) for deployments requiring to control the full sequence of SFFs= /SFs. The text cites some examples of such additional constraints. Section 4.10.4 discusses how cp can be used to provision SFFs with addition= al constraints + how to it helps to retrieve the capabilities of SFFs.=20 You said:=20 > I suggest that the text is silent on whether the ingress interface has > context to the SFF - its an implementation/deployment decision. I see that you are not conformable with Figure 2 (despite the text is clear= this is an example). The intent of that figure is to illustrate the use of= "match condition/action" cited in the text. =20 Would you be OK if that Figure is removed? Thank you. Cheers, Med > -----Message d'origine----- > De=A0: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > Envoy=E9=A0: mardi 17 mai 2016 19:31 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.org > Objet=A0: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt >=20 > Hi Med, >=20 > My concern (as chair) is with Figure 2 (and all of the text surrounding > it) which suggests that the forwarding is based on incoming SFP-id *and* > ingress port (or any of the other criteria listed). >=20 > This is misleading based upon RFC7665 which says the SFF forwards packets > based upon the information conveyed within the SFC encapsulation (see > https://tools.ietf.org/html/rfc7665#section-4.3) and the SFC encapsulatio= n > document (see > https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-7). >=20 > I suggest that the text is silent on whether the ingress interface has > context to the SFF - its an implementation/deployment decision. >=20 > Jim >=20 >=20 > On 5/17/16, 1:42 AM, "mohamed.boucadair@orange.com" > wrote: >=20 > >Hi Jim, > > > >I believe all your comments for section 4.10.5 (-04) (section 4.10.4 in > >-05) have been addressed. > > > >For the record, Andy shared a proposal here > >(http://www.ietf.org/mail-archive/web/sfc/current/msg04616.html) while I > >send a text proposal here > >(http://www.ietf.org/mail-archive/web/sfc/current/msg04651.html). These > >changes were implemented in -05 given that no objections were raised > >against them. > > > >Also, the old section 4.10.4 was removed as per one of your comments. > > > >Applying policies on the full aggregate (sfp-id) is the default mode. Bu= t > >for the particular case of this section (that is about "Fully Controlled > >SFF/SF Sequence for a SFP"), there might be deployments where it is > >appropriate to allow for local enforcement of polices that are more > >fine-grained (TE, for example). This section does not specify a new sfc > >encapsulation or calls for recommendation how forwarding must be > >achieved. It does discuss some information that can be passed via the C2 > >interface if additional information is required to achieve some TE goals= . > > > >Cheers, > >Med > > > >> -----Message d'origine----- > >> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard > >> (jguichar) > >> Envoy=E9 : samedi 14 mai 2016 19:48 > >> =C0 : Martin Stiemerling; sfc@ietf.org > >> Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt > >> > >> I would like to see my comments addressed for section 4.10.4. > >> > >> Our charter calls for a single SFC encapsulation and that is being > >> documented in draft-ietf-sfc-nsh. The text within this section suggest= s > >> that forwarding can be enabled using an SFP-id and some other conditio= n > >> such as input port etc. This is inaccurate based upon the SFC > >> encapsulation as well as our WG charter. There is no mention of the SF= C > >> encapsulation or the fact that the NSH base header is the method used > >>for > >> forwarding; note that the most common forwarding method (and the one > >> implemented in several places) is SFP-id + index - this is not even > >> mentioned!. In addition, this is a control plane document; there is no > >> need to talk about forwarding other than point to the SFC encapsulatio= n > >> document. > >> > >> For these reasons I would like to see this section removed from the > >> document. > >> > >> Jim > >> > >> > >> On 5/14/16, 5:28 AM, "sfc on behalf of Martin Stiemerling" > >> wrote: > >> > >> >Dear all, > >> > > >> >The authors have posted an updated version addressing the reviews out > >>of > >> >the WGLC. > >> > > >> >Please check until May 20th 5pm CEST if your comments have been > >> addressed. > >> > > >> >Thanks, > >> > > >> > Martin > >> > > >> >Am 12.05.16 um 08:44 schrieb internet-drafts@ietf.org: > >> >> > >> >> A New Internet-Draft is available from the on-line Internet-Drafts > >> >>directories. > >> >> This draft is a work item of the Service Function Chaining of the > >>IETF. > >> >> > >> >> Title : Service Function Chaining (SFC) Control > >>Plane > >> >>Components & Requirements > >> >> Author : Mohamed Boucadair > >> >> Filename : draft-ietf-sfc-control-plane-05.txt > >> >> Pages : 27 > >> >> Date : 2016-05-11 > >> >> > >> >> Abstract: > >> >> This document describes requirements for conveying information > >> >> between Service Function Chaining (SFC) control elements and SFC > >> data > >> >> plane functional elements. Also, this document identifies a set > >>of > >> >> control interfaces to interact with SFC-aware elements to > >>establish, > >> >> maintain or recover service function chains. This document does > >>not > >> >> specify protocols nor extensions to existing protocols. > >> >> > >> >> This document exclusively focuses on SFC deployments that are > >>under > >> >> the responsibility of a single administrative entity. > >>Inter-domain > >> >> considerations are out of scope. > >> >> > >> >> > >> >> The IETF datatracker status page for this draft is: > >> >> https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ > >> >> > >> >> There's also a htmlized version available at: > >> >> https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05 > >> >> > >> >> A diff from the previous version is available at: > >> >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-control-plane-05 > >> >> > >> >> > >> >> 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/ > >> >> > >> >> _______________________________________________ > >> >> I-D-Announce mailing list > >> >> I-D-Announce@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/i-d-announce > >> >> Internet-Draft directories: http://www.ietf.org/shadow.html > >> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> >> > >> > > >> >_______________________________________________ > >> >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 May 18 04:42:00 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88BBA12D0CE for ; Wed, 18 May 2016 04:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 wizrdVfT2r3a for ; Wed, 18 May 2016 04:41:55 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 354BD12D0C8 for ; Wed, 18 May 2016 04:41:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27536; q=dns/txt; s=iport; t=1463571715; x=1464781315; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=rgxd/uTcuLsEglPWhDzpnVhyU3LzXVWNcy0GJFEmtpk=; b=HE+ygG61Efv4AQi1+Ytx3qQCPYbNb3Ak5mA9Q7lbcryfmCK8m3qds2Rh 8GI2Lp8g5A+QIlFDDOo2eB12xoZi0fNi+uI1NAXkF33HNcd/W3k6b4o2x Clu7etYm54KUtuVfBk6PG8w5l3ZR6ObOGZIEXu5K3yGnl6EacioVV3fxP s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAgClVDxX/4kNJK1TCoJsS1V+BoQgq?= =?us-ascii?q?WSLaQENgXUXAQqFbwKBPjgUAQEBAQEBAWUnhEIBAQEDAQEBAWQHGwIBCBggBwc?= =?us-ascii?q?hBgsUEQIEARIJiAwDDwgOvXwNhB8BAQEBAQEBAwEBAQEBAQEBAR6GJYRNgkOBV?= =?us-ascii?q?AsBASsmhSMFkxwVhEkxAYV/gniDL4F5gWlOhAGEJoMhgRuHYRSHUwEeAQFCggY?= =?us-ascii?q?cgUtuAYZQNn8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,328,1459814400"; d="scan'208,217";a="103801111" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 May 2016 11:41:53 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4IBfr7W004302 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 18 May 2016 11:41:53 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 18 May 2016 06:41:52 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1104.009; Wed, 18 May 2016 06:41:52 -0500 From: "Jim Guichard (jguichar)" To: "mohamed.boucadair@orange.com" , "Martin Stiemerling" , "sfc@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt Thread-Index: AQHRrBnorsE3n3ea8ESTJLAGtYIQrp+4gacAgABIV4CABC9mAIAAguMAgAC2wvCAAHoMAA== Date: Wed, 18 May 2016 11:41:52 +0000 Message-ID: References: <20160512064455.15167.2456.idtracker@ietfa.amsl.com> <6a339336-a3df-6044-4c66-7a48b869670f@gmail.com> <787AE7BB302AE849A7480A190F8B933008D7585A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D763CC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D763CC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.43.179] Content-Type: multipart/alternative; boundary="_000_D361CADA4F61Djguicharciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 11:41:57 -0000 --_000_D361CADA4F61Djguicharciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Med, Yes, if you can remove Figure 2 and also the text "There are multiple diffe= rent steering policies for one flow within one SFF and each set of steering= policies is specific for an ingress port=94. In addition, can you also make it clear in the text that the SFP-id is carr= ied within the SFC encapsulation. Suggested text: Old: For example, it could be the SFP-id together with any fields in the data pa= ckets, such as (non-exhaustive list): New: For example, it could be the SFP-id carried within the SFC encapsulation wi= th any fields in the data packets, such as (non-exhaustive list): Jim On 5/18/16, 2:10 AM, "mohamed.boucadair@orange.com" > wrote: Hi Jim, Thank you for clarifying your concern. RFC7665 does not exclude that additional information may be used with the S= FP-id to make SFF forwarding decisions. Also, RFC7665 acknowledges that mul= tiple choices may be allowed in an SFF. See this excerpt, for example: SFFs maintain the requisite SFP forwarding information. SFP forwarding information is associated with a service path identifier ^^^^^^^^^^^^^ that is used to uniquely identify an SFP. The service forwarding state enables an SFF to identify which SFs of a given SFP should be applied, and in what order, as traffic flows through the associated SFP. While there may appear to the SFF to be only one available way to deliver the given SF, there may also be multiple choices allowed ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ by the constraints of the SFP. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Section 4.10.4 does not violate RFC7665 because it assumes that the forward= ing information is associated with SFP-id. It does not say that additional = information MUST be supported other than SFP-id, or other information MUST = be supported in addition to the SFP-id, but that some additional informatio= n MIGHT be needed to constrain the SFP (that is still uniquely identified b= y an SFP-id) for deployments requiring to control the full sequence of SFFs= /SFs. The text cites some examples of such additional constraints. Section 4.10.4 discusses how cp can be used to provision SFFs with addition= al constraints + how to it helps to retrieve the capabilities of SFFs. You said: I suggest that the text is silent on whether the ingress interface has context to the SFF - its an implementation/deployment decision. I see that you are not conformable with Figure 2 (despite the text is clear= this is an example). The intent of that figure is to illustrate the use of= "match condition/action" cited in the text. Would you be OK if that Figure is removed? Thank you. Cheers, Med -----Message d'origine----- De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Envoy=E9 : mardi 17 mai 2016 19:31 =C0 : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.org Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt Hi Med, My concern (as chair) is with Figure 2 (and all of the text surrounding it) which suggests that the forwarding is based on incoming SFP-id *and* ingress port (or any of the other criteria listed). This is misleading based upon RFC7665 which says the SFF forwards packets based upon the information conveyed within the SFC encapsulation (see https://tools.ietf.org/html/rfc7665#section-4.3) and the SFC encapsulation document (see https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-7). I suggest that the text is silent on whether the ingress interface has context to the SFF - its an implementation/deployment decision. Jim On 5/17/16, 1:42 AM, "mohamed.boucadair@orange.com" > wrote: >Hi Jim, > >I believe all your comments for section 4.10.5 (-04) (section 4.10.4 in >-05) have been addressed. > >For the record, Andy shared a proposal here >(http://www.ietf.org/mail-archive/web/sfc/current/msg04616.html) while I >send a text proposal here >(http://www.ietf.org/mail-archive/web/sfc/current/msg04651.html). These >changes were implemented in -05 given that no objections were raised >against them. > >Also, the old section 4.10.4 was removed as per one of your comments. > >Applying policies on the full aggregate (sfp-id) is the default mode. But >for the particular case of this section (that is about "Fully Controlled >SFF/SF Sequence for a SFP"), there might be deployments where it is >appropriate to allow for local enforcement of polices that are more >fine-grained (TE, for example). This section does not specify a new sfc >encapsulation or calls for recommendation how forwarding must be >achieved. It does discuss some information that can be passed via the C2 >interface if additional information is required to achieve some TE goals. > >Cheers, >Med > >> -----Message d'origine----- >> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard >> (jguichar) >> Envoy=E9 : samedi 14 mai 2016 19:48 >> =C0 : Martin Stiemerling; sfc@ietf.org >> Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt >> >> I would like to see my comments addressed for section 4.10.4. >> >> Our charter calls for a single SFC encapsulation and that is being >> documented in draft-ietf-sfc-nsh. The text within this section suggests >> that forwarding can be enabled using an SFP-id and some other condition >> such as input port etc. This is inaccurate based upon the SFC >> encapsulation as well as our WG charter. There is no mention of the SFC >> encapsulation or the fact that the NSH base header is the method used >>for >> forwarding; note that the most common forwarding method (and the one >> implemented in several places) is SFP-id + index - this is not even >> mentioned!. In addition, this is a control plane document; there is no >> need to talk about forwarding other than point to the SFC encapsulation >> document. >> >> For these reasons I would like to see this section removed from the >> document. >> >> Jim >> >> >> On 5/14/16, 5:28 AM, "sfc on behalf of Martin Stiemerling" >> on behalf of mls.ietf= @gmail.com> wrote: >> >> >Dear all, >> > >> >The authors have posted an updated version addressing the reviews out >>of >> >the WGLC. >> > >> >Please check until May 20th 5pm CEST if your comments have been >> addressed. >> > >> >Thanks, >> > >> > Martin >> > >> >Am 12.05.16 um 08:44 schrieb internet-drafts@ietf.org: >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> >>directories. >> >> This draft is a work item of the Service Function Chaining of the >>IETF. >> >> >> >> Title : Service Function Chaining (SFC) Control >>Plane >> >>Components & Requirements >> >> Author : Mohamed Boucadair >> >> Filename : draft-ietf-sfc-control-plane-05.txt >> >> Pages : 27 >> >> Date : 2016-05-11 >> >> >> >> Abstract: >> >> This document describes requirements for conveying information >> >> between Service Function Chaining (SFC) control elements and SFC >> data >> >> plane functional elements. Also, this document identifies a set >>of >> >> control interfaces to interact with SFC-aware elements to >>establish, >> >> maintain or recover service function chains. This document does >>not >> >> specify protocols nor extensions to existing protocols. >> >> >> >> This document exclusively focuses on SFC deployments that are >>under >> >> the responsibility of a single administrative entity. >>Inter-domain >> >> considerations are out of scope. >> >> >> >> >> >> The IETF datatracker status page for this draft is: >> >> https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ >> >> >> >> There's also a htmlized version available at: >> >> https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05 >> >> >> >> A diff from the previous version is available at: >> >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-control-plane-05 >> >> >> >> >> >> 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/ >> >> >> >> _______________________________________________ >> >> I-D-Announce mailing list >> >> I-D-Announce@ietf.org >> >> https://www.ietf.org/mailman/listinfo/i-d-announce >> >> Internet-Draft directories: http://www.ietf.org/shadow.html >> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> > >> >_______________________________________________ >> >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_D361CADA4F61Djguicharciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <47FB5109EBE95040A14C988B67625A36@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Med,

Yes, if you can remove Fig= ure 2 and also the text "There are multiple different steering policie= s for one flow within one SFF and each set of steering policies is specific for an ingress port= =94.

In addition, can you also = make it clear in the text that the SFP-id is carried within the SFC encapsu= lation. Suggested text:

Old:
 
For example, it could be the SFP-id together with any fi= elds in the data packets, such as (n= on-exhaustive list):

New:

For example, it coul= d be the SFP-id carried within the SFC encapsulation with any fields in the data packets, su= ch as (non-exhaustive list):

Jim


Hi Jim,

Thank you for clarifying your concern.

RFC7665 does not exclude that additional information may be used with = the SFP-id to make SFF forwarding decisions. Also, RFC7665 acknowledges tha= t multiple choices may be allowed in an SFF. See this excerpt, for example:=   

   SFFs maintain the requisite SFP forwarding information.&n= bsp; SFP
   forwarding information is associated with a service path = identifier
           &nbs= p;            &= nbsp; ^^^^^^^^^^^^^
   that is used to uniquely identify an SFP.  The = service forwarding
   state enables an SFF to identify which SFs of a given SFP= should be
   applied, and in what order, as traffic flows through the = associated
   SFP.  While there may appear to the SFF to be o= nly one available way
   to deliver the given SF, there may also be multiple choic= es allowed
           &nbs= p;            &= nbsp;   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ &nbs= p;  
   by the constraints of the SFP.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Section 4.10.4 does not violate RFC7665 because it assumes that the fo= rwarding information is associated with SFP-id. It does not say that additi= onal information MUST be supported other than SFP-id, or other information = MUST be supported in addition to the SFP-id, but that some additional information MIGHT be needed to constr= ain the SFP (that is still uniquely identified by an SFP-id) for deployment= s requiring to control the full sequence of SFFs/SFs. The text cites some e= xamples of such additional constraints.

Section 4.10.4 discusses how cp can be used to provision SFFs with add= itional constraints + how to it helps to retrieve the capabilities of S= FFs.

You said:

I suggest that the text is silent on whether the ingress interface has=
context to the SFF - its an implementation/deployment decision.

I see that you are not conformable with Figure 2 (despite the text is = clear this is an example). The intent of that figure is to illustrate the u= se of "match condition/action" cited in the text.  

Would you be OK if that Figure is removed?

Thank you.

Cheers,
Med

-----Message d'origine-----
De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
Envoy=E9 : mardi 17 mai 2016 19:31
=C0 : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.org
Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt=
Hi Med,
My concern (as chair) is with Figure 2 (and all of the text surroundin= g
it) which suggests that the forwarding is based on incoming SFP-id *an= d*
ingress port (or any of the other criteria listed).
This is misleading based upon RFC7665 which says the SFF forwards pack= ets
based upon the information conveyed within the SFC encapsulation (see<= /div>
document (see
I suggest that the text is silent on whether the ingress interface has=
context to the SFF - its an implementation/deployment decision.
Jim
On 5/17/16, 1:42 AM, "mohamed.boucadair@orange.com"
>Hi Jim,
>
>I believe all your comments for section 4.10.5 (-04) (section 4.10= .4 in
>-05) have been addressed.
>
>For the record, Andy shared a proposal here
>send a text proposal here
>changes were implemented in -05 given that no objections were rais= ed
>against them.
>
>Also, the old section 4.10.4 was removed as per one of your commen= ts.
>
>Applying policies on the full aggregate (sfp-id) is the default mo= de. But
>for the particular case of this section (that is about "Fully= Controlled
>SFF/SF Sequence for a SFP"), there might be deployments where= it is
>appropriate to allow for local enforcement of polices that are mor= e
>fine-grained (TE, for example).  This section does not s= pecify a new sfc
>encapsulation or calls for recommendation how forwarding must be
>achieved. It does discuss some information that can be passed via = the C2
>interface if additional information is required to achieve some TE= goals.
>
>Cheers,
>Med
>
>> -----Message d'origine-----
>> De : sfc [mailto:sfc-= bounces@ietf.org] De la part de Jim Guichard
>> (jguichar)
>> Envoy=E9 : samedi 14 mai 2016 19:48
>> =C0 : Martin Stiemerling; sfc= @ietf.org
>> Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05= .txt
>>
>> I would like to see my comments addressed for section 4.10.4.=
>>
>> Our charter calls for a single SFC encapsulation and that is = being
>> documented in draft-ietf-sfc-nsh. The text within this sectio= n suggests
>> that forwarding can be enabled using an SFP-id and some other= condition
>> such as input port etc. This is inaccurate based upon the SFC=
>> encapsulation as well as our WG charter. There is no mention = of the SFC
>> encapsulation or the fact that the NSH base header is the met= hod used
>>for
>> forwarding; note that the most common forwarding method (and = the one
>> implemented in several places) is SFP-id + index - this i= s not even
>> mentioned!. In addition, this is a control plane document; th= ere is no
>> need to talk about forwarding other than point to the SFC enc= apsulation
>> document.
>>
>> For these reasons I would like to see this section removed fr= om the
>> document.
>>
>> Jim
>>
>>
>> On 5/14/16, 5:28 AM, "sfc on behalf of Martin Stiemerlin= g"
>> <sfc-bounces@ietf.= org on behalf of mls.ietf@gmail.com> wrote:
>>
>> >Dear all,
>> >
>> >The authors have posted an updated version addressing the= reviews out
>>of
>> >the WGLC.
>> >
>> >Please check until May 20th 5pm CEST if your comments hav= e been
>> addressed.
>> >
>> >Thanks,
>> >
>> >    Martin
>> >
>> >Am 12.05.16 um 08:44 schrieb internet-drafts@ietf.org:
>> >>
>> >> A New Internet-Draft is available from the on-line I= nternet-Drafts
>> >>directories.
>> >> This draft is a work item of the Service Function Ch= aining of the
>>IETF.
>> >>
>> >>         Titl= e           : Service Fun= ction Chaining (SFC) Control
>>Plane
>> >>Components & Requirements
>> >>         Auth= or          : Mohamed Bou= cadair
>> >> Filename        : draft= -ietf-sfc-control-plane-05.txt
>> >> Pages         &nbs= p; : 27
>> >> Date          = ;  : 2016-05-11
>> >>
>> >> Abstract:
>> >>    This document describes requi= rements for conveying information
>> >>    between Service Function Chai= ning (SFC) control elements and SFC
>> data
>> >>    plane functional elements.&nb= sp; Also, this document identifies a set
>>of
>> >>    control interfaces to interac= t with SFC-aware elements to
>>establish,
>> >>    maintain or recover service f= unction chains.  This document does
>>not
>> >>    specify protocols nor extensi= ons to existing protocols.
>> >>
>> >>    This document exclusively foc= uses on SFC deployments that are
>>under
>> >>    the responsibility of a singl= e administrative entity.
>>Inter-domain
>> >>    considerations are out of sco= pe.
>> >>
>> >>
>> >> The IETF datatracker status page for this draft is:<= /div>
>> >>
>> >> There's also a htmlized version available at:
>> >>
>> >> A diff from the previous version is available at:
>> >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-control-plane-05
>> >>
>> >>
>> >> Please note that it may take a couple of minutes fro= m 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:
>> >>
>> >> _______________________________________________
>> >> I-D-Announce mailing list
>> >> Internet-Draft directories: http://www.ietf.org/shadow.html
>> >>
>> >
>> >_______________________________________________
>> >sfc mailing list
>>
>> _______________________________________________
>> sfc mailing list


--_000_D361CADA4F61Djguicharciscocom_-- From nobody Wed May 18 06:01:23 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E2212D148 for ; Wed, 18 May 2016 06:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 SmyQ4N53XBS8 for ; Wed, 18 May 2016 06:01:16 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFC3312D160 for ; Wed, 18 May 2016 06:01:06 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 035C32DCB94; Wed, 18 May 2016 15:01:05 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.27]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id CB78335C082; Wed, 18 May 2016 15:01:04 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0294.000; Wed, 18 May 2016 15:01:04 +0200 From: To: "Jim Guichard (jguichar)" , Martin Stiemerling , "sfc@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt Thread-Index: AQHRrBnorsE3n3ea8ESTJLAGtYIQrp+4gacAgABIV4CABC9mAIAAguMAgAC2wvCAAHoMAIAABJbg Date: Wed, 18 May 2016 13:01:04 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D76703@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <20160512064455.15167.2456.idtracker@ietfa.amsl.com> <6a339336-a3df-6044-4c66-7a48b869670f@gmail.com> <787AE7BB302AE849A7480A190F8B933008D7585A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D763CC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008D76703OPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.5.18.115415 Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 13:01:22 -0000 --_000_787AE7BB302AE849A7480A190F8B933008D76703OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Works for me. Unless there is an objection, these changes will be implemented in the next= revision. Thank you. Cheers, Med De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Envoy=E9 : mercredi 18 mai 2016 13:42 =C0 : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.org Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt Hi Med, Yes, if you can remove Figure 2 and also the text "There are multiple diffe= rent steering policies for one flow within one SFF and each set of steering= policies is specific for an ingress port". In addition, can you also make it clear in the text that the SFP-id is carr= ied within the SFC encapsulation. Suggested text: Old: For example, it could be the SFP-id together with any fields in the data pa= ckets, such as (non-exhaustive list): New: For example, it could be the SFP-id carried within the SFC encapsulation wi= th any fields in the data packets, such as (non-exhaustive list): Jim On 5/18/16, 2:10 AM, "mohamed.boucadair@orange.com" > wrote: Hi Jim, Thank you for clarifying your concern. RFC7665 does not exclude that additional information may be used with the S= FP-id to make SFF forwarding decisions. Also, RFC7665 acknowledges that mul= tiple choices may be allowed in an SFF. See this excerpt, for example: SFFs maintain the requisite SFP forwarding information. SFP forwarding information is associated with a service path identifier ^^^^^^^^^^^^^ that is used to uniquely identify an SFP. The service forwarding state enables an SFF to identify which SFs of a given SFP should be applied, and in what order, as traffic flows through the associated SFP. While there may appear to the SFF to be only one available way to deliver the given SF, there may also be multiple choices allowed ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ by the constraints of the SFP. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Section 4.10.4 does not violate RFC7665 because it assumes that the forward= ing information is associated with SFP-id. It does not say that additional = information MUST be supported other than SFP-id, or other information MUST = be supported in addition to the SFP-id, but that some additional informatio= n MIGHT be needed to constrain the SFP (that is still uniquely identified b= y an SFP-id) for deployments requiring to control the full sequence of SFFs= /SFs. The text cites some examples of such additional constraints. Section 4.10.4 discusses how cp can be used to provision SFFs with addition= al constraints + how to it helps to retrieve the capabilities of SFFs. You said: I suggest that the text is silent on whether the ingress interface has context to the SFF - its an implementation/deployment decision. I see that you are not conformable with Figure 2 (despite the text is clear= this is an example). The intent of that figure is to illustrate the use of= "match condition/action" cited in the text. Would you be OK if that Figure is removed? Thank you. Cheers, Med -----Message d'origine----- De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Envoy=E9 : mardi 17 mai 2016 19:31 =C0 : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.org Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt Hi Med, My concern (as chair) is with Figure 2 (and all of the text surrounding it) which suggests that the forwarding is based on incoming SFP-id *and* ingress port (or any of the other criteria listed). This is misleading based upon RFC7665 which says the SFF forwards packets based upon the information conveyed within the SFC encapsulation (see https://tools.ietf.org/html/rfc7665#section-4.3) and the SFC encapsulation document (see https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-7). I suggest that the text is silent on whether the ingress interface has context to the SFF - its an implementation/deployment decision. Jim On 5/17/16, 1:42 AM, "mohamed.boucadair@orange.com" > wrote: >Hi Jim, > >I believe all your comments for section 4.10.5 (-04) (section 4.10.4 in >-05) have been addressed. > >For the record, Andy shared a proposal here >(http://www.ietf.org/mail-archive/web/sfc/current/msg04616.html) while I >send a text proposal here >(http://www.ietf.org/mail-archive/web/sfc/current/msg04651.html). These >changes were implemented in -05 given that no objections were raised >against them. > >Also, the old section 4.10.4 was removed as per one of your comments. > >Applying policies on the full aggregate (sfp-id) is the default mode. But >for the particular case of this section (that is about "Fully Controlled >SFF/SF Sequence for a SFP"), there might be deployments where it is >appropriate to allow for local enforcement of polices that are more >fine-grained (TE, for example). This section does not specify a new sfc >encapsulation or calls for recommendation how forwarding must be >achieved. It does discuss some information that can be passed via the C2 >interface if additional information is required to achieve some TE goals. > >Cheers, >Med > >> -----Message d'origine----- >> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard >> (jguichar) >> Envoy=E9 : samedi 14 mai 2016 19:48 >> =C0 : Martin Stiemerling; sfc@ietf.org >> Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt >> >> I would like to see my comments addressed for section 4.10.4. >> >> Our charter calls for a single SFC encapsulation and that is being >> documented in draft-ietf-sfc-nsh. The text within this section suggests >> that forwarding can be enabled using an SFP-id and some other condition >> such as input port etc. This is inaccurate based upon the SFC >> encapsulation as well as our WG charter. There is no mention of the SFC >> encapsulation or the fact that the NSH base header is the method used >>for >> forwarding; note that the most common forwarding method (and the one >> implemented in several places) is SFP-id + index - this is not even >> mentioned!. In addition, this is a control plane document; there is no >> need to talk about forwarding other than point to the SFC encapsulation >> document. >> >> For these reasons I would like to see this section removed from the >> document. >> >> Jim >> >> >> On 5/14/16, 5:28 AM, "sfc on behalf of Martin Stiemerling" >> on behalf of mls.ietf= @gmail.com> wrote: >> >> >Dear all, >> > >> >The authors have posted an updated version addressing the reviews out >>of >> >the WGLC. >> > >> >Please check until May 20th 5pm CEST if your comments have been >> addressed. >> > >> >Thanks, >> > >> > Martin >> > >> >Am 12.05.16 um 08:44 schrieb internet-drafts@ietf.org: >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> >>directories. >> >> This draft is a work item of the Service Function Chaining of the >>IETF. >> >> >> >> Title : Service Function Chaining (SFC) Control >>Plane >> >>Components & Requirements >> >> Author : Mohamed Boucadair >> >> Filename : draft-ietf-sfc-control-plane-05.txt >> >> Pages : 27 >> >> Date : 2016-05-11 >> >> >> >> Abstract: >> >> This document describes requirements for conveying information >> >> between Service Function Chaining (SFC) control elements and SFC >> data >> >> plane functional elements. Also, this document identifies a set >>of >> >> control interfaces to interact with SFC-aware elements to >>establish, >> >> maintain or recover service function chains. This document does >>not >> >> specify protocols nor extensions to existing protocols. >> >> >> >> This document exclusively focuses on SFC deployments that are >>under >> >> the responsibility of a single administrative entity. >>Inter-domain >> >> considerations are out of scope. >> >> >> >> >> >> The IETF datatracker status page for this draft is: >> >> https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ >> >> >> >> There's also a htmlized version available at: >> >> https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05 >> >> >> >> A diff from the previous version is available at: >> >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-control-plane-05 >> >> >> >> >> >> 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/ >> >> >> >> _______________________________________________ >> >> I-D-Announce mailing list >> >> I-D-Announce@ietf.org >> >> https://www.ietf.org/mailman/listinfo/i-d-announce >> >> Internet-Draft directories: http://www.ietf.org/shadow.html >> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> > >> >_______________________________________________ >> >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_787AE7BB302AE849A7480A190F8B933008D76703OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Works for me.

 

Unless there is an objection, t= hese changes will be implemented in the next revision.

 

Thank you.

 

Cheers,

Med

 

De : Jim = Guichard (jguichar) [mailto:jguichar@cisco.com]
Envoy=E9 : mercredi 18 mai 2016 13:42
=C0 : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.o= rg
Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.t= xt

 

Hi Med,

 

Yes, if you can remove Figu= re 2 and also the text "There are multiple different steering policies= for one flow within one SFF and each set of steering policies is specific for an ingress port= ”.

 

In addition, can you also m= ake it clear in the text that the SFP-id is carried within the SFC encapsul= ation. Suggested text:

 

Old:

 

For example, it could = be the SFP-id together with any fields in the data packets, such as (n= on-exhaustive list):



New:



For example, it could be th= e SFP-id carried within the SFC encapsulation with any fields in the data packets, su= ch as (non-exhaustive list):

 

Jim

 

 

Hi Jim,

 

Thank you for clarifying yo= ur concern.

 

RFC7665 does not exclude th= at additional information may be used with the SFP-id to make SFF forwardin= g decisions. Also, RFC7665 acknowledges that multiple choices may be allowed in an SFF. See this excerpt, for example:  <= /o:p>

 

   SFFs maintain = the requisite SFP forwarding information.  SFP<= /p>

   forwarding inf= ormation is associated with a service path identifier

    &nb= sp;            =          ^^^^^^^^^^^^^

   that is used t= o uniquely identify an SFP.  The service forwarding

   state enables = an SFF to identify which SFs of a given SFP should be

   applied, and i= n what order, as traffic flows through the associated

   SFP. &nbs= p;While there may appear to the SFF to be only one available way=

   to deliver the= given SF, there may also be multiple choices allowed

    &nb= sp;            =            ^^^^^^^^^= ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^    

   by the constra= ints of the SFP.

   ^^^^^^^^^^^^^^= ^^^^^^^^^^^^^^^^

 

Section 4.10.4 does not vio= late RFC7665 because it assumes that the forwarding information is associat= ed with SFP-id. It does not say that additional information MUST be supported other than SFP-id, or other information MUST be supporte= d in addition to the SFP-id, but that some additional information MIGHT be = needed to constrain the SFP (that is still uniquely identified by an SFP-id= ) for deployments requiring to control the full sequence of SFFs/SFs. The text cites some examples of such additi= onal constraints.

 

Section 4.10.4 discusses ho= w cp can be used to provision SFFs with additional constraints + how to= it helps to retrieve the capabilities of SFFs.

 

You said:

 

I suggest that the text is = silent on whether the ingress interface has

context to the SFF - its an= implementation/deployment decision.

 

I see that you are not conf= ormable with Figure 2 (despite the text is clear this is an example). The i= ntent of that figure is to illustrate the use of "match condition/action" cited in the text.  

 

Would you be OK if that Fig= ure is removed?

 

Thank you.

 

Cheers,

Med

 

-----Message d'origine-----=

De : Jim Guichard (jgu= ichar) [mailto:jguichar@cisco.com= ]

Envoy=E9 : mardi 17 ma= i 2016 19:31

=C0 : BOUCADAIR Mohame= d IMT/OLN; Martin Stiemerling; sfc@ietf.org

Objet : Re: [sfc] I-D = Action: draft-ietf-sfc-control-plane-05.txt

Hi Med,

My concern (as chair) is wi= th Figure 2 (and all of the text surrounding

it) which suggests that the= forwarding is based on incoming SFP-id *and*

ingress port (or any of the= other criteria listed).

This is misleading based up= on RFC7665 which says the SFF forwards packets

based upon the information = conveyed within the SFC encapsulation (see

document (see

I suggest that the text is = silent on whether the ingress interface has

context to the SFF - its an= implementation/deployment decision.

Jim

On 5/17/16, 1:42 AM, "= mohamed.boucadair@orange.co= m"

>Hi Jim,

> 

>I believe all your comm= ents for section 4.10.5 (-04) (section 4.10.4 in

>-05) have been addresse= d.

> 

>For the record, Andy sh= ared a proposal here

>send a text proposal he= re

>changes were implemente= d in -05 given that no objections were raised

>against them.

> 

>Also, the old section 4= .10.4 was removed as per one of your comments.

> 

>Applying policies on th= e full aggregate (sfp-id) is the default mode. But

>for the particular case= of this section (that is about "Fully Controlled

>SFF/SF Sequence for a S= FP"), there might be deployments where it is

>appropriate to allow fo= r local enforcement of polices that are more

>fine-grained (TE, for e= xample).  This section does not specify a new sfc

>encapsulation or calls = for recommendation how forwarding must be

>achieved. It does discu= ss some information that can be passed via the C2

>interface if additional= information is required to achieve some TE goals.

> 

>Cheers,

>Med

> 

>> -----Message d'ori= gine-----

>> De : sfc [mailto:sfc-bounces@ietf.org] De la par= t de Jim Guichard

>> (jguichar)

>> Envoy=E9 : samedi = 14 mai 2016 19:48

>> =C0 : Martin Stiem= erling; sfc@ietf.org

>> Objet : Re: [sfc] = I-D Action: draft-ietf-sfc-control-plane-05.txt

>> 

>> I would like to se= e my comments addressed for section 4.10.4.

>> 

>> Our charter calls = for a single SFC encapsulation and that is being

>> documented in draf= t-ietf-sfc-nsh. The text within this section suggests

>> that forwarding ca= n be enabled using an SFP-id and some other condition

>> such as input port= etc. This is inaccurate based upon the SFC

>> encapsulation as w= ell as our WG charter. There is no mention of the SFC

>> encapsulation or t= he fact that the NSH base header is the method used

>>for

>> forwarding; note t= hat the most common forwarding method (and the one

>> implemented in sev= eral places) is SFP-id + index - this is not even

>> mentioned!. In add= ition, this is a control plane document; there is no

>> need to talk about= forwarding other than point to the SFC encapsulation

>> document.

>> 

>> For these reasons = I would like to see this section removed from the

>> document.

>> 

>> Jim

>> 

>> 

>> On 5/14/16, 5:28 A= M, "sfc on behalf of Martin Stiemerling"

>> <sfc-bounces@ietf.org on behalf of mls.ietf@gmail.com> wrote:

>> 

>> >Dear all,=

>> >

>> >The authors ha= ve posted an updated version addressing the reviews out

>>of

>> >the WGLC.=

>> >

>> >Please check u= ntil May 20th 5pm CEST if your comments have been

>> addressed.

>> >

>> >Thanks,

>> >

>> >  &n= bsp; Martin

>> >

>> >Am 12.05.16 um= 08:44 schrieb internet-drafts@ietf.org:

>> >>

>> >> A New Int= ernet-Draft is available from the on-line Internet-Drafts=

>> >>directorie= s.

>> >> This draf= t is a work item of the Service Function Chaining of the<= /p>

>>IETF.

>> >>

>> >> &nbs= p;       Title     &= nbsp;     : Service Function Chaining (SFC) Control

>>Plane

>> >>Components= & Requirements

>> >> &nbs= p;       Author     =      : Mohamed Boucadair

>> >> Filename&= nbsp;       : draft-ietf-sfc-control-pla= ne-05.txt

>> >> Pages&nbs= p;          : 27

>> >> Date = ;           : 2016-0= 5-11

>> >>

>> >> Abstract:=

>> >> &nbs= p;  This document describes requirements for conveying informatio= n

>> >> &nbs= p;  between Service Function Chaining (SFC) control elements and = SFC

>> data

>> >> &nbs= p;  plane functional elements.  Also, this document ide= ntifies a set

>>of

>> >> &nbs= p;  control interfaces to interact with SFC-aware elements to

>>establish,

>> >> &nbs= p;  maintain or recover service function chains.  This = document does

>>not

>> >> &nbs= p;  specify protocols nor extensions to existing protocols.<= /o:p>

>> >>

>> >> &nbs= p;  This document exclusively focuses on SFC deployments that are=

>>under

>> >> &nbs= p;  the responsibility of a single administrative entity.

>>Inter-domain

>> >> &nbs= p;  considerations are out of scope.

>> >>

>> >>

>> >> The IETF = datatracker status page for this draft is:

>> >>

>> >> There's a= lso a htmlized version available at:

>> >>

>> >> A diff fr= om the previous version is available at:

>> >>

>> >>

>> >> Please no= te that it may take a couple of minutes from the time of<= /p>

>> >>submission=

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

>> >>

>> >> Internet-= Drafts are also available by anonymous FTP at:

>> >>

>> >> _________= ______________________________________

>> >> I-D-Annou= nce mailing list

>> >> Internet-= Draft directories: http://www.ietf.org/shadow.html=

>> >>

>> >

>> >______________= _________________________________

>> >sfc mailing li= st

>> 

>> __________________= _____________________________

>> sfc mailing list

 

 

--_000_787AE7BB302AE849A7480A190F8B933008D76703OPEXCLILMA3corp_-- From nobody Wed May 18 06:36:53 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2852712D17C for ; Wed, 18 May 2016 06:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8BPBNX9z25tW for ; Wed, 18 May 2016 06:36:48 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98A1412B050 for ; Wed, 18 May 2016 06:36:48 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id k142so76704964oib.1 for ; Wed, 18 May 2016 06:36:48 -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; bh=5C0jGWqv5/4j8ibPClE0Ts5BdQ2c7fpZp8U4asTK+GE=; b=oY+trufjw+svz72mqCN/uGDlylXTKATJpVu66yVa5+IG/1DSLPmcKrHRmTjasgw7sX zW3V4pElVwwzID7hVwJIBCJal//SnlBwEv3rdmP6FaP6xxuxuv6TiOkpHy6vDdGeP2o0 cgmepTi0JVRY9hpseqg8xO3xW4H8VRB5LVcHN+G7CGzsNIydkmsMhWgxKtQLWwaZk9mw 5MbmIXHmIcmLCQTsyLNT8x2idAR1aVnLEgwYxtmLU4zSGpbBIS8akRnrbW3gseIWymji ARsXxmYwMmz7HFgd05dP/p8LbNxF1Gq9yDD5mqrz6SFTWoOnqoVnmvhMKLzEET4uqTxJ oolw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5C0jGWqv5/4j8ibPClE0Ts5BdQ2c7fpZp8U4asTK+GE=; b=kwRkjiJR3fM37SWD4u4hQT4Ajwxe6ay4pv2ENjREls/4Uar8WQ5FPBDF5rigW8ZSXE I+Kr82OSnmvF45FOGufEp2ZjvKN9pTRhaPmdn7YDEvpEkLSzk2SK9a8YU8vAfI8S+ftE Vtq0qHtALfkQJCGIRKQazLqenVtdtvf9HdeXzfwAVvos33XzGTF7Vpw0fsul3FAoNT3G BD72xDUD5P/ABDGk1R5qvc01r6ZZh/4ktGA+zMHZG5tylPHS0M0QT69EfMy4LQW8cpC3 Vywv1labQwDF9j682w97eLTv3FGpjlFfzrRWlrc/veKcbypnWZ1OfMd7pqvncgYh639a gJ5w== X-Gm-Message-State: AOPr4FXIiZT7TSpB0e3eNLs2n+rrc2F60A1aq6iR3Ow5c4RrKBaPKsSZSKH///oxr5ds1jW53/1i3SnQZxX2mQ== X-Received: by 10.202.66.5 with SMTP id p5mr4409405oia.65.1463578607945; Wed, 18 May 2016 06:36:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.106 with HTTP; Wed, 18 May 2016 06:36:28 -0700 (PDT) In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D76703@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <20160512064455.15167.2456.idtracker@ietfa.amsl.com> <6a339336-a3df-6044-4c66-7a48b869670f@gmail.com> <787AE7BB302AE849A7480A190F8B933008D7585A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D763CC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D76703@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: "Andrew G. Malis" Date: Wed, 18 May 2016 09:36:28 -0400 Message-ID: To: "BOUCADAIR Mohamed IMT/OLN" Content-Type: multipart/alternative; boundary=001a113d6bfc070cda05331df36a Archived-At: Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" , Martin Stiemerling Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 13:36:52 -0000 --001a113d6bfc070cda05331df36a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99m OK with the second change. Regarding the first change, Jim asked to remove the text "There are multiple different steering policies for one flow within one SFF and each set of steering policies is specific for an ingress port.=E2=80=9D. Rather than remove it, I would suggest to revise it to: =E2=80=9CAs a local decision, there may be multiple different steering policies for a flow within an SFF and steering policies may be specific for an ingress port.= =E2=80=9D. Thanks, Andy On Wed, May 18, 2016 at 9:01 AM, wrote: > Re-, > > > > Works for me. > > > > Unless there is an objection, these changes will be implemented in the > next revision. > > > > Thank you. > > > > Cheers, > > Med > > > > *De :* Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > *Envoy=C3=A9 :* mercredi 18 mai 2016 13:42 > > *=C3=80 :* BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.org > *Objet :* Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt > > > > Hi Med, > > > > Yes, if you can remove Figure 2 and also the text "There are multiple > different steering policies for one flow within one SFF *and each set of > steering policies is specific for an ingress port*=E2=80=9D. > > > > In addition, can you also make it clear in the text that the SFP-id is > carried within the SFC encapsulation. Suggested text: > > > > Old: > > > > For example, it could be the SFP-id together with any fields in the > data packets, such as (non-exhaustive list): > > > > New: > > > > For example, it could be the SFP-id carried *within the SFC encapsulation= * > with any fields in the data packets, such as (non-exhaustive list): > > > > Jim > > > > On 5/18/16, 2:10 AM, "mohamed.boucadair@orange.com" < > mohamed.boucadair@orange.com> wrote: > > > > Hi Jim, > > > > Thank you for clarifying your concern. > > > > RFC7665 does not exclude that additional information may be used with the > SFP-id to make SFF forwarding decisions. Also, RFC7665 acknowledges that > multiple choices may be allowed in an SFF. See this excerpt, for example: > > > > SFFs maintain the requisite SFP forwarding information. SFP > > forwarding information is associated with a service path identifier > > ^^^^^^^^^^^^^ > > that is used to uniquely identify an SFP. The service forwarding > > state enables an SFF to identify which SFs of a given SFP should be > > applied, and in what order, as traffic flows through the associated > > SFP. While there may appear to the SFF to be only one available way > > to deliver the given SF, there may also be multiple choices allowed > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > by the constraints of the SFP. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > Section 4.10.4 does not violate RFC7665 because it assumes that the > forwarding information is associated with SFP-id. It does not say that > additional information MUST be supported other than SFP-id, or other > information MUST be supported in addition to the SFP-id, but that some > additional information MIGHT be needed to constrain the SFP (that is stil= l > uniquely identified by an SFP-id) for deployments requiring to control th= e > full sequence of SFFs/SFs. The text cites some examples of such additiona= l > constraints. > > > > Section 4.10.4 discusses how cp can be used to provision SFFs with > additional constraints + how to it helps to retrieve the capabilities of > SFFs. > > > > You said: > > > > I suggest that the text is silent on whether the ingress interface has > > context to the SFF - its an implementation/deployment decision. > > > > I see that you are not conformable with Figure 2 (despite the text is > clear this is an example). The intent of that figure is to illustrate the > use of "match condition/action" cited in the text. > > > > Would you be OK if that Figure is removed? > > > > Thank you. > > > > Cheers, > > Med > > > > -----Message d'origine----- > > De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com > ] > > Envoy=C3=A9 : mardi 17 mai 2016 19:31 > > =C3=80 : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.org > > Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt > > Hi Med, > > My concern (as chair) is with Figure 2 (and all of the text surrounding > > it) which suggests that the forwarding is based on incoming SFP-id *and* > > ingress port (or any of the other criteria listed). > > This is misleading based upon RFC7665 which says the SFF forwards packets > > based upon the information conveyed within the SFC encapsulation (see > > https://tools.ietf.org/html/rfc7665#section-4.3) and the SFC encapsulatio= n > > document (see > > https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-7). > > I suggest that the text is silent on whether the ingress interface has > > context to the SFF - its an implementation/deployment decision. > > Jim > > On 5/17/16, 1:42 AM, "mohamed.boucadair@orange.com" > > wrote: > > >Hi Jim, > > > > > >I believe all your comments for section 4.10.5 (-04) (section 4.10.4 in > > >-05) have been addressed. > > > > > >For the record, Andy shared a proposal here > > >(http://www.ietf.org/mail-archive/web/sfc/current/msg04616.html) while I > > >send a text proposal here > > >(http://www.ietf.org/mail-archive/web/sfc/current/msg04651.html). These > > >changes were implemented in -05 given that no objections were raised > > >against them. > > > > > >Also, the old section 4.10.4 was removed as per one of your comments. > > > > > >Applying policies on the full aggregate (sfp-id) is the default mode. Bu= t > > >for the particular case of this section (that is about "Fully Controlled > > >SFF/SF Sequence for a SFP"), there might be deployments where it is > > >appropriate to allow for local enforcement of polices that are more > > >fine-grained (TE, for example). This section does not specify a new sfc > > >encapsulation or calls for recommendation how forwarding must be > > >achieved. It does discuss some information that can be passed via the C2 > > >interface if additional information is required to achieve some TE goals= . > > > > > >Cheers, > > >Med > > > > > >> -----Message d'origine----- > > >> De : sfc [mailto:sfc-bounces@ietf.org ] De la > part de Jim Guichard > > >> (jguichar) > > >> Envoy=C3=A9 : samedi 14 mai 2016 19:48 > > >> =C3=80 : Martin Stiemerling; sfc@ietf.org > > >> Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt > > >> > > >> I would like to see my comments addressed for section 4.10.4. > > >> > > >> Our charter calls for a single SFC encapsulation and that is being > > >> documented in draft-ietf-sfc-nsh. The text within this section suggest= s > > >> that forwarding can be enabled using an SFP-id and some other conditio= n > > >> such as input port etc. This is inaccurate based upon the SFC > > >> encapsulation as well as our WG charter. There is no mention of the SF= C > > >> encapsulation or the fact that the NSH base header is the method used > > >>for > > >> forwarding; note that the most common forwarding method (and the one > > >> implemented in several places) is SFP-id + index - this is not even > > >> mentioned!. In addition, this is a control plane document; there is no > > >> need to talk about forwarding other than point to the SFC encapsulatio= n > > >> document. > > >> > > >> For these reasons I would like to see this section removed from the > > >> document. > > >> > > >> Jim > > >> > > >> > > >> On 5/14/16, 5:28 AM, "sfc on behalf of Martin Stiemerling" > > >> wrote: > > >> > > >> >Dear all, > > >> > > > >> >The authors have posted an updated version addressing the reviews out > > >>of > > >> >the WGLC. > > >> > > > >> >Please check until May 20th 5pm CEST if your comments have been > > >> addressed. > > >> > > > >> >Thanks, > > >> > > > >> > Martin > > >> > > > >> >Am 12.05.16 um 08:44 schrieb internet-drafts@ietf.org: > > >> >> > > >> >> A New Internet-Draft is available from the on-line Internet-Drafts > > >> >>directories. > > >> >> This draft is a work item of the Service Function Chaining of the > > >>IETF. > > >> >> > > >> >> Title : Service Function Chaining (SFC) Control > > >>Plane > > >> >>Components & Requirements > > >> >> Author : Mohamed Boucadair > > >> >> Filename : draft-ietf-sfc-control-plane-05.txt > > >> >> Pages : 27 > > >> >> Date : 2016-05-11 > > >> >> > > >> >> Abstract: > > >> >> This document describes requirements for conveying information > > >> >> between Service Function Chaining (SFC) control elements and SFC > > >> data > > >> >> plane functional elements. Also, this document identifies a set > > >>of > > >> >> control interfaces to interact with SFC-aware elements to > > >>establish, > > >> >> maintain or recover service function chains. This document does > > >>not > > >> >> specify protocols nor extensions to existing protocols. > > >> >> > > >> >> This document exclusively focuses on SFC deployments that are > > >>under > > >> >> the responsibility of a single administrative entity. > > >>Inter-domain > > >> >> considerations are out of scope. > > >> >> > > >> >> > > >> >> The IETF datatracker status page for this draft is: > > >> >> https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ > > >> >> > > >> >> There's also a htmlized version available at: > > >> >> https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05 > > >> >> > > >> >> A diff from the previous version is available at: > > >> >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-control-plane-05 > > >> >> > > >> >> > > >> >> 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/ > > >> >> > > >> >> _______________________________________________ > > >> >> I-D-Announce mailing list > > >> >> I-D-Announce@ietf.org > > >> >> https://www.ietf.org/mailman/listinfo/i-d-announce > > >> >> Internet-Draft directories: http://www.ietf.org/shadow.html > > >> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >> >> > > >> > > > >> >_______________________________________________ > > >> >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 > > --001a113d6bfc070cda05331df36a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I=E2=80=99m OK with the second change.

= Regarding the first change, Jim asked to remove the text "There are mu= ltiple different steering policies for one flow within one SFF and each set= of steering policies is specific for an ingress port.=E2=80=9D.
=
Rather than remove it, I would suggest to revise it to: =E2= =80=9CAs a local decision, there may be multiple different steering policie= s for a flow within an SFF and =C2=A0steering policies may be specific for = an ingress port.=E2=80=9D.

Thanks,
Andy<= /div>

On Wed= , May 18, 2016 at 9:01 AM, <mohamed.boucadair@orange.com&g= t; wrote:

Re-,

=C2=A0

Works for me.

=C2=A0

Unless there is an objection, t= hese changes will be implemented in the next revision.=

=C2=A0

Thank you.=

=C2=A0

Cheers,

Med

=C2=A0

De=C2=A0: Jim = Guichard (jguichar) [mailto:jguichar@cisco.com]
Envoy=C3=A9=C2=A0: mercredi 18 mai 2016 13:42


=C3=80=C2=A0: BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.org
Objet=C2=A0: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.t= xt

=C2=A0

Hi Med,

=C2=A0=

Yes, if you can remove Figu= re 2 and also the text "There are multiple different steering policies= for one flow within one SFF and each set of steering policies is specific for an ingress port= =E2=80=9D.

=C2=A0=

In addition, can you also m= ake it clear in the text that the SFP-id is carried within the SFC encapsul= ation. Suggested text:

=C2=A0=

Old:

=C2=A0=

For=C2=A0example, it could = be the SFP-id together with any fields in the data=C2=A0packets, such as (n= on-exhaustive list):



New:



For example, it could be th= e SFP-id carried within the SFC encapsulation with any fields in the data packets, su= ch as (non-exhaustive list):

=C2=A0=

Jim

=C2=A0=

=C2=A0=

Hi Jim,

=C2=A0=

Thank you for clarifying yo= ur concern.

=C2=A0=

RFC7665 does not exclude th= at additional information may be used with the SFP-id to make SFF forwardin= g decisions. Also, RFC7665 acknowledges that multiple choices may be allowed in an SFF. See this excerpt, for example:=C2=A0=C2=A0

=C2=A0=

=C2=A0=C2=A0 SFFs maintain = the requisite SFP forwarding information.=C2=A0=C2=A0SFP

=C2=A0=C2=A0 forwarding inf= ormation is associated with a service path identifier<= /p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0^^^^^^^^^^^^^<= u>

=C2=A0=C2=A0 that is used t= o uniquely identify an SFP.=C2=A0=C2=A0The service forwarding=

=C2=A0=C2=A0 state enables = an SFF to identify which SFs of a given SFP should be<= /p>

=C2=A0=C2=A0 applied, and i= n what order, as traffic flows through the associated<= /p>

=C2=A0=C2=A0 SFP.=C2=A0=C2= =A0While there may appear to the SFF to be only one available way=

=C2=A0=C2=A0 to deliver the= given SF, there may also be multiple choices allowed<= /p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0^^^^^^^^^= ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0 by the constra= ints of the SFP.

=C2=A0=C2=A0 ^^^^^^^^^^^^^^= ^^^^^^^^^^^^^^^^

=C2=A0=

Section 4.10.4 does not vio= late RFC7665 because it assumes that the forwarding information is associat= ed with SFP-id. It does not say that additional information MUST be supported other than SFP-id, or other information MUST be supporte= d in addition to the SFP-id, but that some additional information MIGHT be = needed to constrain the SFP (that is still uniquely identified by an SFP-id= ) for deployments requiring to control the full sequence of SFFs/SFs. The text cites some examples of such additi= onal constraints.

=C2=A0=

Section 4.10.4 discusses ho= w cp can be used to provision SFFs with additional constraints + how to it = helps to retrieve the capabilities of SFFs.

=C2=A0=

You said:

=C2=A0=

I suggest that the text is = silent on whether the ingress interface has

context to the SFF - its an= implementation/deployment decision.

=C2=A0=

I see that you are not conf= ormable with Figure 2 (despite the text is clear this is an example). The i= ntent of that figure is to illustrate the use of "match condition/action" cited in the text.=C2=A0=C2=A0=

=C2=A0=

Would you be OK if that Fig= ure is removed?

=C2=A0=

Thank you.

=C2=A0=

Cheers,

Med

=C2=A0=

-----Message d'origine-= ----

De=C2=A0: Jim Guichard (jgu= ichar) [mailto:jgui= char@cisco.com]

Envoy=C3=A9=C2=A0: mardi 17= mai 2016 19:31

=C3=80=C2=A0: BOUCADAIR Moh= amed IMT/OLN; Martin Stiemerling; sfc@ietf.org

Objet=C2=A0: Re: [sfc] I-D = Action: draft-ietf-sfc-control-plane-05.txt

Hi Med,

My concern (as chair) is wi= th Figure 2 (and all of the text surrounding

it) which suggests that the= forwarding is based on incoming SFP-id *and*

ingress port (or any of the= other criteria listed).

This is misleading based up= on RFC7665 which says the SFF forwards packets

based upon the information = conveyed within the SFC encapsulation (see

document (see=

I suggest that the text is = silent on whether the ingress interface has

context to the SFF - its an= implementation/deployment decision.

Jim

On 5/17/16, 1:42 AM, "= mohamed.b= oucadair@orange.com"

>Hi Jim,

>=C2=A0

>I believe all your comm= ents for section 4.10.5 (-04) (section 4.10.4 in

>-05) have been addresse= d.

>=C2=A0

>For the record, Andy sh= ared a proposal here

>send a text proposal he= re

>changes were implemente= d in -05 given that no objections were raised

>against them.=

>=C2=A0

>Also, the old section 4= .10.4 was removed as per one of your comments.

>=C2=A0

>Applying policies on th= e full aggregate (sfp-id) is the default mode. But

>for the particular case= of this section (that is about "Fully Controlled=

>SFF/SF Sequence for a S= FP"), there might be deployments where it is

>appropriate to allow fo= r local enforcement of polices that are more

>fine-grained (TE, for e= xample).=C2=A0=C2=A0This section does not specify a new sfc

>encapsulation or calls = for recommendation how forwarding must be

>achieved. It does discu= ss some information that can be passed via the C2

>interface if additional= information is required to achieve some TE goals.

>=C2=A0

>Cheers,

>Med

>=C2=A0

>> -----Message d'= ;origine-----

>> De : sfc [mailto:sfc-bounces@ietf.= org] De la part de Jim Guichard

>> (jguichar)<= u>

>> Envoy=C3=A9 : same= di 14 mai 2016 19:48

>> =C3=80 : Martin St= iemerling; sfc@ietf.org

>> Objet : Re: [sfc] = I-D Action: draft-ietf-sfc-control-plane-05.txt

>>=C2=A0

>> I would like to se= e my comments addressed for section 4.10.4.

>>=C2=A0

>> Our charter calls = for a single SFC encapsulation and that is being

>> documented in draf= t-ietf-sfc-nsh. The text within this section suggests<= /p>

>> that forwarding ca= n be enabled using an SFP-id and some other condition<= /p>

>> such as input port= etc. This is inaccurate based upon the SFC

>> encapsulation as w= ell as our WG charter. There is no mention of the SFC<= /p>

>> encapsulation or t= he fact that the NSH base header is the method used

>>for

>> forwarding; note t= hat the most common forwarding method (and the one

>> implemented in sev= eral places) is SFP-id + index - this is not even

>> mentioned!. In add= ition, this is a control plane document; there is no

>> need to talk about= forwarding other than point to the SFC encapsulation<= /p>

>> document.

>>=C2=A0

>> For these reasons = I would like to see this section removed from the

>> document.

>>=C2=A0

>> Jim<= /span>

>>=C2=A0

>>=C2=A0

>> On 5/14/16, 5:28 A= M, "sfc on behalf of Martin Stiemerling"

>>=C2=A0

>> >Dear all,

>> >=

>> >The authors ha= ve posted an updated version addressing the reviews out

>>of

>> >the WGLC.

>> >=

>> >Please check u= ntil May 20th 5pm CEST if your comments have been

>> addressed.<= u>

>> >=

>> >Thanks,=

>> >=

>> >=C2=A0=C2=A0= =C2=A0=C2=A0Martin

>> >=

>> >>=

>> >> A New Int= ernet-Draft is available from the on-line Internet-Drafts

>> >>directorie= s.

>> >> This draf= t is a work item of the Service Function Chaining of the

>>IETF.=

>> >>=

>> >>=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Title=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : Service Function Chaining (SFC) Control=

>>Plane=

>> >>Components= & Requirements

>> >>=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Author=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: Mohamed Boucadair

>> >> Filename= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: draft-ietf-sfc-control-pl= ane-05.txt

>> >> Pages=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 27

>> >> Date=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 2016= -05-11

>> >>=

>> >> Abstract:=

>> >>=C2=A0=C2= =A0=C2=A0=C2=A0This document describes requirements for conveying informati= on

>> >>=C2=A0=C2= =A0=C2=A0=C2=A0between Service Function Chaining (SFC) control elements and= SFC

>> data=

>> >>=C2=A0=C2= =A0=C2=A0=C2=A0plane functional elements.=C2=A0=C2=A0Also, this document id= entifies a set

>>of

>> >>=C2=A0=C2= =A0=C2=A0=C2=A0control interfaces to interact with SFC-aware elements to=

>>establish,

>> >>=C2=A0=C2= =A0=C2=A0=C2=A0maintain or recover service function chains.=C2=A0=C2=A0This= document does

>>not

>> >>=C2=A0=C2= =A0=C2=A0=C2=A0specify protocols nor extensions to existing protocols.

>> >>=

>> >>=C2=A0=C2= =A0=C2=A0=C2=A0This document exclusively focuses on SFC deployments that ar= e

>>under=

>> >>=C2=A0=C2= =A0=C2=A0=C2=A0the responsibility of a single administrative entity.=

>>Inter-domain=

>> >>=C2=A0=C2= =A0=C2=A0=C2=A0considerations are out of scope.

>> >>=

>> >>=

>> >> The IETF = datatracker status page for this draft is:

>> >>=

>> >> There'= ;s also a htmlized version available at:

>> >>=

>> >> A diff fr= om the previous version is available at:

>> >>=

>> >>=

>> >> Please no= te 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:

>> >>=

>> >> _________= ______________________________________

>> >> I-D-Annou= nce mailing list

>> >> Internet-= Draft directories: http://www.ie= tf.org/shadow.html

>> >>=

>> >=

>> >______________= _________________________________

>> >sfc mailing li= st

>>=C2=A0

>> __________________= _____________________________

>> sfc mailing list

=C2=A0=

=C2=A0=


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


--001a113d6bfc070cda05331df36a-- From nobody Wed May 18 07:10:44 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFB912D505 for ; Wed, 18 May 2016 07:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 ERFwlcS-Du_d for ; Wed, 18 May 2016 07:10:35 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2A8B12D1D9 for ; Wed, 18 May 2016 07:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=75517; q=dns/txt; s=iport; t=1463580634; x=1464790234; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iIuyVRfx3kRE5KUYyBA+n5IEsANOy1qF7P3cWkN7dYo=; b=kGzappqj/EyV0Shi5cYjgrVHlL/mKMECSKNxX7qcxPfw64z+wv13Jmx6 Y5/Ejann7pgEsVBcOHWmCBDiufrPpp82lkLE3fTkyHoYHEwLIlVP9Kbr/ yY5PmW8WfoVd9U6bpEqxBd/uhLsDs7HUNIJJGp8TjldNgaWukEOP+jnyE 4=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CwAwD5djxX/5xdJa1UCoJsgSCBBK4Ei?= =?us-ascii?q?3eBdYYRAoE2OBQBAQEBAQEBZSeEQwEFGk0HCwULAgEIGCABBgchERQRAgQOE4g?= =?us-ascii?q?HAxcOvmUNhEIOhiWBdoJXhBcLAQGDRoIuBZMchF4xAYMqgWiDZYUogWlOhAGEJ?= =?us-ascii?q?oMhgRuHdYdTAQ8PRINthz82fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,329,1459814400"; d="asc'?scan'208,217";a="105624056" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 May 2016 14:08:28 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u4IE8Sv2021716 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 18 May 2016 14:08:28 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 18 May 2016 10:08:27 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Wed, 18 May 2016 10:08:26 -0400 From: "Carlos Pignataro (cpignata)" To: "Andrew G. Malis" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt Thread-Index: AQHRrBnpAI4wVukJpUC5G2fnLrcncp+4cOMAgACLaICAA+xVAIAAxfQAgADUOwCAAFyVAIAAFiEAgAAJ5ACAAAjvAA== Date: Wed, 18 May 2016 14:08:26 +0000 Message-ID: <48D88F18-920B-4BE4-B742-B3BDEF98EBF2@cisco.com> References: <20160512064455.15167.2456.idtracker@ietfa.amsl.com> <6a339336-a3df-6044-4c66-7a48b869670f@gmail.com> <787AE7BB302AE849A7480A190F8B933008D7585A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D763CC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D76703@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.182.67] Content-Type: multipart/signed; boundary="Apple-Mail=_0D4EA00A-789F-4239-B8B7-E325AC5005BB"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "Jim Guichard \(jguichar\)" , BOUCADAIR Mohamed IMT/OLN , "sfc@ietf.org" , Martin Stiemerling Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 14:10:42 -0000 --Apple-Mail=_0D4EA00A-789F-4239-B8B7-E325AC5005BB Content-Type: multipart/alternative; boundary="Apple-Mail=_8E7442EB-26C1-44E3-8EDF-1B5D757001BD" --Apple-Mail=_8E7442EB-26C1-44E3-8EDF-1B5D757001BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, SFC, Scanning through this discussion, I found it a bit odd that = draft-ietf-sfc-control-plane-05.txt has not reference to the WG document = that defines the SFC Encapsulation, draft-ietf-sfc-nsh, since that = describes the specifics on SFF forwarding of packets. I=E2=80=99d recommend adding a reference to draft-ietf-sfc-nsh-04.txt, = with a citation next to SPI and Service Path Forwarding. Thanks, =E2=80=94 Carlos. > On May 18, 2016, at 9:36 AM, Andrew G. Malis = wrote: >=20 > I=E2=80=99m OK with the second change. >=20 > Regarding the first change, Jim asked to remove the text "There are = multiple different steering policies for one flow within one SFF and = each set of steering policies is specific for an ingress port.=E2=80=9D. >=20 > Rather than remove it, I would suggest to revise it to: =E2=80=9CAs a = local decision, there may be multiple different steering policies for a = flow within an SFF and steering policies may be specific for an ingress = port.=E2=80=9D. >=20 > Thanks, > Andy >=20 > On Wed, May 18, 2016 at 9:01 AM, > wrote: > Re-, >=20 >=20 >=20 > Works for me. >=20 >=20 >=20 > Unless there is an objection, these changes will be implemented in the = next revision. >=20 >=20 >=20 > Thank you. >=20 >=20 >=20 > Cheers, >=20 > Med >=20 >=20 >=20 > De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com = ] > Envoy=C3=A9 : mercredi 18 mai 2016 13:42 >=20 >=20 > =C3=80 : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.org = > Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt >=20 >=20 >=20 > Hi Med, >=20 >=20 >=20 > Yes, if you can remove Figure 2 and also the text "There are multiple = different steering policies for one flow within one SFF and each set of = steering policies is specific for an ingress port=E2=80=9D. >=20 >=20 >=20 > In addition, can you also make it clear in the text that the SFP-id is = carried within the SFC encapsulation. Suggested text: >=20 >=20 >=20 > Old: >=20 >=20 >=20 > For example, it could be the SFP-id together with any fields in the = data packets, such as (non-exhaustive list): >=20 >=20 >=20 >=20 > New: >=20 >=20 >=20 >=20 > For example, it could be the SFP-id carried within the SFC = encapsulation with any fields in the data packets, such as = (non-exhaustive list): >=20 >=20 >=20 > Jim >=20 >=20 >=20 > On 5/18/16, 2:10 AM, "mohamed.boucadair@orange.com = " > wrote: >=20 >=20 >=20 > Hi Jim, >=20 >=20 >=20 > Thank you for clarifying your concern. >=20 >=20 >=20 > RFC7665 does not exclude that additional information may be used with = the SFP-id to make SFF forwarding decisions. Also, RFC7665 acknowledges = that multiple choices may be allowed in an SFF. See this excerpt, for = example: >=20 >=20 >=20 > SFFs maintain the requisite SFP forwarding information. SFP >=20 > forwarding information is associated with a service path identifier >=20 > ^^^^^^^^^^^^^ >=20 > that is used to uniquely identify an SFP. The service forwarding >=20 > state enables an SFF to identify which SFs of a given SFP should be >=20 > applied, and in what order, as traffic flows through the associated >=20 > SFP. While there may appear to the SFF to be only one available = way >=20 > to deliver the given SF, there may also be multiple choices allowed >=20 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >=20 > by the constraints of the SFP. >=20 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >=20 >=20 >=20 > Section 4.10.4 does not violate RFC7665 because it assumes that the = forwarding information is associated with SFP-id. It does not say that = additional information MUST be supported other than SFP-id, or other = information MUST be supported in addition to the SFP-id, but that some = additional information MIGHT be needed to constrain the SFP (that is = still uniquely identified by an SFP-id) for deployments requiring to = control the full sequence of SFFs/SFs. The text cites some examples of = such additional constraints. >=20 >=20 >=20 > Section 4.10.4 discusses how cp can be used to provision SFFs with = additional constraints + how to it helps to retrieve the capabilities of = SFFs. >=20 >=20 >=20 > You said: >=20 >=20 >=20 > I suggest that the text is silent on whether the ingress interface has >=20 > context to the SFF - its an implementation/deployment decision. >=20 >=20 >=20 > I see that you are not conformable with Figure 2 (despite the text is = clear this is an example). The intent of that figure is to illustrate = the use of "match condition/action" cited in the text. >=20 >=20 >=20 > Would you be OK if that Figure is removed? >=20 >=20 >=20 > Thank you. >=20 >=20 >=20 > Cheers, >=20 > Med >=20 >=20 >=20 > -----Message d'origine----- >=20 > De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com = ] >=20 > Envoy=C3=A9 : mardi 17 mai 2016 19:31 >=20 > =C3=80 : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.org = > Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt >=20 > Hi Med, >=20 > My concern (as chair) is with Figure 2 (and all of the text = surrounding >=20 > it) which suggests that the forwarding is based on incoming SFP-id = *and* >=20 > ingress port (or any of the other criteria listed). >=20 > This is misleading based upon RFC7665 which says the SFF forwards = packets >=20 > based upon the information conveyed within the SFC encapsulation (see >=20 > https://tools.ietf.org/html/rfc7665#section-4.3 = ) and the SFC = encapsulation >=20 > document (see >=20 > https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-7 = ). >=20 > I suggest that the text is silent on whether the ingress interface has >=20 > context to the SFF - its an implementation/deployment decision. >=20 > Jim >=20 > On 5/17/16, 1:42 AM, "mohamed.boucadair@orange.com = " >=20 > > = wrote: >=20 > >Hi Jim, >=20 > > >=20 > >I believe all your comments for section 4.10.5 (-04) (section 4.10.4 = in >=20 > >-05) have been addressed. >=20 > > >=20 > >For the record, Andy shared a proposal here >=20 > >(http://www.ietf.org/mail-archive/web/sfc/current/msg04616.html = ) while = I >=20 > >send a text proposal here >=20 > >(http://www.ietf.org/mail-archive/web/sfc/current/msg04651.html = ). These >=20 > >changes were implemented in -05 given that no objections were raised >=20 > >against them. >=20 > > >=20 > >Also, the old section 4.10.4 was removed as per one of your comments. >=20 > > >=20 > >Applying policies on the full aggregate (sfp-id) is the default mode. = But >=20 > >for the particular case of this section (that is about "Fully = Controlled >=20 > >SFF/SF Sequence for a SFP"), there might be deployments where it is >=20 > >appropriate to allow for local enforcement of polices that are more >=20 > >fine-grained (TE, for example). This section does not specify a new = sfc >=20 > >encapsulation or calls for recommendation how forwarding must be >=20 > >achieved. It does discuss some information that can be passed via the = C2 >=20 > >interface if additional information is required to achieve some TE = goals. >=20 > > >=20 > >Cheers, >=20 > >Med >=20 > > >=20 > >> -----Message d'origine----- >=20 > >> De : sfc [mailto:sfc-bounces@ietf.org = ] De la part de Jim Guichard >=20 > >> (jguichar) >=20 > >> Envoy=C3=A9 : samedi 14 mai 2016 19:48 >=20 > >> =C3=80 : Martin Stiemerling; sfc@ietf.org > >> Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt >=20 > >> >=20 > >> I would like to see my comments addressed for section 4.10.4. >=20 > >> >=20 > >> Our charter calls for a single SFC encapsulation and that is being >=20 > >> documented in draft-ietf-sfc-nsh. The text within this section = suggests >=20 > >> that forwarding can be enabled using an SFP-id and some other = condition >=20 > >> such as input port etc. This is inaccurate based upon the SFC >=20 > >> encapsulation as well as our WG charter. There is no mention of the = SFC >=20 > >> encapsulation or the fact that the NSH base header is the method = used >=20 > >>for >=20 > >> forwarding; note that the most common forwarding method (and the = one >=20 > >> implemented in several places) is SFP-id + index - this is not even >=20 > >> mentioned!. In addition, this is a control plane document; there is = no >=20 > >> need to talk about forwarding other than point to the SFC = encapsulation >=20 > >> document. >=20 > >> >=20 > >> For these reasons I would like to see this section removed from the >=20 > >> document. >=20 > >> >=20 > >> Jim >=20 > >> >=20 > >> >=20 > >> On 5/14/16, 5:28 AM, "sfc on behalf of Martin Stiemerling" >=20 > >> on behalf of = mls.ietf@gmail.com > wrote: >=20 > >> >=20 > >> >Dear all, >=20 > >> > >=20 > >> >The authors have posted an updated version addressing the reviews = out >=20 > >>of >=20 > >> >the WGLC. >=20 > >> > >=20 > >> >Please check until May 20th 5pm CEST if your comments have been >=20 > >> addressed. >=20 > >> > >=20 > >> >Thanks, >=20 > >> > >=20 > >> > Martin >=20 > >> > >=20 > >> >Am 12.05.16 um 08:44 schrieb internet-drafts@ietf.org = : >=20 > >> >> >=20 > >> >> A New Internet-Draft is available from the on-line = Internet-Drafts >=20 > >> >>directories. >=20 > >> >> This draft is a work item of the Service Function Chaining of = the >=20 > >>IETF. >=20 > >> >> >=20 > >> >> Title : Service Function Chaining (SFC) = Control >=20 > >>Plane >=20 > >> >>Components & Requirements >=20 > >> >> Author : Mohamed Boucadair >=20 > >> >> Filename : draft-ietf-sfc-control-plane-05.txt >=20 > >> >> Pages : 27 >=20 > >> >> Date : 2016-05-11 >=20 > >> >> >=20 > >> >> Abstract: >=20 > >> >> This document describes requirements for conveying = information >=20 > >> >> between Service Function Chaining (SFC) control elements and = SFC >=20 > >> data >=20 > >> >> plane functional elements. Also, this document identifies a = set >=20 > >>of >=20 > >> >> control interfaces to interact with SFC-aware elements to >=20 > >>establish, >=20 > >> >> maintain or recover service function chains. This document = does >=20 > >>not >=20 > >> >> specify protocols nor extensions to existing protocols. >=20 > >> >> >=20 > >> >> This document exclusively focuses on SFC deployments that are >=20 > >>under >=20 > >> >> the responsibility of a single administrative entity. >=20 > >>Inter-domain >=20 > >> >> considerations are out of scope. >=20 > >> >> >=20 > >> >> >=20 > >> >> The IETF datatracker status page for this draft is: >=20 > >> >> https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ = > >> >> >=20 > >> >> There's also a htmlized version available at: >=20 > >> >> https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05 = > >> >> >=20 > >> >> A diff from the previous version is available at: >=20 > >> >> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-control-plane-05 = > >> >> >=20 > >> >> >=20 > >> >> Please note that it may take a couple of minutes from the time = of >=20 > >> >>submission >=20 > >> >> until the htmlized version and diff are available at = tools.ietf.org . >=20 > >> >> >=20 > >> >> Internet-Drafts are also available by anonymous FTP at: >=20 > >> >> ftp://ftp.ietf.org/internet-drafts/ = > >> >> >=20 > >> >> _______________________________________________ >=20 > >> >> I-D-Announce mailing list >=20 > >> >> I-D-Announce@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/i-d-announce = > >> >> Internet-Draft directories: http://www.ietf.org/shadow.html = > >> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt = > >> >> >=20 > >> > >=20 > >> >_______________________________________________ >=20 > >> >sfc mailing list >=20 > >> >sfc@ietf.org > >> >https://www.ietf.org/mailman/listinfo/sfc = > >> >=20 > >> _______________________________________________ >=20 > >> sfc mailing list >=20 > >> sfc@ietf.org > >> https://www.ietf.org/mailman/listinfo/sfc = >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc = >=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail=_8E7442EB-26C1-44E3-8EDF-1B5D757001BD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, SFC,

Scanning through this discussion, I found it a bit odd = that draft-ietf-sfc-control-plane-05.txt has not reference to the = WG document that defines the SFC Encapsulation, draft-ietf-sfc-nsh, = since that describes the specifics on SFF forwarding of = packets.

I=E2=80= =99d recommend adding a reference to draft-ietf-sfc-nsh-04.txt, = with a citation next to SPI and Service Path Forwarding.

Thanks,

=E2=80=94 = Carlos. 

On May 18, 2016, at 9:36 AM, = Andrew G. Malis <agmalis@gmail.com> wrote:

I=E2=80=99m OK with the second = change.

Regarding = the first change, Jim asked to remove the text "There are multiple = different steering policies for one flow within one SFF and each set of = steering policies is specific for an ingress port.=E2=80=9D.

Rather than remove it, I = would suggest to revise it to: =E2=80=9CAs a local decision, there may = be multiple different steering policies for a flow within an SFF and =  steering policies may be specific for an ingress = port.=E2=80=9D.

Thanks,
Andy

On Wed, = May 18, 2016 at 9:01 AM, <mohamed.boucadair@orange.com> wrote:

Re-,

 

Works for me.

 

Unless = there is an objection, these changes will be implemented in the next = revision.

 

Thank = you.

 

Cheers,

Med

 

De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
Envoy=C3=A9 : mercredi 18 mai 2016 = 13:42


=C3=80 : BOUCADAIR Mohamed IMT/OLN; Martin = Stiemerling; sfc@ietf.org
Objet : Re: [sfc] I-D Action: = draft-ietf-sfc-control-plane-05.txt

 

Hi Med,

 

Yes, if you can remove = Figure 2 and also the text "There are multiple different steering = policies for one flow within one SFF and each set of steering policies is = specific for an ingress port=E2=80=9D.

 

In addition, can you also = make it clear in the text that the SFP-id is carried within the SFC = encapsulation. Suggested text:

 

Old:

 

For example, it could = be the SFP-id together with any fields in the data packets, such as = (non-exhaustive list):



New:



For example, it could be = the SFP-id carried within the SFC encapsulation with any fields in the = data packets, such as (non-exhaustive list):

 

Jim

 

On 5/18/16, 2:10 AM, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com> wrote:

 

Hi Jim,

 

Thank you for clarifying = your concern.

 

RFC7665 does not exclude = that additional information may be used with the SFP-id to make SFF = forwarding decisions. Also, RFC7665 acknowledges that multiple choices may be allowed in an SFF. See this excerpt, for example:  

 

   SFFs maintain = the requisite SFP forwarding information.  SFP

   forwarding = information is associated with a service path identifier

          &nb= sp;            = ;   ^^^^^^^^^^^^^

   that is used = to uniquely identify an SFP.  The service forwarding

   state enables = an SFF to identify which SFs of a given SFP should be

   applied, and = in what order, as traffic flows through the associated

   = SFP.  While there may appear to the SFF to be only one = available way

   to deliver = the given SF, there may also be multiple choices allowed

          &nb= sp;            = ;     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^&= nbsp;   

   by the = constraints of the SFP.

   = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

 

Section 4.10.4 does not = violate RFC7665 because it assumes that the forwarding information is = associated with SFP-id. It does not say that additional information MUST be supported other than SFP-id, or other information MUST be = supported in addition to the SFP-id, but that some additional = information MIGHT be needed to constrain the SFP (that is still uniquely = identified by an SFP-id) for deployments requiring to control the full sequence of SFFs/SFs. The text cites some examples of such = additional constraints.

 

Section 4.10.4 discusses = how cp can be used to provision SFFs with additional constraints + how = to it helps to retrieve the capabilities of SFFs.

 

You said:

 

I suggest that the text is = silent on whether the ingress interface has

context to the SFF - its = an implementation/deployment decision.

 

I see that you are not = conformable with Figure 2 (despite the text is clear this is an = example). The intent of that figure is to illustrate the use of "match condition/action" cited in the text.  

 

Would you be OK if that = Figure is removed?

 

Thank you.

 

Cheers,

Med

 

-----Message = d'origine-----

De : Jim Guichard = (jguichar) [mailto:jguichar@cisco.com]

Envoy=C3=A9 : mardi = 17 mai 2016 19:31

=C3=80 : BOUCADAIR = Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.org

=

Objet : Re: [sfc] I-D = Action: draft-ietf-sfc-control-plane-05.txt

Hi Med,

My concern (as chair) is = with Figure 2 (and all of the text surrounding

it) which suggests that = the forwarding is based on incoming SFP-id *and*

ingress port (or any of = the other criteria listed).

=

This is misleading based = upon RFC7665 which says the SFF forwards packets

based upon the information = conveyed within the SFC encapsulation (see

https://tools.ietf.org/html/rfc7665#section-4.3) and the = SFC encapsulation

document (see

https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-7= ).

I suggest that the text is = silent on whether the ingress interface has

context to the SFF - its = an implementation/deployment decision.

Jim

On 5/17/16, 1:42 AM, "mohamed.boucadair@orange.com"

<mohamed.boucadair@orange.com> wrote:

>Hi Jim,

> 

>I believe all your = comments for section 4.10.5 (-04) (section 4.10.4 in

>-05) have been = addressed.

> 

>For the record, Andy = shared a proposal here

>(http://www.ietf.org/mail-archive/web/sfc/current/msg04616.html<= /a>) while I

>send a text proposal = here

>(http://www.ietf.org/mail-archive/web/sfc/current/msg04651.html<= /a>). These

>changes were = implemented in -05 given that no objections were raised

>against them.

> 

>Also, the old section = 4.10.4 was removed as per one of your comments.

> 

>Applying policies on = the full aggregate (sfp-id) is the default mode. But

>for the particular = case of this section (that is about "Fully Controlled

>SFF/SF Sequence for a = SFP"), there might be deployments where it is

>appropriate to allow = for local enforcement of polices that are more

>fine-grained (TE, for = example).  This section does not specify a new sfc

>encapsulation or calls = for recommendation how forwarding must be

>achieved. It does = discuss some information that can be passed via the C2

>interface if = additional information is required to achieve some TE goals.

> 

>Cheers,

>Med

> 

>> -----Message = d'origine-----

>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard

>> (jguichar)

>> Envoy=C3=A9 : = samedi 14 mai 2016 19:48

>> =C3=80 : Martin = Stiemerling; sfc@ietf.org

=

>> Objet : Re: [sfc] = I-D Action: draft-ietf-sfc-control-plane-05.txt

>> 

>> I would like to = see my comments addressed for section 4.10.4.

>> 

>> Our charter calls = for a single SFC encapsulation and that is being

>> documented in = draft-ietf-sfc-nsh. The text within this section suggests

>> that forwarding = can be enabled using an SFP-id and some other condition

>> such as input = port etc. This is inaccurate based upon the SFC

>> encapsulation as = well as our WG charter. There is no mention of the SFC

>> encapsulation or = the fact that the NSH base header is the method used

>>for

>> forwarding; note = that the most common forwarding method (and the one

>> implemented in = several places) is SFP-id + index - this is not even

>> mentioned!. In = addition, this is a control plane document; there is no

>> need to talk = about forwarding other than point to the SFC encapsulation

>> document.

>> 

>> For these reasons = I would like to see this section removed from the

>> document.

>> 

>> Jim

>> 

>> 

>> On 5/14/16, 5:28 = AM, "sfc on behalf of Martin Stiemerling"

>> <sfc-bounces@ietf.org on behalf of mls.ietf@gmail.com> wrote:

>> 

>> >Dear all,

>> >

>> >The authors = have posted an updated version addressing the reviews out

>>of

>> >the WGLC.

>> >

>> >Please check = until May 20th 5pm CEST if your comments have been

>> addressed.

>> >

>> >Thanks,

>> >

>> = >    Martin

>> >

>> >Am 12.05.16 = um 08:44 schrieb internet-drafts@ietf.org:

>> >>

>> >> A New = Internet-Draft is available from the on-line Internet-Drafts

>> = >>directories.

>> >> This = draft is a work item of the Service Function Chaining of the

>>IETF.

>> >>

>> = >>         = Title           : = Service Function Chaining (SFC) Control

>>Plane

>> = >>Components & Requirements

>> = >>         = Author          : = Mohamed Boucadair

>> >> = Filename        : = draft-ietf-sfc-control-plane-05.txt

>> >> = Pages           : 27

>> >> = Date           &nbs= p;: 2016-05-11

>> >>

>> >> = Abstract:

>> = >>    This document describes requirements for = conveying information

>> = >>    between Service Function Chaining (SFC) = control elements and SFC

>> data

>> = >>    plane functional = elements.  Also, this document identifies a set

>>of

>> = >>    control interfaces to interact with = SFC-aware elements to

>>establish,

>> = >>    maintain or recover service function = chains.  This document does

>>not

>> = >>    specify protocols nor extensions to = existing protocols.

>> >>

>> = >>    This document exclusively focuses on SFC = deployments that are

>>under

>> = >>    the responsibility of a single = administrative entity.

>>Inter-domain

>> = >>    considerations are out of scope.

>> >>

>> >>

>> >> The IETF = datatracker status page for this draft is:

>> >> https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/<= /a>

>> >>

>> >> There's = also a htmlized version available at:

>> >> https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05=

>> >>

>> >> A diff = from the previous version is available at:

>> >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-control-plan= e-05

>> >>

>> >>

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

>> >>

>> >> = _______________________________________________

>> >> = I-D-Announce mailing list

>> >> I-D-Announce@ietf.org

>> >> https://www.ietf.org/mailman/listinfo/i-d-announce

>> >> = Internet-Draft directories: http://www.ietf.org/shadow.html

>> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

>> >>

>> >

>> = >_______________________________________________

>> >sfc mailing = list

>> >sfc@ietf.org

=

>> >https://www.ietf.org/mailman/listinfo/sfc

>> 

>> = _______________________________________________

>> sfc mailing = list

>> sfc@ietf.org

=

>> https://www.ietf.org/mailman/listinfo/sfc

 

 


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


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

= --Apple-Mail=_8E7442EB-26C1-44E3-8EDF-1B5D757001BD-- --Apple-Mail=_0D4EA00A-789F-4239-B8B7-E325AC5005BB 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 - http://gpgtools.org iQIcBAEBCAAGBQJXPHdaAAoJEIXgpQGOZny95ecP/jK4IquRG66QH5XQ8yZwrFEv 81gsCP2iYagdc2CWKyGHeQdkSMRSUD+1QqncC3KzXBUxbCJoVjGqIkOr01zZlkgR HGyw8zj2brxMeRzoT2kaBc9TbRaIzGcZinoIjbEurR00gtsM/zTS1RDoVUlgofIt Wi5pTQpwYKgDNLrpeFd++1ELF5DG4wAW2x97WB1iNwX7f0xhj7AsNxQKRlMUqSxy i5I3f8TmOeM9keJ9JY3ujDO+zX1SU8Tc9EIBXaUMjsriWf2KYD+JyXlbzGLutdan hKR+0HxM07XK2vENkgNOno2tS/DSoDmZoFf746X70HIlcTdNnb+4PkV40MGE7lcB sEFQzm36mQHupljfVbj++RifK/+6aN/zYtumf/Ndh9zEo74sZ7IEvPLljHYGpM+o ypGdDj92ivQDBi0sxLO7Fbkt6hQDy8vq7+HmytEIlF3aqfB3f/o16nHnw5z29sJf HCqrAKNsnwe4SVMOLy/DfqDYkURZTsAHe8dwh02ex0swS7D87+rYIWrFKrN+Dnyn WOVCMd/W1meHuA2aYmnUMgvfg2/Wda70Sw6C+IWbluCcj8DqngPEk6+ZNr/yiJN5 oCAGGwYRjbLZuIDtTSroDxOEd6ww2sDcwjzVJMaF9h2m8oC4d4O2AMxfdirklc9I K+LbfkHhyv45IDPmgYc7 =BDD4 -----END PGP SIGNATURE----- --Apple-Mail=_0D4EA00A-789F-4239-B8B7-E325AC5005BB-- From nobody Wed May 18 07:17:26 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A28A12D1D9 for ; Wed, 18 May 2016 07:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 0LOTM49aFUAw for ; Wed, 18 May 2016 07:17:18 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 A060612D120 for ; Wed, 18 May 2016 07:17:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 862891D89FA; Wed, 18 May 2016 07:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1463581038; bh=GxCWLSgtIHgm07M2zBGNUpwR7OSKLFhdAKqQMoklhnA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=hMl/7CoZnU1lzrq1mjGzAl0h3KPtGxqPEZXD7J+Fo+AICXBh1tIpQwlW176rCh79/ +j36zg2hu+5CCf7fxjeTdti2eVrI3wIYN/iiPvq4TsJhdvOyC5AsGzPAN3L5+bNBfy BGnCOmWgo960NumDPTuOxbENyPAYnk/329bg52Mc= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id B7A641C5BA0; Wed, 18 May 2016 07:17:17 -0700 (PDT) To: mohamed.boucadair@orange.com, "Jim Guichard (jguichar)" , Martin Stiemerling , "sfc@ietf.org" References: <20160512064455.15167.2456.idtracker@ietfa.amsl.com> <6a339336-a3df-6044-4c66-7a48b869670f@gmail.com> <787AE7BB302AE849A7480A190F8B933008D7585A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D763CC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: "Joel M. Halpern" Message-ID: <59a97075-4b2b-245a-ba57-2f09033807c8@joelhalpern.com> Date: Wed, 18 May 2016 10:17:36 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D763CC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 14:17:25 -0000 So let me ask the question differently. This is the control plane requirements draft. As I understand the intent, it is to describe the properties that control solutions must have to meet the SFC WG needs. If the section is not normative, and merely describes something that can be used in some circumstances, why are we including it? Yours, Joel On 5/18/16 2:10 AM, mohamed.boucadair@orange.com wrote: > Hi Jim, > > Thank you for clarifying your concern. > > RFC7665 does not exclude that additional information may be used with the SFP-id to make SFF forwarding decisions. Also, RFC7665 acknowledges that multiple choices may be allowed in an SFF. See this excerpt, for example: > > SFFs maintain the requisite SFP forwarding information. SFP > forwarding information is associated with a service path identifier > ^^^^^^^^^^^^^ > that is used to uniquely identify an SFP. The service forwarding > state enables an SFF to identify which SFs of a given SFP should be > applied, and in what order, as traffic flows through the associated > SFP. While there may appear to the SFF to be only one available way > to deliver the given SF, there may also be multiple choices allowed > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > by the constraints of the SFP. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Section 4.10.4 does not violate RFC7665 because it assumes that the forwarding information is associated with SFP-id. It does not say that additional information MUST be supported other than SFP-id, or other information MUST be supported in addition to the SFP-id, but that some additional information MIGHT be needed to constrain the SFP (that is still uniquely identified by an SFP-id) for deployments requiring to control the full sequence of SFFs/SFs. The text cites some examples of such additional constraints. > > Section 4.10.4 discusses how cp can be used to provision SFFs with additional constraints + how to it helps to retrieve the capabilities of SFFs. > > You said: > >> I suggest that the text is silent on whether the ingress interface has >> context to the SFF - its an implementation/deployment decision. > > I see that you are not conformable with Figure 2 (despite the text is clear this is an example). The intent of that figure is to illustrate the use of "match condition/action" cited in the text. > > Would you be OK if that Figure is removed? > > Thank you. > > Cheers, > Med > >> -----Message d'origine----- >> De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> Envoyé : mardi 17 mai 2016 19:31 >> À : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.org >> Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt >> >> Hi Med, >> >> My concern (as chair) is with Figure 2 (and all of the text surrounding >> it) which suggests that the forwarding is based on incoming SFP-id *and* >> ingress port (or any of the other criteria listed). >> >> This is misleading based upon RFC7665 which says the SFF forwards packets >> based upon the information conveyed within the SFC encapsulation (see >> https://tools.ietf.org/html/rfc7665#section-4.3) and the SFC encapsulation >> document (see >> https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-7). >> >> I suggest that the text is silent on whether the ingress interface has >> context to the SFF - its an implementation/deployment decision. >> >> Jim >> >> >> On 5/17/16, 1:42 AM, "mohamed.boucadair@orange.com" >> wrote: >> >>> Hi Jim, >>> >>> I believe all your comments for section 4.10.5 (-04) (section 4.10.4 in >>> -05) have been addressed. >>> >>> For the record, Andy shared a proposal here >>> (http://www.ietf.org/mail-archive/web/sfc/current/msg04616.html) while I >>> send a text proposal here >>> (http://www.ietf.org/mail-archive/web/sfc/current/msg04651.html). These >>> changes were implemented in -05 given that no objections were raised >>> against them. >>> >>> Also, the old section 4.10.4 was removed as per one of your comments. >>> >>> Applying policies on the full aggregate (sfp-id) is the default mode. But >>> for the particular case of this section (that is about "Fully Controlled >>> SFF/SF Sequence for a SFP"), there might be deployments where it is >>> appropriate to allow for local enforcement of polices that are more >>> fine-grained (TE, for example). This section does not specify a new sfc >>> encapsulation or calls for recommendation how forwarding must be >>> achieved. It does discuss some information that can be passed via the C2 >>> interface if additional information is required to achieve some TE goals. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard >>>> (jguichar) >>>> Envoyé : samedi 14 mai 2016 19:48 >>>> À : Martin Stiemerling; sfc@ietf.org >>>> Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt >>>> >>>> I would like to see my comments addressed for section 4.10.4. >>>> >>>> Our charter calls for a single SFC encapsulation and that is being >>>> documented in draft-ietf-sfc-nsh. The text within this section suggests >>>> that forwarding can be enabled using an SFP-id and some other condition >>>> such as input port etc. This is inaccurate based upon the SFC >>>> encapsulation as well as our WG charter. There is no mention of the SFC >>>> encapsulation or the fact that the NSH base header is the method used >>>> for >>>> forwarding; note that the most common forwarding method (and the one >>>> implemented in several places) is SFP-id + index - this is not even >>>> mentioned!. In addition, this is a control plane document; there is no >>>> need to talk about forwarding other than point to the SFC encapsulation >>>> document. >>>> >>>> For these reasons I would like to see this section removed from the >>>> document. >>>> >>>> Jim >>>> >>>> >>>> On 5/14/16, 5:28 AM, "sfc on behalf of Martin Stiemerling" >>>> wrote: >>>> >>>>> Dear all, >>>>> >>>>> The authors have posted an updated version addressing the reviews out >>>> of >>>>> the WGLC. >>>>> >>>>> Please check until May 20th 5pm CEST if your comments have been >>>> addressed. >>>>> >>>>> Thanks, >>>>> >>>>> Martin >>>>> >>>>> Am 12.05.16 um 08:44 schrieb internet-drafts@ietf.org: >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>> directories. >>>>>> This draft is a work item of the Service Function Chaining of the >>>> IETF. >>>>>> >>>>>> Title : Service Function Chaining (SFC) Control >>>> Plane >>>>>> Components & Requirements >>>>>> Author : Mohamed Boucadair >>>>>> Filename : draft-ietf-sfc-control-plane-05.txt >>>>>> Pages : 27 >>>>>> Date : 2016-05-11 >>>>>> >>>>>> Abstract: >>>>>> This document describes requirements for conveying information >>>>>> between Service Function Chaining (SFC) control elements and SFC >>>> data >>>>>> plane functional elements. Also, this document identifies a set >>>> of >>>>>> control interfaces to interact with SFC-aware elements to >>>> establish, >>>>>> maintain or recover service function chains. This document does >>>> not >>>>>> specify protocols nor extensions to existing protocols. >>>>>> >>>>>> This document exclusively focuses on SFC deployments that are >>>> under >>>>>> the responsibility of a single administrative entity. >>>> Inter-domain >>>>>> considerations are out of scope. >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-control-plane-05 >>>>>> >>>>>> >>>>>> 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/ >>>>>> >>>>>> _______________________________________________ >>>>>> I-D-Announce mailing list >>>>>> I-D-Announce@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>> >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Wed May 18 07:31:21 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1731412D515 for ; Wed, 18 May 2016 07:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 WWW9vNX8pSRw for ; Wed, 18 May 2016 07:31:17 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DF6D12D122 for ; Wed, 18 May 2016 07:31:16 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id BA43D2DCBE1; Wed, 18 May 2016 16:31:14 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.41]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 966FF4C071; Wed, 18 May 2016 16:31:14 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0294.000; Wed, 18 May 2016 16:31:14 +0200 From: To: "Joel M. Halpern" , "Jim Guichard (jguichar)" , Martin Stiemerling , "sfc@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt Thread-Index: AQHRsRAGAI4wVukJpUC5G2fnLrcncp++vmjg Date: Wed, 18 May 2016 14:31:13 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D76833@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <20160512064455.15167.2456.idtracker@ietfa.amsl.com> <6a339336-a3df-6044-4c66-7a48b869670f@gmail.com> <787AE7BB302AE849A7480A190F8B933008D7585A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D763CC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <59a97075-4b2b-245a-ba57-2f09033807c8@joelhalpern.com> In-Reply-To: <59a97075-4b2b-245a-ba57-2f09033807c8@joelhalpern.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.5.18.115415 Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 14:31:20 -0000 Hi Joel,=20 The section describes an optional set of requirements targeting to control = the full set of SFFs/SFs. For example, it specifies a requirement to instru= ct to SFFs which additional information to use to enforce forwarding polici= es (+SFP-id). Cheers, Med > -----Message d'origine----- > De=A0: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Envoy=E9=A0: mercredi 18 mai 2016 16:18 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Jim Guichard (jguichar); Martin > Stiemerling; sfc@ietf.org > Objet=A0: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt >=20 > So let me ask the question differently. > This is the control plane requirements draft. As I understand the > intent, it is to describe the properties that control solutions must > have to meet the SFC WG needs. >=20 > If the section is not normative, and merely describes something that can > be used in some circumstances, why are we including it? >=20 > Yours, > Joel >=20 > On 5/18/16 2:10 AM, mohamed.boucadair@orange.com wrote: > > Hi Jim, > > > > Thank you for clarifying your concern. > > > > RFC7665 does not exclude that additional information may be used with > the SFP-id to make SFF forwarding decisions. Also, RFC7665 acknowledges > that multiple choices may be allowed in an SFF. See this excerpt, for > example: > > > > SFFs maintain the requisite SFP forwarding information. SFP > > forwarding information is associated with a service path identifier > > ^^^^^^^^^^^^^ > > that is used to uniquely identify an SFP. The service forwarding > > state enables an SFF to identify which SFs of a given SFP should be > > applied, and in what order, as traffic flows through the associated > > SFP. While there may appear to the SFF to be only one available way > > to deliver the given SF, there may also be multiple choices allowed > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > by the constraints of the SFP. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > Section 4.10.4 does not violate RFC7665 because it assumes that the > forwarding information is associated with SFP-id. It does not say that > additional information MUST be supported other than SFP-id, or other > information MUST be supported in addition to the SFP-id, but that some > additional information MIGHT be needed to constrain the SFP (that is stil= l > uniquely identified by an SFP-id) for deployments requiring to control th= e > full sequence of SFFs/SFs. The text cites some examples of such additiona= l > constraints. > > > > Section 4.10.4 discusses how cp can be used to provision SFFs with > additional constraints + how to it helps to retrieve the capabilities of > SFFs. > > > > You said: > > > >> I suggest that the text is silent on whether the ingress interface has > >> context to the SFF - its an implementation/deployment decision. > > > > I see that you are not conformable with Figure 2 (despite the text is > clear this is an example). The intent of that figure is to illustrate the > use of "match condition/action" cited in the text. > > > > Would you be OK if that Figure is removed? > > > > Thank you. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > >> Envoy=E9 : mardi 17 mai 2016 19:31 > >> =C0 : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.org > >> Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt > >> > >> Hi Med, > >> > >> My concern (as chair) is with Figure 2 (and all of the text surroundin= g > >> it) which suggests that the forwarding is based on incoming SFP-id > *and* > >> ingress port (or any of the other criteria listed). > >> > >> This is misleading based upon RFC7665 which says the SFF forwards > packets > >> based upon the information conveyed within the SFC encapsulation (see > >> https://tools.ietf.org/html/rfc7665#section-4.3) and the SFC > encapsulation > >> document (see > >> https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-7). > >> > >> I suggest that the text is silent on whether the ingress interface has > >> context to the SFF - its an implementation/deployment decision. > >> > >> Jim > >> > >> > >> On 5/17/16, 1:42 AM, "mohamed.boucadair@orange.com" > >> wrote: > >> > >>> Hi Jim, > >>> > >>> I believe all your comments for section 4.10.5 (-04) (section 4.10.4 > in > >>> -05) have been addressed. > >>> > >>> For the record, Andy shared a proposal here > >>> (http://www.ietf.org/mail-archive/web/sfc/current/msg04616.html) whil= e > I > >>> send a text proposal here > >>> (http://www.ietf.org/mail-archive/web/sfc/current/msg04651.html). > These > >>> changes were implemented in -05 given that no objections were raised > >>> against them. > >>> > >>> Also, the old section 4.10.4 was removed as per one of your comments. > >>> > >>> Applying policies on the full aggregate (sfp-id) is the default mode. > But > >>> for the particular case of this section (that is about "Fully > Controlled > >>> SFF/SF Sequence for a SFP"), there might be deployments where it is > >>> appropriate to allow for local enforcement of polices that are more > >>> fine-grained (TE, for example). This section does not specify a new > sfc > >>> encapsulation or calls for recommendation how forwarding must be > >>> achieved. It does discuss some information that can be passed via the > C2 > >>> interface if additional information is required to achieve some TE > goals. > >>> > >>> Cheers, > >>> Med > >>> > >>>> -----Message d'origine----- > >>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard > >>>> (jguichar) > >>>> Envoy=E9 : samedi 14 mai 2016 19:48 > >>>> =C0 : Martin Stiemerling; sfc@ietf.org > >>>> Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt > >>>> > >>>> I would like to see my comments addressed for section 4.10.4. > >>>> > >>>> Our charter calls for a single SFC encapsulation and that is being > >>>> documented in draft-ietf-sfc-nsh. The text within this section > suggests > >>>> that forwarding can be enabled using an SFP-id and some other > condition > >>>> such as input port etc. This is inaccurate based upon the SFC > >>>> encapsulation as well as our WG charter. There is no mention of the > SFC > >>>> encapsulation or the fact that the NSH base header is the method use= d > >>>> for > >>>> forwarding; note that the most common forwarding method (and the one > >>>> implemented in several places) is SFP-id + index - this is not even > >>>> mentioned!. In addition, this is a control plane document; there is > no > >>>> need to talk about forwarding other than point to the SFC > encapsulation > >>>> document. > >>>> > >>>> For these reasons I would like to see this section removed from the > >>>> document. > >>>> > >>>> Jim > >>>> > >>>> > >>>> On 5/14/16, 5:28 AM, "sfc on behalf of Martin Stiemerling" > >>>> wrote: > >>>> > >>>>> Dear all, > >>>>> > >>>>> The authors have posted an updated version addressing the reviews > out > >>>> of > >>>>> the WGLC. > >>>>> > >>>>> Please check until May 20th 5pm CEST if your comments have been > >>>> addressed. > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Martin > >>>>> > >>>>> Am 12.05.16 um 08:44 schrieb internet-drafts@ietf.org: > >>>>>> > >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts > >>>>>> directories. > >>>>>> This draft is a work item of the Service Function Chaining of the > >>>> IETF. > >>>>>> > >>>>>> Title : Service Function Chaining (SFC) Control > >>>> Plane > >>>>>> Components & Requirements > >>>>>> Author : Mohamed Boucadair > >>>>>> Filename : draft-ietf-sfc-control-plane-05.txt > >>>>>> Pages : 27 > >>>>>> Date : 2016-05-11 > >>>>>> > >>>>>> Abstract: > >>>>>> This document describes requirements for conveying information > >>>>>> between Service Function Chaining (SFC) control elements and SF= C > >>>> data > >>>>>> plane functional elements. Also, this document identifies a se= t > >>>> of > >>>>>> control interfaces to interact with SFC-aware elements to > >>>> establish, > >>>>>> maintain or recover service function chains. This document doe= s > >>>> not > >>>>>> specify protocols nor extensions to existing protocols. > >>>>>> > >>>>>> This document exclusively focuses on SFC deployments that are > >>>> under > >>>>>> the responsibility of a single administrative entity. > >>>> Inter-domain > >>>>>> considerations are out of scope. > >>>>>> > >>>>>> > >>>>>> The IETF datatracker status page for this draft is: > >>>>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ > >>>>>> > >>>>>> There's also a htmlized version available at: > >>>>>> https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05 > >>>>>> > >>>>>> A diff from the previous version is available at: > >>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-control-plane-0= 5 > >>>>>> > >>>>>> > >>>>>> 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/ > >>>>>> > >>>>>> _______________________________________________ > >>>>>> I-D-Announce mailing list > >>>>>> I-D-Announce@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce > >>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html > >>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> sfc mailing list > >>>>> sfc@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>> > >>>> _______________________________________________ > >>>> sfc mailing list > >>>> sfc@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > From nobody Wed May 18 07:45:29 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3ADF12D165 for ; Wed, 18 May 2016 07:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 YgGPPSkh3YpD for ; Wed, 18 May 2016 07:45:26 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 3BAB212D164 for ; Wed, 18 May 2016 07:35:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 24D8BE00079; Wed, 18 May 2016 07:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1463582144; bh=CkrzRIwXLsoIIbS3cDNz2tguDeFNKxxuc7y4ki/6YD4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ljNrSzUVgSJFASawgvn7j2eAF2KYWQaWS09ogJvgV4+oW6Px6YNaDWGp85dN6WoFk XbnVOnacJXjqOXSKQbOAi+O5QYdBO0pw67TJNJ/38qNCHrSOTB64qTdoxJwHdDUI+B uOVXqznlFgPg5KeiSk+KP+K5621ZtWNzSish9DW4= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 41F941C5BA0; Wed, 18 May 2016 07:35:43 -0700 (PDT) To: mohamed.boucadair@orange.com, "Jim Guichard (jguichar)" , Martin Stiemerling , "sfc@ietf.org" References: <20160512064455.15167.2456.idtracker@ietfa.amsl.com> <6a339336-a3df-6044-4c66-7a48b869670f@gmail.com> <787AE7BB302AE849A7480A190F8B933008D7585A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D763CC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <59a97075-4b2b-245a-ba57-2f09033807c8@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D76833@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: "Joel M. Halpern" Message-ID: <84faf286-d1c1-25d9-8bc1-5b6d5ff15a58@joelhalpern.com> Date: Wed, 18 May 2016 10:36:02 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D76833@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 14:45:29 -0000 If Jim and Carlos can live with it, I will let it go. I have trouble with the notion of "optional requirements". Yours, Joel On 5/18/16 10:31 AM, mohamed.boucadair@orange.com wrote: > Hi Joel, > > The section describes an optional set of requirements targeting to control the full set of SFFs/SFs. For example, it specifies a requirement to instruct to SFFs which additional information to use to enforce forwarding policies (+SFP-id). > > Cheers, > Med > >> -----Message d'origine----- >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Envoyé : mercredi 18 mai 2016 16:18 >> À : BOUCADAIR Mohamed IMT/OLN; Jim Guichard (jguichar); Martin >> Stiemerling; sfc@ietf.org >> Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt >> >> So let me ask the question differently. >> This is the control plane requirements draft. As I understand the >> intent, it is to describe the properties that control solutions must >> have to meet the SFC WG needs. >> >> If the section is not normative, and merely describes something that can >> be used in some circumstances, why are we including it? >> >> Yours, >> Joel >> >> On 5/18/16 2:10 AM, mohamed.boucadair@orange.com wrote: >>> Hi Jim, >>> >>> Thank you for clarifying your concern. >>> >>> RFC7665 does not exclude that additional information may be used with >> the SFP-id to make SFF forwarding decisions. Also, RFC7665 acknowledges >> that multiple choices may be allowed in an SFF. See this excerpt, for >> example: >>> >>> SFFs maintain the requisite SFP forwarding information. SFP >>> forwarding information is associated with a service path identifier >>> ^^^^^^^^^^^^^ >>> that is used to uniquely identify an SFP. The service forwarding >>> state enables an SFF to identify which SFs of a given SFP should be >>> applied, and in what order, as traffic flows through the associated >>> SFP. While there may appear to the SFF to be only one available way >>> to deliver the given SF, there may also be multiple choices allowed >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> by the constraints of the SFP. >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> >>> Section 4.10.4 does not violate RFC7665 because it assumes that the >> forwarding information is associated with SFP-id. It does not say that >> additional information MUST be supported other than SFP-id, or other >> information MUST be supported in addition to the SFP-id, but that some >> additional information MIGHT be needed to constrain the SFP (that is still >> uniquely identified by an SFP-id) for deployments requiring to control the >> full sequence of SFFs/SFs. The text cites some examples of such additional >> constraints. >>> >>> Section 4.10.4 discusses how cp can be used to provision SFFs with >> additional constraints + how to it helps to retrieve the capabilities of >> SFFs. >>> >>> You said: >>> >>>> I suggest that the text is silent on whether the ingress interface has >>>> context to the SFF - its an implementation/deployment decision. >>> >>> I see that you are not conformable with Figure 2 (despite the text is >> clear this is an example). The intent of that figure is to illustrate the >> use of "match condition/action" cited in the text. >>> >>> Would you be OK if that Figure is removed? >>> >>> Thank you. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>> Envoyé : mardi 17 mai 2016 19:31 >>>> À : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.org >>>> Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt >>>> >>>> Hi Med, >>>> >>>> My concern (as chair) is with Figure 2 (and all of the text surrounding >>>> it) which suggests that the forwarding is based on incoming SFP-id >> *and* >>>> ingress port (or any of the other criteria listed). >>>> >>>> This is misleading based upon RFC7665 which says the SFF forwards >> packets >>>> based upon the information conveyed within the SFC encapsulation (see >>>> https://tools.ietf.org/html/rfc7665#section-4.3) and the SFC >> encapsulation >>>> document (see >>>> https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-7). >>>> >>>> I suggest that the text is silent on whether the ingress interface has >>>> context to the SFF - its an implementation/deployment decision. >>>> >>>> Jim >>>> >>>> >>>> On 5/17/16, 1:42 AM, "mohamed.boucadair@orange.com" >>>> wrote: >>>> >>>>> Hi Jim, >>>>> >>>>> I believe all your comments for section 4.10.5 (-04) (section 4.10.4 >> in >>>>> -05) have been addressed. >>>>> >>>>> For the record, Andy shared a proposal here >>>>> (http://www.ietf.org/mail-archive/web/sfc/current/msg04616.html) while >> I >>>>> send a text proposal here >>>>> (http://www.ietf.org/mail-archive/web/sfc/current/msg04651.html). >> These >>>>> changes were implemented in -05 given that no objections were raised >>>>> against them. >>>>> >>>>> Also, the old section 4.10.4 was removed as per one of your comments. >>>>> >>>>> Applying policies on the full aggregate (sfp-id) is the default mode. >> But >>>>> for the particular case of this section (that is about "Fully >> Controlled >>>>> SFF/SF Sequence for a SFP"), there might be deployments where it is >>>>> appropriate to allow for local enforcement of polices that are more >>>>> fine-grained (TE, for example). This section does not specify a new >> sfc >>>>> encapsulation or calls for recommendation how forwarding must be >>>>> achieved. It does discuss some information that can be passed via the >> C2 >>>>> interface if additional information is required to achieve some TE >> goals. >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>>> -----Message d'origine----- >>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard >>>>>> (jguichar) >>>>>> Envoyé : samedi 14 mai 2016 19:48 >>>>>> À : Martin Stiemerling; sfc@ietf.org >>>>>> Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt >>>>>> >>>>>> I would like to see my comments addressed for section 4.10.4. >>>>>> >>>>>> Our charter calls for a single SFC encapsulation and that is being >>>>>> documented in draft-ietf-sfc-nsh. The text within this section >> suggests >>>>>> that forwarding can be enabled using an SFP-id and some other >> condition >>>>>> such as input port etc. This is inaccurate based upon the SFC >>>>>> encapsulation as well as our WG charter. There is no mention of the >> SFC >>>>>> encapsulation or the fact that the NSH base header is the method used >>>>>> for >>>>>> forwarding; note that the most common forwarding method (and the one >>>>>> implemented in several places) is SFP-id + index - this is not even >>>>>> mentioned!. In addition, this is a control plane document; there is >> no >>>>>> need to talk about forwarding other than point to the SFC >> encapsulation >>>>>> document. >>>>>> >>>>>> For these reasons I would like to see this section removed from the >>>>>> document. >>>>>> >>>>>> Jim >>>>>> >>>>>> >>>>>> On 5/14/16, 5:28 AM, "sfc on behalf of Martin Stiemerling" >>>>>> wrote: >>>>>> >>>>>>> Dear all, >>>>>>> >>>>>>> The authors have posted an updated version addressing the reviews >> out >>>>>> of >>>>>>> the WGLC. >>>>>>> >>>>>>> Please check until May 20th 5pm CEST if your comments have been >>>>>> addressed. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Martin >>>>>>> >>>>>>> Am 12.05.16 um 08:44 schrieb internet-drafts@ietf.org: >>>>>>>> >>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>>>> directories. >>>>>>>> This draft is a work item of the Service Function Chaining of the >>>>>> IETF. >>>>>>>> >>>>>>>> Title : Service Function Chaining (SFC) Control >>>>>> Plane >>>>>>>> Components & Requirements >>>>>>>> Author : Mohamed Boucadair >>>>>>>> Filename : draft-ietf-sfc-control-plane-05.txt >>>>>>>> Pages : 27 >>>>>>>> Date : 2016-05-11 >>>>>>>> >>>>>>>> Abstract: >>>>>>>> This document describes requirements for conveying information >>>>>>>> between Service Function Chaining (SFC) control elements and SFC >>>>>> data >>>>>>>> plane functional elements. Also, this document identifies a set >>>>>> of >>>>>>>> control interfaces to interact with SFC-aware elements to >>>>>> establish, >>>>>>>> maintain or recover service function chains. This document does >>>>>> not >>>>>>>> specify protocols nor extensions to existing protocols. >>>>>>>> >>>>>>>> This document exclusively focuses on SFC deployments that are >>>>>> under >>>>>>>> the responsibility of a single administrative entity. >>>>>> Inter-domain >>>>>>>> considerations are out of scope. >>>>>>>> >>>>>>>> >>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ >>>>>>>> >>>>>>>> There's also a htmlized version available at: >>>>>>>> https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05 >>>>>>>> >>>>>>>> A diff from the previous version is available at: >>>>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-control-plane-05 >>>>>>>> >>>>>>>> >>>>>>>> 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/ >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> I-D-Announce mailing list >>>>>>>> I-D-Announce@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> > From nobody Wed May 18 08:39:19 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918B112D59F for ; Wed, 18 May 2016 08:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 wSSgG0_gDf2b for ; Wed, 18 May 2016 08:39:14 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54BD812D113 for ; Wed, 18 May 2016 08:39:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37026; q=dns/txt; s=iport; t=1463585954; x=1464795554; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BKjCUib7u3fMTcF95AiSxosVv9gvbbeMfYiOUhjvvlk=; b=j/NGnumFVcY4+gYkUnN6iaOnxdzz8HaP4YVw/x2GGmiKRMqePb9HhVNM 7hhjXbeKcftcpLeTTPhR0RQYoVT4c3IbiyXWKURglL9bdQPuVNPhsLJrr eWP2rqzMluW6RgRl+G6NgH3UghS024SWMyZgUjNJxSDaB77i4xVyqmQAp A=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BAAwAyjDxX/51dJa1UCoM3VX4GrguLa?= =?us-ascii?q?Q6BcQQXAQqFbwKBOjgUAQEBAQEBAWUnhEIBAQEDAQEBARdUCwULAgEIGCABBgc?= =?us-ascii?q?hBgsUEQIEDgUJBQ2HegMPCA6/EA2EHwEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4Oh?= =?us-ascii?q?iWBdoJXgkOBVAsBAVmCbYIuBZMcFYRJMQGDKoFobYJ4gy+BeYFpToQBhCaDIYE?= =?us-ascii?q?bh2EUh1MBDw8BQ4IGHIFLbgGGUDZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,329,1459814400"; d="asc'?scan'208,217";a="103543655" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 May 2016 15:39:12 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u4IFdBNS023276 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 18 May 2016 15:39:12 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 18 May 2016 11:39:11 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Wed, 18 May 2016 11:39:11 -0400 From: "Carlos Pignataro (cpignata)" To: "Joel M. Halpern" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt Thread-Index: AQHRrBnpAI4wVukJpUC5G2fnLrcncp+4cOMAgACLaICAA+xVAIAAxfQAgADUOwCAAIgYAIAAA86AgAABWQCAABGjAA== Date: Wed, 18 May 2016 15:39:11 +0000 Message-ID: <79285B74-E0A6-4C59-8C81-8F22F2943C8A@cisco.com> References: <20160512064455.15167.2456.idtracker@ietfa.amsl.com> <6a339336-a3df-6044-4c66-7a48b869670f@gmail.com> <787AE7BB302AE849A7480A190F8B933008D7585A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D763CC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <59a97075-4b2b-245a-ba57-2f09033807c8@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D76833@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <84faf286-d1c1-25d9-8bc1-5b6d5ff15a58@joelhalpern.com> In-Reply-To: <84faf286-d1c1-25d9-8bc1-5b6d5ff15a58@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.182.67] Content-Type: multipart/signed; boundary="Apple-Mail=_AD57BD4D-6B55-4056-AB9C-C73BF32A9431"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "Jim Guichard \(jguichar\)" , BOUCADAIR Mohamed IMT/OLN , "sfc@ietf.org" , Martin Stiemerling Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 15:39:17 -0000 --Apple-Mail=_AD57BD4D-6B55-4056-AB9C-C73BF32A9431 Content-Type: multipart/alternative; boundary="Apple-Mail=_870FD1F0-E5BB-4DCF-8E83-2F470B01BFC2" --Apple-Mail=_870FD1F0-E5BB-4DCF-8E83-2F470B01BFC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 To be frank, =93optional requirement=94 sounds like an oxymoron to me. Requirement [ri-kwahyuh r-muh nt] that which is required; a thing demanded or obligatory I understand requirements levels and RFC 2119, but really the spec ought = to be clearly aligned with the control plane, and point to normative = docs for other modules. I=92d suggest trying to keep the scope and focus as per =93Service = Function Chaining (SFC) Control Plane Components & Requirements=94 I think this is also relevant: https://tools.ietf.org/html/rfc1925 (12) In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away. Thanks, =97 Carlos. > On May 18, 2016, at 10:36 AM, Joel M. Halpern = wrote: >=20 > If Jim and Carlos can live with it, I will let it go. I have trouble = with the notion of "optional requirements". >=20 > Yours, > Joel >=20 > On 5/18/16 10:31 AM, mohamed.boucadair@orange.com wrote: >> Hi Joel, >>=20 >> The section describes an optional set of requirements targeting to = control the full set of SFFs/SFs. For example, it specifies a = requirement to instruct to SFFs which additional information to use to = enforce forwarding policies (+SFP-id). >>=20 >> Cheers, >> Med >>=20 >>> -----Message d'origine----- >>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Envoy=E9 : mercredi 18 mai 2016 16:18 >>> =C0 : BOUCADAIR Mohamed IMT/OLN; Jim Guichard (jguichar); Martin >>> Stiemerling; sfc@ietf.org >>> Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt >>>=20 >>> So let me ask the question differently. >>> This is the control plane requirements draft. As I understand the >>> intent, it is to describe the properties that control solutions must >>> have to meet the SFC WG needs. >>>=20 >>> If the section is not normative, and merely describes something that = can >>> be used in some circumstances, why are we including it? >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 5/18/16 2:10 AM, mohamed.boucadair@orange.com wrote: >>>> Hi Jim, >>>>=20 >>>> Thank you for clarifying your concern. >>>>=20 >>>> RFC7665 does not exclude that additional information may be used = with >>> the SFP-id to make SFF forwarding decisions. Also, RFC7665 = acknowledges >>> that multiple choices may be allowed in an SFF. See this excerpt, = for >>> example: >>>>=20 >>>> SFFs maintain the requisite SFP forwarding information. SFP >>>> forwarding information is associated with a service path = identifier >>>> ^^^^^^^^^^^^^ >>>> that is used to uniquely identify an SFP. The service forwarding >>>> state enables an SFF to identify which SFs of a given SFP should = be >>>> applied, and in what order, as traffic flows through the = associated >>>> SFP. While there may appear to the SFF to be only one available = way >>>> to deliver the given SF, there may also be multiple choices = allowed >>>> = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>> by the constraints of the SFP. >>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>=20 >>>> Section 4.10.4 does not violate RFC7665 because it assumes that the >>> forwarding information is associated with SFP-id. It does not say = that >>> additional information MUST be supported other than SFP-id, or other >>> information MUST be supported in addition to the SFP-id, but that = some >>> additional information MIGHT be needed to constrain the SFP (that is = still >>> uniquely identified by an SFP-id) for deployments requiring to = control the >>> full sequence of SFFs/SFs. The text cites some examples of such = additional >>> constraints. >>>>=20 >>>> Section 4.10.4 discusses how cp can be used to provision SFFs with >>> additional constraints + how to it helps to retrieve the = capabilities of >>> SFFs. >>>>=20 >>>> You said: >>>>=20 >>>>> I suggest that the text is silent on whether the ingress interface = has >>>>> context to the SFF - its an implementation/deployment decision. >>>>=20 >>>> I see that you are not conformable with Figure 2 (despite the text = is >>> clear this is an example). The intent of that figure is to = illustrate the >>> use of "match condition/action" cited in the text. >>>>=20 >>>> Would you be OK if that Figure is removed? >>>>=20 >>>> Thank you. >>>>=20 >>>> Cheers, >>>> Med >>>>=20 >>>>> -----Message d'origine----- >>>>> De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>> Envoy=E9 : mardi 17 mai 2016 19:31 >>>>> =C0 : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.org >>>>> Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt >>>>>=20 >>>>> Hi Med, >>>>>=20 >>>>> My concern (as chair) is with Figure 2 (and all of the text = surrounding >>>>> it) which suggests that the forwarding is based on incoming SFP-id >>> *and* >>>>> ingress port (or any of the other criteria listed). >>>>>=20 >>>>> This is misleading based upon RFC7665 which says the SFF forwards >>> packets >>>>> based upon the information conveyed within the SFC encapsulation = (see >>>>> https://tools.ietf.org/html/rfc7665#section-4.3) and the SFC >>> encapsulation >>>>> document (see >>>>> https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-7). >>>>>=20 >>>>> I suggest that the text is silent on whether the ingress interface = has >>>>> context to the SFF - its an implementation/deployment decision. >>>>>=20 >>>>> Jim >>>>>=20 >>>>>=20 >>>>> On 5/17/16, 1:42 AM, "mohamed.boucadair@orange.com" >>>>> wrote: >>>>>=20 >>>>>> Hi Jim, >>>>>>=20 >>>>>> I believe all your comments for section 4.10.5 (-04) (section = 4.10.4 >>> in >>>>>> -05) have been addressed. >>>>>>=20 >>>>>> For the record, Andy shared a proposal here >>>>>> (http://www.ietf.org/mail-archive/web/sfc/current/msg04616.html) = while >>> I >>>>>> send a text proposal here >>>>>> (http://www.ietf.org/mail-archive/web/sfc/current/msg04651.html). >>> These >>>>>> changes were implemented in -05 given that no objections were = raised >>>>>> against them. >>>>>>=20 >>>>>> Also, the old section 4.10.4 was removed as per one of your = comments. >>>>>>=20 >>>>>> Applying policies on the full aggregate (sfp-id) is the default = mode. >>> But >>>>>> for the particular case of this section (that is about "Fully >>> Controlled >>>>>> SFF/SF Sequence for a SFP"), there might be deployments where it = is >>>>>> appropriate to allow for local enforcement of polices that are = more >>>>>> fine-grained (TE, for example). This section does not specify a = new >>> sfc >>>>>> encapsulation or calls for recommendation how forwarding must be >>>>>> achieved. It does discuss some information that can be passed via = the >>> C2 >>>>>> interface if additional information is required to achieve some = TE >>> goals. >>>>>>=20 >>>>>> Cheers, >>>>>> Med >>>>>>=20 >>>>>>> -----Message d'origine----- >>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim = Guichard >>>>>>> (jguichar) >>>>>>> Envoy=E9 : samedi 14 mai 2016 19:48 >>>>>>> =C0 : Martin Stiemerling; sfc@ietf.org >>>>>>> Objet : Re: [sfc] I-D Action: = draft-ietf-sfc-control-plane-05.txt >>>>>>>=20 >>>>>>> I would like to see my comments addressed for section 4.10.4. >>>>>>>=20 >>>>>>> Our charter calls for a single SFC encapsulation and that is = being >>>>>>> documented in draft-ietf-sfc-nsh. The text within this section >>> suggests >>>>>>> that forwarding can be enabled using an SFP-id and some other >>> condition >>>>>>> such as input port etc. This is inaccurate based upon the SFC >>>>>>> encapsulation as well as our WG charter. There is no mention of = the >>> SFC >>>>>>> encapsulation or the fact that the NSH base header is the method = used >>>>>>> for >>>>>>> forwarding; note that the most common forwarding method (and the = one >>>>>>> implemented in several places) is SFP-id + index - this is not = even >>>>>>> mentioned!. In addition, this is a control plane document; there = is >>> no >>>>>>> need to talk about forwarding other than point to the SFC >>> encapsulation >>>>>>> document. >>>>>>>=20 >>>>>>> For these reasons I would like to see this section removed from = the >>>>>>> document. >>>>>>>=20 >>>>>>> Jim >>>>>>>=20 >>>>>>>=20 >>>>>>> On 5/14/16, 5:28 AM, "sfc on behalf of Martin Stiemerling" >>>>>>> wrote: >>>>>>>=20 >>>>>>>> Dear all, >>>>>>>>=20 >>>>>>>> The authors have posted an updated version addressing the = reviews >>> out >>>>>>> of >>>>>>>> the WGLC. >>>>>>>>=20 >>>>>>>> Please check until May 20th 5pm CEST if your comments have been >>>>>>> addressed. >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>>=20 >>>>>>>> Martin >>>>>>>>=20 >>>>>>>> Am 12.05.16 um 08:44 schrieb internet-drafts@ietf.org: >>>>>>>>>=20 >>>>>>>>> A New Internet-Draft is available from the on-line = Internet-Drafts >>>>>>>>> directories. >>>>>>>>> This draft is a work item of the Service Function Chaining of = the >>>>>>> IETF. >>>>>>>>>=20 >>>>>>>>> Title : Service Function Chaining (SFC) = Control >>>>>>> Plane >>>>>>>>> Components & Requirements >>>>>>>>> Author : Mohamed Boucadair >>>>>>>>> Filename : draft-ietf-sfc-control-plane-05.txt >>>>>>>>> Pages : 27 >>>>>>>>> Date : 2016-05-11 >>>>>>>>>=20 >>>>>>>>> Abstract: >>>>>>>>> This document describes requirements for conveying = information >>>>>>>>> between Service Function Chaining (SFC) control elements and = SFC >>>>>>> data >>>>>>>>> plane functional elements. Also, this document identifies a = set >>>>>>> of >>>>>>>>> control interfaces to interact with SFC-aware elements to >>>>>>> establish, >>>>>>>>> maintain or recover service function chains. This document = does >>>>>>> not >>>>>>>>> specify protocols nor extensions to existing protocols. >>>>>>>>>=20 >>>>>>>>> This document exclusively focuses on SFC deployments that = are >>>>>>> under >>>>>>>>> the responsibility of a single administrative entity. >>>>>>> Inter-domain >>>>>>>>> considerations are out of scope. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ >>>>>>>>>=20 >>>>>>>>> There's also a htmlized version available at: >>>>>>>>> https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05 >>>>>>>>>=20 >>>>>>>>> A diff from the previous version is available at: >>>>>>>>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-control-plane-05 >>>>>>>>>=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 >>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> I-D-Announce mailing list >>>>>>>>> I-D-Announce@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>>>>=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 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail=_870FD1F0-E5BB-4DCF-8E83-2F470B01BFC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 To be frank, =93optional requirement=94 sounds like an = oxymoron to me.

Requirement [ri-kwahyuh r-muh nt]
that which is required; a thing d= emanded or obligatory

I understand requirements levels and = RFC 2119, but really the spec ought to be clearly aligned with the = control plane, and point to normative docs for other modules.

I=92d suggest trying to = keep the scope and focus as per =93Service Function Chaining (SFC) = Control Plane Components & Requirements=94

I think this is also = relevant: https://tools.ietf.org/html/rfc1925
  =  (12) In protocol design, perfection has been reached not when = there
        is nothing left to add, but when = there is nothing left to take
        = away.

Thanks,

=97 Carlos.

On = May 18, 2016, at 10:36 AM, Joel M. Halpern <jmh@joelhalpern.com>= wrote:

If Jim and Carlos can live with it, I will let it go.  I = have trouble with the notion of "optional requirements".
Yours,
Joel

On = 5/18/16 10:31 AM, mohamed.boucadair@orange.com wrote:
Hi Joel,
The section describes an optional set of requirements = targeting to control the full set of SFFs/SFs. For example, it specifies = a requirement to instruct to SFFs which additional information to use to = enforce forwarding policies (+SFP-id).

Cheers,
Med

-----Message = d'origine-----
De : Joel M. Halpern [mailto:jmh@joelhalpern.com]
Envoy=E9 : = mercredi 18 mai 2016 16:18
=C0 : BOUCADAIR Mohamed = IMT/OLN; Jim Guichard (jguichar); Martin
Stiemerling; sfc@ietf.org
Objet : Re: [sfc] I-D Action: = draft-ietf-sfc-control-plane-05.txt

So let = me ask the question differently.
This is the control plane = requirements draft.  As I understand the
intent, it = is to describe the properties that control solutions must
have to meet the SFC WG needs.

If = the section is not normative, and merely describes something that can
be used in some circumstances, why are we including it?

Yours,
Joel

On 5/18/16 2:10 AM, mohamed.boucadair@orange.com wrote:
Hi Jim,

Thank you for clarifying your concern.

RFC7665 does not exclude that additional information may be = used with
the SFP-id to make SFF forwarding = decisions. Also, RFC7665 acknowledges
that multiple = choices may be allowed in an SFF. See this excerpt, for
example:
  SFFs maintain the requisite SFP forwarding = information.  SFP
  forwarding information = is associated with a service path identifier
=             &n= bsp;           &nbs= p;^^^^^^^^^^^^^
  that is used to uniquely = identify an SFP.  The service forwarding
=   state enables an SFF to identify which SFs of a given SFP = should be
  applied, and in what order, as = traffic flows through the associated
  SFP. =  While there may appear to the SFF to be only one available way
  to deliver the given SF, there may also be = multiple choices allowed
=             &n= bsp;           &nbs= p;  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
=   by the constraints of the SFP.
=   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Section 4.10.4 does not violate RFC7665 because it assumes = that the
forwarding information is associated = with SFP-id. It does not say that
additional information = MUST be supported other than SFP-id, or other
information = MUST be supported in addition to the SFP-id, but that some
additional information MIGHT be needed to constrain the SFP = (that is still
uniquely identified by an SFP-id) for = deployments requiring to control the
full sequence of = SFFs/SFs. The text cites some examples of such additional
constraints.

Section 4.10.4 discusses how cp can be used to = provision SFFs with
additional constraints + = how to it helps to retrieve the capabilities of
SFFs.

You = said:

I = suggest that the text is silent on whether the ingress interface has
context to the SFF - its an implementation/deployment = decision.

I see that you are = not conformable with Figure 2 (despite the text is
clear this is an example). The intent of that = figure is to illustrate the
use of "match = condition/action" cited in the text.

Would you be OK if that Figure = is removed?

Thank you.

Cheers,
Med

-----Message = d'origine-----
De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
Envoy=E9 : mardi = 17 mai 2016 19:31
=C0 : BOUCADAIR Mohamed IMT/OLN; Martin = Stiemerling; sfc@ietf.org
Objet : Re: [sfc] I-D Action: = draft-ietf-sfc-control-plane-05.txt

Hi = Med,

My concern (as chair) is with Figure 2 = (and all of the text surrounding
it) which suggests that = the forwarding is based on incoming SFP-id
*and*
ingress = port (or any of the other criteria listed).

This is misleading based upon RFC7665 which says the SFF = forwards
packets
based upon the information conveyed within the SFC = encapsulation (see
https://tools.ietf.org/html/rfc7665#section-4.3) and the = SFC
encapsulation
document (see
https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-7= ).

I suggest that the text is silent on = whether the ingress interface has
context to the SFF - its = an implementation/deployment decision.

Jim

On 5/17/16, 1:42 AM, "mohamed.boucadair@orange.com"
<mohamed.boucadair@orange.com> wrote:

Hi Jim,

I believe all your comments for section 4.10.5 (-04) (section = 4.10.4
in
-05) have been = addressed.

For the record, Andy shared a = proposal here
(http://www.ietf.org/mail-archive/web/sfc/current/msg04616.html<= /a>) while
I
send a text proposal = here
(http://www.ietf.org/mail-archive/web/sfc/current/msg04651.html<= /a>).
These
changes were implemented = in -05 given that no objections were raised
against = them.

Also, the old section 4.10.4 was = removed as per one of your comments.

Applying= policies on the full aggregate (sfp-id) is the default mode.
But
for the particular case = of this section (that is about "Fully
Controlled
SFF/SF Sequence for a = SFP"), there might be deployments where it is
appropriate = to allow for local enforcement of polices that are more
fine-grained (TE, for example).  This section does not = specify a new
sfc
encapsulation or calls = for recommendation how forwarding must be
achieved. It = does discuss some information that can be passed via the
C2
interface if additional = information is required to achieve some TE
goals.

Cheers,
Med

-----Message d'origine-----
De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim = Guichard
(jguichar)
Envoy=E9 : samedi 14 mai = 2016 19:48
=C0 : Martin Stiemerling; sfc@ietf.org
Objet : Re: [sfc] I-D Action: = draft-ietf-sfc-control-plane-05.txt

I would = like to see my comments addressed for section 4.10.4.

Our charter calls for a single SFC encapsulation and that is = being
documented in draft-ietf-sfc-nsh. The text within = this section
suggests
that forwarding can be enabled using an SFP-id and some = other
condition
such as input port etc. This is inaccurate = based upon the SFC
encapsulation as well as our WG = charter. There is no mention of the
SFC
encapsulation or the fact that the NSH base header is the = method used
for
forwarding; note that the = most common forwarding method (and the one
implemented in = several places) is SFP-id + index - this is not even
mentioned!. In addition, this is a control plane document; = there is
no
need to talk about forwarding other than point to the SFC
encapsulati= on
document.

For = these reasons I would like to see this section removed from the
document.

Jim


On 5/14/16, 5:28 AM, "sfc on behalf of Martin = Stiemerling"
<sfc-bounces@ietf.org on behalf of mls.ietf@gmail.com> = wrote:

Dear all,

The authors have = posted an updated version addressing the reviews
out
of
the WGLC.

Please check until May = 20th 5pm CEST if your comments have been
addressed.

Thanks,

=   Martin

Am 12.05.16 um 08:44 = schrieb internet-drafts@ietf.org:

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

=        Title =           : Service = Function Chaining (SFC) Control
Plane
Components = & Requirements
=        Author =          : Mohamed = Boucadair
Filename =        : = draft-ietf-sfc-control-plane-05.txt
Pages =           : 27
= Date =            : = 2016-05-11

Abstract:
=   This document describes requirements for conveying = information
  between Service Function Chaining = (SFC) control elements and SFC
data
=   plane functional elements.  Also, this document = identifies a set
of
  control interfaces to interact with SFC-aware = elements to
establish,
  maintain or recover service function chains. =  This document does
not
  specify protocols nor extensions to existing = protocols.

  This document = exclusively focuses on SFC deployments that are
under
=   the responsibility of a single administrative entity.
Inter-domain
  considerations are out of scope.

The IETF datatracker status page for this = draft is:
https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/<= /a>

There's also a htmlized version = available at:
https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05

A diff from the previous version is available = at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-control-plan= e-05


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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt


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

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

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



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

= --Apple-Mail=_870FD1F0-E5BB-4DCF-8E83-2F470B01BFC2-- --Apple-Mail=_AD57BD4D-6B55-4056-AB9C-C73BF32A9431 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 - http://gpgtools.org iQIcBAEBCAAGBQJXPIyeAAoJEIXgpQGOZny9b7MP/j9wJzI6DuYD6OqFabtsQ9AI cu1A9RWRcLq/Wb+rGvXXvO58uoN7HEAwJWac4mot0pcnCOCf2GiKVstjILjrPrM+ GWYYoT7FDPyYBMbjO79W5yb1oAI0zAvBas3lfRkHoeBW1QuUOgo+KIFKSvCABw82 ULDH85Eo9jAMaA0O5I2k5pTJzXop+hAkNWhCGlrKUJxqfs/PkTLYIhPDVzkP2E3d 1te8/EoHmSqMi/DMe3gAE2v8D4Ko9df6FIfYgIrBLJWeO1t4UDCQZKFiIwkHnbaV XEnCXQfFhtJj8NmYiyA40f2eJpkr/6UXOi4Xd484FiF5o3l0I3qEZZOXJAU4Yrk8 L9BBwkl4sA6Qc9OBC0XNjsI6XedtX0DnhVIelG0SkgKDQtcANKXNe0j7VgNDOAwb Bmvq6XzvN6MVEXINWgiDAme1gSQG907N+OCNwt2Rk1MZ2rXf7qq4K38AvCOTAS9N 4NK3ZhfDxYoI598OgOnXp3dTFdorM9sEr/0N34ld0ZYqTo6Dbr6GZ8pJKlbfjPzn QsW3QiTaf5HDCI1yI0F3cIAjoYgA/JpISrfbNsTNkevthe2aMo4hk1EpGOWC5NKe O03VWGobbW/GqG3zE8dnpKDW1xHpmrmaAZvWTftxSYF6kBvP7V7UVkr/bQ85pCxO esA7rHdwDtI0VmQd6+EB =wLbR -----END PGP SIGNATURE----- --Apple-Mail=_AD57BD4D-6B55-4056-AB9C-C73BF32A9431-- From nobody Wed May 18 08:48:06 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F55212D5B7 for ; Wed, 18 May 2016 08:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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_tXibzsqn-8 for ; Wed, 18 May 2016 08:48:03 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC7C512D5B6 for ; Wed, 18 May 2016 08:48:02 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id v145so83088809oie.0 for ; Wed, 18 May 2016 08:48:02 -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; bh=KBbTZ/ifMEwpHm1cnuQoEJLGsYwsXct+gQZrYA2fEoM=; b=OT9l+c9DNSVkNjov+SlxBBCRQ7ikCZXevjz51WaQtwYBOVGtJcBD6RPeYS7bo2XzPq gpjgD2W9t5SKwbfZFk8M+ubkQQZB1+0bGZhjGB3nMutWQYWPYI/Bsj8Sv2b5hGbC/tdH Nx2VMop97bSeQxS1FK2wfMzYlXl8PBstsK7AR8IEl9eZezs2xSR6LTLbEWxi7WHP/81y 5aEfcMMKB8bOyj/W7yUi3ygalhRt1aLzXV0vEOcAqak37oIhnZWsiMFhQYg0adU2s+v3 4aJ5QMebi2KQc5EGqj6rH2uGJQq6HYVMCJu1KJa0Ouk5cmMBWKlFgiT7Xv7zDMdLLK9l Te6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KBbTZ/ifMEwpHm1cnuQoEJLGsYwsXct+gQZrYA2fEoM=; b=geWeqRYt9FBaHLt4NnWarBw172J1y8VQrsbZQHOh0L2dR1eeQ90G291ARiT1cTXCXO V6D/HQOcyzozMdjCSuBuS5COMWcahToDFdxl+nFP4/PFX605fDukzVQ++hdccsYRZTtt KemIIIt2B8wiURuISQt2B5A0VsYiE2ChSF+DCsXG8UaWVdyXrpPmomI+cwJjqBEjraE+ lPigQaI6kvjRS3m2eZzuG2fNMbPjEfgbRWak7JBYtvcj7AF+jkuFeThk+26leiN0mads oHi4cvZYSYYzMVVFif0+BHPEIvTizF7qR5XvlV744W41yDzV+21fDyFyVa1ZBdns2eya R0ZA== X-Gm-Message-State: AOPr4FUZSSwTsrr6mgCUMtazRtzv4YZwm5bgtQvqdHbJ149WonJIeJ4v7dLjykkuhCQ4sUL2y4ZOykOSvoGZng== X-Received: by 10.157.38.227 with SMTP id i32mr4984573otd.20.1463586482092; Wed, 18 May 2016 08:48:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.106 with HTTP; Wed, 18 May 2016 08:47:42 -0700 (PDT) In-Reply-To: <79285B74-E0A6-4C59-8C81-8F22F2943C8A@cisco.com> References: <20160512064455.15167.2456.idtracker@ietfa.amsl.com> <6a339336-a3df-6044-4c66-7a48b869670f@gmail.com> <787AE7BB302AE849A7480A190F8B933008D7585A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D763CC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <59a97075-4b2b-245a-ba57-2f09033807c8@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D76833@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <84faf286-d1c1-25d9-8bc1-5b6d5ff15a58@joelhalpern.com> <79285B74-E0A6-4C59-8C81-8F22F2943C8A@cisco.com> From: "Andrew G. Malis" Date: Wed, 18 May 2016 11:47:42 -0400 Message-ID: To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=001a113e4a0c5d00ad05331fc811 Archived-At: Cc: "Jim Guichard \(jguichar\)" , "Joel M. Halpern" , BOUCADAIR Mohamed IMT/OLN , "sfc@ietf.org" , Martin Stiemerling Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 15:48:06 -0000 --001a113e4a0c5d00ad05331fc811 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Carlos et al, There=E2=80=99s plenty of precedent for optional requirements - for example= , one that comes immediately to mind is RFC 5654, which contains =E2=80=9CMAY=E2= =80=9Ds in addition to =E2=80=9CMUST=E2=80=9Ds. Cheers, Andy On Wed, May 18, 2016 at 11:39 AM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > To be frank, =E2=80=9Coptional requirement=E2=80=9D sounds like an oxymor= on to me. > > *Requirement [ri-kwahyuh r-muh nt]* > *that which is required; a thing demanded or obligatory* > > > I understand requirements levels and RFC 2119, but really the spec ought > to be clearly aligned with the control plane, and point to normative docs > for other modules. > > I=E2=80=99d suggest trying to keep the scope and focus as per =E2=80=9CSe= rvice Function > Chaining (SFC) Control Plane Components & Requirements=E2=80=9D > > I think this is also relevant: https://tools.ietf.org/html/rfc1925 > (12) In protocol design, perfection has been reached not when there > is nothing left to add, but when there is nothing left to take > away. > > Thanks, > > =E2=80=94 Carlos. > > On May 18, 2016, at 10:36 AM, Joel M. Halpern wrote= : > > If Jim and Carlos can live with it, I will let it go. I have trouble wit= h > the notion of "optional requirements". > > Yours, > Joel > > On 5/18/16 10:31 AM, mohamed.boucadair@orange.com wrote: > > Hi Joel, > > The section describes an optional set of requirements targeting to contro= l > the full set of SFFs/SFs. For example, it specifies a requirement to > instruct to SFFs which additional information to use to enforce forwardin= g > policies (+SFP-id). > > Cheers, > Med > > -----Message d'origine----- > De : Joel M. Halpern [mailto:jmh@joelhalpern.com ] > Envoy=C3=A9 : mercredi 18 mai 2016 16:18 > =C3=80 : BOUCADAIR Mohamed IMT/OLN; Jim Guichard (jguichar); Martin > Stiemerling; sfc@ietf.org > Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt > > So let me ask the question differently. > This is the control plane requirements draft. As I understand the > intent, it is to describe the properties that control solutions must > have to meet the SFC WG needs. > > If the section is not normative, and merely describes something that can > be used in some circumstances, why are we including it? > > Yours, > Joel > > On 5/18/16 2:10 AM, mohamed.boucadair@orange.com wrote: > > Hi Jim, > > Thank you for clarifying your concern. > > RFC7665 does not exclude that additional information may be used with > > the SFP-id to make SFF forwarding decisions. Also, RFC7665 acknowledges > that multiple choices may be allowed in an SFF. See this excerpt, for > example: > > > SFFs maintain the requisite SFP forwarding information. SFP > forwarding information is associated with a service path identifier > ^^^^^^^^^^^^^ > that is used to uniquely identify an SFP. The service forwarding > state enables an SFF to identify which SFs of a given SFP should be > applied, and in what order, as traffic flows through the associated > SFP. While there may appear to the SFF to be only one available way > to deliver the given SF, there may also be multiple choices allowed > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > by the constraints of the SFP. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Section 4.10.4 does not violate RFC7665 because it assumes that the > > forwarding information is associated with SFP-id. It does not say that > additional information MUST be supported other than SFP-id, or other > information MUST be supported in addition to the SFP-id, but that some > additional information MIGHT be needed to constrain the SFP (that is stil= l > uniquely identified by an SFP-id) for deployments requiring to control th= e > full sequence of SFFs/SFs. The text cites some examples of such additiona= l > constraints. > > > Section 4.10.4 discusses how cp can be used to provision SFFs with > > additional constraints + how to it helps to retrieve the capabilities of > SFFs. > > > You said: > > I suggest that the text is silent on whether the ingress interface has > context to the SFF - its an implementation/deployment decision. > > > I see that you are not conformable with Figure 2 (despite the text is > > clear this is an example). The intent of that figure is to illustrate the > use of "match condition/action" cited in the text. > > > Would you be OK if that Figure is removed? > > Thank you. > > Cheers, > Med > > -----Message d'origine----- > De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com > ] > Envoy=C3=A9 : mardi 17 mai 2016 19:31 > =C3=80 : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.org > Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt > > Hi Med, > > My concern (as chair) is with Figure 2 (and all of the text surrounding > it) which suggests that the forwarding is based on incoming SFP-id > > *and* > > ingress port (or any of the other criteria listed). > > This is misleading based upon RFC7665 which says the SFF forwards > > packets > > based upon the information conveyed within the SFC encapsulation (see > https://tools.ietf.org/html/rfc7665#section-4.3) and the SFC > > encapsulation > > document (see > https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-7). > > I suggest that the text is silent on whether the ingress interface has > context to the SFF - its an implementation/deployment decision. > > Jim > > > On 5/17/16, 1:42 AM, "mohamed.boucadair@orange.com" > wrote: > > Hi Jim, > > I believe all your comments for section 4.10.5 (-04) (section 4.10.4 > > in > > -05) have been addressed. > > For the record, Andy shared a proposal here > (http://www.ietf.org/mail-archive/web/sfc/current/msg04616.html) while > > I > > send a text proposal here > (http://www.ietf.org/mail-archive/web/sfc/current/msg04651.html). > > These > > changes were implemented in -05 given that no objections were raised > against them. > > Also, the old section 4.10.4 was removed as per one of your comments. > > Applying policies on the full aggregate (sfp-id) is the default mode. > > But > > for the particular case of this section (that is about "Fully > > Controlled > > SFF/SF Sequence for a SFP"), there might be deployments where it is > appropriate to allow for local enforcement of polices that are more > fine-grained (TE, for example). This section does not specify a new > > sfc > > encapsulation or calls for recommendation how forwarding must be > achieved. It does discuss some information that can be passed via the > > C2 > > interface if additional information is required to achieve some TE > > goals. > > > Cheers, > Med > > -----Message d'origine----- > De : sfc [mailto:sfc-bounces@ietf.org ] De la part > de Jim Guichard > (jguichar) > Envoy=C3=A9 : samedi 14 mai 2016 19:48 > =C3=80 : Martin Stiemerling; sfc@ietf.org > Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt > > I would like to see my comments addressed for section 4.10.4. > > Our charter calls for a single SFC encapsulation and that is being > documented in draft-ietf-sfc-nsh. The text within this section > > suggests > > that forwarding can be enabled using an SFP-id and some other > > condition > > such as input port etc. This is inaccurate based upon the SFC > encapsulation as well as our WG charter. There is no mention of the > > SFC > > encapsulation or the fact that the NSH base header is the method used > for > forwarding; note that the most common forwarding method (and the one > implemented in several places) is SFP-id + index - this is not even > mentioned!. In addition, this is a control plane document; there is > > no > > need to talk about forwarding other than point to the SFC > > encapsulation > > document. > > For these reasons I would like to see this section removed from the > document. > > Jim > > > On 5/14/16, 5:28 AM, "sfc on behalf of Martin Stiemerling" > wrote: > > Dear all, > > The authors have posted an updated version addressing the reviews > > out > > of > > the WGLC. > > Please check until May 20th 5pm CEST if your comments have been > > addressed. > > > Thanks, > > Martin > > Am 12.05.16 um 08:44 schrieb internet-drafts@ietf.org: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Service Function Chaining of the > > IETF. > > > Title : Service Function Chaining (SFC) Control > > Plane > > Components & Requirements > Author : Mohamed Boucadair > Filename : draft-ietf-sfc-control-plane-05.txt > Pages : 27 > Date : 2016-05-11 > > Abstract: > This document describes requirements for conveying information > between Service Function Chaining (SFC) control elements and SFC > > data > > plane functional elements. Also, this document identifies a set > > of > > control interfaces to interact with SFC-aware elements to > > establish, > > maintain or recover service function chains. This document does > > not > > specify protocols nor extensions to existing protocols. > > This document exclusively focuses on SFC deployments that are > > under > > the responsibility of a single administrative entity. > > Inter-domain > > considerations are out of scope. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-control-plane-05 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > --001a113e4a0c5d00ad05331fc811 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Carlos et al,

There=E2=80=99s plenty of= precedent for optional requirements - for example, one that comes immediat= ely to mind is RFC 5654, which contains =E2=80=9CMAY=E2=80=9Ds in addition = to =E2=80=9CMUST=E2=80=9Ds.

Cheers,
Andy=


On Wed, May 18, 2016 at 11:39 AM, Carlos Pignataro (cpignata) <= cpignata@cisco.com> wrote:
=
To be frank, =E2=80=9Coptional requirem= ent=E2=80=9D sounds like an oxymoron to me.

Requirement=C2=A0[ri= -kwahyuh=C2=A0r-muh=C2=A0nt]
that=C2=A0which=C2=A0is=C2=A0= required;=C2=A0a=C2=A0thing=C2=A0demanded=C2=A0or=C2=A0obligatory
=

I understand requirements levels and RFC 2= 119, but really the spec ought to be clearly aligned with the control plane= , and point to normative docs for other modules.

I= =E2=80=99d suggest trying to keep the scope and focus as per =E2=80=9CServi= ce Function Chaining (SFC) Control Plane Components & Requirements=E2= =80=9D

I think this is also relevant:=C2=A0https://too= ls.ietf.org/html/rfc1925
=C2= =A0 =C2=A0(12) In protocol design, perfection has been reached not when the= re
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = is nothing left to add, but when there is nothing left to take
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 away.

Thanks,

=E2=80= =94 Carlos.

On May 18, 2016, at 10:36 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote= :

If Jim and Carlos can live with it, I will let it go.= =C2=A0 I have trouble with the notion of "optional requirements".=

Yours,
Joel

On 5/18/16 10:31 AM, mohamed.boucadair@orange.com = wrote:
Hi Joel,

The section describes a= n optional set of requirements targeting to control the full set of SFFs/SF= s. For example, it specifies a requirement to instruct to SFFs which additi= onal information to use to enforce forwarding policies (+SFP-id).

Ch= eers,
Med

-----Message d'origine---= --
De : Joel M. Halpern [mailto:jmh@joelhalpern.com]
Envoy=C3=A9 : mercredi 18 ma= i 2016 16:18
=C3=80 : BOUCADAIR Mohamed IMT/OLN; Jim Guichard (jguichar)= ; Martin
Stiemerling; = sfc@ietf.org
Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-pl= ane-05.txt

So let me ask the question differently.
This is the co= ntrol plane requirements draft.=C2=A0 As I understand the
intent, it is = to describe the properties that control solutions must
have to meet the = SFC WG needs.

If the section is not normative, and merely describes = something that can
be used in some circumstances, why are we including i= t?

Yours,
Joel

On 5/18/16 2:10 AM, mohamed.boucadair@orange.com= wrote:
Hi Jim,

Thank you for clarifyin= g your concern.

RFC7665 does not exclude that additional information= may be used with
the SFP-id to make SFF forwarding decisio= ns. Also, RFC7665 acknowledges
that multiple choices may be allowed in a= n SFF. See this excerpt, for
example:

= =C2=A0=C2=A0SFFs maintain the requisite SFP forwarding information.=C2=A0 S= FP
=C2=A0=C2=A0forwarding information is associated with a service path= identifier
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0^^^^^^^^^^^^^
=C2=A0=C2=A0that is used to uniquely id= entify an SFP.=C2=A0 The service forwarding
=C2=A0=C2=A0state enables a= n SFF to identify which SFs of a given SFP should be
=C2=A0=C2=A0applie= d, and in what order, as traffic flows through the associated
=C2=A0=C2= =A0SFP.=C2=A0 While there may appear to the SFF to be only one available wa= y
=C2=A0=C2=A0to deliver the given SF, there may also be multiple choic= es allowed
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
= =C2=A0=C2=A0by the constraints of the SFP.
=C2=A0=C2=A0^^^^^^^^^^^^^^^^= ^^^^^^^^^^^^^^

Section 4.10.4 does not violate RFC7665 because it as= sumes that the
forwarding information is associated with SF= P-id. It does not say that
additional information MUST be supported othe= r than SFP-id, or other
information MUST be supported in addition to the= SFP-id, but that some
additional information MIGHT be needed to constra= in the SFP (that is still
uniquely identified by an SFP-id) for deployme= nts requiring to control the
full sequence of SFFs/SFs. The text cites s= ome examples of such additional
constraints.

Section 4.10.4 discusses how cp can be used to provision SFFs with
additional constraints + how to it helps to retrieve the capa= bilities of
SFFs.

You said:

I suggest that the text is silent on whether the ingr= ess interface has
context to the SFF - its an implementation/deployment = decision.

I see that you are not conformable with Figur= e 2 (despite the text is
clear this is an example). The int= ent of that figure is to illustrate the
use of "match condition/act= ion" cited in the text.

Would you be = OK if that Figure is removed?

Thank you.

Cheers,
Med
-----Message d'origine-----
De : Jim Gui= chard (jguichar) [m= ailto:jguichar@cisco.com]
Envoy=C3=A9 : mardi 17 mai 2016 19:31
= =C3=80 : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.org
Objet : Re: [sfc] I-D Ac= tion: draft-ietf-sfc-control-plane-05.txt

Hi Med,

My concern = (as chair) is with Figure 2 (and all of the text surrounding
it) which s= uggests that the forwarding is based on incoming SFP-id
*and*
ingr= ess port (or any of the other criteria listed).

This is misleading b= ased upon RFC7665 which says the SFF forwards
= packets
based upon t= he information conveyed within the SFC encapsulation (see
https://too= ls.ietf.org/html/rfc7665#section-4.3) and the SFC
encapsulation
document (see
https://tools.ietf.org/html/draft-ietf-sf= c-nsh-04#section-7).

I suggest that the text is silent on whethe= r the ingress interface has
context to the SFF - its an implementation/d= eployment decision.

Jim


On 5/17/16, 1:42 AM, "mohamed.boucada= ir@orange.com"
<mohamed.boucadair@orange.com> wrote:

Hi Jim,

I believe all your comments for sect= ion 4.10.5 (-04) (section 4.10.4
= in
-05) have been addressed.

For the record, Andy shared a pr= oposal here
(http://www.ietf.org/mail-archive/web/sfc/= current/msg04616.html) while
= I
send a text proposal here
(http://www.ietf.o= rg/mail-archive/web/sfc/current/msg04651.html).
These
changes were implemented in -05 given that n= o objections were raised
against them.

Also, the old section 4.10= .4 was removed as per one of your comments.

Applying policies on the= full aggregate (sfp-id) is the default mode.
=
But
for the particular case of this section (that is abo= ut "Fully
Controlled
S= FF/SF Sequence for a SFP"), there might be deployments where it is
= appropriate to allow for local enforcement of polices that are more
fine= -grained (TE, for example).=C2=A0 This section does not specify a new
sfc
encapsulation or calls for r= ecommendation how forwarding must be
achieved. It does discuss some info= rmation that can be passed via the
C2
interface if additional information is required to achieve some = TE
goals.

Cheers,
Me= d

-----Message d'origine-----
De : = sfc [mailto:sfc-b= ounces@ietf.org] De la part de Jim Guichard
(jguichar)
Envoy=C3= =A9 : samedi 14 mai 2016 19:48
=C3=80 : Martin Stiemerling; sfc@ietf.org
Objet : Re: [sfc]= I-D Action: draft-ietf-sfc-control-plane-05.txt

I would like to see= my comments addressed for section 4.10.4.

Our charter calls for a s= ingle SFC encapsulation and that is being
documented in draft-ietf-sfc-n= sh. The text within this section
=
suggests
that forwarding can b= e enabled using an SFP-id and some other
condition
such as inpu= t port etc. This is inaccurate based upon the SFC
encapsulation as well = as our WG charter. There is no mention of the
=
SFC
encapsulation= or the fact that the NSH base header is the method used
for
forwardi= ng; note that the most common forwarding method (and the one
implemented= in several places) is SFP-id + index - this is not even
mentioned!. In = addition, this is a control plane document; there is
no
need to= talk about forwarding other than point to the SFC
encapsulation
<= blockquote type=3D"cite">
document.

For these reasons I would like to see this section remov= ed from the
document.

Jim


On 5/14/16, 5:28 AM, "s= fc on behalf of Martin Stiemerling"
<sfc-bounces@ietf.org on behalf of mls.ietf@gmail.com>= ; wrote:

Dear all,

The authors have= posted an updated version addressing the reviews
out
of
the WGLC.

Please check until May= 20th 5pm CEST if your comments have been
addressed.

Thanks,

=C2=A0=C2=A0Martin

Am 12.= 05.16 um 08:44 schrieb internet-drafts@ietf.org:

= A New Internet-Draft is available from the on-line Internet-Drafts
direc= tories.
This draft is a work item of the Service Function Chaining of th= e
IETF.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Title =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: Service Function= Chaining (SFC) Control
Plane
Components & Requirements
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Author =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: Mohamed Boucadair
Filename =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0:= draft-ietf-sfc-control-plane-05.txt
Pages =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0: 27
Date =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 2016-05-11

A= bstract:
=C2=A0=C2=A0This document describes requirements for conveying= information
=C2=A0=C2=A0between Service Function Chaining (SFC) contro= l elements and SFC
data
=C2=A0=C2=A0plane functional elements.=C2= =A0 Also, this document identifies a set
of
=C2=A0=C2=A0control i= nterfaces to interact with SFC-aware elements to
establish,
=C2= =A0=C2=A0maintain or recover service function chains.=C2=A0 This document d= oes
not
=C2=A0=C2=A0specify protocols nor extensions to existing = protocols.

=C2=A0=C2=A0This document exclusively focuses on SFC dep= loyments that are
under
=C2=A0=C2=A0the responsibility of a singl= e administrative entity.
Inter-domain
=C2=A0=C2=A0considerations = are out of scope.


The IETF datatracker status page for this draf= t is:
https://datatracker.ietf.org/doc/draft-ietf-sfc-= control-plane/

There's also a htmlized version available at:=
https://tools.ietf.org/html/draft-ietf-sfc-control-plane= -05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-control-= plane-05


Please note that it may take a couple of minutes fr= om the time of
submission
until the htmlized version and diff are ava= ilable at
tools.i= etf.org.

Internet-Drafts are also available by anonymous F= TP at:
ftp://ftp.ietf.org/internet-drafts/

___________________________= ____________________
I-D-Announce mailing list
I-D-Announce@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft dir= ectories: htt= p://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.t= xt


____________________________________________= ___
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing li= st
sfc@ietf.orght= tps://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc maili= ng list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc



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


______________________= _________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc


--001a113e4a0c5d00ad05331fc811-- From nobody Wed May 18 08:52:20 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09AE912D14E for ; Wed, 18 May 2016 08:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 2KKICq4YFpIQ for ; Wed, 18 May 2016 08:52:16 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B74312D113 for ; Wed, 18 May 2016 08:52:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35681; q=dns/txt; s=iport; t=1463586736; x=1464796336; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GfUBsfk0l5TtR/lR7ETO76pDQtQoDv8FAUZvgzAnaUY=; b=MbCSTGDVCWKaxmCtoovy5PYoJMkHe/iqq803+FILeyYhaLjU0ZwrongP wkTNm7QKZN9ALqT0evXlESUOXq1bNXqUQoseIehiMsvtVfssM+Uld+stK 2YVYPuJvHck7qF0VT2ku9go3k+h0rKnH5dXmN1XOjnR7iCkbJKJyycCL4 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BeAgBzjzxX/4ENJK1UCoJsS1V+Bq4Li?= =?us-ascii?q?2kBDYFxBBcBCoVvAoE6OBQBAQEBAQEBZSeEQgEBAQQBAQEXVAsQAgEIEQMBAiE?= =?us-ascii?q?BBgchBgsUCQgCBA4FCRKHegMXDr8hDYQfAQEBAQEBAQECAQEBAQEBAQEBAQEch?= =?us-ascii?q?iWETYJDgVQLAQErEB6FGwWTHBWESTEBhX+CeIMvgXmBaU6EAYQmgyGBG4dhFId?= =?us-ascii?q?TAQ8PAQFCggYcgUtuAYZQNn8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,329,1459814400"; d="scan'208,217";a="275109188" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 May 2016 15:51:55 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u4IFptG1026352 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 18 May 2016 15:51:55 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 18 May 2016 11:51:54 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Wed, 18 May 2016 11:51:54 -0400 From: "Carlos Pignataro (cpignata)" To: "Andrew G. Malis" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt Thread-Index: AQHRrBnpAI4wVukJpUC5G2fnLrcncp+4cOMAgACLaICAA+xVAIAAxfQAgADUOwCAAIgYAIAAA86AgAABWQCAABGjAIAAAmMA//++HYA= Date: Wed, 18 May 2016 15:51:54 +0000 Message-ID: References: <20160512064455.15167.2456.idtracker@ietfa.amsl.com> <6a339336-a3df-6044-4c66-7a48b869670f@gmail.com> <787AE7BB302AE849A7480A190F8B933008D7585A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D763CC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <59a97075-4b2b-245a-ba57-2f09033807c8@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D76833@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <84faf286-d1c1-25d9-8bc1-5b6d5ff15a58@joelhalpern.com> <79285B74-E0A6-4C59-8C81-8F22F2943C8A@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.6.4.160422 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.182.67] Content-Type: multipart/alternative; boundary="_000_D362072644614cpignataciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Jim Guichard \(jguichar\)" , "Joel M. Halpern" , BOUCADAIR Mohamed IMT/OLN , "sfc@ietf.org" , Martin Stiemerling Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 15:52:19 -0000 --_000_D362072644614cpignataciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Andy, Yes, you are right, and I agree. That=92s why I said "I understand requirem= ents levels and RFC 2119=94. However, my point (which I did not clearly articulate) was not so much abou= t optionality but about orthogonality. I can support an "optional requirement=94 (as in MAY) for a control plane f= unction. I have a hard time understanding an =93optional requirement=94 (as in it is= a requirement about SFF Forwarding and data plane and not about control pl= ane constructs). Thanks, =97 Carlos. From: "Andrew G. Malis" > Date: Wednesday, May 18, 2016 at 11:47 AM To: Carlos Pignataro > Cc: Joel Halpern >, Jim Gui= chard >, Med Boucadair >, "sfc@ietf.or= g" >, Martin Stiemer= ling > Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt Carlos et al, There=92s plenty of precedent for optional requirements - for example, one = that comes immediately to mind is RFC 5654, which contains =93MAY=94s in ad= dition to =93MUST=94s. Cheers, Andy On Wed, May 18, 2016 at 11:39 AM, Carlos Pignataro (cpignata) > wrote: To be frank, =93optional requirement=94 sounds like an oxymoron to me. Requirement [ri-kwahyuh r-muh nt] that which is required; a thing demanded or obligatory I understand requirements levels and RFC 2119, but really the spec ought to= be clearly aligned with the control plane, and point to normative docs for= other modules. I=92d suggest trying to keep the scope and focus as per =93Service Function= Chaining (SFC) Control Plane Components & Requirements=94 I think this is also relevant: https://tools.ietf.org/html/rfc1925 (12) In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away. Thanks, =97 Carlos. On May 18, 2016, at 10:36 AM, Joel M. Halpern > wrote: If Jim and Carlos can live with it, I will let it go. I have trouble with = the notion of "optional requirements". Yours, Joel On 5/18/16 10:31 AM, mohamed.boucadair@orange.com wrote: Hi Joel, The section describes an optional set of requirements targeting to control = the full set of SFFs/SFs. For example, it specifies a requirement to instru= ct to SFFs which additional information to use to enforce forwarding polici= es (+SFP-id). Cheers, Med -----Message d'origine----- De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=E9 : mercredi 18 mai 2016 16:18 =C0 : BOUCADAIR Mohamed IMT/OLN; Jim Guichard (jguichar); Martin Stiemerling; sfc@ietf.org Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt So let me ask the question differently. This is the control plane requirements draft. As I understand the intent, it is to describe the properties that control solutions must have to meet the SFC WG needs. If the section is not normative, and merely describes something that can be used in some circumstances, why are we including it? Yours, Joel On 5/18/16 2:10 AM, mohamed.boucadair@orange.com wrote: Hi Jim, Thank you for clarifying your concern. RFC7665 does not exclude that additional information may be used with the SFP-id to make SFF forwarding decisions. Also, RFC7665 acknowledges that multiple choices may be allowed in an SFF. See this excerpt, for example: SFFs maintain the requisite SFP forwarding information. SFP forwarding information is associated with a service path identifier ^^^^^^^^^^^^^ that is used to uniquely identify an SFP. The service forwarding state enables an SFF to identify which SFs of a given SFP should be applied, and in what order, as traffic flows through the associated SFP. While there may appear to the SFF to be only one available way to deliver the given SF, there may also be multiple choices allowed ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ by the constraints of the SFP. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Section 4.10.4 does not violate RFC7665 because it assumes that the forwarding information is associated with SFP-id. It does not say that additional information MUST be supported other than SFP-id, or other information MUST be supported in addition to the SFP-id, but that some additional information MIGHT be needed to constrain the SFP (that is still uniquely identified by an SFP-id) for deployments requiring to control the full sequence of SFFs/SFs. The text cites some examples of such additional constraints. Section 4.10.4 discusses how cp can be used to provision SFFs with additional constraints + how to it helps to retrieve the capabilities of SFFs. You said: I suggest that the text is silent on whether the ingress interface has context to the SFF - its an implementation/deployment decision. I see that you are not conformable with Figure 2 (despite the text is clear this is an example). The intent of that figure is to illustrate the use of "match condition/action" cited in the text. Would you be OK if that Figure is removed? Thank you. Cheers, Med -----Message d'origine----- De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Envoy=E9 : mardi 17 mai 2016 19:31 =C0 : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.org Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt Hi Med, My concern (as chair) is with Figure 2 (and all of the text surrounding it) which suggests that the forwarding is based on incoming SFP-id *and* ingress port (or any of the other criteria listed). This is misleading based upon RFC7665 which says the SFF forwards packets based upon the information conveyed within the SFC encapsulation (see https://tools.ietf.org/html/rfc7665#section-4.3) and the SFC encapsulation document (see https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-7). I suggest that the text is silent on whether the ingress interface has context to the SFF - its an implementation/deployment decision. Jim On 5/17/16, 1:42 AM, "mohamed.boucadair@orange.com" > wrote: Hi Jim, I believe all your comments for section 4.10.5 (-04) (section 4.10.4 in -05) have been addressed. For the record, Andy shared a proposal here (http://www.ietf.org/mail-archive/web/sfc/current/msg04616.html) while I send a text proposal here (http://www.ietf.org/mail-archive/web/sfc/current/msg04651.html). These changes were implemented in -05 given that no objections were raised against them. Also, the old section 4.10.4 was removed as per one of your comments. Applying policies on the full aggregate (sfp-id) is the default mode. But for the particular case of this section (that is about "Fully Controlled SFF/SF Sequence for a SFP"), there might be deployments where it is appropriate to allow for local enforcement of polices that are more fine-grained (TE, for example). This section does not specify a new sfc encapsulation or calls for recommendation how forwarding must be achieved. It does discuss some information that can be passed via the C2 interface if additional information is required to achieve some TE goals. Cheers, Med -----Message d'origine----- De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard (jguichar) Envoy=E9 : samedi 14 mai 2016 19:48 =C0 : Martin Stiemerling; sfc@ietf.org Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt I would like to see my comments addressed for section 4.10.4. Our charter calls for a single SFC encapsulation and that is being documented in draft-ietf-sfc-nsh. The text within this section suggests that forwarding can be enabled using an SFP-id and some other condition such as input port etc. This is inaccurate based upon the SFC encapsulation as well as our WG charter. There is no mention of the SFC encapsulation or the fact that the NSH base header is the method used for forwarding; note that the most common forwarding method (and the one implemented in several places) is SFP-id + index - this is not even mentioned!. In addition, this is a control plane document; there is no need to talk about forwarding other than point to the SFC encapsulation document. For these reasons I would like to see this section removed from the document. Jim On 5/14/16, 5:28 AM, "sfc on behalf of Martin Stiemerling" on behalf of mls.ietf@gm= ail.com> wrote: Dear all, The authors have posted an updated version addressing the reviews out of the WGLC. Please check until May 20th 5pm CEST if your comments have been addressed. Thanks, Martin Am 12.05.16 um 08:44 schrieb internet-drafts@ietf.org: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining of the IETF. Title : Service Function Chaining (SFC) Control Plane Components & Requirements Author : Mohamed Boucadair Filename : draft-ietf-sfc-control-plane-05.txt Pages : 27 Date : 2016-05-11 Abstract: This document describes requirements for conveying information between Service Function Chaining (SFC) control elements and SFC data plane functional elements. Also, this document identifies a set of control interfaces to interact with SFC-aware elements to establish, maintain or recover service function chains. This document does not specify protocols nor extensions to existing protocols. This document exclusively focuses on SFC deployments that are under the responsibility of a single administrative entity. Inter-domain considerations are out of scope. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-control-plane-05 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_D362072644614cpignataciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8A329334826C284ABE3383A3DBDBDC50@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Andy,

Yes, you are right, and I agree. That=92s why I said "I understan= d requirements levels and RFC 2119=94.

However, my point (which I did not clearly articulate) was not so much= about optionality but about orthogonality.

I can support an "optional requirement=94 (as in MAY) for a contr= ol plane function. 

I have a hard time understanding an =93optional requirement=94 (as in = it is a requirement about SFF Forwarding and data plane and not about contr= ol plane constructs).

Thanks,

=97 Carlos.

From: "Andrew G. Malis" &= lt;agmalis@gmail.com>
Date: Wednesday, May 18, 2016 at 11= :47 AM
To: Carlos Pignataro <cpignata@cisco.com>
Cc: Joel Halpern <jmh@joelhalpern.com>, Jim Guichard <jguichar@cisco.com>, Med Boucadair= <mohamed.boucadair@oran= ge.com>, "sfc@ietf.org" <sfc@ietf.org>, Martin Stiemerling <mls.ietf@gmail.com>
Subject: Re: [sfc] I-D Action: draf= t-ietf-sfc-control-plane-05.txt

Carlos et al,

There=92s plenty of precedent for optional requirements - for example,= one that comes immediately to mind is RFC 5654, which contains =93MAY=94s = in addition to =93MUST=94s.

Cheers,
Andy


On Wed, May 18, 2016 at 11:39 AM, Carlos Pignata= ro (cpignata) <cpignata@cisco.com> wrote:
To be frank, =93optional requirement=94= sounds like an oxymoron to me.

Requirement [ri-kwahyuh r-muh nt]
that which is required; a thing deman= ded or obligatory

I understand requirements levels and RFC 2119, but really the spec oug= ht to be clearly aligned with the control plane, and point to normative doc= s for other modules.

I=92d suggest trying to keep the scope and focus as per =93Service Fun= ction Chaining (SFC) Control Plane Components & Requirements=94

I think this is also relevant: https://tools.ietf.org/html/rfc1925
   (12) In protocol design, perfe= ction has been reached not when there
        is nothing left= to add, but when there is nothing left to take
        away.

Thanks,

=97 Carlos.

On May 18, 2016, at 10:36 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
If Jim and Carlos can live with it, I will let it go.  I have tro= uble with the notion of "optional requirements".

Yours,
Joel

On 5/18/16 10:31 AM, mohamed.boucadair@orange.com wrote:
Hi Joel,

The section describes an optional set of requirements targeting to control = the full set of SFFs/SFs. For example, it specifies a requirement to instru= ct to SFFs which additional information to use to enforce forwarding polici= es (+SFP-id).

Cheers,
Med

-----Message d'origine-----
De : Joel M. Halpern [mailto:jmh@joelhalpern.com]
Envoy=E9 : mercredi 18 mai 2016 16:18
=C0 : BOUCADAIR Mohamed IMT/OLN; Jim Guichard (jguichar); Martin
Stiemerling; sfc@ietf.org=
Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt

So let me ask the question differently.
This is the control plane requirements draft.  As I understand the
intent, it is to describe the properties that control solutions must
have to meet the SFC WG needs.

If the section is not normative, and merely describes something that can be used in some circumstances, why are we including it?

Yours,
Joel

On 5/18/16 2:10 AM, mohamed.boucadair@orange.com wrote:
Hi Jim,

Thank you for clarifying your concern.

RFC7665 does not exclude that additional information may be used with
the SFP-id to make SFF forwarding decisions. Also, RFC7665 acknowledges
that multiple choices may be allowed in an SFF. See this excerpt, for
example:

  SFFs maintain the requisite SFP forwarding information.  S= FP
  forwarding information is associated with a service path identi= fier
            &nb= sp;            = ^^^^^^^^^^^^^
  that is used to uniquely identify an SFP.  The service for= warding
  state enables an SFF to identify which SFs of a given SFP shoul= d be
  applied, and in what order, as traffic flows through the associ= ated
  SFP.  While there may appear to the SFF to be only one ava= ilable way
  to deliver the given SF, there may also be multiple choices all= owed
            &nb= sp;            =   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  by the constraints of the SFP.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Section 4.10.4 does not violate RFC7665 because it assumes that the
forwarding information is associated with SFP-id. It does not say that
additional information MUST be supported other than SFP-id, or other
information MUST be supported in addition to the SFP-id, but that some
additional information MIGHT be needed to constrain the SFP (that is still<= br> uniquely identified by an SFP-id) for deployments requiring to control the<= br> full sequence of SFFs/SFs. The text cites some examples of such additional<= br> constraints.

Section 4.10.4 discusses how cp can be used to provision SFFs with
additional constraints + how to it helps to retrieve the capabilities o= f
SFFs.

You said:

I suggest that the text is silent on whether the = ingress interface has
context to the SFF - its an implementation/deployment decision.

I see that you are not conformable with Figure 2 (despite the text is
clear this is an example). The intent of that figure is to illustrate the use of "match condition/action" cited in the text.

Would you be OK if that Figure is removed?

Thank you.

Cheers,
Med

-----Message d'origine-----
De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
Envoy=E9 : mardi 17 mai 2016 19:31
=C0 : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.org
Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt

Hi Med,

My concern (as chair) is with Figure 2 (and all of the text surrounding
it) which suggests that the forwarding is based on incoming SFP-id
*and*
ingress port (or any of the other criteria listed= ).

This is misleading based upon RFC7665 which says the SFF forwards
packets
based upon the information conveyed within the SF= C encapsulation (see
https://tools.ietf.org/html/rfc7665#section-4.3) and the SFC
encapsulation
document (see
https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-7<= /a>).

I suggest that the text is silent on whether the ingress interface has
context to the SFF - its an implementation/deployment decision.

Jim


On 5/17/16, 1:42 AM, "mohamed.boucadair@orange.com"
<moham= ed.boucadair@orange.com> wrote:

Hi Jim,

I believe all your comments for section 4.10.5 (-04) (section 4.10.4
in
-05) have been addressed.

For the record, Andy shared a proposal here
(http://www.ietf.org/mail-archive/web/sfc/current/msg0461= 6.html) while
I
send a text proposal here
(http://www.ietf.org/mail-archive/web/sfc/current/msg0465= 1.html).
These
changes were implemented in -05 given that no obj= ections were raised
against them.

Also, the old section 4.10.4 was removed as per one of your comments.

Applying policies on the full aggregate (sfp-id) is the default mode.
But
for the particular case of this section (that is = about "Fully
Controlled
SFF/SF Sequence for a SFP"), there might be = deployments where it is
appropriate to allow for local enforcement of polices that are more
fine-grained (TE, for example).  This section does not specify a new
sfc
encapsulation or calls for recommendation how for= warding must be
achieved. It does discuss some information that can be passed via the
C2
interface if additional information is required t= o achieve some TE
goals.

Cheers,
Med

-----Message d'origine-----
De : sfc [mailto:= sfc-bounces@ietf.org] De la part de Jim Guichard
(jguichar)
Envoy=E9 : samedi 14 mai 2016 19:48
=C0 : Martin Stiemerling; sfc@ietf.org
Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt

I would like to see my comments addressed for section 4.10.4.

Our charter calls for a single SFC encapsulation and that is being
documented in draft-ietf-sfc-nsh. The text within this section
suggests
that forwarding can be enabled using an SFP-id an= d some other
condition
such as input port etc. This is inaccurate based = upon the SFC
encapsulation as well as our WG charter. There is no mention of the
SFC
encapsulation or the fact that the NSH base heade= r is the method used
for
forwarding; note that the most common forwarding method (and the one
implemented in several places) is SFP-id + index - this is not even
mentioned!. In addition, this is a control plane document; there is
no
need to talk about forwarding other than point to= the SFC
encapsulation
document.

For these reasons I would like to see this section removed from the
document.

Jim


On 5/14/16, 5:28 AM, "sfc on behalf of Martin Stiemerling"
<sfc-bounces@i= etf.org on behalf of mls.ietf@gmail.com<= /a>> wrote:

Dear all,

The authors have posted an updated version addressing the reviews
out
of
the WGLC.

Please check until May 20th 5pm CEST if your comments have been
addressed.

Thanks,

  Martin

Am 12.05.16 um 08:44 schrieb internet-drafts@ietf.org:

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Service Function Chaining of the
IETF.

       Title     &nb= sp;     : Service Function Chaining (SFC) Control<= br>
Plane
Components & Requirements
       Author     &n= bsp;    : Mohamed Boucadair
Filename    &nbs= p;   : draft-ietf-sfc-control-plane-05.txt
Pages     &= nbsp;     : 27
Date     &n= bsp;      : 2016-05-11

Abstract:
  This document describes requirements for conveying information<= br>   between Service Function Chaining (SFC) control elements and SF= C
data
  plane functional elements.  Also= , this document identifies a set
of
  control interfaces to interact with S= FC-aware elements to
establish,
  maintain or recover service function = chains.  This document does
not
  specify protocols nor extensions to e= xisting protocols.

  This document exclusively focuses on SFC deployments that are
under
  the responsibility of a single admini= strative entity.
Inter-domain
  considerations are out of scope.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sfc-control-p= lane/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05<= /a>

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-c= ontrol-plane-05


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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt


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

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

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



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


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


 --_000_D362072644614cpignataciscocom_-- From nobody Wed May 18 10:06:41 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E8612D5DB for ; Wed, 18 May 2016 10:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 NQZTeKOT_Ur2 for ; Wed, 18 May 2016 10:06:38 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 902C612D562 for ; Wed, 18 May 2016 10:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=516; q=dns/txt; s=iport; t=1463591198; x=1464800798; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dTk/K/R25nGYsVol2A6ydM0OCgg/SuWPXfmLyq20oBY=; b=Ab3ZjE9ApdhVTEtgxRa2OlyLd12TZVDwqTG01pXooGbtdmKqAH7fkKOI 0tIsX9Li5/05WBvWT9a4uUTemrZuetaWTRxfg9Eyf0HlReLgumvkM9KLi 8p7VxUQlg7akq+51ClyL8oc5pgRbFdbarpY8ENKCgbDFfn6UZNuaNL6nV Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQCdnzxX/4QNJK1egzeBVAa5dQENg?= =?us-ascii?q?XWGEQKBPTgUAQEBAQEBAWUnhEIBAQEDAXkFCwIBCBguMiUCBA4FiCcIxA0BAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEchiWBdgiCT4Q/gyuCLgEEmCsBjh+BU41Hj0gBH?= =?us-ascii?q?gEBQoNtbocHfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,329,1459814400"; d="scan'208";a="274412124" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 May 2016 17:06:33 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u4IH6XPk022009 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 18 May 2016 17:06:33 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 18 May 2016 12:06:32 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1104.009; Wed, 18 May 2016 12:06:32 -0500 From: "Paul Quinn (paulq)" To: "Joel M. Halpern" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt Thread-Index: AQHRrBnowmZdxnQkbUqg6/VjwwWUs5+4gacAgACLZ4CAA+xWAIAAxfQAgADUOwCAAIgYAIAAA86AgAABWACAACoKAA== Date: Wed, 18 May 2016 17:06:32 +0000 Message-ID: <68F107A9-2763-49AC-B986-C615CC2AE873@cisco.com> References: <20160512064455.15167.2456.idtracker@ietfa.amsl.com> <6a339336-a3df-6044-4c66-7a48b869670f@gmail.com> <787AE7BB302AE849A7480A190F8B933008D7585A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D763CC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <59a97075-4b2b-245a-ba57-2f09033807c8@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D76833@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <84faf286-d1c1-25d9-8bc1-5b6d5ff15a58@joelhalpern.com> In-Reply-To: <84faf286-d1c1-25d9-8bc1-5b6d5ff15a58@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.118.80] Content-Type: text/plain; charset="Windows-1252" Content-ID: <35821350EC542D4C9F3527C891F0A926@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 17:06:40 -0000 > On May 18, 2016, at 10:36 AM, Joel M. Halpern wrote= : >=20 > If Jim and Carlos can live with it, I will let it go. I have trouble wit= h the notion of "optional requirements". >=20 So do I. "optional requirements" runs contrary to the goal of the document= and, in essence, runs the risk of creating a non-exhautive list of options= , not requirements. The draft should be narrow, anchored by the Arch RFC and focus on the requi= rements for an NSH-service chain.=20 From nobody Wed May 18 10:55:10 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66D912D620 for ; Wed, 18 May 2016 10:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 W3sBIsjgjXgc for ; Wed, 18 May 2016 10:55:06 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6C1412D61A for ; Wed, 18 May 2016 10:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=64792; q=dns/txt; s=iport; t=1463594104; x=1464803704; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZP8wk4uPeYKgAaOPXCDMWwNb1TM9AhnJPgYJY3kgtxM=; b=ReGQrqBuC7mcQOEQFeX1OzPa6CwPPqvTN2cHVAgXGxphNavE7ELVhh93 hJ+gIkPL79+muZw6d96mqy9Pts72WUhffrJ8/XQVmQmuLMVN8oCx3xLnZ ZjLX2wO7ASz3WlpMjcarUg0Rgxm1XxdoS98egaEBsqYajOpULmsGUEay/ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQCVqzxX/4MNJK1UCoJsS1Z+Bq4Mi?= =?us-ascii?q?2kBDYFxBBcBCoVvAoE+OBQBAQEBAQEBZSeEQgEBAQMBAQEBFwNKBwsQAgEIEQM?= =?us-ascii?q?BAgEgAQYHIQYLFAkIAgQBDQUJiAwDDwgOv1ENhB8BAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEchiWETYJDgVQLAQE7FgiFGwWTHBWESTEBhX+CeIMvgXmBaU6EAYQmgyG?= =?us-ascii?q?BG4dhFIdTAQ8PAQFCggYcgUtuAYZQNn8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,330,1459814400"; d="scan'208,217";a="109320514" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 May 2016 17:55:03 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u4IHt2db007697 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 18 May 2016 17:55:02 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 18 May 2016 12:55:02 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1104.009; Wed, 18 May 2016 12:55:01 -0500 From: "Jim Guichard (jguichar)" To: "Andrew G. Malis" , BOUCADAIR Mohamed IMT/OLN Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt Thread-Index: AQHRrBnorsE3n3ea8ESTJLAGtYIQrp+4gacAgABIV4CABC9mAIAAguMAgAC2wvCAAHoMAIAABJbggABeggCAAAUmAA== Date: Wed, 18 May 2016 17:55:01 +0000 Message-ID: References: <20160512064455.15167.2456.idtracker@ietfa.amsl.com> <6a339336-a3df-6044-4c66-7a48b869670f@gmail.com> <787AE7BB302AE849A7480A190F8B933008D7585A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D763CC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D76703@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.52.132] Content-Type: multipart/alternative; boundary="_000_D36223A84F69Cjguicharciscocom_" MIME-Version: 1.0 Archived-At: Cc: Martin Stiemerling , "sfc@ietf.org" Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 17:55:09 -0000 --_000_D36223A84F69Cjguicharciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Andy, Its the last part of the sentence I do not like as the SFC encapsulation do= es not call for steering policies specific to an ingress port. I am okay wi= th saying =93As a local decision, there may be multiple different steering = policies that work in conjunction with the SFC encapsulation as specified i= n [draft-ietf-sfc-nsh reference] for one flow within one SFF=94. Frankly though I would rather see the entire section removed from the docum= ent as I don=92t see it adds value but rather confusion (but that=92s a dec= ision for the WG =96 its just my personal opinion). Jim From: "Andrew G. Malis" > Date: Wednesday, May 18, 2016 at 9:36 AM To: BOUCADAIR Mohamed IMT/OLN > Cc: Jim Guichard >, Martin St= iemerling >, "sfc@ietf.org" > Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt I=92m OK with the second change. Regarding the first change, Jim asked to remove the text "There are multipl= e different steering policies for one flow within one SFF and each set of s= teering policies is specific for an ingress port.=94. Rather than remove it, I would suggest to revise it to: =93As a local decis= ion, there may be multiple different steering policies for a flow within an= SFF and steering policies may be specific for an ingress port.=94. Thanks, Andy On Wed, May 18, 2016 at 9:01 AM, > wrote: Re-, Works for me. Unless there is an objection, these changes will be implemented in the next= revision. Thank you. Cheers, Med De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Envoy=E9 : mercredi 18 mai 2016 13:42 =C0 : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.org Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt Hi Med, Yes, if you can remove Figure 2 and also the text "There are multiple diffe= rent steering policies for one flow within one SFF and each set of steering= policies is specific for an ingress port=94. In addition, can you also make it clear in the text that the SFP-id is carr= ied within the SFC encapsulation. Suggested text: Old: For example, it could be the SFP-id together with any fields in the data pa= ckets, such as (non-exhaustive list): New: For example, it could be the SFP-id carried within the SFC encapsulation wi= th any fields in the data packets, such as (non-exhaustive list): Jim On 5/18/16, 2:10 AM, "mohamed.boucadair@orange.com" > wrote: Hi Jim, Thank you for clarifying your concern. RFC7665 does not exclude that additional information may be used with the S= FP-id to make SFF forwarding decisions. Also, RFC7665 acknowledges that mul= tiple choices may be allowed in an SFF. See this excerpt, for example: SFFs maintain the requisite SFP forwarding information. SFP forwarding information is associated with a service path identifier ^^^^^^^^^^^^^ that is used to uniquely identify an SFP. The service forwarding state enables an SFF to identify which SFs of a given SFP should be applied, and in what order, as traffic flows through the associated SFP. While there may appear to the SFF to be only one available way to deliver the given SF, there may also be multiple choices allowed ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ by the constraints of the SFP. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Section 4.10.4 does not violate RFC7665 because it assumes that the forward= ing information is associated with SFP-id. It does not say that additional = information MUST be supported other than SFP-id, or other information MUST = be supported in addition to the SFP-id, but that some additional informatio= n MIGHT be needed to constrain the SFP (that is still uniquely identified b= y an SFP-id) for deployments requiring to control the full sequence of SFFs= /SFs. The text cites some examples of such additional constraints. Section 4.10.4 discusses how cp can be used to provision SFFs with addition= al constraints + how to it helps to retrieve the capabilities of SFFs. You said: I suggest that the text is silent on whether the ingress interface has context to the SFF - its an implementation/deployment decision. I see that you are not conformable with Figure 2 (despite the text is clear= this is an example). The intent of that figure is to illustrate the use of= "match condition/action" cited in the text. Would you be OK if that Figure is removed? Thank you. Cheers, Med -----Message d'origine----- De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Envoy=E9 : mardi 17 mai 2016 19:31 =C0 : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.org Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt Hi Med, My concern (as chair) is with Figure 2 (and all of the text surrounding it) which suggests that the forwarding is based on incoming SFP-id *and* ingress port (or any of the other criteria listed). This is misleading based upon RFC7665 which says the SFF forwards packets based upon the information conveyed within the SFC encapsulation (see https://tools.ietf.org/html/rfc7665#section-4.3) and the SFC encapsulation document (see https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-7). I suggest that the text is silent on whether the ingress interface has context to the SFF - its an implementation/deployment decision. Jim On 5/17/16, 1:42 AM, "mohamed.boucadair@orange.com" > wrote: >Hi Jim, > >I believe all your comments for section 4.10.5 (-04) (section 4.10.4 in >-05) have been addressed. > >For the record, Andy shared a proposal here >(http://www.ietf.org/mail-archive/web/sfc/current/msg04616.html) while I >send a text proposal here >(http://www.ietf.org/mail-archive/web/sfc/current/msg04651.html). These >changes were implemented in -05 given that no objections were raised >against them. > >Also, the old section 4.10.4 was removed as per one of your comments. > >Applying policies on the full aggregate (sfp-id) is the default mode. But >for the particular case of this section (that is about "Fully Controlled >SFF/SF Sequence for a SFP"), there might be deployments where it is >appropriate to allow for local enforcement of polices that are more >fine-grained (TE, for example). This section does not specify a new sfc >encapsulation or calls for recommendation how forwarding must be >achieved. It does discuss some information that can be passed via the C2 >interface if additional information is required to achieve some TE goals. > >Cheers, >Med > >> -----Message d'origine----- >> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard >> (jguichar) >> Envoy=E9 : samedi 14 mai 2016 19:48 >> =C0 : Martin Stiemerling; sfc@ietf.org >> Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt >> >> I would like to see my comments addressed for section 4.10.4. >> >> Our charter calls for a single SFC encapsulation and that is being >> documented in draft-ietf-sfc-nsh. The text within this section suggests >> that forwarding can be enabled using an SFP-id and some other condition >> such as input port etc. This is inaccurate based upon the SFC >> encapsulation as well as our WG charter. There is no mention of the SFC >> encapsulation or the fact that the NSH base header is the method used >>for >> forwarding; note that the most common forwarding method (and the one >> implemented in several places) is SFP-id + index - this is not even >> mentioned!. In addition, this is a control plane document; there is no >> need to talk about forwarding other than point to the SFC encapsulation >> document. >> >> For these reasons I would like to see this section removed from the >> document. >> >> Jim >> >> >> On 5/14/16, 5:28 AM, "sfc on behalf of Martin Stiemerling" >> on behalf of mls.ietf= @gmail.com> wrote: >> >> >Dear all, >> > >> >The authors have posted an updated version addressing the reviews out >>of >> >the WGLC. >> > >> >Please check until May 20th 5pm CEST if your comments have been >> addressed. >> > >> >Thanks, >> > >> > Martin >> > >> >Am 12.05.16 um 08:44 schrieb internet-drafts@ietf.org: >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> >>directories. >> >> This draft is a work item of the Service Function Chaining of the >>IETF. >> >> >> >> Title : Service Function Chaining (SFC) Control >>Plane >> >>Components & Requirements >> >> Author : Mohamed Boucadair >> >> Filename : draft-ietf-sfc-control-plane-05.txt >> >> Pages : 27 >> >> Date : 2016-05-11 >> >> >> >> Abstract: >> >> This document describes requirements for conveying information >> >> between Service Function Chaining (SFC) control elements and SFC >> data >> >> plane functional elements. Also, this document identifies a set >>of >> >> control interfaces to interact with SFC-aware elements to >>establish, >> >> maintain or recover service function chains. This document does >>not >> >> specify protocols nor extensions to existing protocols. >> >> >> >> This document exclusively focuses on SFC deployments that are >>under >> >> the responsibility of a single administrative entity. >>Inter-domain >> >> considerations are out of scope. >> >> >> >> >> >> The IETF datatracker status page for this draft is: >> >> https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ >> >> >> >> There's also a htmlized version available at: >> >> https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05 >> >> >> >> A diff from the previous version is available at: >> >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-control-plane-05 >> >> >> >> >> >> 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/ >> >> >> >> _______________________________________________ >> >> I-D-Announce mailing list >> >> I-D-Announce@ietf.org >> >> https://www.ietf.org/mailman/listinfo/i-d-announce >> >> Internet-Draft directories: http://www.ietf.org/shadow.html >> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> > >> >_______________________________________________ >> >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_D36223A84F69Cjguicharciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <28DE984E6970C743A51831A077256659@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Andy,

Its the last part of the sentence I do not like as the SFC encapsulati= on does not call for steering policies specific to an ingress port. I am ok= ay with saying =93As a local decision, there may be multiple different stee= ring policies that work in conjunction with the SFC encapsulation as specified in [dra= ft-ietf-sfc-nsh reference] for one flow within one SFF=94.

Frankly though I would rather see the entire section removed from the = document as I don=92t see it adds value but rather confusion (but that=92s = a decision for the WG =96 its just my personal opinion).

Jim

From: "Andrew G. Malis" &= lt;agmalis@gmail.com>
Date: Wednesday, May 18, 2016 at 9:= 36 AM
To: BOUCADAIR Mohamed IMT/OLN <<= a href=3D"mailto:mohamed.boucadair@orange.com">mohamed.boucadair@orange.com= >
Cc: Jim Guichard <jguichar@cisco.com>, Martin Stiemerling <= mls.ietf@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] I-D Action: draf= t-ietf-sfc-control-plane-05.txt

I=92m OK with the second change.

Regarding the first change, Jim asked to remove the text "There a= re multiple different steering policies for one flow within one SFF and eac= h set of steering policies is specific for an ingress port.=94.

Rather than remove it, I would suggest to revise it to: =93As a local = decision, there may be multiple different steering policies for a flow with= in an SFF and  steering policies may be specific for an ingress port.= =94.

Thanks,
Andy

On Wed, May 18, 2016 at 9:01 AM, <mo= hamed.boucadair@orange.com> wrote:

Re-,

 

Works for me.

 

Unless there is an objection, t= hese changes will be implemented in the next revision.=

 

Thank you.=

 

Cheers,

Med

 

De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
Envoy=E9 : mercredi 18 mai 2016 13:42


=C0 : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.org
Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.t= xt

 

Hi Med,

 

Yes, if you can remove Figure 2 and also the= text "There are multiple different steering policies for one flow wit= hin one SFF and each set of steering policies is specific for an ingress port= =94.

 

In addition, can you also make it clear in t= he text that the SFP-id is carried within the SFC encapsulation. Suggested = text:

 

Old:

 

For example, it could be the SFP-id tog= ether with any fields in the data packets, such as (non-exhaustive lis= t):



New:



For example, it could be the SFP-id carried within the SFC encapsulation with any fields in the data packets, su= ch as (non-exhaustive list):

 

Jim

 

 

Hi Jim,

 

Thank you for clarifying your concern.

 

RFC7665 does not exclude that additional inf= ormation may be used with the SFP-id to make SFF forwarding decisions. Also= , RFC7665 acknowledges that multiple choices may be allowed in an SFF. See this excerpt, for example: &nbs= p;

 

   SFFs maintain the requisite SFP= forwarding information.  SFP

   forwarding information is assoc= iated with a service path identifier

       &n= bsp;            = ;      ^^^^^^^^^^^^^

   that is used to uniquely identi= fy an SFP.  The service forwarding

   state enables an SFF to identif= y which SFs of a given SFP should be

   applied, and in what order, as = traffic flows through the associated

   SFP.  While there may= appear to the SFF to be only one available way

   to deliver the given SF, there = may also be multiple choices allowed

       &n= bsp;            = ;        ^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^^^^^^^^^^^    

   by the constraints of the SFP.<= u>

   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<= u>

 

Section 4.10.4 does not violate RFC7665 beca= use it assumes that the forwarding information is associated with SFP-id. I= t does not say that additional information MUST be supported other than SFP-id, or other information MUST be supporte= d in addition to the SFP-id, but that some additional information MIGHT be = needed to constrain the SFP (that is still uniquely identified by an SFP-id= ) for deployments requiring to control the full sequence of SFFs/SFs. The text cites some examples of such additi= onal constraints.

 

Section 4.10.4 discusses how cp can be used = to provision SFFs with additional constraints + how to it helps to retr= ieve the capabilities of SFFs.

 

You said:

 

I suggest that the text is silent on whether= the ingress interface has

context to the SFF - its an implementation/d= eployment decision.

 

I see that you are not conformable with Figu= re 2 (despite the text is clear this is an example). The intent of that fig= ure is to illustrate the use of "match condition/action" cited in the text.  =

 

Would you be OK if that Figure is removed?

 

Thank you.

 

Cheers,

Med

 

-----Message d'origine-----

De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com<= /a>]

Envoy=E9 : mardi 17 mai 2016 19:31

Objet : Re: [sfc] I-D Action: draft-iet= f-sfc-control-plane-05.txt

Hi Med,

My concern (as chair) is with Figure 2 (and = all of the text surrounding

it) which suggests that the forwarding is ba= sed on incoming SFP-id *and*

ingress port (or any of the other criteria l= isted).

This is misleading based upon RFC7665 which = says the SFF forwards packets

based upon the information conveyed within t= he SFC encapsulation (see

document (see

I suggest that the text is silent on whether= the ingress interface has

context to the SFF - its an implementation/d= eployment decision.

Jim

On 5/17/16, 1:42 AM, "mohamed.boucadair@orange.c= om"

>Hi Jim,

> 

>I believe all your comments for section = 4.10.5 (-04) (section 4.10.4 in

>-05) have been addressed.<= /span>

> 

>For the record, Andy shared a proposal h= ere

>send a text proposal here<= /span>

>changes were implemented in -05 given th= at no objections were raised

>against them.

> 

>Also, the old section 4.10.4 was removed= as per one of your comments.

> 

>Applying policies on the full aggregate = (sfp-id) is the default mode. But

>for the particular case of this section = (that is about "Fully Controlled

>SFF/SF Sequence for a SFP"), there = might be deployments where it is

>appropriate to allow for local enforceme= nt of polices that are more

>fine-grained (TE, for example). &nb= sp;This section does not specify a new sfc

>encapsulation or calls for recommendatio= n how forwarding must be

>achieved. It does discuss some informati= on that can be passed via the C2

>interface if additional information is r= equired to achieve some TE goals.

> 

>Cheers,

>Med

> 

>> -----Message d'origine-----<= u>

>> De : sfc [mailto:sfc-bounces@ietf.org] De la par= t de Jim Guichard

>> (jguichar)

>> Envoy=E9 : samedi 14 mai 2016 19:48=

>> =C0 : Martin Stiemerling; sfc@ietf.org

>> Objet : Re: [sfc] I-D Action: draft= -ietf-sfc-control-plane-05.txt

>> 

>> I would like to see my comments add= ressed for section 4.10.4.

>> 

>> Our charter calls for a single SFC = encapsulation and that is being

>> documented in draft-ietf-sfc-nsh. T= he text within this section suggests

>> that forwarding can be enabled usin= g an SFP-id and some other condition

>> such as input port etc. This is ina= ccurate based upon the SFC

>> encapsulation as well as our WG cha= rter. There is no mention of the SFC

>> encapsulation or the fact that the = NSH base header is the method used

>>for

>> forwarding; note that the most comm= on forwarding method (and the one

>> implemented in several places) is S= FP-id + index - this is not even

>> mentioned!. In addition, this is a = control plane document; there is no

>> need to talk about forwarding other= than point to the SFC encapsulation

>> document.

>> 

>> For these reasons I would like to s= ee this section removed from the

>> document.

>> 

>> Jim

>> 

>> 

>> On 5/14/16, 5:28 AM, "sfc on b= ehalf of Martin Stiemerling"

>> 

>> >Dear all,<= /p>

>> >

>> >The authors have posted an upda= ted version addressing the reviews out

>>of

>> >the WGLC.<= /p>

>> >

>> >Please check until May 20th 5pm= CEST if your comments have been

>> addressed.

>> >

>> >Thanks,

>> >

>> >    Martin<= u>

>> >

>> >>

>> >> A New Internet-Draft is av= ailable from the on-line Internet-Drafts

>> >>directories.<= /span>

>> >> This draft is a work item = of the Service Function Chaining of the

>>IETF.

>> >>

>> >>    &nb= sp;    Title        =    : Service Function Chaining (SFC) Control=

>>Plane

>> >>Components & Requiremen= ts

>> >>    &nb= sp;    Author        = ;  : Mohamed Boucadair

>> >> Filename   =      : draft-ietf-sfc-control-plane-05.txt<= u>

>> >> Pages   &nb= sp;       : 27

>> >> Date   &nbs= p;        : 2016-05-11

>> >>

>> >> Abstract:

>> >>    Thi= s document describes requirements for conveying information

>> >>    bet= ween Service Function Chaining (SFC) control elements and SFC=

>> data

>> >>    pla= ne functional elements.  Also, this document identifies a set<= /u>

>>of

>> >>    con= trol interfaces to interact with SFC-aware elements to=

>>establish,

>> >>    mai= ntain or recover service function chains.  This document does<= /u>

>>not

>> >>    spe= cify protocols nor extensions to existing protocols.

>> >>

>> >>    Thi= s document exclusively focuses on SFC deployments that are

>>under

>> >>    the= responsibility of a single administrative entity.

>>Inter-domain

>> >>    con= siderations are out of scope.

>> >>

>> >>

>> >> The IETF datatracker statu= s page for this draft is:

>> >>

>> >> There's also a htmlized ve= rsion available at:

>> >>

>> >> A diff from the previous v= ersion is available at:

>> >>

>> >>

>> >> Please note that it may ta= ke a couple of minutes from the time of

>> >>submission

>> >> until the htmlized version= and diff are available at tools.ietf.org.<= /u>

>> >>

>> >> Internet-Drafts are also a= vailable by anonymous FTP at:

>> >>

>> >> __________________________= _____________________

>> >> I-D-Announce mailing list<= u>

>> >> Internet-Draft directories= : http://www.ie= tf.org/shadow.html

>> >>

>> >

>> >_______________________________= ________________

>> >sfc mailing list<= /span>

>> 

>> ___________________________________= ____________

>> sfc mailing list

 

 


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


 --_000_D36223A84F69Cjguicharciscocom_-- From nobody Wed May 18 15:18:59 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE10812D789 for ; Wed, 18 May 2016 15:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.447 X-Spam-Level: X-Spam-Status: No, score=-8.447 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=f5.com 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 XLRzvYAxtO79 for ; Wed, 18 May 2016 15:18:55 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91F9412D75F for ; Wed, 18 May 2016 15:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1463609936; x=1495145936; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BIbqP3vl/d7ztKQ02I8pu5Hqivqm0wN28NgyMcmYJ/8=; b=OXDHxlf8u3sDUzLKG7ftRUY7yn6HRD35H0Xg8omZrV8jcqAsHZuc+1Dr 8fwyEAknyWEpMnTB7hiE/OFCsehRnGvvvM0CRdiMXMcb7QjdOBwTXsJTH UCA5I1aBecZFiXlF8GzCFmNq5yKBhWsw5dZSnl1FuLsiz9d8wA+WfSYAg s=; X-IronPort-AV: E=Sophos;i="5.26,331,1459814400"; d="scan'208";a="219696661" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 18 May 2016 22:18:54 +0000 Received: from SEAEXCHMBX04.olympus.F5Net.com (192.168.15.226) by SEAEXCHMBX08.olympus.F5Net.com (192.168.15.227) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 18 May 2016 15:18:53 -0700 Received: from SEAEXCHMBX04.olympus.F5Net.com ([fe80::856e:99ba:ff8b:b756]) by SEAEXCHMBX04.olympus.F5Net.com ([fe80::856e:99ba:ff8b:b756%21]) with mapi id 15.00.1178.000; Wed, 18 May 2016 15:18:53 -0700 From: Christian Koenning To: "Joel M. Halpern" Thread-Topic: [sfc] Service Path Identifier (SPI) and symmetry Thread-Index: AQHRsHUtFvsY0ydaV0iEs6canF5mkp++ASSAgAASbwD///A3AIAAG7uA///wlQD//43gnQAPAVIAAATLtID///kAAIAAAeWAgAGUbAA= Date: Wed, 18 May 2016 22:18:52 +0000 Message-ID: <3AA4099A-196D-4B9F-9B22-065BB519AAA7@f5.com> References: <708683c2-8c57-41e1-0dc9-153fd09ecdcd@joelhalpern.com> <4ffc7b1e-b9cd-ea61-58b1-55e93e373768@joelhalpern.com> <00D7FD5C-2F8A-4D21-AC12-C560E106704D@F5.com> <6737272c-dbbc-f985-1c9a-7dd93b99659a@joelhalpern.com> <604cceed-4030-79e7-01f9-29a335058bc0@joelhalpern.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="utf-8" Content-ID: <396A4A448B1EAA45A2CF6D3D10A0F7F9@F5.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Service Path Identifier (SPI) and symmetry X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 22:18:58 -0000 VGhhbmtzIEpvZWwhDQoNCkFsbG93IG1lIHRvIGVsYWJvcmF0ZSBvbiB0aGUgY29uZnVzaW9uIGZ1 cnRoZXIuDQoNCjxDT05URVhUPg0KDQo+T24gMTcvMDUvMjAxNiwgMjE6MDcsICJKb2VsIE0uIEhh bHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPg0KPndyb3RlOg0KDQo+Q29ycmVsYXRpb24gb2Yg cGFja2V0cyBpbiB0d28gZGlyZWN0aW9ucyBmb3IgYW4gU0Ygd2hpY2ggd29ya3MNCj5zZWVtcyB0 byByZXF1aXJlIHRoYXQgdGhlIFNGIGtub3cgaG93IHRvIGNvcnJlbGF0ZSBwYWNrZXRzLiAgSWQN Cj5kb2VzIG5vdCBuZWVkIHRvIGxvb2sgYXQgdGhlIFNQSSBmb3IgdGhhdCwgc2luY2UgU1BJIGFy ZQ0KPmNvYXJzZXIgdGhhbiBmbG93LiAgSXQgbWF5IG5lZWQgdG8gbG9vayBhdCBtZXRhZGF0YSAo c3VjaCBhcw0KPnN1YnNjcmliZXIgaWRlbnRpdHkpIGlmIHRoZSBTRiBpcyBpbnNpZGUgYSBkb21h aW4gd2hlcmUgSVANCj5hZGRyZXNzZXMgYXJlIHJldXNlZCAoTkFUIGJlaW5nIGEgc2VydmljZSBm dW5jdGlvbiBpdHNlbGYsIHNvDQo+b25lIGNvdWxkIGJlIG9uIHRoZSByZXVzZSBzaWRlIG9mIGEg TkFULikNCg0KPk9uIDUvMTcvMTYgNDowMiBQTSwgQ2hyaXN0aWFuIEtvZW5uaW5nIHdyb3RlOiBU aGFua3MgSm9lbCwNCg0KPnRoYXQgaXMgd2hlcmUgSSB3YXMgZ2V0dGluZyBjb25mdXNlZC4NCg0K PldoZW4gbG9va2luZyBlLmcuIGF0IGEgc3RhdGVmdWwgU2VydmljZSBGdW5jdGlvbiAoU0YpLCB0 aGVyZQ0KPm5lZWRzIHRvIGJlIGFuIGluc3RydWN0aW9uIHdoaWNoIHR3byBvZiB0aGUgU2Vydmlj ZSBQYXRoDQo+SWRlbnRpZmllcnMgY28tcmVsZWF0ZSBpbiBvcmRlciB0byBlc3RhYmxpc2ggc3Rh dGUuDQoNCjwvQ09OVEVYVD4NCg0KVGFraW5nIHRoZSBjYXNlIG9mIHRoZSBTZXJ2aWNlIEZ1bmN0 aW9uIChTRikgZS5nLiB0ZXJtaW5hdGluZyB0aGUNCmNvbm5lY3Rpb24sIG9yIGFsbG93aW5nIGZv ciBsYXRlIGJpbmRpbmcsIHRoZSBTRiB3b3VsZCBuZWVkIHRvIHNlbnQgdGhlDQpUQ1AgU1lOL0FD SyBzZWdtZW50IGJhY2suIElmIHRoZXJlIGlzIG5vIGEtcHJpbyBrbm93bGVkZ2Ugb2YgdGhlIHJl dHVybg0KU1BJJywgdGhlbiB3aGF0IFNQSScgd291bGQgdGhlIFNGIGNob29zZSA/DQoNCg0KTWFu eSBUaGFua3MNCg0KQ2hyaXN0aWFuIEtvZW5uaW5nIA0KLS0gDQpGNSBOZXR3b3JrcyBJbmMuIA0K Y2hyaXN0aWFuQGY1LmNvbQ0KDQoNCg0KDQoNCg0KDQoNCk9uIDE4LzA1LzIwMTYsIDAwOjExLCAi Sm9lbCBNLiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6DQoNCj5JIHJlYWxp emVkIHJlYWRpbmcgbXkgcmVwbHkgdGhhdCBJIGxlZnQgb3V0IHNvbWV0aGluZyBpbXBvcnRhbnQu DQo+VGhlIGZhY3QgdGhhdCB5b3UgZm91bmQgdGhpcyBjb25mdXNpbmcgaXMgYSBnb29kIGluZGlj YXRpb24gdGhhdCB3ZSANCj5zaG91bGQgdHJ5IHRvIGltcHJvdmUgdGhlIHRleHQuDQo+DQo+WW91 cnMsDQo+Sm9lbA0KPg0KPk9uIDUvMTcvMTYgNzowNCBQTSwgSm9lbCBNLiBIYWxwZXJuIHdyb3Rl Og0KPj4gSSBhbSBub3Qgc3VyZSB3aGljaCBhc3BlY3RzIGNhbiByZWFzb25hYmx5IGdvIGluIHRo ZSBOU0ggZHJhZnQuICBGb3INCj4+IGV4YW1wbGUsIGFsdGhvdWdoIHRoZSBWeExBTiBleGFtcGxl IGNhbiBiZSBlbmhhbmNlZCwgaXQgaXMgc3RpbGwgYW4NCj4+IGV4YW1wbGUsIG5vdCBhbnl0aGlu ZyBub3JtYXRpdmUuDQo+Pg0KPj4gQmFzaWNhbGx5LCBhZGRpdGlvbnMgYXJlIHVwIHRvIHRoZSBX Ry4gIFdpdGhpbiB0aGUgc2NvcGUgb2YgdGhlIGRvY3VtZW50DQo+PiBhbmQgV0cgY2hhcnRlci4N Cj4+DQo+PiBZb3VycywNCj4+IEpvZWwNCj4+DQo+PiBPbiA1LzE3LzE2IDY6MjggUE0sIENocmlz dGlhbiBLb2VubmluZyB3cm90ZToNCj4+PiBUaGFua3MgSm9lbCwNCj4+Pg0KPj4+IFdvdWxkIGl0 IGJlIHBvc3NpYmxlIHRvIGFkZCBhbGwgdGhpcyBjbGFyaWZpY2F0aW9uIGludG8gdGhlIGRyYWZ0 ID8NCj4+PiBJdCB3aWxsIHJlbW92ZSB0aGUgYW1iaWd1aXR5Lg0KPj4+DQo+Pj4NCj4+PiBNYW55 IFRoYW5rcw0KPj4+IENocmlzdGlhbg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiBPbiAx Ny8wNS8yMDE2LCAyMjoxMiwgInNmYyBvbiBiZWhhbGYgb2YgSm9lbCBNLiBIYWxwZXJuIg0KPj4+ IDxzZmMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygam1oQGpvZWxoYWxwZXJuLmNvbT4g d3JvdGU6DQo+Pj4NCj4+Pj4gTmVpdGhlciBOU0ggbm9yIFNGQyBBcmNoaXRlY3R1cmUgd291bGQg Zm9yY2UgdGhlIHNhbWUgVk5JIHRvIGJlIHVzZWQgaW4NCj4+Pj4gZWFjaCBkaXJlY3Rpb24gZm9y IHRoZSBwYWlyZWQgU0ZQcy4gIEkgd291bGQgbm90IGFzc3VtZSB0aGF0IGluIG15IFNGRg0KPj4+ PiBkZXNpZ24uDQo+Pj4+IEh3b2UzdmVyLCBpdCB3b3VsZCBzZWVtIGEgdmVyeSBnb29kIHByYWN0 aWNlLCBhbmQgc29tZXRoaW5nIEkgd291bGQNCj4+Pj4gZXhwZWN0IGNvbnRyb2wgdG8gZG8uDQo+ Pj4+DQo+Pj4+IFRoaXMgZG9lcyBnZXQgYmFjayB0byB5b3VyIGVhcmxpZXIsIHdlbGx0YWtlbiwg cXVlc3Rpb24gYWJvdXQgd2hlcmUgdGVoDQo+Pj4+IFNGRiBnZXRzIHRoZSBWTkkgdG8gcHV0IGlu dG8gdGhlIFZ4TEFOIGhlYWRlci4gIE9uZSBhcHByb2FjaCBpcyB0bw0KPj4+PiBkZWNsYXJlIHRo YXQgYWxsIG9mIHNlcnZpY2UgY2hhaW5pbmcgaXMgYSBzaW5nbGUgVk5JLCBhbmQgc28gaXQgaXMg YW4NCj4+Pj4gU0ZGLXdpZGUgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXIuICBBbm90aGVyIGFwcHJv YWNoIGlzIHRoYXQgc3BlY2lmaWMNCj4+Pj4gcG9ydGlvbnMgdXNlIHNwZWNpZmljIFZOSSwgd2hp Y2ggd291bGQgbGVhZCB0byB3YW50aW5nIHRoZSBWTkkNCj4+Pj4gY29uZmlndXJlZCBpbiB0aGUg U1BJIG1hcHBpbmcgdGFibGUuICBJdCBzZWVtcyB0byBkZXBlbmQgdXBvbiB3aGVyZSB0aGUNCj4+ Pj4gVlRFUCBpcyB1bmRlcnN0b29kIHRvIGJlLiAgSSB0aGluayB3ZSBuZWVkIHRvIGFsbG93IGJv dGggY2FzZXMuDQo+Pj4+DQo+Pj4+IEl0IHNob3VsZCBiZSByZW1lbWJlcmVkIHRoYXQgdGhlIHRh YmxlIGVudHJpZXMgaW4gdGhlIE5TSCBkcmFmdCBhcmUNCj4+Pj4gZXhlbXBsYXJzLCBub3Qgc3Bl Y2lmaWNhdGlvbi4gIFRoZSBOU0ggZHJhZnQgZG9lcyBub3Qgc3RhbmRhcmRpemUgdGhlDQo+Pj4+ IHRyYW5zcG9ydCBtYXBwaW5ncy4gIChBbmQgdGhlIFdHIGNoYXJ0ZXIgbWFrZXMgYXBwZWFycyB0 byBtYWtlIGl0IG91dCBvZg0KPj4+PiBzY29wZSBmb3IgdGhlIFdHLikgIFNvIEkgYW0gbm90IHN1 cmUgd2hlcmUgdGhlIHF1ZXN0aW9uIG9mIGludGVyb3BlcmFibGUNCj4+Pj4gVk5JIHVzZSBmb3Ig VnhMQU4gdHJhbnNwb3J0IGNhbiBiZSBhbnN3ZXJlZC4gIChBbmQgVkxBTiB1c2UgZm9yIEV0aGVy bmV0DQo+Pj4+IFRyYW5zcG9ydC4pDQo+Pj4+DQo+Pj4+IFlvdXJzLA0KPj4+PiBKb2VsDQo+Pj4+ DQo+Pj4+IE9uIDUvMTcvMTYgNTowMiBQTSwgQ2hyaXN0aWFuIEtvZW5uaW5nIHdyb3RlOg0KPj4+ Pj4gVGhhbmtzIGZvciB0aGUgcXVpY2sgcmVwbHkuDQo+Pj4+Pg0KPj4+Pj4gU3BlY2lmaWNhbGx5 IGZvciBWWExBTi1HUEUsIHdpbGwgdGhlIGNvLXJlbGF0aW5nIFNQSSBiZSB1c2luZyB0aGUNCj4+ Pj4+IHNhbWUgVlhMQU4gU2VnbWVudCBJRC9WWExBTiBOZXR3b3JrIElkZW50aWZpZXIgKFZOSSk/ DQo+Pj4+Pg0KPj4+Pj4gU29ycnkgZm9yIHRoZSBicm9hZCBxdWVzdGlvbiwgaSByZWFsaXNlIHRo YXQgaSByYXRoZXIgc2hvdWxkIGdvIGludG8NCj4+Pj4+IHRoZSBkZXRhaWwgZGlyZWN0bHkuDQo+ Pj4+Pg0KPj4+Pj4NCj4+Pj4+IE1hbnkgVGhhbmtzLA0KPj4+Pj4NCj4+Pj4+IENocmlzdGlhbg0K Pj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+PiBPbiAxNyBNYXkgMjAxNiwgYXQgMjE6 NTEsIEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbT4NCj4+Pj4+PiB3cm90ZToN Cj4+Pj4+Pg0KPj4+Pj4+IEkgZG8gbm90IHRoaW5rIHRoYXQgdGhlIFNGQyBhcmNodGllY3R1cmUg b3IgdGhlIE5TSCBtZWNoYW5pc21zDQo+Pj4+Pj4gc3BlY2lmeSBhbnl0aGluZyBhYm91dCB0aGUg aW50ZXItU0ZGIHBhdGhzIHVzZWQgaW4gdGhlIHR3bw0KPj4+Pj4+IGRpZmZlcmVudCBkaXJlY3Rp b25zIGZvciBhIHBhaXIgb2Ygc3ltbWV0cmljYWxseSBjb3JyZWxhdGVkIFNlcnZpY2UNCj4+Pj4+ PiBGdW5jdGlvbiBQYXRocy4NCj4+Pj4+Pg0KPj4+Pj4+IFRoYXQgc2FpZCwgZ2l2ZW4gdGhhdCB0 aGUgdHJhbnNwb3J0cyBhcmUgcnVubmluZyBiZXR3ZWVuIHRoZSBzYW1lDQo+Pj4+Pj4gdHdvIGVu ZC1wb2ludHMsIEkgd291bGQgZXhwZWN0IHRoYXQgb3BlcmF0aW9uYWwgcHJhY3RpY2VzIHdpbGwN Cj4+Pj4+PiByZXN1bHQgaW4gdGhlbSB1c2luZyB0aGUgc2FtZSBraW5kIG9mIHRyYW5zcG9ydC4N Cj4+Pj4+Pg0KPj4+Pj4+IEZvciBtb3N0IG9mIHRoZSB0cmFuc3BvcnRzIHdlIGFyZSBsb29raW5n IGF0LCBpdCBpcyBub3QgY2xlYXIgd2hhdA0KPj4+Pj4+IGl0IG1lYW5zIHRvIGFzayBpZiB0aGV5 IGFyZSB1c2luZyB0aGUgc2FtZSB0dW5uZWwuICBGb3IgZXhhbXBsZSwgaWYNCj4+Pj4+PiB0aGUg dHJhbnNwb3J0IGlzIG5hdGl2ZSBFdGhlcm5ldCwgdGhlbiBvbmUgZGlyZWN0aW9uIHVzZXMgYQ0K Pj4+Pj4+IHBhcnRpY3VsYXIgc3JjL2Rlc3QgRXRoZXJuZXQgYWRkcmVzcyBwYXJpLCBhbmQgdGhl IG90aGVyIGRpcmVjdGlvbg0KPj4+Pj4+IHdpbGwgdHlwaWNhbGx5IChidXQgbm90IGFsd2F5cykg dXNlIHRoZSBzYW1lIGFkZHJlc3NlcyBpbiB0aGUgb3RoZXINCj4+Pj4+PiBvcmRlci4gIElmIHdl IGFyZSB1c2luZyBWeExBTiwgaW4gZWFjaCBkaXJlY3Rpb24gdGhlIHNvdXJjZSBVRFANCj4+Pj4+ PiBwb3J0IHdpbGwgYmUgcmFuZG9tLCBhcyB0aGF0IGlzIHRoZSB3YXkgVnhMQU4gd29ya3MuICBJ ZiB3ZSBhcmUNCj4+Pj4+PiB1c2luZyBMSVNQLCB0aGUgdHVubmVscyBhcmUgY29uc2lkZXJlZCB0 byBiZSB1bmlkaXJlY3Rpb25hbC4NCj4+Pj4+Pg0KPj4+Pj4+IFlvdXJzLCBKb2VsDQo+Pj4+Pj4N Cj4+Pj4+Pj4gT24gNS8xNy8xNiA0OjQ1IFBNLCBDaHJpc3RpYW4gS29lbm5pbmcgd3JvdGU6DQo+ Pj4+Pj4+DQo+Pj4+Pj4+IFRoYW5rcyBKb2VsLA0KPj4+Pj4+Pg0KPj4+Pj4+PiB0aGFua3MgZm9y IGNvbmZpcm1pbmcgZmxvdyBjb3JyZWxhdGlvbiAoTDQpIGlzIGV4cGVjdGVkIGFzIHVzdWFsLA0K Pj4+Pj4+PiBldmVuIHdpdGggaW5ncmVzcyBhbmQgZWdyZXNzIG9uIHR3byBkaWZmZXJlbnQgU2Vy dmljZSBQYXRoIElEcy4NCj4+Pj4+Pj4gVGhlIHF1ZXN0aW9uIG9mIG92ZXJsb2FkaW5nIGFkZHJl c3Mgc3BhY2UgdHJpZWQgdG8gY2xhcmlmeSB0aGUNCj4+Pj4+Pj4gKHJhcmUpIHRoZSBzaXR1YXRp b24gd2hlcmUgMiBlbmRwb2ludCBwYWlycyBoYXZlIHRoZSBzYW1lDQo+Pj4+Pj4+IGFkZHJlc3Nl cyBhbmQgaGF2ZSBhZ3JlZWQgb24gdGhlIHNhbWUgc3JjL2RzdCBwb3J0L3Byb3RvY29sLA0KPj4+ Pj4+PiB3aGljaCBsZWFkcyB0byBmbG93IGNvbGxpc2lvbnMuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFlv dSBtZW50aW9uIHRoYXQgU2VydmljZSBQYXRoIElEIHdpbGwgbm93IGFsbG93IHRvIHJldXNlLQ0K Pj4+Pj4+PiAvZHVwbGljYXRpb24uDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEhvd2V2ZXIsIHlvdSBtZW50 aW9uZWQgdGhhdCBtZXRhZGF0YSB3aWxsIHByb3ZpZGUgYWRkcmVzcyByZXVzZS0NCj4+Pj4+Pj4g LyBkdXBsaWNhdGlvbi4gVGhlcmVmb3JlIHRoZSBmbG93IGNvcnJlbGF0aW9uIHdvdWxkIG5lZWQg dG8NCj4+Pj4+Pj4gaGFwcGVuIG9uIGluY2x1ZGluZyB0aGUgbWV0YWRhdGEgYXMgcGFydCBvZiB0 aGUgdHVwbGUgYXMgd2VsbC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gQWxzbywgYWxsb3cgbWUgdG8gYXNr IGlmIHdlIGV4cGVjdCBpbmdyZXNzIGFuZCBlZ3Jlc3MgU2VydmljZQ0KPj4+Pj4+PiBQYXRoIElE cyBvbiB0aGUgc2FtZSB0cmFuc3BvcnQvdHVubmVsID8NCj4+Pj4+Pj4NCj4+Pj4+Pj4gTWFueSBU aGFua3MNCj4+Pj4+Pj4NCj4+Pj4+Pj4gQ2hyaXN0aWFuIEtvZW5uaW5nIC0tIEY1IE5ldHdvcmtz IEluYy4gY2hyaXN0aWFuQGY1LmNvbQ0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+ Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4gT24gMTcvMDUvMjAxNiwgMjE6MDcsICJKb2Vs IE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPg0KPj4+Pj4+Pj4gd3JvdGU6DQo+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4gQ29ycmVsYXRpb24gb2YgcGFja2V0cyBpbiB0d28gZGlyZWN0aW9ucyBm b3IgYW4gU0Ygd2hpY2ggd29ya3MNCj4+Pj4+Pj4+IHNlZW1zIHRvIHJlcXVpcmUgdGhhdCB0aGUg U0Yga25vdyBob3cgdG8gY29ycmVsYXRlIHBhY2tldHMuICBJZA0KPj4+Pj4+Pj4gZG9lcyBub3Qg bmVlZCB0byBsb29rIGF0IHRoZSBTUEkgZm9yIHRoYXQsIHNpbmNlIFNQSSBhcmUNCj4+Pj4+Pj4+ IGNvYXJzZXIgdGhhbiBmbG93LiAgSXQgbWF5IG5lZWQgdG8gbG9vayBhdCBtZXRhZGF0YSAoc3Vj aCBhcw0KPj4+Pj4+Pj4gc3Vic2NyaWJlciBpZGVudGl0eSkgaWYgdGhlIFNGIGlzIGluc2lkZSBh IGRvbWFpbiB3aGVyZSBJUA0KPj4+Pj4+Pj4gYWRkcmVzc2VzIGFyZSByZXVzZWQgKE5BVCBiZWlu ZyBhIHNlcnZpY2UgZnVuY3Rpb24gaXRzZWxmLCBzbw0KPj4+Pj4+Pj4gb25lIGNvdWxkIGJlIG9u IHRoZSByZXVzZSBzaWRlIG9mIGEgTkFULikNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBJIGFtIG5vdCBz dXJlIHdoYXQgeW91IGFyZSByZWZlcnJpbmcgdG8gYnkgYWRkcmVzcyBuYW1lc3BhY2VzLg0KPj4+ Pj4+Pj4gU1BJcyBkbyBub3Qgc2VncmVnYXRlIHN1YnNjcmliZXJzLCBub3IgYXJlIHRoZXkgcXVh bGlmaWVycyBmb3INCj4+Pj4+Pj4+IGRpc2FtYmlndWF0aW5nIGFkZHJlc3NlcyB3aGVyZSBOQVQg aXMgaW4gdXNlLiAgTWV0YWRhdGEgaW4gdGhlDQo+Pj4+Pj4+PiBwYWNrZXQgaXMgdXNlZCBmb3Ig c3VjaCBkaXNhbWJpZ3VhdGlvbi4gIFNvLCBpbiB0aGUgcHJlc2VuY2Ugb2YNCj4+Pj4+Pj4+IHN1 aXRhYmxlIG1ldGFkYXRhLCBTRkMgYW5kIE5TSCBzdXBwb3J0IGlubmVyIChzdWJzY3JpYmVyKQ0K Pj4+Pj4+Pj4gYWRkcmVzcyByZXVzZSAvIGR1cGxpY2F0aW9uLiAgTkFUIGlzIGFuIGVudmlzaW9u ZWQgc2VydmljZQ0KPj4+Pj4+Pj4gZnVuY3Rpb24uICBKdXN0IGRvbid0IHRyeSB0byB1c2UgdGhl IFNQSSBhcyB0aGUga2V5LiBJdCB3b24ndA0KPj4+Pj4+Pj4gdGVsbCB5b3Ugd2hhdCB5b3UgbmVl ZC4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBZb3VycywgSm9lbA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBP biA1LzE3LzE2IDQ6MDIgUE0sIENocmlzdGlhbiBLb2VubmluZyB3cm90ZTogVGhhbmtzIEpvZWws DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiB0aGF0IGlzIHdoZXJlIEkgd2FzIGdldHRpbmcgY29uZnVz ZWQuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBXaGVuIGxvb2tpbmcgZS5nLiBhdCBhIHN0YXRlZnVs IFNlcnZpY2UgRnVuY3Rpb24gKFNGKSwgdGhlcmUNCj4+Pj4+Pj4+PiBuZWVkcyB0byBiZSBhbiBp bnN0cnVjdGlvbiB3aGljaCB0d28gb2YgdGhlIFNlcnZpY2UgUGF0aA0KPj4+Pj4+Pj4+IElkZW50 aWZpZXJzIGNvLXJlbGVhdGUgaW4gb3JkZXIgdG8gZXN0YWJsaXNoIHN0YXRlLg0KPj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBGdXJ0aGVyIHRvIHRoYXQsIGNvdWxkIHlvdSBkZWZpbmUg aWYgU2VydmljZSBQYXRoIElkZW50aWZpZXJzDQo+Pj4+Pj4+Pj4gYWxsb3dzIGZvciBvdmVybG9h ZGluZyBvZiBhZGRyZXNzIG5hbWVzcGFjZT8NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFBsZWFzZSBh bGxvdyB1cyB0byBjbGFyaWZ5IHRoaXMuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBNYW55IFRoYW5r cw0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gQ2hyaXN0aWFuIEtvZW5uaW5nIC0tIEY1IE5ldHdvcmtz IEluYy4gY2hyaXN0aWFuQGY1LmNvbQ0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBPbiAxNy8wNS8yMDE2 LCAyMDo1NywgIkpvZWwgTS4gSGFscGVybiINCj4+Pj4+Pj4+Pj4gPGptaEBqb2VsaGFscGVybi5j b20+IHdyb3RlOg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBNb3N0IG9mIHVzIGhhdmUgYXNzdW1l ZCB0aGF0IGEgYmktZGlyZWN0aW9uYWwgc3ltbWV0cmljDQo+Pj4+Pj4+Pj4+IHBhdGggcGFpciBp cyBzZXQgdXAgYnkgY29udHJvbCwgYW5kIGhhcyBzZXBhcmF0ZSBTZXJ2aWNlDQo+Pj4+Pj4+Pj4+ IFBhdGggSURzIChhbmQgaW5kaWNpZXMpIGluIGVhY2ggZGlyZWN0aW9uLiAgVGhpcyBkb2VzIGxl YWQNCj4+Pj4+Pj4+Pj4gdG8gYSBuZWVkIGZvciBzZXJ2aWNlIGZ1bmN0aW9ucyB3aGljaCBvcmln aW5hdGUgcmV2ZXJzZQ0KPj4+Pj4+Pj4+PiBkaXJlY3Rpb24gcGFja2V0cyB0byBoYXZlIGEgbWVh bnMgdG8gZ2V0IHRoZSBjb3JyZWN0IFNQSSAvDQo+Pj4+Pj4+Pj4+IEluZGV4IGluIHBsYWNlIGZv ciB0aG9zZSBwYWNrZXRzLiAgVGhlcmUgYXJlIGRyYWZ0cw0KPj4+Pj4+Pj4+PiBkaXNjdXNzaW5n IGFwcHJvYWNoZXMgdG8gdGhhdCBxdWVzdGlvbi4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gWW91 cnMsIEpvZWwNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IE9uIDUvMTcvMTYgMzo0OSBQTSwgQ2hy aXN0aWFuIEtvZW5uaW5nIHdyb3RlOiBHb29kDQo+Pj4+Pj4+Pj4+PiBFdmVuaW5nLA0KPj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IGxvb2tpbmcgYXQgUkZDIDc2NjUgU2VydmljZSBGdW5jdGlvbiBD aGFpbmluZyAoU0ZDKQ0KPj4+Pj4+Pj4+Pj4gQXJjaGl0ZWN0dXJlIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM3NjY1DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gdGhlcmUgaXMgYSBj bGVhciBkZWZpbml0aW9uIG9mIGNoYWluIHN5bWV0cnkNCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ PiAiIDIuMi4gIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW4gU3ltbWV0cnkNCj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+PiBTRkNzIG1heSBiZSB1bmlkaXJlY3Rpb25hbCBvciBiaWRpcmVjdGlvbmFsLiAg QQ0KPj4+Pj4+Pj4+Pj4gdW5pZGlyZWN0aW9uYWwgU0ZDIHJlcXVpcmVzIHRoYXQgdHJhZmZpYyBi ZSBmb3J3YXJkZWQNCj4+Pj4+Pj4+Pj4+IHRocm91Z2ggdGhlIG9yZGVyZWQgU0ZzIGluIG9uZSBk aXJlY3Rpb24gKHNmMSAtPiBzZjIgLT4NCj4+Pj4+Pj4+Pj4+IHNmMyksIHdoZXJlYXMgYSBiaWRp cmVjdGlvbmFsIFNGQyByZXF1aXJlcyBhIHN5bW1ldHJpYw0KPj4+Pj4+Pj4+Pj4gcGF0aCAoc2Yx IC0+IHNmMiAtPiBzZjMgYW5kIHNmMyAtPiBzZjIgLT4gc2YxKSwgYW5kIGluDQo+Pj4+Pj4+Pj4+ PiB3aGljaCB0aGUgU0YgaW5zdGFuY2VzIGFyZSB0aGUgc2FtZSBpbiBvcHBvc2l0ZQ0KPj4+Pj4+ Pj4+Pj4gZGlyZWN0aW9ucy4gIEEgaHlicmlkIFNGQyBoYXMgYXR0cmlidXRlcyBvZiBib3RoDQo+ Pj4+Pj4+Pj4+PiB1bmlkaXJlY3Rpb25hbCBhbmQgYmlkaXJlY3Rpb25hbCBTRkNzOyB0aGF0IGlz IHRvIHNheQ0KPj4+Pj4+Pj4+Pj4gc29tZSBTRnMgcmVxdWlyZSBzeW1tZXRyaWMgdHJhZmZpYywg d2hlcmVhcyBvdGhlciBTRnMgZG8NCj4+Pj4+Pj4+Pj4+IG5vdCBwcm9jZXNzIHJldmVyc2UgdHJh ZmZpYyBvciBhcmUgaW5kZXBlbmRlbnQgb2YgdGhlDQo+Pj4+Pj4+Pj4+PiBjb3JyZXNwb25kaW5n IGZvcndhcmQgdHJhZmZpYy4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiAuLi4NCj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+PiBGdXJ0aGVyLCB0aGVyZSBhcmUgc3RhdGUgdHJhZGUtb2ZmcyBpbiBz eW1tZXRyeS4NCj4+Pj4+Pj4+Pj4+IFN5bW1ldHJ5IG1heSBiZSByZWFsaXplZCBpbiBzZXZlcmFs IHdheXMgZGVwZW5kaW5nIG9uIHRoZQ0KPj4+Pj4+Pj4+Pj4gU0ZGIGFuZCBjbGFzc2lmaWVyIGZ1 bmN0aW9uYWxpdHkuICBJbiBzb21lIGNhc2VzLA0KPj4+Pj4+Pj4+Pj4gIm1pcnJvcmVkIiBjbGFz c2lmaWNhdGlvbiAoaS5lLiwgZnJvbSBTb3VyY2UgdG8NCj4+Pj4+Pj4+Pj4+IERlc3RpbmF0aW9u IGFuZCBmcm9tIERlc3RpbmF0aW9uIHRvIFNvdXJjZSkgcG9saWN5IG1heQ0KPj4+Pj4+Pj4+Pj4g YmUgZGVwbG95ZWQsIHdoZXJlYXMgaW4gb3RoZXJzIHNoYXJlZCBzdGF0ZSBiZXR3ZWVuDQo+Pj4+ Pj4+Pj4+PiBjbGFzc2lmaWVycyBtYXkgYmUgdXNlZCB0byBlbnN1cmUgdGhhdCBzeW1tZXRyaWMg Zmxvd3MNCj4+Pj4+Pj4+Pj4+IGFyZSBjb3JyZWN0bHkgaWRlbnRpZmllZCwgdGhlbiBzdGVlcmVk IGFsb25nIHRoZSByZXF1aXJlZA0KPj4+Pj4+Pj4+Pj4gU0ZQLiAgQXQgYSBoaWdoIGxldmVsLCB0 aGVyZSBhcmUgdmFyaW91cyBjb21tb24gY2FzZXMuDQo+Pj4+Pj4+Pj4+PiBJbiBhIG5vbi1leGhh dXN0aXZlIHdheSwgdGhlcmUgY2FuIGJlIGZvciBleGFtcGxlOg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+IG8gIEEgc2luZ2xlIGNsYXNzaWZpZXIgKG9yIGEgc21hbGwgbnVtYmVyIG9mDQo+Pj4+ Pj4+Pj4+PiBjbGFzc2lmaWVycyksIGluIHdoaWNoIGNhc2UgYm90aCBpbmNvbWluZyBhbmQgb3V0 Z29pbmcNCj4+Pj4+Pj4+Pj4+IGZsb3dzIGNvdWxkIGJlIHJlY29nbml6ZWQgYXQgdGhlIHNhbWUg Y2xhc3NpZmllciwgc28gdGhlDQo+Pj4+Pj4+Pj4+PiBzeW5jaHJvbml6YXRpb24gd291bGQgYmUg ZmVhc2libGUgYnkgaW50ZXJuYWwgbWVjaGFuaXNtcw0KPj4+Pj4+Pj4+Pj4gaW50ZXJuYWwgdG8g dGhlIGNsYXNzaWZpZXIuDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gbyAgU3RhdGVmdWwgY2xh c3NpZmllcnMgd2hlcmUgc2V2ZXJhbCBjbGFzc2lmaWVycyBtYXkgYmUNCj4+Pj4+Pj4+Pj4+IGNs dXN0ZXJlZCBhbmQgc2hhcmUgc3RhdGUuDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gbyAgRnVs bHkgZGlzdHJpYnV0ZWQgY2xhc3NpZmllcnMsIHdoZXJlIHN5bmNocm9uaXphdGlvbg0KPj4+Pj4+ Pj4+Pj4gbmVlZHMgdG8gYmUgcHJvdmlkZWQgdGhyb3VnaCB1bnNwZWNpZmllZCBtZWFucy4NCj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBvICBBIGNsYXNzaWZpZXIgdGhhdCBsZWFybnMgc3RhdGUg ZnJvbSB0aGUgZWdyZXNzDQo+Pj4+Pj4+Pj4+PiBwYWNrZXRzL2Zsb3dzIHRoYXQgaXMgdGhlbiB1 c2VkIHRvIHByb3ZpZGUgc3RhdGUgZm9yIHRoZQ0KPj4+Pj4+Pj4+Pj4gcmV0dXJuIHBhY2tldHMv Zmxvdy4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBvICBTeW1tZXRyeSBtYXkgYWxzbyBiZSBw cm92aWRlZCBieSBzdGF0ZWZ1bCBmb3J3YXJkaW5nDQo+Pj4+Pj4+Pj4+PiBsb2dpYyBpbiB0aGUg U0ZGIGluIHNvbWUgaW1wbGVtZW50YXRpb25zLg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IFRo aXMgaXMgYSBub24tY29tcHJlaGVuc2l2ZSBsaXN0IG9mIGNvbW1vbiBjYXNlcy4gIg0KPj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBIb3dldmVyLCB3aGVuIGxvb2tpbmcgYXQg dGhpcyB0b2dldGhlciB3aXRoIE5ldHdvcmsNCj4+Pj4+Pj4+Pj4+IFNlcnZpY2UgSGVhZGVyIGRy YWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQNCj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXNmYy1uc2gtMDQNCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiAz LjMuICBTZXJ2aWNlIFBhdGggSGVhZGVyDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gIiBTZXJ2 aWNlIFBhdGggSWRlbnRpZmllciAoU1BJKTogaWRlbnRpZmllcyBhIHNlcnZpY2UNCj4+Pj4+Pj4+ Pj4+IHBhdGguIFBhcnRpY2lwYXRpbmcgbm9kZXMgTVVTVCB1c2UgdGhpcyBpZGVudGlmaWVyIGZv cg0KPj4+Pj4+Pj4+Pj4gU2VydmljZSBGdW5jdGlvbiBQYXRoIHNlbGVjdGlvbi4gIg0KPj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IHRoZXJlIGlzIG5vIG5vdGlvbiBvZiBzeW1tZXRyeS4NCj4+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gQ2FuIHlvdSBwbGVhc2UgY29uZmlybSB0 aGF0IGEgYmlkaXJlY3Rpb25hbCBTZXJ2aWNlDQo+Pj4+Pj4+Pj4+PiBGdW5jdGlvbiBDaGFpbiB3 aWxsIGJlIHJlcHJlc2VudGVkIGJ5IG9uZSBzaW5nbGUgU2VydmljZQ0KPj4+Pj4+Pj4+Pj4gUGF0 aCBJZGVudGlmaWVyLCBpbmdyZXNzIHN5bW1ldHJpYyB0byBlZ3Jlc3MgPw0KPj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBQbGVhc2UgYWxsb3cgdXMgdG8gY2xhcmlmeSB0aGlz Lg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IE1hbnkgVGhhbmtzDQo+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4gQ2hyaXN0aWFuIEtvZW5uaW5nIC0tIEY1IE5ldHdvcmtzIEluYy4gY2hyaXN0aWFu QGY1LmNvbQ0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjDQo+ Pj4+Pj4+Pj4+PiBtYWlsaW5nIGxpc3Qgc2ZjQGlldGYub3JnDQo+Pj4+Pj4+Pj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+DQo+ Pj4+DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4gc2ZjQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pg0KPj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+ IHNmY0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z ZmMNCj4+DQo= From nobody Wed May 18 15:28:04 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4090D12D119 for ; Wed, 18 May 2016 15:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 FKqZG7lKn2HW for ; Wed, 18 May 2016 15:28:01 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF74712D599 for ; Wed, 18 May 2016 15:28:00 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-3.sandvine.com (192.168.196.177) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 18 May 2016 18:27:59 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Wed, 18 May 2016 18:27:59 -0400 From: Dave Dolson To: Christian Koenning , "Joel M. Halpern" Thread-Topic: [sfc] Service Path Identifier (SPI) and symmetry Thread-Index: AQHRsHUtFvsY0ydaV0iEs6canF5mkp+9ztmAgAABd4CAAAEwAIAACsQAgAABjACAAAM3gIAAArIAgAAVZQCAAAn5AIAAAeaAgAGDqwD//799OA== Date: Wed, 18 May 2016 22:27:58 +0000 Message-ID: <20160518222757.5697621.218.85137@sandvine.com> References: <708683c2-8c57-41e1-0dc9-153fd09ecdcd@joelhalpern.com> <4ffc7b1e-b9cd-ea61-58b1-55e93e373768@joelhalpern.com> <00D7FD5C-2F8A-4D21-AC12-C560E106704D@F5.com> <6737272c-dbbc-f985-1c9a-7dd93b99659a@joelhalpern.com> <604cceed-4030-79e7-01f9-29a335058bc0@joelhalpern.com> , <3AA4099A-196D-4B9F-9B22-065BB519AAA7@f5.com> In-Reply-To: <3AA4099A-196D-4B9F-9B22-065BB519AAA7@f5.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Service Path Identifier (SPI) and symmetry X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 22:28:03 -0000 Christian, These type of questions are contemplated in draft-penno-sfc-packet Please give your feedback on which solutions work or don't work for you. -Dave Original Message From: Christian Koenning Sent: Wednesday, May 18, 2016 6:19 PM To: Joel M. Halpern Cc: sfc@ietf.org Subject: Re: [sfc] Service Path Identifier (SPI) and symmetry Thanks Joel! Allow me to elaborate on the confusion further. >On 17/05/2016, 21:07, "Joel M. Halpern" >wrote: >Correlation of packets in two directions for an SF which works >seems to require that the SF know how to correlate packets. Id >does not need to look at the SPI for that, since SPI are >coarser than flow. It may need to look at metadata (such as >subscriber identity) if the SF is inside a domain where IP >addresses are reused (NAT being a service function itself, so >one could be on the reuse side of a NAT.) >On 5/17/16 4:02 PM, Christian Koenning wrote: Thanks Joel, >that is where I was getting confused. >When looking e.g. at a stateful Service Function (SF), there >needs to be an instruction which two of the Service Path >Identifiers co-releate in order to establish state. Taking the case of the Service Function (SF) e.g. terminating the connection, or allowing for late binding, the SF would need to sent the TCP SYN/ACK segment back. If there is no a-prio knowledge of the return SPI', then what SPI' would the SF choose ? Many Thanks Christian Koenning -- F5 Networks Inc. christian@f5.com On 18/05/2016, 00:11, "Joel M. Halpern" wrote: >I realized reading my reply that I left out something important. >The fact that you found this confusing is a good indication that we >should try to improve the text. > >Yours, >Joel > >On 5/17/16 7:04 PM, Joel M. Halpern wrote: >> I am not sure which aspects can reasonably go in the NSH draft. For >> example, although the VxLAN example can be enhanced, it is still an >> example, not anything normative. >> >> Basically, additions are up to the WG. Within the scope of the document >> and WG charter. >> >> Yours, >> Joel >> >> On 5/17/16 6:28 PM, Christian Koenning wrote: >>> Thanks Joel, >>> >>> Would it be possible to add all this clarification into the draft ? >>> It will remove the ambiguity. >>> >>> >>> Many Thanks >>> Christian >>> >>> >>> >>> >>> >>> On 17/05/2016, 22:12, "sfc on behalf of Joel M. Halpern" >>> wrote: >>> >>>> Neither NSH nor SFC Architecture would force the same VNI to be used i= n >>>> each direction for the paired SFPs. I would not assume that in my SFF >>>> design. >>>> Hwoe3ver, it would seem a very good practice, and something I would >>>> expect control to do. >>>> >>>> This does get back to your earlier, welltaken, question about where te= h >>>> SFF gets the VNI to put into the VxLAN header. One approach is to >>>> declare that all of service chaining is a single VNI, and so it is an >>>> SFF-wide configuration parameter. Another approach is that specific >>>> portions use specific VNI, which would lead to wanting the VNI >>>> configured in the SPI mapping table. It seems to depend upon where th= e >>>> VTEP is understood to be. I think we need to allow both cases. >>>> >>>> It should be remembered that the table entries in the NSH draft are >>>> exemplars, not specification. The NSH draft does not standardize the >>>> transport mappings. (And the WG charter makes appears to make it out = of >>>> scope for the WG.) So I am not sure where the question of interoperab= le >>>> VNI use for VxLAN transport can be answered. (And VLAN use for Ethern= et >>>> Transport.) >>>> >>>> Yours, >>>> Joel >>>> >>>> On 5/17/16 5:02 PM, Christian Koenning wrote: >>>>> Thanks for the quick reply. >>>>> >>>>> Specifically for VXLAN-GPE, will the co-relating SPI be using the >>>>> same VXLAN Segment ID/VXLAN Network Identifier (VNI)? >>>>> >>>>> Sorry for the broad question, i realise that i rather should go into >>>>> the detail directly. >>>>> >>>>> >>>>> Many Thanks, >>>>> >>>>> Christian >>>>> >>>>> >>>>> >>>>> >>>>>> On 17 May 2016, at 21:51, Joel M. Halpern >>>>>> wrote: >>>>>> >>>>>> I do not think that the SFC archtiecture or the NSH mechanisms >>>>>> specify anything about the inter-SFF paths used in the two >>>>>> different directions for a pair of symmetrically correlated Service >>>>>> Function Paths. >>>>>> >>>>>> That said, given that the transports are running between the same >>>>>> two end-points, I would expect that operational practices will >>>>>> result in them using the same kind of transport. >>>>>> >>>>>> For most of the transports we are looking at, it is not clear what >>>>>> it means to ask if they are using the same tunnel. For example, if >>>>>> the transport is native Ethernet, then one direction uses a >>>>>> particular src/dest Ethernet address pari, and the other direction >>>>>> will typically (but not always) use the same addresses in the other >>>>>> order. If we are using VxLAN, in each direction the source UDP >>>>>> port will be random, as that is the way VxLAN works. If we are >>>>>> using LISP, the tunnels are considered to be unidirectional. >>>>>> >>>>>> Yours, Joel >>>>>> >>>>>>> On 5/17/16 4:45 PM, Christian Koenning wrote: >>>>>>> >>>>>>> Thanks Joel, >>>>>>> >>>>>>> thanks for confirming flow correlation (L4) is expected as usual, >>>>>>> even with ingress and egress on two different Service Path IDs. >>>>>>> The question of overloading address space tried to clarify the >>>>>>> (rare) the situation where 2 endpoint pairs have the same >>>>>>> addresses and have agreed on the same src/dst port/protocol, >>>>>>> which leads to flow collisions. >>>>>>> >>>>>>> You mention that Service Path ID will now allow to reuse- >>>>>>> /duplication. >>>>>>> >>>>>>> However, you mentioned that metadata will provide address reuse- >>>>>>> / duplication. Therefore the flow correlation would need to >>>>>>> happen on including the metadata as part of the tuple as well. >>>>>>> >>>>>>> Also, allow me to ask if we expect ingress and egress Service >>>>>>> Path IDs on the same transport/tunnel ? >>>>>>> >>>>>>> Many Thanks >>>>>>> >>>>>>> Christian Koenning -- F5 Networks Inc. christian@f5.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 17/05/2016, 21:07, "Joel M. Halpern" >>>>>>>> wrote: >>>>>>>> >>>>>>>> Correlation of packets in two directions for an SF which works >>>>>>>> seems to require that the SF know how to correlate packets. Id >>>>>>>> does not need to look at the SPI for that, since SPI are >>>>>>>> coarser than flow. It may need to look at metadata (such as >>>>>>>> subscriber identity) if the SF is inside a domain where IP >>>>>>>> addresses are reused (NAT being a service function itself, so >>>>>>>> one could be on the reuse side of a NAT.) >>>>>>>> >>>>>>>> I am not sure what you are referring to by address namespaces. >>>>>>>> SPIs do not segregate subscribers, nor are they qualifiers for >>>>>>>> disambiguating addresses where NAT is in use. Metadata in the >>>>>>>> packet is used for such disambiguation. So, in the presence of >>>>>>>> suitable metadata, SFC and NSH support inner (subscriber) >>>>>>>> address reuse / duplication. NAT is an envisioned service >>>>>>>> function. Just don't try to use the SPI as the key. It won't >>>>>>>> tell you what you need. >>>>>>>> >>>>>>>> Yours, Joel >>>>>>>> >>>>>>>>> On 5/17/16 4:02 PM, Christian Koenning wrote: Thanks Joel, >>>>>>>>> >>>>>>>>> that is where I was getting confused. >>>>>>>>> >>>>>>>>> When looking e.g. at a stateful Service Function (SF), there >>>>>>>>> needs to be an instruction which two of the Service Path >>>>>>>>> Identifiers co-releate in order to establish state. >>>>>>>>> >>>>>>>>> >>>>>>>>> Further to that, could you define if Service Path Identifiers >>>>>>>>> allows for overloading of address namespace? >>>>>>>>> >>>>>>>>> Please allow us to clarify this. >>>>>>>>> >>>>>>>>> Many Thanks >>>>>>>>> >>>>>>>>> Christian Koenning -- F5 Networks Inc. christian@f5.com >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 17/05/2016, 20:57, "Joel M. Halpern" >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Most of us have assumed that a bi-directional symmetric >>>>>>>>>> path pair is set up by control, and has separate Service >>>>>>>>>> Path IDs (and indicies) in each direction. This does lead >>>>>>>>>> to a need for service functions which originate reverse >>>>>>>>>> direction packets to have a means to get the correct SPI / >>>>>>>>>> Index in place for those packets. There are drafts >>>>>>>>>> discussing approaches to that question. >>>>>>>>>> >>>>>>>>>> Yours, Joel >>>>>>>>>> >>>>>>>>>>> On 5/17/16 3:49 PM, Christian Koenning wrote: Good >>>>>>>>>>> Evening, >>>>>>>>>>> >>>>>>>>>>> looking at RFC 7665 Service Function Chaining (SFC) >>>>>>>>>>> Architecture https://tools.ietf.org/html/rfc7665 >>>>>>>>>>> >>>>>>>>>>> there is a clear definition of chain symetry >>>>>>>>>>> >>>>>>>>>>> " 2.2. Service Function Chain Symmetry >>>>>>>>>>> >>>>>>>>>>> SFCs may be unidirectional or bidirectional. A >>>>>>>>>>> unidirectional SFC requires that traffic be forwarded >>>>>>>>>>> through the ordered SFs in one direction (sf1 -> sf2 -> >>>>>>>>>>> sf3), whereas a bidirectional SFC requires a symmetric >>>>>>>>>>> path (sf1 -> sf2 -> sf3 and sf3 -> sf2 -> sf1), and in >>>>>>>>>>> which the SF instances are the same in opposite >>>>>>>>>>> directions. A hybrid SFC has attributes of both >>>>>>>>>>> unidirectional and bidirectional SFCs; that is to say >>>>>>>>>>> some SFs require symmetric traffic, whereas other SFs do >>>>>>>>>>> not process reverse traffic or are independent of the >>>>>>>>>>> corresponding forward traffic. >>>>>>>>>>> >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> Further, there are state trade-offs in symmetry. >>>>>>>>>>> Symmetry may be realized in several ways depending on the >>>>>>>>>>> SFF and classifier functionality. In some cases, >>>>>>>>>>> "mirrored" classification (i.e., from Source to >>>>>>>>>>> Destination and from Destination to Source) policy may >>>>>>>>>>> be deployed, whereas in others shared state between >>>>>>>>>>> classifiers may be used to ensure that symmetric flows >>>>>>>>>>> are correctly identified, then steered along the required >>>>>>>>>>> SFP. At a high level, there are various common cases. >>>>>>>>>>> In a non-exhaustive way, there can be for example: >>>>>>>>>>> >>>>>>>>>>> o A single classifier (or a small number of >>>>>>>>>>> classifiers), in which case both incoming and outgoing >>>>>>>>>>> flows could be recognized at the same classifier, so the >>>>>>>>>>> synchronization would be feasible by internal mechanisms >>>>>>>>>>> internal to the classifier. >>>>>>>>>>> >>>>>>>>>>> o Stateful classifiers where several classifiers may be >>>>>>>>>>> clustered and share state. >>>>>>>>>>> >>>>>>>>>>> o Fully distributed classifiers, where synchronization >>>>>>>>>>> needs to be provided through unspecified means. >>>>>>>>>>> >>>>>>>>>>> o A classifier that learns state from the egress >>>>>>>>>>> packets/flows that is then used to provide state for the >>>>>>>>>>> return packets/flow. >>>>>>>>>>> >>>>>>>>>>> o Symmetry may also be provided by stateful forwarding >>>>>>>>>>> logic in the SFF in some implementations. >>>>>>>>>>> >>>>>>>>>>> This is a non-comprehensive list of common cases. " >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> However, when looking at this together with Network >>>>>>>>>>> Service Header draft-ietf-sfc-nsh-04.txt >>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-sfc-nsh-04 >>>>>>>>>>> >>>>>>>>>>> 3.3. Service Path Header >>>>>>>>>>> >>>>>>>>>>> " Service Path Identifier (SPI): identifies a service >>>>>>>>>>> path. Participating nodes MUST use this identifier for >>>>>>>>>>> Service Function Path selection. " >>>>>>>>>>> >>>>>>>>>>> there is no notion of symmetry. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Can you please confirm that a bidirectional Service >>>>>>>>>>> Function Chain will be represented by one single Service >>>>>>>>>>> Path Identifier, ingress symmetric to egress ? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Please allow us to clarify this. >>>>>>>>>>> >>>>>>>>>>> Many Thanks >>>>>>>>>>> >>>>>>>>>>> Christian Koenning -- F5 Networks Inc. christian@f5.com >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ sfc >>>>>>>>>>> mailing list sfc@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Wed May 18 15:36:05 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8649912D680 for ; Wed, 18 May 2016 15:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 XFZ1EpT8fbCt for ; Wed, 18 May 2016 15:36:03 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 3D1BF12D1E7 for ; Wed, 18 May 2016 15:36:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 2EA6CE400E4; Wed, 18 May 2016 15:36:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1463610963; bh=Rr7qA2qc8lRt+0wE2oiRJ9sVWkhvy1uaEHWwcxCzMhc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=jXz0EiHHoPpSeShwAi37yseuBVw4mUSNipdwxIBhH5BDKW7LqBFy+yiyGsToSaUEk 7mp2+JyGacOthuPzW36Lg2UnCqYXFbKBLaIqhB+oaUbkGTKn93hYPbKQu8k+8AmAw+ VM9RvVpat0pAdyH8ho0PAtxKQCjSfrV8+PzlDRDs= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id E302AE400E0; Wed, 18 May 2016 15:36:01 -0700 (PDT) To: Christian Koenning References: <708683c2-8c57-41e1-0dc9-153fd09ecdcd@joelhalpern.com> <4ffc7b1e-b9cd-ea61-58b1-55e93e373768@joelhalpern.com> <00D7FD5C-2F8A-4D21-AC12-C560E106704D@F5.com> <6737272c-dbbc-f985-1c9a-7dd93b99659a@joelhalpern.com> <604cceed-4030-79e7-01f9-29a335058bc0@joelhalpern.com> <3AA4099A-196D-4B9F-9B22-065BB519AAA7@f5.com> From: Joel Halpern Direct Message-ID: Date: Wed, 18 May 2016 18:36:24 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <3AA4099A-196D-4B9F-9B22-065BB519AAA7@f5.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Service Path Identifier (SPI) and symmetry X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 22:36:04 -0000 Yep, that is indeed a challenge. There are a couple of approaches proposed. One draft: https://datatracker.ietf.org/doc/draft-penno-sfc-packet/ describes some of the issues and possible approaches. Yours, Joel On 5/18/16 6:18 PM, Christian Koenning wrote: > Thanks Joel! > > Allow me to elaborate on the confusion further. > > > >> On 17/05/2016, 21:07, "Joel M. Halpern" >> wrote: > >> Correlation of packets in two directions for an SF which works >> seems to require that the SF know how to correlate packets. Id >> does not need to look at the SPI for that, since SPI are >> coarser than flow. It may need to look at metadata (such as >> subscriber identity) if the SF is inside a domain where IP >> addresses are reused (NAT being a service function itself, so >> one could be on the reuse side of a NAT.) > >> On 5/17/16 4:02 PM, Christian Koenning wrote: Thanks Joel, > >> that is where I was getting confused. > >> When looking e.g. at a stateful Service Function (SF), there >> needs to be an instruction which two of the Service Path >> Identifiers co-releate in order to establish state. > > > > Taking the case of the Service Function (SF) e.g. terminating the > connection, or allowing for late binding, the SF would need to sent the > TCP SYN/ACK segment back. If there is no a-prio knowledge of the return > SPI', then what SPI' would the SF choose ? > > > Many Thanks > > Christian Koenning > From nobody Wed May 18 15:37:11 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DADF12D6B3 for ; Wed, 18 May 2016 15:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.447 X-Spam-Level: X-Spam-Status: No, score=-8.447 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=f5.com 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 UUmKtJjB8xYY for ; Wed, 18 May 2016 15:37:07 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5D1E12D531 for ; Wed, 18 May 2016 15:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1463611028; x=1495147028; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=jmbHma1SOJ9KVqlAa52gGZcqQi5VelFK2cwotPRsPEY=; b=DcuuieeZmbLkDOZjvDbMuuk0cf/8QcuWoysmH3N3VngEUd/Nffip3sMh FISXYw06mL/UCquDdQ5c4jOWfA0Z/C5bEzLDMjufCS1oNvcT1EG/GUrx4 s55XonOUW6EfRBwG5cj3JjJtd3UGH1UESoe0iqbO/uAETYK6/4sF+e0so s=; X-IronPort-AV: E=Sophos;i="5.26,331,1459814400"; d="scan'208";a="218842700" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP; 18 May 2016 22:37:08 +0000 Received: from SEAEXCHMBX04.olympus.F5Net.com (192.168.15.226) by SEAEXCHMBX04.olympus.F5Net.com (192.168.15.226) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 18 May 2016 15:37:06 -0700 Received: from SEAEXCHMBX04.olympus.F5Net.com ([fe80::856e:99ba:ff8b:b756]) by SEAEXCHMBX04.olympus.F5Net.com ([fe80::856e:99ba:ff8b:b756%21]) with mapi id 15.00.1178.000; Wed, 18 May 2016 15:37:06 -0700 From: Christian Koenning To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] draft-ietf-sfc-nsh-04 with L2 encapsulation Thread-Index: AQHRsHUEuuA61QWLJU2qU3GSbFpt55++EjMA///yAoCAAcyZAA== Date: Wed, 18 May 2016 22:37:06 +0000 Message-ID: References: <8FB80637-C981-499B-A9C2-FCE119761B55@f5.com> <46f91899-618a-7443-1e12-d8bb153cf36e@joelhalpern.com> <5EC3BFCB-31AD-4BA2-A9DD-5B2F1C51831D@f5.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] draft-ietf-sfc-nsh-04 with L2 encapsulation X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 22:37:09 -0000 VGhhbmtzIEpvZWwsDQoNCnRoaXMgcmVhbGx5IGhlbHBzIHRvIGNsYXJpZnkuDQoNCj5PbiAxNy8w NS8yMDE2LCAyMTowOCwgIkpvZWwgTS4gSGFscGVybiIgPGptaEBqb2VsaGFscGVybi5jb20+IHdy b3RlOg0KPkJhc2VkIG9uIHRoaXMsIGhlIGluZGljYXRlZCB0aGF0IGhpcyBxdWVzdGlvbiB3YXMg aW5kZWVkIGFib3V0IHRoZSBpbm5lcg0KPnBhY2tldC4gIFRoYXQgaXMgbGVmdCB1bm1vZGlmaWVk IGJ5IGFueSBTRkYuICBTZXJ2aWNlIGZ1bmN0aW9ucyBjYW4gb2YNCj5jb3Vyc2UgZG8gd2hhdCB0 aGV5IGxpa2UuDQoNCkp1c3QgdG8gY29uZmlybSwgYXMgYWxsIHNlbWFudGljcyBvZiBmb3J3YXJk aW5nIHdpdGhpbiB0aGUgU2VydmljZQ0KRnVuY3Rpb24gQ2hhaW5pbmcgKFNGQykgZW5hYmxlZCBk b21haW4gYXJlIGRlcml2ZWQgZnJvbSBOU0gNClNQSS9TSS9NZXRhZGF0YSwgaXQgYWxzbyBtZWFu cyB0aGUgaW5uZXIgZW5jYXBzdWxhdGlvbiB3aWxsIG5vdCBuZWVkIHRvDQpzdXBwb3J0IGUuZy4g QVJQID8NCg0KT3IgbGV0IG1lIGFzayBkaWZmZXJlbnRseSwgaXMgZXRoZXJ0eXBlIHRoZSBvbmx5 IHJlYXNvbiB0aGF0IHRoZSBmdWxsIEwyDQpoZWFkZXIgaXMgY2FycmllZCB0aHJvdWdoID8gSWYg c28sIHdoeSBub3QgcmV3cml0ZSB0aGUgbWFjIGFkZHJlc3NlcyB0bw0Kc29tZSByZXNlcnZlZCBJ QU5BIHJhbmdlPw0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zZmMt bnNoLTA0DQo5LiAgTlNIIEVuY2Fwc3VsYXRpb24gRXhhbXBsZXMNCg0KICAgIEwyIEZyYW1lOg0K ICAgICstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tLS0rDQogICAgfEwyIGhlYWRlciB8IElQICsgVURQIGRzdCBwb3J0PTQ3OTAgfFZYTEFOLWdw ZSBOUD0weDQoTlNIKXwNCiAgICArLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgIC0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0rDQogICAgTlNILE5QPTB4MyAgICAgfG9yaWdpbmFsIGZyYW1lIHwNCiAgICAtLS0tLS0tLS0t LS0tLS0r4oCU4oCU4oCU4oCU4oCU4oCU4oCUKw0KDQogICAgDQogICAgDQpNYW55IFRoYW5rcw0K DQpDaHJpc3RpYW4gS29lbm5pbmcNCi0tDQpGNSBOZXR3b3JrcyBJbmMuDQpjaHJpc3RpYW5AZjUu Y29tDQoNCg0KDQoNCg0KDQoNCg0KDQpPbiAxNy8wNS8yMDE2LCAyMTowOCwgIkpvZWwgTS4gSGFs cGVybiIgPGptaEBqb2VsaGFscGVybi5jb20+IHdyb3RlOg0KDQo+SW4gbG9va2luZyBhdCB0aGlz IHF1ZXN0aW9uLCBJIHNlbnQgQ2hyaXN0aWFuIHRoZSBmb2xsb3dpbmc6DQo+DQo+TG9va2luZyBh dCBwaWVjZXMgb2YgcGFja2V0cyBvbiB0aGUgd2lyZSwgZm9yIGEgVlhMQU4gcGFja2V0IGNhcnJ5 IE5TSCwgDQo+SSB3aWxsIHNlZToNCj4NCj5FaHRlcm5ldCBIZWFkZXIgd2l0aCBFdGhlcm5ldCBh ZGRyZXNzIHRoaXMgZGV2aWNlIGFuZCB0aGF0IG9mIHRoZSBuZXh0IA0KPklQIGRldmljZSB0b3dh cmRzIHRoZSBJUCBkZXN0aW5hdGlvbjsNCj5JUCBIZWFkZXIgd2l0aCB0aGUgSVAgU291cmNlIGVx dWFsIHRvIHRoaXMgZGV2aWNlIGFuZCBJUCBEZXN0IGVxdWFsIHRvIA0KPnRoYXQgb2YgdGhlIG5l eHQgU0ZGLCBhcyBpbmRpY2F0ZWQgYnkgdGhlIHRhYmxlOw0KPlVEUCBoZWFkZXI7DQo+TlNIIEhl YWRlcjsNCj5PcmlnaW5hbCBwYWNrZXQsIHdoaWNoIG1heSBiZSBhbiBJUCBwYWNrZXQgb3IgYW4g RXRoZXJuZXQgUGFja2V0Lg0KPg0KPklmIHRoZSBPcmlnaW5hbCBwYWNrZXQgaXMgYW4gRXRoZXJu ZXQgcGFja2V0LCBOU0ggd2lsbCBuZXZlciBjaGFuZ2UgdGVoIA0KPkV0aGVybmV0IGhlYWRlcnMg aW4gdGhhdCBwYWNrZXQuDQo+Q29udmVyc2VseSwgdGhlIGZpcnN0IGxpc3RlZCBFdGhlcm5ldCBI ZWFkZXIgaXMgYWRkZWQgYW5kIHN1YnRyYWN0ZWQgYXQgDQo+ZWFjaCBob3AgaW4gYWNjb3JkYW5j ZSB3aXRoIElQIGZvcndhcmRpbmcgcnVsZXMuDQo+DQo+QmFzZWQgb24gdGhpcywgaGUgaW5kaWNh dGVkIHRoYXQgaGlzIHF1ZXN0aW9uIHdhcyBpbmRlZWQgYWJvdXQgdGhlIGlubmVyIA0KPnBhY2tl dC4gIFRoYXQgaXMgbGVmdCB1bm1vZGlmaWVkIGJ5IGFueSBTRkYuICBTZXJ2aWNlIGZ1bmN0aW9u cyBjYW4gb2YgDQo+Y291cnNlIGRvIHdoYXQgdGhleSBsaWtlLg0KPg0KPllvdXJzLA0KPkpvZWwN Cj4NCj5PbiA1LzE3LzE2IDM6NTcgUE0sIENocmlzdGlhbiBLb2VubmluZyB3cm90ZToNCj4+IFRo YW5rcyBKb2VsLA0KPj4NCj4+DQo+PiBBbGxvdyBtZSB0byBjbGFyaWZ5Og0KPj4NCj4+IFdoZW4g bG9va2luZyBhdCB0aGUgaW5uZXIgTDIgcGF5bG9hZCAoIG91dGVyIChOU0gpIGlubmVyIEwyKSwN Cj4+IGlzIHRoZSBTRkYvU0YgcmVxdWlyZWQgdG8gY2hhbmdlIHRoZSBkZXN0aW5hdGlvbiBtYWMg YWRkcmVzcyB0bw0KPj4gd2hhdCB0aGUgbmV4dC1ob3AgbWlnaHQgZXhwZWN0ID8NCj4+DQo+PiBZ b3VyIGFuc3dlcg0KPj4gIkpvZWwgTS4gSGFscGVybiIgPGptaEBqb2VsaGFscGVybi5jb20+IHdy b3RlOg0KPj4NCj4+PiBUaGUgImlubmVyIiBwYWNrZXQgaXMgd2hhdGV2ZXIgTlNIIGlzIGNhcnJ5 aW5nLiAgVGhhdCBpcyB3aGF0ZXZlciB3YXMNCj4+PiBzZW50IGludG8gdGhlIHN5c3RlbS4gIElu ZGl2aWR1YWwgU0YgbWF5IHBsYXkgd2l0aCB0aGF0LCBidXQgTlNIDQo+Pj4gZm9yd2FyZGluZyBp Z25vcmVzIHRoYXQuDQo+Pg0KPj4NCj4+IExvb2tpbmcgYXQgdGhlIG91dGVyIHBheWxvYWQsIGZv ciBlLmcuIGEgVlhMQU4tR1BFIGVuZHBvaW50LCB5b3Ugc2F5DQo+PiB0aGF0IG5vcm1hbCBtZWNo YW5pc20gZGVmaW5lIHRoZSBmb3J3YXJkaW5nLg0KPj4NCj4+IEluIHRoZSBzcGVjaWZjIGV4YW1w bGUgb2YgYmVsb3cNCj4+ICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+ICAgICB8ICBTUEkgfCAgU0kgfCAgTkggICAgICAgICAg ICAgICAgIHwgICBUcmFuc3BvcnQgICAgICAgIHwNCj4+ICAgICArLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+ICAgICB8ICAxMCAgfCAy NTUgfCAgMS4xLjEuMSAgICAgICAgICAgIHwgICBWWExBTi1ncGUgICAgICAgIHwNCj4+DQo+PiBJ dCBtZWFucyB0aGF0IHRoZSBWVEVQIGFkZHJlc3MgaXMgMS4xLjEuMSA/IEhvdyBhYm91dCB0aGUg Vk5JID8NCj4+DQo+PiBDaHJpc3RpYW4NCj4+DQo+Pg0KPj4NCj4+IDE3LzA1LzIwMTYsIDIwOjQ4 LCAiSm9lbCBNLiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6DQo+Pg0KPj4+ IEkgYW0gaGF2aW5nIHRyb3VibGUgcGFyc2luZyB5b3VyIHF1ZXN0aW9uLiAgSSBtYXkgYmUgbWlz cmVhZGluZyBpbm5lcg0KPj4+IGFuZCBvdXRlci4NCj4+PiBUaGUgImlubmVyIiBwYWNrZXQgaXMg d2hhdGV2ZXIgTlNIIGlzIGNhcnJ5aW5nLiAgVGhhdCBpcyB3aGF0ZXZlciB3YXMNCj4+PiBzZW50 IGludG8gdGhlIHN5c3RlbS4gIEluZGl2aWR1YWwgU0YgbWF5IHBsYXkgd2l0aCB0aGF0LCBidXQg TlNIDQo+Pj4gZm9yd2FyZGluZyBpZ25vcmVzIHRoYXQuDQo+Pj4NCj4+PiBOb3csIHRoZSBvdXRl ciBwYWNrZXQgZGVwZW5kcyB1cG9uIHRoZSB0dW5uZWwgdHlwZS4gIElmIHRoZSB0dW5uZWwgaXMg YQ0KPj4+IHB1cmUgRXRoZXJuZXQgdHVubmVsLCB0aGVuIHRoZSBOU0ggdGFibGUgdGVsbHMgeW91 IHRoZSBMMiBBZGRyZXNzIHRvIHVzZQ0KPj4+IGZvciB0aGUgb3V0ZXIgcGFja2V0Lg0KPj4+IElm IHRoZSB0dW5uZWwgaXMgYW4gTDMgZW5jYXBzdWxhdGVkIHR1bm5lbCAoVnhMQU4sIEdSRSwgLi4u KSB0aGVuIHRoZQ0KPj4+IE5TSCBpbmZvcm1hdGlvbiBnaXZlcyB5b3UgdGhlIEwzIG5leHQgaG9w LiAgSXQgaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mDQo+Pj4gdGhlIG91dGVyIElQIHN5c3RlbSwg bm90IHRoZSBOU0ggc3lzdGVtLCB0byByZXNvbHZlIHRoYXQgSVAgYWRkcmVzcyB0bw0KPj4+IGFu IGFjdHVhbCBJbnRlcmZhY2UgYW5kIGlmIG5lZWRlZCAodXN1YWxseSkgYW4gTDIgTUFDIGFkZHJl c3MuICBOU0ggYW5kDQo+Pj4gU0ZDIGRvbid0IGNhcmUgaG93IHRoZSBzeXN0ZW0gZG9lcyB0aGF0 LiAgTW9zdCBjb21tbW9ubHksIGl0IGlzIEFSUCAvDQo+Pj4gSVB2NiBORC4gIEJ1dCBpdCBjYW4g YmUgc3RhdGljIGNvbmZpZ3VyYXRpb24gb3Igc29tZSBvdGhlciBmb3JtIG9mIG1hZ2ljLg0KPj4+ DQo+Pj4gWW91cnMsDQo+Pj4gSm9lbA0KPj4+DQo+Pj4gT24gNS8xNy8xNiAzOjM1IFBNLCBDaHJp c3RpYW4gS29lbm5pbmcgd3JvdGU6DQo+Pj4+IEdvb2QgYWZ0ZXJub29uLA0KPj4+Pg0KPj4+PiB3 ZSBoYXZlIGJlZW4gZGlzY3Vzc2luZyBpbnRlcm5hbGx5IHRoZSBzZW1hbnRpY3Mgb2YNCj4+Pj4g TlNIIEwyIGVuY2Fwc3VsYXRpb24gYXMgcGVyOg0KPj4+Pg0KPj4+PiBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zZmMtbnNoLTA0DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+ IDkuMS4gIEdSRSArIE5TSA0KPj4+Pg0KPj4+PiAgICAgTDIgRnJhbWU6DQo+Pj4+ICAgICArLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+Pj4g ICAgIHxMMiBoZWFkZXIgfCBMMyBoZWFkZXIsIHByb3RvPTQ3fEdSRSBoZWFkZXIsUFQ9MHg4OTRG fA0KPj4+PiAgICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0rDQo+Pj4+ICAgICAtLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KPj4+ PiAgICAgTlNILCBOUD0weDMgICAgfG9yaWdpbmFsIGZyYW1lIHwNCj4+Pj4gICAgIC0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQo+Pj4+DQo+Pj4+IDkuMi4gIFZYTEFOLWdwZSArIE5T SA0KPj4+Pg0KPj4+PiAgICAgTDIgRnJhbWU6DQo+Pj4+ICAgICArLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPj4+PiAgICAgfEwyIGhl YWRlciB8IElQICsgVURQIGRzdCBwb3J0PTQ3OTAgfFZYTEFOLWdwZSBOUD0weDQoTlNIKXwNCj4+ Pj4gICAgICstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0rDQo+Pj4+ICAgICAtLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KPj4+ PiAgICAgTlNILE5QPTB4MyAgICAgfG9yaWdpbmFsIGZyYW1lIHwNCj4+Pj4gICAgIC0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQo+Pj4+DQo+Pj4+DQo+Pj4+IDkuMy4gIEV0aGVybmV0 ICsgTlNIDQo+Pj4+ICAgTDIgRnJhbWU6DQo+Pj4+ICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rDQo+Pj4+ICAgfE91dGVy IEV0aGVybmV0LCBFVD0weDg5NEYgICAgICB8IE5TSCwgTlAgPSAweDMgfCBvcmlnaW5hbCBmcmFt ZSB8DQo+Pj4+ICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0rDQo+Pj4+DQo+Pj4+IEFsc28sIGxldCB1cyByZWNhcCB0aGF0 IHRoZSBmb3J3YXJkaW5nIGJlaGF2aW91ciBpcyBkZXJpdmVkIGZyb20gdGhlDQo+Pj4+IFNQSS9T SSBtYXBwaW5nIGRlZmluZWQgYnkgdGhlIGNvbnRyb2xwbGFuZS4NCj4+Pj4NCj4+Pj4gc2VlIHAu MjANCj4+Pj4NCj4+Pj4gICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rDQo+Pj4+ICAgIHwgIFNQSSB8ICBTSSB8ICBOSCAgICAgICAgICAg ICAgICAgfCAgIFRyYW5zcG9ydCAgICAgICAgfA0KPj4+PiAgICArLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+Pj4gICAgfCAgMTAgIHwg MjU1IHwgIDEuMS4xLjEgICAgICAgICAgICB8ICAgVlhMQU4tZ3BlICAgICAgICB8DQo+Pj4+ICAg IHwgIDEwICB8IDI1NCB8ICAyLjIuMi4yICAgICAgICAgICAgfCAgIG52R1JFICAgICAgICAgICAg fA0KPj4+PiAgICB8ICAxMCAgfCAyNTEgfCAgMTAuMS4yLjMgICAgICAgICAgIHwgICBHUkUgICAg ICAgICAgICAgIHwNCj4+Pj4gICAgfCAgNDAgIHwgMjUxIHwgIDEwLjEuMi4zICAgICAgICAgICB8 ICAgR1JFICAgICAgICAgICAgICB8DQo+Pj4+ICAgIHwgIDUwICB8IDIwMCB8ICAwMToyMzo0NTo2 Nzo4OTphYiAgfCAgIEV0aGVybmV0ICAgICAgICAgfA0KPj4+PiAgICB8ICAxNSAgfCAyMTIgfCAg TnVsbCAoZW5kIG9mIHBhdGgpIHwgICBOb25lICAgICAgICAgICAgIHwNCj4+Pj4gICAgKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+Pj4+ ICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA5OiBTRkYgTlNIIE1hcHBpbmcgRXhhbXBsZQ0K Pj4+Pg0KPj4+PiBOb3cgbG9va2luZyBhdCBhIHNwZWNpZmljIGV4YW1wbGUgZm9yIGZvcndhcmRp bmcgdG8gYSBWWExBTi1HUEUNCj4+Pj4gZW5kcG9pbnQsIGlzIHRoZSBuZXh0LWhvcCBkZWZpbmVk IGFzIHRoZSBvdXRlciBsYXllciBkZXN0aW5hdGlvbiwgb3IgaXMNCj4+Pj4gdGhpcyB0aGUgaW5u ZXIgbGF5ZXIgZGVzdGluYXRpb24sIGFuZCBzb21lIGZvcm0gb2YgQVJQIG9yIHByZWRlZmluZWQN Cj4+Pj4gcmVzb2x1dGlvbiBpcyBhc3N1bWVkID8NCj4+Pj4NCj4+Pj4gT3IgZXZlbiB0byBhc2sg bW9yZSBzcGVjaWZpY2FsbHksIHdoZW4gZm9yd2FyZGluZyBmcm9tIGEgU0ZGIHRvIGEgU0YNCj4+ Pj4gdXNpbmcgVlhMQU4tR1BFIE5TSCB3aXRoIEwyIGVuY2Fwc3VsYXRpb24sIGlzIGl0IGV4cGVj dGVkIHRoYXQgdGhlIGlubmVyDQo+Pj4+IEwyIGRlc3RpbmF0aW9uIGFkZHJlc3MgaXMgYmVpbmcg Y2hhbmdlZCB0byB0aGUgcmVzb2x2ZWQgTDIgYWRkcmVzcyBvZg0KPj4+PiB0aGUgU0YgPw0KPj4+ Pg0KPj4+PiBUaGUgbWlzc2luZyBjbGFyaXR5IGlzIGRlcml2ZWQgZnJvbSB0aGUgZGVmaW5pdGlv biBhYm92ZSwgIm9yaWdpbmFsDQo+Pj4+IGZyYW1lLiIgVGhpcyBjYW4gZWl0aGVyIG1lYW4gZW5j YXBzdWxhdGlvbiBoYXBwZW5zIGF0IENsYXNzaWZpZXIgTGV2ZWwsDQo+Pj4+IGFuZCB0aGVuIHRo ZSBMMiBIZWFkZXIgd2lsbCBzdGF5IHVudG91Y2hlZC4gQnV0IHdoYXQgaXMgdGhlbiB0aGUgcHVy cG9zZQ0KPj4+PiBvZiBpdCA/IE9yIGRvZXMgdGhpcyBtZWFuIHRoZSBpbm5lciBMMiBBZGRyZXNz ZXMgbmVlZCB0byB0byByZW5kZXJlZCBob3ANCj4+Pj4gYnkgaG9wIGFzIGluIHRyYWRpdGlvbmFs IG5ldHdvcmtzLiBUaGlzIHdvdWxkIG1lYW4gd2UgaGF2ZSBhIHBvc3NpYmxlDQo+Pj4+IHVud2Fu dGVkIGRlcGVuZGVuY3kuDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IFRoZSBxdWVzdGlvbiBjYW4g YmUgdGFrZW4gb3V0IG9mIHRoZSB0cmFuc3BvcnQgc2NvcGUsIGFuZCBzaW1wbGUgYmUNCj4+Pj4g ZGVmaW5lZCBhcyDigJxEb2VzIE5TSCBMMiBlbmNhcHN1bGF0aW9uIGNhcmUgYWJvdXQgdGhlIGlu bmVyIEwyIGhlYWRlcnMgP+KAnQ0KPj4+Pg0KPj4+PiBQbGVhc2UgYWxsb3cgdXMgdG8gY2xhcmlm eSB0aGlzLg0KPj4+Pg0KPj4+PiBNYW55IFRoYW5rcw0KPj4+Pg0KPj4+PiBDaHJpc3RpYW4gS29l bm5pbmcNCj4+Pj4gLS0NCj4+Pj4gRjUgTmV0d29ya3MgSW5jLg0KPj4+PiBjaHJpc3RpYW5AZjUu Y29tDQo+Pj4+DQo+Pj4+DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4gc2ZjQGlldGYub3JnDQo+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Wed May 18 15:42:50 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B615612D79C for ; Wed, 18 May 2016 15:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 LpvjRF2a5I96 for ; Wed, 18 May 2016 15:42:46 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 1C49112D798 for ; Wed, 18 May 2016 15:42:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 09F1AE400E8; Wed, 18 May 2016 15:42:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1463611365; bh=RBx4YWDUKedNJ9YxtagUZZrW7+nmariTFp/Kw3/u250=; h=Subject:To:References:From:Date:In-Reply-To:From; b=i8KbZqAaBjIcNLayIheDF0o+evls7EtDO7mxKb8V3O1ZEYqUMuhWolJHMvYjuCNOT nV/fPl2GPRF48KCAQ+qRick0YdrUeHsIg9U8dX3Qin60iExj1uFY+4OEa4BrdeBzra psk1E+S5qEdmhJ+8JbSY1c5o2fAuDNfFBMMSLrXM= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id EF29BE400C0; Wed, 18 May 2016 15:42:43 -0700 (PDT) To: Christian Koenning , "sfc@ietf.org" References: <8FB80637-C981-499B-A9C2-FCE119761B55@f5.com> <46f91899-618a-7443-1e12-d8bb153cf36e@joelhalpern.com> <5EC3BFCB-31AD-4BA2-A9DD-5B2F1C51831D@f5.com> From: "Joel M. Halpern" Message-ID: Date: Wed, 18 May 2016 18:43:01 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] draft-ietf-sfc-nsh-04 with L2 encapsulation X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 22:42:49 -0000 The carried packet can be either L2 or L3. The reason is that different users may get different services. For example, if the service chain is being used to deliver a virtualized Residential Gateway, it may be processing the Ethernet packets from the subscriber. At some point in the chain, the Ethernet header may (or may not) be removed by a service function. Of course, the subscriber service could be an IP service, in which case all that gets delivered into the chain is an IP packet. That is why NSH does not mandate the inner packet type, but rather has a type field. As for how the sender may have derived his Ethernet destination address, that depends very much on deployments. I can think of several different ways to do it. While some of those will require specific service functions to make them work, the underlying SFC and NSH mechanisms are the same for all of them. Yours, Joel On 5/18/16 6:37 PM, Christian Koenning wrote: > Thanks Joel, > > this really helps to clarify. > >> On 17/05/2016, 21:08, "Joel M. Halpern" wrote: >> Based on this, he indicated that his question was indeed about the inner >> packet. That is left unmodified by any SFF. Service functions can of >> course do what they like. > > Just to confirm, as all semantics of forwarding within the Service > Function Chaining (SFC) enabled domain are derived from NSH > SPI/SI/Metadata, it also means the inner encapsulation will not need to > support e.g. ARP ? > > Or let me ask differently, is ethertype the only reason that the full L2 > header is carried through ? If so, why not rewrite the mac addresses to > some reserved IANA range? > > https://tools.ietf.org/html/draft-ietf-sfc-nsh-04 > 9. NSH Encapsulation Examples > > L2 Frame: > +----------+------------------------+---------------------+ > |L2 header | IP + UDP dst port=4790 |VXLAN-gpe NP=0x4(NSH)| > +----------+------------------------+---------------------+ > ---------------+---------------+ > NSH,NP=0x3 |original frame | > ---------------+———————+ > > > > Many Thanks > > Christian Koenning > -- > F5 Networks Inc. > christian@f5.com > > > > > > > > > > On 17/05/2016, 21:08, "Joel M. Halpern" wrote: > >> In looking at this question, I sent Christian the following: >> >> Looking at pieces of packets on the wire, for a VXLAN packet carry NSH, >> I will see: >> >> Ehternet Header with Ethernet address this device and that of the next >> IP device towards the IP destination; >> IP Header with the IP Source equal to this device and IP Dest equal to >> that of the next SFF, as indicated by the table; >> UDP header; >> NSH Header; >> Original packet, which may be an IP packet or an Ethernet Packet. >> >> If the Original packet is an Ethernet packet, NSH will never change teh >> Ethernet headers in that packet. >> Conversely, the first listed Ethernet Header is added and subtracted at >> each hop in accordance with IP forwarding rules. >> >> Based on this, he indicated that his question was indeed about the inner >> packet. That is left unmodified by any SFF. Service functions can of >> course do what they like. >> >> Yours, >> Joel >> >> On 5/17/16 3:57 PM, Christian Koenning wrote: >>> Thanks Joel, >>> >>> >>> Allow me to clarify: >>> >>> When looking at the inner L2 payload ( outer (NSH) inner L2), >>> is the SFF/SF required to change the destination mac address to >>> what the next-hop might expect ? >>> >>> Your answer >>> "Joel M. Halpern" wrote: >>> >>>> The "inner" packet is whatever NSH is carrying. That is whatever was >>>> sent into the system. Individual SF may play with that, but NSH >>>> forwarding ignores that. >>> >>> >>> Looking at the outer payload, for e.g. a VXLAN-GPE endpoint, you say >>> that normal mechanism define the forwarding. >>> >>> In the specifc example of below >>> +-------------------------------------------------------+ >>> | SPI | SI | NH | Transport | >>> +-------------------------------------------------------+ >>> | 10 | 255 | 1.1.1.1 | VXLAN-gpe | >>> >>> It means that the VTEP address is 1.1.1.1 ? How about the VNI ? >>> >>> Christian >>> >>> >>> >>> 17/05/2016, 20:48, "Joel M. Halpern" wrote: >>> >>>> I am having trouble parsing your question. I may be misreading inner >>>> and outer. >>>> The "inner" packet is whatever NSH is carrying. That is whatever was >>>> sent into the system. Individual SF may play with that, but NSH >>>> forwarding ignores that. >>>> >>>> Now, the outer packet depends upon the tunnel type. If the tunnel is a >>>> pure Ethernet tunnel, then the NSH table tells you the L2 Address to use >>>> for the outer packet. >>>> If the tunnel is an L3 encapsulated tunnel (VxLAN, GRE, ...) then the >>>> NSH information gives you the L3 next hop. It is the responsibility of >>>> the outer IP system, not the NSH system, to resolve that IP address to >>>> an actual Interface and if needed (usually) an L2 MAC address. NSH and >>>> SFC don't care how the system does that. Most commmonly, it is ARP / >>>> IPv6 ND. But it can be static configuration or some other form of magic. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 5/17/16 3:35 PM, Christian Koenning wrote: >>>>> Good afternoon, >>>>> >>>>> we have been discussing internally the semantics of >>>>> NSH L2 encapsulation as per: >>>>> >>>>> https://tools.ietf.org/html/draft-ietf-sfc-nsh-04 >>>>> >>>>> >>>>> >>>>> 9.1. GRE + NSH >>>>> >>>>> L2 Frame: >>>>> +----------+--------------------+--------------------+ >>>>> |L2 header | L3 header, proto=47|GRE header,PT=0x894F| >>>>> +----------+--------------------+--------------------+ >>>>> ---------------+---------------+ >>>>> NSH, NP=0x3 |original frame | >>>>> ---------------+---------------+ >>>>> >>>>> 9.2. VXLAN-gpe + NSH >>>>> >>>>> L2 Frame: >>>>> +----------+------------------------+---------------------+ >>>>> |L2 header | IP + UDP dst port=4790 |VXLAN-gpe NP=0x4(NSH)| >>>>> +----------+------------------------+---------------------+ >>>>> ---------------+---------------+ >>>>> NSH,NP=0x3 |original frame | >>>>> ---------------+---------------+ >>>>> >>>>> >>>>> 9.3. Ethernet + NSH >>>>> L2 Frame: >>>>> +-------------------------------+---------------+----------------+ >>>>> |Outer Ethernet, ET=0x894F | NSH, NP = 0x3 | original frame | >>>>> +-------------------------------+---------------+----------------+ >>>>> >>>>> Also, let us recap that the forwarding behaviour is derived from the >>>>> SPI/SI mapping defined by the controlplane. >>>>> >>>>> see p.20 >>>>> >>>>> +-------------------------------------------------------+ >>>>> | SPI | SI | NH | Transport | >>>>> +-------------------------------------------------------+ >>>>> | 10 | 255 | 1.1.1.1 | VXLAN-gpe | >>>>> | 10 | 254 | 2.2.2.2 | nvGRE | >>>>> | 10 | 251 | 10.1.2.3 | GRE | >>>>> | 40 | 251 | 10.1.2.3 | GRE | >>>>> | 50 | 200 | 01:23:45:67:89:ab | Ethernet | >>>>> | 15 | 212 | Null (end of path) | None | >>>>> +-------------------------------------------------------+ >>>>> Figure 9: SFF NSH Mapping Example >>>>> >>>>> Now looking at a specific example for forwarding to a VXLAN-GPE >>>>> endpoint, is the next-hop defined as the outer layer destination, or is >>>>> this the inner layer destination, and some form of ARP or predefined >>>>> resolution is assumed ? >>>>> >>>>> Or even to ask more specifically, when forwarding from a SFF to a SF >>>>> using VXLAN-GPE NSH with L2 encapsulation, is it expected that the inner >>>>> L2 destination address is being changed to the resolved L2 address of >>>>> the SF ? >>>>> >>>>> The missing clarity is derived from the definition above, "original >>>>> frame." This can either mean encapsulation happens at Classifier Level, >>>>> and then the L2 Header will stay untouched. But what is then the purpose >>>>> of it ? Or does this mean the inner L2 Addresses need to to rendered hop >>>>> by hop as in traditional networks. This would mean we have a possible >>>>> unwanted dependency. >>>>> >>>>> >>>>> >>>>> The question can be taken out of the transport scope, and simple be >>>>> defined as “Does NSH L2 encapsulation care about the inner L2 headers ?†>>>>> >>>>> Please allow us to clarify this. >>>>> >>>>> Many Thanks >>>>> >>>>> Christian Koenning >>>>> -- >>>>> F5 Networks Inc. >>>>> christian@f5.com >>>>> >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc From nobody Thu May 19 04:16:41 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA7D12D96D for ; Thu, 19 May 2016 04:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 uSQb-R8Rgwbv for ; Thu, 19 May 2016 04:16:35 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94D6912D969 for ; Thu, 19 May 2016 04:16:35 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id v145so122689298oie.0 for ; Thu, 19 May 2016 04:16:35 -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; bh=Uj6UDBAUFfTfPayLZHYWgyb9/U3EirtWk0j65CGxNLI=; b=0jWudGGPgIfnQz9dfscGee/JyFwhrP4GNwEhCo8PB3xSkwxrDv7eNZzQRY6cStsy+K lRh0xLuOGPW2F3fzw6bAqE2cniJDUipSynzGNoi8/c0VTWme1/8jd+sua2IdgEMrhSk2 5p84YoGJjz9PpolWorcVaY9AfSWRZ8PuKNxFCtQz+0tRzD4ZuiwX1USmtclrY9vwJTL0 +WAaojGmGccTwbloiWmXN3czJk1UsCENlSJrwFkMUinc2G6vGSdee8Bu2ZMcWJMB16I+ V9+addPNwGeoCsHCuZIcLDdBTSJHtftg9kuq3RO32TPrbPT1l8liboc4hS4GyRscSoWg AMdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Uj6UDBAUFfTfPayLZHYWgyb9/U3EirtWk0j65CGxNLI=; b=kV5+UtjIvXbtQIXZFPgexRShPp7FOOnb0LRZZ8CKGe1rcN7YSq7/YUTIL0l6y2P0R1 NhC+d2mKC7ml152+TaGRkG0LCJzXchvx+C/KhsuekoQAaHonsvNfkoTTZT7rtv9ai1ON bUiQjrtp/KOBJGncEvrBDtqWC+qkV1hRwSYvQjFU2+yfZyiPmVxHBzfKssqdeGN0g1iK roP3e2MMj4IXUycLqwULMA72g5zx7CWRmjwcN1BIr3JyLNSX8y+woWnH1sqFj4K1P2Ra PW2IeMV0ugO6MbePHUFwB+sGaQnct0ozjiAGzdg44iex9dCCntejAgTMbTxaja7rHglp MgUw== X-Gm-Message-State: AOPr4FU8EuJfA3GK3KID34TMIbzbr6DJDyST/A6vcG2VZV3GUVnD4srRURSPap9sHnfnP8QuMUOl9ctwc7DZoA== X-Received: by 10.202.181.4 with SMTP id e4mr7810406oif.164.1463656594890; Thu, 19 May 2016 04:16:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.106 with HTTP; Thu, 19 May 2016 04:16:15 -0700 (PDT) In-Reply-To: References: <20160512064455.15167.2456.idtracker@ietfa.amsl.com> <6a339336-a3df-6044-4c66-7a48b869670f@gmail.com> <787AE7BB302AE849A7480A190F8B933008D7585A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D763CC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D76703@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: "Andrew G. Malis" Date: Thu, 19 May 2016 07:16:15 -0400 Message-ID: To: "Jim Guichard (jguichar)" Content-Type: multipart/alternative; boundary=001a113ce46269658d0533301bf3 Archived-At: Cc: Martin Stiemerling , BOUCADAIR Mohamed IMT/OLN , "sfc@ietf.org" Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 11:16:39 -0000 --001a113ce46269658d0533301bf3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jim, That sentence is fine, as is adding a reference to the encapsulation. Cheers, Andy On Wed, May 18, 2016 at 1:55 PM, Jim Guichard (jguichar) wrote: > Hi Andy, > > Its the last part of the sentence I do not like as the SFC encapsulation > does not call for steering policies specific to an ingress port. I am oka= y > with saying =E2=80=9CAs a local decision, there may be multiple different= steering > policies *that work in conjunction with the SFC encapsulation as > specified in [draft-ietf-sfc-nsh reference] *for one flow within one SFF= =E2=80=9D. > > Frankly though I would rather see the entire section removed from the > document as I don=E2=80=99t see it adds value but rather confusion (but t= hat=E2=80=99s a > decision for the WG =E2=80=93 its just my personal opinion). > > Jim > > From: "Andrew G. Malis" > Date: Wednesday, May 18, 2016 at 9:36 AM > To: BOUCADAIR Mohamed IMT/OLN > Cc: Jim Guichard , Martin Stiemerling < > mls.ietf@gmail.com>, "sfc@ietf.org" > Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt > > I=E2=80=99m OK with the second change. > > Regarding the first change, Jim asked to remove the text "There are > multiple different steering policies for one flow within one SFF and each > set of steering policies is specific for an ingress port.=E2=80=9D. > > Rather than remove it, I would suggest to revise it to: =E2=80=9CAs a loc= al > decision, there may be multiple different steering policies for a flow > within an SFF and steering policies may be specific for an ingress port.= =E2=80=9D. > > Thanks, > Andy > > On Wed, May 18, 2016 at 9:01 AM, wrote: > >> Re-, >> >> >> >> Works for me. >> >> >> >> Unless there is an objection, these changes will be implemented in the >> next revision. >> >> >> >> Thank you. >> >> >> >> Cheers, >> >> Med >> >> >> >> *De :* Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> *Envoy=C3=A9 :* mercredi 18 mai 2016 13:42 >> >> *=C3=80 :* BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.org >> *Objet :* Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt >> >> >> >> Hi Med, >> >> >> >> Yes, if you can remove Figure 2 and also the text "There are multiple >> different steering policies for one flow within one SFF *and each set of >> steering policies is specific for an ingress port*=E2=80=9D. >> >> >> >> In addition, can you also make it clear in the text that the SFP-id is >> carried within the SFC encapsulation. Suggested text: >> >> >> >> Old: >> >> >> >> For example, it could be the SFP-id together with any fields in the >> data packets, such as (non-exhaustive list): >> >> >> >> New: >> >> >> >> For example, it could be the SFP-id carried *within the SFC >> encapsulation* with any fields in the data packets, such as >> (non-exhaustive list): >> >> >> >> Jim >> >> >> >> On 5/18/16, 2:10 AM, "mohamed.boucadair@orange.com" < >> mohamed.boucadair@orange.com> wrote: >> >> >> >> Hi Jim, >> >> >> >> Thank you for clarifying your concern. >> >> >> >> RFC7665 does not exclude that additional information may be used with th= e >> SFP-id to make SFF forwarding decisions. Also, RFC7665 acknowledges that >> multiple choices may be allowed in an SFF. See this excerpt, for example= : >> >> >> >> SFFs maintain the requisite SFP forwarding information. SFP >> >> forwarding information is associated with a service path identifier >> >> ^^^^^^^^^^^^^ >> >> that is used to uniquely identify an SFP. The service forwarding >> >> state enables an SFF to identify which SFs of a given SFP should be >> >> applied, and in what order, as traffic flows through the associated >> >> SFP. While there may appear to the SFF to be only one available way >> >> to deliver the given SF, there may also be multiple choices allowed >> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> >> by the constraints of the SFP. >> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> >> >> Section 4.10.4 does not violate RFC7665 because it assumes that the >> forwarding information is associated with SFP-id. It does not say that >> additional information MUST be supported other than SFP-id, or other >> information MUST be supported in addition to the SFP-id, but that some >> additional information MIGHT be needed to constrain the SFP (that is sti= ll >> uniquely identified by an SFP-id) for deployments requiring to control t= he >> full sequence of SFFs/SFs. The text cites some examples of such addition= al >> constraints. >> >> >> >> Section 4.10.4 discusses how cp can be used to provision SFFs with >> additional constraints + how to it helps to retrieve the capabilities of >> SFFs. >> >> >> >> You said: >> >> >> >> I suggest that the text is silent on whether the ingress interface has >> >> context to the SFF - its an implementation/deployment decision. >> >> >> >> I see that you are not conformable with Figure 2 (despite the text is >> clear this is an example). The intent of that figure is to illustrate th= e >> use of "match condition/action" cited in the text. >> >> >> >> Would you be OK if that Figure is removed? >> >> >> >> Thank you. >> >> >> >> Cheers, >> >> Med >> >> >> >> -----Message d'origine----- >> >> De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com >> ] >> >> Envoy=C3=A9 : mardi 17 mai 2016 19:31 >> >> =C3=80 : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.org >> >> Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt >> >> Hi Med, >> >> My concern (as chair) is with Figure 2 (and all of the text surrounding >> >> it) which suggests that the forwarding is based on incoming SFP-id *and* >> >> ingress port (or any of the other criteria listed). >> >> This is misleading based upon RFC7665 which says the SFF forwards packet= s >> >> based upon the information conveyed within the SFC encapsulation (see >> >> https://tools.ietf.org/html/rfc7665#section-4.3) and the SFC >> encapsulation >> >> document (see >> >> https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-7). >> >> I suggest that the text is silent on whether the ingress interface has >> >> context to the SFF - its an implementation/deployment decision. >> >> Jim >> >> On 5/17/16, 1:42 AM, "mohamed.boucadair@orange.com" >> >> wrote: >> >> >Hi Jim, >> >> > >> >> >I believe all your comments for section 4.10.5 (-04) (section 4.10.4 in >> >> >-05) have been addressed. >> >> > >> >> >For the record, Andy shared a proposal here >> >> >(http://www.ietf.org/mail-archive/web/sfc/current/msg04616.html) while = I >> >> >send a text proposal here >> >> >(http://www.ietf.org/mail-archive/web/sfc/current/msg04651.html). These >> >> >changes were implemented in -05 given that no objections were raised >> >> >against them. >> >> > >> >> >Also, the old section 4.10.4 was removed as per one of your comments. >> >> > >> >> >Applying policies on the full aggregate (sfp-id) is the default mode. B= ut >> >> >for the particular case of this section (that is about "Fully Controlle= d >> >> >SFF/SF Sequence for a SFP"), there might be deployments where it is >> >> >appropriate to allow for local enforcement of polices that are more >> >> >fine-grained (TE, for example). This section does not specify a new sf= c >> >> >encapsulation or calls for recommendation how forwarding must be >> >> >achieved. It does discuss some information that can be passed via the C= 2 >> >> >interface if additional information is required to achieve some TE goal= s. >> >> > >> >> >Cheers, >> >> >Med >> >> > >> >> >> -----Message d'origine----- >> >> >> De : sfc [mailto:sfc-bounces@ietf.org ] De la >> part de Jim Guichard >> >> >> (jguichar) >> >> >> Envoy=C3=A9 : samedi 14 mai 2016 19:48 >> >> >> =C3=80 : Martin Stiemerling; sfc@ietf.org >> >> >> Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt >> >> >> >> >> >> I would like to see my comments addressed for section 4.10.4. >> >> >> >> >> >> Our charter calls for a single SFC encapsulation and that is being >> >> >> documented in draft-ietf-sfc-nsh. The text within this section sugges= ts >> >> >> that forwarding can be enabled using an SFP-id and some other conditi= on >> >> >> such as input port etc. This is inaccurate based upon the SFC >> >> >> encapsulation as well as our WG charter. There is no mention of the S= FC >> >> >> encapsulation or the fact that the NSH base header is the method used >> >> >>for >> >> >> forwarding; note that the most common forwarding method (and the one >> >> >> implemented in several places) is SFP-id + index - this is not even >> >> >> mentioned!. In addition, this is a control plane document; there is n= o >> >> >> need to talk about forwarding other than point to the SFC encapsulati= on >> >> >> document. >> >> >> >> >> >> For these reasons I would like to see this section removed from the >> >> >> document. >> >> >> >> >> >> Jim >> >> >> >> >> >> >> >> >> On 5/14/16, 5:28 AM, "sfc on behalf of Martin Stiemerling" >> >> >> wrote: >> >> >> >> >> >> >Dear all, >> >> >> > >> >> >> >The authors have posted an updated version addressing the reviews ou= t >> >> >>of >> >> >> >the WGLC. >> >> >> > >> >> >> >Please check until May 20th 5pm CEST if your comments have been >> >> >> addressed. >> >> >> > >> >> >> >Thanks, >> >> >> > >> >> >> > Martin >> >> >> > >> >> >> >Am 12.05.16 um 08:44 schrieb internet-drafts@ietf.org: >> >> >> >> >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> >> >> >>directories. >> >> >> >> This draft is a work item of the Service Function Chaining of the >> >> >>IETF. >> >> >> >> >> >> >> >> Title : Service Function Chaining (SFC) Control >> >> >>Plane >> >> >> >>Components & Requirements >> >> >> >> Author : Mohamed Boucadair >> >> >> >> Filename : draft-ietf-sfc-control-plane-05.txt >> >> >> >> Pages : 27 >> >> >> >> Date : 2016-05-11 >> >> >> >> >> >> >> >> Abstract: >> >> >> >> This document describes requirements for conveying information >> >> >> >> between Service Function Chaining (SFC) control elements and SF= C >> >> >> data >> >> >> >> plane functional elements. Also, this document identifies a se= t >> >> >>of >> >> >> >> control interfaces to interact with SFC-aware elements to >> >> >>establish, >> >> >> >> maintain or recover service function chains. This document doe= s >> >> >>not >> >> >> >> specify protocols nor extensions to existing protocols. >> >> >> >> >> >> >> >> This document exclusively focuses on SFC deployments that are >> >> >>under >> >> >> >> the responsibility of a single administrative entity. >> >> >>Inter-domain >> >> >> >> considerations are out of scope. >> >> >> >> >> >> >> >> >> >> >> >> The IETF datatracker status page for this draft is: >> >> >> >> https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ >> >> >> >> >> >> >> >> There's also a htmlized version available at: >> >> >> >> https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05 >> >> >> >> >> >> >> >> A diff from the previous version is available at: >> >> >> >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-control-plane-0= 5 >> >> >> >> >> >> >> >> >> >> >> >> 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.or= g >> . >> >> >> >> >> >> >> >> Internet-Drafts are also available by anonymous FTP at: >> >> >> >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> I-D-Announce mailing list >> >> >> >> I-D-Announce@ietf.org >> >> >> >> https://www.ietf.org/mailman/listinfo/i-d-announce >> >> >> >> Internet-Draft directories: http://www.ietf.org/shadow.html >> >> >> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> >> >> >> >> > >> >> >> >_______________________________________________ >> >> >> >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 >> >> > --001a113ce46269658d0533301bf3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jim,

That sentence is fine, as is addin= g a reference to the encapsulation.

Cheers,
<= div>Andy

On Wed, May 18, 2016 at 1:55 PM, Jim Guichard (jguichar) <jguichar@cis= co.com> wrote:
Hi Andy,

Its the last part of the sentence I do not like as the SFC encapsulati= on does not call for steering policies specific to an ingress port. I am ok= ay with saying =E2=80=9CAs a local decision, there may be multiple differen= t steering policies that work in conjunction with the SFC encapsulation as specified in [dra= ft-ietf-sfc-nsh reference] for one flow within one SFF=E2=80=9D.

Frankly though I would rather see the entire section removed from the = document as I don=E2=80=99t see it adds value but rather confusion (but tha= t=E2=80=99s a decision for the WG =E2=80=93 its just my personal opinion).<= /div>

Jim

From: "Andrew G. Malis" &= lt;agmalis@gmail.com= >
Date: Wednesday, May 18, 201= 6 at 9:36 AM
To: BOUCADAIR Mohamed IMT/OLN <<= a href=3D"mailto:mohamed.boucadair@orange.com" target=3D"_blank">mohamed.bo= ucadair@orange.com>
Cc: Jim Guichard <jguichar@cisco.com>, Marti= n Stiemerling <m= ls.ietf@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] I-D Action: draf= t-ietf-sfc-control-plane-05.txt

I=E2=80=99m OK with the second change.

Regarding the first change, Jim asked to remove the text "There a= re multiple different steering policies for one flow within one SFF and eac= h set of steering policies is specific for an ingress port.=E2=80=9D.

Rather than remove it, I would suggest to revise it to: =E2=80=9CAs a = local decision, there may be multiple different steering policies for a flo= w within an SFF and =C2=A0steering policies may be specific for an ingress = port.=E2=80=9D.

Thanks,
Andy

On Wed, May 18, 2016 at 9:01 AM, <mo= hamed.boucadair@orange.com> wrote:

Re-,

=C2=A0

Works for me.

=C2=A0

Unless there is an objection, t= hese changes will be implemented in the next revision.=

=C2=A0

Thank you.=

=C2=A0

Cheers,

Med

=C2=A0

De=C2=A0: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
Envoy=C3=A9=C2=A0: mercredi 18 mai 2016 13:42


=C3=80=C2=A0: BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.org
Objet=C2=A0: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.t= xt

=C2=A0

Hi Med,

=C2=A0

Yes, if you can remove Figure 2 and also the text &= quot;There are multiple different steering policies for one flow within one= SFF and each set of steering policies is specific for an ingress port= =E2=80=9D.

=C2=A0

In addition, can you also make it clear in the text= that the SFP-id is carried within the SFC encapsulation. Suggested text:

=C2=A0

Old:

=C2=A0

For=C2=A0example, it could be the SFP-id together w= ith any fields in the data=C2=A0packets, such as (non-exhaustive list):<= /u>



New:



For example, it could be the SFP-id carried within the SFC encapsulation with any fields in the data packets, su= ch as (non-exhaustive list):

=C2=A0

Jim

=C2=A0

On 5/18/16, 2:10 AM, "mohamed.boucadair@orange.com&= quot; <mohamed.boucadair@orange.com> wrote:

=C2=A0

Hi Jim,

=C2=A0

Thank you for clarifying your concern.

=C2=A0

RFC7665 does not exclude that additional informatio= n may be used with the SFP-id to make SFF forwarding decisions. Also, RFC76= 65 acknowledges that multiple choices may be allowed in an SFF. See this excerpt, for example:=C2=A0=C2= =A0

=C2=A0

=C2=A0=C2=A0 SFFs maintain the requisite SFP forwar= ding information.=C2=A0=C2=A0SFP

=C2=A0=C2=A0 forwarding information is associated w= ith a service path identifier

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0^^^^^^^^^^^^^

=C2=A0=C2=A0 that is used to uniquely identify an S= FP.=C2=A0=C2=A0The service forwarding

=C2=A0=C2=A0 state enables an SFF to identify which= SFs of a given SFP should be

=C2=A0=C2=A0 applied, and in what order, as traffic= flows through the associated

=C2=A0=C2=A0 SFP.=C2=A0=C2=A0While there may appear= to the SFF to be only one available way

=C2=A0=C2=A0 to deliver the given SF, there may als= o be multiple choices allowed

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^^^^=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0 by the constraints of the SFP.<= u>

=C2=A0=C2=A0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<= u>

=C2=A0

Section 4.10.4 does not violate RFC7665 because it = assumes that the forwarding information is associated with SFP-id. It does = not say that additional information MUST be supported other than SFP-id, or other information MUST be supporte= d in addition to the SFP-id, but that some additional information MIGHT be = needed to constrain the SFP (that is still uniquely identified by an SFP-id= ) for deployments requiring to control the full sequence of SFFs/SFs. The text cites some examples of such additi= onal constraints.

=C2=A0

Section 4.10.4 discusses how cp can be used to prov= ision SFFs with additional constraints + how to it helps to retrieve the ca= pabilities of SFFs.

=C2=A0

You said:

=C2=A0

I suggest that the text is silent on whether the in= gress interface has

context to the SFF - its an implementation/deployme= nt decision.

=C2=A0

I see that you are not conformable with Figure 2 (d= espite the text is clear this is an example). The intent of that figure is = to illustrate the use of "match condition/action" cited in the text.=C2=A0=C2=A0=

=C2=A0

Would you be OK if that Figure is removed?

=C2=A0

Thank you.

=C2=A0

Cheers,

Med

=C2=A0

-----Message d'origine-----

De=C2=A0: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]

Envoy=C3=A9=C2=A0: mardi 17 mai 2016 19:31

=C3=80=C2=A0: BOUCADAIR Mohamed IMT/OLN; Martin Sti= emerling; sfc@ietf.org

Objet=C2=A0: Re: [sfc] I-D Action: draft-ietf-sfc-c= ontrol-plane-05.txt

Hi Med,

My concern (as chair) is with Figure 2 (and all of = the text surrounding

it) which suggests that the forwarding is based on = incoming SFP-id *and*

ingress port (or any of the other criteria listed).=

This is misleading based upon RFC7665 which says th= e SFF forwards packets

based upon the information conveyed within the SFC = encapsulation (see

document (see

I suggest that the text is silent on whether the in= gress interface has

context to the SFF - its an implementation/deployme= nt decision.

Jim

On 5/17/16, 1:42 AM, "mohamed.boucadair@orange.com&= quot;

>Hi Jim,

>=C2=A0

>I believe all your comments for section 4.10.5 = (-04) (section 4.10.4 in

>-05) have been addressed.<= /p>

>=C2=A0

>For the record, Andy shared a proposal here<= /u>

>send a text proposal here<= /p>

>changes were implemented in -05 given that no o= bjections were raised

>against them.

>=C2=A0

>Also, the old section 4.10.4 was removed as per= one of your comments.

>=C2=A0

>Applying policies on the full aggregate (sfp-id= ) is the default mode. But

>for the particular case of this section (that i= s about "Fully Controlled

>SFF/SF Sequence for a SFP"), there might b= e deployments where it is

>appropriate to allow for local enforcement of p= olices that are more

>fine-grained (TE, for example).=C2=A0=C2=A0This= section does not specify a new sfc

>encapsulation or calls for recommendation how f= orwarding must be

>achieved. It does discuss some information that= can be passed via the C2

>interface if additional information is required= to achieve some TE goals.

>=C2=A0

>Cheers,

>Med

>=C2=A0

>> -----Message d'origine-----<= /u>

>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Ji= m Guichard

>> (jguichar)

>> Envoy=C3=A9 : samedi 14 mai 2016 19:48<= /u>

>> =C3=80 : Martin Stiemerling; sfc@ietf.org

>> Objet : Re: [sfc] I-D Action: draft-ietf-s= fc-control-plane-05.txt

>>=C2=A0

>> I would like to see my comments addressed = for section 4.10.4.

>>=C2=A0

>> Our charter calls for a single SFC encapsu= lation and that is being

>> documented in draft-ietf-sfc-nsh. The text= within this section suggests

>> that forwarding can be enabled using an SF= P-id and some other condition

>> such as input port etc. This is inaccurate= based upon the SFC

>> encapsulation as well as our WG charter. T= here is no mention of the SFC

>> encapsulation or the fact that the NSH bas= e header is the method used

>>for

>> forwarding; note that the most common forw= arding method (and the one

>> implemented in several places) is SFP-id += index - this is not even

>> mentioned!. In addition, this is a control= plane document; there is no

>> need to talk about forwarding other than p= oint to the SFC encapsulation

>> document.

>>=C2=A0

>> For these reasons I would like to see this= section removed from the

>> document.

>>=C2=A0

>> Jim

>>=C2=A0

>>=C2=A0

>> On 5/14/16, 5:28 AM, "sfc on behalf o= f Martin Stiemerling"

>>=C2=A0

>> >Dear all,

>> >

>> >The authors have posted an updated ver= sion addressing the reviews out

>>of

>> >the WGLC.

>> >

>> >Please check until May 20th 5pm CEST i= f your comments have been

>> addressed.

>> >

>> >Thanks,

>> >

>> >=C2=A0=C2=A0=C2=A0=C2=A0Martin<= u>

>> >

>> >>

>> >> A New Internet-Draft is available= from the on-line Internet-Drafts

>> >>directories.<= /p>

>> >> This draft is a work item of the = Service Function Chaining of the

>>IETF.

>> >>

>> >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Title=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 : Service Function Chaining (SFC) Control

>>Plane

>> >>Components & Requirements

>> >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Author=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0: Mohamed Boucadair

>> >> Filename=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0: draft-ietf-sfc-control-plane-05.txt=

>> >> Pages=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 27

>> >> Date=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 2016-05-11

>> >>

>> >> Abstract:

>> >>=C2=A0=C2=A0=C2=A0=C2=A0This docum= ent describes requirements for conveying information

>> >>=C2=A0=C2=A0=C2=A0=C2=A0between Se= rvice Function Chaining (SFC) control elements and SFC=

>> data

>> >>=C2=A0=C2=A0=C2=A0=C2=A0plane func= tional elements.=C2=A0=C2=A0Also, this document identifies a set<= /u>

>>of

>> >>=C2=A0=C2=A0=C2=A0=C2=A0control in= terfaces to interact with SFC-aware elements to

>>establish,

>> >>=C2=A0=C2=A0=C2=A0=C2=A0maintain o= r recover service function chains.=C2=A0=C2=A0This document does<= /u>

>>not

>> >>=C2=A0=C2=A0=C2=A0=C2=A0specify pr= otocols nor extensions to existing protocols.

>> >>

>> >>=C2=A0=C2=A0=C2=A0=C2=A0This docum= ent exclusively focuses on SFC deployments that are

>>under

>> >>=C2=A0=C2=A0=C2=A0=C2=A0the respon= sibility of a single administrative entity.

>>Inter-domain

>> >>=C2=A0=C2=A0=C2=A0=C2=A0considerat= ions are out of scope.

>> >>

>> >>

>> >> The IETF datatracker status page = for this draft is:

>> >>

>> >> There's also a htmlized versi= on available at:

>> >>

>> >> A diff from the previous version = is available at:

>> >>

>> >>

>> >> Please note that it may take a co= uple of minutes from the time of

>> >>submission

>> >> until the htmlized version and di= ff are available at tools.ietf.org.<= /u>

>> >>

>> >> Internet-Drafts are also availabl= e by anonymous FTP at:

>> >>

>> >> _________________________________= ______________

>> >> I-D-Announce mailing list<= u>

>> >> Internet-Draft directories: http://www.ie= tf.org/shadow.html

>> >>

>> >

>> >______________________________________= _________

>> >sfc mailing list<= /p>

>>=C2=A0

>> __________________________________________= _____

>> sfc mailing list

=C2=A0

=C2=A0


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

--001a113ce46269658d0533301bf3-- From nobody Thu May 19 07:30:47 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5F512D0DE for ; Thu, 19 May 2016 07:30:46 -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 autolearn_force=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 T0GyxTwPc7rC for ; Thu, 19 May 2016 07:30:39 -0700 (PDT) Received: from hub021-ca-8.exch021.serverdata.net (hub021-ca-8.exch021.serverdata.net [64.78.56.73]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB18112B059 for ; Thu, 19 May 2016 07:30:37 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-8.exch021.domain.local ([10.254.4.112]) with mapi id 14.03.0266.001; Thu, 19 May 2016 07:30:36 -0700 From: Ron Parker To: "Joel M. Halpern" , Christian Koenning , "sfc@ietf.org" Thread-Topic: [sfc] draft-ietf-sfc-nsh-04 with L2 encapsulation Thread-Index: AQHRsHUIdTs15T8dt0uR69AqqESFGp++ATqAgAAC+4CAAbvWAIAAAaeAgACS1wA= Date: Thu, 19 May 2016 14:30:36 +0000 Message-ID: References: <8FB80637-C981-499B-A9C2-FCE119761B55@f5.com> <46f91899-618a-7443-1e12-d8bb153cf36e@joelhalpern.com> <5EC3BFCB-31AD-4BA2-A9DD-5B2F1C51831D@f5.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [107.107.61.7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] draft-ietf-sfc-nsh-04 with L2 encapsulation X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 14:30:46 -0000 SSB3b3VsZCBhZGQgdGhhdCBpZiB0aGUgImlubmVyIiBETUFDIG9mIGEgY2FycmllZCBMMiBmcmFt ZSBuZWVkZWQgdG8gYmUgY2hhbmdlZCBmb3Igc29tZSBhcHBsaWNhdGlvbi1zcGVjaWZpYyByZWFz b24gKGUuZy4sIHNvbWUgc29ydCBvZiBwcm94eSBmdW5jdGlvbmFsaXR5KSwgdGhhdCB3b3VsZCBi ZSB0aGUgcmVzcG9uc2liaWxpdHkgb2YgYSBzZXJ2aWNlIGZ1bmN0aW9uIGFuZCBub3QgdGhlIHJl c3BvbnNpYmlsaXR5IG9mIGFuIFNGRi4NCg0KICAgUm9uDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgSm9lbCBNLiBIYWxwZXJuDQpTZW50OiBXZWRuZXNkYXksIE1heSAxOCwgMjAxNiA2OjQz IFBNDQpUbzogQ2hyaXN0aWFuIEtvZW5uaW5nIDxDLktvZW5uaW5nQEY1LmNvbT47IHNmY0BpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtzZmNdIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNCB3aXRoIEwyIGVu Y2Fwc3VsYXRpb24NCg0KVGhlIGNhcnJpZWQgcGFja2V0IGNhbiBiZSBlaXRoZXIgTDIgb3IgTDMu ICBUaGUgcmVhc29uIGlzIHRoYXQgZGlmZmVyZW50IHVzZXJzIG1heSBnZXQgZGlmZmVyZW50IHNl cnZpY2VzLg0KDQpGb3IgZXhhbXBsZSwgaWYgdGhlIHNlcnZpY2UgY2hhaW4gaXMgYmVpbmcgdXNl ZCB0byBkZWxpdmVyIGEgdmlydHVhbGl6ZWQgUmVzaWRlbnRpYWwgR2F0ZXdheSwgaXQgbWF5IGJl IHByb2Nlc3NpbmcgdGhlIEV0aGVybmV0IHBhY2tldHMgZnJvbSB0aGUgc3Vic2NyaWJlci4gIEF0 IHNvbWUgcG9pbnQgaW4gdGhlIGNoYWluLCB0aGUgRXRoZXJuZXQgaGVhZGVyIG1heSAob3IgbWF5 DQpub3QpIGJlIHJlbW92ZWQgYnkgYSBzZXJ2aWNlIGZ1bmN0aW9uLiAgT2YgY291cnNlLCB0aGUg c3Vic2NyaWJlciBzZXJ2aWNlIGNvdWxkIGJlIGFuIElQIHNlcnZpY2UsIGluIHdoaWNoIGNhc2Ug YWxsIHRoYXQgZ2V0cyBkZWxpdmVyZWQgaW50byB0aGUgY2hhaW4gaXMgYW4gSVAgcGFja2V0Lg0K DQpUaGF0IGlzIHdoeSBOU0ggZG9lcyBub3QgbWFuZGF0ZSB0aGUgaW5uZXIgcGFja2V0IHR5cGUs IGJ1dCByYXRoZXIgaGFzIGEgdHlwZSBmaWVsZC4NCg0KQXMgZm9yIGhvdyB0aGUgc2VuZGVyIG1h eSBoYXZlIGRlcml2ZWQgaGlzIEV0aGVybmV0IGRlc3RpbmF0aW9uIGFkZHJlc3MsIHRoYXQgZGVw ZW5kcyB2ZXJ5IG11Y2ggb24gZGVwbG95bWVudHMuICBJIGNhbiB0aGluayBvZiBzZXZlcmFsIGRp ZmZlcmVudCB3YXlzIHRvIGRvIGl0LiAgV2hpbGUgc29tZSBvZiB0aG9zZSB3aWxsIHJlcXVpcmUg c3BlY2lmaWMgc2VydmljZSBmdW5jdGlvbnMgdG8gbWFrZSB0aGVtIHdvcmssIHRoZSB1bmRlcmx5 aW5nIFNGQyBhbmQgTlNIIG1lY2hhbmlzbXMgYXJlIHRoZSBzYW1lIGZvciBhbGwgb2YgdGhlbS4N Cg0KWW91cnMsDQpKb2VsDQoNCk9uIDUvMTgvMTYgNjozNyBQTSwgQ2hyaXN0aWFuIEtvZW5uaW5n IHdyb3RlOg0KPiBUaGFua3MgSm9lbCwNCj4NCj4gdGhpcyByZWFsbHkgaGVscHMgdG8gY2xhcmlm eS4NCj4NCj4+IE9uIDE3LzA1LzIwMTYsIDIxOjA4LCAiSm9lbCBNLiBIYWxwZXJuIiA8am1oQGpv ZWxoYWxwZXJuLmNvbT4gd3JvdGU6DQo+PiBCYXNlZCBvbiB0aGlzLCBoZSBpbmRpY2F0ZWQgdGhh dCBoaXMgcXVlc3Rpb24gd2FzIGluZGVlZCBhYm91dCB0aGUgDQo+PiBpbm5lciBwYWNrZXQuICBU aGF0IGlzIGxlZnQgdW5tb2RpZmllZCBieSBhbnkgU0ZGLiAgU2VydmljZSBmdW5jdGlvbnMgDQo+ PiBjYW4gb2YgY291cnNlIGRvIHdoYXQgdGhleSBsaWtlLg0KPg0KPiBKdXN0IHRvIGNvbmZpcm0s IGFzIGFsbCBzZW1hbnRpY3Mgb2YgZm9yd2FyZGluZyB3aXRoaW4gdGhlIFNlcnZpY2UgDQo+IEZ1 bmN0aW9uIENoYWluaW5nIChTRkMpIGVuYWJsZWQgZG9tYWluIGFyZSBkZXJpdmVkIGZyb20gTlNI IA0KPiBTUEkvU0kvTWV0YWRhdGEsIGl0IGFsc28gbWVhbnMgdGhlIGlubmVyIGVuY2Fwc3VsYXRp b24gd2lsbCBub3QgbmVlZCANCj4gdG8gc3VwcG9ydCBlLmcuIEFSUCA/DQo+DQo+IE9yIGxldCBt ZSBhc2sgZGlmZmVyZW50bHksIGlzIGV0aGVydHlwZSB0aGUgb25seSByZWFzb24gdGhhdCB0aGUg ZnVsbCANCj4gTDIgaGVhZGVyIGlzIGNhcnJpZWQgdGhyb3VnaCA/IElmIHNvLCB3aHkgbm90IHJl d3JpdGUgdGhlIG1hYyANCj4gYWRkcmVzc2VzIHRvIHNvbWUgcmVzZXJ2ZWQgSUFOQSByYW5nZT8N Cj4NCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2ZjLW5zaC0wNA0K PiA5LiAgTlNIIEVuY2Fwc3VsYXRpb24gRXhhbXBsZXMNCj4NCj4gICAgIEwyIEZyYW1lOg0KPiAg ICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0t LS0tLSsNCj4gICAgIHxMMiBoZWFkZXIgfCBJUCArIFVEUCBkc3QgcG9ydD00NzkwIHxWWExBTi1n cGUgTlA9MHg0KE5TSCl8DQo+ICAgICArLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPiAgICAgLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLSsNCj4gICAgIE5TSCxOUD0weDMgICAgIHxvcmlnaW5hbCBmcmFtZSB8DQo+ICAgICAt LS0tLS0tLS0tLS0tLS0r4oCU4oCU4oCU4oCU4oCU4oCU4oCUKw0KPg0KPg0KPg0KPiBNYW55IFRo YW5rcw0KPg0KPiBDaHJpc3RpYW4gS29lbm5pbmcNCj4gLS0NCj4gRjUgTmV0d29ya3MgSW5jLg0K PiBjaHJpc3RpYW5AZjUuY29tDQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+IE9uIDE3LzA1 LzIwMTYsIDIxOjA4LCAiSm9lbCBNLiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbT4gd3Jv dGU6DQo+DQo+PiBJbiBsb29raW5nIGF0IHRoaXMgcXVlc3Rpb24sIEkgc2VudCBDaHJpc3RpYW4g dGhlIGZvbGxvd2luZzoNCj4+DQo+PiBMb29raW5nIGF0IHBpZWNlcyBvZiBwYWNrZXRzIG9uIHRo ZSB3aXJlLCBmb3IgYSBWWExBTiBwYWNrZXQgY2FycnkgDQo+PiBOU0gsIEkgd2lsbCBzZWU6DQo+ Pg0KPj4gRWh0ZXJuZXQgSGVhZGVyIHdpdGggRXRoZXJuZXQgYWRkcmVzcyB0aGlzIGRldmljZSBh bmQgdGhhdCBvZiB0aGUgDQo+PiBuZXh0IElQIGRldmljZSB0b3dhcmRzIHRoZSBJUCBkZXN0aW5h dGlvbjsgSVAgSGVhZGVyIHdpdGggdGhlIElQIA0KPj4gU291cmNlIGVxdWFsIHRvIHRoaXMgZGV2 aWNlIGFuZCBJUCBEZXN0IGVxdWFsIHRvIHRoYXQgb2YgdGhlIG5leHQgDQo+PiBTRkYsIGFzIGlu ZGljYXRlZCBieSB0aGUgdGFibGU7IFVEUCBoZWFkZXI7IE5TSCBIZWFkZXI7IE9yaWdpbmFsIA0K Pj4gcGFja2V0LCB3aGljaCBtYXkgYmUgYW4gSVAgcGFja2V0IG9yIGFuIEV0aGVybmV0IFBhY2tl dC4NCj4+DQo+PiBJZiB0aGUgT3JpZ2luYWwgcGFja2V0IGlzIGFuIEV0aGVybmV0IHBhY2tldCwg TlNIIHdpbGwgbmV2ZXIgY2hhbmdlIA0KPj4gdGVoIEV0aGVybmV0IGhlYWRlcnMgaW4gdGhhdCBw YWNrZXQuDQo+PiBDb252ZXJzZWx5LCB0aGUgZmlyc3QgbGlzdGVkIEV0aGVybmV0IEhlYWRlciBp cyBhZGRlZCBhbmQgc3VidHJhY3RlZCANCj4+IGF0IGVhY2ggaG9wIGluIGFjY29yZGFuY2Ugd2l0 aCBJUCBmb3J3YXJkaW5nIHJ1bGVzLg0KPj4NCj4+IEJhc2VkIG9uIHRoaXMsIGhlIGluZGljYXRl ZCB0aGF0IGhpcyBxdWVzdGlvbiB3YXMgaW5kZWVkIGFib3V0IHRoZSANCj4+IGlubmVyIHBhY2tl dC4gIFRoYXQgaXMgbGVmdCB1bm1vZGlmaWVkIGJ5IGFueSBTRkYuICBTZXJ2aWNlIGZ1bmN0aW9u cyANCj4+IGNhbiBvZiBjb3Vyc2UgZG8gd2hhdCB0aGV5IGxpa2UuDQo+Pg0KPj4gWW91cnMsDQo+ PiBKb2VsDQo+Pg0KPj4gT24gNS8xNy8xNiAzOjU3IFBNLCBDaHJpc3RpYW4gS29lbm5pbmcgd3Jv dGU6DQo+Pj4gVGhhbmtzIEpvZWwsDQo+Pj4NCj4+Pg0KPj4+IEFsbG93IG1lIHRvIGNsYXJpZnk6 DQo+Pj4NCj4+PiBXaGVuIGxvb2tpbmcgYXQgdGhlIGlubmVyIEwyIHBheWxvYWQgKCBvdXRlciAo TlNIKSBpbm5lciBMMiksIGlzIHRoZSANCj4+PiBTRkYvU0YgcmVxdWlyZWQgdG8gY2hhbmdlIHRo ZSBkZXN0aW5hdGlvbiBtYWMgYWRkcmVzcyB0byB3aGF0IHRoZSANCj4+PiBuZXh0LWhvcCBtaWdo dCBleHBlY3QgPw0KPj4+DQo+Pj4gWW91ciBhbnN3ZXINCj4+PiAiSm9lbCBNLiBIYWxwZXJuIiA8 am1oQGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6DQo+Pj4NCj4+Pj4gVGhlICJpbm5lciIgcGFja2V0 IGlzIHdoYXRldmVyIE5TSCBpcyBjYXJyeWluZy4gIFRoYXQgaXMgd2hhdGV2ZXIgDQo+Pj4+IHdh cyBzZW50IGludG8gdGhlIHN5c3RlbS4gIEluZGl2aWR1YWwgU0YgbWF5IHBsYXkgd2l0aCB0aGF0 LCBidXQgDQo+Pj4+IE5TSCBmb3J3YXJkaW5nIGlnbm9yZXMgdGhhdC4NCj4+Pg0KPj4+DQo+Pj4g TG9va2luZyBhdCB0aGUgb3V0ZXIgcGF5bG9hZCwgZm9yIGUuZy4gYSBWWExBTi1HUEUgZW5kcG9p bnQsIHlvdSBzYXkgDQo+Pj4gdGhhdCBub3JtYWwgbWVjaGFuaXNtIGRlZmluZSB0aGUgZm9yd2Fy ZGluZy4NCj4+Pg0KPj4+IEluIHRoZSBzcGVjaWZjIGV4YW1wbGUgb2YgYmVsb3cNCj4+PiAgICAg Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r DQo+Pj4gICAgIHwgIFNQSSB8ICBTSSB8ICBOSCAgICAgICAgICAgICAgICAgfCAgIFRyYW5zcG9y dCAgICAgICAgfA0KPj4+ICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+PiAgICAgfCAgMTAgIHwgMjU1IHwgIDEuMS4xLjEgICAg ICAgICAgICB8ICAgVlhMQU4tZ3BlICAgICAgICB8DQo+Pj4NCj4+PiBJdCBtZWFucyB0aGF0IHRo ZSBWVEVQIGFkZHJlc3MgaXMgMS4xLjEuMSA/IEhvdyBhYm91dCB0aGUgVk5JID8NCj4+Pg0KPj4+ IENocmlzdGlhbg0KPj4+DQo+Pj4NCj4+Pg0KPj4+IDE3LzA1LzIwMTYsIDIwOjQ4LCAiSm9lbCBN LiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6DQo+Pj4NCj4+Pj4gSSBhbSBo YXZpbmcgdHJvdWJsZSBwYXJzaW5nIHlvdXIgcXVlc3Rpb24uICBJIG1heSBiZSBtaXNyZWFkaW5n IA0KPj4+PiBpbm5lciBhbmQgb3V0ZXIuDQo+Pj4+IFRoZSAiaW5uZXIiIHBhY2tldCBpcyB3aGF0 ZXZlciBOU0ggaXMgY2FycnlpbmcuICBUaGF0IGlzIHdoYXRldmVyIA0KPj4+PiB3YXMgc2VudCBp bnRvIHRoZSBzeXN0ZW0uICBJbmRpdmlkdWFsIFNGIG1heSBwbGF5IHdpdGggdGhhdCwgYnV0IA0K Pj4+PiBOU0ggZm9yd2FyZGluZyBpZ25vcmVzIHRoYXQuDQo+Pj4+DQo+Pj4+IE5vdywgdGhlIG91 dGVyIHBhY2tldCBkZXBlbmRzIHVwb24gdGhlIHR1bm5lbCB0eXBlLiAgSWYgdGhlIHR1bm5lbCAN Cj4+Pj4gaXMgYSBwdXJlIEV0aGVybmV0IHR1bm5lbCwgdGhlbiB0aGUgTlNIIHRhYmxlIHRlbGxz IHlvdSB0aGUgTDIgDQo+Pj4+IEFkZHJlc3MgdG8gdXNlIGZvciB0aGUgb3V0ZXIgcGFja2V0Lg0K Pj4+PiBJZiB0aGUgdHVubmVsIGlzIGFuIEwzIGVuY2Fwc3VsYXRlZCB0dW5uZWwgKFZ4TEFOLCBH UkUsIC4uLikgdGhlbiANCj4+Pj4gdGhlIE5TSCBpbmZvcm1hdGlvbiBnaXZlcyB5b3UgdGhlIEwz IG5leHQgaG9wLiAgSXQgaXMgdGhlIA0KPj4+PiByZXNwb25zaWJpbGl0eSBvZiB0aGUgb3V0ZXIg SVAgc3lzdGVtLCBub3QgdGhlIE5TSCBzeXN0ZW0sIHRvIA0KPj4+PiByZXNvbHZlIHRoYXQgSVAg YWRkcmVzcyB0byBhbiBhY3R1YWwgSW50ZXJmYWNlIGFuZCBpZiBuZWVkZWQgDQo+Pj4+ICh1c3Vh bGx5KSBhbiBMMiBNQUMgYWRkcmVzcy4gIE5TSCBhbmQgU0ZDIGRvbid0IGNhcmUgaG93IHRoZSBz eXN0ZW0gDQo+Pj4+IGRvZXMgdGhhdC4gIE1vc3QgY29tbW1vbmx5LCBpdCBpcyBBUlAgLw0KPj4+ PiBJUHY2IE5ELiAgQnV0IGl0IGNhbiBiZSBzdGF0aWMgY29uZmlndXJhdGlvbiBvciBzb21lIG90 aGVyIGZvcm0gb2YgbWFnaWMuDQo+Pj4+DQo+Pj4+IFlvdXJzLA0KPj4+PiBKb2VsDQo+Pj4+DQo+ Pj4+IE9uIDUvMTcvMTYgMzozNSBQTSwgQ2hyaXN0aWFuIEtvZW5uaW5nIHdyb3RlOg0KPj4+Pj4g R29vZCBhZnRlcm5vb24sDQo+Pj4+Pg0KPj4+Pj4gd2UgaGF2ZSBiZWVuIGRpc2N1c3NpbmcgaW50 ZXJuYWxseSB0aGUgc2VtYW50aWNzIG9mIE5TSCBMMiANCj4+Pj4+IGVuY2Fwc3VsYXRpb24gYXMg cGVyOg0KPj4+Pj4NCj4+Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXNmYy1uc2gtMDQNCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IDkuMS4gIEdSRSArIE5TSA0K Pj4+Pj4NCj4+Pj4+ICAgICBMMiBGcmFtZToNCj4+Pj4+ICAgICArLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+Pj4+ICAgICB8TDIgaGVhZGVy IHwgTDMgaGVhZGVyLCBwcm90bz00N3xHUkUgaGVhZGVyLFBUPTB4ODk0RnwNCj4+Pj4+ICAgICAr LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+ Pj4+ICAgICAtLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KPj4+Pj4gICAgIE5TSCwg TlA9MHgzICAgIHxvcmlnaW5hbCBmcmFtZSB8DQo+Pj4+PiAgICAgLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLSsNCj4+Pj4+DQo+Pj4+PiA5LjIuICBWWExBTi1ncGUgKyBOU0gNCj4+Pj4+ DQo+Pj4+PiAgICAgTDIgRnJhbWU6DQo+Pj4+PiAgICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+Pj4+ICAgICB8TDIgaGVhZGVy IHwgSVAgKyBVRFAgZHN0IHBvcnQ9NDc5MCB8VlhMQU4tZ3BlIE5QPTB4NChOU0gpfA0KPj4+Pj4g ICAgICstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tLS0rDQo+Pj4+PiAgICAgLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCj4+Pj4+ ICAgICBOU0gsTlA9MHgzICAgICB8b3JpZ2luYWwgZnJhbWUgfA0KPj4+Pj4gICAgIC0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IDkuMy4gIEV0aGVy bmV0ICsgTlNIDQo+Pj4+PiAgIEwyIEZyYW1lOg0KPj4+Pj4gICArLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSsNCj4+Pj4+ICAg fE91dGVyIEV0aGVybmV0LCBFVD0weDg5NEYgICAgICB8IE5TSCwgTlAgPSAweDMgfCBvcmlnaW5h bCBmcmFtZSB8DQo+Pj4+PiAgIA0KPj4+Pj4gKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rDQo+Pj4+Pg0KPj4+Pj4gQWxzbywg bGV0IHVzIHJlY2FwIHRoYXQgdGhlIGZvcndhcmRpbmcgYmVoYXZpb3VyIGlzIGRlcml2ZWQgZnJv bSANCj4+Pj4+IHRoZSBTUEkvU0kgbWFwcGluZyBkZWZpbmVkIGJ5IHRoZSBjb250cm9scGxhbmUu DQo+Pj4+Pg0KPj4+Pj4gc2VlIHAuMjANCj4+Pj4+DQo+Pj4+PiAgICArLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+Pj4+ICAgIHwgIFNQ SSB8ICBTSSB8ICBOSCAgICAgICAgICAgICAgICAgfCAgIFRyYW5zcG9ydCAgICAgICAgfA0KPj4+ Pj4gICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rDQo+Pj4+PiAgICB8ICAxMCAgfCAyNTUgfCAgMS4xLjEuMSAgICAgICAgICAgIHwgICBW WExBTi1ncGUgICAgICAgIHwNCj4+Pj4+ICAgIHwgIDEwICB8IDI1NCB8ICAyLjIuMi4yICAgICAg ICAgICAgfCAgIG52R1JFICAgICAgICAgICAgfA0KPj4+Pj4gICAgfCAgMTAgIHwgMjUxIHwgIDEw LjEuMi4zICAgICAgICAgICB8ICAgR1JFICAgICAgICAgICAgICB8DQo+Pj4+PiAgICB8ICA0MCAg fCAyNTEgfCAgMTAuMS4yLjMgICAgICAgICAgIHwgICBHUkUgICAgICAgICAgICAgIHwNCj4+Pj4+ ICAgIHwgIDUwICB8IDIwMCB8ICAwMToyMzo0NTo2Nzo4OTphYiAgfCAgIEV0aGVybmV0ICAgICAg ICAgfA0KPj4+Pj4gICAgfCAgMTUgIHwgMjEyIHwgIE51bGwgKGVuZCBvZiBwYXRoKSB8ICAgTm9u ZSAgICAgICAgICAgICB8DQo+Pj4+PiAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgIEZp Z3VyZSA5OiBTRkYgTlNIIE1hcHBpbmcgRXhhbXBsZQ0KPj4+Pj4NCj4+Pj4+IE5vdyBsb29raW5n IGF0IGEgc3BlY2lmaWMgZXhhbXBsZSBmb3IgZm9yd2FyZGluZyB0byBhIFZYTEFOLUdQRSANCj4+ Pj4+IGVuZHBvaW50LCBpcyB0aGUgbmV4dC1ob3AgZGVmaW5lZCBhcyB0aGUgb3V0ZXIgbGF5ZXIg ZGVzdGluYXRpb24sIA0KPj4+Pj4gb3IgaXMgdGhpcyB0aGUgaW5uZXIgbGF5ZXIgZGVzdGluYXRp b24sIGFuZCBzb21lIGZvcm0gb2YgQVJQIG9yIA0KPj4+Pj4gcHJlZGVmaW5lZCByZXNvbHV0aW9u IGlzIGFzc3VtZWQgPw0KPj4+Pj4NCj4+Pj4+IE9yIGV2ZW4gdG8gYXNrIG1vcmUgc3BlY2lmaWNh bGx5LCB3aGVuIGZvcndhcmRpbmcgZnJvbSBhIFNGRiB0byBhIA0KPj4+Pj4gU0YgdXNpbmcgVlhM QU4tR1BFIE5TSCB3aXRoIEwyIGVuY2Fwc3VsYXRpb24sIGlzIGl0IGV4cGVjdGVkIHRoYXQgDQo+ Pj4+PiB0aGUgaW5uZXINCj4+Pj4+IEwyIGRlc3RpbmF0aW9uIGFkZHJlc3MgaXMgYmVpbmcgY2hh bmdlZCB0byB0aGUgcmVzb2x2ZWQgTDIgYWRkcmVzcyANCj4+Pj4+IG9mIHRoZSBTRiA/DQo+Pj4+ Pg0KPj4+Pj4gVGhlIG1pc3NpbmcgY2xhcml0eSBpcyBkZXJpdmVkIGZyb20gdGhlIGRlZmluaXRp b24gYWJvdmUsIA0KPj4+Pj4gIm9yaWdpbmFsIGZyYW1lLiIgVGhpcyBjYW4gZWl0aGVyIG1lYW4g ZW5jYXBzdWxhdGlvbiBoYXBwZW5zIGF0IA0KPj4+Pj4gQ2xhc3NpZmllciBMZXZlbCwgYW5kIHRo ZW4gdGhlIEwyIEhlYWRlciB3aWxsIHN0YXkgdW50b3VjaGVkLiBCdXQgDQo+Pj4+PiB3aGF0IGlz IHRoZW4gdGhlIHB1cnBvc2Ugb2YgaXQgPyBPciBkb2VzIHRoaXMgbWVhbiB0aGUgaW5uZXIgTDIg DQo+Pj4+PiBBZGRyZXNzZXMgbmVlZCB0byB0byByZW5kZXJlZCBob3AgYnkgaG9wIGFzIGluIHRy YWRpdGlvbmFsIA0KPj4+Pj4gbmV0d29ya3MuIFRoaXMgd291bGQgbWVhbiB3ZSBoYXZlIGEgcG9z c2libGUgdW53YW50ZWQgZGVwZW5kZW5jeS4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IFRo ZSBxdWVzdGlvbiBjYW4gYmUgdGFrZW4gb3V0IG9mIHRoZSB0cmFuc3BvcnQgc2NvcGUsIGFuZCBz aW1wbGUgDQo+Pj4+PiBiZSBkZWZpbmVkIGFzIOKAnERvZXMgTlNIIEwyIGVuY2Fwc3VsYXRpb24g Y2FyZSBhYm91dCB0aGUgaW5uZXIgTDIgaGVhZGVycyA/4oCdDQo+Pj4+Pg0KPj4+Pj4gUGxlYXNl IGFsbG93IHVzIHRvIGNsYXJpZnkgdGhpcy4NCj4+Pj4+DQo+Pj4+PiBNYW55IFRoYW5rcw0KPj4+ Pj4NCj4+Pj4+IENocmlzdGlhbiBLb2VubmluZw0KPj4+Pj4gLS0NCj4+Pj4+IEY1IE5ldHdvcmtz IEluYy4NCj4+Pj4+IGNocmlzdGlhbkBmNS5jb20NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IHNmYyBtYWls aW5nIGxpc3QNCj4+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zZmMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg== From nobody Fri May 20 08:07:19 2016 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A82B12B018; Fri, 20 May 2016 08:07:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160520150719.336.63788.idtracker@ietfa.amsl.com> Date: Fri, 20 May 2016 08:07:19 -0700 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-control-plane-06.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 15:07:19 -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 of the IETF. Title : Service Function Chaining (SFC) Control Plane Components & Requirements Author : Mohamed Boucadair Filename : draft-ietf-sfc-control-plane-06.txt Pages : 27 Date : 2016-05-20 Abstract: This document describes requirements for conveying information between Service Function Chaining (SFC) control elements and SFC data plane functional elements. Also, this document identifies a set of control interfaces to interact with SFC-aware elements to establish, maintain or recover service function chains. This document does not specify protocols nor extensions to existing protocols. This document exclusively focuses on SFC deployments that are under the responsibility of a single administrative entity. Inter-domain considerations are out of scope. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sfc-control-plane-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-control-plane-06 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 May 20 08:09:33 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A8812D1BF for ; Fri, 20 May 2016 08:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 fEl-Hn-NVnQ0 for ; Fri, 20 May 2016 08:09:30 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8D1B12B018 for ; Fri, 20 May 2016 08:09:29 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 60C28C07B2 for ; Fri, 20 May 2016 17:09:28 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 403912006D for ; Fri, 20 May 2016 17:09:28 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0294.000; Fri, 20 May 2016 17:09:28 +0200 From: To: "sfc@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-control-plane-06.txt Thread-Index: AQHRsqlQwgji8Yk81EOH5Mg5swCl7p/B7Xew Date: Fri, 20 May 2016 15:09:27 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D88D23@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <20160520150719.336.63788.idtracker@ietfa.amsl.com> In-Reply-To: <20160520150719.336.63788.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-06.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 15:09:32 -0000 Dear all,=20 The updated version implements the following changes: . The changes suggested by Jim: https://www.ietf.org/mail-archive/web/sfc/c= urrent/msg04711.html and https://www.ietf.org/mail-archive/web/sfc/current/= msg04722.html. . Add a reference to the NSH spec as the SFC encapsulation. No objection was raised against the changes made to address the WGLC commen= ts. Cheers, Med > -----Message d'origine----- > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: vendredi 20 mai 2016 17:07 > =C0=A0: i-d-announce@ietf.org > Cc=A0: sfc@ietf.org > Objet=A0: [sfc] I-D Action: draft-ietf-sfc-control-plane-06.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Service Function Chaining of the IETF. >=20 > Title : Service Function Chaining (SFC) Control Plane > Components & Requirements > Author : Mohamed Boucadair > Filename : draft-ietf-sfc-control-plane-06.txt > Pages : 27 > Date : 2016-05-20 >=20 > Abstract: > This document describes requirements for conveying information > between Service Function Chaining (SFC) control elements and SFC data > plane functional elements. Also, this document identifies a set of > control interfaces to interact with SFC-aware elements to establish, > maintain or recover service function chains. This document does not > specify protocols nor extensions to existing protocols. >=20 > This document exclusively focuses on SFC deployments that are under > the responsibility of a single administrative entity. Inter-domain > considerations are out of scope. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sfc-control-plane-06 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-control-plane-06 >=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 > 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 Mon May 23 06:25:40 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF6012D8B2 for ; Mon, 23 May 2016 06:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 dQQZXtFa77LA for ; Mon, 23 May 2016 06:25:36 -0700 (PDT) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by ietfa.amsl.com (Postfix) with ESMTP id 5B96D12B03A for ; Mon, 23 May 2016 06:25:36 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP; 23 May 2016 06:25:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,355,1459839600"; d="scan'208,217";a="982862791" Received: from irsmsx108.ger.corp.intel.com ([163.33.3.3]) by orsmga002.jf.intel.com with ESMTP; 23 May 2016 06:25:35 -0700 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.198]) by IRSMSX108.ger.corp.intel.com ([169.254.11.33]) with mapi id 14.03.0248.002; Mon, 23 May 2016 14:25:34 +0100 From: "Duarte Cardoso, Igor" To: "sfc@ietf.org" Thread-Topic: Using IETF SFC to fulfill ETSI VNFFG Thread-Index: AdG09PL3ZHn3L/+hTDSWHlx0DNk9gw== Date: Mon, 23 May 2016 13:25:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] Content-Type: multipart/alternative; boundary="_000_E09EC9A2DDB2914E953966C44BEF9CF6D23CF9IRSMSX103gercorpi_" MIME-Version: 1.0 Archived-At: Subject: [sfc] Using IETF SFC to fulfill ETSI VNFFG X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 13:25:38 -0000 --_000_E09EC9A2DDB2914E953966C44BEF9CF6D23CF9IRSMSX103gercorpi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear SFC WG, I have been following the WG's efforts to normalize and standardize the mul= tiple areas and scopes of Service Function Chaining. The concept of SFC Encapsulation, and composing Service Function Paths, is = of particular interest to me. I wonder, however, if anyone has been working on a bigger picture where SFC= , along with the only SFC Encapsulation protocol NSH, can be used in an ET= SI NFV MANO environment, e.g. how can SFC be mapped to VNFs, VNFFGs, NSs, a= nd so forth, and what drawbacks, incompatibilities, workarounds can be foun= d. I'll appreciate any response even slightly related to my thoughts. Best regards, Igor. --_000_E09EC9A2DDB2914E953966C44BEF9CF6D23CF9IRSMSX103gercorpi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear SFC WG,

 

I have been following the WG’s efforts to norm= alize and standardize the multiple areas and scopes of Service Function Cha= ining.

The concept of SFC Encapsulation, and composing Serv= ice Function Paths, is of particular interest to me.

 

I wonder, however, if anyone has been working on a b= igger picture where SFC, along with the only SFC Encapsulation protocol NSH= ,  can be used in an ETSI NFV MANO environment, e.g. how can SFC be ma= pped to VNFs, VNFFGs, NSs, and so forth, and what drawbacks, incompatibilities, workarounds can be found.

 

I’ll appreciate any response even slightly rel= ated to my thoughts.

 

Best regards,=

Igor.

 

--_000_E09EC9A2DDB2914E953966C44BEF9CF6D23CF9IRSMSX103gercorpi_-- From nobody Mon May 23 06:58:30 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80D912D8EA for ; Mon, 23 May 2016 06:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 HY95T1twXZFm for ; Mon, 23 May 2016 06:58:27 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24A5F12D198 for ; Mon, 23 May 2016 06:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5946; q=dns/txt; s=iport; t=1464011907; x=1465221507; h=from:to:subject:date:message-id:mime-version; bh=hX4dmq5hOTDfSNEVS+5QJRaenSO07Ivq7Er8TXNAnJE=; b=amoadeZI421vxotxg+rBweXlWQiXsPDNYjjsBjJlgOoN1AcHhqIa5MOj y/EFbb++xPo6bVFnoUCX4v8kXGcZf1b/xq6IrKZSXJGcoMjbMsV0YDgbH 6ra2Pa1VUs77hT4kENAIt7z9JIuodLGZYkWT/rolRXMkJNKLiXK5/Kmae o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C0AwABDENX/4cNJK0WBEOCbEtWfQa1A?= =?us-ascii?q?YJqgg8BDYF1IoVvgTA4FAEBAQEBAQFlJ4RCAQEFJwZeAQgRAwECKDkUCQoEARK?= =?us-ascii?q?ILw6NB7czAQEBAQEFAQEBAQEBHAWGJ4RNhBBPhToFjh2FGoUAAYV/iCCPHI9LA?= =?us-ascii?q?R4BAUKDbW4BiFF/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,356,1459814400"; d="scan'208,217";a="110083906" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 May 2016 13:58:26 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u4NDwQfK022832 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 23 May 2016 13:58:26 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 23 May 2016 08:58:25 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1104.009; Mon, 23 May 2016 08:58:25 -0500 From: "Jim Guichard (jguichar)" To: "Duarte Cardoso, Igor" , "sfc@ietf.org" Thread-Topic: [sfc] Using IETF SFC to fulfill ETSI VNFFG Thread-Index: AQHRtPssxlkqvxXE/Ey6ngZZlix4Og== Date: Mon, 23 May 2016 13:58:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.28.150] Content-Type: multipart/alternative; boundary="_000_D368849F4FA50jguicharciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Using IETF SFC to fulfill ETSI VNFFG X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 13:58:29 -0000 --_000_D368849F4FA50jguicharciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Igor, You might start looking here -> https://wiki.opnfv.org/display/sfc/Service+= Function+Chaining+Home Jim From: sfc > on behalf of = "Duarte Cardoso, Igor" > Date: Monday, May 23, 2016 at 9:25 AM To: "sfc@ietf.org" > Subject: [sfc] Using IETF SFC to fulfill ETSI VNFFG Dear SFC WG, I have been following the WG's efforts to normalize and standardize the mul= tiple areas and scopes of Service Function Chaining. The concept of SFC Encapsulation, and composing Service Function Paths, is = of particular interest to me. I wonder, however, if anyone has been working on a bigger picture where SFC= , along with the only SFC Encapsulation protocol NSH, can be used in an ET= SI NFV MANO environment, e.g. how can SFC be mapped to VNFs, VNFFGs, NSs, a= nd so forth, and what drawbacks, incompatibilities, workarounds can be foun= d. I'll appreciate any response even slightly related to my thoughts. Best regards, Igor. --_000_D368849F4FA50jguicharciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <237CAD59DF661C4CB9E8B15C8969E7EA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Igor,


Jim

From: sfc <sfc-bounces@ietf.org> on behalf of "Duarte C= ardoso, Igor" <igo= r.duarte.cardoso@intel.com>
Date: Monday, May 23, 2016 at 9:25 = AM
To: "sfc@ietf.org" <sfc@ietf.= org>
Subject: [sfc] Using IETF SFC to fu= lfill ETSI VNFFG

Dear SFC WG,

 

I have been following the WG’s efforts to norm= alize and standardize the multiple areas and scopes of Service Function Cha= ining.

The concept of SFC Encapsulation, and composing Serv= ice Function Paths, is of particular interest to me.

 

I wonder, however, if anyone has been working on a b= igger picture where SFC, along with the only SFC Encapsulation protocol NSH= ,  can be used in an ETSI NFV MANO environment, e.g. how can SFC be ma= pped to VNFs, VNFFGs, NSs, and so forth, and what drawbacks, incompatibilities, workarounds can be found.

 

I’ll appreciate any response even slightly rel= ated to my thoughts.

 

Best regards,=

Igor.

 

 --_000_D368849F4FA50jguicharciscocom_-- From nobody Tue May 24 10:22:50 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92EBE12D92B for ; Tue, 24 May 2016 10:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 tTnhTWKRaJTr for ; Tue, 24 May 2016 10:22:44 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918A812D920 for ; Tue, 24 May 2016 10:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4082; q=dns/txt; s=iport; t=1464110564; x=1465320164; h=from:to:cc:subject:date:message-id:mime-version; bh=S6KISmp8ht+onYexhlOgCtXwewwtqbV17mLdDQ66j0E=; b=avqJ/cW9tGKUmBhOxVmNwXcpbzVZ5tPSwl74GaMWEVCnjfEciN2Lm/a7 8Ut5ALaOZbQ435iJre6p9v4Wb6r132Rugbrava8DBte+Mrj8KvY1ez4mp aZsJ8ba41YHA7QFsOjSQCQJnQU/reQbWW5B53SDKWxNR61lS53q1qoQWo Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7BQDVjERX/5FdJa1cgzdWgQO0f4UHg?= =?us-ascii?q?XYihW8egRc5EwEBAQEBAQFlHAuESSNWEgEMPgIEMCcEDog0DrIhkVsBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEXBYgdhxSDAiuCLgWTN4UAAYEuhFGIII8cj0sBIgI+g?= =?us-ascii?q?22Jdn8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,360,1459814400"; d="scan'208,217";a="276695028" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 May 2016 17:22:43 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u4OHMh64009232 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 24 May 2016 17:22:43 GMT Received: from xch-rtp-011.cisco.com (64.101.220.151) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 24 May 2016 13:22:42 -0400 Received: from xch-rtp-011.cisco.com ([64.101.220.151]) by XCH-RTP-011.cisco.com ([64.101.220.151]) with mapi id 15.00.1104.009; Tue, 24 May 2016 13:22:42 -0400 From: "Eric Wang (ejwang)" To: "sfc@ietf.org" Thread-Topic: What if the SF consumes all the packets? Thread-Index: AQHRteDhhDpGTxui20mcSeoFEXfl7w== Date: Tue, 24 May 2016 17:22:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.155.85.65] Content-Type: multipart/alternative; boundary="_000_F03F0057CADB4EC987ED4DB84464C86Bciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Kent Leung \(kleung\)" Subject: [sfc] What if the SF consumes all the packets? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 17:22:46 -0000 --_000_F03F0057CADB4EC987ED4DB84464C86Bciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gZXZlcnlvbmUsDQoNClNvIGZhciBtb3N0IG9mIHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyBp biB0aGUgU0ZDIGZyYW1ld29yayBmb3J3YXJkIHBhY2tldHMgYmFjayB0byB0aGUgU0ZGLiAgVGhl cmUgaXMgYW5vdGhlciBzZXQgb2YgU0ZzIHRoYXQgcmVjZWl2ZXMgcGFja2V0cyBidXQgZG9lcyBu b3QgZm9yd2FyZCB0aGVtIG91dC4gIEFuYWx5dGljIGZ1bmN0aW9ucyBhbmQgSURTIGFyZSBhIGZl dyBleGFtcGxlcy4gIFRoZXkgYXJlICJwYWNrZXQgc2lua3MiIG9yIOKAnHJlY2VpdmUtb25seeKA nSBTRnMuDQoNClNvbWUgY2hhbGxlbmdlcyBmb3IgdGhvc2UgU0ZzIHRvIG9wZXJhdGUgaW4gU0ZD Og0KDQotIEJlaW5nIHBhcnQgb2YgYW4gU0ZQIC0gVGhleSBhcmUgbWFuYWdlZCBhcyBTRiBmb3Ig c2ltcGxlIGFuZCBjb25zaXN0ZW50IFNGQyBwb2xpY3ksIGJ1dCB0aGV5IGRvIG5vdCBlZ3Jlc3Mg dHJhZmZpYw0KLSBQYWNrZXQgcmVwbGljYXRpb24gLSB0aG9zZSBTRnMgbmVlZCB0byB0YWtlIGEg Y29weSBvZiB0aGUgcGFja2V0cyBzbyB0aGF0IHRoZSBvcmlnaW5hbCBvbmVzIGNvbnRpbnVlIG9u IHRoZSBwYXRoDQotIFNlcnZpY2UgaW5kZXggZGVjcmVtZW50aW5nIC0gcGFja2V0cyDigJxwYXNz aW5n4oCdIHN1Y2ggYW4gU0YgbmVlZCB0byBoYXZlIHRoZWlyIFNJIGRlY3JlbWVudGVkIGJlZm9y ZSByZWFjaGluZyB0aGUgbmV4dCBTRg0KDQpXZSBwdWJsaXNoZWQgYSBkcmFmdCBhdHRlbXB0aW5n IHRvIGFkZHJlc3MgdGhlIG5lZWQgZm9yIHN1cHBvcnRpbmcgdGhpcyBzZXQgb2YgU0ZzLCBhcyBh IGNvbXBsZW1lbnRhcnkgdG8gdGhlIFNGQyBmcmFtZXdvcmsgdG9kYXkuDQpodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtd2FuZy1zZmMtcmVjZWl2ZS1vbmx5LTAwDQoNCldvdWxkIGFw cHJlY2lhdGUgeW91ciBmZWVkYmFjay4NCg0KUmVnYXJkcywNCi1FcmljDQoNCg== --_000_F03F0057CADB4EC987ED4DB84464C86Bciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IZWxsbyBl dmVyeW9uZSw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpTbyBm YXIgbW9zdCBvZiB0aGUgc2VydmljZSBmdW5jdGlvbnMgaW4gdGhlIFNGQyBmcmFtZXdvcmsgZm9y d2FyZCBwYWNrZXRzIGJhY2sgdG8gdGhlIFNGRi4gJm5ic3A7VGhlcmUgaXMgYW5vdGhlciBzZXQg b2YgU0ZzIHRoYXQgcmVjZWl2ZXMgcGFja2V0cyBidXQgZG9lcyBub3QgZm9yd2FyZCB0aGVtIG91 dC4gJm5ic3A7QW5hbHl0aWMgZnVuY3Rpb25zIGFuZCBJRFMgYXJlIGEgZmV3IGV4YW1wbGVzLiAm bmJzcDtUaGV5IGFyZSAmcXVvdDtwYWNrZXQgc2lua3MmcXVvdDsgb3Ig4oCccmVjZWl2ZS1vbmx5 4oCdDQogU0ZzLiAmbmJzcDsNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPlNvbWUgY2hhbGxlbmdlcyBmb3IgdGhvc2UgU0ZzIHRvIG9wZXJhdGUgaW4g U0ZDOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+LSBCZWluZyBwYXJ0IG9mIGFuIFNGUCAtIFRoZXkgYXJlIG1hbmFnZWQgYXMgU0YgZm9y IHNpbXBsZSBhbmQgY29uc2lzdGVudCBTRkMgcG9saWN5LCBidXQgdGhleSBkbyBub3QgZWdyZXNz IHRyYWZmaWM8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LSBQYWNrZXQgcmVwbGljYXRpb24gLSB0aG9z ZSBTRnMgbmVlZCB0byB0YWtlIGEgY29weSBvZiB0aGUgcGFja2V0cyBzbyB0aGF0IHRoZSBvcmln aW5hbCBvbmVzIGNvbnRpbnVlIG9uIHRoZSBwYXRoPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi0gU2Vy dmljZSBpbmRleCBkZWNyZW1lbnRpbmcgLSBwYWNrZXRzIOKAnHBhc3NpbmfigJ0gc3VjaCBhbiBT RiBuZWVkIHRvIGhhdmUgdGhlaXIgU0kgZGVjcmVtZW50ZWQgYmVmb3JlIHJlYWNoaW5nIHRoZSBu ZXh0IFNGPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5XZSBwdWJsaXNoZWQgYSBkcmFmdCBhdHRlbXB0aW5nIHRvIGFkZHJlc3MgdGhlIG5l ZWQgZm9yIHN1cHBvcnRpbmcgdGhpcyBzZXQgb2YgU0ZzLCBhcyBhIGNvbXBsZW1lbnRhcnkgdG8g dGhlIFNGQyBmcmFtZXdvcmsgdG9kYXkuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13YW5nLXNmYy1yZWNlaXZlLW9ubHktMDAi IGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13YW5nLXNmYy1yZWNl aXZlLW9ubHktMDA8L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5Xb3VsZCBhcHByZWNpYXRlIHlvdXIgZmVlZGJhY2suPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5SZWdhcmRz LDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4tRXJpYzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F03F0057CADB4EC987ED4DB84464C86Bciscocom_-- From nobody Thu May 26 11:02:49 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F20F12D80C for ; Thu, 26 May 2016 11:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 CiV83qCNVQYd for ; Thu, 26 May 2016 11:02:43 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::726]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFAA512D80E for ; Thu, 26 May 2016 11:02:42 -0700 (PDT) Received: from TU4PR84MB0159.NAMPRD84.PROD.OUTLOOK.COM (10.162.187.152) by TU4PR84MB0157.NAMPRD84.PROD.OUTLOOK.COM (10.162.187.150) with Microsoft SMTP Server (TLS) id 15.1.501.7; Thu, 26 May 2016 18:02:24 +0000 Received: from TU4PR84MB0159.NAMPRD84.PROD.OUTLOOK.COM ([10.162.187.152]) by TU4PR84MB0159.NAMPRD84.PROD.OUTLOOK.COM ([10.162.187.152]) with mapi id 15.01.0501.015; Thu, 26 May 2016 18:02:24 +0000 From: "Bottorff, Paul" To: Christian Koenning , "sfc@ietf.org" Thread-Topic: Service Path Identifier (SPI) and symmetry Thread-Index: AQHRsHUtFvsY0ydaV0iEs6canF5mkp/Lix3A Date: Thu, 26 May 2016 18:02:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: F5.com; dkim=none (message not signed) header.d=none;F5.com; dmarc=none action=none header.from=hpe.com; x-originating-ip: [104.220.20.125] x-ms-office365-filtering-correlation-id: d8a4a962-b3b1-4f00-24ae-08d3858fe40e x-microsoft-exchange-diagnostics: 1; TU4PR84MB0157; 5:w1Lo0YoPqEnn80AqGXAKr21D13r2gVBFUzVo7N6wsjytEVRZLneX7uxV6gMkle2gYyEz7AkP2okFAYrfc0pg+EC5AeTUq2NNxhPzAL1UTRN3VsrjvpCwiDr0uTERoXaGw4hvP7iIlgGXZDtWy0dAFw==; 24:ZKtZMhVcsAxLnzHanovOU2y1KlFA/BcCjwVrP0oB1upsuOKodpXweZ/4hXSMX90qBsjRtdllSFysNrHFKGytXrXP1eJswnWx9KDtdf4cA9o=; 7:QgQiiuxyilY0ch3rUzdmE6IIDtwWsGNfWOzmjMPqdWVM+zLt5Ey6nqo5RA5VLpQSiyCpNfc4DMAJ7vnK1pHv6D8hg1klO1LpSCOwmL1X0H3eiU0Vc9GmLv6+UsFe7wMixaktbCDNYvfCVvjw2uD09gMc5201kK3pHArbTysrrDUv42Rj6ealqVf3lJl1zmy+ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TU4PR84MB0157; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155)(69137744131126); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:TU4PR84MB0157; BCL:0; PCL:0; RULEID:; SRVR:TU4PR84MB0157; x-forefront-prvs: 0954EE4910 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(66654002)(377454003)(3280700002)(11100500001)(19300405004)(3660700001)(122556002)(2900100001)(10400500002)(86362001)(5004730100002)(15975445007)(77096005)(2950100001)(66066001)(17750500001)(790700001)(102836003)(9686002)(5008740100001)(3846002)(81166006)(586003)(1220700001)(8936002)(8676002)(2906002)(33656002)(50986999)(189998001)(107886002)(19580395003)(19617315012)(19580405001)(2501003)(5002640100001)(5003600100002)(5001770100001)(106116001)(87936001)(19625215002)(76176999)(54356999)(92566002)(99286002)(16236675004); DIR:OUT; SFP:1102; SCL:1; SRVR:TU4PR84MB0157; H:TU4PR84MB0159.NAMPRD84.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_TU4PR84MB015992AAB255B0EA0816AFDFFE410TU4PR84MB0159NAMP_" MIME-Version: 1.0 X-OriginatorOrg: hpe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2016 18:02:24.1696 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: TU4PR84MB0157 Archived-At: Subject: Re: [sfc] Service Path Identifier (SPI) and symmetry X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 18:02:46 -0000 --_000_TU4PR84MB015992AAB255B0EA0816AFDFFE410TU4PR84MB0159NAMP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2hyaXN0aWFuOg0KDQpBIHZlcnkgZ29vZCBxdWVzdGlvbi4NCg0KSU1ITyB0aGUgU1BJIGNh buKAmXQgYmUgYmktZGlyZWN0aW9uYWwgYmVjYXVzZSB0aGUgZm9yd2FyZGluZyBkaXJlY3Rpb24g d291bGQgYmUgYW1iaWd1b3VzIGZvciBzaW5nbGUgYXJtZWQgU0ZzLg0KDQpUaGUgcmV2ZXJzYWwg cHJvYmxlbSBwb2ludHMgb3V0IGEgYmFzaWMgZGVmaWNpZW5jeSBvZiB0aGUgU1BJK1NJIE5TSCBm aWVsZHMuIFRoZXNlIGZpZWxkcyBmb3JtIHRoZSBzZXJ2ZXIgbGF5ZXIgbmV0d29yayBhZGRyZXNz IChub3QgdGhlIHRyYW5zcG9ydCBsYXllciBhZGRyZXNzKS4gV2hhdCB3ZSBsYWNrIGlzIGEgd2F5 IHRvIGVuY29kZSB0aGUgcmV2ZXJzZSBhZGRyZXNzLg0KDQpUaGUgZGlyZWN0IG1ldGhvZCBmb3Ig aGFuZGxpbmcgZm9yd2FyZCBhbmQgYmFja3dhcmQgYWRkcmVzc2luZyBpcyB0byBlbmNvZGUgYm90 aCBhIGZvcndhcmQgYW5kIHJldmVyc2UgcGF0aCBpbiB0aGUgTlNIIGhlYWRlciAoU1BJRi9TUElS KS4gVGhpcyB3b3VsZCBiZSBzaW1pbGFyIHRvIEV0aGVybmV0IERBL1NBIG9yIElQIFNJUC9TSVAu IFN1Y2ggYW4gZW5jb2Rpbmcgd291bGQgYmUgdGhlIG1vc3QgZmxleGlibGUgd2F5IHRvIGJ1aWxk IHRoZSBOU0ggaGVhZGVyLCBob3dldmVyIGZvciBhIG1vcmUgc3BhY2UgZWZmaWNpZW50IG1ldGhv ZCB3aGljaCBvZmZlcnMgdGhlIG1pbmltdW0gbW9kaWZpY2F0aW9uIHRvIHRoZSBleGlzdGluZyBO U0ggZmllbGRzIHdlIGhhdmUgaGFkIHN1Y2Nlc3MgZW5jb2RpbmcgYSByZXZlcnNlIGFkZHJlc3Mg YnkgcmVzZXJ2aW5nIHRoZSBoaWdoIG9yZGVyIGJpdCBvZiB0aGUgU1BJIHRvIGRlc2lnbmF0ZSB0 aGUgcmV2ZXJzZSBhZGRyZXNzLiBTbyBpbiB0aGlzIG1ldGhvZCB0aGUgU1BJRiBhbHdheXMgaGFz IGhpZ2ggb3JkZXIgYml0IDAgYW5kIHRoZSBTUElSIGFsd2F5cyBoYXMgaGlnaCBvcmRlciBiaXQg MS4gQW4gU0Ygb3IgT0FNIHdoaWNoIG5lZWRzIHRvIHNlbmQgYWxvbmcgdGhlIHJldmVyc2UgcGF0 aCBjYW4gYWx3YXlzIGZvcm0gdGhlIHJldmVyc2UgYWRkcmVzcyBieSBmbGlwcGluZyB0aGUgaGln aCBvcmRlciBiaXQgb2YgdGhlIFNQSS4NCg0KQ2hlZXJzLA0KDQpQYXVsDQoNCkZyb206IHNmYyBb bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0aWFuIEtvZW5u aW5nDQpTZW50OiBUdWVzZGF5LCBNYXkgMTcsIDIwMTYgMTI6NDkgUE0NClRvOiBzZmNAaWV0Zi5v cmcNClN1YmplY3Q6IFtzZmNdIFNlcnZpY2UgUGF0aCBJZGVudGlmaWVyIChTUEkpIGFuZCBzeW1t ZXRyeQ0KDQpHb29kIEV2ZW5pbmcsDQoNCmxvb2tpbmcgYXQgUkZDIDc2NjUNClNlcnZpY2UgRnVu Y3Rpb24gQ2hhaW5pbmcgKFNGQykgQXJjaGl0ZWN0dXJlDQpodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNzY2NQ0KDQp0aGVyZSBpcyBhIGNsZWFyIGRlZmluaXRpb24gb2YgY2hhaW4gc3lt ZXRyeQ0KDQoiDQoyLjIuICBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluIFN5bW1ldHJ5DQoNCiAgIFNG Q3MgbWF5IGJlIHVuaWRpcmVjdGlvbmFsIG9yIGJpZGlyZWN0aW9uYWwuICBBIHVuaWRpcmVjdGlv bmFsIFNGQw0KICAgcmVxdWlyZXMgdGhhdCB0cmFmZmljIGJlIGZvcndhcmRlZCB0aHJvdWdoIHRo ZSBvcmRlcmVkIFNGcyBpbiBvbmUNCiAgIGRpcmVjdGlvbiAoc2YxIC0+IHNmMiAtPiBzZjMpLCB3 aGVyZWFzIGEgYmlkaXJlY3Rpb25hbCBTRkMgcmVxdWlyZXMgYQ0KICAgc3ltbWV0cmljIHBhdGgg KHNmMSAtPiBzZjIgLT4gc2YzIGFuZCBzZjMgLT4gc2YyIC0+IHNmMSksIGFuZCBpbg0KICAgd2hp Y2ggdGhlIFNGIGluc3RhbmNlcyBhcmUgdGhlIHNhbWUgaW4gb3Bwb3NpdGUgZGlyZWN0aW9ucy4g IEEgaHlicmlkDQogICBTRkMgaGFzIGF0dHJpYnV0ZXMgb2YgYm90aCB1bmlkaXJlY3Rpb25hbCBh bmQgYmlkaXJlY3Rpb25hbCBTRkNzOw0KICAgdGhhdCBpcyB0byBzYXkgc29tZSBTRnMgcmVxdWly ZSBzeW1tZXRyaWMgdHJhZmZpYywgd2hlcmVhcyBvdGhlciBTRnMNCiAgIGRvIG5vdCBwcm9jZXNz IHJldmVyc2UgdHJhZmZpYyBvciBhcmUgaW5kZXBlbmRlbnQgb2YgdGhlDQogICBjb3JyZXNwb25k aW5nIGZvcndhcmQgdHJhZmZpYy4NCg0KICAgLi4uDQoNCiAgICBGdXJ0aGVyLCB0aGVyZSBhcmUg c3RhdGUgdHJhZGUtb2ZmcyBpbiBzeW1tZXRyeS4gIFN5bW1ldHJ5IG1heSBiZQ0KICAgcmVhbGl6 ZWQgaW4gc2V2ZXJhbCB3YXlzIGRlcGVuZGluZyBvbiB0aGUgU0ZGIGFuZCBjbGFzc2lmaWVyDQog ICBmdW5jdGlvbmFsaXR5LiAgSW4gc29tZSBjYXNlcywgIm1pcnJvcmVkIiBjbGFzc2lmaWNhdGlv biAoaS5lLiwgZnJvbQ0KICAgU291cmNlIHRvIERlc3RpbmF0aW9uIGFuZCBmcm9tIERlc3RpbmF0 aW9uIHRvIFNvdXJjZSkgcG9saWN5IG1heSBiZQ0KICAgZGVwbG95ZWQsIHdoZXJlYXMgaW4gb3Ro ZXJzIHNoYXJlZCBzdGF0ZSBiZXR3ZWVuIGNsYXNzaWZpZXJzIG1heSBiZQ0KICAgdXNlZCB0byBl bnN1cmUgdGhhdCBzeW1tZXRyaWMgZmxvd3MgYXJlIGNvcnJlY3RseSBpZGVudGlmaWVkLCB0aGVu DQogICBzdGVlcmVkIGFsb25nIHRoZSByZXF1aXJlZCBTRlAuICBBdCBhIGhpZ2ggbGV2ZWwsIHRo ZXJlIGFyZSB2YXJpb3VzDQogICBjb21tb24gY2FzZXMuICBJbiBhIG5vbi1leGhhdXN0aXZlIHdh eSwgdGhlcmUgY2FuIGJlIGZvciBleGFtcGxlOg0KDQogICBvICBBIHNpbmdsZSBjbGFzc2lmaWVy IChvciBhIHNtYWxsIG51bWJlciBvZiBjbGFzc2lmaWVycyksIGluIHdoaWNoDQogICAgICBjYXNl IGJvdGggaW5jb21pbmcgYW5kIG91dGdvaW5nIGZsb3dzIGNvdWxkIGJlIHJlY29nbml6ZWQgYXQg dGhlDQogICAgICBzYW1lIGNsYXNzaWZpZXIsIHNvIHRoZSBzeW5jaHJvbml6YXRpb24gd291bGQg YmUgZmVhc2libGUgYnkNCiAgICAgIGludGVybmFsIG1lY2hhbmlzbXMgaW50ZXJuYWwgdG8gdGhl IGNsYXNzaWZpZXIuDQoNCiAgIG8gIFN0YXRlZnVsIGNsYXNzaWZpZXJzIHdoZXJlIHNldmVyYWwg Y2xhc3NpZmllcnMgbWF5IGJlIGNsdXN0ZXJlZA0KICAgICAgYW5kIHNoYXJlIHN0YXRlLg0KDQog ICBvICBGdWxseSBkaXN0cmlidXRlZCBjbGFzc2lmaWVycywgd2hlcmUgc3luY2hyb25pemF0aW9u IG5lZWRzIHRvIGJlDQogICAgICBwcm92aWRlZCB0aHJvdWdoIHVuc3BlY2lmaWVkIG1lYW5zLg0K DQogICBvICBBIGNsYXNzaWZpZXIgdGhhdCBsZWFybnMgc3RhdGUgZnJvbSB0aGUgZWdyZXNzIHBh Y2tldHMvZmxvd3MgdGhhdA0KICAgICAgaXMgdGhlbiB1c2VkIHRvIHByb3ZpZGUgc3RhdGUgZm9y IHRoZSByZXR1cm4gcGFja2V0cy9mbG93Lg0KDQogICBvICBTeW1tZXRyeSBtYXkgYWxzbyBiZSBw cm92aWRlZCBieSBzdGF0ZWZ1bCBmb3J3YXJkaW5nIGxvZ2ljIGluIHRoZQ0KICAgICAgU0ZGIGlu IHNvbWUgaW1wbGVtZW50YXRpb25zLg0KDQogICBUaGlzIGlzIGEgbm9uLWNvbXByZWhlbnNpdmUg bGlzdCBvZiBjb21tb24gY2FzZXMuICINCg0KDQpIb3dldmVyLCB3aGVuIGxvb2tpbmcgYXQgdGhp cyB0b2dldGhlciB3aXRoDQpOZXR3b3JrIFNlcnZpY2UgSGVhZGVyDQpkcmFmdC1pZXRmLXNmYy1u c2gtMDQudHh0DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zZmMtbnNo LTA0DQoNCjMuMy4gIFNlcnZpY2UgUGF0aCBIZWFkZXINCg0KIg0KICAgU2VydmljZSBQYXRoIElk ZW50aWZpZXIgKFNQSSk6IGlkZW50aWZpZXMgYSBzZXJ2aWNlIHBhdGguDQogICBQYXJ0aWNpcGF0 aW5nIG5vZGVzIE1VU1QgdXNlIHRoaXMgaWRlbnRpZmllciBmb3IgU2VydmljZSBGdW5jdGlvbg0K ICAgUGF0aCBzZWxlY3Rpb24uDQoiDQoNCnRoZXJlIGlzIG5vIG5vdGlvbiBvZiBzeW1tZXRyeS4N Cg0KDQpDYW4geW91IHBsZWFzZSBjb25maXJtIHRoYXQgYSBiaWRpcmVjdGlvbmFsIFNlcnZpY2Ug RnVuY3Rpb24gQ2hhaW4NCndpbGwgYmUgcmVwcmVzZW50ZWQgYnkgb25lIHNpbmdsZSBTZXJ2aWNl IFBhdGggSWRlbnRpZmllciwgaW5ncmVzcyBzeW1tZXRyaWMgdG8gZWdyZXNzID8NCg0KDQpQbGVh c2UgYWxsb3cgdXMgdG8gY2xhcmlmeSB0aGlzLg0KDQpNYW55IFRoYW5rcw0KDQpDaHJpc3RpYW4g S29lbm5pbmcNCi0tDQpGNSBOZXR3b3JrcyBJbmMuDQpjaHJpc3RpYW5AZjUuY29tPG1haWx0bzpj aHJpc3RpYW5AZjUuY29tPg0KDQo= --_000_TU4PR84MB015992AAB255B0EA0816AFDFFE410TU4PR84MB0159NAMP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBDaHJpc3RpYW46PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BIHZlcnkgZ29vZCBxdWVzdGlvbi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklNSE8gdGhlIFNQSSBjYW7igJl0IGJlIGJp LWRpcmVjdGlvbmFsIGJlY2F1c2UgdGhlIGZvcndhcmRpbmcgZGlyZWN0aW9uIHdvdWxkIGJlIGFt YmlndW91cyBmb3Igc2luZ2xlIGFybWVkIFNGcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PGJyPg0KVGhl IHJldmVyc2FsIHByb2JsZW0gcG9pbnRzIG91dCBhIGJhc2ljIGRlZmljaWVuY3kgb2YgdGhlIFNQ SSYjNDM7U0kgTlNIIGZpZWxkcy4gVGhlc2UgZmllbGRzIGZvcm0gdGhlIHNlcnZlciBsYXllciBu ZXR3b3JrIGFkZHJlc3MgKG5vdCB0aGUgdHJhbnNwb3J0IGxheWVyIGFkZHJlc3MpLiBXaGF0IHdl IGxhY2sgaXMgYSB3YXkgdG8gZW5jb2RlIHRoZSByZXZlcnNlIGFkZHJlc3MuDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBkaXJlY3QgbWV0aG9kIGZvciBo YW5kbGluZyBmb3J3YXJkIGFuZCBiYWNrd2FyZCBhZGRyZXNzaW5nIGlzIHRvIGVuY29kZSBib3Ro IGEgZm9yd2FyZCBhbmQgcmV2ZXJzZSBwYXRoIGluIHRoZSBOU0ggaGVhZGVyIChTUElGL1NQSVIp LiBUaGlzIHdvdWxkIGJlIHNpbWlsYXINCiB0byBFdGhlcm5ldCBEQS9TQSBvciBJUCBTSVAvU0lQ LiBTdWNoIGFuIGVuY29kaW5nIHdvdWxkIGJlIHRoZSBtb3N0IGZsZXhpYmxlIHdheSB0byBidWls ZCB0aGUgTlNIIGhlYWRlciwgaG93ZXZlciBmb3IgYSBtb3JlIHNwYWNlIGVmZmljaWVudCBtZXRo b2Qgd2hpY2ggb2ZmZXJzIHRoZSBtaW5pbXVtIG1vZGlmaWNhdGlvbiB0byB0aGUgZXhpc3Rpbmcg TlNIIGZpZWxkcyB3ZSBoYXZlIGhhZCBzdWNjZXNzIGVuY29kaW5nIGEgcmV2ZXJzZSBhZGRyZXNz DQogYnkgcmVzZXJ2aW5nIHRoZSBoaWdoIG9yZGVyIGJpdCBvZiB0aGUgU1BJIHRvIGRlc2lnbmF0 ZSB0aGUgcmV2ZXJzZSBhZGRyZXNzLiBTbyBpbiB0aGlzIG1ldGhvZCB0aGUgU1BJRiBhbHdheXMg aGFzIGhpZ2ggb3JkZXIgYml0IDAgYW5kIHRoZSBTUElSIGFsd2F5cyBoYXMgaGlnaCBvcmRlciBi aXQgMS4gQW4gU0Ygb3IgT0FNIHdoaWNoIG5lZWRzIHRvIHNlbmQgYWxvbmcgdGhlIHJldmVyc2Ug cGF0aCBjYW4gYWx3YXlzIGZvcm0gdGhlIHJldmVyc2UNCiBhZGRyZXNzIGJ5IGZsaXBwaW5nIHRo ZSBoaWdoIG9yZGVyIGJpdCBvZiB0aGUgU1BJLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48YnI+DQpQYXVsICZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gc2ZjIFttYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkNocmlzdGlhbiBLb2Vu bmluZzxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBNYXkgMTcsIDIwMTYgMTI6NDkgUE08YnI+ DQo8Yj5Ubzo8L2I+IHNmY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbc2ZjXSBTZXJ2 aWNlIFBhdGggSWRlbnRpZmllciAoU1BJKSBhbmQgc3ltbWV0cnk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Hb29kIEV2ZW5pbmcsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPmxv b2tpbmcgYXQgUkZDIDc2NjUmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlNl cnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgKFNGQykgQXJjaGl0ZWN0dXJlPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NzY2NSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc2NjU8L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PnRoZXJlIGlzIGEgY2xlYXIgZGVmaW5pdGlvbiBvZiBjaGFpbiBzeW1ldHJ5PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Mi4yLiAmbmJzcDtTZXJ2aWNl IEZ1bmN0aW9uIENoYWluIFN5bW1ldHJ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDtTRkNzIG1h eSBiZSB1bmlkaXJlY3Rpb25hbCBvciBiaWRpcmVjdGlvbmFsLiAmbmJzcDtBIHVuaWRpcmVjdGlv bmFsIFNGQzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO3JlcXVp cmVzIHRoYXQgdHJhZmZpYyBiZSBmb3J3YXJkZWQgdGhyb3VnaCB0aGUgb3JkZXJlZCBTRnMgaW4g b25lPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ZGlyZWN0aW9u IChzZjEgLSZndDsgc2YyIC0mZ3Q7IHNmMyksIHdoZXJlYXMgYSBiaWRpcmVjdGlvbmFsIFNGQyBy ZXF1aXJlcyBhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7c3lt bWV0cmljIHBhdGggKHNmMSAtJmd0OyBzZjIgLSZndDsgc2YzIGFuZCBzZjMgLSZndDsgc2YyIC0m Z3Q7IHNmMSksIGFuZCBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7ICZu YnNwO3doaWNoIHRoZSBTRiBpbnN0YW5jZXMgYXJlIHRoZSBzYW1lIGluIG9wcG9zaXRlIGRpcmVj dGlvbnMuICZuYnNwO0EgaHlicmlkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJz cDsgJm5ic3A7U0ZDIGhhcyBhdHRyaWJ1dGVzIG9mIGJvdGggdW5pZGlyZWN0aW9uYWwgYW5kIGJp ZGlyZWN0aW9uYWwgU0ZDczs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyAm bmJzcDt0aGF0IGlzIHRvIHNheSBzb21lIFNGcyByZXF1aXJlIHN5bW1ldHJpYyB0cmFmZmljLCB3 aGVyZWFzIG90aGVyIFNGczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7ICZu YnNwO2RvIG5vdCBwcm9jZXNzIHJldmVyc2UgdHJhZmZpYyBvciBhcmUgaW5kZXBlbmRlbnQgb2Yg dGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7Y29ycmVzcG9u ZGluZyBmb3J3YXJkIHRyYWZmaWMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJz cDsgJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7Li4u PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7IEZ1cnRoZXIsIHRoZXJlIGFyZSBzdGF0 ZSB0cmFkZS1vZmZzIGluIHN5bW1ldHJ5LiAmbmJzcDtTeW1tZXRyeSBtYXkgYmU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDtyZWFsaXplZCBpbiBzZXZlcmFsIHdh eXMgZGVwZW5kaW5nIG9uIHRoZSBTRkYgYW5kIGNsYXNzaWZpZXI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDtmdW5jdGlvbmFsaXR5LiAmbmJzcDtJbiBzb21lIGNh c2VzLCAmcXVvdDttaXJyb3JlZCZxdW90OyBjbGFzc2lmaWNhdGlvbiAoaS5lLiwgZnJvbTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO1NvdXJjZSB0byBEZXN0aW5h dGlvbiBhbmQgZnJvbSBEZXN0aW5hdGlvbiB0byBTb3VyY2UpIHBvbGljeSBtYXkgYmU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDtkZXBsb3llZCwgd2hlcmVhcyBp biBvdGhlcnMgc2hhcmVkIHN0YXRlIGJldHdlZW4gY2xhc3NpZmllcnMgbWF5IGJlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7dXNlZCB0byBlbnN1cmUgdGhhdCBz eW1tZXRyaWMgZmxvd3MgYXJlIGNvcnJlY3RseSBpZGVudGlmaWVkLCB0aGVuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7c3RlZXJlZCBhbG9uZyB0aGUgcmVxdWly ZWQgU0ZQLiAmbmJzcDtBdCBhIGhpZ2ggbGV2ZWwsIHRoZXJlIGFyZSB2YXJpb3VzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7Y29tbW9uIGNhc2VzLiAmbmJzcDtJ biBhIG5vbi1leGhhdXN0aXZlIHdheSwgdGhlcmUgY2FuIGJlIGZvciBleGFtcGxlOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj4mbmJzcDsgJm5ic3A7byAmbmJzcDtBIHNpbmdsZSBjbGFzc2lmaWVyIChvciBhIHNtYWxs IG51bWJlciBvZiBjbGFzc2lmaWVycyksIGluIHdoaWNoPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBjYXNlIGJvdGggaW5jb21pbmcgYW5kIG91dGdv aW5nIGZsb3dzIGNvdWxkIGJlIHJlY29nbml6ZWQgYXQgdGhlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBzYW1lIGNsYXNzaWZpZXIsIHNvIHRoZSBz eW5jaHJvbml6YXRpb24gd291bGQgYmUgZmVhc2libGUgYnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7IGludGVybmFsIG1lY2hhbmlzbXMgaW50ZXJu YWwgdG8gdGhlIGNsYXNzaWZpZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDtvICZuYnNwO1N0 YXRlZnVsIGNsYXNzaWZpZXJzIHdoZXJlIHNldmVyYWwgY2xhc3NpZmllcnMgbWF5IGJlIGNsdXN0 ZXJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg YW5kIHNoYXJlIHN0YXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7byAmbmJzcDtGdWxseSBk aXN0cmlidXRlZCBjbGFzc2lmaWVycywgd2hlcmUgc3luY2hyb25pemF0aW9uIG5lZWRzIHRvIGJl PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBwcm92 aWRlZCB0aHJvdWdoIHVuc3BlY2lmaWVkIG1lYW5zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7 byAmbmJzcDtBIGNsYXNzaWZpZXIgdGhhdCBsZWFybnMgc3RhdGUgZnJvbSB0aGUgZWdyZXNzIHBh Y2tldHMvZmxvd3MgdGhhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgaXMgdGhlbiB1c2VkIHRvIHByb3ZpZGUgc3RhdGUgZm9yIHRoZSByZXR1cm4g cGFja2V0cy9mbG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7byAmbmJzcDtTeW1tZXRyeSBt YXkgYWxzbyBiZSBwcm92aWRlZCBieSBzdGF0ZWZ1bCBmb3J3YXJkaW5nIGxvZ2ljIGluIHRoZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgU0ZGIGlu IHNvbWUgaW1wbGVtZW50YXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7VGhpcyBpcyBh IG5vbi1jb21wcmVoZW5zaXZlIGxpc3Qgb2YgY29tbW9uIGNhc2VzLiAmcXVvdDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SG93ZXZlciwg d2hlbiBsb29raW5nIGF0IHRoaXMgdG9nZXRoZXIgd2l0aCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+TmV0d29yayBTZXJ2aWNlIEhlYWRlcjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+ZHJhZnQtaWV0Zi1zZmMtbnNoLTA0LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtc2ZjLW5zaC0wNCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2Zj LW5zaC0wNDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+My4zLiAmbmJzcDtTZXJ2aWNlIFBhdGggSGVhZGVyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7ICZu YnNwO1NlcnZpY2UgUGF0aCBJZGVudGlmaWVyIChTUEkpOiBpZGVudGlmaWVzIGEgc2VydmljZSBw YXRoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO1BhcnRpY2lw YXRpbmcgbm9kZXMgTVVTVCB1c2UgdGhpcyBpZGVudGlmaWVyIGZvciBTZXJ2aWNlIEZ1bmN0aW9u PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7UGF0aCBzZWxlY3Rp b24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+dGhl cmUgaXMgbm8gbm90aW9uIG9mIHN5bW1ldHJ5LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkNhbiB5b3UgcGxlYXNlIGNvbmZpcm0gdGhhdCBh IGJpZGlyZWN0aW9uYWwgU2VydmljZSBGdW5jdGlvbiBDaGFpbiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+d2lsbCBiZSByZXByZXNlbnRlZCBieSBvbmUgc2luZ2xlIFNlcnZp Y2UgUGF0aCBJZGVudGlmaWVyLCBpbmdyZXNzIHN5bW1ldHJpYyB0byBlZ3Jlc3MgPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlBsZWFzZSBhbGxvdyB1 cyB0byBjbGFyaWZ5IHRoaXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk1hbnkgVGhhbmtzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkNo cmlzdGlhbiBLb2VubmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+LS08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkY1IE5ldHdvcmtzIEluYy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpjaHJpc3RpYW5AZjUuY29tIj5jaHJpc3Rp YW5AZjUuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_TU4PR84MB015992AAB255B0EA0816AFDFFE410TU4PR84MB0159NAMP_-- From nobody Thu May 26 11:49:02 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED55612D899 for ; Thu, 26 May 2016 11:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 o3ZlqMSTQsNV for ; Thu, 26 May 2016 11:48:59 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93C6C12DAA9 for ; Thu, 26 May 2016 11:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38252; q=dns/txt; s=iport; t=1464288370; x=1465497970; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=w5DgzXgWq/u08jeGa+dVvugzlqwW166qDD63ZgsD9aY=; b=Ka3rKCqeNLI4ynHr/gx2IZMe0azD4H8pUl8iyTzbleA7ZeyVHksCVQ/V 3gyKGido2AeIeLz8q1QYLimnUe9FGjVe2iKSywXTn+MfkjgsGp7u3km2l 0qs4cGQqi4fEWYav0lFq1HlfkjeY/TewMk3V3tO+QMx8KkMbjy6Susta6 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BPAgA7REdX/4cNJK1cgmxNVn0Ggz22J?= =?us-ascii?q?gENgXgihW8CHIEdOBQBAQEBAQEBZSeEQwEBAQQjBAZcAgEIEQEDAQEhAQYDAgI?= =?us-ascii?q?CMBQDBggCBAESCIgnDrITkWIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYpzhCkkC?= =?us-ascii?q?R+CS4JZBY1lhVKFAAGFf4J4hSGBcIRPiGSPSwEeAQFCg21uiRZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,369,1459814400"; d="scan'208,217";a="112286029" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 May 2016 18:46:09 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u4QIk9vJ001262 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 26 May 2016 18:46:09 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 26 May 2016 13:46:09 -0500 Received: from xch-rcd-020.cisco.com ([173.37.102.30]) by XCH-RCD-020.cisco.com ([173.37.102.30]) with mapi id 15.00.1104.009; Thu, 26 May 2016 13:46:08 -0500 From: "Surendra Kumar (smkumar)" To: "Bottorff, Paul" , Christian Koenning , "sfc@ietf.org" Thread-Topic: Service Path Identifier (SPI) and symmetry Thread-Index: AQHRsHUtFvsY0ydaV0iEs6canF5mkp/Lix3AgAAP+0A= Date: Thu, 26 May 2016 18:46:08 +0000 Message-ID: <1a80281212814b3fb29a9bb9092567b5@XCH-RCD-020.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.155.34.80] Content-Type: multipart/alternative; boundary="_000_1a80281212814b3fb29a9bb9092567b5XCHRCD020ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Service Path Identifier (SPI) and symmetry X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 18:49:01 -0000 --_000_1a80281212814b3fb29a9bb9092567b5XCHRCD020ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGF1bCwNCg0KSW4gZ2VuZXJhbCBJIGNhbiBzZWUgaG93IGhhdmluZyB0d28gU2VydmljZSBo ZWFkZXJzIG1heSBoZWxwLg0KSW4gcHJhY3RpY2UgaG93ZXZlciwgYSBzaW5nbGUgb25lIHdpdGgg aGlnaC1vcmRlciBiaXQgZGlmZmVyZW50aWF0aW5nIHRoZSBmb3J3YXJkL3JldmVyc2UgbmFtZSBz cGFjZSB3b3JrcyB3ZWxsIHdoZXJlIGJpLWRpcmVjdGlvbmFsIGJlaGF2aW9yIGlzIG5lZWRlZCBh bmQgaGFzIGZvciB1cy4gSSBzdXBwb3J0IHVzaW5nIHRoZSBoaWdoLW9yZGVyIGJpdCBhcyBhbiBp bXBsZW1lbnRhdGlvbiBkZXRhaWwuDQoNCk9uZSBvcHRpb24gd2l0aCBNRC1UWVBFMiBtYXkgYmUg dG8gdXNlIFRMVnMgdG8gY2FycnkgdGhlIG90aGVyIHNlcnZpY2UtaGVhZGVyLCB0aGF0IGFjaGll dmVzIHRoZSBkZXNpcmVkIGVmZmVjdCB3aGlsZSBub3QgdGF4aW5nIGFsbCBpbXBsZW1lbnRhdGlv bnMuDQoNClN1cmVuZHJhLg0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEJvdHRvcmZmLCBQYXVsDQpTZW50OiBUaHVyc2RheSwgTWF5IDI2LCAy MDE2IDExOjAyIEFNDQpUbzogQ2hyaXN0aWFuIEtvZW5uaW5nIDxDLktvZW5uaW5nQEY1LmNvbT47 IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgUGF0aCBJZGVudGlmaWVy IChTUEkpIGFuZCBzeW1tZXRyeQ0KDQpIaSBDaHJpc3RpYW46DQoNCkEgdmVyeSBnb29kIHF1ZXN0 aW9uLg0KDQpJTUhPIHRoZSBTUEkgY2Fu4oCZdCBiZSBiaS1kaXJlY3Rpb25hbCBiZWNhdXNlIHRo ZSBmb3J3YXJkaW5nIGRpcmVjdGlvbiB3b3VsZCBiZSBhbWJpZ3VvdXMgZm9yIHNpbmdsZSBhcm1l ZCBTRnMuDQoNClRoZSByZXZlcnNhbCBwcm9ibGVtIHBvaW50cyBvdXQgYSBiYXNpYyBkZWZpY2ll bmN5IG9mIHRoZSBTUEkrU0kgTlNIIGZpZWxkcy4gVGhlc2UgZmllbGRzIGZvcm0gdGhlIHNlcnZl ciBsYXllciBuZXR3b3JrIGFkZHJlc3MgKG5vdCB0aGUgdHJhbnNwb3J0IGxheWVyIGFkZHJlc3Mp LiBXaGF0IHdlIGxhY2sgaXMgYSB3YXkgdG8gZW5jb2RlIHRoZSByZXZlcnNlIGFkZHJlc3MuDQoN ClRoZSBkaXJlY3QgbWV0aG9kIGZvciBoYW5kbGluZyBmb3J3YXJkIGFuZCBiYWNrd2FyZCBhZGRy ZXNzaW5nIGlzIHRvIGVuY29kZSBib3RoIGEgZm9yd2FyZCBhbmQgcmV2ZXJzZSBwYXRoIGluIHRo ZSBOU0ggaGVhZGVyIChTUElGL1NQSVIpLiBUaGlzIHdvdWxkIGJlIHNpbWlsYXIgdG8gRXRoZXJu ZXQgREEvU0Egb3IgSVAgU0lQL1NJUC4gU3VjaCBhbiBlbmNvZGluZyB3b3VsZCBiZSB0aGUgbW9z dCBmbGV4aWJsZSB3YXkgdG8gYnVpbGQgdGhlIE5TSCBoZWFkZXIsIGhvd2V2ZXIgZm9yIGEgbW9y ZSBzcGFjZSBlZmZpY2llbnQgbWV0aG9kIHdoaWNoIG9mZmVycyB0aGUgbWluaW11bSBtb2RpZmlj YXRpb24gdG8gdGhlIGV4aXN0aW5nIE5TSCBmaWVsZHMgd2UgaGF2ZSBoYWQgc3VjY2VzcyBlbmNv ZGluZyBhIHJldmVyc2UgYWRkcmVzcyBieSByZXNlcnZpbmcgdGhlIGhpZ2ggb3JkZXIgYml0IG9m IHRoZSBTUEkgdG8gZGVzaWduYXRlIHRoZSByZXZlcnNlIGFkZHJlc3MuIFNvIGluIHRoaXMgbWV0 aG9kIHRoZSBTUElGIGFsd2F5cyBoYXMgaGlnaCBvcmRlciBiaXQgMCBhbmQgdGhlIFNQSVIgYWx3 YXlzIGhhcyBoaWdoIG9yZGVyIGJpdCAxLiBBbiBTRiBvciBPQU0gd2hpY2ggbmVlZHMgdG8gc2Vu ZCBhbG9uZyB0aGUgcmV2ZXJzZSBwYXRoIGNhbiBhbHdheXMgZm9ybSB0aGUgcmV2ZXJzZSBhZGRy ZXNzIGJ5IGZsaXBwaW5nIHRoZSBoaWdoIG9yZGVyIGJpdCBvZiB0aGUgU1BJLg0KDQpDaGVlcnMs DQoNClBhdWwNCg0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBDaHJpc3RpYW4gS29lbm5pbmcNClNlbnQ6IFR1ZXNkYXksIE1heSAxNywgMjAxNiAx Mjo0OSBQTQ0KVG86IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDog W3NmY10gU2VydmljZSBQYXRoIElkZW50aWZpZXIgKFNQSSkgYW5kIHN5bW1ldHJ5DQoNCkdvb2Qg RXZlbmluZywNCg0KbG9va2luZyBhdCBSRkMgNzY2NQ0KU2VydmljZSBGdW5jdGlvbiBDaGFpbmlu ZyAoU0ZDKSBBcmNoaXRlY3R1cmUNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NjY1 DQoNCnRoZXJlIGlzIGEgY2xlYXIgZGVmaW5pdGlvbiBvZiBjaGFpbiBzeW1ldHJ5DQoNCiINCjIu Mi4gIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW4gU3ltbWV0cnkNCg0KICAgU0ZDcyBtYXkgYmUgdW5p ZGlyZWN0aW9uYWwgb3IgYmlkaXJlY3Rpb25hbC4gIEEgdW5pZGlyZWN0aW9uYWwgU0ZDDQogICBy ZXF1aXJlcyB0aGF0IHRyYWZmaWMgYmUgZm9yd2FyZGVkIHRocm91Z2ggdGhlIG9yZGVyZWQgU0Zz IGluIG9uZQ0KICAgZGlyZWN0aW9uIChzZjEgLT4gc2YyIC0+IHNmMyksIHdoZXJlYXMgYSBiaWRp cmVjdGlvbmFsIFNGQyByZXF1aXJlcyBhDQogICBzeW1tZXRyaWMgcGF0aCAoc2YxIC0+IHNmMiAt PiBzZjMgYW5kIHNmMyAtPiBzZjIgLT4gc2YxKSwgYW5kIGluDQogICB3aGljaCB0aGUgU0YgaW5z dGFuY2VzIGFyZSB0aGUgc2FtZSBpbiBvcHBvc2l0ZSBkaXJlY3Rpb25zLiAgQSBoeWJyaWQNCiAg IFNGQyBoYXMgYXR0cmlidXRlcyBvZiBib3RoIHVuaWRpcmVjdGlvbmFsIGFuZCBiaWRpcmVjdGlv bmFsIFNGQ3M7DQogICB0aGF0IGlzIHRvIHNheSBzb21lIFNGcyByZXF1aXJlIHN5bW1ldHJpYyB0 cmFmZmljLCB3aGVyZWFzIG90aGVyIFNGcw0KICAgZG8gbm90IHByb2Nlc3MgcmV2ZXJzZSB0cmFm ZmljIG9yIGFyZSBpbmRlcGVuZGVudCBvZiB0aGUNCiAgIGNvcnJlc3BvbmRpbmcgZm9yd2FyZCB0 cmFmZmljLg0KDQogICAuLi4NCg0KICAgIEZ1cnRoZXIsIHRoZXJlIGFyZSBzdGF0ZSB0cmFkZS1v ZmZzIGluIHN5bW1ldHJ5LiAgU3ltbWV0cnkgbWF5IGJlDQogICByZWFsaXplZCBpbiBzZXZlcmFs IHdheXMgZGVwZW5kaW5nIG9uIHRoZSBTRkYgYW5kIGNsYXNzaWZpZXINCiAgIGZ1bmN0aW9uYWxp dHkuICBJbiBzb21lIGNhc2VzLCAibWlycm9yZWQiIGNsYXNzaWZpY2F0aW9uIChpLmUuLCBmcm9t DQogICBTb3VyY2UgdG8gRGVzdGluYXRpb24gYW5kIGZyb20gRGVzdGluYXRpb24gdG8gU291cmNl KSBwb2xpY3kgbWF5IGJlDQogICBkZXBsb3llZCwgd2hlcmVhcyBpbiBvdGhlcnMgc2hhcmVkIHN0 YXRlIGJldHdlZW4gY2xhc3NpZmllcnMgbWF5IGJlDQogICB1c2VkIHRvIGVuc3VyZSB0aGF0IHN5 bW1ldHJpYyBmbG93cyBhcmUgY29ycmVjdGx5IGlkZW50aWZpZWQsIHRoZW4NCiAgIHN0ZWVyZWQg YWxvbmcgdGhlIHJlcXVpcmVkIFNGUC4gIEF0IGEgaGlnaCBsZXZlbCwgdGhlcmUgYXJlIHZhcmlv dXMNCiAgIGNvbW1vbiBjYXNlcy4gIEluIGEgbm9uLWV4aGF1c3RpdmUgd2F5LCB0aGVyZSBjYW4g YmUgZm9yIGV4YW1wbGU6DQoNCiAgIG8gIEEgc2luZ2xlIGNsYXNzaWZpZXIgKG9yIGEgc21hbGwg bnVtYmVyIG9mIGNsYXNzaWZpZXJzKSwgaW4gd2hpY2gNCiAgICAgIGNhc2UgYm90aCBpbmNvbWlu ZyBhbmQgb3V0Z29pbmcgZmxvd3MgY291bGQgYmUgcmVjb2duaXplZCBhdCB0aGUNCiAgICAgIHNh bWUgY2xhc3NpZmllciwgc28gdGhlIHN5bmNocm9uaXphdGlvbiB3b3VsZCBiZSBmZWFzaWJsZSBi eQ0KICAgICAgaW50ZXJuYWwgbWVjaGFuaXNtcyBpbnRlcm5hbCB0byB0aGUgY2xhc3NpZmllci4N Cg0KICAgbyAgU3RhdGVmdWwgY2xhc3NpZmllcnMgd2hlcmUgc2V2ZXJhbCBjbGFzc2lmaWVycyBt YXkgYmUgY2x1c3RlcmVkDQogICAgICBhbmQgc2hhcmUgc3RhdGUuDQoNCiAgIG8gIEZ1bGx5IGRp c3RyaWJ1dGVkIGNsYXNzaWZpZXJzLCB3aGVyZSBzeW5jaHJvbml6YXRpb24gbmVlZHMgdG8gYmUN CiAgICAgIHByb3ZpZGVkIHRocm91Z2ggdW5zcGVjaWZpZWQgbWVhbnMuDQoNCiAgIG8gIEEgY2xh c3NpZmllciB0aGF0IGxlYXJucyBzdGF0ZSBmcm9tIHRoZSBlZ3Jlc3MgcGFja2V0cy9mbG93cyB0 aGF0DQogICAgICBpcyB0aGVuIHVzZWQgdG8gcHJvdmlkZSBzdGF0ZSBmb3IgdGhlIHJldHVybiBw YWNrZXRzL2Zsb3cuDQoNCiAgIG8gIFN5bW1ldHJ5IG1heSBhbHNvIGJlIHByb3ZpZGVkIGJ5IHN0 YXRlZnVsIGZvcndhcmRpbmcgbG9naWMgaW4gdGhlDQogICAgICBTRkYgaW4gc29tZSBpbXBsZW1l bnRhdGlvbnMuDQoNCiAgIFRoaXMgaXMgYSBub24tY29tcHJlaGVuc2l2ZSBsaXN0IG9mIGNvbW1v biBjYXNlcy4gIg0KDQoNCkhvd2V2ZXIsIHdoZW4gbG9va2luZyBhdCB0aGlzIHRvZ2V0aGVyIHdp dGgNCk5ldHdvcmsgU2VydmljZSBIZWFkZXINCmRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQNCmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNmYy1uc2gtMDQNCg0KMy4zLiAg U2VydmljZSBQYXRoIEhlYWRlcg0KDQoiDQogICBTZXJ2aWNlIFBhdGggSWRlbnRpZmllciAoU1BJ KTogaWRlbnRpZmllcyBhIHNlcnZpY2UgcGF0aC4NCiAgIFBhcnRpY2lwYXRpbmcgbm9kZXMgTVVT VCB1c2UgdGhpcyBpZGVudGlmaWVyIGZvciBTZXJ2aWNlIEZ1bmN0aW9uDQogICBQYXRoIHNlbGVj dGlvbi4NCiINCg0KdGhlcmUgaXMgbm8gbm90aW9uIG9mIHN5bW1ldHJ5Lg0KDQoNCkNhbiB5b3Ug cGxlYXNlIGNvbmZpcm0gdGhhdCBhIGJpZGlyZWN0aW9uYWwgU2VydmljZSBGdW5jdGlvbiBDaGFp bg0Kd2lsbCBiZSByZXByZXNlbnRlZCBieSBvbmUgc2luZ2xlIFNlcnZpY2UgUGF0aCBJZGVudGlm aWVyLCBpbmdyZXNzIHN5bW1ldHJpYyB0byBlZ3Jlc3MgPw0KDQoNClBsZWFzZSBhbGxvdyB1cyB0 byBjbGFyaWZ5IHRoaXMuDQoNCk1hbnkgVGhhbmtzDQoNCkNocmlzdGlhbiBLb2VubmluZw0KLS0N CkY1IE5ldHdvcmtzIEluYy4NCmNocmlzdGlhbkBmNS5jb208bWFpbHRvOmNocmlzdGlhbkBmNS5j b20+DQoNCg== --_000_1a80281212814b3fb29a9bb9092567b5XCHRCD020ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYW5kYXJhOw0KCXBhbm9zZS0xOjIgMTQg NSAyIDMgMyAzIDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbmRh cmEiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDsNCglmb250LXdlaWdodDpub3JtYWw7 DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYW5kYXJhJnF1b3Q7LHNhbnMtc2VyaWYiPkhp IFBhdWwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FuZGFyYSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYW5k YXJhJnF1b3Q7LHNhbnMtc2VyaWYiPkluIGdlbmVyYWwgSSBjYW4gc2VlIGhvdyBoYXZpbmcgdHdv IFNlcnZpY2UgaGVhZGVycyBtYXkgaGVscC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDYW5kYXJhJnF1b3Q7LHNhbnMtc2VyaWYiPkluIHByYWN0aWNlIGhvd2V2ZXIsIGEgc2lu Z2xlIG9uZSB3aXRoIGhpZ2gtb3JkZXIgYml0IGRpZmZlcmVudGlhdGluZyB0aGUgZm9yd2FyZC9y ZXZlcnNlIG5hbWUgc3BhY2Ugd29ya3Mgd2VsbCB3aGVyZSBiaS1kaXJlY3Rpb25hbCBiZWhhdmlv ciBpcyBuZWVkZWQgYW5kIGhhcyBmb3IgdXMuIEkgc3VwcG9ydA0KIHVzaW5nIHRoZSBoaWdoLW9y ZGVyIGJpdCBhcyBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FuZGFyYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYW5kYXJhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uZSBv cHRpb24gd2l0aCBNRC1UWVBFMiBtYXkgYmUgdG8gdXNlIFRMVnMgdG8gY2FycnkgdGhlIG90aGVy IHNlcnZpY2UtaGVhZGVyLCB0aGF0IGFjaGlldmVzIHRoZSBkZXNpcmVkIGVmZmVjdCB3aGlsZSBu b3QgdGF4aW5nIGFsbCBpbXBsZW1lbnRhdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FuZGFyYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDYW5kYXJhJnF1b3Q7LHNhbnMtc2VyaWYiPlN1cmVuZHJhLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbmRhcmEmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYu b3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Cb3R0b3JmZiwgUGF1bDxicj4NCjxiPlNlbnQ6PC9i PiBUaHVyc2RheSwgTWF5IDI2LCAyMDE2IDExOjAyIEFNPGJyPg0KPGI+VG86PC9iPiBDaHJpc3Rp YW4gS29lbm5pbmcgJmx0O0MuS29lbm5pbmdARjUuY29tJmd0Ozsgc2ZjQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbc2ZjXSBTZXJ2aWNlIFBhdGggSWRlbnRpZmllciAoU1BJKSBh bmQgc3ltbWV0cnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgQ2hyaXN0aWFuOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QSB2ZXJ5IGdvb2QgcXVlc3Rpb24uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JTUhPIHRoZSBTUEkgY2Fu 4oCZdCBiZSBiaS1kaXJlY3Rpb25hbCBiZWNhdXNlIHRoZSBmb3J3YXJkaW5nIGRpcmVjdGlvbiB3 b3VsZCBiZSBhbWJpZ3VvdXMgZm9yIHNpbmdsZSBhcm1lZCBTRnMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi Pjxicj4NClRoZSByZXZlcnNhbCBwcm9ibGVtIHBvaW50cyBvdXQgYSBiYXNpYyBkZWZpY2llbmN5 IG9mIHRoZSBTUEkmIzQzO1NJIE5TSCBmaWVsZHMuIFRoZXNlIGZpZWxkcyBmb3JtIHRoZSBzZXJ2 ZXIgbGF5ZXIgbmV0d29yayBhZGRyZXNzIChub3QgdGhlIHRyYW5zcG9ydCBsYXllciBhZGRyZXNz KS4gV2hhdCB3ZSBsYWNrIGlzIGEgd2F5IHRvIGVuY29kZSB0aGUgcmV2ZXJzZSBhZGRyZXNzLg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgZGlyZWN0IG1l dGhvZCBmb3IgaGFuZGxpbmcgZm9yd2FyZCBhbmQgYmFja3dhcmQgYWRkcmVzc2luZyBpcyB0byBl bmNvZGUgYm90aCBhIGZvcndhcmQgYW5kIHJldmVyc2UgcGF0aCBpbiB0aGUgTlNIIGhlYWRlciAo U1BJRi9TUElSKS4gVGhpcyB3b3VsZCBiZSBzaW1pbGFyDQogdG8gRXRoZXJuZXQgREEvU0Egb3Ig SVAgU0lQL1NJUC4gU3VjaCBhbiBlbmNvZGluZyB3b3VsZCBiZSB0aGUgbW9zdCBmbGV4aWJsZSB3 YXkgdG8gYnVpbGQgdGhlIE5TSCBoZWFkZXIsIGhvd2V2ZXIgZm9yIGEgbW9yZSBzcGFjZSBlZmZp Y2llbnQgbWV0aG9kIHdoaWNoIG9mZmVycyB0aGUgbWluaW11bSBtb2RpZmljYXRpb24gdG8gdGhl IGV4aXN0aW5nIE5TSCBmaWVsZHMgd2UgaGF2ZSBoYWQgc3VjY2VzcyBlbmNvZGluZyBhIHJldmVy c2UgYWRkcmVzcw0KIGJ5IHJlc2VydmluZyB0aGUgaGlnaCBvcmRlciBiaXQgb2YgdGhlIFNQSSB0 byBkZXNpZ25hdGUgdGhlIHJldmVyc2UgYWRkcmVzcy4gU28gaW4gdGhpcyBtZXRob2QgdGhlIFNQ SUYgYWx3YXlzIGhhcyBoaWdoIG9yZGVyIGJpdCAwIGFuZCB0aGUgU1BJUiBhbHdheXMgaGFzIGhp Z2ggb3JkZXIgYml0IDEuIEFuIFNGIG9yIE9BTSB3aGljaCBuZWVkcyB0byBzZW5kIGFsb25nIHRo ZSByZXZlcnNlIHBhdGggY2FuIGFsd2F5cyBmb3JtIHRoZSByZXZlcnNlDQogYWRkcmVzcyBieSBm bGlwcGluZyB0aGUgaGlnaCBvcmRlciBiaXQgb2YgdGhlIFNQSS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PGJyPg0K UGF1bCAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHNm YyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2ZjLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DaHJpc3RpYW4gS29lbm5pbmc8 YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWF5IDE3LCAyMDE2IDEyOjQ5IFBNPGJyPg0KPGI+ VG86PC9iPiA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFtzZmNdIFNlcnZpY2UgUGF0aCBJZGVudGlmaWVyIChTUEkpIGFu ZCBzeW1tZXRyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si Pkdvb2QgRXZlbmluZyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+bG9va2luZyBhdCBSRkMgNzY2NSZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+U2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyAoU0ZD KSBBcmNoaXRlY3R1cmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NjY1Ij5odHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNzY2NTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+dGhlcmUgaXMgYSBjbGVhciBkZWZpbml0aW9u IG9mIGNoYWluIHN5bWV0cnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+JnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4yLjIuICZuYnNwO1NlcnZpY2UgRnVuY3Rpb24gQ2hhaW4gU3ltbWV0cnk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+Jm5ic3A7ICZuYnNwO1NGQ3MgbWF5IGJlIHVuaWRpcmVjdGlvbmFsIG9yIGJpZGly ZWN0aW9uYWwuICZuYnNwO0EgdW5pZGlyZWN0aW9uYWwgU0ZDPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7cmVxdWlyZXMgdGhhdCB0cmFmZmljIGJlIGZvcndhcmRl ZCB0aHJvdWdoIHRoZSBvcmRlcmVkIFNGcyBpbiBvbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZuYnNwOyAmbmJzcDtkaXJlY3Rpb24gKHNmMSAtJmd0OyBzZjIgLSZndDsgc2YzKSwg d2hlcmVhcyBhIGJpZGlyZWN0aW9uYWwgU0ZDIHJlcXVpcmVzIGE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDtzeW1tZXRyaWMgcGF0aCAoc2YxIC0mZ3Q7IHNmMiAt Jmd0OyBzZjMgYW5kIHNmMyAtJmd0OyBzZjIgLSZndDsgc2YxKSwgYW5kIGluPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7d2hpY2ggdGhlIFNGIGluc3RhbmNlcyBh cmUgdGhlIHNhbWUgaW4gb3Bwb3NpdGUgZGlyZWN0aW9ucy4gJm5ic3A7QSBoeWJyaWQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDtTRkMgaGFzIGF0dHJpYnV0ZXMg b2YgYm90aCB1bmlkaXJlY3Rpb25hbCBhbmQgYmlkaXJlY3Rpb25hbCBTRkNzOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO3RoYXQgaXMgdG8gc2F5IHNvbWUgU0Zz IHJlcXVpcmUgc3ltbWV0cmljIHRyYWZmaWMsIHdoZXJlYXMgb3RoZXIgU0ZzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ZG8gbm90IHByb2Nlc3MgcmV2ZXJzZSB0 cmFmZmljIG9yIGFyZSBpbmRlcGVuZGVudCBvZiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZuYnNwOyAmbmJzcDtjb3JyZXNwb25kaW5nIGZvcndhcmQgdHJhZmZpYy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsuLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiZuYnNwOyAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyAm bmJzcDsgRnVydGhlciwgdGhlcmUgYXJlIHN0YXRlIHRyYWRlLW9mZnMgaW4gc3ltbWV0cnkuICZu YnNwO1N5bW1ldHJ5IG1heSBiZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7 ICZuYnNwO3JlYWxpemVkIGluIHNldmVyYWwgd2F5cyBkZXBlbmRpbmcgb24gdGhlIFNGRiBhbmQg Y2xhc3NpZmllcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO2Z1 bmN0aW9uYWxpdHkuICZuYnNwO0luIHNvbWUgY2FzZXMsICZxdW90O21pcnJvcmVkJnF1b3Q7IGNs YXNzaWZpY2F0aW9uIChpLmUuLCBmcm9tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4m bmJzcDsgJm5ic3A7U291cmNlIHRvIERlc3RpbmF0aW9uIGFuZCBmcm9tIERlc3RpbmF0aW9uIHRv IFNvdXJjZSkgcG9saWN5IG1heSBiZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5i c3A7ICZuYnNwO2RlcGxveWVkLCB3aGVyZWFzIGluIG90aGVycyBzaGFyZWQgc3RhdGUgYmV0d2Vl biBjbGFzc2lmaWVycyBtYXkgYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNw OyAmbmJzcDt1c2VkIHRvIGVuc3VyZSB0aGF0IHN5bW1ldHJpYyBmbG93cyBhcmUgY29ycmVjdGx5 IGlkZW50aWZpZWQsIHRoZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyAm bmJzcDtzdGVlcmVkIGFsb25nIHRoZSByZXF1aXJlZCBTRlAuICZuYnNwO0F0IGEgaGlnaCBsZXZl bCwgdGhlcmUgYXJlIHZhcmlvdXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNw OyAmbmJzcDtjb21tb24gY2FzZXMuICZuYnNwO0luIGEgbm9uLWV4aGF1c3RpdmUgd2F5LCB0aGVy ZSBjYW4gYmUgZm9yIGV4YW1wbGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDtvICZuYnNwO0Eg c2luZ2xlIGNsYXNzaWZpZXIgKG9yIGEgc21hbGwgbnVtYmVyIG9mIGNsYXNzaWZpZXJzKSwgaW4g d2hpY2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7 IGNhc2UgYm90aCBpbmNvbWluZyBhbmQgb3V0Z29pbmcgZmxvd3MgY291bGQgYmUgcmVjb2duaXpl ZCBhdCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsgJm5i c3A7IHNhbWUgY2xhc3NpZmllciwgc28gdGhlIHN5bmNocm9uaXphdGlvbiB3b3VsZCBiZSBmZWFz aWJsZSBieTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgaW50ZXJuYWwgbWVjaGFuaXNtcyBpbnRlcm5hbCB0byB0aGUgY2xhc3NpZmllci48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+Jm5ic3A7ICZuYnNwO28gJm5ic3A7U3RhdGVmdWwgY2xhc3NpZmllcnMgd2hlcmUgc2V2 ZXJhbCBjbGFzc2lmaWVycyBtYXkgYmUgY2x1c3RlcmVkPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBhbmQgc2hhcmUgc3RhdGUuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PiZuYnNwOyAmbmJzcDtvICZuYnNwO0Z1bGx5IGRpc3RyaWJ1dGVkIGNsYXNzaWZpZXJzLCB3aGVy ZSBzeW5jaHJvbml6YXRpb24gbmVlZHMgdG8gYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7IHByb3ZpZGVkIHRocm91Z2ggdW5zcGVjaWZpZWQgbWVh bnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDtvICZuYnNwO0EgY2xhc3NpZmllciB0aGF0IGxl YXJucyBzdGF0ZSBmcm9tIHRoZSBlZ3Jlc3MgcGFja2V0cy9mbG93cyB0aGF0PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBpcyB0aGVuIHVzZWQgdG8g cHJvdmlkZSBzdGF0ZSBmb3IgdGhlIHJldHVybiBwYWNrZXRzL2Zsb3cuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZu YnNwOyAmbmJzcDtvICZuYnNwO1N5bW1ldHJ5IG1heSBhbHNvIGJlIHByb3ZpZGVkIGJ5IHN0YXRl ZnVsIGZvcndhcmRpbmcgbG9naWMgaW4gdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyBTRkYgaW4gc29tZSBpbXBsZW1lbnRhdGlvbnMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZuYnNwOyAmbmJzcDtUaGlzIGlzIGEgbm9uLWNvbXByZWhlbnNpdmUgbGlzdCBvZiBj b21tb24gY2FzZXMuICZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7 ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5Ib3dldmVyLCB3aGVuIGxvb2tpbmcgYXQgdGhpcyB0b2dldGhl ciB3aXRoJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5OZXR3b3JrIFNlcnZp Y2UgSGVhZGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5kcmFmdC1pZXRmLXNmYy1u c2gtMDQudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zZmMtbnNoLTA0Ij5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zZmMtbnNoLTA0PC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4zLjMu ICZuYnNwO1NlcnZpY2UgUGF0aCBIZWFkZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+JnF1b3Q7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7U2VydmljZSBQYXRoIElkZW50aWZpZXIg KFNQSSk6IGlkZW50aWZpZXMgYSBzZXJ2aWNlIHBhdGguPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj4mbmJzcDsgJm5ic3A7UGFydGljaXBhdGluZyBub2RlcyBNVVNUIHVzZSB0aGlzIGlk ZW50aWZpZXIgZm9yIFNlcnZpY2UgRnVuY3Rpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiZuYnNwOyAmbmJzcDtQYXRoIHNlbGVjdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj50aGVyZSBpcyBubyBub3Rpb24gb2Ygc3ltbWV0cnku Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ Q2FuIHlvdSBwbGVhc2UgY29uZmlybSB0aGF0IGEgYmlkaXJlY3Rpb25hbCBTZXJ2aWNlIEZ1bmN0 aW9uIENoYWluJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj53aWxsIGJlIHJl cHJlc2VudGVkIGJ5IG9uZSBzaW5nbGUgU2VydmljZSBQYXRoIElkZW50aWZpZXIsIGluZ3Jlc3Mg c3ltbWV0cmljIHRvIGVncmVzcyA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+UGxlYXNlIGFsbG93IHVzIHRvIGNsYXJpZnkgdGhpcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+TWFueSBUaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Q2hyaXN0aWFuIEtvZW5uaW5nPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RjUg TmV0d29ya3MgSW5jLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFp bHRvOmNocmlzdGlhbkBmNS5jb20iPmNocmlzdGlhbkBmNS5jb208L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1a80281212814b3fb29a9bb9092567b5XCHRCD020ciscocom_-- From nobody Thu May 26 14:28:44 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E21A12D75C for ; Thu, 26 May 2016 14:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 gOOU1y2PlqKG for ; Thu, 26 May 2016 14:28:39 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38E3F12D769 for ; Thu, 26 May 2016 14:28:38 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-2.sandvine.com (192.168.194.177) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 26 May 2016 17:28:36 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Thu, 26 May 2016 17:28:35 -0400 From: Dave Dolson To: "Surendra Kumar (smkumar)" , "Bottorff, Paul" , Christian Koenning , "sfc@ietf.org" Thread-Topic: Service Path Identifier (SPI) and symmetry Thread-Index: AQHRsHUtFvsY0ydaV0iEs6canF5mkp/Lix3AgAAP+0CAAC3l4A== Date: Thu, 26 May 2016 21:28:35 +0000 Message-ID: References: <1a80281212814b3fb29a9bb9092567b5@XCH-RCD-020.cisco.com> In-Reply-To: <1a80281212814b3fb29a9bb9092567b5@XCH-RCD-020.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830F82F04wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Service Path Identifier (SPI) and symmetry X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 21:28:41 -0000 --_000_E8355113905631478EFF04F5AA706E9830F82F04wtlexchp2sandvi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBxdWVzdGlvbiBvZiB0aGUgcmV2ZXJzYWwgcHJvYmxlbSAoYW5kIHBhY2tldCBpbmplY3Rp b24gaW4gZ2VuZXJhbCkga2VlcHMgY29taW5nIHVwLg0KDQpQbGVhc2UgcmVhZCBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGVubm8tc2ZjLXBhY2tldC0wMw0KYW5kIHByb3ZpZGUg ZmVlZC1iYWNrLg0KDQpJbiBwYXJ0aWN1bGFyLCB2YXJpb3VzIG1ldGhvZHMgYXJlIGRpc2N1c3Nl ZCB1c2luZyAoYSkgT0FNIHBhY2tldHMsIChiKSByZXZlcnNhbCBpbmZvcm1hdGlvbiBpbiBtZXRh LWRhdGEsIChjKSBhbGdvcml0aG1pYyBhcHByb2FjaGVzIHRvIGNvbXB1dGluZyByZXZlcnNlZCBm aWVsZHMuDQoNCkxldCB1cyBrbm93IHdoYXQgd29ya3MgZm9yIHlvdS4NCg0KLURhdmUNCg0KDQpG cm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN1cmVu ZHJhIEt1bWFyIChzbWt1bWFyKQ0KU2VudDogVGh1cnNkYXksIE1heSAyNiwgMjAxNiAyOjQ2IFBN DQpUbzogQm90dG9yZmYsIFBhdWw7IENocmlzdGlhbiBLb2VubmluZzsgc2ZjQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBQYXRoIElkZW50aWZpZXIgKFNQSSkgYW5kIHN5bW1l dHJ5DQoNCkhpIFBhdWwsDQoNCkluIGdlbmVyYWwgSSBjYW4gc2VlIGhvdyBoYXZpbmcgdHdvIFNl cnZpY2UgaGVhZGVycyBtYXkgaGVscC4NCkluIHByYWN0aWNlIGhvd2V2ZXIsIGEgc2luZ2xlIG9u ZSB3aXRoIGhpZ2gtb3JkZXIgYml0IGRpZmZlcmVudGlhdGluZyB0aGUgZm9yd2FyZC9yZXZlcnNl IG5hbWUgc3BhY2Ugd29ya3Mgd2VsbCB3aGVyZSBiaS1kaXJlY3Rpb25hbCBiZWhhdmlvciBpcyBu ZWVkZWQgYW5kIGhhcyBmb3IgdXMuIEkgc3VwcG9ydCB1c2luZyB0aGUgaGlnaC1vcmRlciBiaXQg YXMgYW4gaW1wbGVtZW50YXRpb24gZGV0YWlsLg0KDQpPbmUgb3B0aW9uIHdpdGggTUQtVFlQRTIg bWF5IGJlIHRvIHVzZSBUTFZzIHRvIGNhcnJ5IHRoZSBvdGhlciBzZXJ2aWNlLWhlYWRlciwgdGhh dCBhY2hpZXZlcyB0aGUgZGVzaXJlZCBlZmZlY3Qgd2hpbGUgbm90IHRheGluZyBhbGwgaW1wbGVt ZW50YXRpb25zLg0KDQpTdXJlbmRyYS4NCg0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCb3R0b3JmZiwgUGF1bA0KU2VudDogVGh1cnNkYXksIE1h eSAyNiwgMjAxNiAxMTowMiBBTQ0KVG86IENocmlzdGlhbiBLb2VubmluZyA8Qy5Lb2VubmluZ0BG NS5jb208bWFpbHRvOkMuS29lbm5pbmdARjUuY29tPj47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2Zj QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgUGF0aCBJZGVudGlmaWVyIChT UEkpIGFuZCBzeW1tZXRyeQ0KDQpIaSBDaHJpc3RpYW46DQoNCkEgdmVyeSBnb29kIHF1ZXN0aW9u Lg0KDQpJTUhPIHRoZSBTUEkgY2Fu4oCZdCBiZSBiaS1kaXJlY3Rpb25hbCBiZWNhdXNlIHRoZSBm b3J3YXJkaW5nIGRpcmVjdGlvbiB3b3VsZCBiZSBhbWJpZ3VvdXMgZm9yIHNpbmdsZSBhcm1lZCBT RnMuDQoNClRoZSByZXZlcnNhbCBwcm9ibGVtIHBvaW50cyBvdXQgYSBiYXNpYyBkZWZpY2llbmN5 IG9mIHRoZSBTUEkrU0kgTlNIIGZpZWxkcy4gVGhlc2UgZmllbGRzIGZvcm0gdGhlIHNlcnZlciBs YXllciBuZXR3b3JrIGFkZHJlc3MgKG5vdCB0aGUgdHJhbnNwb3J0IGxheWVyIGFkZHJlc3MpLiBX aGF0IHdlIGxhY2sgaXMgYSB3YXkgdG8gZW5jb2RlIHRoZSByZXZlcnNlIGFkZHJlc3MuDQoNClRo ZSBkaXJlY3QgbWV0aG9kIGZvciBoYW5kbGluZyBmb3J3YXJkIGFuZCBiYWNrd2FyZCBhZGRyZXNz aW5nIGlzIHRvIGVuY29kZSBib3RoIGEgZm9yd2FyZCBhbmQgcmV2ZXJzZSBwYXRoIGluIHRoZSBO U0ggaGVhZGVyIChTUElGL1NQSVIpLiBUaGlzIHdvdWxkIGJlIHNpbWlsYXIgdG8gRXRoZXJuZXQg REEvU0Egb3IgSVAgU0lQL1NJUC4gU3VjaCBhbiBlbmNvZGluZyB3b3VsZCBiZSB0aGUgbW9zdCBm bGV4aWJsZSB3YXkgdG8gYnVpbGQgdGhlIE5TSCBoZWFkZXIsIGhvd2V2ZXIgZm9yIGEgbW9yZSBz cGFjZSBlZmZpY2llbnQgbWV0aG9kIHdoaWNoIG9mZmVycyB0aGUgbWluaW11bSBtb2RpZmljYXRp b24gdG8gdGhlIGV4aXN0aW5nIE5TSCBmaWVsZHMgd2UgaGF2ZSBoYWQgc3VjY2VzcyBlbmNvZGlu ZyBhIHJldmVyc2UgYWRkcmVzcyBieSByZXNlcnZpbmcgdGhlIGhpZ2ggb3JkZXIgYml0IG9mIHRo ZSBTUEkgdG8gZGVzaWduYXRlIHRoZSByZXZlcnNlIGFkZHJlc3MuIFNvIGluIHRoaXMgbWV0aG9k IHRoZSBTUElGIGFsd2F5cyBoYXMgaGlnaCBvcmRlciBiaXQgMCBhbmQgdGhlIFNQSVIgYWx3YXlz IGhhcyBoaWdoIG9yZGVyIGJpdCAxLiBBbiBTRiBvciBPQU0gd2hpY2ggbmVlZHMgdG8gc2VuZCBh bG9uZyB0aGUgcmV2ZXJzZSBwYXRoIGNhbiBhbHdheXMgZm9ybSB0aGUgcmV2ZXJzZSBhZGRyZXNz IGJ5IGZsaXBwaW5nIHRoZSBoaWdoIG9yZGVyIGJpdCBvZiB0aGUgU1BJLg0KDQpDaGVlcnMsDQoN ClBhdWwNCg0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBDaHJpc3RpYW4gS29lbm5pbmcNClNlbnQ6IFR1ZXNkYXksIE1heSAxNywgMjAxNiAxMjo0 OSBQTQ0KVG86IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDogW3Nm Y10gU2VydmljZSBQYXRoIElkZW50aWZpZXIgKFNQSSkgYW5kIHN5bW1ldHJ5DQoNCkdvb2QgRXZl bmluZywNCg0KbG9va2luZyBhdCBSRkMgNzY2NQ0KU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyAo U0ZDKSBBcmNoaXRlY3R1cmUNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NjY1DQoN CnRoZXJlIGlzIGEgY2xlYXIgZGVmaW5pdGlvbiBvZiBjaGFpbiBzeW1ldHJ5DQoNCiINCjIuMi4g IFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW4gU3ltbWV0cnkNCg0KICAgU0ZDcyBtYXkgYmUgdW5pZGly ZWN0aW9uYWwgb3IgYmlkaXJlY3Rpb25hbC4gIEEgdW5pZGlyZWN0aW9uYWwgU0ZDDQogICByZXF1 aXJlcyB0aGF0IHRyYWZmaWMgYmUgZm9yd2FyZGVkIHRocm91Z2ggdGhlIG9yZGVyZWQgU0ZzIGlu IG9uZQ0KICAgZGlyZWN0aW9uIChzZjEgLT4gc2YyIC0+IHNmMyksIHdoZXJlYXMgYSBiaWRpcmVj dGlvbmFsIFNGQyByZXF1aXJlcyBhDQogICBzeW1tZXRyaWMgcGF0aCAoc2YxIC0+IHNmMiAtPiBz ZjMgYW5kIHNmMyAtPiBzZjIgLT4gc2YxKSwgYW5kIGluDQogICB3aGljaCB0aGUgU0YgaW5zdGFu Y2VzIGFyZSB0aGUgc2FtZSBpbiBvcHBvc2l0ZSBkaXJlY3Rpb25zLiAgQSBoeWJyaWQNCiAgIFNG QyBoYXMgYXR0cmlidXRlcyBvZiBib3RoIHVuaWRpcmVjdGlvbmFsIGFuZCBiaWRpcmVjdGlvbmFs IFNGQ3M7DQogICB0aGF0IGlzIHRvIHNheSBzb21lIFNGcyByZXF1aXJlIHN5bW1ldHJpYyB0cmFm ZmljLCB3aGVyZWFzIG90aGVyIFNGcw0KICAgZG8gbm90IHByb2Nlc3MgcmV2ZXJzZSB0cmFmZmlj IG9yIGFyZSBpbmRlcGVuZGVudCBvZiB0aGUNCiAgIGNvcnJlc3BvbmRpbmcgZm9yd2FyZCB0cmFm ZmljLg0KDQogICAuLi4NCg0KICAgIEZ1cnRoZXIsIHRoZXJlIGFyZSBzdGF0ZSB0cmFkZS1vZmZz IGluIHN5bW1ldHJ5LiAgU3ltbWV0cnkgbWF5IGJlDQogICByZWFsaXplZCBpbiBzZXZlcmFsIHdh eXMgZGVwZW5kaW5nIG9uIHRoZSBTRkYgYW5kIGNsYXNzaWZpZXINCiAgIGZ1bmN0aW9uYWxpdHku ICBJbiBzb21lIGNhc2VzLCAibWlycm9yZWQiIGNsYXNzaWZpY2F0aW9uIChpLmUuLCBmcm9tDQog ICBTb3VyY2UgdG8gRGVzdGluYXRpb24gYW5kIGZyb20gRGVzdGluYXRpb24gdG8gU291cmNlKSBw b2xpY3kgbWF5IGJlDQogICBkZXBsb3llZCwgd2hlcmVhcyBpbiBvdGhlcnMgc2hhcmVkIHN0YXRl IGJldHdlZW4gY2xhc3NpZmllcnMgbWF5IGJlDQogICB1c2VkIHRvIGVuc3VyZSB0aGF0IHN5bW1l dHJpYyBmbG93cyBhcmUgY29ycmVjdGx5IGlkZW50aWZpZWQsIHRoZW4NCiAgIHN0ZWVyZWQgYWxv bmcgdGhlIHJlcXVpcmVkIFNGUC4gIEF0IGEgaGlnaCBsZXZlbCwgdGhlcmUgYXJlIHZhcmlvdXMN CiAgIGNvbW1vbiBjYXNlcy4gIEluIGEgbm9uLWV4aGF1c3RpdmUgd2F5LCB0aGVyZSBjYW4gYmUg Zm9yIGV4YW1wbGU6DQoNCiAgIG8gIEEgc2luZ2xlIGNsYXNzaWZpZXIgKG9yIGEgc21hbGwgbnVt YmVyIG9mIGNsYXNzaWZpZXJzKSwgaW4gd2hpY2gNCiAgICAgIGNhc2UgYm90aCBpbmNvbWluZyBh bmQgb3V0Z29pbmcgZmxvd3MgY291bGQgYmUgcmVjb2duaXplZCBhdCB0aGUNCiAgICAgIHNhbWUg Y2xhc3NpZmllciwgc28gdGhlIHN5bmNocm9uaXphdGlvbiB3b3VsZCBiZSBmZWFzaWJsZSBieQ0K ICAgICAgaW50ZXJuYWwgbWVjaGFuaXNtcyBpbnRlcm5hbCB0byB0aGUgY2xhc3NpZmllci4NCg0K ICAgbyAgU3RhdGVmdWwgY2xhc3NpZmllcnMgd2hlcmUgc2V2ZXJhbCBjbGFzc2lmaWVycyBtYXkg YmUgY2x1c3RlcmVkDQogICAgICBhbmQgc2hhcmUgc3RhdGUuDQoNCiAgIG8gIEZ1bGx5IGRpc3Ry aWJ1dGVkIGNsYXNzaWZpZXJzLCB3aGVyZSBzeW5jaHJvbml6YXRpb24gbmVlZHMgdG8gYmUNCiAg ICAgIHByb3ZpZGVkIHRocm91Z2ggdW5zcGVjaWZpZWQgbWVhbnMuDQoNCiAgIG8gIEEgY2xhc3Np ZmllciB0aGF0IGxlYXJucyBzdGF0ZSBmcm9tIHRoZSBlZ3Jlc3MgcGFja2V0cy9mbG93cyB0aGF0 DQogICAgICBpcyB0aGVuIHVzZWQgdG8gcHJvdmlkZSBzdGF0ZSBmb3IgdGhlIHJldHVybiBwYWNr ZXRzL2Zsb3cuDQoNCiAgIG8gIFN5bW1ldHJ5IG1heSBhbHNvIGJlIHByb3ZpZGVkIGJ5IHN0YXRl ZnVsIGZvcndhcmRpbmcgbG9naWMgaW4gdGhlDQogICAgICBTRkYgaW4gc29tZSBpbXBsZW1lbnRh dGlvbnMuDQoNCiAgIFRoaXMgaXMgYSBub24tY29tcHJlaGVuc2l2ZSBsaXN0IG9mIGNvbW1vbiBj YXNlcy4gIg0KDQoNCkhvd2V2ZXIsIHdoZW4gbG9va2luZyBhdCB0aGlzIHRvZ2V0aGVyIHdpdGgN Ck5ldHdvcmsgU2VydmljZSBIZWFkZXINCmRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQNCmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNmYy1uc2gtMDQNCg0KMy4zLiAgU2Vy dmljZSBQYXRoIEhlYWRlcg0KDQoiDQogICBTZXJ2aWNlIFBhdGggSWRlbnRpZmllciAoU1BJKTog aWRlbnRpZmllcyBhIHNlcnZpY2UgcGF0aC4NCiAgIFBhcnRpY2lwYXRpbmcgbm9kZXMgTVVTVCB1 c2UgdGhpcyBpZGVudGlmaWVyIGZvciBTZXJ2aWNlIEZ1bmN0aW9uDQogICBQYXRoIHNlbGVjdGlv bi4NCiINCg0KdGhlcmUgaXMgbm8gbm90aW9uIG9mIHN5bW1ldHJ5Lg0KDQoNCkNhbiB5b3UgcGxl YXNlIGNvbmZpcm0gdGhhdCBhIGJpZGlyZWN0aW9uYWwgU2VydmljZSBGdW5jdGlvbiBDaGFpbg0K d2lsbCBiZSByZXByZXNlbnRlZCBieSBvbmUgc2luZ2xlIFNlcnZpY2UgUGF0aCBJZGVudGlmaWVy LCBpbmdyZXNzIHN5bW1ldHJpYyB0byBlZ3Jlc3MgPw0KDQoNClBsZWFzZSBhbGxvdyB1cyB0byBj bGFyaWZ5IHRoaXMuDQoNCk1hbnkgVGhhbmtzDQoNCkNocmlzdGlhbiBLb2VubmluZw0KLS0NCkY1 IE5ldHdvcmtzIEluYy4NCmNocmlzdGlhbkBmNS5jb208bWFpbHRvOmNocmlzdGlhbkBmNS5jb20+ DQoNCg== --_000_E8355113905631478EFF04F5AA706E9830F82F04wtlexchp2sandvi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYW5kYXJhOw0KCXBh bm9zZS0xOjIgMTQgNSAyIDMgMyAzIDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpw Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxT dHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FuZGFyYSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5 bGU6bm9ybWFsO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxs b29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpz cGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZs aW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyBx dWVzdGlvbiBvZiB0aGUgcmV2ZXJzYWwgcHJvYmxlbSAoYW5kIHBhY2tldCBpbmplY3Rpb24gaW4g Z2VuZXJhbCkga2VlcHMgY29taW5nIHVwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGxlYXNlIHJlYWQNCjxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wZW5uby1zZmMtcGFja2V0LTAzIj5o dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGVubm8tc2ZjLXBhY2tldC0wMzwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YW5kIHByb3ZpZGUgZmVlZC1iYWNrLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SW4gcGFydGljdWxhciwgdmFyaW91cyBtZXRob2RzIGFyZSBkaXNjdXNzZWQgdXNpbmcg KGEpIE9BTSBwYWNrZXRzLCAoYikgcmV2ZXJzYWwgaW5mb3JtYXRpb24gaW4gbWV0YS1kYXRhLCAo YykgYWxnb3JpdGhtaWMgYXBwcm9hY2hlcyB0byBjb21wdXRpbmcgcmV2ZXJzZWQNCiBmaWVsZHMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5MZXQgdXMga25vdyB3aGF0IHdvcmtzIGZvciB5b3UuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tRGF2 ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ U3VyZW5kcmEgS3VtYXIgKHNta3VtYXIpPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBNYXkg MjYsIDIwMTYgMjo0NiBQTTxicj4NCjxiPlRvOjwvYj4gQm90dG9yZmYsIFBhdWw7IENocmlzdGlh biBLb2VubmluZzsgc2ZjQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2ZjXSBT ZXJ2aWNlIFBhdGggSWRlbnRpZmllciAoU1BJKSBhbmQgc3ltbWV0cnk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDYW5kYXJhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkhpIFBhdWwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FuZGFyYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYW5kYXJhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkluIGdl bmVyYWwgSSBjYW4gc2VlIGhvdyBoYXZpbmcgdHdvIFNlcnZpY2UgaGVhZGVycyBtYXkgaGVscC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYW5kYXJhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkluIHByYWN0aWNlIGhvd2V2ZXIsIGEgc2luZ2xlIG9uZSB3aXRoIGhp Z2gtb3JkZXIgYml0IGRpZmZlcmVudGlhdGluZyB0aGUgZm9yd2FyZC9yZXZlcnNlIG5hbWUgc3Bh Y2Ugd29ya3Mgd2VsbCB3aGVyZSBiaS1kaXJlY3Rpb25hbCBiZWhhdmlvciBpcyBuZWVkZWQgYW5k IGhhcyBmb3IgdXMuIEkNCiBzdXBwb3J0IHVzaW5nIHRoZSBoaWdoLW9yZGVyIGJpdCBhcyBhbiBp bXBsZW1lbnRhdGlvbiBkZXRhaWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FuZGFyYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDYW5kYXJhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPk9uZSBvcHRpb24gd2l0aCBNRC1UWVBFMiBtYXkgYmUgdG8gdXNlIFRMVnMgdG8gY2Fycnkg dGhlIG90aGVyIHNlcnZpY2UtaGVhZGVyLCB0aGF0IGFjaGlldmVzIHRoZSBkZXNpcmVkIGVmZmVj dCB3aGlsZSBub3QgdGF4aW5nIGFsbCBpbXBsZW1lbnRhdGlvbnMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FuZGFyYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYW5kYXJhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPlN1cmVuZHJhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbmRhcmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNmYyBbPGEgaHJlZj0ibWFp bHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Cb3R0b3JmZiwgUGF1bDxicj4NCjxiPlNlbnQ6PC9iPiBU aHVyc2RheSwgTWF5IDI2LCAyMDE2IDExOjAyIEFNPGJyPg0KPGI+VG86PC9iPiBDaHJpc3RpYW4g S29lbm5pbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpDLktvZW5uaW5nQEY1LmNvbSI+Qy5Lb2Vubmlu Z0BGNS5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRm Lm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzZmNdIFNlcnZpY2UgUGF0aCBJZGVu dGlmaWVyIChTUEkpIGFuZCBzeW1tZXRyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5IaSBDaHJpc3RpYW46PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BIHZlcnkgZ29vZCBxdWVzdGlvbi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PklNSE8gdGhlIFNQSSBjYW7igJl0IGJlIGJpLWRpcmVjdGlvbmFsIGJlY2F1c2UgdGhlIGZvcndh cmRpbmcgZGlyZWN0aW9uIHdvdWxkIGJlIGFtYmlndW91cyBmb3Igc2luZ2xlIGFybWVkIFNGcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PGJyPg0KVGhlIHJldmVyc2FsIHByb2JsZW0g cG9pbnRzIG91dCBhIGJhc2ljIGRlZmljaWVuY3kgb2YgdGhlIFNQSSYjNDM7U0kgTlNIIGZpZWxk cy4gVGhlc2UgZmllbGRzIGZvcm0gdGhlIHNlcnZlciBsYXllciBuZXR3b3JrIGFkZHJlc3MgKG5v dCB0aGUgdHJhbnNwb3J0IGxheWVyIGFkZHJlc3MpLiBXaGF0IHdlIGxhY2sgaXMgYSB3YXkgdG8g ZW5jb2RlIHRoZSByZXZlcnNlIGFkZHJlc3MuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBkaXJlY3QgbWV0aG9k IGZvciBoYW5kbGluZyBmb3J3YXJkIGFuZCBiYWNrd2FyZCBhZGRyZXNzaW5nIGlzIHRvIGVuY29k ZSBib3RoIGEgZm9yd2FyZCBhbmQgcmV2ZXJzZSBwYXRoIGluIHRoZSBOU0ggaGVhZGVyIChTUElG L1NQSVIpLiBUaGlzIHdvdWxkIGJlIHNpbWlsYXINCiB0byBFdGhlcm5ldCBEQS9TQSBvciBJUCBT SVAvU0lQLiBTdWNoIGFuIGVuY29kaW5nIHdvdWxkIGJlIHRoZSBtb3N0IGZsZXhpYmxlIHdheSB0 byBidWlsZCB0aGUgTlNIIGhlYWRlciwgaG93ZXZlciBmb3IgYSBtb3JlIHNwYWNlIGVmZmljaWVu dCBtZXRob2Qgd2hpY2ggb2ZmZXJzIHRoZSBtaW5pbXVtIG1vZGlmaWNhdGlvbiB0byB0aGUgZXhp c3RpbmcgTlNIIGZpZWxkcyB3ZSBoYXZlIGhhZCBzdWNjZXNzIGVuY29kaW5nIGEgcmV2ZXJzZSBh ZGRyZXNzDQogYnkgcmVzZXJ2aW5nIHRoZSBoaWdoIG9yZGVyIGJpdCBvZiB0aGUgU1BJIHRvIGRl c2lnbmF0ZSB0aGUgcmV2ZXJzZSBhZGRyZXNzLiBTbyBpbiB0aGlzIG1ldGhvZCB0aGUgU1BJRiBh bHdheXMgaGFzIGhpZ2ggb3JkZXIgYml0IDAgYW5kIHRoZSBTUElSIGFsd2F5cyBoYXMgaGlnaCBv cmRlciBiaXQgMS4gQW4gU0Ygb3IgT0FNIHdoaWNoIG5lZWRzIHRvIHNlbmQgYWxvbmcgdGhlIHJl dmVyc2UgcGF0aCBjYW4gYWx3YXlzIGZvcm0gdGhlIHJldmVyc2UNCiBhZGRyZXNzIGJ5IGZsaXBw aW5nIHRoZSBoaWdoIG9yZGVyIGJpdCBvZiB0aGUgU1BJLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hlZXJzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48YnI+DQpQYXVsICZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0 bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkNocmlzdGlh biBLb2VubmluZzxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBNYXkgMTcsIDIwMTYgMTI6NDkg UE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRm Lm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3NmY10gU2VydmljZSBQYXRoIElkZW50aWZp ZXIgKFNQSSkgYW5kIHN5bW1ldHJ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+R29vZCBFdmVuaW5nLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5sb29raW5nIGF0IFJGQyA3NjY1Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5TZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIChT RkMpIEFyY2hpdGVjdHVyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc2NjUiPmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NjY1PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj50aGVyZSBpcyBhIGNsZWFyIGRlZmluaXRpb24gb2YgY2hhaW4gc3ltZXRyeTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjIuMi4gJm5ic3A7U2VydmljZSBGdW5jdGlvbiBD aGFpbiBTeW1tZXRyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsg Jm5ic3A7U0ZDcyBtYXkgYmUgdW5pZGlyZWN0aW9uYWwgb3IgYmlkaXJlY3Rpb25hbC4gJm5ic3A7 QSB1bmlkaXJlY3Rpb25hbCBTRkM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOyAmbmJzcDtyZXF1aXJlcyB0aGF0IHRyYWZmaWMgYmUgZm9yd2FyZGVkIHRo cm91Z2ggdGhlIG9yZGVyZWQgU0ZzIGluIG9uZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO2RpcmVjdGlvbiAoc2YxIC0mZ3Q7IHNmMiAtJmd0 OyBzZjMpLCB3aGVyZWFzIGEgYmlkaXJlY3Rpb25hbCBTRkMgcmVxdWlyZXMgYTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO3N5bW1ldHJpYyBw YXRoIChzZjEgLSZndDsgc2YyIC0mZ3Q7IHNmMyBhbmQgc2YzIC0mZ3Q7IHNmMiAtJmd0OyBzZjEp LCBhbmQgaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OyAmbmJzcDt3aGljaCB0aGUgU0YgaW5zdGFuY2VzIGFyZSB0aGUgc2FtZSBpbiBvcHBvc2l0ZSBk aXJlY3Rpb25zLiAmbmJzcDtBIGh5YnJpZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO1NGQyBoYXMgYXR0cmlidXRlcyBvZiBib3RoIHVuaWRp cmVjdGlvbmFsIGFuZCBiaWRpcmVjdGlvbmFsIFNGQ3M7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7dGhhdCBpcyB0byBzYXkgc29tZSBTRnMg cmVxdWlyZSBzeW1tZXRyaWMgdHJhZmZpYywgd2hlcmVhcyBvdGhlciBTRnM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDtkbyBub3QgcHJvY2Vz cyByZXZlcnNlIHRyYWZmaWMgb3IgYXJlIGluZGVwZW5kZW50IG9mIHRoZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO2NvcnJlc3BvbmRpbmcg Zm9yd2FyZCB0cmFmZmljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7ICZuYnNwOy4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7ICZuYnNwOyBGdXJ0aGVyLCB0aGVyZSBhcmUgc3RhdGUgdHJhZGUtb2ZmcyBp biBzeW1tZXRyeS4gJm5ic3A7U3ltbWV0cnkgbWF5IGJlPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7cmVhbGl6ZWQgaW4gc2V2ZXJhbCB3YXlz IGRlcGVuZGluZyBvbiB0aGUgU0ZGIGFuZCBjbGFzc2lmaWVyPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ZnVuY3Rpb25hbGl0eS4gJm5ic3A7 SW4gc29tZSBjYXNlcywgJnF1b3Q7bWlycm9yZWQmcXVvdDsgY2xhc3NpZmljYXRpb24gKGkuZS4s IGZyb208bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyAm bmJzcDtTb3VyY2UgdG8gRGVzdGluYXRpb24gYW5kIGZyb20gRGVzdGluYXRpb24gdG8gU291cmNl KSBwb2xpY3kgbWF5IGJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsgJm5ic3A7ZGVwbG95ZWQsIHdoZXJlYXMgaW4gb3RoZXJzIHNoYXJlZCBzdGF0ZSBi ZXR3ZWVuIGNsYXNzaWZpZXJzIG1heSBiZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO3VzZWQgdG8gZW5zdXJlIHRoYXQgc3ltbWV0cmljIGZs b3dzIGFyZSBjb3JyZWN0bHkgaWRlbnRpZmllZCwgdGhlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO3N0ZWVyZWQgYWxvbmcgdGhlIHJlcXVp cmVkIFNGUC4gJm5ic3A7QXQgYSBoaWdoIGxldmVsLCB0aGVyZSBhcmUgdmFyaW91czxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO2NvbW1vbiBj YXNlcy4gJm5ic3A7SW4gYSBub24tZXhoYXVzdGl2ZSB3YXksIHRoZXJlIGNhbiBiZSBmb3IgZXhh bXBsZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO28g Jm5ic3A7QSBzaW5nbGUgY2xhc3NpZmllciAob3IgYSBzbWFsbCBudW1iZXIgb2YgY2xhc3NpZmll cnMpLCBpbiB3aGljaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgY2FzZSBib3RoIGluY29taW5nIGFuZCBvdXRnb2luZyBmbG93 cyBjb3VsZCBiZSByZWNvZ25pemVkIGF0IHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgc2FtZSBjbGFzc2lmaWVyLCBzbyB0 aGUgc3luY2hyb25pemF0aW9uIHdvdWxkIGJlIGZlYXNpYmxlIGJ5PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBpbnRlcm5hbCBt ZWNoYW5pc21zIGludGVybmFsIHRvIHRoZSBjbGFzc2lmaWVyLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7byAmbmJzcDtTdGF0ZWZ1bCBjbGFzc2lmaWVy cyB3aGVyZSBzZXZlcmFsIGNsYXNzaWZpZXJzIG1heSBiZSBjbHVzdGVyZWQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7IGFuZCBz aGFyZSBzdGF0ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7ICZu YnNwO28gJm5ic3A7RnVsbHkgZGlzdHJpYnV0ZWQgY2xhc3NpZmllcnMsIHdoZXJlIHN5bmNocm9u aXphdGlvbiBuZWVkcyB0byBiZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgcHJvdmlkZWQgdGhyb3VnaCB1bnNwZWNpZmllZCBt ZWFucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO28g Jm5ic3A7QSBjbGFzc2lmaWVyIHRoYXQgbGVhcm5zIHN0YXRlIGZyb20gdGhlIGVncmVzcyBwYWNr ZXRzL2Zsb3dzIHRoYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOyAmbmJzcDsgJm5ic3A7IGlzIHRoZW4gdXNlZCB0byBwcm92aWRlIHN0YXRlIGZvciB0 aGUgcmV0dXJuIHBhY2tldHMvZmxvdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7ICZuYnNwO28gJm5ic3A7U3ltbWV0cnkgbWF5IGFsc28gYmUgcHJvdmlkZWQgYnkg c3RhdGVmdWwgZm9yd2FyZGluZyBsb2dpYyBpbiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7IFNGRiBpbiBzb21lIGltcGxl bWVudGF0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7ICZu YnNwO1RoaXMgaXMgYSBub24tY29tcHJlaGVuc2l2ZSBsaXN0IG9mIGNvbW1vbiBjYXNlcy4gJnF1 b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkhvd2V2ZXIsIHdoZW4gbG9v a2luZyBhdCB0aGlzIHRvZ2V0aGVyIHdpdGgmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPk5ldHdvcmsgU2VydmljZSBIZWFkZXI8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPmRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNmYy1uc2gtMDQiPmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNmYy1uc2gtMDQ8L2E+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPjMuMy4gJm5ic3A7U2VydmljZSBQYXRoIEhlYWRlcjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDtTZXJ2aWNlIFBhdGggSWRlbnRpZmll ciAoU1BJKTogaWRlbnRpZmllcyBhIHNlcnZpY2UgcGF0aC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDtQYXJ0aWNpcGF0aW5nIG5vZGVzIE1V U1QgdXNlIHRoaXMgaWRlbnRpZmllciBmb3IgU2VydmljZSBGdW5jdGlvbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO1BhdGggc2VsZWN0aW9u LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+JnF1b3Q7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPnRoZXJlIGlzIG5vIG5vdGlvbiBvZiBzeW1t ZXRyeS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5DYW4geW91IHBsZWFzZSBj b25maXJtIHRoYXQgYSBiaWRpcmVjdGlvbmFsIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPndpbGwgYmUgcmVwcmVz ZW50ZWQgYnkgb25lIHNpbmdsZSBTZXJ2aWNlIFBhdGggSWRlbnRpZmllciwgaW5ncmVzcyBzeW1t ZXRyaWMgdG8gZWdyZXNzID88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5QbGVhc2UgYWxs b3cgdXMgdG8gY2xhcmlmeSB0aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5NYW55IFRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5DaHJpc3Rp YW4gS29lbm5pbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPi0t PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5GNSBOZXR3b3JrcyBJ bmMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJt YWlsdG86Y2hyaXN0aWFuQGY1LmNvbSI+Y2hyaXN0aWFuQGY1LmNvbTwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_E8355113905631478EFF04F5AA706E9830F82F04wtlexchp2sandvi_-- From nobody Thu May 26 15:16:41 2016 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A8812DB7F; Thu, 26 May 2016 15:16:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160526221637.14518.93908.idtracker@ietfa.amsl.com> Date: Thu, 26 May 2016 15:16:37 -0700 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-nsh-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 22:16:37 -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 of the IETF. Title : Network Service Header Authors : Paul Quinn Uri Elzur Filename : draft-ietf-sfc-nsh-05.txt Pages : 38 Date : 2016-05-26 Abstract: This document describes a Network Service Header (NSH) inserted onto encapsulated packets or frames to realize service function paths. NSH also provides a mechanism for metadata exchange along the instantiated service path. NSH is the SFC encapsulation required to support the Service Function Chaining (SFC) Architecture (defined in RFC7665). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sfc-nsh-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-05 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 Thu May 26 15:19:32 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A2E12D14E for ; Thu, 26 May 2016 15:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a_Ut_l52sthk for ; Thu, 26 May 2016 15:19:29 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19A4A12DB81 for ; Thu, 26 May 2016 15:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1571; q=dns/txt; s=iport; t=1464301168; x=1465510768; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=Q73Kj5IF6olc7ZowqMdpWcN1LNft5UlRFBNLKwkZByM=; b=SBUpmZUqVjZhEqLlrkkzgymaiSyccbSSNZDlfB5wa67KWZlkfflBNBSs 2Eb1T33Logu/+Y8cuKDF3Dc6/ZCUyqvwhIlS09tNGmcOLfAGeCuRalpG/ 2pHAddC6LzjQDfA+lhn127bGG4u8ONCfrI3ovqdTBJ9OBlRM8itZb62+4 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAgD1dUdX/4YNJK1cgzlWfQa5YwENg?= =?us-ascii?q?XgihW8CgT04FAEBAQEBAQFlHAuEQwEBBAE6PQcLAgEZAQIBAhYJEDIXBAIIAgQ?= =?us-ascii?q?TiCcIDsNBAQEBAQEBAQMBAQEBAQEBAQEehieBdgiCToR+gm2CLgWNZYpSAYV/i?= =?us-ascii?q?CCBaU6EAYhkj0sBHgEBQoNtbgGJFX8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,370,1459814400"; d="scan'208";a="112244405" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 May 2016 22:19:27 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u4QMJRDw006042 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 26 May 2016 22:19:27 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 26 May 2016 17:19:26 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1104.009; Thu, 26 May 2016 17:19:26 -0500 From: "Paul Quinn (paulq)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-ietf-sfc-nsh-05.txt Thread-Index: AQHRt5xIK4mgpbzsZE+VXpQqqZzR7w== Date: Thu, 26 May 2016 22:19:26 +0000 Message-ID: <1B60792E-A394-4171-9DEE-97FCE81D758C@cisco.com> References: <20160526221637.14518.30341.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.17.237] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [sfc] Fwd: New Version Notification for draft-ietf-sfc-nsh-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 22:19:31 -0000 Dear WG, This new version of NSH takes into account the comments that were raised re= : -05. Thank you, Paul > Begin forwarded message: >=20 > From: > Subject: New Version Notification for draft-ietf-sfc-nsh-05.txt > Date: May 26, 2016 at 6:16:37 PM EDT > To: Uri Elzur , Paul Quinn >=20 >=20 > A new version of I-D, draft-ietf-sfc-nsh-05.txt > has been successfully submitted by Paul Quinn and posted to the > IETF repository. >=20 > Name: draft-ietf-sfc-nsh > Revision: 05 > Title: Network Service Header > Document date: 2016-05-26 > Group: sfc > Pages: 38 > URL: https://www.ietf.org/internet-drafts/draft-ietf-sfc-nsh-0= 5.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ > Htmlized: https://tools.ietf.org/html/draft-ietf-sfc-nsh-05 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-05 >=20 > Abstract: > This document describes a Network Service Header (NSH) inserted onto > encapsulated packets or frames to realize service function paths. > NSH also provides a mechanism for metadata exchange along the > instantiated service path. NSH is the SFC encapsulation required to > support the Service Function Chaining (SFC) Architecture (defined in > RFC7665). >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Thu May 26 15:20:14 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5A712DB82 for ; Thu, 26 May 2016 15:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 L9yPOibQ6o81 for ; Thu, 26 May 2016 15:20:12 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8881512D14E for ; Thu, 26 May 2016 15:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1900; q=dns/txt; s=iport; t=1464301212; x=1465510812; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=5IcitsNzI6jgBbdn/vATpx0JYeKu+aB6ukJYrwf9SPE=; b=mQ+Z2CQZepUiX6XYDFpAOLY/eOCtx9aWZ8yjoLgL0ITopAS41NiJ0xtM XwtMXgU8ms5pprtgF21XFotHzcCWrTe8KAHewCKOqN7ohUWj3kf5pyGFx ueUAywz7CoqXbrETtoU0zVFDqfTSBby/2EnunpOR5eRv9gE9ZzT36E4Ry k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAgAfdkdX/40NJK1cgzlWfQa5YwENg?= =?us-ascii?q?XgXC4VvAoE9OBQBAQEBAQEBZRwLhEMBAQEDAQEBATc0CQcLAgEIEQECAQIBFQk?= =?us-ascii?q?QJwsXBggCBBOIJwgOw0EBAQEBAQEBAQEBAQEBAQEBAQEBAQEchieBdoJWhD8/g?= =?us-ascii?q?m2CLgWNZYpSAYV/iCCBaU6EAYMshTiPSwEeAQFCg21uAYkVfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,370,1459814400"; d="scan'208";a="111478312" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 May 2016 22:20:11 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u4QMKBga011335 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 26 May 2016 22:20:11 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 26 May 2016 17:20:10 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1104.009; Thu, 26 May 2016 17:20:10 -0500 From: "Paul Quinn (paulq)" To: "sfc@ietf.org" Thread-Topic: [sfc] New Version Notification for draft-ietf-sfc-nsh-05.txt Thread-Index: AQHRt5xIK4mgpbzsZE+VXpQqqZzR75/MHh+A Date: Thu, 26 May 2016 22:20:10 +0000 Message-ID: References: <20160526221637.14518.30341.idtracker@ietfa.amsl.com> <1B60792E-A394-4171-9DEE-97FCE81D758C@cisco.com> In-Reply-To: <1B60792E-A394-4171-9DEE-97FCE81D758C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.17.237] Content-Type: text/plain; charset="us-ascii" Content-ID: <0497D6A562226D4DA56764D3E96725AF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] New Version Notification for draft-ietf-sfc-nsh-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 22:20:13 -0000 of course that should have read re:-04. Paul > On May 26, 2016, at 6:19 PM, Paul Quinn (paulq) wrote: >=20 > Dear WG, >=20 > This new version of NSH takes into account the comments that were raised = re: -05. >=20 > Thank you, > Paul >=20 >> Begin forwarded message: >>=20 >> From: >> Subject: New Version Notification for draft-ietf-sfc-nsh-05.txt >> Date: May 26, 2016 at 6:16:37 PM EDT >> To: Uri Elzur , Paul Quinn >>=20 >>=20 >> A new version of I-D, draft-ietf-sfc-nsh-05.txt >> has been successfully submitted by Paul Quinn and posted to the >> IETF repository. >>=20 >> Name: draft-ietf-sfc-nsh >> Revision: 05 >> Title: Network Service Header >> Document date: 2016-05-26 >> Group: sfc >> Pages: 38 >> URL: https://www.ietf.org/internet-drafts/draft-ietf-sfc-nsh-= 05.txt >> Status: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ >> Htmlized: https://tools.ietf.org/html/draft-ietf-sfc-nsh-05 >> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-0= 5 >>=20 >> Abstract: >> This document describes a Network Service Header (NSH) inserted onto >> encapsulated packets or frames to realize service function paths. >> NSH also provides a mechanism for metadata exchange along the >> instantiated service path. NSH is the SFC encapsulation required to >> support the Service Function Chaining (SFC) Architecture (defined in >> RFC7665). >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of submis= sion >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Thu May 26 15:53:37 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365E512DB8C for ; Thu, 26 May 2016 15:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 lHLebXhtuuXR for ; Thu, 26 May 2016 15:53:32 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E661012D9EB for ; Thu, 26 May 2016 15:53:31 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id k23so147918430oih.0 for ; Thu, 26 May 2016 15:53:31 -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; bh=dsZIAb5ZS1OCR8XmOYo2qL3hOHHLu2CxzNw+hynZg6A=; b=TK8N/bZUdUcyPaBMSdzE0U4tilTuaYqD2/735w++NLMQqslerpl9gYr+8rAaGvAJu+ pk1GUmeo+GcOo0jEKkw6V2R+GA5bGFH9DCN6fa3xk8ifSWwMeleqWMbem0bjBlSSvsbp nr0yE+KPkAC6vru4SuW7+EL0lgkSh9OjkkCKQPBzrYYea7vfoXAIKa7nfsSYWbC9REqs we9FpmddRE8BvdeCAiMeMXoBLOpyM5YVhGoJIQjCc7jQpwz3T/ueSVqx1fHQwaAOG3Iy JrPDeFIiv0H8ZXFeFWqDrjpK0X8ANjjl4JS0q49ZjgU6hDcKAGrH6jwzab8vIxKXic9+ A75w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dsZIAb5ZS1OCR8XmOYo2qL3hOHHLu2CxzNw+hynZg6A=; b=jEoGQK9ZF8gF6KnC4JXnWlpdhSFI1jx1bOEER61ZBCrWAi6ppKd5he549Xp658K2RG l0MpUcDP/NP4wA4+cMQYrEaKqwaCUAc48Lv9F7L/7lNhWwa5ZtammDeeBvYbVo/k+bbL NS1my1PG55mIC3bDRe3VZjF2qdFDaEGA1/A1S35veJUynALrmI9rE/rBP3anFHSGTwV1 xz+whmr7WL7PGRVpDWqUZzPNABRcnbGHQ7jW3zXb+MPL2DVN7zxGH03n43Z7U+tn/7ca ebllDJFcUOGZJkwtMxLakjUGBekKWwgYrR/pq7hdP8i2+bU/3tJfXRtYRNrod1D/J/gH 1fEQ== X-Gm-Message-State: ALyK8tIIYbsVeZpNX+2gIy2NsSSxPHB/1L584tNWrV/sPKaEZ609Ft5/JmUM0tUdsauIlth1jlZeWLHoKLZGbg== X-Received: by 10.202.75.86 with SMTP id y83mr6439785oia.99.1464303211267; Thu, 26 May 2016 15:53:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.8 with HTTP; Thu, 26 May 2016 15:53:11 -0700 (PDT) In-Reply-To: References: <20160526221637.14518.30341.idtracker@ietfa.amsl.com> <1B60792E-A394-4171-9DEE-97FCE81D758C@cisco.com> From: "Andrew G. Malis" Date: Thu, 26 May 2016 18:53:11 -0400 Message-ID: To: "Paul Quinn (paulq)" Content-Type: multipart/alternative; boundary=001a11c172f0c04d010533c6a8d5 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-ietf-sfc-nsh-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 22:53:35 -0000 --001a11c172f0c04d010533c6a8d5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Paul, Section 13.2.4 still needs revising. Since it=E2=80=99s short, I=E2=80=99ve= included it here: 13.2.4 . MD Class Registry IANA is requested to set up a registry of "MD Class". These are 16- bit values. Registry entries are assigned by using the "IETF Review" policy defined in RFC 5226 [RFC5226 ]. TLV Classes defined by this document are listed below. New values are assigned via Standards Action [RFC5226 ]. 0x0000 to 0x01ff: IETF Consensus 0x0200 to 0x7fff: Expert Review 0xfff6 to 0xfffe: Experimental 0xffff: Reserved In the third line, =E2=80=9CTLV=E2=80=9D should be =E2=80=9CMD=E2=80=9D. In the sixth line, the term =E2=80=9CIETF Consensus=E2=80=9D is no longer u= sed, it=E2=80=99s now =E2=80=9CIETF Review=E2=80=9D. The text in the paragraph states that entries are assigned using the IETF Review policy, but then the registry space is partitioned. So I recommend that the sentence "Registry entries are assigned by using the "IETF Review= =E2=80=9D policy defined in RFC 5226 [RFC5226].=E2=80=9D be removed. It then states =E2=80=9C New values are assigned via Standards Action [RFC5= 226].=E2=80=9D However, that also contradicts the partioning, so that sentence should also be removed. Also a question: Note that "Standards Action" and "IETF Review" are not the same thing. However, if you look through the list of new registries defined in section 13.2, both Standards Action and IETF Review are used for different registries. Is there a reason that they aren=E2=80=99t all one or= the other? Thanks, Andy On Thu, May 26, 2016 at 6:20 PM, Paul Quinn (paulq) wrote= : > of course that should have read re:-04. > > Paul > > > > On May 26, 2016, at 6:19 PM, Paul Quinn (paulq) wrote= : > > > > Dear WG, > > > > This new version of NSH takes into account the comments that were raise= d > re: -05. > > > > Thank you, > > Paul > > > >> Begin forwarded message: > >> > >> From: > >> Subject: New Version Notification for draft-ietf-sfc-nsh-05.txt > >> Date: May 26, 2016 at 6:16:37 PM EDT > >> To: Uri Elzur , Paul Quinn > >> > >> > >> A new version of I-D, draft-ietf-sfc-nsh-05.txt > >> has been successfully submitted by Paul Quinn and posted to the > >> IETF repository. > >> > >> Name: draft-ietf-sfc-nsh > >> Revision: 05 > >> Title: Network Service Header > >> Document date: 2016-05-26 > >> Group: sfc > >> Pages: 38 > >> URL: > https://www.ietf.org/internet-drafts/draft-ietf-sfc-nsh-05.txt > >> Status: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ > >> Htmlized: https://tools.ietf.org/html/draft-ietf-sfc-nsh-05 > >> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh= -05 > >> > >> Abstract: > >> This document describes a Network Service Header (NSH) inserted onto > >> encapsulated packets or frames to realize service function paths. > >> NSH also provides a mechanism for metadata exchange along the > >> instantiated service path. NSH is the SFC encapsulation required to > >> support the Service Function Chaining (SFC) Architecture (defined in > >> RFC7665). > >> > >> > >> > >> > >> 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 > --001a11c172f0c04d010533c6a8d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Paul,

Section 13.2.4 still needs revisi= ng. Since it=E2=80=99s short, I=E2=80=99ve included it here:

= 
13.2.4.  MD Class Registry


   IANA is requested to set up a registry of "MD Class".  These a=
re 16-
   bit values.  Registry entries are assigned by using the "IETF Revie=
w"
   policy defined in RFC 52=
26 [RFC5226].  TLV Classes defined by this
   document are listed below.  New values are assigned via Standards
   Action [RFC5226=
].
   0x0000 to 0x01ff: IETF Consensus
   0x0200 to 0x7fff: Expert Review
   0xfff6 to 0xfffe: Experimental
   0xffff: Reserved

In the third line, =E2= =80=9CTLV=E2=80=9D should be =E2=80=9CMD=E2=80=9D.

In the sixth line, the term =E2=80=9CIETF Consensus=E2=80=9D is no longer = used, it=E2=80=99s now =E2=80=9CIETF Review=E2=80=9D.

<= div>The text in the paragraph states that entries are assigned using the IE= TF Review policy, but then the registry space is partitioned. So I recommen= d that the sentence "Registry entries are assigned by using the "= IETF Review=E2=80=9D policy defined in RFC 5226 [RFC5226].=E2=80=9D be remo= ved.

It then states =E2=80=9C New values are assig= ned via Standards Action [RFC5226].=E2=80=9D However, that also contradicts= the partioning, so that sentence should also be removed.


Also a question: Note that "Standards Action&qu= ot; and "IETF Review" are not the same thing. However, if you loo= k through the list of new registries defined in section 13.2, both Standard= s Action and IETF Review are used for different registries. Is there a reas= on that they aren=E2=80=99t all one or the other?

= Thanks,
Andy


On Thu, May 26, 2016 at 6:20 PM, Paul Quinn= (paulq) <paulq@cisco.com> wrote:
of course that should have read re:-04.

Paul


> On May 26, 2016, at 6:19 PM, Paul Quinn (paulq) <paulq@cisco.com> wrote:
>
> Dear WG,
>
> This new version of NSH takes into account the comments that were rais= ed re: -05.
>
> Thank you,
> Paul
>
>> Begin forwarded message:
>>
>> From: <internet-dra= fts@ietf.org>
>> Subject: New Version Notification for draft-ietf-sfc-nsh-05.txt >> Date: May 26, 2016 at 6:16:37 PM EDT
>> To: Uri Elzur <uri.elzur= @intel.com>, Paul Quinn <paulq= @cisco.com>
>>
>>
>> A new version of I-D, draft-ietf-sfc-nsh-05.txt
>> has been successfully submitted by Paul Quinn and posted to the >> IETF repository.
>>
>> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft= -ietf-sfc-nsh
>> Revision:=C2=A0 =C2=A0 05
>> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Netwo= rk Service Header
>> Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A02016-05-26
>> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sfc >> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A038 >> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-sfc-nsh-05= .txt
>> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/
>> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:= //tools.ietf.org/html/draft-ietf-sfc-nsh-05
>> Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-05 >>
>> Abstract:
>>=C2=A0 This document describes a Network Service Header (NSH) inser= ted onto
>>=C2=A0 encapsulated packets or frames to realize service function p= aths.
>>=C2=A0 NSH also provides a mechanism for metadata exchange along th= e
>>=C2=A0 instantiated service path.=C2=A0 NSH is the SFC encapsulatio= n required to
>>=C2=A0 support the Service Function Chaining (SFC) Architecture (de= fined in
>>=C2=A0 RFC7665).
>>
>>
>>
>>
>> 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

--001a11c172f0c04d010533c6a8d5-- From nobody Thu May 26 17:16:41 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9275712D9B0 for ; Thu, 26 May 2016 17:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.446 X-Spam-Level: X-Spam-Status: No, score=-8.446 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=f5.com 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 AkmJ70dgto_j for ; Thu, 26 May 2016 17:16:37 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD47312DBC1 for ; Thu, 26 May 2016 17:14:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1464308041; x=1495844041; h=from:to:subject:date:message-id:mime-version; bh=FBrAt6qZEjI5t2/9xWdA7NS5bIYn6KSGoaeB4Lpj0kg=; b=O8+0jDaeIG3r4d3lg5fbOOpVJB5dW7vXLRPnnJlMD8KzzXpQaSYOUvXo 5MwLls9mFv8b8ib1NL5/Rn3IeLMV+1H1+5b6fJeSQxeAaB8r4bl0XHsT0 4GE3aMIgLEpK2jrVwkU77Gw70ZF/Yt8Jb0/CCY9iCCuNJ3VKhYiwJRE57 4=; X-IronPort-AV: E=Sophos;i="5.26,371,1459814400"; d="scan'208,217";a="220100788" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP; 27 May 2016 00:14:01 +0000 Received: from SEAEXCHMBX02.olympus.F5Net.com (192.168.15.224) by SEAEXCHMBX07.olympus.F5Net.com (192.168.15.50) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 26 May 2016 17:14:00 -0700 Received: from SEAEXCHMBX02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f]) by seaexchmbx02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f%13]) with mapi id 15.00.1178.000; Thu, 26 May 2016 17:14:00 -0700 From: Sumandra Majee To: "Surendra Kumar (smkumar)" , "Bottorff, Paul" , Christian Koenning , "sfc@ietf.org" Thread-Topic: [sfc] Service Path Identifier (SPI) and symmetry Thread-Index: AQHRt6yqkjM8nquyFEK/9W7Blz8b0A== Date: Fri, 27 May 2016 00:14:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: multipart/alternative; boundary="_000_D36CDD295240Bsmajeef5com_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Service Path Identifier (SPI) and symmetry X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 00:16:40 -0000 --_000_D36CDD295240Bsmajeef5com_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable While I acknowledge it is an issue, there is no need to have a single solut= ion for this. 1. Have two distinct SPI-F and SPI-R. If controller and classifiers are = able to coordinate that then that is one solution. 2. Having SPI-R |=3D HI bit. That simplifies the allocation but it is ag= ain an implementation issue. PathID (fortunately) has many bits and will ha= ve many uses for those bits. 3. Some services and forwarder has complete flow state which makes the r= everse path problem, not a problem. The reverse flow match would automatica= lly forward pkts where it came from. Even in one Armed case the forward pat= h is SIP -> DIP while reverse path is DIP->SIP. It really depends on amount of context information a forwarding entity can = use. From: sfc > on behalf of = Surendra Kumar > Date: Thursday, May 26, 2016 at 11:46 AM To: "Bottorff, Paul" >,= Christian Koenning >, "sfc@iet= f.org" > Subject: Re: [sfc] Service Path Identifier (SPI) and symmetry Hi Paul, In general I can see how having two Service headers may help. In practice however, a single one with high-order bit differentiating the f= orward/reverse name space works well where bi-directional behavior is neede= d and has for us. I support using the high-order bit as an implementation d= etail. One option with MD-TYPE2 may be to use TLVs to carry the other service-head= er, that achieves the desired effect while not taxing all implementations. Surendra. From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Bottorff, Paul Sent: Thursday, May 26, 2016 11:02 AM To: Christian Koenning >; sfc@i= etf.org Subject: Re: [sfc] Service Path Identifier (SPI) and symmetry Hi Christian: A very good question. IMHO the SPI can=92t be bi-directional because the forwarding direction wou= ld be ambiguous for single armed SFs. The reversal problem points out a basic deficiency of the SPI+SI NSH fields= . These fields form the server layer network address (not the transport lay= er address). What we lack is a way to encode the reverse address. The direct method for handling forward and backward addressing is to encode= both a forward and reverse path in the NSH header (SPIF/SPIR). This would = be similar to Ethernet DA/SA or IP SIP/SIP. Such an encoding would be the m= ost flexible way to build the NSH header, however for a more space efficien= t method which offers the minimum modification to the existing NSH fields w= e have had success encoding a reverse address by reserving the high order b= it of the SPI to designate the reverse address. So in this method the SPIF = always has high order bit 0 and the SPIR always has high order bit 1. An SF= or OAM which needs to send along the reverse path can always form the reve= rse address by flipping the high order bit of the SPI. Cheers, Paul From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Christian Koenning Sent: Tuesday, May 17, 2016 12:49 PM To: sfc@ietf.org Subject: [sfc] Service Path Identifier (SPI) and symmetry Good Evening, looking at RFC 7665 Service Function Chaining (SFC) Architecture https://tools.ietf.org/html/rfc7665 there is a clear definition of chain symetry " 2.2. Service Function Chain Symmetry SFCs may be unidirectional or bidirectional. A unidirectional SFC requires that traffic be forwarded through the ordered SFs in one direction (sf1 -> sf2 -> sf3), whereas a bidirectional SFC requires a symmetric path (sf1 -> sf2 -> sf3 and sf3 -> sf2 -> sf1), and in which the SF instances are the same in opposite directions. A hybrid SFC has attributes of both unidirectional and bidirectional SFCs; that is to say some SFs require symmetric traffic, whereas other SFs do not process reverse traffic or are independent of the corresponding forward traffic. ... Further, there are state trade-offs in symmetry. Symmetry may be realized in several ways depending on the SFF and classifier functionality. In some cases, "mirrored" classification (i.e., from Source to Destination and from Destination to Source) policy may be deployed, whereas in others shared state between classifiers may be used to ensure that symmetric flows are correctly identified, then steered along the required SFP. At a high level, there are various common cases. In a non-exhaustive way, there can be for example: o A single classifier (or a small number of classifiers), in which case both incoming and outgoing flows could be recognized at the same classifier, so the synchronization would be feasible by internal mechanisms internal to the classifier. o Stateful classifiers where several classifiers may be clustered and share state. o Fully distributed classifiers, where synchronization needs to be provided through unspecified means. o A classifier that learns state from the egress packets/flows that is then used to provide state for the return packets/flow. o Symmetry may also be provided by stateful forwarding logic in the SFF in some implementations. This is a non-comprehensive list of common cases. " However, when looking at this together with Network Service Header draft-ietf-sfc-nsh-04.txt https://tools.ietf.org/html/draft-ietf-sfc-nsh-04 3.3. Service Path Header " Service Path Identifier (SPI): identifies a service path. Participating nodes MUST use this identifier for Service Function Path selection. " there is no notion of symmetry. Can you please confirm that a bidirectional Service Function Chain will be represented by one single Service Path Identifier, ingress symmetri= c to egress ? Please allow us to clarify this. Many Thanks Christian Koenning -- F5 Networks Inc. christian@f5.com --_000_D36CDD295240Bsmajeef5com_ Content-Type: text/html; charset="Windows-1252" Content-ID: <411C565E9D965D4EA60D2DCD07C95F6E@F5.com> Content-Transfer-Encoding: quoted-printable
While I acknowledge it is an issue, there is no need to have a single = solution for this.

  1. Have two distinct SPI-F and SPI-R. If controller and classifiers are ab= le to coordinate that then that is one solution.
  2. Having SPI-R |=3D = HI bit. That simplifies the allocation but it is again an implementation is= sue. PathID (fortunately) has many bits and will have many uses for those b= its.
  3. Some services and forwarder has complete flow state which make= s the reverse path problem, not a problem. The reverse flow match would aut= omatically forward pkts where it came from. Even in one Armed case the forw= ard path is SIP -> DIP while reverse path is DIP->SIP. 
It really depends on amount of context information a forwarding entity= can use. 


From: sfc <sfc-bounces@ietf.org> on behalf of Surendra Kumar= <smkumar@cisco.com>
Date: Thursday, May 26, 2016 at 11:= 46 AM
To: "Bottorff, Paul" <= paul.bottorff@hpe.com>, Chr= istian Koenning <C.Koenning@F5.com<= /a>>, "sfc@ietf.org" <<= a href=3D"mailto:sfc@ietf.org">sfc@ietf.org>
Subject: Re: [sfc] Service Path Ide= ntifier (SPI) and symmetry

Hi Paul,

 

In general I can see how having two Service headers may help= .

In practice however, a single one with high-order bit differ= entiating the forward/reverse name space works well where bi-directional be= havior is needed and has for us. I support using the high-order bit as an implementation detail.

 

One option with MD-TYPE2 may be to use TLVs to carry the oth= er service-header, that achieves the desired effect while not taxing all im= plementations.

 

Surendra.

 

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Bottorff, Paul
Sent: Thursday, May 26, 2016 11:02 AM
To: Christian Koenning <C.Ko= enning@F5.com>; sfc@ietf.org
Subject: Re: [sfc] Service Path Identifier (SPI) and symmetry

 

Hi Christian:

 

A very good question.

 

IMHO the SPI can=92t be bi-directio= nal because the forwarding direction would be ambiguous for single armed SF= s.


The reversal problem points out a basic deficiency of the SPI+SI NSH fi= elds. These fields form the server layer network address (not the transport= layer address). What we lack is a way to encode the reverse address.

 

The direct method for handling forw= ard and backward addressing is to encode both a forward and reverse path in= the NSH header (SPIF/SPIR). This would be similar to Ethernet DA/SA or IP SIP/SIP. Such an encoding would be the = most flexible way to build the NSH header, however for a more space efficie= nt method which offers the minimum modification to the existing NSH fields = we have had success encoding a reverse address by reserving the high order bit of the SPI to designate the revers= e address. So in this method the SPIF always has high order bit 0 and the S= PIR always has high order bit 1. An SF or OAM which needs to send along the= reverse path can always form the reverse address by flipping the high order bit of the SPI.

 

Cheers,


Paul  

 

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Christian Koenning
Sent: Tuesday, May 17, 2016 12:49 PM
To: sfc@ietf.org
Subject: [sfc] Service Path Identifier (SPI) and symmetry=

 

Good Evening,

 

looking at RFC 7665 <= /p>

Service Function Chaining (SFC) Architecture=

 

there is a clear definition of chain symetry=

 

"

2.2.  Service Function Chain Symmetry

 

   SFCs may be unidirectional or b= idirectional.  A unidirectional SFC

   requires that traffic be forwar= ded through the ordered SFs in one

   direction (sf1 -> sf2 -> = sf3), whereas a bidirectional SFC requires a

   symmetric path (sf1 -> sf2 -= > sf3 and sf3 -> sf2 -> sf1), and in

   which the SF instances are the = same in opposite directions.  A hybrid

   SFC has attributes of both unid= irectional and bidirectional SFCs;

   that is to say some SFs require= symmetric traffic, whereas other SFs

   do not process reverse traffic = or are independent of the

   corresponding forward traffic.<= o:p>

   

   ...

   

    Further, there are state trade= -offs in symmetry.  Symmetry may be

   realized in several ways depend= ing on the SFF and classifier

   functionality.  In some ca= ses, "mirrored" classification (i.e., from

   Source to Destination and from = Destination to Source) policy may be

   deployed, whereas in others sha= red state between classifiers may be

   used to ensure that symmetric f= lows are correctly identified, then

   steered along the required SFP.=  At a high level, there are various

   common cases.  In a non-ex= haustive way, there can be for example:

 

   o  A single classifier (or= a small number of classifiers), in which

      case both incoming and = outgoing flows could be recognized at the

      same classifier, so the= synchronization would be feasible by

      internal mechanisms int= ernal to the classifier.

 

   o  Stateful classifiers wh= ere several classifiers may be clustered

      and share state.

 

   o  Fully distributed class= ifiers, where synchronization needs to be

      provided through unspec= ified means.

 

   o  A classifier that learn= s state from the egress packets/flows that

      is then used to provide= state for the return packets/flow.

 

   o  Symmetry may also be pr= ovided by stateful forwarding logic in the

      SFF in some implementat= ions.

 

   This is a non-comprehensive lis= t of common cases. "

   

 

However, when looking at this together with&= nbsp;

Network Service Header

draft-ietf-sfc-nsh-04.txt<= /p>

 

3.3.  Service Path Header

 

"

   Service Path Identifier (SPI): = identifies a service path.

   Participating nodes MUST use th= is identifier for Service Function

   Path selection.

"

 

there is no notion of symmetry. 

 

 

Can you please confirm that a bidirectional = Service Function Chain 

will be represented by one single Service Pa= th Identifier, ingress symmetric to egress ?

 

 

Please allow us to clarify this.<= /span>

 

Many Thanks

 

Christian Koenning

--

F5 Networks Inc.

 

 --_000_D36CDD295240Bsmajeef5com_-- From nobody Tue May 31 11:02:26 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77C412D1A5 for ; Tue, 31 May 2016 11:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.327 X-Spam-Level: X-Spam-Status: No, score=-8.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 lqfBfODDnlTi for ; Tue, 31 May 2016 11:02:14 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ietfa.amsl.com (Postfix) with ESMTP id D819F12D18E for ; Tue, 31 May 2016 11:02:14 -0700 (PDT) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga102.fm.intel.com with ESMTP; 31 May 2016 11:02:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,396,1459839600"; d="scan'208,217";a="113583387" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by fmsmga004.fm.intel.com with ESMTP; 31 May 2016 11:02:12 -0700 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.240]) by IRSMSX102.ger.corp.intel.com ([169.254.2.10]) with mapi id 14.03.0248.002; Tue, 31 May 2016 19:02:12 +0100 From: "Duarte Cardoso, Igor" To: "Eric Wang (ejwang)" , "sfc@ietf.org" Thread-Topic: What if the SF consumes all the packets? Thread-Index: AQHRteDhhDpGTxui20mcSeoFEXfl75/TYINQ Date: Tue, 31 May 2016 18:02:11 +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: [163.33.239.181] Content-Type: multipart/alternative; boundary="_000_E09EC9A2DDB2914E953966C44BEF9CF6D46EEDIRSMSX103gercorpi_" MIME-Version: 1.0 Archived-At: Cc: "Kent Leung \(kleung\)" Subject: Re: [sfc] What if the SF consumes all the packets? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 18:02:24 -0000 --_000_E09EC9A2DDB2914E953966C44BEF9CF6D46EEDIRSMSX103gercorpi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRXJpYywgS2VudCwNCg0KVGhpcyBkcmFmdCBoYXMgY2FwdHVyZWQgbXkgYXR0ZW50aW9uIHNp bmNlIGl0J3MgYWJvdXQgYSBzdWJqZWN0IHRoYXQgSSd2ZSBhbHNvIGdpdmVuIGEgbGl0dGxlIGJp dCBvZiB0aG91Z2h0LiBIZXJlIGdvZXMgbXkgcmV2aWV3LCBwbGVhc2UgZXhjdXNlIGFueSBwb3Nz aWJsZSBtaXNpbnRlcnByZXRhdGlvbiwgYW5kIHBvaW50IG91dCBpZiB0aGVyZSdzIGFueS4NCg0K SXQgc2VlbXMgbGlrZSBSTyBTRnMgYXJlIGJlaW5nIHRyZWF0ZWQgYXMgb3V0c2lkZSBmdW5jdGlv bnMgbm90IHJlYWxseSBwYXJ0IG9mIHRoZSBTRkMgZG9tYWluLCBsaWtlIG5vbi1TRkMtYXdhcmUg U0ZzIHRoYXQgcmVxdWlyZSB0aGUgU0ZDIHByb3h5IGFzIHRoZSBnYXRlIHRvIHRoZSBTRkMgZG9t YWluLCBhbmQgYSBuZXcga2luZCBvZiBsb2dpY2FsIFNGIGJlaW5nIGludHJvZHVjZWQgdG8gcmVw bGFjZSB0aGVtLCB0aGUgRXh0ZW5kZWQgU0ZDIFByb3h5LCB3aGVuIHRoZSBTRkMgYXJjaGl0ZWN0 dXJlIGNvdWxkIGJlIHNsaWdodGx5ICJleHBsb2l0ZWQiIHRvIGFkZHJlc3MgdGhlIHVzZSBjYXNl IG9mIG1pcnJvcmluZyBwYWNrZXRzIGFuZCBzdGlsbCBlbmQgdXAgc3VwcG9ydGluZyBSTyBTRnMu DQoNCkFib3V0IFJPIEVTcywgbXkgdmlldyBpcyBzcGxpdCBiZXR3ZWVuIHRoaW5raW5nIHRoYXQg aXQgaXMgc2xpZ2h0bHkgb3V0IG9mIHNjb3BlIHZlcnN1cyB0aGF0IGl0IGFjdHVhbGx5IGdvZXMg aW50byB3aGF0IEkgd2FzIHRoaW5raW5nIHRvbyAoZm9yIHRoZSBTRkYgc2NlbmFyaW8gb25seSku DQoNCkRpc2NsYWltZXI6IEZvciB0aGUgaW5kaXZpZHVhbCBjb21tZW50cyBhYm91dCBzcGVjaWZp YyBsaW5lcywgSSBoYWRuJ3QgcmVhZCBhbnl0aGluZyBhZnRlciB0aGUgcG9pbnQgYWJvdXQgd2hp Y2ggSSB3YXMgY29tbWVudGluZy4NCg0KRnJvbSBSRkMgNzY2NToNCj4gICA0LjguICBSZWNsYXNz aWZpY2F0aW9uIGFuZCBCcmFuY2hpbmcNCj4gICBUaGUgU0ZDIGFyY2hpdGVjdHVyZSBzdXBwb3J0 cyByZWNsYXNzaWZpY2F0aW9uIChvciBub24taW5pdGlhbA0KPiAgIGNsYXNzaWZpY2F0aW9uKSBh cyB3ZWxsLiAgQXMgcGFja2V0cyB0cmF2ZXJzZSBhbiBTRlAsDQo+ICAgcmVjbGFzc2lmaWNhdGlv biBtYXkgb2NjdXIgLS0gdHlwaWNhbGx5IHBlcmZvcm1lZCBieSBhIGNsYXNzaWZpY2F0aW9uDQo+ ICAgZnVuY3Rpb24gY28tcmVzaWRlbnQgd2l0aCBhIHNlcnZpY2UgZnVuY3Rpb24uICBSZWNsYXNz aWZpY2F0aW9uIG1heQ0KPiAgIHJlc3VsdCBpbiB0aGUgc2VsZWN0aW9uIG9mIGEgbmV3IFNGUCwg YW4gdXBkYXRlIG9mIHRoZSBhc3NvY2lhdGVkDQo+ICAgbWV0YWRhdGEsIG9yIGJvdGguICBUaGlz IGlzIHJlZmVycmVkIHRvIGFzICJicmFuY2hpbmciLg0KDQoNClJldmlldzoNCg0KUGFnZSAzOg0K PiAgICBSTyBFUzogIEEgUmVjZWl2ZS1Pbmx5IEV4dGVybmFsIFNlcnZpY2Ugbm90IHBhcnRpY2lw YXRpbmcgaW4gU0ZDLg0KPiAgICBTcGVjaWZpY2FsbHksIGFuIFJPIEVTIGlzIG5vdCBhbiBTRi4g IEl0IGlzIG5vdCBhbGxvY2F0ZWQgd2l0aCBhDQo+ICAgIFNlcnZpY2UgSW5kZXggKFNJKSBpbiB0 aGUgU2VydmljZSBGdW5jdGlvbiBQYXRoIChTRlApLiAgSG93ZXZlciwNCj4gICAgaXQgcmVjZWl2 ZXMgcGFja2V0cyBmcm9tIHRoZSBTRkYgb3IgYW4gU0YuDQpJZiBpdCBpcyBub3QgaW5zaWRlIHRo ZSBTRkMgZG9tYWluLCB0aGVuIHdoeSBkb2VzIGl0IGludGVyYWN0IHdpdGggYW4gU0ZGIG9yIGFu IFNGPw0KDQpQYWdlIDQ6DQo+ICAgZXhhbWluZWQgYnkgYSBjaGFpbiBvZiBzZXJ2aWNlcyBiZWZv cmUgdGhleSByZWFjaCB0aGUgc2VydmVyLiAgVGhlDQo+ICAgdGhyZWUgc2VydmljZSBmdW5jdGlv bnMsIEREb1MsIElEUyBhbmQgRmlyZXdhbGwsIGNvbXBvc2UgYW4gU0ZDLg0KSSBhZ3JlZSwgdGhl eSBjb21wb3NlIGFuIFNGQy4NCg0KPiAgIEVhY2ggU0YgaW5jbHVkaW5nIHRoZSBJRFMgU0YgaXMg YWxsb2NhdGVkIHdpdGggYSBTZXJ2aWNlIEluZGV4IChTSSkNCj4gICBpbiB0aGUgU0ZQLiAgVGhl IElEUyBTRiBpcyBhIGZ1bmRhbWVudGFsIHBhcnQgb2YgdGhlIHNlcnZpY2UgY2hhaW4NClRoaXMg aXMgd2hlcmUgSSB3b3VsZCBsaWtlIHRvIGRlYmF0ZSAtIHNob3VsZCB0aGUgMyBvZiB0aGVtIHJl YWxseSBiZSBpbiB0aGUgc2FtZSBTRlA/DQpJIGFzayB0aGlzIGJlY2F1c2UgdGhlcmUgYXJlIGVz c2VudGlhbGx5IDIgInBhdGhzIiBiZWluZyB0YWtlbiBieSB0aGUgcGFja2V0cyAoZXZlbiB0aG91 Z2ggb25seSBvbmUgaXMgdXNlZCB0byBvdXRwdXQpLiBUaGUgZmlyc3QgKG1haW4pIG9uZSBpbmNs dWRlcyBmdW5jdGlvbiBERG9TIGFuZCBGaXJld2FsbCwgd2hpbGUgdGhlIHNlY29uZCBpcyBhbiAi Uk8gcGF0aCIgY29tcG9zZWQgYnkgZnVuY3Rpb25zIEREb1MgYW5kIElEUy4gU28gdGhpcyBpcyBh IGJyYW5jaGluZyBTRkMgYWZ0ZXIgRERvUy4gSG93ZXZlciwgaXQgaGFzIG9uZSBtYWpvciBkaWZm ZXJlbmNlIGluIHRoYXQgaXQncyBub3QgcmVhbGx5IGJyYW5jaGluZywgYnV0IHJlcGxpY2F0aW5n Lg0KDQo+ICAgRXh0ZW5kaW5nIHRoZSBTRkMgZnJhbWV3b3JrIHRvIFJPIFNGIGVuYWJsZXMgYSB1 bmlmaWVkIFNGQyBwb2xpY3kNCj4gIG1vZGVsIGZvciBTRkMgYWRtaW5pc3RyYXRvcnMuICBUaGUg YWRtaW5pc3RyYXRvciBvbmx5IG5lZWRzIHRvIG1hbmFnZQ0KSSB0aGluayB0aGF0IHJhdGhlciB0 aGFuIG92ZXJsb2FkaW5nIFNGUHMgd2l0aCBSTyBhbmQgbm9uLVJPIFNGcywgcGVyaGFwcyB3ZSBz aG91bGQgdXNlIHRoZSBmbGV4aWJpbGl0eSBvZiBTRkMgRW5jYXBzdWxhdGlvbiBhbmQgU0ZQcyB0 byBvdXIgYWR2YW50YWdlLiBQbGVhc2UgY2hlY2sgd2hlbiBJIG1lbnRpb24gYSBDbGFzc2lmaWVy IHJlcGxpY2F0aW5nIHRyYWZmaWMuDQoNCj4gICB0aHJlYXQgYW5hbHlzaXMuICBXaGVuIGRvaW5n IHNvLCBpdCBpcyBkZXNpcmVkIHRoYXQgdGhlIGNvbnN0cnVjdGlvbg0KPiAgIG9mIHRoZSBTRlAg aXMgbm90IGFmZmVjdGVkLiAgVGhhdCBpcywgdGhlIFNlcnZpY2UgUGF0aCBJRCAoU1BJRCkgYW5k DQo+ICAgU0kgZm9yIGVhY2ggb2YgdGhlIFNGcyBpbiB0aGUgU0ZQIHJlbWFpbiB1bmNoYW5nZWQu DQpJIGFncmVlLg0KDQpQYWdlIDU6DQo+ICAgQW4gUk8gRVMgc3RpbGwgcmVxdWlyZXMgc3VwcG9y dCBmcm9tIFNGQyBlbGVtZW50cyBpbmNsdWRpbmcgU0ZGIGFuZA0KPiAgIFNGIGZvciByZWNlaXZp bmcgcGFja2V0cy4gIEJlY2F1c2UgYW4gUk8gRVMgZG9lcyBub3Qgc2VuZCBiYWNrDQo+ICAgcGFj a2V0cywgaXQgbXVzdCByZWNlaXZlIHJlcGxpY2F0aW9uIG9mIHRoZSBwYWNrZXRzLiAgRGVwZW5k aW5nIG9uDQpQYXJ0aWFsbHkgYWdyZWUgc2luY2UgSSB3b3VsZCBleHBlY3QgdGhlIHNhbWUgc3Rh dGVtZW50IHRvIGJlIG1hZGUgYWJvdXQgYSBub3JtYWwgUk8gU0YuIEFsc28sIHRoZSBTRkYgbWF5 IG5vdCBiZSB0aGUgYmVzdCBwbGFjZSB0byBleGVjdXRlIHRoZSByZXBsaWNhdGlvbi4gT24gb25l IGhhbmQgdGhlIFNGRiBjb3VsZCBkbyBpdCwgbWVhbmluZyB0aGF0IGFuIGV4aXN0aW5nIFNGUCB3 b3VsZCBhbHdheXMgYmUgcmV1c2VkLiBPbiB0aGUgb3RoZXIgaGFuZCwgdGhlIENsYXNzaWZpZXIg Y291bGQgZG8gaXQgc2luY2UgaXQncyB0aGUgZW50aXR5IHRoYXQgaW4gcHJhY3RpY2UgZG9lcyBi cmFuY2hpbmcgZGVwZW5kaW5nIG9uIGRpZmZlcmVudCBjcml0ZXJpYSBidXQsIGFsdGhvdWdoIG5v dCBtYW5kYXRvcnksIGl0IHNob3VsZCBoYXZlIGEgZGlmZmVyZW50IFNGUCBiZWNhdXNlIGEgZGlm ZmVyZW50IGFjdGlvbiB3YXMgdGFrZW4gYnkgdGhlIENsYXNzaWZpZXIgYW5kIHRodXMgYSBkaWZm ZXJlbnQgcGF0aCB0YWtlbiBieSB0aGUgcGFja2V0cyAtIGFuZCBhbHNvIGhlbHBzIG9uIHRyYWNp bmcgYW5kIG1vbml0b3JpbmcuDQoNClBhZ2UgNzoNCj4gICB0aGF0IHBhY2tldCBiYWNrIHRvIHRo ZSBTRkYuICBUaGlzIGNhcGFiaWxpdHkgaXMgYW4gZXh0ZW5zaW9uIHRvIHRoZQ0KPiAgIGN1cnJl bnQgU0ZDIFByb3h5IGFzIGRlZmluZWQgaW4gKFtSRkM3NjY1XSkuDQpUaGUgU0ZDIFByb3h5IGlz IG1lYW50IHRvIGJlIHRoZSAidHJhbnNsYXRvciIgZm9yIG5vbi1TRkMtYXdhcmUgU0ZzLCBhbmQg dGhlIEV4dGVuZGVkIFNGQyBQcm94eSBzZWVtcyB0byBoYXZlIG5vIHJlbGF0aW9uc2hpcCB3aXRo IHRoZSBmb3JtZXIgaW4gdGhhdCByZWdhcmQuIEhvd2V2ZXIsIGZyb20gdGhlIGNoYWluJ3MgcG9p bnQgb2YgdmlldywgaXQncyBkZWZpbml0ZWx5IGFuIFNGQyBQcm94eS4NCg0KUGFnZSA5Og0KPiAg IGFuYWx5c2lzLCBwYWNrZXQgZGF0YSByZXBsaWNhdGlvbiBtYXkgYmUgY29uZHVjdGVkIGJ5IGFu IFNGIGNhcGFibGUNCj4gICBvZiBpZGVudGlmeWluZyBmaWxlIGJvdW5kYXJ5IGluIHRoZSBwYWNr ZXQgc3RyZWFtLiAgVGhlIFJPIEVTIHdvdWxkDQo+ICAgYmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBT RiBhbmQgcmVjZWl2ZXMgcGFja2V0IGRhdGEgZnJvbSB0aGUgU0YNCklzIHRoaXMgc3RpbGwgaW4g dGhlIHNjb3BlIG9mIHRoZSBkcmFmdD8gSXQgc2VlbXMgdG8gYmUgc29tZXRoaW5nIHVwIHRvIHRo ZSBTRiB0byBleGVjdXRlLCBhbmQgdGhlcmUncyBhbiBpbmZpbml0ZSBhbW91bnQgb2YgdGhpbmdz IHRoYXQgY291bGQgYmUgZG9uZSBieSBhbiBTRi4NCg0KPiAgIEFsdGVybmF0aXZlbHksIGZvciB1 c2UgY2FzZXMgc3VjaCBhcyBnZW5lcmljIHBhY2tldCBjYXB0dXJlIGZvcg0KPiAgIHRyb3VibGVz aG9vdGluZywgdGhlIFNGRiBtYXkgY2Fycnkgb3V0IHRoZSBwYWNrZXQgcmVwbGljYXRpb24gYW5k DQo+ICAgZm9yd2FyZGluZyB3b3JrLiAgSGlnaGVyIHBlcmZvcm1hbmNlIG1heSBiZSBhY2hpZXZl ZCB3aXRoIGhhcmR3YXJlDQo+ICAgYmFzZWQgU0ZGLg0KU2VlIHdoYXQgSSB3YXMgZW52aXNpb25p bmcgYXQgdGhlIGVuZCBvZiBteSByZXZpZXcuDQoNClBhZ2UgMTE6DQpXaGVyZSB0aGUgc2NlbmFy aW8gdGhhdCBtYWRlIHVzZSBvZiBhbiBFeHRlbmRlZCBTRkMgUHJveHkgd2FzIHBlcmZlY3RseSBh Y2hpZXZhYmxlIChiZWNhdXNlIHRoZSBiYXNlIFNGQyBhYnN0cmFjdGlvbiB3YXMga2VwdCB1bnRv dWNoZWQgLSBhcyBpdCBlc3NlbnRpYWxseSByZXVzZXMgdGhlIGV4aXN0aW5nIFNGQyBQcm94eSBj b25jZXB0IGJ1dCBkb2VzIHNvbWV0aGluZyBkaWZmZXJlbnQgYmVoaW5kIGl0KSwgdGhlIG90aGVy IHNjZW5hcmlvICh3aGVyZSBhbiBTRkYgaXMgdXNlZCB0byByZXBsaWNhdGUgdHJhZmZpYykgY2Fu bm90IHlldCBiZSBzdXBwb3J0ZWQsIGV2ZW4gdGFraW5nIGludG8gYWNjb3VudCBkcmFmdC1pZXRm LXNmYy1uc2gtMDUsIHNpbmNlIGEgc2luZ2xlIG5leHQtaG9wIG11c3QgYmUgc2VsZWN0ZWQgYnkg dGhlIFNGRi4NCg0KUGFnZSAxNjoNCkRyYWZ0cyBkcmFmdC1pZXRmLXNmYy1uc2gtMDUgYW5kIGRy YWZ0LWlldGYtc2ZjLWNvbnRyb2wtcGxhbmUtMDYgYXJlIG91dC4NCg0KDQpMZXQgbWUgc2hhcmUg dGhlIHNvbHV0aW9uIEkgaGFkIG1pbmQuIEknbGwgYXBwcmVjaWF0ZSBmZWVkYmFjayBvbiB0aGlz Og0KICAgICAgICAgICAgICAgIC0gQWN0aW9ucyBpbiB0aGUgQ2xhc3NpZmllciAoYmVzaWRlcyB1 cGRhdGluZyBtZXRhZGF0YSwgU0ZQIGluZm9ybWF0aW9uIGFuZCBzZW5kaW5nLCBpdCBjb3VsZCBh bHNvIHN1cHBvcnQgcmVwbGljYXRpb24pOw0KICAgICAgICAgICAgICAgIC0gQWx0ZXJuYXRpdmVs eSwgc3VwcG9ydCBzZXRzIG9mIE5IcyB3aGVuIGZvcndhcmRpbmcgaW5zdGVhZCBvZiBzaW5nbGUg TkhzIGluIHRoZSBTRkYgZm9yd2FyZGluZyB0YWJsZSAodG8gYmUgdXNlZCBpbiBwYXJhbGxlbCk7 DQogICAgICAgICAgICAgICAgLSBVcGRhdGUgY29udHJvbCBwbGFuZSB0byBhY2NvbW1vZGF0ZSBl aXRoZXIgdGhlIHNldHMgb2YgTkhzIG9yIHRoZSBuZXcga2luZCBvZiBhY3Rpb24gZm9yIHRoZSBD bGFzc2lmaWVyOw0KICAgICAgICAgICAgICAgIC0gTm8gbmVlZCB0byBvdmVybG9hZCB0aGUgbW9k ZWwgd2l0aCBhbiBFeHRlbmRlZCBTRkMgUHJveHkuDQoNCk15IG1haW4gY29uY2VybnMgYWJvdXQg dGhlIHByb3Bvc2VkIHNvbHV0aW9uIGluIGRyYWZ0LXdhbmctc2ZjLXJlY2VpdmUtb25seS0wMDoN CiAgICAgICAgICAgICAgICAtIFBvdGVudGlhbCBhZGRpdGlvbmFsIGRlbGF5cyBhbmQgcGVyZm9y bWFuY2UgbG9zcyBpbnRyb2R1Y2VkIGJ5IGxpbmVhcmx5IGluc2VydGluZyB0aGUgRXh0ZW5kZWQg U0ZDIFByb3h5IGZ1bmN0aW9uIGZvciB0aGUgc2FrZSBvZiBwYXJhbGxlbGl6aW5nIHRyYWZmaWM7 DQogICAgICAgICAgICAgICAgLSBSTyBTRnMgYXJlIGJlaW5nIHRyZWF0ZWQgYXMgb3V0c2lkZSBm dW5jdGlvbnMgbm90IHJlYWxseSBwYXJ0IG9mIHRoZSBTRkMgZG9tYWluLCBsaWtlIG5vbi1TRkMt YXdhcmUgU0ZzIHRoYXQgcmVxdWlyZSB0aGUgU0ZDIHByb3h5IGFzIHRoZSBnYXRlIHRvIHRoZSBT RkMgZG9tYWluLCBhbmQgYSBuZXcga2luZCBvZiBsb2dpY2FsIFNGIGJlaW5nIGludHJvZHVjZWQg dG8gcmVwbGFjZSB0aGVtOw0KICAgICAgICAgICAgICAgIC0gU3BlY2lmaWNhbGx5IGF0IHRoZSBT RkYtYmFzZWQgcmVwbGljYXRpb24gc2NlbmFyaW8sIHRoZXJlIGlzIHRoZSBuZWVkIHRvIGZvcm1h bGx5IGV4dGVuZCB0aGUgb3JpZ2luYWwgZGVmaW5pdGlvbnMgb2YgU0ZGIGFuZCBTRkYgbWFwcGlu ZyB0YWJsZSAoZXNzZW50aWFsbHkgc3VwcG9ydGluZyB0aGUgIkNvcHkiIGZpZWxkIGluIHRoZSBT RkYgZm9yd2FyZGluZyB0YWJsZSBwcmVzZW50ZWQpOw0KICAgICAgICAgICAgICAgIC0gV2hhdCBo YXBwZW5zIGlmIHlvdSBuZWVkIHRvIHJlcGxpY2F0ZSB0cmFmZmljIHRvIG1vcmUgdGhhbiBhIHNp bmdsZSBhZGRpdGlvbmFsIGZ1bmN0aW9uPw0KDQpNeSBtYWluIGNvbmNlcm5zIGFib3V0IHRoZSBz b2x1dGlvbiBJIGhhZCBpbiBtaW5kOg0KICAgICAgICAgICAgICAgIC0gUG90ZW50aWFsIHBlcmZv cm1hbmNlIGxvc3MgaW4gU0ZGIG9yIENsYXNzaWZpZXIgaWYgYW55IG9mIHRoZW0gYXJlIHJlc3Bv bnNpYmxlIGZvciB0aGUgcmVwbGljYXRpb24gYWN0aW9uOw0KICAgICAgICAgICAgICAgIC0gSWYg dGhlIFNGRiBpcyBjaG9zZW4gZm9yIHJlcGxpY2F0aW9uLCB0aGVyZSBpcyB0aGUgbmVlZCB0byBm b3JtYWxseSBleHRlbmQgdGhlIG9yaWdpbmFsIGRlZmluaXRpb25zIG9mIFNGRiBhbmQgU0ZGIFtO U0hdIG1hcHBpbmcgdGFibGUuDQoNCkJlc3QgcmVnYXJkcywNCklnb3IuDQoNCkZyb206IHNmYyBb bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJpYyBXYW5nIChlandh bmcpDQpTZW50OiBUdWVzZGF5LCBNYXkgMjQsIDIwMTYgNjoyMyBQTQ0KVG86IHNmY0BpZXRmLm9y Zw0KQ2M6IEtlbnQgTGV1bmcgKGtsZXVuZykgPGtsZXVuZ0BjaXNjby5jb20+DQpTdWJqZWN0OiBb c2ZjXSBXaGF0IGlmIHRoZSBTRiBjb25zdW1lcyBhbGwgdGhlIHBhY2tldHM/DQoNCkhlbGxvIGV2 ZXJ5b25lLA0KDQpTbyBmYXIgbW9zdCBvZiB0aGUgc2VydmljZSBmdW5jdGlvbnMgaW4gdGhlIFNG QyBmcmFtZXdvcmsgZm9yd2FyZCBwYWNrZXRzIGJhY2sgdG8gdGhlIFNGRi4gIFRoZXJlIGlzIGFu b3RoZXIgc2V0IG9mIFNGcyB0aGF0IHJlY2VpdmVzIHBhY2tldHMgYnV0IGRvZXMgbm90IGZvcndh cmQgdGhlbSBvdXQuICBBbmFseXRpYyBmdW5jdGlvbnMgYW5kIElEUyBhcmUgYSBmZXcgZXhhbXBs ZXMuICBUaGV5IGFyZSAicGFja2V0IHNpbmtzIiBvciDigJxyZWNlaXZlLW9ubHnigJ0gU0ZzLg0K DQpTb21lIGNoYWxsZW5nZXMgZm9yIHRob3NlIFNGcyB0byBvcGVyYXRlIGluIFNGQzoNCg0KLSBC ZWluZyBwYXJ0IG9mIGFuIFNGUCAtIFRoZXkgYXJlIG1hbmFnZWQgYXMgU0YgZm9yIHNpbXBsZSBh bmQgY29uc2lzdGVudCBTRkMgcG9saWN5LCBidXQgdGhleSBkbyBub3QgZWdyZXNzIHRyYWZmaWMN Ci0gUGFja2V0IHJlcGxpY2F0aW9uIC0gdGhvc2UgU0ZzIG5lZWQgdG8gdGFrZSBhIGNvcHkgb2Yg dGhlIHBhY2tldHMgc28gdGhhdCB0aGUgb3JpZ2luYWwgb25lcyBjb250aW51ZSBvbiB0aGUgcGF0 aA0KLSBTZXJ2aWNlIGluZGV4IGRlY3JlbWVudGluZyAtIHBhY2tldHMg4oCccGFzc2luZ+KAnSBz dWNoIGFuIFNGIG5lZWQgdG8gaGF2ZSB0aGVpciBTSSBkZWNyZW1lbnRlZCBiZWZvcmUgcmVhY2hp bmcgdGhlIG5leHQgU0YNCg0KV2UgcHVibGlzaGVkIGEgZHJhZnQgYXR0ZW1wdGluZyB0byBhZGRy ZXNzIHRoZSBuZWVkIGZvciBzdXBwb3J0aW5nIHRoaXMgc2V0IG9mIFNGcywgYXMgYSBjb21wbGVt ZW50YXJ5IHRvIHRoZSBTRkMgZnJhbWV3b3JrIHRvZGF5Lg0KaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXdhbmctc2ZjLXJlY2VpdmUtb25seS0wMA0KDQpXb3VsZCBhcHByZWNpYXRl IHlvdXIgZmVlZGJhY2suDQoNClJlZ2FyZHMsDQotRXJpYw0KDQo= --_000_E09EC9A2DDB2914E953966C44BEF9CF6D46EEDIRSMSX103gercorpi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFp bEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBFcmljLCBLZW50 LDxvOnA+PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoaXMgZHJh ZnQgaGFzIGNhcHR1cmVkIG15IGF0dGVudGlvbiBzaW5jZSBpdCdzIGFib3V0IGEgc3ViamVjdCB0 aGF0IEkndmUgYWxzbyBnaXZlbiBhIGxpdHRsZSBiaXQgb2YgdGhvdWdodC4gSGVyZSBnb2VzIG15 IHJldmlldywgcGxlYXNlIGV4Y3VzZSBhbnkgcG9zc2libGUNCiBtaXNpbnRlcnByZXRhdGlvbiwg YW5kIHBvaW50IG91dCBpZiB0aGVyZSdzIGFueS4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5JdCBzZWVtcyBsaWtlIFJPIFNGcyBhcmUgYmVpbmcgdHJlYXRlZCBh cyBvdXRzaWRlIGZ1bmN0aW9ucyBub3QgcmVhbGx5IHBhcnQgb2YgdGhlIFNGQyBkb21haW4sIGxp a2Ugbm9uLVNGQy1hd2FyZSBTRnMgdGhhdCByZXF1aXJlIHRoZSBTRkMgcHJveHkgYXMgdGhlIGdh dGUgdG8NCiB0aGUgU0ZDIGRvbWFpbiwgYW5kIGEgbmV3IGtpbmQgb2YgbG9naWNhbCBTRiBiZWlu ZyBpbnRyb2R1Y2VkIHRvIHJlcGxhY2UgdGhlbSwgdGhlIEV4dGVuZGVkIFNGQyBQcm94eSwgd2hl biB0aGUgU0ZDIGFyY2hpdGVjdHVyZSBjb3VsZCBiZSBzbGlnaHRseSAmcXVvdDtleHBsb2l0ZWQm cXVvdDsgdG8gYWRkcmVzcyB0aGUgdXNlIGNhc2Ugb2YgbWlycm9yaW5nIHBhY2tldHMgYW5kIHN0 aWxsIGVuZCB1cCBzdXBwb3J0aW5nIFJPIFNGcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkFib3V0IFJPIEVTcywgbXkgdmlldyBpcyBzcGxpdCBiZXR3ZWVuIHRo aW5raW5nIHRoYXQgaXQgaXMgc2xpZ2h0bHkgb3V0IG9mIHNjb3BlIHZlcnN1cyB0aGF0IGl0IGFj dHVhbGx5IGdvZXMgaW50byB3aGF0IEkgd2FzIHRoaW5raW5nIHRvbyAoZm9yIHRoZSBTRkYgc2Nl bmFyaW8NCiBvbmx5KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkRpc2NsYWltZXI6IEZvciB0aGUgaW5kaXZpZHVhbCBjb21tZW50cyBhYm91dCBzcGVjaWZpYyBs aW5lcywgSSBoYWRuJ3QgcmVhZCBhbnl0aGluZyBhZnRlciB0aGUgcG9pbnQgYWJvdXQgd2hpY2gg SSB3YXMgY29tbWVudGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkZyb20gUkZDIDc2NjU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZndDsmbmJzcDsmbmJzcDsgNC44 LiZuYnNwOyBSZWNsYXNzaWZpY2F0aW9uIGFuZCBCcmFuY2hpbmc8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Jmd0OyZuYnNwOyZuYnNwOyBUaGUgU0ZDIGFyY2hpdGVjdHVyZSBzdXBwb3J0cyByZWNsYXNzaWZp Y2F0aW9uIChvciBub24taW5pdGlhbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mZ3Q7Jm5ic3A7Jm5ic3A7 IGNsYXNzaWZpY2F0aW9uKSBhcyB3ZWxsLiZuYnNwOyBBcyBwYWNrZXRzIHRyYXZlcnNlIGFuIFNG UCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmd0OyZuYnNwOyZuYnNwOyByZWNsYXNzaWZpY2F0aW9uIG1h eSBvY2N1ciAtLSB0eXBpY2FsbHkgcGVyZm9ybWVkIGJ5IGEgY2xhc3NpZmljYXRpb248bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Jmd0OyZuYnNwOyZuYnNwOyBmdW5jdGlvbiBjby1yZXNpZGVudCB3aXRoIGEg c2VydmljZSBmdW5jdGlvbi4mbmJzcDsgUmVjbGFzc2lmaWNhdGlvbiBtYXk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jmd0OyZuYnNwOyZuYnNwOyByZXN1bHQgaW4gdGhlIHNlbGVjdGlvbiBvZiBhIG5ldyBT RlAsIGFuIHVwZGF0ZSBvZiB0aGUgYXNzb2NpYXRlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mZ3Q7Jm5i c3A7Jm5ic3A7IG1ldGFkYXRhLCBvciBib3RoLiZuYnNwOyBUaGlzIGlzIHJlZmVycmVkIHRvIGFz ICZxdW90O2JyYW5jaGluZyZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZXZpZXc6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5QYWdlIDM6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgUk8gRVM6Jm5ic3A7IEEgUmVjZWl2ZS1Pbmx5IEV4dGVybmFs IFNlcnZpY2Ugbm90IHBhcnRpY2lwYXRpbmcgaW4gU0ZDLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNwZWNpZmljYWxseSwgYW4gUk8gRVMgaXMgbm90IGFuIFNGLiZu YnNwOyBJdCBpcyBub3QgYWxsb2NhdGVkIHdpdGggYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFNlcnZpY2UgSW5kZXggKFNJKSBpbiB0aGUgU2VydmljZSBGdW5jdGlv biBQYXRoIChTRlApLiZuYnNwOyBIb3dldmVyLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGl0IHJlY2VpdmVzIHBhY2tldHMgZnJvbSB0aGUgU0ZGIG9yIGFuIFNGLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5JZiBpdCBpcyBub3QgaW5zaWRlIHRoZSBTRkMgZG9tYWluLCB0aGVu IHdoeSBkb2VzIGl0IGludGVyYWN0IHdpdGggYW4gU0ZGIG9yIGFuIFNGPzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UGFnZSA0OjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m Z3Q7Jm5ic3A7Jm5ic3A7IGV4YW1pbmVkIGJ5IGEgY2hhaW4gb2Ygc2VydmljZXMgYmVmb3JlIHRo ZXkgcmVhY2ggdGhlIHNlcnZlci4mbmJzcDsgVGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZndDsmbmJz cDsmbmJzcDsgdGhyZWUgc2VydmljZSBmdW5jdGlvbnMsIEREb1MsIElEUyBhbmQgRmlyZXdhbGws IGNvbXBvc2UgYW4gU0ZDLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGFncmVlLCB0aGV5IGNvbXBvc2Ug YW4gU0ZDLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmd0OyZu YnNwOyZuYnNwOyBFYWNoIFNGIGluY2x1ZGluZyB0aGUgSURTIFNGIGlzIGFsbG9jYXRlZCB3aXRo IGEgU2VydmljZSBJbmRleCAoU0kpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZndDsmbmJzcDsmbmJzcDsg aW4gdGhlIFNGUC4mbmJzcDsgVGhlIElEUyBTRiBpcyBhIGZ1bmRhbWVudGFsIHBhcnQgb2YgdGhl IHNlcnZpY2UgY2hhaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhpcyBpcyB3aGVyZSBJIHdvdWxkIGxp a2UgdG8gZGViYXRlIC0gc2hvdWxkIHRoZSAzIG9mIHRoZW0gcmVhbGx5IGJlIGluIHRoZSBzYW1l IFNGUD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhc2sgdGhpcyBiZWNhdXNlIHRoZXJlIGFyZSBlc3Nl bnRpYWxseSAyICZxdW90O3BhdGhzJnF1b3Q7IGJlaW5nIHRha2VuIGJ5IHRoZSBwYWNrZXRzIChl dmVuIHRob3VnaCBvbmx5IG9uZSBpcyB1c2VkIHRvIG91dHB1dCkuIFRoZSBmaXJzdCAobWFpbikg b25lIGluY2x1ZGVzIGZ1bmN0aW9uDQogRERvUyBhbmQgRmlyZXdhbGwsIHdoaWxlIHRoZSBzZWNv bmQgaXMgYW4gJnF1b3Q7Uk8gcGF0aCZxdW90OyBjb21wb3NlZCBieSBmdW5jdGlvbnMgRERvUyBh bmQgSURTLiBTbyB0aGlzIGlzIGEgYnJhbmNoaW5nIFNGQyBhZnRlciBERG9TLiBIb3dldmVyLCBp dCBoYXMgb25lIG1ham9yIGRpZmZlcmVuY2UgaW4gdGhhdCBpdCdzIG5vdCByZWFsbHkgYnJhbmNo aW5nLCBidXQgcmVwbGljYXRpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mZ3Q7Jm5ic3A7Jm5ic3A7IEV4dGVuZGluZyB0aGUgU0ZDIGZyYW1ld29yayB0byBS TyBTRiBlbmFibGVzIGEgdW5pZmllZCBTRkMgcG9saWN5PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZndDsg Jm5ic3A7bW9kZWwgZm9yIFNGQyBhZG1pbmlzdHJhdG9ycy4mbmJzcDsgVGhlIGFkbWluaXN0cmF0 b3Igb25seSBuZWVkcyB0byBtYW5hZ2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB0aGF0IHJh dGhlciB0aGFuIG92ZXJsb2FkaW5nIFNGUHMgd2l0aCBSTyBhbmQgbm9uLVJPIFNGcywgcGVyaGFw cyB3ZSBzaG91bGQgdXNlIHRoZSBmbGV4aWJpbGl0eSBvZiBTRkMgRW5jYXBzdWxhdGlvbiBhbmQg U0ZQcyB0byBvdXIgYWR2YW50YWdlLiBQbGVhc2UNCiBjaGVjayB3aGVuIEkgbWVudGlvbiBhIENs YXNzaWZpZXIgcmVwbGljYXRpbmcgdHJhZmZpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZndDsmbmJzcDsmbmJzcDsgdGhyZWF0IGFuYWx5c2lzLiZuYnNwOyBX aGVuIGRvaW5nIHNvLCBpdCBpcyBkZXNpcmVkIHRoYXQgdGhlIGNvbnN0cnVjdGlvbjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mZ3Q7Jm5ic3A7Jm5ic3A7IG9mIHRoZSBTRlAgaXMgbm90IGFmZmVjdGVkLiZu YnNwOyBUaGF0IGlzLCB0aGUgU2VydmljZSBQYXRoIElEIChTUElEKSBhbmQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jmd0OyZuYnNwOyZuYnNwOyBTSSBmb3IgZWFjaCBvZiB0aGUgU0ZzIGluIHRoZSBTRlAg cmVtYWluIHVuY2hhbmdlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlBhZ2UgNTo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Jmd0OyZuYnNwOyZuYnNwOyBBbiBSTyBFUyBzdGlsbCByZXF1aXJlcyBzdXBwb3J0IGZyb20gU0ZD IGVsZW1lbnRzIGluY2x1ZGluZyBTRkYgYW5kPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZndDsmbmJzcDsm bmJzcDsgU0YgZm9yIHJlY2VpdmluZyBwYWNrZXRzLiZuYnNwOyBCZWNhdXNlIGFuIFJPIEVTIGRv ZXMgbm90IHNlbmQgYmFjazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mZ3Q7Jm5ic3A7Jm5ic3A7IHBhY2tl dHMsIGl0IG11c3QgcmVjZWl2ZSByZXBsaWNhdGlvbiBvZiB0aGUgcGFja2V0cy4mbmJzcDsgRGVw ZW5kaW5nIG9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlBhcnRpYWxseSBhZ3JlZSBzaW5jZSBJIHdvdWxk IGV4cGVjdCB0aGUgc2FtZSBzdGF0ZW1lbnQgdG8gYmUgbWFkZSBhYm91dCBhIG5vcm1hbCBSTyBT Ri4gQWxzbywgdGhlIFNGRiBtYXkgbm90IGJlIHRoZSBiZXN0IHBsYWNlIHRvIGV4ZWN1dGUgdGhl IHJlcGxpY2F0aW9uLiBPbg0KIG9uZSBoYW5kIHRoZSBTRkYgY291bGQgZG8gaXQsIG1lYW5pbmcg dGhhdCBhbiBleGlzdGluZyBTRlAgd291bGQgYWx3YXlzIGJlIHJldXNlZC4gT24gdGhlIG90aGVy IGhhbmQsIHRoZSBDbGFzc2lmaWVyIGNvdWxkIGRvIGl0IHNpbmNlIGl0J3MgdGhlIGVudGl0eSB0 aGF0IGluIHByYWN0aWNlIGRvZXMgYnJhbmNoaW5nIGRlcGVuZGluZyBvbiBkaWZmZXJlbnQgY3Jp dGVyaWEgYnV0LCBhbHRob3VnaCBub3QgbWFuZGF0b3J5LCBpdCBzaG91bGQgaGF2ZQ0KIGEgZGlm ZmVyZW50IFNGUCBiZWNhdXNlIGEgZGlmZmVyZW50IGFjdGlvbiB3YXMgdGFrZW4gYnkgdGhlIENs YXNzaWZpZXIgYW5kIHRodXMgYSBkaWZmZXJlbnQgcGF0aCB0YWtlbiBieSB0aGUgcGFja2V0cyAt IGFuZCBhbHNvIGhlbHBzIG9uIHRyYWNpbmcgYW5kIG1vbml0b3JpbmcuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5QYWdlIDc6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZn dDsmbmJzcDsmbmJzcDsgdGhhdCBwYWNrZXQgYmFjayB0byB0aGUgU0ZGLiZuYnNwOyBUaGlzIGNh cGFiaWxpdHkgaXMgYW4gZXh0ZW5zaW9uIHRvIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mZ3Q7Jm5i c3A7Jm5ic3A7IGN1cnJlbnQgU0ZDIFByb3h5IGFzIGRlZmluZWQgaW4gKFtSRkM3NjY1XSkuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlRoZSBTRkMgUHJveHkgaXMgbWVhbnQgdG8gYmUgdGhlICZxdW90O3Ry YW5zbGF0b3ImcXVvdDsgZm9yIG5vbi1TRkMtYXdhcmUgU0ZzLCBhbmQgdGhlIEV4dGVuZGVkIFNG QyBQcm94eSBzZWVtcyB0byBoYXZlIG5vIHJlbGF0aW9uc2hpcCB3aXRoIHRoZSBmb3JtZXIgaW4g dGhhdCByZWdhcmQuDQogSG93ZXZlciwgZnJvbSB0aGUgY2hhaW4ncyBwb2ludCBvZiB2aWV3LCBp dCdzIGRlZmluaXRlbHkgYW4gU0ZDIFByb3h5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+UGFnZSA5OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mZ3Q7Jm5ic3A7Jm5ic3A7 IGFuYWx5c2lzLCBwYWNrZXQgZGF0YSByZXBsaWNhdGlvbiBtYXkgYmUgY29uZHVjdGVkIGJ5IGFu IFNGIGNhcGFibGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmd0OyZuYnNwOyZuYnNwOyBvZiBpZGVudGlm eWluZyBmaWxlIGJvdW5kYXJ5IGluIHRoZSBwYWNrZXQgc3RyZWFtLiZuYnNwOyBUaGUgUk8gRVMg d291bGQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmd0OyZuYnNwOyZuYnNwOyBiZSBhc3NvY2lhdGVkIHdp dGggdGhlIFNGIGFuZCByZWNlaXZlcyBwYWNrZXQgZGF0YSBmcm9tIHRoZSBTRjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5JcyB0aGlzIHN0aWxsIGluIHRoZSBzY29wZSBvZiB0aGUgZHJhZnQ/IEl0IHNlZW1z IHRvIGJlIHNvbWV0aGluZyB1cCB0byB0aGUgU0YgdG8gZXhlY3V0ZSwgYW5kIHRoZXJlJ3MgYW4g aW5maW5pdGUgYW1vdW50IG9mIHRoaW5ncyB0aGF0IGNvdWxkIGJlIGRvbmUgYnkgYW4gU0YuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mZ3Q7ICZuYnNwOyZuYnNw O0FsdGVybmF0aXZlbHksIGZvciB1c2UgY2FzZXMgc3VjaCBhcyBnZW5lcmljIHBhY2tldCBjYXB0 dXJlIGZvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mZ3Q7Jm5ic3A7Jm5ic3A7IHRyb3VibGVzaG9vdGlu ZywgdGhlIFNGRiBtYXkgY2Fycnkgb3V0IHRoZSBwYWNrZXQgcmVwbGljYXRpb24gYW5kPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZndDsmbmJzcDsmbmJzcDsgZm9yd2FyZGluZyB3b3JrLiZuYnNwOyBIaWdo ZXIgcGVyZm9ybWFuY2UgbWF5IGJlIGFjaGlldmVkIHdpdGggaGFyZHdhcmU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jmd0OyZuYnNwOyZuYnNwOyBiYXNlZCBTRkYuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNlZSB3 aGF0IEkgd2FzIGVudmlzaW9uaW5nIGF0IHRoZSBlbmQgb2YgbXkgcmV2aWV3LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UGFnZSAxMTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+V2hlcmUgdGhlIHNjZW5hcmlvIHRoYXQgbWFkZSB1c2Ugb2YgYW4gRXh0ZW5kZWQgU0ZDIFBy b3h5IHdhcyBwZXJmZWN0bHkgYWNoaWV2YWJsZSAoYmVjYXVzZSB0aGUgYmFzZSBTRkMgYWJzdHJh Y3Rpb24gd2FzIGtlcHQgdW50b3VjaGVkIC0gYXMgaXQgZXNzZW50aWFsbHkgcmV1c2VzDQogdGhl IGV4aXN0aW5nIFNGQyBQcm94eSBjb25jZXB0IGJ1dCBkb2VzIHNvbWV0aGluZyBkaWZmZXJlbnQg YmVoaW5kIGl0KSwgdGhlIG90aGVyIHNjZW5hcmlvICh3aGVyZSBhbiBTRkYgaXMgdXNlZCB0byBy ZXBsaWNhdGUgdHJhZmZpYykgY2Fubm90IHlldCBiZSBzdXBwb3J0ZWQsIGV2ZW4gdGFraW5nIGlu dG8gYWNjb3VudCBkcmFmdC1pZXRmLXNmYy1uc2gtMDUsIHNpbmNlIGEgc2luZ2xlIG5leHQtaG9w IG11c3QgYmUgc2VsZWN0ZWQgYnkgdGhlDQogU0ZGLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+UGFnZSAxNjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RHJhZnRzIGRyYWZ0 LWlldGYtc2ZjLW5zaC0wNSBhbmQgZHJhZnQtaWV0Zi1zZmMtY29udHJvbC1wbGFuZS0wNiBhcmUg b3V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkxldCBtZSBzaGFyZSB0aGUgc29sdXRpb24gSSBoYWQgbWluZC4gSSds bCBhcHByZWNpYXRlIGZlZWRiYWNrIG9uIHRoaXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIEFjdGlvbnMgaW4gdGhlIENsYXNzaWZpZXIgKGJl c2lkZXMgdXBkYXRpbmcgbWV0YWRhdGEsIFNGUCBpbmZvcm1hdGlvbiBhbmQgc2VuZGluZywgaXQg Y291bGQgYWxzbyBzdXBwb3J0IHJlcGxpY2F0aW9uKTs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gQWx0ZXJuYXRpdmVseSwgc3VwcG9ydCBzZXRz IG9mIE5IcyB3aGVuIGZvcndhcmRpbmcgaW5zdGVhZCBvZiBzaW5nbGUgTkhzIGluIHRoZSBTRkYg Zm9yd2FyZGluZyB0YWJsZSAodG8gYmUgdXNlZCBpbiBwYXJhbGxlbCk7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIFVwZGF0ZSBjb250cm9sIHBs YW5lIHRvIGFjY29tbW9kYXRlIGVpdGhlciB0aGUgc2V0cyBvZiBOSHMgb3IgdGhlIG5ldyBraW5k IG9mIGFjdGlvbiBmb3IgdGhlIENsYXNzaWZpZXI7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIE5vIG5lZWQgdG8gb3ZlcmxvYWQgdGhlIG1vZGVs IHdpdGggYW4gRXh0ZW5kZWQgU0ZDIFByb3h5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+TXkgbWFpbiBjb25jZXJucyBhYm91dCB0aGUgcHJvcG9zZWQgc29sdXRp b24gaW4gZHJhZnQtd2FuZy1zZmMtcmVjZWl2ZS1vbmx5LTAwOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBQb3RlbnRpYWwgYWRkaXRpb25hbCBk ZWxheXMgYW5kIHBlcmZvcm1hbmNlIGxvc3MgaW50cm9kdWNlZCBieSBsaW5lYXJseSBpbnNlcnRp bmcgdGhlIEV4dGVuZGVkIFNGQyBQcm94eSBmdW5jdGlvbiBmb3IgdGhlIHNha2Ugb2YgcGFyYWxs ZWxpemluZw0KIHRyYWZmaWM7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAtIFJPIFNGcyBhcmUgYmVpbmcgdHJlYXRlZCBhcyBvdXRzaWRlIGZ1bmN0 aW9ucyBub3QgcmVhbGx5IHBhcnQgb2YgdGhlIFNGQyBkb21haW4sIGxpa2Ugbm9uLVNGQy1hd2Fy ZSBTRnMgdGhhdCByZXF1aXJlIHRoZSBTRkMgcHJveHkgYXMgdGhlIGdhdGUNCiB0byB0aGUgU0ZD IGRvbWFpbiwgYW5kIGEgbmV3IGtpbmQgb2YgbG9naWNhbCBTRiBiZWluZyBpbnRyb2R1Y2VkIHRv IHJlcGxhY2UgdGhlbTs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IC0gU3BlY2lmaWNhbGx5IGF0IHRoZSBTRkYtYmFzZWQgcmVwbGljYXRpb24gc2Nl bmFyaW8sIHRoZXJlIGlzIHRoZSBuZWVkIHRvIGZvcm1hbGx5IGV4dGVuZCB0aGUgb3JpZ2luYWwg ZGVmaW5pdGlvbnMgb2YgU0ZGIGFuZCBTRkYgbWFwcGluZyB0YWJsZQ0KIChlc3NlbnRpYWxseSBz dXBwb3J0aW5nIHRoZSAmcXVvdDtDb3B5JnF1b3Q7IGZpZWxkIGluIHRoZSBTRkYgZm9yd2FyZGlu ZyB0YWJsZSBwcmVzZW50ZWQpOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgLSBXaGF0IGhhcHBlbnMgaWYgeW91IG5lZWQgdG8gcmVwbGljYXRlIHRy YWZmaWMgdG8gbW9yZSB0aGFuIGEgc2luZ2xlIGFkZGl0aW9uYWwgZnVuY3Rpb24/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPk15IG1haW4gY29uY2VybnMgYWJvdXQgdGhlIHNvbHV0aW9uIEkgaGFkIGluIG1pbmQ6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIFBv dGVudGlhbCBwZXJmb3JtYW5jZSBsb3NzIGluIFNGRiBvciBDbGFzc2lmaWVyIGlmIGFueSBvZiB0 aGVtIGFyZSByZXNwb25zaWJsZSBmb3IgdGhlIHJlcGxpY2F0aW9uIGFjdGlvbjs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gSWYgdGhlIFNGRiBp cyBjaG9zZW4gZm9yIHJlcGxpY2F0aW9uLCB0aGVyZSBpcyB0aGUgbmVlZCB0byBmb3JtYWxseSBl eHRlbmQgdGhlIG9yaWdpbmFsIGRlZmluaXRpb25zIG9mIFNGRiBhbmQgU0ZGIFtOU0hdIG1hcHBp bmcgdGFibGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1JRSIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1JRSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPklnb3IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5FcmljIFdhbmcgKGVqd2FuZyk8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWF5IDI0LCAy MDE2IDY6MjMgUE08YnI+DQo8Yj5Ubzo8L2I+IHNmY0BpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4g S2VudCBMZXVuZyAoa2xldW5nKSAmbHQ7a2xldW5nQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gW3NmY10gV2hhdCBpZiB0aGUgU0YgY29uc3VtZXMgYWxsIHRoZSBwYWNrZXRzPzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxs byBldmVyeW9uZSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5TbyBmYXIgbW9zdCBvZiB0aGUgc2VydmljZSBmdW5jdGlvbnMgaW4gdGhlIFNGQyBmcmFtZXdv cmsgZm9yd2FyZCBwYWNrZXRzIGJhY2sgdG8gdGhlIFNGRi4gJm5ic3A7VGhlcmUgaXMgYW5vdGhl ciBzZXQgb2YgU0ZzIHRoYXQgcmVjZWl2ZXMgcGFja2V0cyBidXQgZG9lcyBub3QgZm9yd2FyZCB0 aGVtIG91dC4gJm5ic3A7QW5hbHl0aWMgZnVuY3Rpb25zIGFuZCBJRFMgYXJlIGEgZmV3IGV4YW1w bGVzLiAmbmJzcDtUaGV5IGFyZSAmcXVvdDtwYWNrZXQNCiBzaW5rcyZxdW90OyBvciDigJxyZWNl aXZlLW9ubHnigJ0gU0ZzLiAmbmJzcDsgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Tb21lIGNoYWxsZW5nZXMgZm9yIHRob3NlIFNGcyB0byBvcGVyYXRlIGlu IFNGQzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+LSBCZWluZyBwYXJ0IG9mIGFuIFNGUCAtIFRoZXkgYXJlIG1hbmFnZWQgYXMgU0YgZm9yIHNp bXBsZSBhbmQgY29uc2lzdGVudCBTRkMgcG9saWN5LCBidXQgdGhleSBkbyBub3QgZWdyZXNzIHRy YWZmaWM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi0gUGFja2V0IHJlcGxpY2F0aW9uIC0gdGhvc2UgU0ZzIG5lZWQgdG8gdGFrZSBhIGNvcHkgb2Yg dGhlIHBhY2tldHMgc28gdGhhdCB0aGUgb3JpZ2luYWwgb25lcyBjb250aW51ZSBvbiB0aGUgcGF0 aDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBT ZXJ2aWNlIGluZGV4IGRlY3JlbWVudGluZyAtIHBhY2tldHMg4oCccGFzc2luZ+KAnSBzdWNoIGFu IFNGIG5lZWQgdG8gaGF2ZSB0aGVpciBTSSBkZWNyZW1lbnRlZCBiZWZvcmUgcmVhY2hpbmcgdGhl IG5leHQgU0Y8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+V2UgcHVibGlzaGVkIGEgZHJhZnQgYXR0ZW1wdGluZyB0byBhZGRyZXNzIHRoZSBuZWVk IGZvciBzdXBwb3J0aW5nIHRoaXMgc2V0IG9mIFNGcywgYXMgYSBjb21wbGVtZW50YXJ5IHRvIHRo ZSBTRkMgZnJhbWV3b3JrIHRvZGF5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXdhbmctc2ZjLXJlY2VpdmUtb25seS0wMCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXdhbmctc2ZjLXJlY2VpdmUtb25seS0wMDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V291bGQgYXBwcmVjaWF0ZSB5b3VyIGZl ZWRiYWNrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+LUVyaWM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_E09EC9A2DDB2914E953966C44BEF9CF6D46EEDIRSMSX103gercorpi_--