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

[<[e-mail]>]

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:[e-mail]] 
Sent: Friday, September 02, 2016 18:30
To: LITKOWSKI Stephane OBS/OINIS; Ogaki, Kenichi
Cc: [e-mail]
Subject: RE: [L3sm] [l3sm] #20 (draft-ltsd-l3sm-l3vpn-service-model): Placement of the management branch

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,

 


_________________________________________________________________________________________________________________________

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.