Re: [L3sm] Next Step of RFC8049

[Qin Wu <[e-mail]>]

Sorry to chime in, a few comments line (marked with [Qin]).
-----邮件原件-----
发件人: L3sm [mailto:[e-mail]] 代表 David Ball
发送时间: 2017年6月22日 20:26
收件人: [e-mail]; Ogaki, Kenichi; Qin Wu; [e-mail]
主题: Re: [L3sm] Next Step of RFC8049

Thanks Stephane - responses in line (marked [DB3]):

On 21/06/2017 10:56, [e-mail] wrote:
> Hi,
>
> Please find some comments inline (marked with [SLI])
>
>
>> 	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?

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

>>
>> 	8.	There is a 'svc-mtu' leaf under the site-network-access; however, it's not mentioned in section 6 and it's not clear how it's intended to be used.  At least for IPv4, packets larger than the MTU can be fragmented (although that might be undesirable, so it might be useful to have a per-VPN knob to disable it).  I think the minimum requirement is that the customer and the SP agree on the lowest MTU across the whole VPN, so that the customer can be certain that packets shorter than that will be delivered.  Of course, the customer might use techniques like path MTU discovery to determine that they can use a larger MTU for particular paths.  I think it would be useful to have some discussion of this topic in the RFC.
>> 	
>> 	[KO] This leaf is required to be set the value if a customer requires to do so. But, I have no idea about the case.
>>
>>
>> [DB] Anyone else?  It doesn't seem useful to have a leaf in the model if we don't know what it means...
>>
>>
> [SLI] This was mainly introduced for two use cases:
> - customer requiring a specific IPv4 or IPv6 MTU (jumbo MTU)
> - carrier's carrier case where the connection is an MPLS connection and not more IP, so we need to know what is expected in term of "mpls mtu"
> For sure the customer needs to fill consistent informations in order to make it working.

[DB3]
Right - so this could use some more explanation in the text I think.

[Qin]: Sure.
>
>> 	9.	There is a per-site limit on the number of  IPv4/IPv6 routes ("maximum-routes") - is this the maximum number of routes that can be advertised by the customer towards the SP at that site?  In a multi-VPN case, would it be useful to have a per-site, per-VPN limit, e.g. in the case where one of the VPNs is an extranet, to limit the number of prefixes that can be advertised into the extranet at that site?
>> 		
>> 	[KO] It may be useful, but a solution is required, and I don't know such an existing solution.
>>
>>
>> [DB]: Ok, yes I can see how implementing that might not be straightforward.
>>
>>
>>
>> 	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.

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

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