Subject: Re: [L3sm] [l3sm] #3 (draft-ltsd-l3sm-l3vpn-service-model): M to N availability support

From: Qin Wu <[email-masked]>
Date: Thu, 12 Nov 2015 08:06:04 +0000

If we stick to one site with one attachment, with the following proposals, we still don't know how one site with primary access is related to another site with backup access,
We still don't know how one site with loadsharing access is related to another site with another loadsharing access. Yes, introducing site-group-id can address this issue, 
Alternatively, if we allow one site with multi-attachment, then site-group-site is not needed in case different access type belong to the same site. It is unlikely to have multiple attachment for site available belonging to different site.

One comment on "multihomed"identity proposal, it looks single service type corresponds to single homing scenario, primary backup service type corresponds to dual homing scenario,
Loadsharing service type corresponds to multi-homing scenario (see section 5.2.1.2), it looks confusing if we introduce "multihomed" as another new service type for site-availability.

-Qin
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2015年9月30日 15:57
收件人: [email-masked]; Qin Wu
主题: RE: [L3sm] [l3sm] #3 (draft-ltsd-l3sm-l3vpn-service-model): M to N availability support

Hi,

Here is what we have :
- a site is defined as a network attachment, so if a real customer site requires dualhoming, there is a need for two sites. Do we need to change this assumption and having a single site with multi-attachment ?

-Then we have for a site the possibility to define : loadsharing or primary/backup, so we cannot manage M to N availability.
Two proposals :
1) Add a "multihomed" identity for site-availability in addition to a "preference" access-type identity. In case "preference" access-type is used, we may use a conditional leaf preference-value to give order of preferences  between sites (same preference between multiple sites = loadsharing if preferred). We keep other identities to identify easily more simple cases. The number of customers using M to N is very low compared to the one using primary/backup or simple loadsharing. So from an abstraction point of view, it may be good to keep it.
2) Use only preference (no more need of identity) and remove service-type and access-type in availability.

Thoughts ?

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of l3sm issue tracker
Sent: Wednesday, September 23, 2015 09:38
To: [email-masked]
Cc: [email-masked]
Subject: [L3sm] [l3sm] #3 (draft-ltsd-l3sm-l3vpn-service-model): M to N availability support

#3: M to N availability support

 In v(-01),Site Availability support primary-back,loadsharing,single.
 In prague meeting, Kireeti Kompella brought up a case where there is M  primary,N backup,loading sharing among M primary, N backups for backup, do  we support M to N availability in service model? How do we support it?

 One relevant question is,In v(-01), can one site provide more than one  attachment? If not, how do we know one site offering backup access is used  for another site offering primary access?

-- 
-------------------------------------------------+----------------------
-------------------------------------------------+---
 Reporter:  [email-masked]                   |      Owner:  Site
     Type:  enhancement                          |  Availability
 Priority:  minor                                |     Status:  new
Component:  draft-ltsd-l3sm-l3vpn-service-model  |  Milestone:
 Severity:  -                                    |    Version:
                                                 |   Keywords:
-------------------------------------------------+----------------------
-------------------------------------------------+---

Ticket URL: <http://trac.tools.ietf.org/wg/l3sm/trac/ticket/3>
l3sm <http://tools.ietf.org/l3sm/>

_______________________________________________
L3sm mailing list
[email-masked]
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.

---

From: <[email-masked]>
Date: Thu, 12 Nov 2015 13:20:32 +0000

We can go to modeling a site as referring to a customer site and no more to a particular access.
You would find a proposal attached.

The "sites" container really refer as a site and it may be composed of multiple "site-network-access"
Routing-protocols (named as routing-information) is part of the site, not the access, as we expect to use the same routing on both accesses ... (to be discussed as there are always corner cases I know where it does not).

Svc-input-bw/output-bw is moved to site-network-access.

"Site-availability" container is removed. But an "availability" container is created in site-network-access with an access-priority leaf which allows to encode the preference of the access within the site.
It's really flexible as you can encode anything, but IMO, it brings a lot of complexity in the OSS layer to find the appropriate design and configuration.
We may impose some convention here to limit the usage , example leave only a range "1..3", one being the highest priority. We can write that to encode a primary/backup, we should use 1 for primary, 2 for backup,3 for last resort. For loadsharing, every accesses using 1.  Multiple primary, backups and last resort could be implemented :
Two accesses with 1, and two accesses with 2 will represent two primary links in loadsharing, in case both are inaccessible, we would use the two backups in loadsharing mode.
I hope 3 levels of priority is enough ...

Thoughts ?

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Thursday, November 12, 2015 09:06
To: LITKOWSKI Stephane SCE/OINIS; [email-masked]
Subject: Re: [L3sm] [l3sm] #3 (draft-ltsd-l3sm-l3vpn-service-model): M to N availability support

If we stick to one site with one attachment, with the following proposals, we still don't know how one site with primary access is related to another site with backup access, We still don't know how one site with loadsharing access is related to another site with another loadsharing access. Yes, introducing site-group-id can address this issue, Alternatively, if we allow one site with multi-attachment, then site-group-site is not needed in case different access type belong to the same site. It is unlikely to have multiple attachment for site available belonging to different site.

One comment on "multihomed"identity proposal, it looks single service type corresponds to single homing scenario, primary backup service type corresponds to dual homing scenario, Loadsharing service type corresponds to multi-homing scenario (see section 5.2.1.2), it looks confusing if we introduce "multihomed" as another new service type for site-availability.

-Qin
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]]
发送时间: 2015年9月30日 15:57
收件人: [email-masked]; Qin Wu
主题: RE: [L3sm] [l3sm] #3 (draft-ltsd-l3sm-l3vpn-service-model): M to N availability support

Hi,

Here is what we have :

Thoughts ?

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of l3sm issue tracker
Sent: Wednesday, September 23, 2015 09:38
To: [email-masked]
Cc: [email-masked]
Subject: [L3sm] [l3sm] #3 (draft-ltsd-l3sm-l3vpn-service-model): M to N availability support

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.

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Sat, 14 Nov 2015 11:48:24 +0900

Hi Stephane,

Should we control requested-site-start/stop and actual-site-start/stop per site-network-access level or not?

As I wrote before, "local-as" equivalent to the current autonomous system and "remote-as" in bgp should be specified for both PE and CE side, because the customer has to know the remote-as for PE to be configured on their CE when CE is customer-managed.
"customer-lan-connection" should have pairs of CE LAN address(address) and prefix(lan), because the management system cannot set CE LAN interface without the prefix when CE is provider-managed.

A proposal is as follows.

In this model, how can we differentiate bgp ip-connection with customer-lan-connection/cascaded-lan-prefixes and static ip-connection with them?

+--rw routing-information
|   +--rw bgp
|   |  +--rw address-family*   identityref
|   |  +―-rw local-as?         uint16
|   |  +--rw remote-as?	 uint16
|   +--rw static
|   |  +--rw customer-lan-connection* [address]
|   |  |  +--rw address        union
|   |  |  +--rw lan            union
|   |  |  +--rw lan-protocol?  identityref
|   |  +--rw cascaded-lan-prefixes
|   |     +--rw ipv4-lan-prefixes* [lan]
|   |     |  +--rw lan         inet:ipv4-prefix
|   |     |  +--rw lan-tag?    string
|   |     |  +--rw next-hop    inet:ipv4-address
|   |     +--rw ipv6-lan-prefixes* [lan]
|   |        +--rw lan         inet:ipv6-prefix
|   |        +--rw lan-tag?    string
|   |        +--rw next-hop    inet:ipv6-address

"inet:ipv4-prefix" includes mask information, then "sites/site-network-access/ip-connection/ipv4/subnet/addresses/mask" is not necessary, also ipv6. And, the type of "sites/site-network-access/ip-connection/ipv6/address-allocation-type” should be “identityref”.

All the best,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, November 12, 2015 10:21 PM
To: Qin Wu; [email-masked]
Subject: Re: [L3sm] [l3sm] #3 (draft-ltsd-l3sm-l3vpn-service-model): M to N availability support

Thoughts ?

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Thursday, November 12, 2015 09:06
To: LITKOWSKI Stephane SCE/OINIS; [email-masked]
Subject: Re: [L3sm] [l3sm] #3 (draft-ltsd-l3sm-l3vpn-service-model): M to N availability support

-Qin
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]]
发送时间: 2015年9月30日 15:57
收件人: [email-masked]; Qin Wu
主题: RE: [L3sm] [l3sm] #3 (draft-ltsd-l3sm-l3vpn-service-model): M to N availability support

Hi,

Here is what we have :

Thoughts ?

---

From: Qin Wu <[email-masked]>
Date: Mon, 16 Nov 2015 09:13:41 +0000

-----邮件原件-----
发件人: L3sm [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2015年11月12日 21:21
收件人: Qin Wu; [email-masked]
主题: Re: [L3sm] [l3sm] #3 (draft-ltsd-l3sm-l3vpn-service-model): M to N availability support

[Qin]: The figure in the attached proposal is malformed, please fix it.

[Qin]:So the site-availability is changed as "access-availability".

[Qin]: Agree. Encoding provides flexibility to support M to N availability support but the downside is availability support is implicated represented using encoded value.
With site-availability, we can explicit express availability support by using service type and access type. Do we have way to keep access type and service type when we consider moving availability parameter under site-network-access?

Thoughts ?

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Thursday, November 12, 2015 09:06
To: LITKOWSKI Stephane SCE/OINIS; [email-masked]
Subject: Re: [L3sm] [l3sm] #3 (draft-ltsd-l3sm-l3vpn-service-model): M to N availability support

-Qin
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]]
发送时间: 2015年9月30日 15:57
收件人: [email-masked]; Qin Wu
主题: RE: [L3sm] [l3sm] #3 (draft-ltsd-l3sm-l3vpn-service-model): M to N availability support

Hi,

Here is what we have :

Thoughts ?