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

[David Ball <[e-mail]>]

Hi Kenichi,


On 25/08/2017 13:59, [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.

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

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


     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]>
>>>
>> -- 
>> David Ball
>> <[e-mail]>
>>
>>

-- 
David Ball
<[e-mail]>