Re: [L3sm] multiVPN , subVPN , multihoming

[<[e-mail]>]

This looks acceptable to me. I will update the I-D accordingly and will post a new version including the editorial issues you found.
 

-----Original Message-----
From: Ogaki, Kenichi [mailto:[e-mail]] 
Sent: Friday, March 11, 2016 02:39
To: LITKOWSKI Stephane OBS/OINIS; [e-mail]
Subject: RE: [L3sm] multiVPN , subVPN , multihoming

Hi Stephane,

>We are almost aligned, I'm still wondering why you need the choice for the VPN policy under site-network-access.
>Could you elaborate again ? 

I'd just like to allow possible options depending on use cases, but don't want to drastically change the structure at this phase.
On this ML, someone sometimes said that the model should be simpler and not optimized to any corner case, even if SPs don't think so.

My proposal just allows the simplest expression when a customer just wants to use single-homed site(-network-access) to a single VPN without any filtering.
In *this* case, the customer doesn't need any vpn-policy under the site and only has to directly refer vpn-id under vpn-svc. Case1) If this customer want to use multiVPN at the other site, then he can define a vpn-policy and refer this at that site. Case2)

But, the site-network-access must exclusively refer vpn-id or vpn-policy-id under the site-network-access to avoid any conflict and inconsistent configuration, then we need choice statement to differentiate these two.

Is this acceptable?

Here are exercises. 
Case1)
<vpn-services>
    <vpn-svc>
        <vpn-id>VPN1</vpn-id>
        ...
    </vpn-svc>
</vpn-services>

<sites>
    <site>
        <site-id>site1</site-id>
        <site-network-accesses>
            <site-network-access>
                <site-network-access-id>logical_access#1_in_single-homing</site-network-access-id>
                <vpn-id>VPN1</vpn-id>
                ...
            </site-network-access>
        </site-network-accesses>
        ...
    </site>
<sites>

Case2)
<sites>
    <site>
        <site-id>site2</site-id>
        <vpn-policy-list>
            <vpn-policy>
                <vpn-poicy-id>multihomeVPN_policy#1</vpn-poicy-id>
                <entries>
                    <id>1</id>
                    <vpn>
                        <vpn-id>VPN1</vpn-id>
                        ...
                    </vpn>
                    ...
                </entries>
                <entries>
                    <id>2</id>
                    <vpn>
                        <vpn-id>VPN2</vpn-id>
                        ...
                    </vpn>
                    ...
                </entries>
            </vpn-policy>
        </vpn-policy-list>
        ...
        <site-network-accesses>
            <site-network-access>
                <site-network-access-id>logical_access#1_in_multi-homing</site-network-access-id>
                <vpn-policy-id>multihomeVPN_policy#1</vpn-policy-id>
                ...
            </site-network-access>
            <site-network-access>
                <site-network-access-id>logical_access#2_in_multi-homing</site-network-access-id>
                <vpn-policy-id>multihomeVPN_policy#1</vpn-policy-id>
                ...
            </site-network-access>
            ...
        </site-network-accesses>
        ...
    </site>
<sites>

BTW, I found another editorial.
On configuration examples in Sections 5.2.2.2, 6 and 7, vpn-policy/entries/vpn/vpn should be vpn-policy/entries/vpn/vpn-id.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Thursday, March 10, 2016 11:26 PM
To: Ogaki, Kenichi; [e-mail]
Subject: Re: [L3sm] multiVPN , subVPN , multihoming

Hi Kenichi,

We are almost aligned, I'm still wondering why you need the choice for the VPN policy under site-network-access.
Could you elaborate again ? 

Thanks,


-----Original Message-----
From: Ogaki, Kenichi [mailto:[e-mail]]
Sent: Monday, March 07, 2016 03:20
To: LITKOWSKI Stephane OBS/OINIS; [e-mail]
Subject: RE: [L3sm] multiVPN , subVPN , multihoming

Hi Stephane,

Thank you for refine.
See comments inline, please.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Friday, March 04, 2016 6:19 PM
To: Ogaki, Kenichi; [e-mail]
Subject: Re: [L3sm] multiVPN , subVPN , multihoming

Can I understand your group-id as a kind of VPN policy pointer ?
If yes, why not expressing it this way ?

[KO] Looks better than mine!

      +--rw sites* [site-id]
      |  +--rw site-id                  svc-id
      |  +--rw apply-template?          leafref
      |  +--rw requested-site-start?    yang:date-and-time
      |  +--rw requested-site-stop?     yang:date-and-time
      |  +--rw actual-site-start?       yang:date-and-time
      |  +--rw actual-site-stop?        yang:date-and-time
      |  +--rw location
      |  |  +--rw address?        string
      |  |  +--rw zip-code?       string
      |  |  +--rw city?           string
      |  |  +--rw country-code?   string
      |  +--rw site-diversity
      |  |  +--rw type?         placement-diversity
      |  |  +--rw site-group*   uint32
      |  +--rw management
      |  |  +--rw type?                   identityref
      |  |  +--rw management-transport?   identityref
      |  |  +--rw address?                union
      |  +--rw vpn-policy-list			=> here is the list of vpn-policies
      |  |  +--rw vpn-policy* [id]
      |  |     +--rw vpn-policy-id        svc-id
      |  |     +--rw entries* [id]
      |  +--rw maximum-routes
      |  +--rw security
      |  +--rw service
      |  +--rw routing-protocols
      |  +--rw site-network-accesses
      |     +--rw site-network-access* [site-network-access-id]
      |        +--rw site-network-access-id    svc-id
      |        +--rw apply-template?           leafref
      |        +--rw vpn-policy-id	         leafref or svc-id ?	=> here is the pointer you refer
      |        +--rw access-diversity
      |        +--rw bearer
      |        +--rw ip-connection
      |        +--rw security
      |        +--rw service
      |        +--rw routing-protocols
      |        +--rw availability
      |           +--rw access-priority?   uint32

Let me try to summarize the usage :

- single logical access + multiVPN : we define a single entry in the vpn-policy-list (one group-id) and on the site-network-access I had the reference to the vpn-policy-id, does it works like this ?
- multiple logical access for multihoming + multiVPN : we define a single entry in the vpn-policy-list (one group-id) and on each site-network-access I had the reference to the vpn-policy-id, does it works like this ?
- multiple logical access for multihoming + subVPN : we define an entry in the vpn-policy-list (one group-id) per subVPN and on each site-network-access I had the reference to the vpn-policy-id linked to the subVPN I'm using, does it works like this ?

[KO] Exactly!

That works and sounds acceptable from my point of view but user will need to manipulate this vpn-policy list and mapping to site network accesses. Is it acceptable for everyone ?

[KO] So, as I touched on the previous email, as an option, I would additionally like to define choice statement to directly refer a vpn-id or refer a vpn-policy-id depending on the use case.
If a customer use only single-homed single VPN, this makes it easier.
Like this.

+--rw site-network-acccess
|  +--rw site-network-access* [site-network-access-id]  |  ...
|  |  +--rw (choose_vpn-policy)?
|  |     +--:(if_vpn-volicy-id)
|  |     |  +--rw vpn-policy-id?	leafref
|  |     +--:(if_vpn-id)
|  |        +--rw vpn-id?	leafref


choice choose_vpn-policy {
    case if_vpn-policy-id {
        leafref vpn-policy-id {
            path "/l3vpn-svc/sites/site/vpn-policy-list/vpn-policy/vpn-policy-id";
        }
    }
    case if_vpn-id {
        leafref vpn-id {
            path "/l3vpn-svc/vpn-services/vpn-svc/vpn-id";
        }
    }
}

Does this make sense?


-----Original Message-----
From: Ogaki, Kenichi [mailto:[e-mail]]
Sent: Friday, March 04, 2016 02:26
To: LITKOWSKI Stephane OBS/OINIS; [e-mail]
Subject: RE: [L3sm] multiVPN , subVPN , multihoming

Hi Stephane,

See comments inline, please.

Thanks,
Kenichi


-----Original Message-----
From: L3sm [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Thursday, March 03, 2016 6:02 PM
To: Ogaki, Kenichi; [e-mail]
Subject: Re: [L3sm] multiVPN , subVPN , multihoming

Hi Kenichi,

Thanks for the feedback.
Some comments inline.

-----Original Message-----
From: Ogaki, Kenichi [mailto:[e-mail]]
Sent: Thursday, March 03, 2016 03:32
To: LITKOWSKI Stephane SCE/OINIS; [e-mail]
Subject: RE: [L3sm] multiVPN , subVPN , multihoming

Hi Stephane,

Thank you for the summary.

Your proposed model makes sense, but still remain to be discussed. 

Your proposed sites structure have become a little bit complex.
[SLI] Yes and no, yes because on one hand  we introduce a new hierarchy but on the other hand the hierarchy is really clear and all  "interesting stuffs" are configured under "sub-site" or "site-network-access" as today we do under "sites" and "site-network-access". In the new proposal, the site container really becomes "administrative" informations.

I really agree with the necessity of multihoming support, but for me the majority of our customers are using single-homing. They sometimes use different carrier's access line for the diversity.
So, I prefer keeping more simpler structure in the current model. Introducing a new hierarchy must bring a complexity especially for those who are not using them.
[SLI] In our case, we have tons of multihoming with different cases : loadsharing, primary/backup, M:N ... backup with other SP is also done but less common. So clearly, multihoming is a MUST for us.


Another perspective is the relationship with the device capability. I understand we shouldn't discuss any device model. But, the granularity of applying a vpn-policy can be technically the site-network-access level. This may bring another new use case in the future. Then, we should be aware of this.
[SLI] Well that depends on the definition you give to site-network-access. If it is only used for multihoming (as in my proposal), it does not really make sense to have a VPN policy per site-network-access. If you have a use case of multihoming with different policies per logical access, please tell me.


[KO] I agree. That depends on a use case, then how to use a site-network-access should depend on the use case, and this should not be optimized to multi-homing. In the current model, only site-network-access is corresponding to an ip connection one-to-one. And the fact is that we can technically differentiate vpn-policy per site-network-access(ip connection) whether one of the use cases is multi-homing or not.
So, for the model simplicity and sustainability, I just want to deal with both multi-homing and subVPN by a single syntax, site-network-accesses, with different semantics for general purposes including multi-homing and subVPN as well as future possible use cases.


So, an alternative proposal is like this.
All the vpn policies are described under sites as a groups with the group id, and each site-network-access refers one of vpn-policy by group id to be applied.


      +--rw sites* [site-id]
      |  +--rw site-id                  svc-id
      |  +--rw apply-template?          leafref
      |  +--rw requested-site-start?    yang:date-and-time
      |  +--rw requested-site-stop?     yang:date-and-time
      |  +--rw actual-site-start?       yang:date-and-time
      |  +--rw actual-site-stop?        yang:date-and-time
      |  +--rw location
      |  |  +--rw address?        string
      |  |  +--rw zip-code?       string
      |  |  +--rw city?           string
      |  |  +--rw country-code?   string
      |  +--rw site-diversity
      |  |  +--rw type?         placement-diversity
      |  |  +--rw site-group*   uint32
      |  +--rw management
      |  |  +--rw type?                   identityref
      |  |  +--rw management-transport?   identityref
      |  |  +--rw address?                union
      |  +--rw vpn-policy
      |  |  +--rw groups* [id]
      |  |     +--rw id        svc-id
      |  |     +--rw entries* [id]
      |  +--rw maximum-routes
      |  +--rw security
      |  +--rw service
      |  +--rw routing-protocols
      |  +--rw site-network-accesses
      |     +--rw site-network-access* [site-network-access-id]
      |        +--rw site-network-access-id    svc-id
      |        +--rw apply-template?           leafref
      |        +--rw vpn-policy
      |           +-rw group-id                leafref
      |        +--rw access-diversity
      |        +--rw bearer
      |        +--rw ip-connection
      |        +--rw security
      |        +--rw service
      |        +--rw routing-protocols
      |        +--rw availability
      |           +--rw access-priority?   uint32

[SLI] That works, but we need to manage group-ids (which looks similar to the sub-site ID we were discussing during the interim). I do not understand why you put the group-id under vpn-policy in the site-network-access ?


[KO] The group-id under vpn-policy in the site-network-access refers to a groups under sites/vpn-policy.
For the simplicity, I want to describe all the vpn-policies at the same place as the current model. For example, one for multi-homing and the other for a logical access in subVPN case.
When we need multi-homing, two (or more) site-network-access specify a same vpn which is described by a vpn-policy. On the other hand, when we need a logical access to a different vpn in subVPN case under the same sites, another site-network-access just have to specify to a different vpn like below.

If only a site-network-access exists in a sites and no filter necessity, users can omit sites/vpn-policy and directly specify vpn-id under site-network-access/vpn-policy as the same scheme as I proposed below with choice statement. We need to refine structure more, but this becomes simpler.

https://mailarchive.ietf.org/arch/msg/l3sm/L5dzU-3BaGWRFJ9TBJjYREMAwUE

<sites>
    <site-id>site1</site-id>
    .
    <vpn-policy>
        <groups>
            <id>multihomeVPN_policy#1</id>
            <entries>
                <id>1</id>
                <vpn>
                    <vpn>VPN1</vpn>
                    .
                </vpn>
            </entries>
        </groups>
        <groups>
            <id>subVPN_A_poicy#1</id>
            <entries>
                <id>1</id>
                <vpn>
                    <vpn>VPN2</vpn>
                    .
                </vpn>
            </entries>
        </groups>
        .
    </vpn-policy>
    .
    <site-network-accesses>
        <site-network-access>
            <site-network-access-id>logical_access#1_in_multi-homing</site-network-access-id>
            <vpn-policy>
                <group-id>multihomeVPNpolicy#1</group-id>
            </vpn-policy>
            .
        </site-network-access>
        <site-network-access>
            <site-network-access-id>logical_access#2_in_multi-homing</site-network-access-id>
            <vpn-policy>
                <group-id>multihomeVPNpolicy#1</group-id>
            </vpn-policy>
            .
        </site-network-access>
        <site-network-access>
            <site-network-access-id>logical_access#1_in_subVPN_case</site-network-access-id>
            <vpn-policy>
                <group-id>subVPN_A_poicy#1</group-id>
            </vpn-policy>
            .
        </site-network-access>
    </site-network-accesses>
    .
<sites>

I believe this is an alternative solution for both multi-homing and subVPN as well as future possible use cases, and just like to ask which structure do other operators prefer?


If a cross-reference is required in vpn-svc, we can refer these as ops-state like this.

      +--rw vpn-svc* [vpn-id]
      |  +--rw vpn-id                   svc-id
      |  +--rw customer-name?           string
      |  +--rw topology?                identityref
      |  +--rw cloud-access* [cloud-identifier]
      |  +--rw multicast
      |  +--rw mpls?                    boolean
      |  +--rw transport-constraints
      |  +--ro accommodated-sites
      |     +--ro sites*
      |        +--ro site-id
      |        +--ro site-network-access*
      |           +--ro site-network-access-id leafref


Does this make sense?
Which does the other people prefer?

BTW, what's site-vpn-flavor?
[SLI] This is the multiplexing leaf that Lucy was proposing.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Wednesday, March 02, 2016 11:30 PM
To: [e-mail]
Subject: [L3sm] multiVPN , subVPN , multihoming

Hi,

 

 

Let's try to summarize as we tried during the interim meeting :

 

We first have the site which does represent a connection of a customer location to one or more VPN services.

A site can be multihomed, this means that it will have multiple "logical connections" using different bearers and providing a certain level of access diversity. The important point here is that the N logical connections are not sharing the same bearer.

 

A site can be part of multiple VPNs and this can be achieved in two ways :

.         multiVPN : in this case, a site has a logical connection L that can belong to multiple VPNs. Filtering is available to allow some LANs related to this logical connection to be part of a specific VPN. This may correspond to a kind of Hub site, or merge of companies or complex company organization .

.         subVPN : in this case, the site has multiple logical connections, each logical connection belongs to a particular VPN. >From a customer point of view, each logical connections must never communicate between each other expect if explicitly authorized. This may correspond to a company having multiple affiliates on the same site and each affiliate is independent from each other.

 

Those three options can be mixed :

.         multihomed+multiVPN : a site has N logical connections with a different associated bearer (multihomed). This is done for resiliency. The site must access to multiple VPNs, each logical connection will belong to the same set of VPNs.

.         Multihomed +subVPN : a site has  different bearer (multihomed) => B1 to Bn. This is done for resiliency. On top of each bearer, the customer will create L1 up to Lm logical connections. Resiliency may be different for each set of logical connections : L1-Lx may be implemented on B1 to Bx' while Ly-Lm may be implemented on By'-Bn. So for a particular logical access Lx, the VPn policy will be the same on all bearers where it is implemented. But each logical access may have a different vpn-policy

.         More fancy (but that exists) : multihomed+subVPN+multiVPN : same as previous, but each logical connection (subVPN) may be part of multiple VPNs.

 

In the current model, we do not manage the bearer provisioning, and I do not think this is the role of the L3VPN model to address this, so we only have a reference (as a string) to identify the bearer on which a site-network-access is built (bearer container with bearer-reference leaf).

In case of subVPN, if we go to use site-network-access to model it, the bearer-reference will be mandatory to identify subVPN case (logical connections sharing the same bearer), I also proposed to introduce a sub-site-id leaf to identify the logical accesses that are part of a common availability group.

 

Now regarding the multiVPN case, it is today expressed by the VPN-policy. For subVPN, it was proposed to add VPN-policy under site-network-access (with a check that both cannot be used together).

In case of multihomed+multiVPN, we use the vpn-policy at site level to have benefit of inheritance (which is expected in the behavior) : all logical access has the same VPN policy by design.

In case of multihomed+subVPN, we use the vpn-policy at site-network-access level so each logical access has its own policy but inheritance is no more possible and we have to express the same VPN-policy for all the logical accesses having the same sub-site-id. Is it an issue ?

 

Now we had also on the table a proposal of expressing VPN attachment in vpn-svc instead of using the VPN-policy : this will be done by referencing sites.

This is partially working. We will have an issue with the subVPN case, where a subsite (that has no reference) must be attached to a VPN. It has no reference, because it's not part of the tree, we just have a leaf that gives information about mapping between logical-accesses and subsites. 

 

1)      Keeping VPN-policy and using it at site and site-network-access level works except for the default inheritance for the multihomed subVPN sites. 

2)      The list under vpn-svc requires a subsite path reference that we do not have in the tree. It would make sense to create a subsite under site but as mentioned during the call, this complexifies the tree. A simplification could be to always use the subsite list and so moving most of the site parameters under subsite. Site-network-access will be under subsite.

 

 

Any preference or any idea ?

 

A proposal could be to introduce this sub-site list and always using it (can we force max-element to 1 in case a leaf as a particular value ?) :

 

      +--rw sites

      |  +--rw site* [site-id]

      |     +--rw site-id            svc-id

      |     +--rw location

      |     +--rw site-diversity

      |     +--rw management

      |     +--rw site-vpn-flavor?   identityref

      |     +--rw apply-template?    leafref

      |     +--rw sub-sites

      |        +--rw sub-site* [sub-site-id]

      |           +--rw sub-site-id              svc-id

      |           +--rw requested-site-start?    yang:date-and-time

      |           +--rw requested-site-stop?     yang:date-and-time

      |           +--rw actual-site-start?       yang:date-and-time

      |           +--rw actual-site-stop?        yang:date-and-time

      |           +--rw maximum-routes

      |           +--rw security

      |           +--rw service

      |           +--rw routing-protocols

      |           +--rw vpn-policy

      |           +--rw site-network-accesses

      |              +--rw site-network-access* [site-network-access-id]

      |                 +--rw site-network-access-id    svc-id

      |                 +--rw apply-template?           leafref

      |                 +--rw access-diversity

      |                 |     ...

      |                 +--rw bearer

      |                 |     ...

      |                 +--rw ip-connection

      |                 |     ...

      |                 +--rw security

      |                 |     ...

      |                 +--rw service

      |                 |     ...

      |                 +--rw routing-protocols

      |                 |     ...

      |                 +--rw availability

      |                       ...

 

 

With this proposal, vpn-policy is only needed at sub-site level. This proposal also works with the list of references in vpn-svc instead of vpn-policy (we reference the sub-site).

"Sub-site" name may be changed, because it may be confusing, if you have any proposal . (site-network-access-group ?)

 

Thoughts ?

 

 

 

Orange logo <http://www.orange.com/> 

 

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET

Orange Expert Future Networks

phone: [phone] <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
mobile: [phone] <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>
[e-mail] <mailto:[e-mail]>  

 

 

_________________________________________________________________________________________________________________________

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.


_________________________________________________________________________________________________________________________

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.

_______________________________________________
L3sm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/l3sm


_________________________________________________________________________________________________________________________

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.

_______________________________________________
L3sm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/l3sm


_________________________________________________________________________________________________________________________

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.

_______________________________________________
L3sm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/l3sm


_________________________________________________________________________________________________________________________

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.