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

[<[e-mail]>]

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:[e-mail]] On Behalf Of Landry, Jean-Philippe
Sent: Friday, September 02, 2016 14:29
To: Ogaki, Kenichi
Cc: [e-mail]
Subject: Re: [L3sm] [l3sm] #20 (draft-ltsd-l3sm-l3vpn-service-model): Placement of the management branch

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: [phone]
<<mailto:[e-mail]>>
https://session.collaboration.bell.ca/join/krcwz 



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

Hi,

Same comment to issue#15.

All the best,
Kenichi

-----Original Message-----
From: L3sm [mailto:[e-mail]] On Behalf Of l3sm issue tracker
Sent: Thursday, September 01, 2016 7:16 AM
To: [e-mail]; [e-mail]
Cc: [e-mail]
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: [e-mail]   |  Owner: draft-ltsd-l3sm-l3vpn-
  Type: defect     | [e-mail]
 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
[e-mail]
https://www.ietf.org/mailman/listinfo/l3sm

_______________________________________________
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.