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

[Qin Wu <[e-mail]>]

-----邮件原件-----
发件人: 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]>