Re: [L3sm] Next Step of RFC8049

[David Ball <[e-mail]>]

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]>