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 597C8127023; Wed, 3 Jan 2018 05:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 mn0noFV8Gn4E; Wed, 3 Jan 2018 05:10:38 -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 494711201F8; Wed, 3 Jan 2018 05:10:38 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 82C4A40A8C; Wed, 3 Jan 2018 14:01:10 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.13]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 5A7EB1A0072; Wed, 3 Jan 2018 14:01:10 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM6D.corporate.adroot.infra.ftgroup ([fe80::54f9:a6c3:c013:cbc7%19]) with mapi id 14.03.0361.001; Wed, 3 Jan 2018 14:01:10 +0100 From: To: "draft-ietf-bess-mvpn-expl-track.authors@ietf.org" CC: "bess@ietf.org" , "bess-chairs@ietf.org" Thread-Topic: Shepherd's review of draft-ietf-bess-mvpn-expl-track Thread-Index: AdN5jsmXDQSoAwXXRoKBWZf9DikTzQ== Date: Wed, 3 Jan 2018 13:01:09 +0000 Message-ID: <7712_1514984470_5A4CD416_7712_401_1_9E32478DFA9976438E7A22F69B08FF921EB01322@OPEXCLILMA4.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.168.234.2] Content-Type: multipart/related; boundary="_004_9E32478DFA9976438E7A22F69B08FF921EB01322OPEXCLILMA4corp_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [bess] Shepherd's review of draft-ietf-bess-mvpn-expl-track X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 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, 03 Jan 2018 13:10:42 -0000 --_004_9E32478DFA9976438E7A22F69B08FF921EB01322OPEXCLILMA4corp_ Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921EB01322OPEXCLILMA4corp_" --_000_9E32478DFA9976438E7A22F69B08FF921EB01322OPEXCLILMA4corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As shepherd of this document, please find below some comments that I have: Overall comments: - Please add a section that contains all the abbreviations expansi= ons: that may help non expert people to follow the acronyms without looking= for the first reference in the text. - I usually like figures. For the intro, it may be wonderful to bu= ild a figure that reminds the existing S-PMSI/Leaf A-D procedure. So withou= t reading the text, we can remember how it works. - The interAS case may also be better with a Figure and an example= (or couples of). Introduction: "By originating one of these BGP routes, an ingress node advertises that it is transmitting a particular multicast flow." [SLI] Is "is transmitting" correct ? Can't we have situations where an S-PM= SI route is/was advertised but no traffic is flowing (no yet started or swi= tched, or stopped). "Now suppose that the ingress node wants explicit tracking for each individual flow that it transmits (following the procedures of [RFC6625] on that P-tunnel." [SLI] Missing ")" "This allows the ingress node to determine the set of egress nodes that are receiving flows from the ingress node." [SLI] I think the Leaf A-D tells that there is a receiver interested by the= flow, but does not tell that it actually receives it. " Howver, this procedure requires several clarifications:" [SLI] There is a typo s/Howver/However/ "The procedures of [RFC6625] do not clearly state how to handle an S-PMSI A-D route if its NLRI contains wild cards, but its PTA specifies "no tunnel info"." [SLI] I quickly ran over RFC6625, it does not mention anything on explicit = tracking or Leaf A-D routes. So we assume that RFC6513/6514 only applies he= re. " * The explicit tracking procedures do not allow an ingress node to "see" past the boundaries of the segmentation domain. This particular problem is not further addressed in this revision of this document. " [SLI] Do you plan to address it ? Or do we now consider it as out of scope ? Section 2: "Prior specifications define one flag in the PTA, the "Leaf Info Required" (LIR) flag, that is used for explicit tracking." [SLI] Please point to the right reference "If the LIR-pF flag is set in a given PTA, the LIR flag of that PTA SHOULD also be set." [SLI] Why not using a MUST ? "one forces a a response to be sent an egress node that does not support LIR-pF" [SLI] Is there a missing word like 'sent by an egress node" ? Section 3: "The definition of "match for reception" in [RFC6625] is hereby modified as follows:" [SLI] Please point to the section that you are updating. In addition, section 3.2 of RFC6625 contains multiple if then else conditio= ns for each cases (C-S,C-G) and (C-*,C-G). Please give some precision in wh= ere do you want to insert your new statement in this processing sequence. I= guess it is at the beginning. "When finding the "match for reception" for a given (C-S,C-G) or (C-*,C-G), ignore any S-PMSI A-D route that has no PTA, or whose PTA specifying "no tunnel information"." [SLI] I would be in favor to introduce a normative statement here. "We also introduce a new notion: the "match for tracking". This differs from the "match for reception" as follows:" [SLI] It would be better to give a definition of the "match for tracking" b= efore giving the rules. Here you're explaining only the rules, not the diff= erence in the meaning. Wouldn't it be easier to tell that the implementatio= n MUST consider only the S-PMSI A-D routes that have a LIR flag and/or LR-p= F flag set and then run the same rules as the RFC6625. Why do you want to h= ave S-PMSI routes with PTA and LIR unset in your route list for "match for = tracking" ? You need to take care here on your text proposal as one of your= previous statement updates the RFC6625 and the match reception procedure, = so the rules to be applied are the original one from RFC6625 and not the up= dated one. " Also note that if a match for tracking does not have the LIR flag or the LIR-pF flag set, no explicit tracking information will be generated. See Section 5." [SLI] Again I do not see the value added of keeping such route as a match f= or tracking as there is no tracking requested. Section 4: "Such a route could be an I-PMSI A-D route, a (C-*,C-G1) S-PMSI A-D route, a (C-S1,C-*) S-PMSI A-D route, or a (C-*,C-*) S-PMSI A-D route. " [SLI] Is per flow explicit tracking also required for I-PMSI ? I do not see= it listed in the goals of the doc ? The goal was to address wildcards S-PM= SI AD routes. "Further, if the ingress node originates a wildcard S-PMSI A-D route carrying a PTA specifying the tunnel to be used for carrying (C-S1,C-G1) traffic, and if that PTA has the LIR-pF bit set, then explicit tracking for (C-S1,C-G1) is requested by that S-PMSI A-D route. Thus the ingress node SHOULD NOT originate a (C-S1,C-G1) S-PMSI A-D route whose PTA specifies "no tunnel info"; such a route would not provide any additional functionality." [SLI] I do not fully understand this text in the context of your procedure = 1. which deals with an origination of an (C-S1,C-G1) S-PMSI A-D route (no w= ildcard). As I understand the procedure for the wildcard is defined in 2. "2. The following procedure can be used if (and only if) it is known that the egress nodes support the optional LIR-pF flag." I have some issue with this sentence. It does not seem to be normative as t= here is no normative statement. However I understand it as a critical thing= ("and only if" !) so it may require at least a SHOULD. Then the issue I see is that this knowledge does not come from the protocol= , so it sounds important to me to highlight the impact of a mistake. BUT, reading the section 5. I understand that it is not as critical as it s= eems as the receiver will ignore simply the LIR-pF flag and apply the stand= ard procedure (LIR set). Please clarify the criticity to have or not this knowledge. " To terminate explicit tracking that has been initiated by an S-PMSI A-D route whose PTA specifies a tunnel, the ingress node re-originates the route without the LIR flag set" [SLI] Do we also need to clear the LIR-pf ? It would make sense to do so. "If the match for tracking has LIR set and if either (a) the egress node does not support LIR-pF, or (b) LIR-pF is not set, then the egress node must respond to the match for tracking, following procedures specified in other documents for the case where LIR is set." [SLI] Please state the relevant document references here. Section 5.2 "Note that, per RFC4364, every RD begins with a two-octet type field that is either 0, 1, or 2. By adding 16 to the second octet of the RD, we force the type field to be 16, 17, or 18. " [SLI] It works but we may need to ensure that the types > 16 cannot be used= anymore by new applications. Moreover if new RD types are created, new sib= lings will have to be created. Wouldn't it be easier to set the MSB of the RD type to 1 ? so we only lock = half of the type space. Or what could be the impact of using the RD of the local VRF of the egress = node ? Section 5.3 "In the case where the egress node is not a PE, but rather an ABR or ASBR, it will not know whether it needs to receive a given flow unless it receives a Leaf A-D route whose NLRI specifies that flow and whose IP-address-specific RT specifies an address of the egress node." [SLI] The sentence works but when reading it I needed multiple reread to un= derstand that the "IP-address-specific RT specifies an address of the egress node." was referring to the ASBR/ABR = and not the receiver PE. Do you mind using "this egress node" or "this ABR/ASBR" ? Section 8. [SLI] Do we have counter-measures against such "attack" ? Ingress PE droppi= ng ? Section 9.2 I think RFC7524 needs to be referenced as normative giving that its knowled= ge is required to understand section 5.3. I think that section 5.3 is also = updating/complementing the procedures in RFC7524 with the "no-tunnel info" = case. 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_9E32478DFA9976438E7A22F69B08FF921EB01322OPEXCLILMA4corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

As shepherd of this document, please find below some= comments that I have:

 

Overall comments:

-     &= nbsp;    Please add a section that contains all the abbrevia= tions expansions: that may help non expert people to follow the acronyms wi= thout looking for the first reference in the text.

-     &= nbsp;    I usually like figures. For the intro, it may be wo= nderful to build a figure that reminds the existing S-PMSI/Leaf A-D procedu= re. So without reading the text, we can remember how it works.

-     &= nbsp;    The interAS case may also be better with a Figure a= nd an example (or couples of).

 

Introduction:

“By originating one of these BGP rou=
tes, an ingress node advertises that

   it is transmitting a particular m= ulticast flow.”

[SLI] Is “is transmitting” correct ? Can= ’t we have situations where an S-PMSI route is/was advertised but no = traffic is flowing (no yet started or switched, or stopped).

 

“Now
   suppose that the ingress node=
 wants explicit tracking for each
   individual flow that it trans=
mits (following the procedures of
   [RFC6625] on that P-tunnel.&#=
8221;
[SLI] Missing “)”
 
 
“This allows the

   ingress node to determine the=
 set of egress nodes that are receiving


   flows from the ingress node.&=
#8221;


[SLI] I think the Leaf A-D tells that ther=
e is a receiver interested by the flow, but does not tell that it actually =
receives it.


 


 


“   Howver, this procedure=
 requires several clarifications:”


[SLI] There is a typo s/Howver/However/


 


“The procedures of [RFC6625] do not =
clearly state how to handle an


      S-PMSI A-D =
route if its NLRI contains wild cards, but its PTA


      specifies &=
quot;no tunnel info".”


 


[SLI] I quickly ran over RFC6625, it does =
not mention anything on explicit tracking or Leaf A-D routes. So we assume =
that RFC6513/6514 only applies here.


 


 


“   *  The explicit t=
racking procedures do not allow an ingress node


       =
  to "see" past the boundaries of the segmentation domain.


 


       =
  This particular problem is not further addressed in this<=
/span>


       =
  revision of this document.


“


[SLI] Do you plan to address it ? Or do we=
 now consider it as out of scope ?


 


 


 


Section 2:


“Prior specifications define one fla=
g in the PTA, the "Leaf Info


   Required" (LIR) flag, th=
at is used for explicit tracking.”


 


[SLI] Please point to the right reference<=
o:p>


 


“If the LIR-pF flag is set in a give=
n PTA, the LIR flag of that PTA


   SHOULD also be set.”


[SLI] Why not using a MUST ?


 


“one forces a


   a response to be sent an egre=
ss node that does not support LIR-pF”


[SLI] Is there a missing word like ‘=
sent by an egress node” ?


 


 


 


 


Section 3:


“The definition of "match for r=
eception" in [RFC6625] is hereby


   modified as follows:”


 


[SLI] Please point to the section that you=
 are updating.


In addition, section 3.2 of RFC6625 contai=
ns multiple if then else conditions for each cases (C-S,C-G) and (C-*,C-G).=
 Please give some precision in where do you want to insert your new stateme=
nt in this processing sequence. I guess it is at the beginning.<=
/span>


 


 


“When finding the "match for re=
ception" for a given (C-S,C-G) or


      (C-*,C-G), =
ignore any S-PMSI A-D route that has no PTA, or whose

      PTA specify=
ing "no tunnel information".”


[SLI] I would be in favor to introduce a normative s=
tatement here.


 


“We also introduce a new notion: the=
 "match for tracking".  This


   differs from the "match =
for reception" as follows:”


[SLI] It would be better to give a definit=
ion of the “match for tracking” before giving the rules. Here y=
ou’re explaining only the rules, not the difference in the meaning. W=
ouldn’t it be easier to tell that the implementation MUST consider on=
ly the S-PMSI A-D routes that have a LIR flag and/or LR-pF flag set and the=
n run the same rules as the RFC6625. Why do you want to have S-PMSI routes =
with PTA and LIR unset in your route list for “match for trackingR=
21; ? You need to take care here on your text proposal as one of your previ=
ous statement updates the RFC6625 and the match reception procedure, so the=
 rules to be applied are the original one from RFC6625 and not the updated =
one.


 


 


“   Also note that if a ma=
tch for tracking does not have the LIR flag or


   the LIR-pF flag set, no expli=
cit tracking information will be


   generated.  See Section =
5.”


[SLI] Again I do not see the value added o=
f keeping such route as a match for tracking as there is no tracking reques=
ted.


 


 


Section 4:


“Such a route could be an=



       I-PMS=
I A-D route, a (C-*,C-G1) S-PMSI A-D route, a (C-S1,C-*)<=
/pre>

       S-PMS=
I A-D route, or a (C-*,C-*) S-PMSI A-D route. “

[SLI] Is per flow explicit tracking also r=
equired for I-PMSI ? I do not see it listed in the goals of the doc ? The g=
oal was to address wildcards S-PMSI AD routes.


 


“Further, if the ingress node origin=
ates a wildcard S-PMSI A-D


       route car=
rying a PTA specifying the tunnel to be used for


       carrying =
(C-S1,C-G1) traffic, and if that PTA has the LIR-pF bit

       set, then=
 explicit tracking for (C-S1,C-G1) is requested by that

       S-PMSI A-=
D route.  Thus the ingress node SHOULD NOT originate a


       (C-S1,C-G=
1) S-PMSI A-D route whose PTA specifies "no tunnel

       info"=
;; such a route would not provide any additional


       functiona=
lity.”


 


[SLI] I do not fully understand this text in t=
he context of your procedure 1. which deals with an origination of an (C-S1=
,C-G1) S-PMSI A-D route (no wildcard). As I understand
 the procedure for the wildcard is defined in 2.


 


 


 


 


“2. The following procedure can be used =
if (and only if) it is known


       that the =
egress nodes support the optional LIR-pF flag.”


 


I have some issue with this sentence. It d=
oes not seem to be normative as there is no normative statement. However I =
understand it as a critical thing (“and only if” !) so it may r=
equire at least a SHOULD.


Then the issue I see is that this knowledg=
e does not come from the protocol, so it sounds important to me to highligh=
t the impact of a mistake.


 


BUT, reading the section 5. I understand t=
hat it is not as critical as it seems as the receiver will ignore simply th=
e LIR-pF flag and apply the standard procedure (LIR set).=



Please clarify the criticity to have or no=
t this knowledge.


 


 


“      =
; To terminate explicit tracking that has been initiated by an


       S-PMSI A-=
D route whose PTA specifies a tunnel, the ingress node


       re-origin=
ates the route without the LIR flag set”


 


[SLI] Do we also need to clear the LIR-pf ? It=
 would make sense to do so.


 


 


“If the match for tracking has LIR s=
et and if either (a) the


       egress no=
de does not support LIR-pF, or (b) LIR-pF is not set,


       then the =
egress node must respond to the match for tracking,


       following=
 procedures specified in other documents for the case


       where LIR=
 is set.”


 


[SLI] Please state the relevant document refer=
ences here.


 


 


 


 


Section 5.2


 


 


“Note that, per RFC4364, every RD be=
gins with a two-octet type field


   that is either 0, 1, or 2.  =
By adding 16 to the second octet of the


   RD, we force the type field to be=
 16, 17, or 18. “


 


[SLI] It works but we may need to ensure that =
the types > 16 cannot be used anymore by new applications. Moreover if n=
ew RD types are created, new siblings will have to
 be created.


Wouldn’t it be easier to set the MSB of =
the RD type to 1 ? so we only lock half of the type space.


Or what could be the impact of using the RD of=
 the local VRF of the egress node ?


 


Section 5.3


 


“In the case where the egress


   node is not a PE, but rather an A=
BR or ASBR, it will not know whether


   it needs to receive a given flow =
unless it receives a Leaf A-D route


   whose NLRI specifies that flow an=
d whose IP-address-specific RT


   specifies an address of the egres=
s node.”


 


[SLI] The sentence works but when reading it I=
 needed multiple reread to understand that the “IP-address-specific R=
T


   specifies an address of the egres=
s node.” was referring to the ASBR/ABR and not the receiver PE.<=
/o:p>


Do you mind using “this egress node̶=
1; or “this ABR/ASBR” ?


 


 


Section 8.


[SLI] Do we have counter-measures against such=
 “attack” ? Ingress PE dropping ?


 


 


 


Section 9.2


I think RFC7524 needs to be referenced as normative =
giving that its knowledge is required to understand section 5.3. I think th=
at section 5.3 is also updating/complementing the procedures in RFC7524 wit=
h the “no-tunnel info” case.


 


 


 


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  N=
EW !

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_9E32478DFA9976438E7A22F69B08FF921EB01322OPEXCLILMA4corp_-- --_004_9E32478DFA9976438E7A22F69B08FF921EB01322OPEXCLILMA4corp_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=1093; creation-date="Wed, 03 Jan 2018 13:01:09 GMT"; modification-date="Wed, 03 Jan 2018 13:01:09 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_9E32478DFA9976438E7A22F69B08FF921EB01322OPEXCLILMA4corp_--