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

["Landry, Jean-Philippe" <[e-mail]>]

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

________________________ 
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: [e-mail] [mailto:[e-mail]] 
Sent: Friday, September 02, 2016 11:49 AM
To: Landry, Jean-Philippe; Ogaki, Kenichi
Cc: [e-mail]
Subject: RE: [L3sm] [l3sm] #20 (draft-ltsd-l3sm-l3vpn-service-model): Placement of the management branch

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,