Re: [L3sm] Next Step of RFC8049

[Qin Wu <[e-mail]>]

Thanks David, please see my reply inline below tagged with [Qin-1]

-----邮件原件-----
发件人: David Ball [mailto:[e-mail]] 
发送时间: 2017年6月27日 19:42
收件人: Qin Wu; [e-mail]; Ogaki, Kenichi ([e-mail]); [e-mail]
主题: Re: [L3sm] Next Step of RFC8049

Thanks Qin - more below tagged with [DB4].


On 24/06/2017 10:18, Qin Wu wrote:
>
>>> 	3.	Somewhat related, I am trying to understand the difference between a site with sub-VPNs (i.e. each site-access-link is connected to a different VPN) vs treating it as two sites, each with a single site-access-link.  The text says a sub-VPN "is similar to having separate sites, but in this case the customer wants to share some physical components while maintaining strong communication isolation".  Does "this case" mean the sub-VPN case or the multiple sites case?  Either way, the customer could share physical components and maintain strong isolation, right?
>>> 	
>>> 		[KO] This case means the sub-VPN case, and your indication is right.
>>>
>>>
>>> [DB].  Ok - if it the same as using multiple sites (which would still be topologically separate even if they use the same physical components), I guess I don't understand the purpose of having sub-VPN as an option - but good to know there is nothing extra I'm missing here.
>>>
>>> [KO] Sub-VPN is a real-life usecase provided in commercial VPN services.
>> [DB2]
>> Sure, I am not disputing that this set-up exists; my question is why 
>> it should be modelled as a sub-VPN instead of modelling at separate sites?
>> The same scenario can be expressed either way, right?
>>
>> [SLI] We had this debate earlier when modeling the subVPN (using multiple sites was one of the possibility but not retained).
>> The subVPNs has the particularity of sharing a common bearer and a common CPE (it's a VRF lite CPE in term of configuration).
> [DB3]
> I agree that two site network accesses in the same site and using a subVPN can share a common bearer and a common CPE, but two site-network-accesses in different sites could also share a common bearer and a common CPE, right?  Per your answer above, the site is a notion defined by the customer, so couldn't they designate two site network accesses as being in different sites even if they share the same bearer?
>
> I understand what subVPN *can* do - what I'm trying to understand is whether there is anything that *can't* be done with multiple sites. The text suggests that there is some functional difference between these two approaches, but if so, I don't understand what it is.  It would be helpful to either make the text clearer about the difference, or else change it to say that the two approaches are functionally the same.
>
> [Qin]: How does two site-network-access belonging to two different site share the same bearer or physical component?

[DB4]
Stephane said before "The site is a notion that is defined by the customer", and described how it could be a single location or multiple locations.  My interpretation was that a "site" is independent of location, so as well as having a single site spanning multiple locations, you could also have a multiple sites at a single location.  I took the meaning to be: a site is an arbitrary collection of site network accesses, independent of how or where they are connected.  With this interpretation, I don't see any problems with two site-network-accesses, belonging to two different "sites" but connecting to the same location, sharing the same bearer (e.g. different VLANs on the same phyiscal Ethernet link).

But perhaps I have extrapolated too far from what Stephane said?  Is the intent that a given location can only have a single site (but a site can span multiple locations)?

In any case, I think the RFC would benefit from some clearer description of exactly what is meant by a "site".

[Qin-1]:Yes, Indeed, you extrapolate too much,:-), we will add a few text to clarify what the site is. Thanks!

>>> 	5.	For cloud access, a single VPN can connect to multiple cloud services, and for each cloud service you have to specify which sites are authorized to access the cloud.  Is there a reason it was modelled this way, rather than having a separate VPN service to connect to each cloud service?  If there was a separate VPN service for each cloud service, then only the right sites would be attached to the VPN for each cloud, and it would not be necessary to have a separate list of authorized sites, right?
>>> 		
>>> 	[KO] That's right.
>>>
>>>
>>> [DB] So is there a reason it was not done that way?
>>>
>>> [KO] The requirement that a VPN want to connect multiple clouds still exists. The latter case cannot cover this.
>> [DB2]
>> Can you give an example that can be modelled with multiple clouds in 
>> a single VPN that could not be modelled as multiple VPNs?
>>
>> [SLI] Using multiple VPNs has a major impact on the service design (not talking about implementation). From a service perspective, let's say that the customer starts with an any to any VPN where all sites can communicate with each other.
>> After some months, it requires a cloud interconnection, so it's hub site can spawn VM in AWS for example but the other sites should not access to AWS. From a service perspective, you need to model it as a list of authorized/unauthorized sites.
>> Now in term of implementation, you can do what you want, you can create additional VPNs, you can use ACLs or whatever... but from a service perspective, the customer has a single VPN and a cloud access with limited access.
> [DB3]
> Ok - but in this scenario, why wouldn't the customer just get a new service connecting the hub site to the cloud when they need it?
> I can see why it might be treated, commercially, as part of the same *product*, but I don't understand why it would need to be the same *service*?
>
> [Qin]:This provides fine granularity control on a site getting access to public cloud or internet.
> You may also add a new site to an existing VPN, but this site may not have authorization to get access to public cloud unless you explicitly configure it.

[DB4]
Ok - so the same functionality could be achieved by just adding a new VPN in this case, but I guess the point is that it's easier to manage this way?

[Qin-1] If my understanding is correct, Our assumption, is one VPN service can provide access to public cloud and provide cloud, data center network, we don't deem providing access to public cloud as a new VPN service,
Instead, it is part of existing VPN service.
Maybe you just have different model design.

>>> 	10.	There is a qos-classification-policy (either per-site or per-site-network-access), which describes how to map packets to the right class of service.  In a single-VPN case, this is fine, but I am not sure how to interpret it when the site is attached to multiple VPNs.  The different VPNs might have different classes of service, so doesn't the classification policy need to be per-site per-VPN, not just per-site?
>>> 	
>>> 	[KO] As described in 6.12.2.1, where to classify and apply the qos is up to the SP, and outside of scope of this model.
>>>
>>>
>>> [DB] Agreed, but that wasn't my question.  The question is, in a multi-VPN case, don't you want a different QoS policy for each VPN at the site?
>>>
>>> [KO] As I wrote below, we need at least classify/apply a qos at input/output of PE, not differentiate it per VPN. But, other SPs may want this.
>> [DB2] Right - so shouldn't the model support it?
>> [SLI] I'm not sure this is necessary, in the multiVPN case, the site is "shared", so the customer expects flows to go to sites that are located in different VPNs. The customer can use the dst-prefix or the target-site in order to set a particular class for a particular flow whatever the VPN.
> [DB3]
> Right, but it would be very easy with this mechanism for the customer to make a mistake and have a policy that maps a packet that will go to a site in one VPN to a class that only exists in the other VPN; and moreover, it would be hard for the SP to check this. Would it not be better to design the model so that these sorts of consistency checks are implicit in the structure of the model, rather than relying on the customer not to make a mistake?
>
> Of course, if all the VPNs have the same set of classes, then there is no issue.  Perhaps that is the common case?
>
> [Qin]: Attaching site to appropriate VPN is realized using vpn-attachment, either referencing VPN directly or referencing vpn policy. In that way, site will know to which VPN the packet should be forwarded.

[DB4]
Yes - the question was not about forwarding the packet, but about applying the QoS policy.

Perhaps an example will help to clarify the scenario I'm thinking of.

Suppose I have two VPNs, "foo" and "bar".  At a particular site, I use the VPN policy to attach the site to both "foo" and "bar", as a multiVPN attachment.

VPN "foo" has three classes of service, called H, M and L.
VPN "bar" also has three classes of service, called square, circle and triangle.

Now, for packets that are mapped to VPN "foo" (per the VPN policy), I need to set a QoS classification policy with target classes H, M and L.  
But, for packets that are mapped to VPN "bar" (per the VPN policy), I need to set a QoS classification policy with target classes square, circle and triangle.  However, with the model it is only possible to have a single QoS classification policy for the whole site.  So, I must configure a policy that has all six target classes (H, M, L, circle, square and triangle) and try to ensure that packets that will be mapped to VPN "foo" get target class H, M or L and packets that will be mapped to VPN "bar" get target class circle, square or triangle.  This is very hard since which VPN the packets get mapped to depends on routing information, which is dynamic.

I know this is a contrived example, but you can easily think of more realistic cases, e.g. the site is attached to both a VPN service with EF, AF and BE classes and also attached to an internet access service that only has a single class. 

[Qin-1]: You forget that we also have target-sites defined under 'qos-classification-policy', target-sites will be an alternative way to identify the destination of a flow targeted to specific VPN besides using destination address, VPN-attachment tell us which site is attached to which VPN, no matter whether one site is attached to one VPN, or two VPNs. Combining VPN-attachment and target-sites, we will know how to map specific VPN(Indicated by target sites) to specific target class. Each site will also know how to correctly apply QoS policy.

>>> 	12.	On similar lines, in the qos-profile there is a guaranteed-bandwidth, which can either be for just the access, or can be end-to-end.  How should an end-to-end bandwidth guarantee be interpreted if the VPN has more than two sites?  Or does it only make sense for a P2P case?
>>> 		
>>> 	[KO] Same comment as above. As I know, a SP controls the bandwidth at input/output of PE.
>>>
>>>
>>> [DB] Agreed - but again, the question is about the meaning of the attribute rather than where the SP implements it.  In a VPN with 10 sites, what does it mean to say that the end-to-end bandwidth is 10Mb/s?
>>>
>>> [KO] For our case, this means not an end-to-end qos, but an access qos. If a SP wants an end-to-end qos, he/she must negotiate some constraints or conditions with her/his customer outside of this model.
>> [DB2] My question was specifically about when the end-to-end leaf is 
>> set to true.
>>
>> [SLI] The main use case is P2P, but if it is set for a class which involves more than two sites, the reservation will be done to all the sites involved.
> [DB3]
> So, for example, suppose I have a VPN with 5 sites, with the following
> settings:
>    * Site A: svc-input-bandwidth = svc-output-bandwidth = 100000000, for class "foo" guaranteed-bw-percent = 10, end-to-end = true
>    * Site B: svc-input-bandwidth = svc-output-bandwidth = 200000000, for class "foo" guaranteed-bw-percent = 20, end-to-end = true
>    * Site C: svc-input-bandwidth = svc-output-bandwidth = 300000000, for class "foo" guaranteed-bw-percent = 30, end-to-end = true
>    * Site D: svc-input-bandwidth = svc-output-bandwidth = 400000000, for class "foo" guaranteed-bw-percent = 40, end-to-end = true
>    * Site E: svc-input-bandwidth = svc-output-bandwidth = 500000000, 
> for class "foo" guaranteed-bw-percent = 50, end-to-end = true
>
> What does this mean?  What bandwidth is reserved between each of the 10 pairs of sites?
>
> [Qin]: set end to end leaf as true means bandwidth reservation is applied to end to end connectivity, across MPLS transport network.
> Set end to end leaf as false means bandwidth reservation is only applied to access connectivity for customer site.
> Choose class "foo" with specific target site, we know from which site to which site bandwidth reservation needs to be performed.

[DB4] If the SP receives a request with the above data, what bandwidth do they need to reserve end-to-end between A and B, or between E and C?

[Qin-1]: Just like we use RSVP or RSVP-TE to reserve resource across network. If we specify target-sites under ' qos-classification-policy ', we will know from which source site to which target site the bandwidth needs to be reserved across the network. The target-sites could be a list,e.g, Site A is the source site, SiteB, Site D are part of target-sites list, we can reserve the same bandwidth from Site A to Site B as the one from Site A to Site D.

>>> 	13.	Lots of questions about the routing-protocols:
>>> 	
>>> 		1.	When the routing protocol is "direct", the SP routes traffic towards the prefix specified by the connection address; however, one would expect that they always do this regardless of what other routing protocol is in use, right?  So, what is the difference between specifying routing protocol "direct", and leaving the routing protcol list empty?
>>> 	
>>> 	
>>> 	[KO] The list routing-protocol has the entity with "type" as the key. Then empty routing protocol is not allowed.
>>>
>>>
>>> [DB] I meant an empty list, not an empty element in the list.  There is no "min-elements" on the routing-protocol list, so the list itself could be empty.
>>>
>>> [KO] I understand. I think it should specify the "min-elements" with one entity. But, we may be able to understand the case as the direct, if the list is empty.
>> [DB2] Right - so if the "direct" case can be represented by an empty 
>> list, then there is no need to explicitly specify "direct".
>>
>> [SLI] Some SPs prevents to advertise the interco subnet except if the customer really requires it.
> [DB3]
> Sorry I did not understand how this relates to the issue?
>
> [Qin]: Why not specify direct route in the model if direct route need to be supported? We could ad min-element "1" to make sure the list cannot be empty.

[DB4]
My opinion would be the opposite - why force it to be specified if it's not needed?
Probably the best option is to leave it as it is, i.e. it can be specified or not.

[Qin-1]: I like to argue why not respect direct route as many other optional routing protocol such as bgp, ospf.:-)  Many Thanks for your valuable comments.

     David

--
David Ball
<[e-mail]>