Re: [L3sm] 答复: New Version Notification for draft-wu-l3sm-rfc8049bis-02.txt

["Ogaki, Kenichi" <[e-mail]>]

Hi David,

See comments inline, please.
Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[e-mail]] On Behalf Of Qin Wu
Sent: Wednesday, August 30, 2017 9:40 PM
To: ke-oogaki; daviball
Cc: l3sm; stephane.litkowski; [e-mail]; adrian
Subject: [L3sm] 答复: New Version Notification for draft-wu-l3sm-rfc8049bis-02.txt




Sent from HUAWEI AnyOffice
发件人： daviball
收件人： ke-oogaki;
抄送： Qin Wu; l3sm; stephane.litkowski; adrian; Jan Lindblad (jlindbla);
主题： Re: [L3sm] New Version Notification for draft-wu-l3sm-rfc8049bis-02.txt
时间： 2017-08-30 19:19:28



Hi Kenichi,



On 25/08/2017 13:59, [e-mail] <mailto:[e-mail]>  wrote:



		Hi Qin,
		
		Looking back at Jan's comments, I think his point was not that the 
		leaves should all be mandatory, but that they should either be 
		mandatory, or they should have descriptions that explain the meaning if 
		they are not present.  So I think we are basically in agreement (I said: 
		"Also this use case needs to be mentioned in the description for those 
		leaves.") - but I've copied Jan in case I have mis-interpretted what he 
		said.
		
		I disagree that the connection subnet is always requested by the 
		customer - a very common scenario where this is not the case is for 
		residential internet access.  In that case, the addresses used behind 
		the CE are typically from private address space, so the customer can be 
		confident that they won't conflict with whatever the provider has chosen 
		to use (and allocate with DHCP) on the PE/CE link.  Another common case 
		is where it is a provider-managed CE, so the connection addressing 
		applies to the downstream link from the CE to the customer, not to the 
		PE/CE link.  In this case the customer may not have any of their own 
		subnets (i.e. everything is directly connected (at L3) to the CE), so 
		there is no chance of a conflict.

	[KO] As an VPN service provider, our customer really specifies the addresses for provider-customer boundary links in our commercial service. I believe the other service providers also do so.


[DB] That's fine, we are not trying to preclude that case.  However, making the leaves mandatory means that it must always be done this way, i.e. that there are never cases where the provider chooses the addressing.  I don't believe that is the case.

[KO2] I agree. We shouldn't preclude any potential/future use cases. Then, it's appropriate that these leaves are optional.

	As the abstract says, this model is limited to BGP PE-based VPN service. Your scenario for a residential internet access is out of scope.


[DB] Cloud access, including internet access, is included in the model.
[Qin] just to clarify, we don't model internet access as a site network connectivity, similar to public cloud, it is a external service which the current l3vpn service can get access to. 


	As shown in a diagram at Section 6.11, the provider-managed CE case considers that customer routers exist under a provider-managed CE. In that case, we can easily imagine address conflict between a CE-customer router link and subnets under a customer router. Also, even if a site is a provider-managed CE site, but if any other site is a customer-managed CE site and allocates addresses by themselves, an address conflict must happen.


[DB] Yes; but there may be a case where there are no customer routers, just customer hosts connected directly to the provider-managed CE or connected directly to the PE (as described in section 6.11.2).  In this case there is no possibility of conflict.

[Qin] talking with l3sm design team,we believe In case of two site network accesses belonging to the same Von service, address conflict between two site network accesses should be avoided.
    David





			 -----邮件原件-----
			 发件人: David Ball [mailto:[e-mail]]
			 发送时间: 2017年8月23日 19:48
			 收件人: Ogaki, Kenichi; Qin Wu; [e-mail]
			 抄送: 'Stephane Litkowski'; [e-mail]
			 主题: Re: [L3sm] New Version Notification for draft-wu-l3sm-rfc8049bis-02.txt
			
			 On 22/08/2017 11:13, Ogaki, Kenichi wrote:
			

				 Hi Qin,
				

					        2. For the connection addresses, the provider's IP address/mask:

				 As for dhcp related provider-addresses and the masks, these are not what SP provides, but the subnet which the customer requests to specify the leased address subnet. Then, these must be configurable.

			 So you're saying even when DHCP is used, the customer can request that addresses will be allocated from a specific subnet?  That's not something I've heard of, but ok. :)  These leaves should definitely be optional in that case, as the more normal case is that the customer does not request a specific subnet.  Also this use case needs to be mentioned in the description for those leaves.
			
			 [Qin]: Early on in the YANG Doctor review from Jan, one suggestion was to make provider-address and customer-address mandatory parameter.
			 https://www.ietf.org/mail-archive/web/l3sm/current/msg00677.html
			 We think his point is valid and have implemented his comment.
			 Talking with L3SM design team members recently, it has been agreed that all these parameters (irrespective of DHCP case or static case )are basically specified/requested by a customer.
			 Otherwise, address conflict occurs between provider-allocated subnets (PE-CE links) and customer-allocated subnets (under CE).
			 So for consistency, I think we should make all these parameters as mandatory parameters.
			
			       David
			

				 Thanks,
				 Kenichi
				
				 -----Original Message-----
				 From: L3sm [mailto:[e-mail]] On Behalf Of Qin Wu
				 Sent: Monday, August 21, 2017 5:39 PM
				 To: David Ball; [e-mail]
				 Cc: Stephane Litkowski; Kenichi Ogaki; [e-mail]
				 Subject: Re: [L3sm] New Version Notification for
				 draft-wu-l3sm-rfc8049bis-02.txt
				

					 11. In accordance with the clarified scope, parts of the model that correspond
					         with information provided by the SP need to be marked with "config false".
					         I've identified the following, but there might be more.
					        1. The list of profiles of various types (i.e. l3vpn-service/vpn-profiles)
					        2. For the connection addresses, the provider's IP address/mask:
					       • l3vpn-service/sites/site/site-network-accesses/site-network-access/ip-connection/ipv4/provider-dhcp/provider-address
					       • l3vpn-service/sites/site/site-network-accesses/site-network-access/ip-connection/ipv4/provider-dhcp/mask
					       • l3vpn-service/sites/site/site-network-accesses/site-network-access/ip-connection/ipv4/dhcp-relay/provider-address
					       • l3vpn-service/sites/site/site-network-accesses/site-network-access/ip-connection/ipv4/dhcp-relay/mask
					       • l3vpn-service/sites/site/site-network-accesses/site-network-access/ip-connection/ipv4/addresses/provider-address
					       • l3vpn-service/sites/site/site-network-accesses/site-network-access/ip-connection/ipv4/addresses/mask
					       • l3vpn-service/sites/site/site-network-accesses/site-network-access/ip-connection/ipv6/provider-dhcp/provider-address
					       • l3vpn-service/sites/site/site-network-accesses/site-network-access/ip-connection/ipv6/provider-dhcp/mask
					       • l3vpn-service/sites/site/site-network-accesses/site-network-access/ip-connection/ipv6/dhcp-relay/provider-address
					       • l3vpn-service/sites/site/site-network-accesses/site-network-access/ip-connection/ipv6/dhcp-relay/mask
					       • l3vpn-service/sites/site/site-network-accesses/site-network-access/ip-connection/ipv6/addresses/provider-address
					       •
					 l3vpn-service/sites/site/site-network-accesses/site-network-access/ip
					 -connection/ipv6/addresses/mask

				    
				
				 That sounds reasonable.
				
				 [Qin]: One more comment, we can not put ‘config false’ for
				 l3vpn-service/vpn-profiles, since Config true leafrefs MUST NOT refer
				 to config false data
				
				 This issue was discussed before, see discussion available at:
				
				 https://www.ietf.org/mail-archive/web/l3sm/current/msg00683.html
				
				
				

			 --
			 David Ball
			 <[e-mail]> <mailto:[e-mail]> 
			

		-- 
		David Ball
		<[e-mail]> <mailto:[e-mail]> 
		
		

	


-- 
David Ball
<[e-mail]> <mailto:[e-mail]>