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

["Jan Lindblad (jlindbla)" <[e-mail]>]

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.

That is exactly right. For a standard to be useful/interoperable, the system behavior needs to be predictable. Undefined behavior needs to become defined or outlawed. I don't have any particular sentiment about what is the right behavior, you are the experts there. From a YANG perspective, too many mandatory leaves might make a model a little clumsy+rigid.

/jan


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.

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]<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]
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]<mailto:[e-mail]>>