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

[Qin Wu <[e-mail]>]

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.


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]<mailto:[e-mail]>
 抄送: 'Stephane Litkowski'; [e-mail]<mailto:[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]<mailto:[e-mail]>
 Cc: Stephane Litkowski; Kenichi Ogaki; [e-mail]<mailto:[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]>