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

["[e-mail]" <[e-mail]>]

Hi David

See comment inline, please.

Thanks,
Kenichi
 
On Aug 25, 2017 8:04 PM, "David Ball" 
<[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.
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.
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.

>
>Thanks,
>
>
>     David
>
>
>On 24/08/2017 12:11, Qin Wu wrote:
>> -----邮件原件-----
>> 发件人: 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]>
>>
>
>-- 
>David Ball
><[e-mail]>
>
>