Re: [bess] New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt

["Dikshit, Saumya" <[e-mail]>]

Thanks Sasha, for the detailed design/flows for both the symmetric/asymmetric IRB flows.

Though I am still struggling to convince myself on the thumb rule for absorbing/not-absorbing the routes,
ONLY based on Route-Targets irrespective of nature of EVIs. Since control plane procedures ought to capture/reduce
error scenarios.

Regards,
Saumya.

From: Alexander Vainshtein [mailto:[e-mail]]
Sent: Thursday, July 27, 2023 1:19 PM
To: Dikshit, Saumya <[e-mail]>
Cc: [e-mail]; Jorge Rabadan (Nokia) <[e-mail]>
Subject: RE: New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt

Saumya,
I think I have already answered that: the operator should avoid re-use of RTs associated with IP-VPN services by EVPN services – and vice versa.
If this rule of the thumb is violated, the consequences are unpredictable and, most probably, catastrophic☹.

Regarding your specific question: I guess (FWIW) that the authors of RFC 9135 have been trying to define the behavior in the following scenario:

  1.  An EVI and an IP-VPN are instantiated in PE-1 and PE-2
     *   The EVI in both PEs:

                                                               i.      Represents a certain IP subnet SN1

                                                             ii.      Uses RT-EVI as its Import and Export RT

     *   The IP-VPN uses RT-IP (that is different from RT-EVI) as its Import and Export RT
  1.  IP-VRF and MAC-VRF that locally represent this EVI and this IP-VPN in PE-1 are connected by a Symmetric IRB
  2.  IP-VRF and MAC-VRF that locally represent this EVI and this IP-VPN in PE-2 are connected by an Asymmetric IRB (because it does not support Symmetric IRBs)
  3.  IP-VRF in PE-2 is connected to yet another subnet SN2
  4.  PE-1 and PE-2 advertise to their locally connected subnets:
     *   If VPN-IP AFI/SAFI(s) are enabled in both PEs, these routes can be advertised in the corresponding AFI/SAFI
     *   Alternatively these routes can be advertised as IP Prefix (EVPN RT-5) routes with RT-IP
In this case PE-2 would be able to send traffic it receives from SN2 with the destination being a specific host on the subnet SN1 that is reachable via PE-1 as following:

  1.  It will recognize the destination as belonging to a locally attached subnet and sends it via the Asymmetric IRB.
  2.  ARP Cache of the Asymmetric IRB (that is updated from the MAC/IP Advertisement route advertised by PE-1 for this host, so its lookup will yield the correct MACF address for this host.  As a consequence, the packet will be encapsulated into an Ethernet frame with the corresponding Destination MAC address, and injected into the local MAC-VRF
  3.  The FDB of the MAC-VRF in PE-2 will contain an entry (learned from the MAC/IP Advertisement route advertised by PE-1 for this host) that points to MAC-VRF and PE-1, and the encapsulated packet will be forwarded accordingly (this is what Asymmetric IRB is supposed to do).
  4.  The MAC-VRF in PE-1 will receive the encapsulated packet and forward via the matching local Attachment Circuit.
I do not think that RFC 9135 discusses what happens in the case of misconfiguration, nor do I think such discussion is necessary.

I hope this helps.
Regards,
Sasha

From: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, July 27, 2023 9:33 AM
To: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] RE: New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt

Hi Sasha,

Thanks for the response. I am 4 months too early ☺

To further the discussion:
How should I co-relate  to the following text in https://www.rfc-editor.org/rfc/rfc9135.html#name-control-plane-receiving-pe<https://clicktime.symantec.com/15sM1H8mnTeTkMWo2VcyL?h=PB00_h9_Y3SfICxMyUqHLswwiKXoAYEuGrQyU9_s6Xo=&u=https://www.rfc-editor.org/rfc/rfc9135.html#name-control-plane-receiving-pe> :

If the receiving PE receives this route with both the MAC-VRF and IP-VRF Route Targets and the MAC/IP Advertisement route includes the MPLS Label2 field but the receiving PE only supports asymmetric IRB mode, then the receiving PE MUST ignore the MPLS Label2 field and install the MAC address in the corresponding MAC-VRF and (IP, MAC) association in the ARP table for that tenant (identified by the corresponding IP-VRF Route Target).


·       If the send side is configured with Route-Target-1 for MAC-VRF and Route-Target-2 for IP-VRF.

·       If the receive side (supports only asymmetric IRB), is configured with Route-Target-2 for MAC-VRF.
It should lead to receive side absorbing the Route, even though it’s a scenario of mis-configuration. Is there a way to corner these scenarios via control plane exchanges. ?

Regards,
Saumya,

From: Alexander Vainshtein [mailto:[e-mail]]
Sent: Monday, March 27, 2023 9:49 AM
To: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>
Subject: RE: New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt

Saumya,
More of the same – quoting from Section 2 of RFC 4360<https://clicktime.symantec.com/15sLvSwVKqxsLQgsUwDpi?h=_xrRsRiWw4JhyYOWgE8EskHvwalDtWXD_YIvMknK0Xc=&u=https://www.rfc-editor.org/rfc/rfc4360#section-2> (the relevant text is highlighted):


   The Extended Communities Attribute is a transitive optional BGP
   attribute, with the Type Code 16.  The attribute consists of a set of
   "extended communities".  All routes with the Extended Communities
   attribute belong to the communities listed in the attribute.

The term “set” in this context (as opposed to “list”) means that the order in which specific Extended Communities appear in this attribute is not relevant.

Regards,
Sasha

From: Alexander Vainshtein
Sent: Monday, March 27, 2023 1:09 PM
To: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>
Subject: RE: New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt

Saumya,
Lots of thanks for a prompt response.

I do not think that the order in which RTs appear in the list of extended communities has any significance in any application.
In particular, this order is not specified in RFC 9135, so that nothing prevents an otherwise interoperable implementation to add the IP-VRF Export RT first and the MAC-VRF RT second.

Regards,
Sasha

From: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>
Sent: Monday, March 27, 2023 11:56 AM
To: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] RE: New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt

Hi Sasha,

I had picked up a very simple example, in context of Route-Type-1 handling as it’s ambiguous as compared to Route-Type-2 handling (2nd label and 2nd Route-Target can be associated with IP-VRF while processing). I am sure, there may be many-more combinations/deployments/configurations which can lead to issues, if it’s worth digging into them.
That’s even more a reason to call it out explicitly in this new draft and/or flag it off as IP-VRF and not leave it to the operator.

Coming to your below example:
>>> As a consequence, MAC-VRF in PE-3 will install this route, but it will not install any routes to MAC addresses that have been learned by the MAC-VRF in PE-1 from traffic.
[SD] PE-3 can still ignore absorbing anything against Route-Target-2 in MAC-VRF (from MAC/IP route), as it can take clue from the fact that Route-Target-2 (corresponding to Label-2) is the 2nd route-target carried in the MAC/IP route, other than Route-Target-1 (corresponding to Label-1). But I agree that MAC-only routes will not be absorbed at all as it will carry only Route-Target-1.

Regards,
Saumya.

From: Alexander Vainshtein [mailto:[e-mail]]
Sent: Sunday, March 26, 2023 6:25 PM
To: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>
Subject: RE: New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt

Saumya,
My guess (FWIW) is that the operator should not “reuse” RTs used for L3 VPNs in EVPN – and vice versa.

If this rule of the thumb is violated, lots of unpleasant things can happen even without IP aliasing.

Egg,, consider the case in which:
·       PE1 contains a MAC-VRF with RT-1 and an IP-VRF with RT-2 that are connected by a Symmetric IRB
·       PE-2 contains an IP-VRF with RT-2
·       PE-3 contains a MAC-VRF with RT-2.
When MAC-VRF inPE-1 learns some IP→MAC pair {IP1, M1} from ARP/ND, it advertises an EVPN Type 2 route with RT-1 and Rt-2 attached. As a consequence, MAC-VRF in PE-3 will install this route, but it will not install any routes to MAC addresses that have been learned by the MAC-VRF in PE-1 from traffic.

My 2c,
Sasha

From: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>
Sent: Sunday, March 26, 2023 3:52 PM
To: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>; Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] RE: New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt

Hi Sasha, Jorge and all

Consider the simplistic scenario of BGP-EVPN-Peers (and Vteps), PE1 and PE2 (might be in different/same fabrics/sites/pods), wherein,

·       PE1 supports both IP A-D and MAC A-D whereas

·       PE2 supports legacy of MAC A-D.

PE1 publishes:

·       MAC A-D with Route-Target1 (for EVI-1/VNI-1/Bride-domain-1) and

·       IP A-D (for EVI-2/VNI-2/local-VRF-x) with Route-Target2
indicating MAC aliasing and IP aliasing respectively.

Whereas, PE2 is configured for

·        (EVI-1/VNI-1/Bridge-domain-1) for importing with Route-Target1, and

·        (EVI-2/VNI-2/Bridge-domain-2) for importing with Route-Target2

PE2 can surely mistake IP A-D published by PE1 for a MAC A-D and
establishes it’s next-hop database (ecmp or otherwize) accordingly against the Bridge-domain-2 instead of ignoring the IP A-D advertisement.

The difference between IP A-D/MAC A-D (Route type-1) and the Route Type-2 is that

·       in Route Type-2, the second label and the second route-target imply that its being carried for IP-VRF

·       whereas , in Route Type-1, it comes down to configuration and operators prerogative to take care of it.


https://www.rfc-editor.org/rfc/rfc9135.html#section-5.2<https://clicktime.symantec.com/15sM1GSZo6UHTMFNWpX2g?h=G4kq24V2sHHnLgNQaaqdkxzq2a1liVTw7LqgPSNsECc=&u=https://www.rfc-editor.org/rfc/rfc9135.html#section-5.2>
If the receiving PE receives this route with both the MAC-VRF and IP-VRF Route Targets and the MAC/IP Advertisement route includes the MPLS Label2 field but the receiving PE only supports asymmetric IRB mode, then the receiving PE MUST ignore the MPLS Label2 field and install the MAC address in the corresponding MAC-VRF and (IP, MAC) association in the ARP table for that tenant (identified by the corresponding IP-VRF Route Target).

For above reasons, we should have an explicit flagging off and/or atleast a dedicate section in the draft for calling-out this scenario,
as we don’t have an organic/implicit way of distinguishing between IP-VRF and MAC-VRF related attributes being carried in Route-Type-1, unlike a Route-Type-2.

Regards,
Saumya.

From: Alexander Vainshtein [mailto:[e-mail]]
Sent: Saturday, March 25, 2023 6:43 AM
To: Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>; Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt

Saumya, Jorge and all,
FWIW I concur with Jorge.

The draft states than an IP per EVI EVPN A-D route:
1.     Includes RD of IO-VEF in its NLRI
2.     Carries RT of IP-VRF.
Assuming that Import RTs of MAC-VRFs and IP-VRFs in any given PE are different, I do not see any potential for wrong mapping.

My 2c,
Sasha

Get Outlook for Android<https://clicktime.symantec.com/15sLvSFHLUnh3QRSyG7t4?h=GyX9YOygLsY9e_Nf9hF6oQ03ZR4tPLXHzRlhgVl7z-A=&u=https://aka.ms/AAb9ysg>

________________________________
From: Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>
Sent: Friday, March 24, 2023, 23:26
To: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>; Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] Re: New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt

Hi Saumya,

I don’t think there is any need for especial flagging and the route-target will identify in which VRF the route needs to be imported.
We have other cases in which a route type can be imported into a MAC-VRF or IP-VRF (see RFC9135) and there is no especial ‘flag’ for it. This has not caused any issues so I don’t see why A-D routes would create issues either, to me it is the same thing.

Thanks.
Jorge


From: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>
Date: Friday, March 24, 2023 at 6:50 AM
To: Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>, Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See https://clicktime.symantec.com/15siFA3PedCRuwP2WEnEr?h=E0vKoxusvwRmg-2Wi4QRWfCEVPf2V0B7GpSJdjOAu1Q=&u=http://nok.it/ext<https://clicktime.symantec.com/15siFA3PedCRuwP2WEnEr?h=E0vKoxusvwRmg-2Wi4QRWfCEVPf2V0B7GpSJdjOAu1Q=&u=http://nok.it/ext> for additional information.


Thank You Jorge.

Since it’s already on the field, I have few follow up queries related to “Interworking with BGP-Peers capable of ONLY MAC-aliasing”:

As I understand that the draft does not proposes any new PDU constructs and leverages existing ones (as defined for MAC-aliasing in rfc7432) to publish IP A-D per ES and IP A-D per EVI (EVPN Route Type 1) for IP-aliasing and fast-convergence respectively.

For interworking with “BGP-EVPN peers” that comply only to MAC-aliasing and not to IP-aliasing, are there any explicit procedures defined in the draft ?

As it’s expected to be Route-Target based absorption/dropping of the IP A-D (per ES or EVI) NLRI,

is the ONLY implicit way for receive-side BGP-EVPN-Peers (only expecting MAC-aliasing in network) to ignore the IP A-D routes.

If “a” is true, then is there a possibility that EVI mappings (MPLS Labels, VNIs and corresponding Route-Targets) sent in IP A-D is being leveraged by MAC-Aliasing for an Layer-2 configuration (Bridge-domain and corresponding Route Targets) and can lead to error in processing.


Instead, will it apt to call out the IP A-D from MAC A-D via an explicit flagging in the route itself. It will save the receive side BGP-EVPN peer (only doing MAC-aliasing) from processing the IP A-D with no avail. Thus saving some processing cycles which may lead to an error state.

It will be great to have a section for “backward compatibility with MAC-aliasing ONLY peers”.

Regards,
Saumya.


From: Jorge Rabadan (Nokia) [mailto:[e-mail]]
Sent: Thursday, March 23, 2023 3:58 PM
To: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>; Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt

Hi Saumya,

Yes, there are implementations deployed in networks.
For the vendor I’m aware of, it includes pretty much all transport tunnels - vxlan, mpls, sr-mpls, SRv6…
The use cases in the draft are agnostic of the transport.
Thx
Jorge
________________________________
From: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, March 23, 2023 09:51
To: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>; Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See http://nok.it/ext<https://clicktime.symantec.com/15siFA3PedCRuwP2WEnEr?h=E0vKoxusvwRmg-2Wi4QRWfCEVPf2V0B7GpSJdjOAu1Q=&u=http://nok.it/ext> for additional information.


Hello Authors of draft-sajassi-bess-evpn-ip-aliasing,

If there is an implementation reference from any Vendor for this draft https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-ip-aliasing/<https://clicktime.symantec.com/15siKzEg7Et2KtCx3oBPU?h=wNU3T3Cevp1QqxepBtv7LOJDxf-F4f7-WvODlSy5Hos=&u=https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-ip-aliasing/>.
It will be good to know if the reference fabric for the implementation. Does it includes Vxlan, if not others ?

Regards,
Saumya.

From: BESS [mailto:[e-mail]] On Behalf Of Alexander Vainshtein
Sent: Tuesday, January 10, 2023 9:14 PM
To: Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [bess] New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt

Jorge and all,
I have read the latest revision of the draft and I agree that it is ready for the WG adoption call.
From my POV it meets the two conditions that, IMHO, define WG adoption:
It addresses a real problem
It provides a reasonably good start for solution of this problem.

My 2c,
Sasha

From: BESS <[e-mail]<mailto:[e-mail]>> On Behalf Of Jorge Rabadan (Nokia)
Sent: Tuesday, January 10, 2023 3:52 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] [bess] FW: New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt

FYI

We just updated this draft based on the comments made by Sasha on the list. We also fixed some nits and updated references.
We’d like to reiterate that document is ready for WG adoption call.

Thanks.
Jorge

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, January 10, 2023 at 2:40 PM
To: A. Sajassi <[e-mail]<mailto:[e-mail]>>, G. Badoni <[e-mail]<mailto:[e-mail]>>, J. Drake <[e-mail]<mailto:[e-mail]>>, Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>, L. Krattiger <[e-mail]<mailto:[e-mail]>>, P. Warade <[e-mail]<mailto:[e-mail]>>, S. Pasupula <[e-mail]<mailto:[e-mail]>>, Ali Sajassi <[e-mail]<mailto:[e-mail]>>, Gaurav Badoni <[e-mail]<mailto:[e-mail]>>, John Drake <[e-mail]<mailto:[e-mail]>>, Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>, Lukas Krattiger <[e-mail]<mailto:[e-mail]>>, Priyanka Warade <[e-mail]<mailto:[e-mail]>>
Subject: New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt

A new version of I-D, draft-sajassi-bess-evpn-ip-aliasing-06.txt
has been successfully submitted by J. Rabadan and posted to the
IETF repository.

Name:           draft-sajassi-bess-evpn-ip-aliasing
Revision:       06
Title:          EVPN Support for L3 Fast Convergence and Aliasing/Backup Path
Document date:  2023-01-10
Group:          Individual Submission
Pages:          20
URL:            https://www.ietf.org/archive/id/draft-sajassi-bess-evpn-ip-aliasing-06.txt<https://clicktime.symantec.com/15siVeDMbsp2p1wKgTxN4?h=Bx1_zlXLVe5CXSl4uPQinOw4O-VdjSd1bRQf_MxBmjQ=&u=https://www.ietf.org/archive/id/draft-sajassi-bess-evpn-ip-aliasing-06.txt>
Status:         https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-ip-aliasing/<https://clicktime.symantec.com/15siKypngeSqz8HUbMA4p?h=izZF6rfMzUeFiWQGKAhvgPS53_OWNi_PQUtGVJSJxQo=&u=https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-ip-aliasing/>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing<https://clicktime.symantec.com/15siQp259G8SQ57Q8uZDS?h=oAVtm-7JQjfNt-rdM331nh6a308FM7ntGGsF4o4NBws=&u=https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing>
Diff:           https://author-tools.ietf.org/iddiff?url2=draft-sajassi-bess-evpn-ip-aliasing-06<https://clicktime.symantec.com/15siF9dWE2mFaBTZ3nkvC?h=tpILk5e82UtksHG0WfCcO2FrK_oHNes6kqzFmThK-S8=&u=https://author-tools.ietf.org/iddiff?url2=draft-sajassi-bess-evpn-ip-aliasing-06>

Abstract:
   This document proposes an EVPN extension to allow several of its
   multihoming functions, fast convergence and aliasing/backup path, to
   be used in conjunction with inter-subnet forwarding.  The extension
   is limited to All-Active and Single-Active redundancy modes.




The IETF Secretariat

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.


Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.