Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D417130EA4; Wed, 27 Feb 2019 02:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 dY7xVHPS5vkP; Wed, 27 Feb 2019 02:21:54 -0800 (PST) Received: from orange.com (mta136.mail.business.static.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 D1295130E27; Wed, 27 Feb 2019 02:21:53 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 448Wv43cQxz1yqH; Wed, 27 Feb 2019 11:21:52 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.82]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 448Wv42gbzzFpWv; Wed, 27 Feb 2019 11:21:52 +0100 (CET) Received: from OPEXCAUBMA3.corporate.adroot.infra.ftgroup ([fe80::90fe:7dc1:fb15:a02b]) by OPEXCAUBM5E.corporate.adroot.infra.ftgroup ([fe80::849f:f804:b713:d99a%21]) with mapi id 14.03.0435.000; Wed, 27 Feb 2019 11:21:52 +0100 From: To: "draft-ietf-bess-nsh-bgp-control-plane@ietf.org" CC: "bess@ietf.org" Thread-Topic: Shepherd's review of draft-ietf-bess-nsh-bgp-control-plane-06 Thread-Index: AdTN15CohDC0LG//QgG1ys5nLdIbiQ== Date: Wed, 27 Feb 2019 10:21:51 +0000 Message-ID: <6687_1551262912_5C7664C0_6687_242_18_9E32478DFA9976438E7A22F69B08FF924C199D40@OPEXCAUBMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: multipart/related; boundary="_004_9E32478DFA9976438E7A22F69B08FF924C199D40OPEXCAUBMA3corp_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [bess] Shepherd's review of draft-ietf-bess-nsh-bgp-control-plane-06 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 10:21:58 -0000 --_004_9E32478DFA9976438E7A22F69B08FF924C199D40OPEXCAUBMA3corp_ Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF924C199D40OPEXCAUBMA3corp_" --_000_9E32478DFA9976438E7A22F69B08FF924C199D40OPEXCAUBMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Here is my review of draft-ietf-bess-nsh-bgp-control-plane-06 General comment: The document is globally well written with good examples that help the unde= rstanding. However it requires some refinements in the normative language u= sed: some statement should be normative but are not using upper case words. Detailed comments: Abstract: - Please expand "BGP" on first use - Please give a reference associated to "Network Service Header" Introduction: - When "classifier" is used as an example of SF, do you refer to t= he classifier used to steer the traffic onto an SFC ? If yes, I don't think= it could be considered as an SF. - I think the "conventional" approach described in the intro is re= ally old school and even before SFC, we had some means, like dynamic routin= g protocols and other mechanisms like separate routing tables, to steer the= traffic through a set of services. I agree that there is also some drawbac= k associated with such approaches like the operational complexity of provis= ioning. Section 1.2: It would be good to give a definition for the additional terms that are def= ined in this document. Section 2.1: =B7 As the section is focused on dataplane, it would be good to ren= ame it as "Reminder on NSH dataplane" or something like that. It does not p= rovide a functional overview of the controlplane which is what was expected= based on the title. =B7 "A special Service Function, called a Classifier, is located at= each ingress point to a service function overlay network. It assigns the packets of a given packet flow to a specific Service Function Path. " Again, based on my understanding, the Classifier cannot really be considere= d as an SF , at least this is a component out of the SFC which steers the t= raffic onto an SFC. =B7 "An unknown or invalid SPI SHALL be treated as an error and the= SFF MUST drop the packet. Such errors SHOULD be logged, and such logs MUST be subject to rate limits." I found strange to have such statement in this document which is focused on= the controlplane while this statement is a dataplane statement. Isn't it p= art of RFC8300 Section 3 : "3. Update the NSH: SFs MUST decrement the serv= ice index by one. If an SFF receives a packet with an SPI and SI that do not correspond to a valid next hop in a valid SFP, that packet MUST be dropped by the SFF." The next paragraph deals also with normative dataplane statement which is I= MO out of scope of this document. Section 2.2 =B7 "The SFIR describes a particular instance of a particular Service Function". Would it be good to talk about "Service= Function Instance" rather than instance of a Service Function ? That's und= erstandable, of course, however I think it's good to reuse the exact termin= ology. =B7 I think the SFT definition is appearing a bit late in this sect= ion and in the document as it as been referenced already multiple times bef= ore. =B7 "Service Function Type (SFT) that is the category of SF that is supported by an SFF". Don't you mean SFI r= ather than SFF ? =B7 "Thus the SFF can be seen as a portal...". Would "gateway" be m= ore suitable rather than "portal" ? =B7 The Figure 1 is not really used in this section as part of the = existing text. I would be better to have a companion text that explains the= figure. =B7 I don't like (personal opinion), the "grouping" of SFIs in the = Figure 1 as part of an SFT. What strikes me is that it could be confused wi= th the usual representation of an SF composed of multiple SFIs. Again that'= s just a personal feeling. Section 3: =B7 "they must use BGP Capabilities": is it a normative MUST ? Section 3.1: =B7 s/a two byte Type field and a six byte/a two bytes Type field a= nd a six bytes/ =B7 "Two SFIs of the same SFT must be associated". Is it a normativ= e MUST ? Same comment for next sentences in the paragraph (multiple occuren= ces) =B7 "The Service Function Type identifies a service function". I do= n't think we can really say that, it identifies the type of service the SF = is providing but not the SF itself. =B7 "Each node hosting an SFI must originate an SFIR for each type of SF that it hosts, and it may advertise an SFIR for each instance of each type of SF." Is it really "a= nd" ? I mean can we just summarize by using " Each node hosting an SFI MUST= originate an SFIR for each instance of each type of SF" ? =B7 "A BGP Update containing one or more SFIRs will also include". = Is it a MUST or SHOULD "also include"? =B7 How is the nexthop encoded in the NLRI ? Section 3.1.1 =B7 s/"It can be included"/"It MAY be included"/ ? =B7 That would be great to give more details about the usage of poo= ls =B7 The encoding in Figure 4 is not matching the text. Figure 4 has= Type=3D0x80, Sub-type=3DTBD6, text says type=3DTBD6 and subtype=3D0x00 =B7 How is the pool ID managed ? Section 3.1.2 =B7 Same comment about Figure 5 not matching the text. Section 3.2: =B7 s/a two byte Type field and a six byte/a two bytes Type field a= nd a six bytes/ =B7 Same comment about normative language "must" vs "MUST" =B7 How is the nexthop encoded in the NLRI ? Section 3.2.1: =B7 From a readability point of view, it would be good to tell in t= he second sentence that the requested attribute is Optional Transitive (we = can see it in the description but it is also good to have it in the intro o= f the attribute). =B7 "The presence rules and meanings are as follows.". It would be = good to use normative language in the following sentences. =B7 I don't see the "error handling" behavior associated with this = attribute (discard, treat-as-withdraw...) Section 3.2.1.1 =B7 "It may be present" or "It MAY be present" ? Section 4.1 Having an SFF being part of a single overlay network is IMO a very limited = use case, in such a case, I don't think that you need an RT at all. The SFF= could be part of a L3VPN which will be used as an underlay. An SFF being "multitenant" is more valid and defacto requires to maintain s= eparate forwarding states (VRF like...). This is mandatory to maintain the = tenant isolation and RTs are very useful here to know the appropriate conte= xt to put the routes in. Section 7.1 While I understand that the node doing the classification can perform a dee= p packet inspection to get an entropy indicator, any intermediate node cann= ot set it again as the NSH header will be there. Here is an example: PacketsIn ---> Classifier ->SFF1 (SFI1) -> SFF2(SFI2) ->SFF3(SFI3)->Packets= Out to dest Classifier pushes NSH header onto the packets as well as the underlay tunne= l (using an entropy indicator in UDP or ELI/EL). Where the packets comes in= at SFF1, IMO, it strips the underlay tunnels including the entropy indicat= or. Which means that when the packet with NSH header will go to SFF2, it wi= ll not have anymore entropy indicator and there is no way to build it again= as the NSH header prevents a new deep packet inspection. Am I missing some= thing ? Maintaing a per packet state is IMO not doable , especially if the = SFI modifies the packet content. Section 8 I would have been good to have two SFIs with the same SFT on the same SFF i= n the example. I don't like the representation of RD using "192.0.2.1,1" as the "," can be= confusing with a regular separator. Why not using :"192.0.2.1:1" notation = which is well known ? Section 8.9.1: How does an SFF know that an attached SFI is stateful ? I don't think it ca= n know that. I don't think that the fact that SFF2 is used in both direction is safe fro= m a loadbalancing perspective. If the hashing algorithm used by SFF2 is sensible to the order of the keys = (like source vs dest address, or source vs dest port), it may provide a dif= ferent SFI as a result of the hashing between the forward and the reverse f= low. Section 8.9.2: How can the controller instruct the classifier how to place traffic ? In addition, this could involve multiple classifiers that need to be coordi= nated. The ingress forward classifier and the ingress reverse classifier should us= e SFPs within the same assoc. Section 9: Do we have to set limits on receiving nodes in term of number of states rec= eived from the controller to mitigate some attack ? The text talks about security of BGP, what kind of mechanism should be put = in place ? Do we have any interdomain considerations ? This is a controller based approach, so the security of the controller itse= lf is also important. References: Shouldn't RFC7665 be normative ? I think that the mpls-sfc and mpls-sfc-encaps should also be normative as y= ou are defining a controlplane to use them. Brgds, [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/OINIS/NET Orange Expert Future Networks phone: +33 2 23 06 49 83 NEW ! mobile: +33 6 71 63 27 50 NEW ! stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_9E32478DFA9976438E7A22F69B08FF924C199D40OPEXCAUBMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

Here is my review of draft-ietf-bess-nsh-bgp-control= -plane-06

 

General comment:

 

The document is globally well written with good exam= ples that help the understanding. However it requires some refinements in t= he normative language used: some statement should be normative but are not = using upper case words.

 

 

Detailed comments:

 

Abstract:

-     &= nbsp;    Please expand “BGP” on first use

-     &= nbsp;    Please give a reference associated to “Networ= k Service Header”

 

Introduction:

-     &= nbsp;    When “classifier” is used as an example= of SF, do you refer to the classifier used to steer the traffic onto an SF= C ? If yes, I don’t think it could be considered as an SF.=

-     &= nbsp;    I think the “conventional” approach des= cribed in the intro is really old school and even before SFC, we had some m= eans, like dynamic routing protocols and other mechanisms like separate rou= ting tables, to steer the traffic through a set of services. I agree that there is also some drawback associated with = such approaches like the operational complexity of provisioning.=

 

Section 1.2:

It would be good to give a definitio= n for the additional terms that are defined in this document.

 

Section 2.1:

&nb= sp;

 

=
=B7         As the section is focused on =
dataplane, it would be good to rename it as “Reminder on NSH dataplan=
e” or something like that. It does not provide a functional overview =
of the controlplane which is what was expected based on the title.
 
=
=B7         “A special Service Function, called a Classifier, is located at each

   ingress point to a service functi= on overlay network.  It assigns the

   packets of a given packet flow to= a specific Service Function Path.

“

Again, based on my understanding, th= e Classifier cannot really be considered as an SF , at least this is a comp= onent out of the SFC which steers the traffic onto an SFC.

 

=
=B7         “An unknown or invalid SPI SHALL be treated as an error and the SFF
   MUST drop the packet.  S=
uch errors SHOULD be logged, and such logs
   MUST be subject to rate limit=
s.”
 
I found strange to have such statement in =
this document which is focused on the controlplane while this statement is =
a dataplane statement. Isn’t it part of RFC8300 Section 3 : “3.=
  Update the NSH: SFs MUST decrement the service index by one.  I=
f
       an SF=
F receives a packet with an SPI and SI that do not
       corre=
spond to a valid next hop in a valid SFP, that packet MUST
       be dr=
opped by the SFF.”
The next paragraph deals also with normati=
ve dataplane statement which is IMO out of scope of this document.
 
 
Section 2.2
=
=B7         “The SFIR describes a p=
articular instance of a
      particular =
Service Function”. Would it be good to talk about “Service Func=
tion Instance” rather than instance of a Service Function ? That̵=
7;s understandable, of course, however I think it’s good to reuse the=
 exact terminology. 
=
=B7         I think the SFT definition is=
 appearing a bit late in this section and in the document as it as been ref=
erenced already multiple times before.
=
=B7         “Service Function Type =
(SFT) that
   is the category of SF that is=
 supported by an SFF”. Don’t you mean SFI rather than SFF ?
=
=B7         “Thus the SFF can be se=
en as a portal…”. Would “gateway” be more suitable =
rather than “portal” ?
=
=B7         The Figure 1 is not really us=
ed in this section as part of the existing text. I would be better to have =
a companion text that explains the figure.
=
=B7         I don’t like (personal =
opinion), the “grouping” of SFIs in the Figure 1 as part of an =
SFT. What strikes me is that it could be confused with the usual representa=
tion of an SF composed of multiple SFIs. Again that’s just a personal=
 feeling.
 
Section 3:
=
=B7         “they must use BGP Capa=
bilities”: is it a normative MUST ?
 
Section 3.1:
=
=B7         s/a two byte Type field and a=
 six byte/a two bytes Type field and a six bytes/
=
=B7         “Two SFIs of the same SFT must be associated”. Is it a normative MUST=
 ? Same comment for next sentences in the paragraph (multiple occurences)
=
=B7         “The Service Function Type identifies a service function”. I don̵=
7;t think we can really say that, it identifies the type of service the SF =
is providing but not the SF itself.
=
=B7         “Each node hosting an SFI
   must originate an SFIR for ea=
ch type of SF that it hosts, and it may
   advertise an SFIR for each in=
stance of each type of SF.” Is it really “and” ? I mean c=
an we just summarize by using “ Each node hosting an SFI MUST origina=
te an SFIR for each instance of each type of SF” ?<=
/pre>

=B7        
“A BGP Update containi=
ng one or more SFIRs will also include”. Is it a MUST or SHOULD ̶=
0;also include”?


=B7        
How is the nexthop encoded i=
n the NLRI ?


 


Section 3.1.1


=
=B7         s/“It can be included&#=
8221;/”It MAY be included”/ ?


=
=B7         That would be great to give m=
ore details about the usage of pools


=
=B7         The encoding in Figure 4 is n=
ot matching the text. Figure 4 has Type=3D0x80, Sub-type=3DTBD6, text says =
type=3DTBD6 and subtype=3D0x00


=
=B7         How is the pool ID managed ?<=
o:p>


 


Section 3.1.2


=B7        
Same comment about Figure 5 =
not matching the text.


 


Section 3.2:


=
=B7         s/a two byte Type field and a=
 six byte/a two bytes Type field and a six bytes/


=
=B7         Same comment about normative =
language “must” vs “MUST”


=
=B7         How is the nexthop encoded in the NLRI ?<=
/span>


 


Section 3.2.1:


=
=B7         From a readability point of v=
iew, it would be good to tell in the second sentence that the requested att=
ribute is Optional Transitive (we can see it in the description but it is a=
lso good to have it in the intro of the attribute).


=
=B7         “The presence rules and=
 meanings are as follows.”. It would be good to use normative languag=
e in the following sentences.


=
=B7         I don’t see the “=
error handling” behavior associated with this attribute (discard, tre=
at-as-withdraw…)


 


Section 3.2.1.1


=
=B7         “It may be present̶=
1; or “It MAY be present” ?


 


Section 4.1


 


Having an SFF being part of a single=
 overlay network is IMO a very limited use case, in such a case, I don̵=
7;t think that you need an RT at all. The SFF could be part of
 a L3VPN which will be used as an underlay.


An SFF being “multitenant̶=
1; is more valid and defacto requires to maintain separate forwarding state=
s (VRF like…). This is mandatory to maintain the tenant isolation and
 RTs are very useful here to know the appropriate context to put the routes=
 in.


 


Section 7.1


While I understand that the node doi=
ng the classification can perform a deep packet inspection to get an entrop=
y indicator, any intermediate node cannot set it again as
 the NSH header will be there.


Here is an example:


 


      =
           



PacketsIn -=E0 Classifier =
->SFF1
 (SFI1) -> SFF2(SFI2) ->SFF3(SFI3)->PacketsOut to dest<=
/span>


 


Classifier pushes NSH header onto th=
e packets as well as the underlay tunnel (using an entropy indicator in UDP=
 or ELI/EL). Where the packets comes in at SFF1, IMO, it
 strips the underlay tunnels including the entropy indicator. Which means t=
hat when the packet with NSH header will go to SFF2, it will not have anymo=
re entropy indicator and there is no way to build it again as the NSH heade=
r prevents a new deep packet inspection.
 Am I missing something ? Maintaing a per packet state is IMO not doable , =
especially if the SFI modifies the packet content.


 


Section 8


I would have been good to have two S=
FIs with the same SFT on the same SFF in the example.


I don’t like the representatio=
n of RD using “192.0.2.1,1” as the “,” can be confu=
sing with a regular separator. Why not using :”192.0.2.1:1” not=
ation which is well known
 ?


 


 


Section 8.9.1:


How does an SFF know that an attache=
d SFI is stateful ? I don’t think it can know that.=



I don’t think that the fact th=
at SFF2 is used in both direction is safe from a loadbalancing perspective.=



If the hashing algorithm used by SFF=
2 is sensible to the order of the keys (like source vs dest address, or sou=
rce vs dest port), it may provide a different SFI as a result
 of the hashing between the forward and the reverse flow.=



 


Section 8.9.2:


How can the controller instruct the =
classifier how to place traffic ?


In addition, this could involve mult=
iple classifiers that need to be coordinated.


The ingress forward classifier and t=
he ingress reverse classifier should use SFPs within the same assoc.


 


Section 9:


Do we have to set limits on receivin=
g nodes in term of number of states received from the controller to mitigat=
e some attack ?


The text talks about security of BGP=
, what kind of mechanism should be put in place ?


Do we have any interdomain considera=
tions ?


This is a controller based approach,=
 so the security of the controller itself is also important.


 


 


References:


Shouldn’t RFC7665 be normative=
 ?


I think that the mpls-sfc and mpls-s=
fc-encaps should also be normative as you are defining a controlplane to us=
e them.


 


 


 


Brgds,


 


 


 


3D"O=


 <=
o:p>


Stephane Litkowski


Network Architect


Orange/SCE/EQUANT/OINIS/NET


Orange Expert Future Networks=



phone:
+33
 2 23 06 49 83  NEW !

mobile:

+33 6 71 63 27 50  NEW =
;!

s=
tephane.litkowski@orange.com



 


______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_9E32478DFA9976438E7A22F69B08FF924C199D40OPEXCAUBMA3corp_-- --_004_9E32478DFA9976438E7A22F69B08FF924C199D40OPEXCAUBMA3corp_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=1093; creation-date="Wed, 27 Feb 2019 10:21:51 GMT"; modification-date="Wed, 27 Feb 2019 10:21:51 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAAoACgDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1O48f afbXMsDWl0WjcoSAuDg49aj/AOFiad/z53f5L/jXB6r/AMhe9/67v/M1Ur5Geb4pSaTX3H2dPJcJ KCbT+89H/wCFiad/z53f5L/jR/wsTTv+fO7/ACX/ABrziip/tnFd19xX9iYPs/vPR/8AhYmnf8+d 3+S/40V5xRR/bOK7r7g/sTB9n95b1X/kL3v/AF3f+ZqpW3Po17qGo3s0Cx7DdPGpeQLvbOdq56mo R4d1EmEFYVaZdyI0oDY9cda450KspNqLO2niKUYJOSvbv5GVRWwPC+qmR4zFErI/l4aUDc2A2B68 GmDw7qTQrIIkJZVYR+YN+GOAdvuan6tW/lf3FfWqH86+8yqK2bjQG0+EvqU/2dmyIgieYGI6gkHg 0VM6M4O0tGVCtCavF3R1o8Oa7BcTtbXdh5TztPGJYyxjY9xxwcUxfDniNZ1m+32DOIPs+WjJymc8 8dc96KK+y/s+l3f3s+J/tKt2X3Ie+geJZJlla/0/eswmH7s/eChfT0FXDo2rDTRCktoLoIqfaCxy NrZGPlz+GaKKpYGmr6vXzJlj6sraLTyMrUPCOuant+03lh8pJ+RGXJPUniiiisZ5Thpvmldv1N4Z xioLljZL0R//2Q== --_004_9E32478DFA9976438E7A22F69B08FF924C199D40OPEXCAUBMA3corp_--