Re: [L3sm] Next Step of RFC8049

[David Ball <[e-mail]>]

Ok, if this case is the reason for having the customer-name field in the 
model, then it definitely needs a lot more explanation!

     David


On 28/06/2017 12:43, Ogaki, Kenichi wrote:
> Hi David,
>
> At least in *our* service, a Tier2-provider just sells the Tier1-provider's service with some additional values, and the original service is operated by the Tier1-provider, not by the Tier2-provider. Then, a Tier1-provider must know which vpn/site/site-network-access is used by which end-user in order to provide smooth activation/commissioning and operation.
>
> Thanks,
> Kenichi
>
> -----Original Message-----
> From: David Ball [mailto:[e-mail]]
> Sent: Tuesday, June 27, 2017 8:53 PM
> To: Ogaki, Kenichi; [e-mail]; 'Qin Wu'; [e-mail]
> Subject: Re: [L3sm] Next Step of RFC8049
>
> Thanks Kenichi - there is one of your answers that I'm still confused about, see below:
>
>
>
> On 26/06/2017 04:23, Ogaki, Kenichi wrote:
>
>
> 			4.	Under the VPN service, there is a leaf for the customer name.  If the model is supposed to represent the request from a customer to the SP, I would have thought the customer name would be known out-of-band, e.g. from the AAA for the request?  It would be bad if one customer could request things for another customer by filling in a different customer name in the model!
> 					
> 				[KO] A customer can only access the model instance of that customer. Please see section 10.
> 			
> 			
> 			[DB] Yes exactly - if a customer can only access their own instance of the model, why does the customer name need to be specified within the model?  You already know you are dealing with that customer's instance of the model.  It seems like the customer-name leaf is unnecessary?
> 			
> 			[KO] As common usecases, a VPN service is provided not only by Tier 1 providers, but also by Tier 2 providers or IT divisions of enterprises in order to provide their own end users by using a Tier 1 provider's VPN service. Such customers usually requires this kind of attributes for their management purposes.
>
> 		[DB2]
> 		I didn't really follow this, sorry.  The module contains the
> 		information that needs to be sent from the customer to the SP, right?
> 		If the customer using the model (i.e. the Tier2 in your above example)
> 		needs to track which of their own customers the service is for, that's
> 		something that's internal to them, isn't it?
>
> 	[KO3] Yes, that's internal to them, but they (i.e. our customers) really request and are currently using this. Then, we need to model this.
>
>
> Perhaps I am misunderstanding the scenario.
>
> If I understand correctly, the case is where the yang is being used between a Tier2 provider (lets call them T2-telecom) and Tier1 provider (lets call them T1-networks).  In other words, from the perspective of the RFC and the yang module, T1-networks is the SP and T2-telecom is the customer.
>
> T2-telecom has their own customers call them (foo-bank, bar-supermarket and baz-advertising).  Whenever T2-telecom orders a new VPN from T1-networks, they want to record, in their internal systems, which of their end customers the new VPN is for.  Of course there is probably a lot of other information they want to store in their internal systems about their customers, such as contact info, billing and invoicing info, trouble tickets, etc.
>
> What I don't understand is why T2-telecom would want to send the name of their end-customer (foo-bank, bar-supermarket or baz-advertising) to T1-networks as part of the netconf request when they order a new VPN.  What is T1-networks going to do with this information?
>
>
>      David
>
>

-- 
David Ball
<[e-mail]>