Re: [L3sm] Next Step of RFC8049

Thanks Kenichi - more comments inline.  It would be great to hear some 
other opinions too.

On 14/06/2017 10:09, Ogaki, Kenichi wrote:
> Hi David,
>
> Thanks for you comments.
> See more comments inline, please.
>
> Thanks,
> Kenichi
>
> -----Original Message-----
> From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of David Ball
> Sent: Monday, June 12, 2017 11:39 PM
> To: Ogaki, Kenichi; 'Qin Wu'; l3sm@ietf.org
> Subject: Re: [L3sm] Next Step of RFC8049
>
> Thanks Kenichi, please see further thoughs inline:
>
>
>
> On 08/06/2017 05:01, Ogaki, Kenichi wrote:
>
>
> 	Hi David,
> 	
> 	As an author and operator, see comments inline, please.
> 	Stephane, luis, could you correct me if I misunderstand?
> 	
> 	Thanks,
> 	Kenichi
> 	
> 	-----Original Message-----
> 	From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of David Ball
> 	Sent: Saturday, June 03, 2017 12:08 AM
> 	To: Qin Wu; l3sm@ietf.org
> 	Subject: Re: [L3sm] Next Step of RFC8049
> 	
> 	Hi Qin,
> 	
> 	
> 	As you are working on a bis version, I have a few questions on RFC8049 that might lead to discussion on the list, and perhaps some further changes.
> 	
> 	
> 	1.	The scope of the RFC seems to be focused on information that needs to be passed from the customer to the SP (e.g. in a "request"); however, clearly for the customer to be able to use the service, there is also information that needs to be passed back from the SP to the customer.  It seems that the model is not intended to cover that - is that right?  I think that's fine, but it would be helpful to make this clearer (perhaps in section 5?)
> 	
> 	[KO] That's right.
>
>
> [DB]: Ok, thanks.  Qin, if you are developing a bis version, it would definitely help to make this clearer near the start of the doc.
>
>
>
> 	2.	I have some questions about the concept of a "site".  In the simplest case, it seems clear that this means a single physical location, with one or more connections (site network accesses) to the SP.  The RFC also describes a case where a single "site" could be in multiple locations that are interconnected independently of the VPN service - the example given is multiple offices in the same city.  Does this extend more generally?  E.g., if two locations in different cities are connected by a backdoor link, does that mean they're the same site?  What about if the backdoor link is only used for backup (i.e. when connectivity via the VPN is down)?  Is a "site" always completely disconnected (topologically) from other sites (other than via the VPN service)?
> 	
> 	[KO] This case of the backdoor is a corner case and a service model should not define such corner cases.
>
>
> [DB] Ok - but what about my more general question?  Is a single site always assumed to be topologically disconnected from other sites?
>
> [KO] I don't think so. If a customer connects two sites with a backdoor and appropriately advertises both sites' routes to both connected PEs by using a dynamic routing protocol, both sites should still be reachable when the break of one of PE-CE links occurs.

[DB2]
Ok - so in general, if the Subscriber has a number of access connections 
(i.e. site-network-accesses) connecting various parts of their network 
(wherever they are located) to the SP, it is up to them to determine how 
to group them into sites?

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

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

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

> 	6.	On that subject, the yang module has /l3vpn-svc/vpn-services/vpn-service/cloud-accesses/cloud-access/list-flavor, which is a choice of permit-any, permit-any-except and deny-any-except.  It also has /l3vpn-svc/vpn-services/vpn-service/cloud-accesses/cloud-access/authorized-sites and /l3vpn-svc/vpn-services/vpn-service/cloud-accesses/cloud-access/denied-sites, which seem to serve the same purpose.  This looks like an error - was one of these supposed to be deleted?  If not, what is the difference?  I noticed that section 6.2.2 only mentions the first one (list-flavor/...).
> 	
> 	
> 	[KO] I think you are right. deny-any-except looks same as authorized-sites, and permit-any-except does denied-sites.
>
> [DB] Qin, will you be fixing this in the bis version?
>
>
>
> 	7.	Sticking with cloud access, there is an option for enabling NAT44.  However, only a single address can be specified.  For some big enterprise customers, when NAT is used, more than one public-facing address is needed (typically from the same IP prefix) - is there a way to accommodate that case?
> 	
> 	[KO] The current model can cover the case. SP just has to pick a range of addresses, but some augmentations, how many addresses are required, is desired.
>
>
> [DB] Ok.
>
>
>
> 	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...
>
>
>
> 	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?

> 	11.	The related qos-profile has constraints on latency and jitter; however, these apply to all packets in a flow.  So, for example, if there were sites in London, Paris and San Francisco, the same latency constraint would apply to packets from London to Paris and packets from London to San Francisco, which doesn't seem very useful.  Similarly, in a multi-VPN case, the same constraints would apply regardless of which VPN the packet maps to.  This type of constraint would normally be in an SLS, but I thought in general the approach was to avoid trying to specify an SLS in the model?
> 		
> 	[KO] Same comment as above. And, I agree with your thought about the SLS.
>
>
> [DB] Ok.  I don't know when this was added, I don't remember seeing it in the drafts I looked at at the time.  Do you think it should be removed in Qin's bis version?
>
> [KO] I don't think so. If a SP wants to allow the customer to specify the latency or jitter from London to Paris, this can work. It's up to an SP.

[DB2] Right, but the way the model is, the model can't be used to 
specify the latency or jitter from London to Paris, it is just a single 
value for the VPN as a whole.

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

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

> 		2.	The purpose of VRRP is to be opaque to the customer - so it's not clear why the customer would explicitly request this?  Is the intent to capture that the customer wants to ensure there is redundancy of the access link at L2? If so, perhaps it would be better handled by having some sort of access constraint for "l2-diverse"?
> 			
> 	[KO] From an operator's perspective, VRRP has common consensus for L3VPN customers rather than what l2-diverse means.
>
>
> [DB] Ok.
>
>
>
> 		3.	For OSPF, doesn't some information on the timers (hello interval, dead interval, retransmit interval) need to be exchanged, so that the customer and SP can configure their devices in such a way that they won't time each other out?  Perhaps the intent is that the SP specifies these, and it's not covered in the model (going back to my first question)?  If so, it would be useful to make this explicit.
> 	
> 	[KO] As you wrote, that's negotiated outside of this model.
>
>
> [DB] Ok.
>
>
>
> 		4.	For OSPF, a metric can be specified - the only description is "Metric of the PE-CE link".  How is this intended to be used?  How does this relate to the 'access-priority' for the site-network-accesses, which is supposed to be used to influence load-sharing and active/standby?
> 	
> 	[KO] As described above, I think how to behave the combination of a routing protocol and an access priority is up to a SP. The routing protocol may work on the active link specified by the access priority.
>
>
> [DB] I don't see how a customer will be able to use these parameters correctly/appropriately if the corresponding behaviour isn't clearly described.  What is expected to happen if the customer sets the OSPF metric to a particular value?
> (Also, if it is a provider-managed CE, is this really the metric of the PE-CE link?)
>
> [KO] As I wrote, a SP must inform how this mechanism works to his/her customer outside of this model. It depends on each SP's implementation.

[DB2] Ok; in my opinion, having things in the model without any 
information about how they should be used is not useful, but so be it.

> 		5.	For BGP, there is an AS number, but is it supposed to be the customer's AS number or the SP's AS number?  The description just says "AS Number", which is not very illuminating.
> 			
> 	[KO] That's customer's AS number. It's obvious that a SP has an AS number for their L3VPN service. For example of KDDI, 9996 is our IPVPN AS number.
>
>
> [DB] I think it would be useful to clarify it.  Qin?
>
>
>
> 		6.	Also I think there is a lot more that would need to be agreed on for BGP; for instance, the timers (similar to the OSPF case), authentication (e.g. MD5+password), whether the SP will apply "AS override" behaviour, etc.
> 	
> 	[KO] Same as OSPF. Some specific function should be augmented if a SP wants to use, although we want the authentication.
>
>
> [DB] Ok.
>
>
>
> 		7.	For dual-stack BGP, the text says it is up to the SP to decide whether to use one session or two sessions - but clearly the customer needs to know this too so that they can configure their devices accordingly.  Is that intended to be outside the scope of the model?  It would be useful to clarify it.
> 			
> 	[KO] I think this is also communicated outside of the model.
>
>
> [DB] Ok.
>
>
>
> 		8.	It also says that the session addressing is derived from the connection parameters - this is a common case, but not the only way to do it.  For example, if there are multiple site-network-accesses, then the SP may decide to use a single BGP session between loopbacks, using EBGP-multihop, rather than a separate BGP session on each site-network-access.  Can the model accomodate this case?
> 			
> 	[KO] The current model only supports the latter case. An argumentation is required if a SP wants to use the former one.
>
>
> [DB] Ok.
>
>
>
> 		9.	For static routing, each prefix has a mandatory nexthop; however, for P2P L2 technologies (e.g. PPP, ATM), the nexthop might not be needed, right?
> 	
> 	[KO] From a PE's perspective, the next hop for a LAN/subnet behind CE with PE-CE P2P link should be the CE end point of the P2P link.
>
>
> [DB] Right, but for a P2P L2 technology, the IP nexthop doesn't need to be specified, right?
>
> [KO] That's right. But, I think it's same as the direct case described in 6.11.2, and don't need even static routing.

[DB2] Ok.

> 	14.	Lots of parameters can be specified either on the site or on the site-network-access.  However, BFD can only be specified on the site-network-access.  Is there a reason for this?  I would have thought if you want BFD on one site-network-access, you probably want it on all of them, with the same parameters, so having the possibility of specifying it once under the site would seem useful.
> 		
> 	
> 	[KO] As you wrote, the current model can cover the case, if a SP wants to extend to inherit so,  he/she can augment.
>
>
> [DB] Agreed - but I was wondering if there was a reason it was done this way originally?  Or was it just an oversight?
>
> [KO] I think, if a solution covers two requirements, each solution for each requirement is not always necessary.

[DB2] Agreed - my question is why, in this particular case, only the 
per-access solution was included whereas for other attributes, both 
mechanisms were included.  What was the specific rationale for not 
adding BFD as a per-site attribute?

> 	15.	Some questions about the IPv4/IPv6 connection for each site-network-access:
> 	
> 		1.	When DHCP is used, the provider address and mask aren't specified - but doesn't the customer need to know this, so as to avoid allocating addresses within that prefix to their internal devices?  Or does this again fall into the category of information passed from the SP to the customer, and hence not in the scope of the model?
> 			
> 		2.	Similarly, when DHCP is used, the customer may still want some statically-assigned hosts on that subnet (e.g. for servers etc).  There is a leaf for saying how many DHCP addresses are being requested, but I think the customer would also need to know which addresses, so that they can assign other addresses on that subnet statically, right?
> 			
> 	[KO] Agree. Even for the provider-dhcp case, a customer must at least be able to require the provider-addrss, PE address/subnet.
>
>
> [DB] I guess given your other answers, this would be outside the scope of the model?
>
> [KO] No, I think the model should definitely specify this.

[DB2] Ok.  Qin, should we add this?

> 		3.	When DHCP-Relay is used, does it make sense to have a multi-VPN case?  I'm not sure how the SP would know which VPN to forward the DHCP requests over in this case.
> 			
> 	[KO] The customer must specify the DHCP server address, a SP just forwards a DHCP request there based on the routing table even in multi-VPN case.
>
>
> [DB] Ok.
>
>
>
> 		4.	For IPv6 connection, is there a case where only link-local addresses are used?
> 	
> 	[KO] No, a global one is also supported.
>
>
> [DB] I meant, if the customer wanted to use only LL addresses on the link, is there a way to specify that?
>
> [KO] The customer just has not to assign a global address. But, the model may be better to definitely specify which type of IPv6 address is used.

[DB2] Right, I don't think this can be specified in the model at the 
moment.  Qin, something else to add?

     David

> 	16.	Under the site-network-access, there is a svc-input-bandwidth and svc-output-bandwidth.  Section 6.12.1 says that input/output is from the site's perspective, i.e. "input bandwidth" means download from the SP towards the site, and "output bandwidth" means upload from the site towards the SP.  However, the descriptions of the leaves within the module say the opposite: svc-input-bandwidth is "From the PE's perspective, the service input bandwidth of the connection." and likewise for output.  To my mind, expressing this from the SP's perspective makes more sense (i.e., it is input to or output from the VPN service) - but either way, the document should be consistent and not contradict itself.  Note that these leaves are also refered to in section 6.12.2.2 for the QoS profile - that text might also be affected when resolving the conflict.
> 	
> 	[KO] Agree.
>
>
> [DB] Qin, will you fix this?
>
>
>
> 	17.	The access-priority leaf is supposed to be used to define a preference for load-balancing or active/standby when there are multiple site-network-accesses.  However, it wasn't clear to me whether this was intended to apply to ingress traffic, egress traffic, or both; or how it relates to the routing protocol metrics/costs.  When the customer sends traffic towards the SP, they can chose whichever site-network-access they like, and the SP should deliver the traffic, so it seems that nothing needs to be specified in that case; if so, the access-priority would only apply to traffic flowing from the SP to the customer.  However, assuming a dynamic routing protocol is used, the customer ought to be able to influence that by advertising different metrics on the different site-network-accesses (provided the SP honours these).  The only more complex case I could think of is where there's a desire to ensure that traffic always flows bidirectionally on the same link - but then, I
> 	couldn't figure out how the access-priority could help with that.  Am I missing something?
> 	
> 	[KO] As above described, I think How this works is up to a SP.
>
>
> [DB] Ok - but it doesn't seem very useful if the customer doesn't know how the SP will use it; how will the customer know what to request?
>
> [KO] As described above, a SP must inform how this mechanism works to his/her customer outside of this model.
>
>
>      David
>
>
>
>
> 	
> 	
> 	
> 	On 09/05/2017 14:57, Qin Wu wrote:
> 	
> 	
> 		Dear L3SM list,
> 		
> 		As you saw, Jan did a very good review of the L3SM YANG model, and there has
> 		been a little discussion on this list.
> 		
> 		I am preparing a bis draft to include all of the comments. The plan is:
> 		- I show the draft to Jan and the authors of the RFC
> 		- I post the draft
> 		- We review it on this list
> 		- We ask Benoit to AD sponsor it
> 		
> 		I hope to have the revision ready very soon.
> 		
> 		Regards,
> 		Qin
> 		
> 		
> 		Sent from HUAWEI AnyOffice
> 	
> 		
> 		
> 		_______________________________________________
> 		L3sm mailing list
> 		L3sm@ietf.org
> 		https://www.ietf.org/mailman/listinfo/l3sm
> 	
> 	
>
>

-- 
David Ball
<daviball@cisco.com>