Subject: Re: [L3sm] [l3sm] #20 (draft-ltsd-l3sm-l3vpn-service-model): Placement of the management branch

From: "Ogaki, Kenichi" <[email-masked]>
Date: Fri, 2 Sep 2016 13:34:49 +0900

Hi,

Same comment to issue#15.

All the best,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of l3sm issue tracker
Sent: Thursday, September 01, 2016 7:16 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [L3sm] [l3sm] #20 (draft-ltsd-l3sm-l3vpn-service-model): Placement of the management branch

#20: Placement  of  the  management branch

 The following branch (for the CE management) is currently placed under the  site branch.

  +--rw management
  | +--rw type? identityref
  | +--rw management-transport? identityref
  | +--rw address? inet:ip-address

 This is problematic for multi CE multi homed sites.

 Recommending to move this branch under the site-network-access branch.

 While this has the potential to lead to redundant or conflicting data  accros multiple network accesses connected to the same CE, this is  necessary for multi-CE sites.

 Suggestion to avoid redundant or conflictual management info accross same  CE  network accesses would be to make the branch optional and impose on  the management solution to specify the management data on at least one of  the network access connected to any one CE (presumably the first network  access to be installed or the primary network access).

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

Ticket URL: <https://trac.tools.ietf.org/wg/l3sm/trac/ticket/20>
l3sm <https://tools.ietf.org/l3sm/>

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

---

From: "Landry, Jean-Philippe" <[email-masked]>
Date: Fri, 2 Sep 2016 12:29:03 +0000

You are correct to point out this recommendation is directly related same use case as ticket 15, which is CE diversity at a multi-homed site. 

However I would like to point out that unlike ticket 15, this is not addressable via augmentation of the diversity constraints list. In a configuration such as depicted in section 5.6 of the model, it would be impossible to specify the management parameter of each of the individual CEs of the HUB sites since  only one management block is allowed per  site.

Here is this diagram as it stands in V12 for your reading convenience:

Hub#1 LAN (Primary/backup)          Hub#2 LAN (Loadsharing)
     |                                                  |
     |     access-priority 1       access-priority 1    |
     |--- CE1 ------- PE1         PE3 --------- CE3 --- |
     |                                                  |
     |                                                  |
     |--- CE2 ------- PE2         PE4 --------- CE4 --- |
     |     access-priority 2       access-priority 1    |

                             PE5
                              |
                              |
                              |
                             CE5
                              |
                         Spoke#1 site (Single-homed)

Cheers

JPL

________________________ 
Jean-Philippe Landry, Senior Technical Architect/Architecte technique principal,
New Technology Introduction, Bell Canada
1 Alexander-Graham-Bell, E2
Verdun, QC, H3E 3B3
téléphone: (514) 391-3494 
<<mailto:[email-masked]>> 
https://session.collaboration.bell.ca/join/krcwz 

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]] 
Sent: Friday, September 02, 2016 12:35 AM
To: Landry, Jean-Philippe
Cc: [email-masked]
Subject: RE: [L3sm] [l3sm] #20 (draft-ltsd-l3sm-l3vpn-service-model): Placement of the management branch

Hi,

All the best,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of l3sm issue tracker
Sent: Thursday, September 01, 2016 7:16 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [L3sm] [l3sm] #20 (draft-ltsd-l3sm-l3vpn-service-model): Placement of the management branch

 +--rw management

---

From: <[email-masked]>
Date: Fri, 2 Sep 2016 15:49:28 +0000

Supporting Dual and single CE sounds important to me as well. I thought it was supported but it was a mistake or we broke something at a certain point, but anyway ...
It's not a trivial change and we need to take care.

What we have now is the notion of site which is globally a customer location that need to be attached to SP network. The attachment is done through site-network-accesses. Site-network-accesses can be used for subVPN as well as multihoming but we do not have the notion of CE device.
Moreover CE can be provider managed or customer managed or comanaged.
In case CE is provided by the SP, we need to know how many CEs the customer is requesting for the site and how site-network-accesses are mapped to CEs. We cannot really put management IP under site-network-accesses because this would create a 1:1 mapping between site-network-access and CE which breaks subVPN and singleCE multihomed scenarios.

So one proposal is to create a "customer-device" container under the site that will contain a list of devices with an ID.
For the management IP, it is only used for comanaged scenario but as the CE is provided by the SP, we would need a different IP per device, so we can move the management container under the list. But I do not want to open a mix of different management strategy per site (one CE provider managed, the other customer managed) so we need to explode the management container.

Container management {
	Leaf type {
	}
}
Container customer-devices {
	List customer-devices {
		Key id;
		Leaf id {
			Type string;
		}
		Container management { # only if management type is co-managed
			Leaf transport-type;
			Leaf ip-address;
		} 
	}
}
This ID can be used as a reference under site-network-access. We can add a leaf "device-id" that would be used in case of provider-managed site.

+--rw site-network-accesses
               +--rw site-network-access* [site-network-access-id]
                  +--rw site-network-access-id      svc-id
                  +--rw site-network-access-type?   identityref
                  +--rw access-diversity {site-diversity}?
                  |  +--rw groups
                  |  |  +--rw group* [group-id]
                  |  |     +--rw group-id    string
                  +--rw device-id? 	string <<<<<

Does it sound a reasonable addition ? Any other proposal ?

Best Regards,

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Landry, Jean-Philippe
Sent: Friday, September 02, 2016 14:29
To: Ogaki, Kenichi
Cc: [email-masked]
Subject: Re: [L3sm] [l3sm] #20 (draft-ltsd-l3sm-l3vpn-service-model): Placement of the management branch

                             PE5
                              |
                              |
                              |
                             CE5
                              |

Cheers

JPL

________________________
Jean-Philippe Landry, Senior Technical Architect/Architecte technique principal, New Technology Introduction, Bell Canada

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]]
Sent: Friday, September 02, 2016 12:35 AM
To: Landry, Jean-Philippe
Cc: [email-masked]
Subject: RE: [L3sm] [l3sm] #20 (draft-ltsd-l3sm-l3vpn-service-model): Placement of the management branch

Hi,

All the best,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of l3sm issue tracker
Sent: Thursday, September 01, 2016 7:16 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [L3sm] [l3sm] #20 (draft-ltsd-l3sm-l3vpn-service-model): Placement of the management branch

 +--rw management
 | +--rw type? identityref
 | +--rw management-transport? identityref  | +--rw address? inet:ip-address

_________________________________________________________________________________________________________________________

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: "Landry, Jean-Philippe" <[email-masked]>
Date: Fri, 2 Sep 2016 16:29:45 +0000

Yes, from my perspective this would indeed work.

In my initial comment I foresaw that 1:N CE to site-network-access capability could still be preserved if the model specified that management information would either have to be repeated on all site-network-accesses or be specified on at least one of them for any given CE (diversity constraint "same-CE" being the "glue" that carried the notion of common CE across the different site-network-access). Your approach is cleaner and more direct. 

I also agree that customer either want to manage their CEs or they don't for any given site they may own. Mix and matching different management types for different CEs at a given site would be over-reaching realistic requirements in my opinion.

JPL

________________________ 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, September 02, 2016 11:49 AM
To: Landry, Jean-Philippe; Ogaki, Kenichi
Cc: [email-masked]
Subject: RE: [L3sm] [l3sm] #20 (draft-ltsd-l3sm-l3vpn-service-model): Placement of the management branch

Container management {
	Leaf type {
	}
}

Best Regards,

---

From: <[email-masked]>
Date: Mon, 5 Sep 2016 07:57:42 +0000

Does anyone have objection on this proposal ?

I would like to close the updates and post a new version of the I-D asap.

-----Original Message-----
From: Landry, Jean-Philippe [mailto:[email-masked]] 
Sent: Friday, September 02, 2016 18:30
To: LITKOWSKI Stephane OBS/OINIS; Ogaki, Kenichi
Cc: [email-masked]
Subject: RE: [L3sm] [l3sm] #20 (draft-ltsd-l3sm-l3vpn-service-model): Placement of the management branch

JPL

________________________

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, September 02, 2016 11:49 AM
To: Landry, Jean-Philippe; Ogaki, Kenichi
Cc: [email-masked]
Subject: RE: [L3sm] [l3sm] #20 (draft-ltsd-l3sm-l3vpn-service-model): Placement of the management branch

Container management {
	Leaf type {
	}
}

 +--rw site-network-access* [site-network-access-id]  +--rw site-network-access-id svc-id  +--rw site-network-access-type? identityref  +--rw access-diversity {site-diversity}?

Best Regards,

---

From: <[email-masked]>
Date: Mon, 5 Sep 2016 08:32:05 +0000

I finally see one caveat with this proposal.
It works fine when both CEs are on the same location, but does not work when CEs are hosted in different locations (two buildings in the same city for example).
In this case, we need a dedicated location address for each CE to ensure proper sending of CE and bearer provisioning.

So globally we have to deal with :

1) Single CE in a single physical location
2) Dual (or more) CE in single physical location (same postal address)
3) Dual (or more) CE in different physical location

Currently the site is representing a physical location. 
We can achieve 1) easily
We can achieve 2) using the proposed scheme (adding customer-device container and device-id)

We can imagine doing 3) by creating two sites with a single site-network-access and using access-priority to implement the routing policy. So here the SP is no more aware that the two sites are in reality a multihomed site. Is is an issue ?

Any thought ?

Thanks,

-----Original Message-----
From: Landry, Jean-Philippe [mailto:[email-masked]]
Sent: Friday, September 02, 2016 18:30
To: LITKOWSKI Stephane OBS/OINIS; Ogaki, Kenichi
Cc: [email-masked]
Subject: RE: [L3sm] [l3sm] #20 (draft-ltsd-l3sm-l3vpn-service-model): Placement of the management branch

JPL

________________________

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, September 02, 2016 11:49 AM
To: Landry, Jean-Philippe; Ogaki, Kenichi
Cc: [email-masked]
Subject: RE: [L3sm] [l3sm] #20 (draft-ltsd-l3sm-l3vpn-service-model): Placement of the management branch

Container management {
	Leaf type {
	}
}

Best Regards,

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.