Re: [Idr] Part 3 of CAR/CT Adoption call (7/14/2022 to 7/27/2022) - Operational Differences

[Kaliraj Vairavakkalai <[e-mail]>]

Bruno, inline pls.

Thanks,
Kaliraj

From: [e-mail] <[e-mail]>
Date: Thursday, July 21, 2022 at 6:10 AM
To: Kaliraj Vairavakkalai <[e-mail]>
Cc: Susan Hares <[e-mail]>, [e-mail] <[e-mail]>
Subject: RE: [Idr] Part 3 of CAR/CT Adoption call (7/14/2022 to 7/27/2022) - Operational Differences
[External Email. Be cautious of content]

Hi Kaliraj,

Thanks for taking the time to reply.
Please see inline [Bruno]



Orange Restricted
From: Kaliraj Vairavakkalai <[e-mail]>
Sent: Wednesday, July 20, 2022 5:19 AM
To: DECRAENE Bruno INNOV/NET <[e-mail]>; Susan Hares <[e-mail]>; [e-mail]
Subject: Re: [Idr] Part 3 of CAR/CT Adoption call (7/14/2022 to 7/27/2022) - Operational Differences

Hi Bruno,

I feel like you may not be considering Anycast EP?

[Bruno]
- without “EP”: my reading is that implicitly, you means that Anycast (without “EP”) worst just fine with BGP CAR. So let’s make this explicit.

KV> No. I meant ‘Anycast Endpoint’. I meant, CAR can mis-route for ‘Anycast Endpoints’ in non-agreeing color domains.

- with “EP”: I’m not completely certain what “EP” means. From BGP-CT,  “EP : End point, a loopback address in the network.”. Anycast EP is not self-explicit to me,

KV> Anycast EP is an ‘Anycast IP-address’, that would be used as nexthop in BGP service route updates.

but from below email, I’ll assume that it’s “anycast” but not really “any” i.e. Ingress wants visibility of each path and be able to select the one it want.

KV> The mis-routing observation is for non-agreeing color domains, using anycast endpoints.

Please see following threads that discuss possibility of Mis-routing,
ECMP, and Color management problems with Anycast-EP deployments,
when using Color in NLRI.

https://mailarchive.ietf.org/arch/msg/idr/nAj25sX0x_lp09VEqUDSCxmDR_w/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/nAj25sX0x_lp09VEqUDSCxmDR_w/__;!!NEt6yMaO-gk!C4w6ZczSTEpo1-jQ373xH2qTNYLEQFnOgZ18EOZVMr6sKSlhs2Izv8MFExT4nVLKukZ1LU9GVhBEqU1zyVMBE8jSyw$>

[Bruno]
Honestly, I’m not seeing any “Mis-routing, ECMP, and color management problems”. I’m seeing some questions been asked.

KV2> It is the second email-thread that talks about Misrouting. Pasting link again here:
KV2> https://mailarchive.ietf.org/arch/msg/idr/yI9y1iik3hO-dATSrvi4ST4K9CY/
KV2> Shunwan seems to understand the problem. And DJ as-well. All DJ is saying is the color
KV2> needs to be coordinated, and when doing so, the color-management problem appears for
KV2> the ‘improving visibility to ingress’ case.

I don’t feel that my email and your above thread are discussion the same point:

KV2> They are related. I’ll try to connect the dots. Please read on..

- My original email is on NLRI.key.
One want (at least) one path per (Intent, EndPoint). Hence IMO as per BGP (4271) BGP rule, the natural encoding of the NLRI.key is to include (EndPoint, Intent).

KV2> So in the example (non agreeing color domains),
         @D2
              (IP1,100), LCM=200 (from D3)
              (IP1,100)          (from D4)
KV2> The two routes indicate different ‘effective-intent’, even though they have same Color value in the NLRI.

KV2> So path-selection uses these two routes to do ECMP/protection. Ref : https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-04#section-2.7

- Your thread seems to be about color resolution/indirection between the service route and the transport route.

KV2> It is about the resolution of the Transport-route(CAR) over the correct intent.
KV2> because the ‘effective intent’ of these paths is not the same (one of them has an LCM)
KV2> they resolve over different intents. But path-selection NLRI.key does not take this into account.
KV2> So traffic intended for SLA 100 can get routed into SLA 200, or the reverse. Hence, mis-routing is possible.

On this point, my co-authors would be much more competent to reply. A priori, it seems to me that the use of Local-Color-Mapping (LCM) Extended Community addresses your point (mapping to a third color if needed; which represent the intent as seen by the service). And, speaking for myself only, if you/the WG really want to have this resolution color always encoded in a community, one could possibly always attach this community (up to mandating this in the draft is needed). That seems like an optimization/minor point to me (i.e. nothing fundamental)

KV2> From my analysis of CAR so far, I see the procedures specified there work for simple cases, that dont involve Anycast or Non-agreeing Color-domains.
KV2> As a WG member, I feel necessary to alert the customers that they should consider these scenarios when deploying CAR. Once agreement is reached,
KV2> it may be best to describe these as Caveats in the CAR draft.
KV2> BGP-CT handles all these cases without exception, because it follows RFC-4364 procedures. Please read on.

https://mailarchive.ietf.org/arch/msg/idr/OOZOBSyjdAYBar8NxvOqo6-5fAc/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/OOZOBSyjdAYBar8NxvOqo6-5fAc/__;!!NEt6yMaO-gk!C4w6ZczSTEpo1-jQ373xH2qTNYLEQFnOgZ18EOZVMr6sKSlhs2Izv8MFExT4nVLKukZ1LU9GVhBEqU1zyVONUnWQRA$>

[Bruno]
IP anycast, by definition, mandates coordination between the endpoints (‘ domains) to agree on the IP to use.
So coordination is granted and IMO they should also coordinate on the color to use. (if it were me, I’d say that the “owner” of the IP address is the one choosing/allocating the color to use). With that, I think that the problem does not exist.

KV2> The scenario being discussed here is administrative-domains which don’t have one Color-namespace across all the domains.
KV2> Sure, the problem can be solved in different places. CT solves it in the protocol. In CAR operators coordinate that problem doesn’t happen.
KV2> All customer networks may not be able to reach such an agreement, to have single color namespace. Especially across network mergers.


(note that one could probably find a similar example with BGP-CT. With RD type 1, the administrator field is an IP address. An easy choice seems to use the IP address of the endpoint. In which case, it seems to me that with BGP-CT one could have (derived from your email)
         @D2
              (01:IP1:O1:IP1), TCID=200 (from D3)
             (01:IP1:O1:IP1), TCID=100 (from D4)


             (01:IP1:O2:IP1), TCID=100 (from D3)
              (01:IP1:O2:IP1), TCID=200 (from D4)

Note: 01:IP1:01:IP is RD:Endpoint and more precisely  “RD type”:” Administrator subfield”: Assigned Number subfield:EndPoint IP address
With that BGP-CT have the same problem

KV2> Nope. CT doesn’t have a problem. Because the endpoint routes are organized in a Transport-Route-DB, which is per TC.
KV2> So, we will have :
KV2>     TC100 TRDB :
KV2>            (IP1), (from D4)
KV2>            (IP1), (from D3)
KV2>     TC200 TRDB :
KV2>            (IP1), (from D3)
KV2>            (IP1), (from D4)

KV2> So the path selection that happens in the TRDB (context of TCID)
KV2> does not mix different SLAs, irrespective of what the NLRI key contains.


(same NRLI.index for different intents). In both cases, the root cause is that the owner of IP1 needs to coordinate/maintain the sub allocations spaces (color for BGP-CAR, Assigned Number subfield for BGP-CT)

Regards,
--Bruno


Further pls see inline for some responses on RD usage. KV>

Thanks
Kaliraj
From: Idr <[e-mail]<mailto:[e-mail]>> on behalf of [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, July 19, 2022 at 5:31 AM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] Part 3 of CAR/CT Adoption call (7/14/2022 to 7/27/2022) - Operational Differences
[External Email. Be cautious of content]

Hi Sue, all,

> This forum (Part 3) is place to discuss operational differences between the CAR and CT drafts.

> These procedures for this mail thread are:

> A.      On original discussion on point in a draft
> 1.      Text in either the CAR or CT draft that is applicable to the operational difference.

I think that a key point is the NLRI key, i.e. the Network Layer Reachability Information, aka the reachability that we are interested in.

I’m assuming that it is clear that the reachability that we want to advertise is (EndPoint, Color). IOW, we want (at least) a path to each (EndPoint, Color).

BGP CAR uses exactly that key:

“NLRI Key: IP Prefix, Color” https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-05#section-2.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-05*section-2.1__;Iw!!NEt6yMaO-gk!BUOqY4kARoJB8KWs7XqqThd3l2Sv8Ku8YKKxy3R_zz6aZR0rLFIRVHbu5DlIWdiV8gdIxjKLNk7ISrMEAcohYAerDQ$>

“    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

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |  NLRI Length  |  Key Length   |   NLRI Type   |Prefix Length  |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |               IP Prefix (variable)                           //

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |               Color (4 octets)                                |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ »



https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-05#section-2.9.2<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car-05*section-2.9.2__;Iw!!NEt6yMaO-gk!BUOqY4kARoJB8KWs7XqqThd3l2Sv8Ku8YKKxy3R_zz6aZR0rLFIRVHbu5DlIWdiV8gdIxjKLNk7ISrMEAcqJwMTh0w$>




BGP CT uses a different key, namely (RD, EndPoint):

KV> yes, and the color is carried in the RT. RD dont carry any meaning, just a distinguisher.
KV> So path-selection happens for just ‘EP’ in context of a Color (Transport class Route DB).

“When AFI/SAFI is 1/76, the Classful Transport NLRI Prefix consists of an 8-byte RD followed by an IPv4 prefix.”


“      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

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |    Length     |                 Label                 |Rsrv |S|

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     ~                     Route Distinguisher (8 bytes)             |

     |                                                               |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |                     IPv4/IPv6 Prefix                          ~

     |                                                               |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



         Fig 2: SAFI 76 "Classful Transport" NLRI”



“Route Distinguihser:



     8 byte RD as defined in [RFC4364 Sec 4.2].”



https://www.ietf.org/archive/id/draft-kaliraj-idr-bgp-classful-transport-planes-17.html#name-bgp-classful-transport-fami<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-kaliraj-idr-bgp-classful-transport-planes-17.html*name-bgp-classful-transport-fami__;Iw!!NEt6yMaO-gk!BUOqY4kARoJB8KWs7XqqThd3l2Sv8Ku8YKKxy3R_zz6aZR0rLFIRVHbu5DlIWdiV8gdIxjKLNk7ISrMEAcrmRg2_nQ$>



> 2.      Provide a sample topology.


[cid:image001.jpg@01D89CFA.65ED09A0]


> 3.      Discuss the pros/cons clearly stating whether your post is a: pro, con, or clarifying question.

BGP CAR uses the key/NLRI that we do want to propagate: (EndPoint, Color). That’s a good fit.

BGP CT uses, as key, (RD, Endpoint), with RD as defined in RFC4364.
Two observations:

a)       (RD, Endpoint) is not the NLRI that we want to reach. We want to reach (EndPoint, color)
KV> EP with Transport-Target:0:<color> gives that info. RD is just the messenger, disambiguator
KV> in BGP updates.

b) In VPN/RFC4364, the purpose of the RD is to _distinguish_ EndPoint (IP prefix) because they are not unique across VPNs. That is not needed for the BGP color use case because EndPoint are Public (or a minimum agreed upon by a set of consenting adults)

KV> Even here, an EP has a different personality in context of a transport-layer color.
KV> E.g. in your topology, the reachability info to reach EP ‘E’ via a certain Color Gold
KV> is different from the reachability info to reach same EP via a different color Bronze.
KV> So though EP E is a provider-space ‘public’ IP-address, it has a different per color
KV> persona/instance, which need to be distinguished in a BGP update. CAR uses
KV> color to disambiguate those instances in a BGP-update, CT uses RD.


“a” and “b” are two arguments against using (RD, EndPoint) as the NLRI.key.

There has been some argument that RD may be useful to advertise multiple path for a destination (Endpoint, Color) or even to identify the source of the advertisement.
- This is not inline with the definition of RD / RFC4364 which states

“An RD is simply a number, and it does not contain any inherent

   information; it does not identify the origin of the route or the set

   of VPNs to which the route is to be distributed.  The purpose of the

   RD is solely to allow one to create distinct routes to a common IPv4

   address prefix. »

https://datatracker.ietf.org/doc/html/rfc4364#section-4.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc4364*section-4.1__;Iw!!NEt6yMaO-gk!BUOqY4kARoJB8KWs7XqqThd3l2Sv8Ku8YKKxy3R_zz6aZR0rLFIRVHbu5DlIWdiV8gdIxjKLNk7ISrMEAcpHQUYXfQ$>

KV> RD does not identify destination or source of route, for route leaking purposes. But _when_ unique RDs are
KV> in use, it does aid in troubleshooting. That is what we meant. We do recommend using unique-RDs, but not
KV> mandatory. Same-RDs MAY be used when path-information need to be filtered out.

KV>    https://datatracker.ietf.org/doc/html/draft-kaliraj-idr-bgp-classful-transport-planes-17#section-10.9<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-kaliraj-idr-bgp-classful-transport-planes-17*section-10.9__;Iw!!NEt6yMaO-gk!C4w6ZczSTEpo1-jQ373xH2qTNYLEQFnOgZ18EOZVMr6sKSlhs2Izv8MFExT4nVLKukZ1LU9GVhBEqU1zyVNMBqEirg$>

KV>      Deploying unique RDs is strongly RECOMMENDED because it helps in
KV>      troubleshooting by uniquely identifying originator of a route and
KV>      avoids path-hiding.

KV> Following email from Balaji nicely summarises the benefits of using RD :
KV> https://mailarchive.ietf.org/arch/msg/idr/mZEyLrvb2ooXDvGMryznZBac7BE/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/mZEyLrvb2ooXDvGMryznZBac7BE/__;!!NEt6yMaO-gk!C4w6ZczSTEpo1-jQ373xH2qTNYLEQFnOgZ18EOZVMr6sKSlhs2Izv8MFExT4nVLKukZ1LU9GVhBEqU1zyVOhWOcP8A$>

That RD purpose is absolutely not needed in the use case that we are discussing, because the IP address prefix is unique/has a single meaning.

KV> Consider Anycast use-cases, where the same EP may be used on multiple nodes, so not unique.

So really no need to re-add a RD with public name space, which would typically contain …. an IP address in most discussions (and possibly the same IP address of the EndPoint if the route is sourced by the destination…).


So in summary, the NLRI.key proposed in BGP CT (RD, EndPoint) is not a good fit. While the NLRI.key proposed in BGP CAR (EndPoint, Color) is the right fit.

KV> Please see threads referred to in beginning on this email that describe problems because of color is carried in NLRI.

Going further, let’s assume that we have a RD field because… we have one. What could be its use?
One proposal was to advertise the source. But this explicitly contradicts RD definition in RFC4364 (cf above). This is also not the typical operational model, both for Internet and VPN, where the source is typically indicated using a community or extended community (e.g., site of origin).

KV> It is good to hear consensus that things like SOO Community are in common use, which affect the update packing arguments.

One proposal was to advertise multiple paths for the same destination. However:
- RD(s) is(are) chosen by the originator ie. the egress domain. There is no reason that this AS choose the right number of paths as best fists all others (ingress, transit) ASes. E.g. in above figure, AS1 may advertise 3 RD/paths, while may be AS3 would be willing to have 5 RD/paths.

KV> The RDs chosen by egress-domain are propagated as-is by transit domain to ingress. This model does not need additional
KV> Colors in those transport-networks. The Egress may originate RD per service-function or stats-group. I agree that these
KV> functions will be confined to egress-domain, as you note. E.g. for the ‘per-ASBR statistics usecase’ in topology above,
KV> node E can use three RDs to get stats of traffic coming from three ASBRs (A12, B12, C12) in its domain, irrespective of
KV> which ASBRs in other domains this traffic traversed.

KV> Another example is : different service-funcions (SF1, SF2) can be attached to the node E, such that RD1:E, RD2:E can be
KV> used to advertise these service functions with different UHP labels in BGP-CT, while using same Transport-class RT. So
KV> provisioning new colored tunnels in the transport network is not required.

KV> In CAR, for such usecases, operator will have the provisioning and management overhead of using distinct Colors
KV> (because Color is the distinguisher in CAR NLRI), and will have to co-ordinate to resolve them over
KV> the ‘same SLA tunnel’ in the transport-layer. And again, using multiple colors to represent same SLA prevents
KV> ECMP/Protection between the CAR NLRIs.
KV> Ref : https://mailarchive.ietf.org/arch/msg/idr/nAj25sX0x_lp09VEqUDSCxmDR_w/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/nAj25sX0x_lp09VEqUDSCxmDR_w/__;!!NEt6yMaO-gk!C4w6ZczSTEpo1-jQ373xH2qTNYLEQFnOgZ18EOZVMr6sKSlhs2Izv8MFExT4nVLKukZ1LU9GVhBEqU1zyVMBE8jSyw$>


- It’s very possible that the number of RD be not even chosen by the egress AS. Based on Seamless MPLS work, I would assume that the route be either originated by the egress PE (in which case a single route/RD) is used, or by the ASBRs of the egress AS (in which case the number of route/RD is the number of ASBR of this AS, e.g. 3 in the above figure, irrespectively of other considerations).


If a distinguisher field would be needed for some deployments, a priori I would personally not be opposed to have (EndPoint, Color, distinguisher) with distinguisher being a simple unsigned integer field. That been said, with a 32-bits color field, I feel like we already have plenty of room without adding a distinguisher.

Thanks,
Regards,
--Bruno



Orange Restricted
From: Idr <[e-mail]<mailto:[e-mail]>> On Behalf Of Susan Hares
Sent: Thursday, July 14, 2022 10:17 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [Idr] Part 3 of CAR/CT Adoption call (7/14/2022 to 7/27/2022) - Operational Differences

The IDR Adoption call for CAR and CT technologies is extended for an extra week
(7/14/2022 to 7/27/2022).

The IDR adoption call on Q2 has brought many discussions on pro/cons of the CAR
and CT BGP technologies:
https://mailarchive.ietf.org/arch/msg/idr/AP_ClbZgpkX6CNy7TaZiU8SMD5w/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/AP_ClbZgpkX6CNy7TaZiU8SMD5w/__;!!NEt6yMaO-gk!BUOqY4kARoJB8KWs7XqqThd3l2Sv8Ku8YKKxy3R_zz6aZR0rLFIRVHbu5DlIWdiV8gdIxjKLNk7ISrMEAcqHJPNgyQ$>

Since the IDR chairs agree with the summary of Jeff Haas (IDR Co-chair) posted on March 21, 2022 –
that for route resolution and route origination/propagation, BGP-CAR and BGP-CT
are functionally identical, but operationally different.
    ( https://mailarchive.ietf.org/arch/msg/idr/e69NRd9i2aG0WUxFkShEfQHZsHo/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/e69NRd9i2aG0WUxFkShEfQHZsHo/__;!!NEt6yMaO-gk!BUOqY4kARoJB8KWs7XqqThd3l2Sv8Ku8YKKxy3R_zz6aZR0rLFIRVHbu5DlIWdiV8gdIxjKLNk7ISrMEAcrb_eR4Kg$>

This forum (Part 3) is place to discuss operational differences between the CAR and CT drafts.

These procedures for this mail thread are:


A.   On original discussion on point in a draft

1.    Text in either the CAR or CT draft that is applicable to the operational difference.

2.       Provide a sample topology.

3.       Discuss the pros/cons clearly stating whether your post is a: pro, con, or clarifying question.
Try to split clarifying question posts away from pro/con posts. Remember, you can post to this forum several times.
In your technical discussion, define your terms and avoid value judgement.



B.       On a discussion based on message in Q2 or Q1 mail list:

1.       Quote and link to Q1 or Q2 forum’s message.

2.       Text in either the CAR or CT draft that is applicable to the problem
      (Either provide the text or give specific reference (section, paragraph, and line(s)).


3.       Provide a sample topology.

4.       Summarize your viewpoint as: correction, clarifying question, pro, or con.

5.       Discuss the pro/con or text giving technical discussion.
In your technical discussion avoid define terms, give specific
examples in terms of draft text, sample topology, and facts.
If you state an opinion, back it up with technical facts.

If you are making a correction, assume the other person either misunderstood
or has a difference of opinion.  Respect each other as each IDR member is
entitled to their opinion. As a group we are working toward excellent BGP
in deployed technology.

In your delightful passion on these two technology additions to BGP (CAR and CT), please adhere to these rules.

Thank you, Susan Hares


_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles 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 electroniques 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 information 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 delete 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.


Juniper Business Use Only

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles 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 electroniques 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 information 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 delete 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.


Juniper Business Use Only